How fast can the propeller respond to external pin changes?
cbmeeks
Posts: 634
in Propeller 1
I read that the WAITPEQ checks the I/O pins every clock cycle.
Does this mean that I can reliably check pin transitions at 80MHz?
What I really need to know, actually, is if the propeller could respond to an external Z80 address read/write at 4MHz?
Thanks
Does this mean that I can reliably check pin transitions at 80MHz?
What I really need to know, actually, is if the propeller could respond to an external Z80 address read/write at 4MHz?
Thanks
Comments
Instructions run at 20MIPS, so it's going to depend on how many instructions you need to do all the operations (get the address, read the value from the hub, make the data pins outputs, put the value on the data pins, wait for the read to be over, set the data pins back to inputs).
Hmmmm, sounds like a tall order...
Bean
This is what I bought:
http://www.mouser.com/Search/ProductDetail.aspx?R=Z84C0010PEGvirtualkey69200000virtualkey692-Z84C0010PEG
I know very little about the Z80 but I'm learning.
Anyway, what my initial plan is (at a very high level) is to capture address $4000 - $5AFF (well, padded out to 8k perhaps) and use that as the video buffer. This is what the ZX Spectrum uses.
So in the ZX, the CPU is halted (clock actually stopped) during the video sweeps but other areas of memory are simple Z80/RAM.
That does concern me a little because I believe some clever ZX Spectrum coders have managed to cycle count when the vblank happens and then do things like alter screen data and create raster effects. Which means the prop would have to be able to do that as well.
I hope this isn't a tall order for the propeller to have that kind of access.
If you are intending a peripheral device, that does sounds feasible provided the data rate is not too high, for the reason Bean stated. If you it is a perhipheral device and you wish to code on your Z80 to get a status from the propeller before actual data, that could be done by whilst waiting for access to any hub data. You may need to signal to a second Cog, by connecting two pins together, one out one in, so that the second cog can output a 'waiting for data' status to the Z80 whilst the first Cog accesses hub ram.
I guess the correct answer would be that I was planning on using the prop as general memory for an 8k area of the normal 64K SRAM.
For example, any time the Z80 is NOT within my memory range, it would be executing instructions off the external SRAM IC. But, when it's in my range, I want to take the data written by the Z80 and stuff it in a global (BYTE Screen[8192]) variable that another COG is using to render data to the TV.
When reading from that range, the propeller would then load the data bus with the contents of the Screen variable.
Then Bean's comment stands.
However, if you treated the propeller as a byte orientated peripheral, it may well word if you can provide a status back to the Z80 to inform it of being busy.
Do your normal address / i/o decode as on Z80. The Propeller responds to two addresses. One is the byte interface, the second can decode to abyte interface or a single pin for busy status.
Are you address decoding in external TTL / CPLD? Or where you thinging of monitoring the address lines directly? external decoding would be best.
1) Propeller does a waitpeq for Z80 address lines of A15,A14,A13 = 010. This puts me in the $4000 - $5FFF range.
2) I then would translate the remaining 13 pins into an arbitrary 8k position.
3) If reading, then take the variable and dump to data bus
4) If writing, take data bus and put into variable.
I realize this is a lot of pins. 16 for the address and 8 for the data. So that's 24 not counting the control lines.
I was hoping to use a parallel to serial shift register for maybe the data bus. But I'm concerned with the propagation delay on this.
As you can see, I'm in the day-dreaming phase now. But my video driver is working pretty well and I get a few Z80's this Thursday. :-)
How about the 4 pins currently for 8KB block decode. Plus 2 pins for lower memory decode, would just decode A1 and A0, so your perhipheral will appear multiple times in your 8KB window.
A1, A0 == %00 = Data to/from screen
A1, A0 == %01 = Toggle Data / Command mode - where you can take additional commands for clear screen, cursor position, select colour etc.
A1, A0 == %10 = Ouput to Z80 as a Busy flag. Wait until it's 0 then send to Propeller
A1,A0 == %11 = Reset Propeller? May be useful while testing code? Wait a good time for it to reload from I2C
Now, does the Z80 have a WAIT signal which could be driven by the Propeller, effectively replace A1,A0 == %10 above? And if so, is there maximum number of cycles the wait may held?
Well, what I'm trying to do is emulate a ZX Spectrum. It had a custom chip called the ULA that "cheated" and simply stopped the clock for the Z80 when rendering video. It didn't actually use the WAIT that I know of. The ULA was the 3.5MHz clock source for the Z80 so by stopping the clock, the Z80 never knew what was happening.
Also, I may have incorrectly explained this originally too.
So let me back up and see if I can paint a better picture.
I'm going from memory so I hope I'm not messing this up. But the ZX Spectrum was essentially just three chips (plus some glue). The Z80, RAM and the ULA. (technically it was DRAM in 8 or 16 chips but for the sake of simplicity, we'll say one RAM).
Now, the ULA did several things for the ZX Spectrum. It provided the video display, handled the 1bit DAC for audio, handled the keyboard and provided a clock source for the Z80 CPU.
During normal operations, the Z80 was in control. It reads/writes to anywhere in RAM (except the lower ROM area). The video memory area was hard-coded and could not be changed.
This area started at $4000 and ran all the way to $5AFF. Which is a 6,144 bytes. Immediately following was 768 bytes of "color data". So that's 6,912 bytes of data for video total.
Now, since the ULA was also providing video, once the video beam reached the first lines to draw, it would halt the CPU (not using HALT but literally stopping the clock) and then stream the RAM contents starting at $4000 all the way to $5AFF. Which would be one full screen. During that time, the CPU was totally unaware this was happening.
Which means that the entire computer slows down when the screen is being painted. LOL. (got to love it).
Unfortunately for the ZX Spectrum, the ULA didn't just grab the 6,912 bytes it needed, it actually grabbed the entire 16K starting at $4000. This was referred to as "contended RAM".
What I was hoping to do with my design was to only stop the CPU while it was in the first 8K of memory starting at $4000 instead of the full 16K.
But there are some unknowns for me. First, the games that ran on the ZX Spectrum depended on that weird architecture so to NOT contend the full 16K might actually affect timing.
Also, IIRC, the ULA would let go of the CPU after during each horizontal blanking period. Giving it a little more power while it wasn't physically painting pixels. In fact, I think it even let go during the border colors.
So that is my challenge. And I hope you enjoyed your Sinclair ZX Spectrum history lesson!!! :-D
Wow, thank you for that.
How about using an SRAM chip, decoded for for the entire 8K memory range. WIth your propeller, try and emulate the ULA. So stop the clock on the Z80 and grab the data from the SRAM into the Prop for the screen. It may be slower than the ULA so you may have to do it in smaller blocks to not affect the Z80 too much. Did the ULA provide a timer service too? Or was there a 50/60/100/120Hz interrupt from the PSU at x-over.
This may work, but the screen update may be too slow, depending on how much ram you can grab externally. However, you could perhaps use a number of cogs working in unison, which once synced drive the SRAM hard and updating the video buffer in hub ram between them at the same time. 4 is a good binary number, leaving you some cogs for driving the screen.
How does that sound?
It may not work, but worth an experiment?
Those efforts are bound to give clues as to what is possible.
Do you want to run ZX binaries unchanged ?
In that case, you will need to clone the ULA operation.
If you do not mind changing code at both sides, life may get a little bit easier (well, more under your control, at least).
The Prop can generate a gated clock without much effort, and could also generate H,V
It can wait on a Z80 signal to 12.5ns granularity, with a setup time of 75ns, and then it will phase lock and execute opcodes at 50ns on any COG.
ie the COGs can operate at any phase of the 12,5ns SysCLK, but each one needs 4 clks/opcode
Actually, I thought about doing that. I do plan on using an SRAM chip as the propeller just doesn't have enough RAM. I wondered how bad it would be to stop the Z80, then read the SRAM directly into the COG. I will certainly experiment with both scenarios.
@jmg
My plan would be to run the binaries unaltered. So yeah, cloning the ULA might be improbably with the propeller. However, a VAST majority of the ULA logic was devoted to rendering the video. And I already have that in one COG. So the rest would be to decode the simple address logic for the keyboard and a few other things.
**EDIT**
One thing I just thought of, the new Sinclair Vega is an emulated ZX Spectrum in software. Even the Z80. This runs on (I'm assuming beefy) ARM microcontroller. Apparently, it's supposed to be pretty accurate too. So this one chip (plus some external RAM) is emulating the 3.5MHz and ULA. So I know this isn't a fair comparison with Propeller, but seems to at least prove it can be done in software. Of course, it would help to know how fast that ARM is...lol.
Throw enough megahertz at something and you can almost emulate anything. :-)
@both of you.
How about the GameDuino?, a small Xilinx FPGA board to emulate the ULA and drive the graphics?
@cbmeeks
Do you know verilog or programmable logic, and/or willing to try and learn? It's a while new world.
-Phil
Well, I don't know how I feel about FPGA. First, I really wanted this to be a hobby project that beginners (like me) could assemble on a breadboard.
FPGA is hard.
Plus, I wanted this to be as "retro" as possible. My initial goal was to only use newer components where functionality couldn't be purchased new today. For example, you can't buy new ULA or TMS9918 chips these days. You can't buy new AY-3-8910's, etc. You might be able to find old, new stock but they aren't made.
So researching NTSC video generators (without FPGA) brought me to Parallax a few years ago.
However, I do have a Mojo v3 board that I never could get to work. After I installed the 28+ GIGS of IDE, it wouldn't work. So I gave up.
I'm not opposed to learning it, though.
@PhiPhi
Would stopping the clock for the Z80 also not do the same thing? I think the /WAIT is the "official, preferred" way to do it but the ULA just stopped time.
So, I guess in theory, once I stopped the clock I have all the time in the world. But I'm worried about is stopping it for too long and causing the games to run at snail's pace.
The Prop can generate a clock in NCO mode, so you may be able to stop, and also nudge up and down the 4MHz - if you have Video under your control, changes in Z80 clock will not be visible.
Pivotal numbers would be how many bytes per line the Z80 can burst-shift, and how random the access is, and how packed any read-modify-writes are.
Yup, but possible. There is a Spectrum ULA on opencores.org if you venture there. That plus the GameDuino may do it, that also provides audio.
I understand that requirement. It was an mcu that could drive VGA which brought me here.
Yes they are greedy on disc space.
Unfortunately, I don't know those numbers yet. I would say the access is totally random. Imagine brilliant game programmers in the 80's pushing the Z80 and ZX Spectrum beyond what it was supposed to do. So I would have to believe the access would have to be any position, any time.
And yes, the video will totally be rendered/controlled by the propeller. The Z80 only sends pixels to a hard-coded memory address. It's not like the TMS where you pass in commands. I'm really going to give the full SRAM some thought. Surely there are propeller video drivers out there that run from external RAM? Might be possible if I had really fast SRAM too. Like 12.5 or 15ns.
In fact, one scanline would only be 32 bytes. If I could grab that during/before the hsync then that might work. hmmm
@78rpm
Concerning FPGA, I will go that route if I must. I know I can emulate an entire ZX Spectrum with FPGA but if I'm going to do that, why not just run an emulator on my Mac? I want hardware that I can build and plug into my CRT TV.
I want raw Z80 power. :-D
http://forums.parallax.com/discussion/150407/video-graphics-controller-using-propeller-to-control-sdram
Awesome. Thanks for the link!
Obviously you would have to build a suitable video circuit for the data you have, hopefully the basic principle will be sufficient to get you a good way there. Fast access SRAM.
Awesome! Best answer I've heard all day. lol
I get my new Z80's in Thursday. I'm headed to Detroit this weekend, however. So I might not have time to play with them before I go. But if I do, I will keep everyone posted.
The naive, excited engineer in me says that I'm so close to building this thing...the realistic, senior programmer in me says I have a lot to learn. lol
I'd really be more interested in propeller stuff for the ZX81 (Timex Sinclair 1000) really, but I'm game for either system.
Bean
I would be beyond grateful for any help you could provide! I will send you a PM soon to touch base.
That Timex Sinclair 2068 is a lovely machine (I'm a buyer any time you want to part ways...hehehe).
It's actually a "better" ZX Spectrum. However, the problem with it (from a commercial view) was that it was too incompatible with the Speccy that most of the games wouldn't work. Too bad really.
I also own a ZX81 (and a TS1000). Those are even less complicated than the Speccy.
So I have a cog that is for the ULA TV driver. Wouldn't be hard to modify to support the B/W mode of the ZX81.
To add the TS2068 extended mode would be awesome. It's the same thing but higher vertical color resolution.
Each 8x1 char can be two colors instead of 8x8. That shouldn't be too hard either. Just a little more memory.
The 512x192 monochrome mode might be tough but doable.
Finally, the TS2068 implemented the AY sound chip. I was planning on using the AY cog as a "feature" to my clone. The tricky part about the TS2068, though, is that the mappings were different. So maybe the clone could choose which mappings from flash or something.
Anyway, a mega ZX Spectrum machine makes me drool. :-D
I just need to get to the bench and get those Z80's going and boot some ROM. Then iterate to make it better.
Exciting stuff!
Right now I'm looking at using the Propeller as a I/O device. Using the IOREQ, RD , WR, Data, and A0-A7 I can detect the I/O request, I/O port (A0-A7) and value (D0-D8). I was thinking of using the WAIT to slow things down but on the ZX81 the WAIT is used to synchronize the video signal so it'll mess with video generation. For what I'm planning the WAIT may not be needed.
Ironically I am using a FPGA running ZX-GATE a softcore ZX81 and Spectrum so I can easily interface the 3.25V signals to the Propeller. I do plan on interfacing to the real ZX81 and use current limiting resistors on the Z80 signals.
The first thing I want to interface is the AY-Cog to make a simulated ZONX sound board.
Sounds like we are building similar devices. I don't know as much about the ZX81. My first hurdle is to get a better understanding of the Z80 CPU and how to control it with the prop. Once I do that, I feel the rest will start coming along nicely.
:-)
BTW, I'd be interested in your project as well. Perhaps we could collaborate if needed.
Thanks!
What you are doing is going to be a fun and challenging project.
In a similar project I did with the Z80 and Propeller last year, I managed to get a 4kB block of Z80 memory (for video/text) captured by the Prop at 3.375MHz and emulate a 6545 CRTC video controller as well. Additionally, I was able to create several I/O peripheral ports by decoding IORQ and didn't use any WAIT states at this clock speed to get data back from the hub in time. None of this required actually stopping the Z80 clock, it all ran continuously and transparently which was nice. You may however require using WAIT states if your PASM is too slow for handling the Z80 bus at 4MHz and you will need to be very careful when driving the data bus to avoid clashes during your reads and look at the timing diagrams carefully. I know the timing was rather tight even at 3.375MHz and I wanted any back to back combinations of memory and I/O reads/writes to all work without problems. I put in a couple of 74LVC244 buffers on the data bus between z80 and Propeller to allow tri-stateable bidirectional data transfers and voltage translation too because I was mating a 5V Z80 to the 3.3V Prop, doing this also relaxed the timing a little on reads as it gave the propeller a bit more time to switch off its output before the next Z80 write would drive the bus and potentially clash with it. You might wan't to consider doing something similar especially at 4MHz.
Ultimately in all this work, I found the Propeller pin limitations the trickiest to deal with because I had to simultaneously output mono VGA and composite video as well as have 4 SPI pins for SD card accesses and PS/2 for keyboard and there weren't quite enough pins (and probably COGs) for it all unless I sacrificed something. So to workaround the issue I just added a small AVR micro for the keyboard decoding which worked fine in the end and I now have my old Z80 CP/M machine running again and brought out of the last century.
Good luck.
rogloh