Z80 Driven Propeller Update
Vega256
Posts: 197
Hey guys,
Here is where I stand with my Z80/Propeller circuit.
So far, I have gotten the Z80 and the Prop to cooperate with one another via the Z80's /BUSREQ line, which, in simplest terms, suspends the Z80 after it has completed the instruction that it was executing when it received the request. When the Z80 is ready to release the bus for external control, it asserts its /BUSACK signal. With both /BUSREQ and /BUSACK connected to the Propeller, I am able to have the Z80 and the Propeller work independently and cooperatively.
As of currently, the sole purpose of the Propeller being included in my system is to supply a television with a composite signal representing the contents of the VRAM. Here is how the Propeller does its task.
When power is applied to the circuit, the Z80 and the Propeller begin operation.
The Z80 stores color information in VRAM which is connected in the system. Whilst it is doing this, the Propeller waits for approximately 16,000 microseconds before requesting bus access of the Z80. When the time comes for the Propeller to read what is in VRAM, it requests access of the bus and waits for the Z80 to acknowledge its request.
Upon acknowledgement of the request, the Prop asserts the first address ($0) of VRAM on the bus and pulls its /RD signal low so that VRAM will return the data at that location. The Propeller accepts the returned data and stores it in a variable. VRAM can only return one byte at once but the color data that the Propeller uses is in long format. Because of this incompatibility, the Propeller stores the returned bytes in a long one byte at a time. Therefore, the Propeller must repeat the memory read cycle 4 times total.
When the Propeller has read in 4 bytes of data from VRAM, it fills up the area of memory which is read by the TV driver with the color data it retrieved from VRAM, using longfill (). After this, the cycle repeats. That is, the Propeller gives bus access back to the Z80 and it alters the contents of VRAM again etcetera.
With this hardware and software configuration, I had been able to successfully display solid colors to the display.
Next, I tried to exercise the Propeller a bit more by having it read data from more than the first 4 locations in VRAM. This way, I could display more than one color on the television at one time.
I reserved an array of 32 bytes in Propeller memory that serves as a buffer that will be assigned the values of VRAM and then copied to the screen pointer. Since, in smaller terms, one pixel is represented by one byte, 32 bytes would represent 32 colors, respectively.
Instead of the read cycle repeating 4 times, it now repeats 32 times to retrieve the information. When the time comes to draw to the screen, bytemove () is used to copy the contents of the buffer from the address of the buffer to the address of screen memory. I used all white in this run.
As of currently, there is an issue with the software implementation above.
When I run the program, what I get is a very short and distorted bar at the top of the screen. Half of it is white and the other half is various other colors. I understand that 8 longs won't be enough to make an entire line, but still the line should be longer than it is. suspect a timing issue.
If any of you have any advice, questions, comments, or solutions regarding this issues, do not hesitate to post.
Here is where I stand with my Z80/Propeller circuit.
So far, I have gotten the Z80 and the Prop to cooperate with one another via the Z80's /BUSREQ line, which, in simplest terms, suspends the Z80 after it has completed the instruction that it was executing when it received the request. When the Z80 is ready to release the bus for external control, it asserts its /BUSACK signal. With both /BUSREQ and /BUSACK connected to the Propeller, I am able to have the Z80 and the Propeller work independently and cooperatively.
As of currently, the sole purpose of the Propeller being included in my system is to supply a television with a composite signal representing the contents of the VRAM. Here is how the Propeller does its task.
When power is applied to the circuit, the Z80 and the Propeller begin operation.
The Z80 stores color information in VRAM which is connected in the system. Whilst it is doing this, the Propeller waits for approximately 16,000 microseconds before requesting bus access of the Z80. When the time comes for the Propeller to read what is in VRAM, it requests access of the bus and waits for the Z80 to acknowledge its request.
Upon acknowledgement of the request, the Prop asserts the first address ($0) of VRAM on the bus and pulls its /RD signal low so that VRAM will return the data at that location. The Propeller accepts the returned data and stores it in a variable. VRAM can only return one byte at once but the color data that the Propeller uses is in long format. Because of this incompatibility, the Propeller stores the returned bytes in a long one byte at a time. Therefore, the Propeller must repeat the memory read cycle 4 times total.
When the Propeller has read in 4 bytes of data from VRAM, it fills up the area of memory which is read by the TV driver with the color data it retrieved from VRAM, using longfill (). After this, the cycle repeats. That is, the Propeller gives bus access back to the Z80 and it alters the contents of VRAM again etcetera.
With this hardware and software configuration, I had been able to successfully display solid colors to the display.
Next, I tried to exercise the Propeller a bit more by having it read data from more than the first 4 locations in VRAM. This way, I could display more than one color on the television at one time.
I reserved an array of 32 bytes in Propeller memory that serves as a buffer that will be assigned the values of VRAM and then copied to the screen pointer. Since, in smaller terms, one pixel is represented by one byte, 32 bytes would represent 32 colors, respectively.
Instead of the read cycle repeating 4 times, it now repeats 32 times to retrieve the information. When the time comes to draw to the screen, bytemove () is used to copy the contents of the buffer from the address of the buffer to the address of screen memory. I used all white in this run.
As of currently, there is an issue with the software implementation above.
When I run the program, what I get is a very short and distorted bar at the top of the screen. Half of it is white and the other half is various other colors. I understand that 8 longs won't be enough to make an entire line, but still the line should be longer than it is. suspect a timing issue.
If any of you have any advice, questions, comments, or solutions regarding this issues, do not hesitate to post.
Comments
Without seeing that, the only recommendation I can make is to compartmentalize the video system on the Prop, ignore the Z80, and run your test cases to insure that it will in fact display what you expect, given the buffer contents you define. When that works, then stuff the buffer from the Z80, and take a look see.
If the CMOS Z80 will suffer running at 4 MHz @ 3.3 V (from 10 MHz @ 5V) then it could be worth the experiment. The DracBlade (@80 MHz) seems to do about "a 2MHz Z80", but with the full 64KB, of course.
That is a clever idea, Ale. I didn't think to put the Prop directly on the bus. If it is done this way, though, whose responsibility is it to know when the TV requires an update? Maybe the Propeller can signal a non-maskable interrupt to the Z80 every frame?
@ Mike Green, potatohead
Sorry guys for the absence of a schematic. I haven't actually written up one yet. I am without a scanner to upload any content to my computer and most schematic software I have tried to get requires hard-to-find footprints and components, so, if you guys will be patient, I can try to draw one with Paint.
@ davidsaunders,
I am not sure what GSX is.
Hook a Z80 up to 4 Propellers.
Use 16K of RAM from each one as Z80 RAM making up 64K.
Hopefully there is enough RAM left in one of them to leave space for a VT100 terminal display.
The rest provide a huge array of peripherals, parallel IO, Serial IO, SD card etc etc for the Z80. Not to mention the boot loader.
I think that should be the propeller, because it's the one actually connected to the TV. I am confused about your video path. Seems to me, the easiest path would be to simply free the Z80 of having to respond to the frame at all. Instead, have the prop poll the video memory to get pixel data, and display it, with said polling happening just as often as needed to get the display data. The Z80, in a simple design, would be halted for a cycle, while the prop gets it's data from the busses, then is allowed to continue at all other times.
You end up with a somewhat slow Z80, during active screen drawing, and a faster one during blanking periods.
From the Z80's point of view, there is just a block of RAM that is video memory, and perhaps some address that it can look at to determine where the screen drawing really is.
Though you might like it. No one says it had to be sensible. As it's 2011 and people are still wanting to run Z80's, CP/M etc the I assume "sensible" is not part of the requirement.
But really, 4 Props instead of an EPROM, a bunch of RAMS, an 8255 PIO chip a UART etc etc. Seems OK to me.
Thank you for this kick in the posterior. This has me playing with different ways to interface the Propeller to the 68000/680x0 CPUs.
I love this forum for exactly this reason
Vega256: See the examples in my sig for a more complicated way to do exactly what we propose. The prop has to refresh the TV every 50 or 60 times a second so just write to video memory and consider it "displayed"
Have fun
Interesting approach and a neat idea! You are welcome to use anything from the N8VEM PropIO board. It is all published on the N8VEM wiki and may be helpful to you. Dave (Yoda) is here and he designed most of it and wrote the software for interfacing a Propeller to a Z80 via the ECB bus. However its approach is quite different from yours in that the Propeller appears as an IO device. I suppose the Propeller could emulate the whole Z80 bus and perform everything from reset to memory to IO if enough pins were used.
During the recent N8 development (Z8S180 based all-in-one computer formerly known as the N8VEM home computer) we briefly considered using the Propeller for video and audio support. It could easily provide the PS/2 keyboard, mouse, and SD support as well. The main obstacle to using the Propeller was it completely broke the MSX compatibility which requires AY-3-8910 and TMS9918A chips for sound and video respectively. As I recall there has been some work on AY-3-8910 emulation but no TMS9918A emulation on the Propeller AFAIK.
I can picture a Z80 computer design using one Propeller doing fulltime audio and video emulation and another doing the reset handling, boot ROM, and then reverting to general purpose IO like keyboard, mouse, SD, etc. I think Dave was considering such a creature at one point although I don't know what happened to it. Hopefully he will chime in on this thread.
Good luck! Thanks and have a nice day!
Andrew Lynch
@ lynchaj,
Thank you. I will definitely keep your resources in mind.
And use some waitpne to detect the fall of the propWR/propRD signals, get the address and data and write it to HUB memory:
WR_loop waitpne propWR, propWR mov data, INA mov addr, INA shr addr, #8 wrbyte addr, data' ' we assume that now the propWR signal went HIGH !!!!! jmp #WR_loopEver since Pullmoll went and put an entire Z80 emulation on a propeller chip I've kind of been hooked on the prop. But there were a couple of drawbacks i) an emulation speed of only around 2Mhz, and ii) no stable MP/M or banked memory solution.
I have a schematic designed for a Z80/Prop hybrid but I have never had it made because I think there are better solutions. And this thread already has me thinking about those.
The first thing is the things the prop can do. It can do keyboard, sd card, mouse and video. But if you want graphics you need to devote a reasonable amount of ram to graphics and 19200 bytes is the figure I am using because it does both text and also 64 color to 160x120. Kye's SD card driver needs about half the hub ram and put this all together and 19200 bytes of video ram plus keyboard/mouse/sd card/Z80 access code and I don't think it all fits in a standard propeller.
No matter though, because it easily fits in a propeller with a static ram chip, and you can write in Spin or Pasm or C. And the static ram chip is the same as the one used by the N8VEM.
So - what about the Z80 side. I have a board with a design where the propeller takes over the Z80's ram chip to write some boot data but it does use a fair few glue chips. In some ways I'm tempted to go back to a Z80 plus eprom! Make the Z80 side absolutely minimal - 8255, eprom, Z80 and a 512k ram chip. A byte wide comms channel to the propeller plus control pins and the prop controls the bank switching (high 3 bits) and maybe the prop even does things like create the Z80 clock?
And maybe maybe it is possible to squeeze 19200 video ram into the prop and an sd driver, and then save on a ram chip for the prop?
Hi!
The N8 is going to "beta test" at the end of June. I will send a PCB out for the team to build and test. The N8 design is a Z8S180 CPU plus five main "capital" chips: TMS9918A, AY-3-8910, WD37C65 FDC, and two 8255 PPIs. The rest is basically memory, glue logic, latches, buffers, transceivers, connectors, and miscellaneous components. The TMS9918A for video, the AY-3-8910 for audio, and the first 8255 is for IDE or parallel expansion, and the second 8255 is for parallel printer port, PS/2 keyboard, and PS/2 mouse.
I am mulling over some ideas for the next version of N8. It will either be based on the V9938/V9958 VDP instead of the TMS9918A or possibly a Propeller emulating both a TMS9918A and AY-3-8910 if such a thing exists at the time. The Propeller concept is appealing since it could perform the NTSC to VGA conversion easily but the drawback is that it does not exist
My suggestion for Vega256 is to emulate the Propeller as a TMS9918A VDP. The Propeller code from the PropIO could be readily adapted and the TMS9918A is a well documented and understood chip. It would simplify the Z80 to Propeller interface quite a bit. Also it would be useful as a general purpose emulation like PullMoll's AY-3-8910 emulation.
Thanks and have a nice day!
Andrew Lynch
It's very accurate and even "timer interrupt driven envelope tricks" (like "sync buzzer") works just like the real thing.
TMS9918A emulation is on the way to the prop as well, have a look at: http://forums.parallax.com/showthread.php?131793-C3-platform-emulation-fan-site
/Ahle2
1. EEPROM :-
A prop on the Z80 bus can simulate whatever size eeprom you require (well really 32KB max). It just loads hub from it's 24C512 eeprom. If you do not require all the 32KB (most likely you don't) then some of the prop is left for other things like maybe the AY-3-8910 audio.
2. VIDEO :-
A prop on the bus can present a window in SRAM for the video memory and can simulate the TMS9918A (No doubt it can be done). The remainder of the prop is available to perform the function of other I/O components (IDE/Parallel, Parallel Printer (can you still buy them???), PS2 keyboard and PS2 mouse.
The above 2 props would also be able to simulate hard drives using an SD/microSD card (we have done it in ZiCog). And of course the prop can do most of the glue logic, including bank switching, if required.
Sounds like Z8S180 CPU + 512KB SRAM + 2 x Props (replacing TMS9918A, AY-3-8910, WDC37C65 FDC, 2 x 8255 PPIs, EEPROM, and some glue logic)
Of course, I would go one step further and replace the Z8S180 CPU with a prop and be done with it (there is still a bit of tuning to be done to get more speed than a ~5MHz Z80)
Hi, I am not seeing the TMS9918A emulation in the referenced thread. Am I missing something?
Thanks
Andrew Lynch
Hi
http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder¶m=N8%20(previously%20Home%20Computer)
we also discuss on the N8VEM mailing list
http://groups.google.com/group/n8vem
Thanks and have a nice day!
Andrew Lynch
digimorf is currently developing an emulation of the Sega SC-3000 computer and it uses the TMS9918A as its video processor.
I don't think he has begun coding on the TMS9918A part yet, but at least it's in the pipe.
/Ahle2
Hi,
I think the Propeller could probably emulate a boot EPROM easily enough and probably handle Z80 reset, PS/2 keyboard, mouse, VGA display, SD without issue.
I think the TMS9918A and AY-3-8910 emulation might be possible on a single Propeller but we'd have to see. The TMS9918A is a fairly complex chip.
The WD37C65 though is a sophisticated, integrated floppy controller. I don't think I've seen a Propeller emulate an FDC especially one with built in data separator which can handle 1Mbps data streams. WD37C65 is not like the much simpler NEC765 or i8272 it is more like the SMC9266 integrated FDC or i82072. If a Propeller can do it, it would require most if not all of the cogs IMO.
Also the Z8S180 is an integrated CPU with DMA, dual serial ports, timers, etc. It is much more sophisticated than the Z80 itself or Z80 emulations on Propeller and runs at up to 33 MHz so I think keeping with the real hardware has advantages over emulation.
Thanks!
Andrew Lynch