I'd use a CPLD instead of the TTL chips, but than you need software, and programmer, and so on... the TTLs may be just lying around... I just wonder if MREQ toggles between successive memory accesses...
Can't a Prop do what an 8255 would do in that situation at those speeds?
I'm not sure I go with the idea of using shared memory instead of Z80 IN/OUT instructions. That means the Prop has to poll some memory locations all the time, which means it has to take control of the bus, which slows down the Z80.
Isn't it better to have the Prop waiting on the IO/M signal, or whatever it is called, from the Z80 and then do the work like a regular peripheral would?
To read memory, the Z80 pulls MREQ and RD low. To read an I/O byte, it pulls IORQ and RD low. If IORQ is being monitored by the Prop, there is no need to worry about MREQ as all accesses are to memory.
Heater:
Can't a Prop do what an 8255 would do in that situation at those speeds?
Yes but it uses too many pins and there are none left for useful things. I'm thinking the prop has a keyboard, serial port, 8 pins for VGA and 4 for SD which only leaves 12 left. Of course, there could be some cunning solutions sharing the video pins and Z80 access and do the Z80 access in the front porch or back porch of the display or after the frame has been drawn. I did some experiments with the TV driver once and found you could do around 50,000 pasm instructions between frames.
I was originally thinking of shared memory, but the problem with that is you have to rewrite CP/M. Now I'm thinking you trap the IORQ. Monitor the IORQ pin. If it goes low you can do one of two things. You can either pull the Z80 WAIT pin low which preserves the data and address lines as long as you like. Or, if you have the Z80 clock driven by a pasm routine, just stop the clock. Then read the Address lines to find out the port number and then read or write the data lines.
This way you don't use the busrq line (the only time the busrq line is used is at startup when you put the Z80 program into memory).
I think with a 8255 you end up running out of pins and can't address all 64k. But no matter - you can poke a small bootloader program into the Z80 and then set it running to transfer a bigger program.
I think there is an error on my schematic, I think you also need control of the Z80 reset line. So you need to control /rd, /wr and /reset. But if you control /reset I don't think you need to control /busrq any more. Hold the Z80 in reset, program a bootloader into ram (maybe 50 bytes or something) and then transfer CP/M via in/out.
I am hopeful this can be reduced to a Z80, memory chip and a 8255.
I think you may be able to do this with a Z80, memory chip, 2 '245's and the prop. On boot up the prop monitors the Z80 lines and feed instructions to the Z80 data lines at the appropriate times to cause a bootstrap program to be stored in the ram chip.
I've got this idea that maybe this is possible with *no* support chips. Just a propeller, Z80, ram.
Let's see. pin 30/31 for download to the prop. 28/29 for eeprom and we also use the data line for the Z80 /busrq line.
2 pins for keyboard. 2 for a second serial port. So that is the top 8 pins used.
Now in the next block of 8 (pins 16-23) devote 3 to a display. That is 3 for a TV display, and you could also use the same 3 to drive a VGA in single color (green gun only, or connect all 3 colors for white on black).
That leaves 5 pins free. One to monitor /iorq. One to Z80 reset. One to Z80 clock. One to Z80 /rd and one to Z80 /wr.
Pins P0-P7 are data and P8-P15 are A0-A7. Pulldown 10k resistors on A8-A15 for the ram chip.
Start off with reset held low and that puts the Z80 into HiZ. Once the eeprom has loaded put the eeprom data line high which is /busrq.
Now clock in a small bootloader program, reset high, and then start the clock.
The clock generator is in pasm, and after each clock cycle, check if /iorq is low. If it is, read the port from A0-A7 and either read or write the data lines depending on the state of the /rd and /wr lines. It does not matter if this takes a while in pasm as the same pasm routine is running the clock.
The /busrq line is needed because this puts the Z80 into HiZ. You could use this for two things. The first is to do a DMA load into the first 256 ram locations which could be useful for block disk read/writes. And the second reason is that you need to access the SD card and this shares pins P0-P3 so you need the Z80 to stop running while accessing the SD.
If this works, it should be possible to drop the SIMH CP/M image in directly, and then write propeller code to handle the SIMH ports.
Logically this sounds correct. I would prefer the reset line from the prop to be pulled up and an inverter used to the Z80. You could use a transistor for this. I would presume you would require a pullup on /iorq? The SIL resistor networks would work nicely here.
Now you are making me cry over all the Z80s I threw out in 2001
So I will now have to go buying a couple of Z80's too? (Just got me some 6502C chips.. there's a project over on Savage Circuits about doing something very similar with a 6502 and a Propeller.) Of course I have a Z80 chip from my old Nascom 1, but it's only 2MHz..
The speed of the Z80 may not matter so much - get it working at 2Mhz anyway (in fact, I'll probably clock it at 0.1Hz first und watchen das blinkenlichten).
BTW if you want some free Z80s, just find Cluso99's nearest rubbish dump, then start digging...
I only have a, relativly, modern CMOS one at 10 MHz. This is at 5 Volts but being CMOS I thought that it might limp along at a lower rate at 3.3 Volts and allow for dirrect connections. It should be a bit better than the 2 MHz that the DracBlade emulates at, not that I am compaining in the slightest.
I think that a separate RAM will be good to start with, like the 6052 Laptop project, and watch for IORQ activity to indicate that the Z80 needs to talk to somebody else. BUSRQ or RESET will Tristate the Z80 and allow for RAM preloading. I
In a rash fit of "WILL YOU THROW OUT ALL THAT JUNK !" enforced activity I got rid of my EPROM programmer (KISS), its amazing how used you get to newer stuff with easily programmable flash (and inbuilt UARTs). At work there might be the possibility of getting hold of a Rabbit board (from a dish controller) that is supposed to be mostly Z80 ish.
Good point re the voltage difference. I am thinking 8 3k3 resistors for the data lines to do the voltage translation. If the Z80 runs at 5V then 3.3V is a high. Need a 3k3 also on lines that go from the Z80 to the prop - ie /rd, /wr and /iorq.
And pullups on a number of Z80 pins, and pulldowns on A8-A15.
So there will be some resistors here, but it still should be just two chips - Z80 and ram.
No eprom needed though. Easier to write a small bootloader.
Tor's link is great because they have even put the 6502 on a Gadget Gangster board. A Z80 plus ram plus resistors should also fit on a GG board.
As you say a real NMOS Z80, with its TTL compatible voltages, might be better at dirrect connection than a CMOS one, but then you will need seveal car batteries to power it up :-)
My N1 used about 2 Amps just for the 5 Volt rail and a fair chunk of that went into the Z80 judging by its warmth.
Has anything come of this project? I have been getting into the ZX81 again with their new ZXpand (32K ram and SD card to save ZX81 programs) and ZXpand-AY sound card. The ZXpand-AY sound card also has 2 ports of 8 I/O lines that would be interesting to interface with a micro-controller for more functionality (i.e. SPI or something). Since there is no SHIFTOUT command for the ZX81, I'm going to have to write Z80 assember code. Is there any parallax code on this I could follow for Z80 conversion also? Possibly anything happening with an 8255 might be good too.
Just wanting to see what's happening here and if anything might be applicable to some ideas I have of interfacing a ZX81 to a micro-controller like a propeller or something.
I too am interested in this project. Like Tim I have got back into using a ZX81 and going to the ZX81 forum for ideas. I have a breakout board for the ZX81 edge connector and I'm trying to see how to interface a Propeller with it. Right now I have two ZX81/Propeller projects.
1. A Cassette player substitute that converts files from a SD card to the audio output that a ZX81 can understand. It uses a Serial LCD and a simple 2 button interface to navigate through the SD card. I have it working and want to see if I can also save files to the SD card. This probably could be converted easily into other protocols that other old 8 bit computers use. If there is an interest I'll start a thread on it.
2. A Human Interface Device. The Propeller will read in the keyboard matrix and then either convert a PS2 keyboard, Joystick, NES controller, WII nunchuck or classic controller into the appropriate input to the ZX81. I have just started this project.
@Tim if I could I'd like to PM you about the ZX-Pand and the other add-ons. I've been debating getting them and would like to see your impression of them.
I remember meeting up with you at the get together at Old Bit Collectors place in OH earlier this year and on the Propeller Powered forums (haven't been to in a while).
I chicken'd out of doing it properly. One of the reasons I was fond of the idea of using the Prop as all of the periferals was that i didn't have any suitable, real, Z80 bits that I had enough knowledge of to get going. Then Grant Searle's artical went past my nose just as I knew where a SIO/2 (and a Z80B) was.
So this was made ... At present the Prop wakes up as KyeDos and I have PropTerm feeding the TTL port of the SIO. Nothing clever, I know, but as I have SOOOOO many free pins, more will happen. I have laid on the possibility of the Z80's and SIO's clock coming from the Prop (instead of a 7.3MHz Osc) and the RS232 port of the SIO has its own option as well so the Prop could be its CTC (jitters permitting).
As always, the only new bits are the PCB material and the solder. (the d type leads were "cough" found)
Thanks, but as always I am only riding on others shoulders.I do enjoy the constructional side, SHE buys loads of materials and makes worthless cards and trinkets ... I collect loads of junk and make worthless retro-computers ...This one boots as either a version of M$ basic (as on the blessed Nascom) or then onto CP/M 2.2. I will have to work out a way of using the Prop's SD card as the program input/output as well as the '232 port.
The toner transfer seems to be going into one of my "poor" phases. It still works but I have to do more re-working to get things right. The photo paper (Tesco Everyday value glossy) has been repackaged as .... quality glossy, and isn't as good :-( I suppose in their defense they are not intending for it to be iron proof. The blue plastic sheets are much better but work out at £4 each and this project would have used 2 or three of them.Yes I know that I am being cheap, but I can bask in the warm glow of ... a Z80B at 7.3MHz (Grant recons that they all go >10MHz ... tempting).
I have since found a CMOS SIO/2 to go with the CMOS Z80 so I could try them in this, but they might be better placed for the 3.3V Prop world.
My post count will soon be the date that all of this Z80 "infection " started!
Comments
I'm not sure I go with the idea of using shared memory instead of Z80 IN/OUT instructions. That means the Prop has to poll some memory locations all the time, which means it has to take control of the bus, which slows down the Z80.
Isn't it better to have the Prop waiting on the IO/M signal, or whatever it is called, from the Z80 and then do the work like a regular peripheral would?
To read memory, the Z80 pulls MREQ and RD low. To read an I/O byte, it pulls IORQ and RD low. If IORQ is being monitored by the Prop, there is no need to worry about MREQ as all accesses are to memory.
Heater:
Yes but it uses too many pins and there are none left for useful things. I'm thinking the prop has a keyboard, serial port, 8 pins for VGA and 4 for SD which only leaves 12 left. Of course, there could be some cunning solutions sharing the video pins and Z80 access and do the Z80 access in the front porch or back porch of the display or after the frame has been drawn. I did some experiments with the TV driver once and found you could do around 50,000 pasm instructions between frames.
I was originally thinking of shared memory, but the problem with that is you have to rewrite CP/M. Now I'm thinking you trap the IORQ. Monitor the IORQ pin. If it goes low you can do one of two things. You can either pull the Z80 WAIT pin low which preserves the data and address lines as long as you like. Or, if you have the Z80 clock driven by a pasm routine, just stop the clock. Then read the Address lines to find out the port number and then read or write the data lines.
This way you don't use the busrq line (the only time the busrq line is used is at startup when you put the Z80 program into memory).
I think with a 8255 you end up running out of pins and can't address all 64k. But no matter - you can poke a small bootloader program into the Z80 and then set it running to transfer a bigger program.
I think there is an error on my schematic, I think you also need control of the Z80 reset line. So you need to control /rd, /wr and /reset. But if you control /reset I don't think you need to control /busrq any more. Hold the Z80 in reset, program a bootloader into ram (maybe 50 bytes or something) and then transfer CP/M via in/out.
I am hopeful this can be reduced to a Z80, memory chip and a 8255.
Let's see. pin 30/31 for download to the prop. 28/29 for eeprom and we also use the data line for the Z80 /busrq line.
2 pins for keyboard. 2 for a second serial port. So that is the top 8 pins used.
Now in the next block of 8 (pins 16-23) devote 3 to a display. That is 3 for a TV display, and you could also use the same 3 to drive a VGA in single color (green gun only, or connect all 3 colors for white on black).
That leaves 5 pins free. One to monitor /iorq. One to Z80 reset. One to Z80 clock. One to Z80 /rd and one to Z80 /wr.
Pins P0-P7 are data and P8-P15 are A0-A7. Pulldown 10k resistors on A8-A15 for the ram chip.
Start off with reset held low and that puts the Z80 into HiZ. Once the eeprom has loaded put the eeprom data line high which is /busrq.
Now clock in a small bootloader program, reset high, and then start the clock.
The clock generator is in pasm, and after each clock cycle, check if /iorq is low. If it is, read the port from A0-A7 and either read or write the data lines depending on the state of the /rd and /wr lines. It does not matter if this takes a while in pasm as the same pasm routine is running the clock.
The /busrq line is needed because this puts the Z80 into HiZ. You could use this for two things. The first is to do a DMA load into the first 256 ram locations which could be useful for block disk read/writes. And the second reason is that you need to access the SD card and this shares pins P0-P3 so you need the Z80 to stop running while accessing the SD.
If this works, it should be possible to drop the SIMH CP/M image in directly, and then write propeller code to handle the SIMH ports.
Now you are making me cry over all the Z80s I threw out in 2001
-Tor
Looks a very similar idea.
The speed of the Z80 may not matter so much - get it working at 2Mhz anyway (in fact, I'll probably clock it at 0.1Hz first und watchen das blinkenlichten).
BTW if you want some free Z80s, just find Cluso99's nearest rubbish dump, then start digging...
I think that a separate RAM will be good to start with, like the 6052 Laptop project, and watch for IORQ activity to indicate that the Z80 needs to talk to somebody else. BUSRQ or RESET will Tristate the Z80 and allow for RAM preloading. I
In a rash fit of "WILL YOU THROW OUT ALL THAT JUNK !" enforced activity I got rid of my EPROM programmer (KISS), its amazing how used you get to newer stuff with easily programmable flash (and inbuilt UARTs). At work there might be the possibility of getting hold of a Rabbit board (from a dish controller) that is supposed to be mostly Z80 ish.
And pullups on a number of Z80 pins, and pulldowns on A8-A15.
So there will be some resistors here, but it still should be just two chips - Z80 and ram.
No eprom needed though. Easier to write a small bootloader.
Tor's link is great because they have even put the 6502 on a Gadget Gangster board. A Z80 plus ram plus resistors should also fit on a GG board.
My N1 used about 2 Amps just for the 5 Volt rail and a fair chunk of that went into the Z80 judging by its warmth.
This is another idea - fits on the Gadget Gangster USB board.
Keyboard, TV or VGA, second serial port, Z80 and Z80 ram. I don't think I left anything out...
Just wanting to see what's happening here and if anything might be applicable to some ideas I have of interfacing a ZX81 to a micro-controller like a propeller or something.
Thanks,
Tim
1. A Cassette player substitute that converts files from a SD card to the audio output that a ZX81 can understand. It uses a Serial LCD and a simple 2 button interface to navigate through the SD card. I have it working and want to see if I can also save files to the SD card. This probably could be converted easily into other protocols that other old 8 bit computers use. If there is an interest I'll start a thread on it.
2. A Human Interface Device. The Propeller will read in the keyboard matrix and then either convert a PS2 keyboard, Joystick, NES controller, WII nunchuck or classic controller into the appropriate input to the ZX81. I have just started this project.
@Tim if I could I'd like to PM you about the ZX-Pand and the other add-ons. I've been debating getting them and would like to see your impression of them.
I remember meeting up with you at the get together at Old Bit Collectors place in OH earlier this year and on the Propeller Powered forums (haven't been to in a while).
Is the Prop going to be connected to the data bus?
So this was made ... At present the Prop wakes up as KyeDos and I have PropTerm feeding the TTL port of the SIO. Nothing clever, I know, but as I have SOOOOO many free pins, more will happen. I have laid on the possibility of the Z80's and SIO's clock coming from the Prop (instead of a 7.3MHz Osc) and the RS232 port of the SIO has its own option as well so the Prop could be its CTC (jitters permitting).
As always, the only new bits are the PCB material and the solder. (the d type leads were "cough" found)
Alan
Thanks, but as always I am only riding on others shoulders.I do enjoy the constructional side, SHE buys loads of materials and makes worthless cards and trinkets ... I collect loads of junk and make worthless retro-computers ...This one boots as either a version of M$ basic (as on the blessed Nascom) or then onto CP/M 2.2. I will have to work out a way of using the Prop's SD card as the program input/output as well as the '232 port.
The toner transfer seems to be going into one of my "poor" phases. It still works but I have to do more re-working to get things right. The photo paper (Tesco Everyday value glossy) has been repackaged as .... quality glossy, and isn't as good :-( I suppose in their defense they are not intending for it to be iron proof. The blue plastic sheets are much better but work out at £4 each and this project would have used 2 or three of them.Yes I know that I am being cheap, but I can bask in the warm glow of ... a Z80B at 7.3MHz (Grant recons that they all go >10MHz ... tempting).
I have since found a CMOS SIO/2 to go with the CMOS Z80 so I could try them in this, but they might be better placed for the 3.3V Prop world.
My post count will soon be the date that all of this Z80 "infection " started!
Alan