Eudimorphodon
Veteran Member
Electronics design question: SRAM/ROM read "Duty Cycle"? Also, Z80 wait states.
Today I was working on the "video card" project I mentioned in a thread in the CP/M section. Specifically I was working on a likely codebase switch for the software I'm using as the basis of the timing for the card (the one I was working with on the initial prototype had a "no distribution without permission" encumbrance, so I'm either going to try rewriting it entirely from scratch or, more likely, heavily borrowing from Nick Gammon's Arduino VGA library), and I noticed a "bug" in my current code that, despite its presence, seems to allow the device to work fine anyway. If in fact what the "bug" does is kosher that would actually be a good thing for my purposes, so I'm wondering if anyone can confirm it's all right.
To cut a long story as short I can the code running on the MCU bit-bangs via port writes as quickly as possible the following actions:
1: Lower a pin that's connected to both "OE" and "Read" on a memory chip. (Currently a flash ROM, in the final version, RAM character buffer.)
2: Currently a NOP, but in the final version will, in text mode, trigger OE/READ on a ROM. (character generator)
3: Toggle the "load" pin on a shift register connected to the output of the memory.
4: Toggle a "clock" pin on a counter that accelerates line address generation.
5: Un-assert OE/READ on the memory.
6: Wait until we've done a total of 8 ticks and start over again. (I have 8 CPU clocks per byte, every assembly language instruction for this executes in one cycle.)
(Note that there is, or at least was intended to be, some interleaving in steps 1-5, multiple pins get toggled at once.)
What I discovered analyzing the code (by single-stepping it in the simulator) for porting from pure Assembly to a possible/probable mixed C/assembly environment was I'd messed up with the OE/READ cycling so once it got turned it stayed on for the entire line instead of toggling on and off, IE, the ROM is constantly outputting a value including, presumably, probably outputting some uncertain values when the address lines change.
On the actual hardware the video display looks fine, so the Flash memory at least doesn't seem to care. I got to thinking about it, and since I know ROMs (and sometimes SRAMS, in unique cases) sometimes get abused as PALs and mapping registers, can I assume it's actually okay to do this? (IE, just leave OE and READ on constantly and just not care about the un-settled outputs since, given the tick-latency, addresses and data should be stable when it counts, IE, when I trigger the shift register load.) Leaving out having to toggle them cuts the number of instructions needed per character by about half, and time is very much of the essence in a C-port of the code. Just wondering if anyone thinks this is asking for the chips in question to melt into goo.
(For writes to the frame buffer memory I'm planning to use a GAL for the CPU address decoder, and I can have it arbitrate the read/write status for the RAM depending which has control. One of the datasheets for a device I was thinking of using for the RAM does say it can go into a "low power" mode 20ns after OE is un-asserted that saves some significant amount of power, but it also doesn't seem to say anything specific about a 100% on duty cycle being a "problem". I could still turn off OE/READ during the blanking intervals with no sweat..)
In a related question: Is anyone here deeply familiar with how WAIT states are handled on the Z80? I was reading the TRS-80 Model III technical manual to try to understand how it eliminated the "hash" contention you get on a Model I when video memory is written. My understanding of what it says is when the anti-streaking mechanism is enabled whenever the machine is not inside one of various blanking areas an access to the screen addresses by the CPU will assert a WAIT line. Reading through it it looks like worst case the CPU could be effectively WAIT-ed for at least 64 character positions, which at the Model III's pixel clock/CPU speed ratio would be... around a hundred machine cycles?
Is this "excessive", or is this roughly typical of how anti-streaking is implemented on 1980-ish vintage low-cost video systems? (6502 systems of course don't count.)
Today I was working on the "video card" project I mentioned in a thread in the CP/M section. Specifically I was working on a likely codebase switch for the software I'm using as the basis of the timing for the card (the one I was working with on the initial prototype had a "no distribution without permission" encumbrance, so I'm either going to try rewriting it entirely from scratch or, more likely, heavily borrowing from Nick Gammon's Arduino VGA library), and I noticed a "bug" in my current code that, despite its presence, seems to allow the device to work fine anyway. If in fact what the "bug" does is kosher that would actually be a good thing for my purposes, so I'm wondering if anyone can confirm it's all right.
To cut a long story as short I can the code running on the MCU bit-bangs via port writes as quickly as possible the following actions:
1: Lower a pin that's connected to both "OE" and "Read" on a memory chip. (Currently a flash ROM, in the final version, RAM character buffer.)
2: Currently a NOP, but in the final version will, in text mode, trigger OE/READ on a ROM. (character generator)
3: Toggle the "load" pin on a shift register connected to the output of the memory.
4: Toggle a "clock" pin on a counter that accelerates line address generation.
5: Un-assert OE/READ on the memory.
6: Wait until we've done a total of 8 ticks and start over again. (I have 8 CPU clocks per byte, every assembly language instruction for this executes in one cycle.)
(Note that there is, or at least was intended to be, some interleaving in steps 1-5, multiple pins get toggled at once.)
What I discovered analyzing the code (by single-stepping it in the simulator) for porting from pure Assembly to a possible/probable mixed C/assembly environment was I'd messed up with the OE/READ cycling so once it got turned it stayed on for the entire line instead of toggling on and off, IE, the ROM is constantly outputting a value including, presumably, probably outputting some uncertain values when the address lines change.
On the actual hardware the video display looks fine, so the Flash memory at least doesn't seem to care. I got to thinking about it, and since I know ROMs (and sometimes SRAMS, in unique cases) sometimes get abused as PALs and mapping registers, can I assume it's actually okay to do this? (IE, just leave OE and READ on constantly and just not care about the un-settled outputs since, given the tick-latency, addresses and data should be stable when it counts, IE, when I trigger the shift register load.) Leaving out having to toggle them cuts the number of instructions needed per character by about half, and time is very much of the essence in a C-port of the code. Just wondering if anyone thinks this is asking for the chips in question to melt into goo.
(For writes to the frame buffer memory I'm planning to use a GAL for the CPU address decoder, and I can have it arbitrate the read/write status for the RAM depending which has control. One of the datasheets for a device I was thinking of using for the RAM does say it can go into a "low power" mode 20ns after OE is un-asserted that saves some significant amount of power, but it also doesn't seem to say anything specific about a 100% on duty cycle being a "problem". I could still turn off OE/READ during the blanking intervals with no sweat..)
In a related question: Is anyone here deeply familiar with how WAIT states are handled on the Z80? I was reading the TRS-80 Model III technical manual to try to understand how it eliminated the "hash" contention you get on a Model I when video memory is written. My understanding of what it says is when the anti-streaking mechanism is enabled whenever the machine is not inside one of various blanking areas an access to the screen addresses by the CPU will assert a WAIT line. Reading through it it looks like worst case the CPU could be effectively WAIT-ed for at least 64 character positions, which at the Model III's pixel clock/CPU speed ratio would be... around a hundred machine cycles?
Is this "excessive", or is this roughly typical of how anti-streaking is implemented on 1980-ish vintage low-cost video systems? (6502 systems of course don't count.)
