I think you are trying to take emulation to an extreme. You don't have to emulate the backend of the FDC controller - all you need to do is present a set of registers that make the front side program happy. I would use the uSD as the backend which can be done in 2 cogs. The register emulation would be very straight forward. If the TM9918A is a text only chip (I have not looked at the specs of it yet) then the same could be done there - if only text mode then it would be simple to make the current propIO look like the 9918A on the front end I believe. I am still thinking a z8S180, ram chip, 2 props and some glue chips could make a nice system (even supporting DMA) - still mulling the design over in my head. We should talk some time about it - I would like to try to prototype it this summer. I would like it to be a 3.3 V design - makes interfacing simpler.
You might consider changing the pin assignments. Data bus on Propeller pins P0..7 will save a few instructions for transfers to/from HUB memory. Having data bus on other pins can make you lose 200ns per byte (2.5MB/s -vs- 5MB/s for example). Individual control signals or video groups can be anywhere.
You might consider changing the pin assignments. Data bus on Propeller pins P0..7 will save a few instructions for transfers to/from HUB memory. Having data bus on other pins can make you lose 200ns per byte (2.5MB/s -vs- 5MB/s for example). Individual control signals or video groups can be anywhere.
I take it that the reason for this significant loss is due to the architecture of the Propeller?
Unless you use a 3.3V Z80 and memories I'd recommend you put some 1k series resistors between the the address/data/control signals and the propeller pins.
Unless you use a 3.3V Z80 and memories I'd recommend you put some 1k series resistors between the the address/data/control signals and the propeller pins.
Do you know 3.3V variants of the Z80?
Except for the SMDish EZ80s?
Where is the clock circuit? Considering how slow the Z80 bus transactions may be, the Propeller could most likely keep up without special attention to pin usage.
@Ale, don't you think a 1K series resistor is a bit too high? How did you arrive at that value?
Where is the clock circuit? Considering how slow the Z80 bus transactions may be, the Propeller could most likely keep up without special attention to pin usage.
@Ale, don't you think a 1K series resistor is a bit too high? How did you arrive at that value?
I have not drawn a clock circuit yet, however, the Z80 is clocked at around 6 MHz (5.88 MHz ideally).
You will require series resistors with the leds and the leds need to be reversed. You do not require a pullup on the prop reset pin unless you have a long line that could have noise.
You should have a 4pin "propplug" style header to program the prop's eeprom - I presume you intend including the eeprom?
As jazzed said, the data pins are best on P0-7.
You define a 32KB SRAM & 32KB ROM. Is this correct? Why not just use 1x 128KB SRAM and let the prop load the ROM section at power up? (Surely the rom is only small?)
You define a 32KB SRAM & 32KB ROM. Is this correct? Why not just use 1x 128KB SRAM and let the prop load the ROM section at power up? (Surely the rom is only small?)
That is quite an interesting suggestion from Cluso99. If you put pullups (?10k) on A8-A15, and just talk to the ram using A0-A7, it should be possible to poke a 256 byte program into ram. This should be more than enough to get a little comms program working that then enables a more formal comms protocol to fill up the ram from the propeller.
It also would then save on the rom/ram select logic. You should be able to save two or three chips there. The 'catch' is the prop needs to take over /WR and /MREQ in order to program the ram. And BUSRQ to tell the Z80 to go to sleep while you load up the bootstrap program.
You do save on the need for an eprom programmer and an eprom eraser.
Also, re interface between 3V and 5V, there have been many discussions about this. I think 1k was the standard for a while, but I think the consensus of the most recent discussion, based on the specs of internal diodes in the propeller, is that 3.3k is a better value.
You will require series resistors with the leds and the leds need to be reversed. You do not require a pullup on the prop reset pin unless you have a long line that could have noise.
You should have a 4pin "propplug" style header to program the prop's eeprom - I presume you intend including the eeprom?
As jazzed said, the data pins are best on P0-7.
You define a 32KB SRAM & 32KB ROM. Is this correct? Why not just use 1x 128KB SRAM and let the prop load the ROM section at power up? (Surely the rom is only small?)
Yes, there were a lot of things excluded from my schematic, some of which are the clock circuit and the Propeller's EEPROM. You see, the original idea was to have the actual program and sprites stored in 32K of ROM, 16K of work RAM so that the Z80 would have some scratchpad space, and 16K of video buffer (possibly mapped as Propeller RAM) for the Propeller to read from and render to the screen. The important thing to note in my design is that the Propeller will do the same thing always and without fail; and this is to generate the graphics from the video buffer. That said, the Propeller's code should be constant.
As mentioned above, I am not sure where to put the 16K of VRAM just yet, however, I am leaning towards mapping it to the Propeller because the Z80 could directly manipulate the contents of Prop RAM whilst the Prop itself is generating video from that.
That is quite an interesting suggestion from Cluso99. If you put pullups (?10k) on A8-A15, and just talk to the ram using A0-A7, it should be possible to poke a 256 byte program into ram. This should be more than enough to get a little comms program working that then enables a more formal comms protocol to fill up the ram from the propeller.
It also would then save on the rom/ram select logic. You should be able to save two or three chips there. The 'catch' is the prop needs to take over /WR and /MREQ in order to program the ram. And BUSRQ to tell the Z80 to go to sleep while you load up the bootstrap program.
You do save on the need for an eprom programmer and an eprom eraser.
Also, re interface between 3V and 5V, there have been many discussions about this. I think 1k was the standard for a while, but I think the consensus of the most recent discussion, based on the specs of internal diodes in the propeller, is that 3.3k is a better value.
I am working on the voltage incompatibility. I will try to lay down some resistors but this entire prototype is on a breadboard and I am trying to conserve both order and space. Unfortunately however, these are becoming more of a dichotomy as I move forward.
I'd go with the suggestions. For testing I'd just use one propeller and the Z80 and use HUB RAM for program and data, then I'd expand it. Breadboard is best for testing
I must try and test just how high a clock rate that a 10MHz (@ 5V) Z80 will trundle along at when supplied with 3.3 V. Then it would be posible to see if 5 Volts and resistors is better/worse than 3.3 volts everywhere.
I have pushed the Prop up to 4.2 Volts before, partly to see if a LiPo cell could be suffered dirrectly and partly as a half way house between 3.3 V and 5 V.
Following on the footsteps of Vega256 I connected the only Z80 I have, a eZ80L92 (a 3.3V part) to the propeller. My idea was to use the propeller as ROM and RAM, just for tests. For consecutive accesses, to fetch opcodes from memory, the Chip Select logic does not toggle the CS line. I mean this example:
di
loop:
jp loop
This renders the flank detection method useless. The prop can still be used but I imagine that only for single byte interleaved accesses (so flank detection works).
The datasheet shows CS toggling but... well it does not in the conditions I used... I'll have to stuff a Flash and use the ZPak dongle to program it...
GSX is an extension for CP/M that provides vector Graphics functions see: http://www.cpm.z80.de/drilib.html
About half way down the pagew are some documents related to GSX.
I have some Z80 chips sitting in front of me, and I have a book on Z80 programming that has a circuit for a "minimum" Z80 design. EPROM, RAM, Z80 and some latches for I/O.
Can we do this with less?
Well, let's consider a self contained Z80 system running CP/M with 64k of ram (or bigger, because large ram chips now are cheaper anyway). That is all. The Z80 is happily running with its program, everything is fine. In reality, mostly what the Z80 is doing is polling for keyboard input, so instead of OUT and IN instructions, we replace the CP/M I/O command with instructions to read from a buffer that can be read and written with DMA. Ditto I/O commands to access the disk. Easy to customise CP/M to do that.
So the Z80 & ram are still happily running. It reads from a buffer - no input? read again etc. It writes a block to the disk - magically the block disappears and the Z80 carries on. Z80 plus ram chip, nothing else.
Now, what is going on with the Propeller side? We can use the Prop to generate a clock. We can also use two MCP23017 I/O expanders driven from the I2C bus (the eeprom) of the prop to generate 32 I/O lines. So the Prop can do things like pull the Z80 BUSRQ low, which then puts the Z80 into high impedance, as if it does not exist. Then take complete control of the Ram chip, reading to memory and writing to memory. We can fill the Ram with a CP/M image on startup. Put data into the Keyboard buffer. Read the Console Output buffer and put that data on a screen. Read blocks of data in and out of the Ram, and then to and from an SD card disk image.
Why bother?
Well, I've been frustrated that not one simulation I have built has been quite able to match a real chip for speed. I have a sneaking suspicion that maybe with caching the simulation can run faster, but there have been some very good arguments put by others saying it can't.
So why not use a real chip?
The challenge is in the interface and I think the key here is the MCP23017 chip. This has some rather unique properties compared to, say, discrete TTL chips, or the complexity of a CPLD. First - only $1.20 or so. Any pin can be an output, or an input (effectively HiZ). Plus, you can program it to make a pin pulled up with a weak resistor (about 100k). Perfect for the transition from Z80 to MCP23017 control where you want the ram /WR and /RD lines to stay high to prevent any spurious data writes. No pullups needed! And then there is something I think could be useful as well, and that is the ability to trigger an interrupt if a pin on the MCP23017 changes state. That could be useful for monitoring the /IO line on the Z80 (if it is possible to trap it fast enough) and then detect that the Z80 wants to read or write some data. The prop takes over the Z80 at that point, but otherwise lets it run on its own.
I need to do some more study on the MCP23017. I think there are drivers in the Obex. But I think it could be the key to a very cost effective Prop/Z80 hybrid.
On my Nascom I could never get it to run at 4MHz without the ocational crash, so it spent most of its life in 2MHz mode.
I often sit there pondering on getting on with the bolting on a Prop to a Z80. When Pullmoll sorted out my beloved Nascom simulation it took away that yearning. Only yesterday I was reading through the past threads on PropAltair(?) with a view to warp the code to a 8052. Then Basic52 could be embedded.
As Heater. says, "Where is the emulation of an abucus?"
I think that as long as I hold onto the likes of 8052, Z80s and 2KB SRAMs I will have those "issues".
Therapy comes in the shape of a dustbin. But the gits around here only collect them every two weeks and that gives far too much time for their reterval
@Dr_Acula you have been mentioning the MCP23017, would a MCP23S017 which uses a SPI interface be faster and better for this application? I too have quite a few Z80s lying around collecting dust. I've been toying with the idea of a Prop/Z80 combo to create a clone of my first computer, the ZX81 and this thread has a me thinking about it again.
This is a solution using 12 propeller pins to talk to a Z80. But having drawn this up, I think there might be a solution using an 8255 to replace all those TTL chips.
Comments
I think you are trying to take emulation to an extreme. You don't have to emulate the backend of the FDC controller - all you need to do is present a set of registers that make the front side program happy. I would use the uSD as the backend which can be done in 2 cogs. The register emulation would be very straight forward. If the TM9918A is a text only chip (I have not looked at the specs of it yet) then the same could be done there - if only text mode then it would be simple to make the current propIO look like the 9918A on the front end I believe. I am still thinking a z8S180, ram chip, 2 props and some glue chips could make a nice system (even supporting DMA) - still mulling the design over in my head. We should talk some time about it - I would like to try to prototype it this summer. I would like it to be a 3.3 V design - makes interfacing simpler.
Dave
The moment you miss the HUB window you lose 200ns (at 80MHz).
With "proper" planning, it is not an issue.
Except for the SMDish EZ80s?
@Ale, don't you think a 1K series resistor is a bit too high? How did you arrive at that value?
You should have a 4pin "propplug" style header to program the prop's eeprom - I presume you intend including the eeprom?
As jazzed said, the data pins are best on P0-7.
You define a 32KB SRAM & 32KB ROM. Is this correct? Why not just use 1x 128KB SRAM and let the prop load the ROM section at power up? (Surely the rom is only small?)
That is quite an interesting suggestion from Cluso99. If you put pullups (?10k) on A8-A15, and just talk to the ram using A0-A7, it should be possible to poke a 256 byte program into ram. This should be more than enough to get a little comms program working that then enables a more formal comms protocol to fill up the ram from the propeller.
It also would then save on the rom/ram select logic. You should be able to save two or three chips there. The 'catch' is the prop needs to take over /WR and /MREQ in order to program the ram. And BUSRQ to tell the Z80 to go to sleep while you load up the bootstrap program.
You do save on the need for an eprom programmer and an eprom eraser.
Also, re interface between 3V and 5V, there have been many discussions about this. I think 1k was the standard for a while, but I think the consensus of the most recent discussion, based on the specs of internal diodes in the propeller, is that 3.3k is a better value.
Yes, there were a lot of things excluded from my schematic, some of which are the clock circuit and the Propeller's EEPROM. You see, the original idea was to have the actual program and sprites stored in 32K of ROM, 16K of work RAM so that the Z80 would have some scratchpad space, and 16K of video buffer (possibly mapped as Propeller RAM) for the Propeller to read from and render to the screen. The important thing to note in my design is that the Propeller will do the same thing always and without fail; and this is to generate the graphics from the video buffer. That said, the Propeller's code should be constant.
As mentioned above, I am not sure where to put the 16K of VRAM just yet, however, I am leaning towards mapping it to the Propeller because the Z80 could directly manipulate the contents of Prop RAM whilst the Prop itself is generating video from that.
I am working on the voltage incompatibility. I will try to lay down some resistors but this entire prototype is on a breadboard and I am trying to conserve both order and space. Unfortunately however, these are becoming more of a dichotomy as I move forward.
I have pushed the Prop up to 4.2 Volts before, partly to see if a LiPo cell could be suffered dirrectly and partly as a half way house between 3.3 V and 5 V.
This renders the flank detection method useless. The prop can still be used but I imagine that only for single byte interleaved accesses (so flank detection works).
The datasheet shows CS toggling but... well it does not in the conditions I used... I'll have to stuff a Flash and use the ZPak dongle to program it...
About half way down the pagew are some documents related to GSX.
Can we do this with less?
Well, let's consider a self contained Z80 system running CP/M with 64k of ram (or bigger, because large ram chips now are cheaper anyway). That is all. The Z80 is happily running with its program, everything is fine. In reality, mostly what the Z80 is doing is polling for keyboard input, so instead of OUT and IN instructions, we replace the CP/M I/O command with instructions to read from a buffer that can be read and written with DMA. Ditto I/O commands to access the disk. Easy to customise CP/M to do that.
So the Z80 & ram are still happily running. It reads from a buffer - no input? read again etc. It writes a block to the disk - magically the block disappears and the Z80 carries on. Z80 plus ram chip, nothing else.
Now, what is going on with the Propeller side? We can use the Prop to generate a clock. We can also use two MCP23017 I/O expanders driven from the I2C bus (the eeprom) of the prop to generate 32 I/O lines. So the Prop can do things like pull the Z80 BUSRQ low, which then puts the Z80 into high impedance, as if it does not exist. Then take complete control of the Ram chip, reading to memory and writing to memory. We can fill the Ram with a CP/M image on startup. Put data into the Keyboard buffer. Read the Console Output buffer and put that data on a screen. Read blocks of data in and out of the Ram, and then to and from an SD card disk image.
Why bother?
Well, I've been frustrated that not one simulation I have built has been quite able to match a real chip for speed. I have a sneaking suspicion that maybe with caching the simulation can run faster, but there have been some very good arguments put by others saying it can't.
So why not use a real chip?
The challenge is in the interface and I think the key here is the MCP23017 chip. This has some rather unique properties compared to, say, discrete TTL chips, or the complexity of a CPLD. First - only $1.20 or so. Any pin can be an output, or an input (effectively HiZ). Plus, you can program it to make a pin pulled up with a weak resistor (about 100k). Perfect for the transition from Z80 to MCP23017 control where you want the ram /WR and /RD lines to stay high to prevent any spurious data writes. No pullups needed! And then there is something I think could be useful as well, and that is the ability to trigger an interrupt if a pin on the MCP23017 changes state. That could be useful for monitoring the /IO line on the Z80 (if it is possible to trap it fast enough) and then detect that the Z80 wants to read or write some data. The prop takes over the Z80 at that point, but otherwise lets it run on its own.
I need to do some more study on the MCP23017. I think there are drivers in the Obex. But I think it could be the key to a very cost effective Prop/Z80 hybrid.
I often sit there pondering on getting on with the bolting on a Prop to a Z80. When Pullmoll sorted out my beloved Nascom simulation it took away that yearning. Only yesterday I was reading through the past threads on PropAltair(?) with a view to warp the code to a 8052. Then Basic52 could be embedded.
As Heater. says, "Where is the emulation of an abucus?"
Did I say that? What on earth did I mean?
8052....You have a very troubled mind:)
As for the troubled mind, SO ?
Therapy comes in the shape of a dustbin. But the gits around here only collect them every two weeks and that gives far too much time for their reterval
(and there we are, back on thread)