Thing is with two Props, one for handling the Z80 and one for the terminal you can actually get on and develop the Z80 end by itself just using a terminal program on your PC. Then add the terminal Prop to the set up as and when required or drive it from a PC.
I have another design I just sent off to BatchPCB. Ok, the emulators are fine but I never got them to run more than equivalent to 2Mhz. I'm sure we could do better if we merged in the cache idea from the GCC thread.
One of the reasons I keep looking at the Z80 is that in its standard configuration it has twice the memory of the propeller. I've been trying to get the chip count down and I think one can do something with bank switching and 4 chips plus the propeller.
Take a propeller chip and use 8 pins for data and one for /wr and one for /rd and two for A0 and A1 and use those 12 pins to drive a 8255. That leaves lots of propeller pins free for VGA and keyboard and SD card and uarts. Now the 8255 has 24 I/O pins which is enough to talk to most of the Z80 pins. So add a Z80, 512k ram and another 8255 for the Z80 to talk to the real world.
The controlling 8255 has 3 pins for bank select. The Z80 8255 can talk back to the propeller with a pin to say it wants some data, so you don't have to worry about missing fast pulses.
So ok, two more prop pins, one to detect the Z80 wants to talk, and I used another one for the Z80 clock so the propeller can control the clock speed (useful for slowing down games).
The bank switching is experimental, but rather than switching in and out banks, each block of 64k is self contained, and the propeller switches banks and then issues a reset to the Z80. So a little unorthadox there.
There are enough 8255 pins to talk to the lower 256 bytes of the Z80 memory so that is enough to poke in a program to do some more sophisticated comms.
The idea I have is that virtually all of CP/M can be moved over to the propeller. The SD driver (so CP/M can talk to a standard SD file rather than a disk image), the serial code and the keyboard. So CP/M will be very small and it could give the largest code space ever available to CP/M programs.
Just some random thoughts anyway!
One day I'd like to have a group of Z80s with a common memory that is polled in sequence, like a propeller works. But each 'cog' would be 64k, not 2k.
I always preferred the Z80 op-codes.
But I can happily live with just 8080 instructions.
Me too. I always used Z80 mnemonics but mainly stuck with only the 8080 opcodes. There are a lot less to learn.
I think I asked heater a while back about how much space the zicog took if you just did the 8080 codes and whether there would be room left in a cog for a simple cache driver.
I'd be quite happy with less pins for a VGA text terminal. Only the sync signals and one colour is required (Green of course). RCA is no good as I'd want a decent text display for WordStar. Can we find a keyboard that only needs one pin for serial data?
Perhaps this calls for two Props. One could be the terminal display and keyboard, the other taking care of the ROM emulation, SD card and other Z80 IO/ports.
The Terminal/Keyboard Prop board by itself would have other uses. For example a VGA text terminal for Rasbery Pi boards. In fact somewhere here there is already a design for such a terminal. PocketTerm, or what was it called?
I have done a 1pin video and 1pin keyboard already. Use it on the RamBlade for zicog/cpm already. Uses a standard ps2 keyboard. See the debug section of OBEX.
BTW been extremely busy but that will come to an end for a while next week. I have some new designs waiting in the wings.
@Dr_Acula Any chance we will get a look at this board when time permits?
With your banking you could have the Propeller completely control the ram and using some micromanaging and some programmed signals from the Z80 you could have the Prop switch the bank that the z80 is looking at without having to reset the Z80. It would be a tricky memory management system to program though. Maybe only switch out a portion of the bottom of the 64k to keep at least one portion consistant.
@Dr_Acula Any chance we will get a look at this board when time permits?
Sure, I'll post when I get home. It is a Z80, two 82C55s and a ram chip. One reason for going through a 8255 to get to the Z80 is it decreases the number of 2K7 resistors to do the voltage level shifting. Another reason is one chip acts as a bidirectional buffer and latch and pin number expander, which frees up more propeller pins.
I've got lots of designs that have formal bank switching switching out the bottom 32k or top 16k or whatever. However, they add more chips. I figure that if the propeller can access the bottom 256 bytes of each bank, the propeller can handle moving data between banks. Any time there is a bank change, the Z80 operating system is going to know about it because it would have requested it, so it can store registers etc, and can set a return location flag before requesting a bank change.
It was just a little design challenge to see how few chips could be used. It is untested of course - will have to wait for the boards to come back.
re
The only problem I have with the N8VEM project (not just the N8VEM) is that I don't have a programmer to program either a EEPROM or EPROM which is a major disability when trying to build a computer from scratch...
The propeller could program a parallel eeprom - I looked into this and the logic high on an eeprom is less than 3V. So if you just join propeller pins to eeprom pins, and you never read the data back off the eeprom then you don't need any level shifting resistors. Program it at the slowest (but most definite) speed and you don't need to poll the eeprom. Or add 2K7s and read data back.
I agree EPROMs are a pain - you need an eraser and a programmer. The latest design started off with the idea that the propeller would be the eprom. It then grew when I realised that it is better to do the uart in the propeller than use a uart chip. The keyboard could be done by either the prop or the Z80 (I have Z80 code for a keyboard driver). Ditto the SD card but I think the N8VEM guys are struggling with all the SD card formats, and so it would be easier to drop in Kye's SD code which works with so many different cards.
But (heresy here), I think the actual Z80 might be able to do the job faster than an emulation.
Ultimately I want the Z80 to work with a touchscreen. I think it is time to bring CP/M to the touchscreen generation with icons etc, and for that it needs more code space than CP/M allows, hence the bank switching. What I am thinking of doing is writing the touchscreen driver in C and running it in its own bank, independently of the CP/M system. That makes porting over from the propeller easier. Icons and games need to be able to dump tiles fast from ram.
I'd be quite happy with less pins for a VGA text terminal. Only the sync signals and one colour is required (Green of course). RCA is no good as I'd want a decent text display for WordStar. Can we find a keyboard that only needs one pin for serial data?
Perhaps this calls for two Props. One could be the terminal display and keyboard, the other taking care of the ROM emulation, SD card and other Z80 IO/ports.
The Terminal/Keyboard Prop board by itself would have other uses. For example a VGA text terminal for Rasbery Pi boards. In fact somewhere here there is already a design for such a terminal. PocketTerm, or what was it called?
At one point I was looking at making something using 2 Propellers to replace some large old Z80 boards in instruments I was servicing. Having no access to the Z80 source code made it more difficult since I had to emulate all the I/O registers, buffers, and latches, but it seemed doable at the time.
With access to the Z80 source code it should not be that difficult to do, but the prop that interfaces to the Z80 will need almost all of it's pins for controlling the Z80 unless you use latches. That's 16 address pins, 8 data pins, and at least 4 control pins.
Hi I've built a sinclair spectrum clone that's basicly a z80 being supervised by a propeller. I can upload some schematics and spin files of what I've got so far if that would help.
I use a parallel 128k static ram which the propeller address by incrementing a row of 163 counters. As the prop only needs to transfer programs from an SDcard to the ram or read consecutive addressess that make up the screen display then that works fine and reduces the pins needed. As the static ram doesn't need the refresh period that the z80 generates I use that signal for the prop to transfer the display block from sram into it's internal memory then out to the display. The z80 is clocked from a propeller pin so it's easy to either, single step while monitoring the data and control bus, or use different counter frequencies.
Although I was setting out to make a spectrum clone It should be quite easy to use convert it to other z80 based systems and make it more generic.
Or just take any bits you like and splice them into your own project, that's what I did!
I've posted some photos of my second working prototype already ( easy to find they're on the only other thread I've posted on. Can't work out how to do a link, sorry. I'm a regular but quiet, reader of this forum and I certainly wouldn't have got as far as I have with electronics without it.)
I cut the pin use for VGA down to 4 (VHBB) and then put it onto P23 -> (but I never got around to sorting out the memory waste that gave). Then there was the 4053 switch over on the nominal IC2 pins for KBD (changed over by H pulses). That was an attempt to clear P0 - P18 with the SD on P19 - 22.
@Basher, I would like to see those files. I'm looking into using the Propeller to capture display data from a ZX81/TS1000 and what you are doing looks like something I could use. Thanks!
One day I'd like to have a group of Z80s with a common memory that is polled in sequence, like a propeller works. But each 'cog' would be 64k, not 2k.
I love that idea! a z80 propeller. You could monitor some of the undocumented z80 opcodes and when they appear make the next write or read to the common 64k bank rather than the "cog" 64k , the undocumented opcodes could be made to work as hub commands.
I suppose it would be a bit silly to use a propeller to do the coordination of the Z80's, a bit like using a chainsaw to make an axe.
Just spent the evening sorting through my project files and it's dawning on me how important good documentation is especially if you want to share your work with others at some point . I'm making a resolution that next time the device I want isn't in an eagle library I'll take the time to edit the part properly and not just pick another part with the same footprint.
okay, the first attatchment is the main circuit, next two are the logic for the CPLD's on that board, then the main spin file, logic for propeller board CPLD, propeller circuit with LCD interface, vga driver for the lcd module( innolux AT070TN07), circuit for the lcd power sequencing chip and finally the z80 code used to load and start .sna files( I can't find the source code so I'll have to disassemble it later).
I'm going to spend some time documenting the next version properly. I'm almost ready to etch the next version which consolidates most of the logic onto one larger CPLD and adds a Li-po battery and charging circuit as I want to make it portable.
I found a neat article where someone uses three shift registers to access the lines of an EEProm to create serial communication between the EEProm and an AVR. It's pretty neat.
Comments
Thing is with two Props, one for handling the Z80 and one for the terminal you can actually get on and develop the Z80 end by itself just using a terminal program on your PC. Then add the terminal Prop to the set up as and when required or drive it from a PC.
I have another design I just sent off to BatchPCB. Ok, the emulators are fine but I never got them to run more than equivalent to 2Mhz. I'm sure we could do better if we merged in the cache idea from the GCC thread.
One of the reasons I keep looking at the Z80 is that in its standard configuration it has twice the memory of the propeller. I've been trying to get the chip count down and I think one can do something with bank switching and 4 chips plus the propeller.
Take a propeller chip and use 8 pins for data and one for /wr and one for /rd and two for A0 and A1 and use those 12 pins to drive a 8255. That leaves lots of propeller pins free for VGA and keyboard and SD card and uarts. Now the 8255 has 24 I/O pins which is enough to talk to most of the Z80 pins. So add a Z80, 512k ram and another 8255 for the Z80 to talk to the real world.
The controlling 8255 has 3 pins for bank select. The Z80 8255 can talk back to the propeller with a pin to say it wants some data, so you don't have to worry about missing fast pulses.
So ok, two more prop pins, one to detect the Z80 wants to talk, and I used another one for the Z80 clock so the propeller can control the clock speed (useful for slowing down games).
The bank switching is experimental, but rather than switching in and out banks, each block of 64k is self contained, and the propeller switches banks and then issues a reset to the Z80. So a little unorthadox there.
There are enough 8255 pins to talk to the lower 256 bytes of the Z80 memory so that is enough to poke in a program to do some more sophisticated comms.
The idea I have is that virtually all of CP/M can be moved over to the propeller. The SD driver (so CP/M can talk to a standard SD file rather than a disk image), the serial code and the keyboard. So CP/M will be very small and it could give the largest code space ever available to CP/M programs.
Just some random thoughts anyway!
One day I'd like to have a group of Z80s with a common memory that is polled in sequence, like a propeller works. But each 'cog' would be 64k, not 2k.
Me too. I always used Z80 mnemonics but mainly stuck with only the 8080 opcodes. There are a lot less to learn.
I think I asked heater a while back about how much space the zicog took if you just did the 8080 codes and whether there would be room left in a cog for a simple cache driver.
I have done a 1pin video and 1pin keyboard already. Use it on the RamBlade for zicog/cpm already. Uses a standard ps2 keyboard. See the debug section of OBEX.
BTW been extremely busy but that will come to an end for a while next week. I have some new designs waiting in the wings.
Jeff
With your banking you could have the Propeller completely control the ram and using some micromanaging and some programmed signals from the Z80 you could have the Prop switch the bank that the z80 is looking at without having to reset the Z80. It would be a tricky memory management system to program though. Maybe only switch out a portion of the bottom of the 64k to keep at least one portion consistant.
Sure, I'll post when I get home. It is a Z80, two 82C55s and a ram chip. One reason for going through a 8255 to get to the Z80 is it decreases the number of 2K7 resistors to do the voltage level shifting. Another reason is one chip acts as a bidirectional buffer and latch and pin number expander, which frees up more propeller pins.
I've got lots of designs that have formal bank switching switching out the bottom 32k or top 16k or whatever. However, they add more chips. I figure that if the propeller can access the bottom 256 bytes of each bank, the propeller can handle moving data between banks. Any time there is a bank change, the Z80 operating system is going to know about it because it would have requested it, so it can store registers etc, and can set a return location flag before requesting a bank change.
It was just a little design challenge to see how few chips could be used. It is untested of course - will have to wait for the boards to come back.
re
The propeller could program a parallel eeprom - I looked into this and the logic high on an eeprom is less than 3V. So if you just join propeller pins to eeprom pins, and you never read the data back off the eeprom then you don't need any level shifting resistors. Program it at the slowest (but most definite) speed and you don't need to poll the eeprom. Or add 2K7s and read data back.
I agree EPROMs are a pain - you need an eraser and a programmer. The latest design started off with the idea that the propeller would be the eprom. It then grew when I realised that it is better to do the uart in the propeller than use a uart chip. The keyboard could be done by either the prop or the Z80 (I have Z80 code for a keyboard driver). Ditto the SD card but I think the N8VEM guys are struggling with all the SD card formats, and so it would be easier to drop in Kye's SD code which works with so many different cards.
But (heresy here), I think the actual Z80 might be able to do the job faster than an emulation.
Ultimately I want the Z80 to work with a touchscreen. I think it is time to bring CP/M to the touchscreen generation with icons etc, and for that it needs more code space than CP/M allows, hence the bank switching. What I am thinking of doing is writing the touchscreen driver in C and running it in its own bank, independently of the CP/M system. That makes porting over from the propeller easier. Icons and games need to be able to dump tiles fast from ram.
At one point I was looking at making something using 2 Propellers to replace some large old Z80 boards in instruments I was servicing. Having no access to the Z80 source code made it more difficult since I had to emulate all the I/O registers, buffers, and latches, but it seemed doable at the time.
With access to the Z80 source code it should not be that difficult to do, but the prop that interfaces to the Z80 will need almost all of it's pins for controlling the Z80 unless you use latches. That's 16 address pins, 8 data pins, and at least 4 control pins.
I use a parallel 128k static ram which the propeller address by incrementing a row of 163 counters. As the prop only needs to transfer programs from an SDcard to the ram or read consecutive addressess that make up the screen display then that works fine and reduces the pins needed. As the static ram doesn't need the refresh period that the z80 generates I use that signal for the prop to transfer the display block from sram into it's internal memory then out to the display. The z80 is clocked from a propeller pin so it's easy to either, single step while monitoring the data and control bus, or use different counter frequencies.
Although I was setting out to make a spectrum clone It should be quite easy to use convert it to other z80 based systems and make it more generic.
Or just take any bits you like and splice them into your own project, that's what I did!
I've posted some photos of my second working prototype already ( easy to find they're on the only other thread I've posted on. Can't work out how to do a link, sorry. I'm a regular but quiet, reader of this forum and I certainly wouldn't have got as far as I have with electronics without it.)
I love that idea! a z80 propeller. You could monitor some of the undocumented z80 opcodes and when they appear make the next write or read to the common 64k bank rather than the "cog" 64k , the undocumented opcodes could be made to work as hub commands.
I suppose it would be a bit silly to use a propeller to do the coordination of the Z80's, a bit like using a chainsaw to make an axe.
No problem, i'll get them sorted when I get home tonight.
never let good sence get in the way of a retro plan !
okay, the first attatchment is the main circuit, next two are the logic for the CPLD's on that board, then the main spin file, logic for propeller board CPLD, propeller circuit with LCD interface, vga driver for the lcd module( innolux AT070TN07), circuit for the lcd power sequencing chip and finally the z80 code used to load and start .sna files( I can't find the source code so I'll have to disassemble it later).
I'm going to spend some time documenting the next version properly. I'm almost ready to etch the next version which consolidates most of the logic onto one larger CPLD and adds a Li-po battery and charging circuit as I want to make it portable.