Hmmmm – Ok
I had the idea that i could simplify and bulletproof my millisecond interrupt generator by just issuing a brief (20-30 uS) pulse every millisecond and ignoring the Z80’s pulse that clears it. The pulse would have to be long enough to still be there when the z80 reads the input port to check the source of the interrupt. I did a logic analyzer capture that included the /in signal so I see my /khz signal go low, then 17 uS later the Z80 reads the port(/in) then 13 uS later it writes the port to clear it. That’s fine, a 20-25 us pulse would cover it but then the Z80 issues 4 more reads! Sadly, I’ll have to trace and time the logic to see what’s going on. Or maybe I’ll just try it.
Ok, looking at the code, the IN that tests for the clock interrupt is at 53 cycles in, the OUT that resets it is at 105 cycles. those are close enough to my measurements to satisfy me. All the other I/O is Josh scanning the keyboard and led’s.
So I think a 25 uS pulse will be just fine. Mind you, the EI that re-enables interrupts is right after the OUT at 105 so I will have to pay attention if I speed up the Z80 much.
I’d like to maintain as much of josh’s memory locations as I can so I’ll need to shoehorn my mods in to jump around his code carefully.
Annnd No! The trace looks fine but running the blink I get just a tiny blip every second or so like when it was triggering continually.
Annnd Again No! I put back the code i had yesterday where the avr waited for the signal an di got the same result. I’ll have to look harder at the ISR.
HAH! Of course the code is littered with OUT’s and IN’s – it’s using that port to update LEDs and to send serial data!