I'm at the stage now where I'm trying to work out the timing code for the clock frequency. I was up too late last night trying to figure out how the propeller counters work. ;-)
I managed to get some "accurate" clock signals generated from the propeller such as 2.5MHz, 5.0MHz, etc.
One of the first issues I've run into is how to get a signal at 3.5MHz with as little jitter as possible. I've got some more learning to do with those counters.
In regards to the WAIT states, I don't think I will need them. I know that is the "proper" way to tell the Z80 to wait for slower devices. But the design I am trying to mimick is the ZX Spectrum. The ULA chip on that computer halted the clock for contended memory.
Anyway, I was also trying to think of ways to reduce pin counts on the prop and my naive engineer's mind (hehehe) thought, "Hey! I might be able to do it with no address pins!".
So here is what I was thinking....at the beginning of each scanline I use one prop pin to "activate" some address decoding logic using various gates/IC's. This decoding logic could even halt the CPU. This will of course take a little time during my hsync setup. Then, I would use another prop pin to clock some counters (or *something*) and strobe/step through the next 32 bytes for the scanline. If I'm lucky, I can grab that during the hsync and just keep the CPU stopped while I draw the line. Of course, I will also have to get the attribute (colors) from another section of RAM so there would be another address decoding. But with the color attributes, I have another 32 bytes but it's used for 8 lines so I might be able to spread the work out some. Or maybe I could have something in the address decoding that could jump to the attribute location for the next line in the right border.
Bottom line, my idea is to use:
8 pins for data bus.
1 pin to enable address decoding.
1 pin for Z80 clock.
Now, keeping the component count low is important. But I'm not making a million dollar project here. I want to approach this in a somewhat similar way I approach software...get it working well then optimize. So if I need to add a few buffers, counters, etc. then so be it. :-)
Comments
I'm at the stage now where I'm trying to work out the timing code for the clock frequency. I was up too late last night trying to figure out how the propeller counters work. ;-)
I managed to get some "accurate" clock signals generated from the propeller such as 2.5MHz, 5.0MHz, etc.
One of the first issues I've run into is how to get a signal at 3.5MHz with as little jitter as possible. I've got some more learning to do with those counters.
In regards to the WAIT states, I don't think I will need them. I know that is the "proper" way to tell the Z80 to wait for slower devices. But the design I am trying to mimick is the ZX Spectrum. The ULA chip on that computer halted the clock for contended memory.
Anyway, I was also trying to think of ways to reduce pin counts on the prop and my naive engineer's mind (hehehe) thought, "Hey! I might be able to do it with no address pins!".
So here is what I was thinking....at the beginning of each scanline I use one prop pin to "activate" some address decoding logic using various gates/IC's. This decoding logic could even halt the CPU. This will of course take a little time during my hsync setup. Then, I would use another prop pin to clock some counters (or *something*) and strobe/step through the next 32 bytes for the scanline. If I'm lucky, I can grab that during the hsync and just keep the CPU stopped while I draw the line. Of course, I will also have to get the attribute (colors) from another section of RAM so there would be another address decoding. But with the color attributes, I have another 32 bytes but it's used for 8 lines so I might be able to spread the work out some. Or maybe I could have something in the address decoding that could jump to the attribute location for the next line in the right border.
Bottom line, my idea is to use:
8 pins for data bus.
1 pin to enable address decoding.
1 pin for Z80 clock.
Now, keeping the component count low is important. But I'm not making a million dollar project here. I want to approach this in a somewhat similar way I approach software...get it working well then optimize. So if I need to add a few buffers, counters, etc. then so be it. :-)