Propeller as EEPROM emulator and Peripheral Chip for z80?
rwgast_logicdesign
Posts: 1,464
[FONT=arial, sans-serif]I have wanted to start building my own 8 bit computer for a long time. Ive decided I want to go the z80/propeller route. I plan on using the propeller to generate the z80s clock signal along with managing the keyboard/video etc. Old 8 bit computers expect a parallel eeprom which is kind of a pain in the butt. I was wondering if it would be possible to use the prop as an EEPROM emulator... i.e. the propeller could grab the z80s ROM file from either a serial connection or an i2c EEPROM then send it off to the z80s EEPROM pins via bit banging.. Is this even a practical idea, or would it be better to just get an EEPROM programmer?[/FONT]
Comments
Initial experiments using the 32 I/O pins of two MCP23017 chips on the I2C bus work fine. But then some boffins on that thread came up with a method of reducing the chip count. To zero extra chips!
Take a propeller and devote 8 pins to a data bus. Run the Z80 at 3.3V. Use just 4 more propeller pins and connect to the Z80 reset, Z80 clock, Z80 /wr and Z80 /rd line. Circuit is a Propeller, Z80 and ram chip. 12 propeller pins (and they can be reused for a comms bus once the Z80 is running).
Issue a reset to the Z80. Now start clocking the Z80 and listening to the /rd line. After about 3 clocks the Z80 will start up and the first thing it does is read a byte from memory location zero. /rd will go low and the propeller detects this. If you have a low value resistor eg 220R between the z80 and the propeller and connect the propeller to the ram pins, you can force lines on the memory chip to different states to the Z80. So the Z80 is trying to read data, but instead you force z80 /rd high, Z80 /wr low and put your own bootstrap byte into the ram. Then let /wr go high and /rd go low. Next, let the Z80 try to read again. But this time, on the data bus, make all the pins low. Now cycle the clock pin. The Z80 reads in a NOP and then proceeds to the next instruction. Do this for each address until you have a bootstrap program inside the Z80 (should be only 30-40 bytes). Now issue a reset and restart the Z80 and let it run normally. The bootstrap program can then talk using a more sophisticated comms protocol with the propeller.
Crazy stuff and not tested as yet but will be soon.
Use RAM!
When the computer starts, the Propeller holds the Z80 inactive, reads the 'ROM Image' from I2C/SPI/whatever, then uses a shift register and some counters to clock the data out to the RAM.
But there is the trick. If you control the bus you can let the Z80 provide a counter up through RAM addresses and write boot code in to RAM as it goes. That means you don't need any external counter chips or shift registers or waste Prop pins with address bits.
True, but...
A 'boot loader' code to be 'loaded' first is an unnecessary step.
My solution allows you to REWRITE the 'ROM' while the computer is still running...
In fact, if it's timed right, it can be done while the Z80 is busy with I/O commands(assuming that you split the bus somewhere) or by working in the 4th clock cycle when the Z80 is busy with internal work. (Assuming a bit faster RAM than was used in the 80s, or that you run the Z80 at a lower speed)
You would be able to load ANY CODE, at ANY TIME.
Much more flexible than paging...
Also, it's not that difficult to add ANOTHER shift register for 'run mode' where one output disables the counter and shift register used to load the ROM image, and instead enable something else on those Propeller IO pins...
Imagine that, a digital transformer...
Yeah, I'm a nutcase...
(Also, just watched an Iron Man marathon... Sensible ideas are very low on the list right now. OK, did a it of FF in the first and second movie... )
Using only RAM is a good idea, and that is what the 3 chip proposal is suggesting. There is no advantage to using shift registers or counters unless you want to build a computer that has a direct memory access I/O system. What would being able to rewrite the rom while the computer is running give you?
Dr_Acula's suggestion seems to be for a (dare I say elegantly simple) minimal chip count system that is also surprisingly flexible. There are enough pins left over for keyboard, mouse, SD, and possibly a text VGA display. Also, there is no reason the propeller has to load a bootstrap program. With the control it has over the Z80 there is no reason it could not load the entire ram with data from a file or files on the SD card. That could be the OS or another application.
What seems to have been overlooked so far though is that some pins will be needed to read at least part of the address bus for I/O instructions.
Good point. 4 control pins allows a bootstrap. Add another two pins and you can monitor /IORQ and also A0 so you can have two "ports" the Z80 can use to talk to the propeller. Port 00H could be data, and port 01H could be control. That should be enough for simple 8 bit data transfer.
This is one of the 'minimalist' circuits that might be worth a try. jpeg low res, and pdf higher resolution.
You can leave out the keyboard, audio, VGA, SD card initially and use one of the Obex serial objects to debug data back to the PC with the proptool terminal.
If you have an existing propeller board with regulator, eeprom, download circuit, this Z80 experiment only uses another two chips.
First person to build this and get a bootstrap program running wins fame and fortune on the propeller forum! Well, fame anyway
It has made me get WIN ME (yeah, yeah, yeah - I'm sorry (the '98se disk didn't work)) back onto a PC, for
http://www.qsl.net/iz7ath/web/02_brew/17_eprom/english/pag05_eng.htm
(If more pins are needed there is always the 4 pin option on the VGA and then the SD going onto the saved 4)
How quickly the pioneers are forgotten:)
I see no reason why the Z80 in a RAM plus Prop circuit should not run at full speed when it is let rip on the code "poked" into RAM by the Prop. Except of course when it bumps into those I/O operations that the Prop is handling.
If the Prop is having trouble asserting WAIT (or whatever) in response to CS (or whatever) in time to satidfy the Z80 then I would lobby for the inclusion of a flip-flop to help it.
You are in serious need of therapy. Perhaps Dr. A can help:)
I'd rather run M$ Office on a 386SX with 2MB RAM and Windows 3.0...
(Actually, I have done that... )
As for the I/O operations.
Checking only ONE address pin is a big waste. The Z80 has an 8bit address space for I/O after all.
If you don't want to 'waste' Propeller pins, add a couple of AND gates for the higher pins to minimize the 'waste' somewhat.
Yes, I know, the Propeller can handle a lot of IO on the system, but if the Propeller does it all, then why bother having the Z80 in there?
1) Console out.
3) Console in.
3) Disk I/O.
4) Printer.
5) An interrupt controller.
These can all be multiplexed through a single port, and perhaps a control/status port that talks to the Prop. So a couple of bits of the I/O address is all that is needed.
You don't need to AND any address pins together. Without that all that happens is that your ports(s) can actually be accessed at lot's of addresses through out the address space. Decoding all the addresses only means the port is available at one address. Hardly a requiement.
It's is better to let the Prop do as much I/O work as possible, that requires less Z80 code to be written and increases RAM space available for it's programs.
Why have the Z80 in there? The need for speed when running CP/M and such.
I tried '98SE first, looked ar ME, thought about '95 ... It's just to get easy access to the Parallel port ... remember those ???
The bullet option would be a valid pension plan, at the moment.
Not to make too big of a fuss about it, but is that the same circuit as the previous file named Propeller z80 minimalist?
Well, anyway, we seem to be discussing two different circuits - one that uses the whole address bus (and can force feed
instructions to Z80 RAM) and one that uses only A0 to implement two "virtual registers" in the Prop.
The first one (A0-A15) means that the Z80 software will have to be loaded into the EEPROM or SD card.
The second (A0 only) means the Z80 will have a ROM chip of its own.
Right?
While maybe not the absolute minimal chip count, I like this approach better as I think it would be more
likely to work (reliably too!), it provides more flexible I/O space, and maybe easier to debug too...
ZaP-1 anyone?
Re your circuit above, I see a ROM. ROMs are tricky because you then need a programmer. Sure they are cheap on ebay but it is another cost that may not be needed. Are you thinking of removing the ROM somehow?
I haven't had a board made with that minimalist circuit but would be very happy it it helped someone else. The reason is that I see propeller pins as being very precious, and pins used for bootstrapping are kind of wasted after booting. The really clever use of propeller pins is doing things fast, in pasm, and so I figure that because bootstrapping can be done slowly, it is better to add one more chip like a MCP23008 and use that for bootstrapping. Alternatively, a HC125 on the VGA pins. Or even a 74HC4066 on the VGA pins. There are quite a number of solutions if you are allowed just one more chip.
But I am intrigued by the idea of using the Z80's own counter to avoid having to talk to the address lines as that saves lots of chips/prop pins/board space.
Re the Zicog and qZ80 - the limiting thing there is speed. Equivalent to about a 2Mhz Z80 and hardly any Z80 computers ever ran that slow. There are ways to speed both those emulations up by using the cache drivers the GCC people are using, but no-one has done this.
For me, I picked up some 20Mhz Z80 chips on ebay recently, and I want to see Wordstar boot at that speed!
Re the debate about ports, the 'traditional' Z80 has 256 ports. It seems to me you can get the same sort of thing with just two ports - port zero is data, and port 1 is the port number. Slower because it is two OUT instructions instead of one, but on the other hand, a port call is going to usually take many more propeller clock cycles to process.
In some ways it may not matter so much what the hardware is. If one defines 256 ports - some as keyboard, some as display, some as serial port etc, and that exists in software on the Z80 and software on the propeller, then it should be fairly easy to recode that software for different hardware configurations. In fact, this is where I am at with my project. I have some boards being made that are going to take 3 weeks, so meanwhile I have some older hardware. But the software project can still be worked on, and in an ideal world, the software would work on lots of different hardware. I think that was the CP/M philosophy too. But I can't quite bring myself to issue an edict to everyone saying "you must use my port numbers!" I'd really like to brainstorm that. My general thoughts are to use port numbers up to about 30 and make them the same as CP/M 2.2. Above that number, maybe one could allocate a few reserved numbers - two for keyboard, a few for the serial port etc. I'd then like to go through the SD propeller code (FSRW or Kye's code) and number the important routines and call them port numbers, eg things like "Open a file" is a port number. VGA I'm thinking of using the VT100 protocol so that only needs one (mabye 2) ports. Then there might be new fun things to add, eg a port number to talk to the I2C bus, and the propeller then translates that to the I2C serial stream. Regarding what numbers one assigns to these ports, do people have strong feelings on this?
As for Win ME - <shakes head sadly>
It's not really needed for a minimal system, but for a more generic use I agree. It also allows you to run software that has no source code available since you can have the prop read that address and send the data to a suitable output on the propeller side.
Another thing that is missing (and not really needed on a mini system) is bank switching so we can take advantage of the larger ram chips. Perhaps a small PLD or ASIC could take care of that on a maxi system.
How you approach it really depends on what you want/need to do. If you want to run CPM and programs that have source code available a minimal system should be all that is needed.
If you are trying to replace an old Z80 board in an instrument or other equipment where there is only machine code in rom, eprom, or eeprom available, and there are multiple hardware interfaces at various I/O addresses then you need more. At the very least you need to be able to decode all 256 I/O addresses.
All good points, and I agree with them when applied to a system intended to run CPM or any other software where the source code is available. For CPM the BIOS can be modified to work with two control ports and no changes would be needed for the application as long as it adheres to the CPM I/O calling standards. On the other hand, if you are trying to replace a Z80 board that does not run CPM, has no source code available, and uses dozens of I/O addresses the propeller needs to have access the 8 I/O address bits.
The CPM bios is modified so that address bit = 0 selects the control register, and address bit = 1 selects the data register.
The propeller software uses the data from the control register to select one of the I/O devices it controls (serial port, SD card, parallel port, etc).
Once the control register is written to all subsequent writes to the data register will be written to that device. To write data to any other device requires that the control register be updated. This could result in many more (twice as many?) I/O operations unless the interrupt routines were updated to save and restore the read and write control registers.
Dr. A,
20Mhz Z80s? Oh Stop! You're making me drool all over the keyboard!
A couple of things I've thought about?
1) yes, I could lose the ROM - B U T - you gotta write the loader. Ok?
Something has to act as an address source, and if you can trick the Z80
into providing addresses, then by all means - lose the ROM.
But I'd not want to run 16 address lines from the Z80 to the Prop.
Like you said, Prop pins are precious.
I can work back up to Z80 Assembly, but Pasm makes my head spin.
I would suggest leaving some Z80 I/O port addresses to the Z80
for (FAST) user I/O. 128 ports is probably easiest.
All console I/O (and some handy stuff like RTC, etc) through the Prop.
2) Here is a way to reduce the speed hit on reading 2 ports on the Prop side...
Read nine bits. The 9th bit is A0.
On the Z80 side you are doing OUT PortAddress, DATA (one instruction cycle)
A0 is part of the port address... not a separate write cycle.
On the Prop side, we can read any number of bits at a time.
Yes, you still have to parse the 9th bit to know whether it's a command word
or a data byte, but one read cycle should do the trick right nice. Happy?
As for bank switching, maybe - for a RAM disk?
But that would be a Z80 function (It's the Z80's RAM)
A 48k Transient Program Area worked fine on the Kaypro.
It will run almost ALL CP/M user software.
I like your suggestion to keep the VGA pins.
A touch screen is awful small for full time hard core editing or whatever.
I think it would be right handy to be able to plug in a real monitor.
As for the 30 or so port numbers for CP/M functions, they wouldn't be PORT numbers, but
function numbers - written to the HIGH PORT (A0=1) - ie command or function numbers
(and yes, use the CP/M. function numbers to keep every thing sensible).
We still only have 2 I/O port addresses in use -
Depending on any hardware port address decoding!
Otherwise we COULD have 128 ports with A0 = 0 and 128 ports with A0 = 1 -
all going to the Prop.
'138 to the rescue (is there an HC139?)
I'm happy to see the Nascom worked out. I'm not bitter...honest. Not only do I remember parallel ports, we still have PC based systems that use parallel expanders with three 8255 PIOs on them. Access is easy, I hacked the Linux PIO driver to work with them! No ME required.
As for the bullet pension. I'm saving up for the bullet now. Hope some one can loan me a gun at some point.
@Dr_A, Did you forget your own link to such a scheme. What's wrong with that guys circuits?
http://www.shaels.net/index.php/mini80/mini80-general/119-mini8o-overview I'm sure the common CP/M machines I used, like Intertec Superbrain did, plus their disks were much slower. I think there is lot to be said for having a "standard" here. ZiCog sticks to using exactly the same ports in the same way as the AltairZ80 SIMH project. That way it's easy to test on the sim on a PC and move to Prop system.
@kwin,
I see what you mean about wanting to run random old code with random port addresses and functions. It's not really a case of having the source code or not. We have run MS 4K BASIC on the Prop with no source code. But you do have to know more than just port addresses it uses you also need to know what functionality it expects there. Getting random old code to work can be a challenge and perhaps needs custom hardware in each case. Thus making your minimalist board rather maximal in the general case.
There are Z80 clones designed to run at speeds as low as 1MHz.
http://www.cryptomuseum.com/spy/fs5000/files/NSC800.pdf
It has a multiplexed address/data bus, several interrupts the stock Z80 doesn't have, power save, and if you look at page 24 of the PDF...
there's a special register mapped into the I/O space at 0BBh
And yes, I can verify that this chip has been used commercially.
There's one in my Philips VideoWriter 250...
(Clunky 'all in one' word-procesor with built-in dot-matrix printer.)
It is NOT only Z80 clone - It is marriage between Z80 and I8085
Then t would have had a serial port.
8085:
Serial port, multiplexed address/data
Z80:
No serial, full address and data busses, double set of registers + index registers.
NSC800:
No serial, multiplexed address/data, double set of registers + Index registers, power save.
The Z80 design sacrificed some interrupt pins and the serial port for full data and address buses, gaining a 20% speed improvement.
Assorted DMA commands also added to the general speed advantage.
Th alternate register set tossed the book overboard when it came to writing FAST interrupt routines, which meant it could do interrupt-based bit-banging serial using external chips, negating the 8085's advantage of built-in port. (Kind of like the Propeller, really... Just not as elegant as on the Propeller, of course)
Heater! Bless you. What a find.
At first blush it looks really sweet.
No touch screen, but a working CP/M base system that's up and running -
with working BDOS and all, that's a huge jump forward time-wise.
And it looks like he used a Parallax Demo board as the Propeller base.
I guess I need to trace through his pin assignments to see what exactly is going on there,
but - sweet!
Ok, it's not the single board minimalist circuit offering pocket CP/M at the moment, but
certainly an excellent starting place for it.
What do you say, Doc?
8085 RST 5.5 - 6.5 - 7.5
NSC800 RST A, B, C
It is a great circuit and has some very cunning ideas. And I think we can go further and not use a HC165 or a HC367. Worth noting that on the schematic http://www.shaels.net/index.php/mini80/mini80-general/119-mini8o-overview there are some minor mistakes. All the wires joining the chips do not need joins, and also where busrq and reset join the vertical wire there ?should be joins. Though that does join together reset and busrq so I am not sure about that.
One very important experiment he has done is show the Z80 can be run at 3V3. That simplifies things a lot.
Yes, you do need to know what functionality is expected at a particular port, but that is not usually a problem when you have the schematics and service manual. Keypads, switches, displays, and serial ports are no problem for the propeller. The difficulty often comes from the strange tricks that were used for booting, memory or I/O decoding, and using memory in excess of 64K. For instance, did you know that you could use the Z80 block I/O instructions to read and write to as much as 64K of additional memory? Of course if you used the ports for all 64K of ram there would be no ports left for I/O.
Yes, there are some errors on that schematic.
The '367 answers one of the problems that was bugging me when I wrote the above.
When the Z80 is trying to do an instruction fetch, it asserts /MREQ, /M1, and /RD.
How then do we do a write cycle to memory with /RD (and the RAM's /OE) already asserted?
That would be guaranteed to offend the holy keepers of the magic smoke!
The Mini-80 circuit uses Prop P12 to enable or disable the '367, (tri-state) thus removing
the Z's /RD signal so it can assert its own pseudo /WR signal (From Prop P12).
Same thing fro the RAM chip's /OE pin (/Output Enable).
But those are the only two signals so handled.
Any tristate buffer, or multiplexor chip would do for that trick.
But it HAS to be done - one way or the other.
He also has a hold of /BUSRQ. Can't say why yet.
But I'm fairly sure he's diddling the CLK signal for the Z80 via Prop P10.
(So why mess with /BUSRQ ?
Doc, I believe that 'HC168 is actually a '165, Parallel in shift register. The pin numbers match.
It looks like that is used to shift the lower 8 address bits into the Prop via Prop P14.
The shift register is clocked by Prop P15.
But why the serial out fromn that shift register be tied to Z80 /M1 ???
I'd not even hazard a wild guess.
Well, I'll volunteer to be the sacrificial lamb and try to contact him.
Good question! I think there are many solutions. One I'd like to test out (boards on the way) is to use a low value resistor. High enough that the propeller can force the pin to a certain state but low enough that it doesn't upset normal Z80 operation. I'm guessing something like about 220 ohms. So there is a 220 ohm resistor on the Z80 /WR and /RD pins and so the Z80 is trying to drive /RD low and /WR high but the propeller forces the voltage at the memory chip to /RD high and /WR low. The ram /OE should not matter as the ram needs to be enabled either way.
Untested as yet but I'm hopeful that two resistors will save using a chip.