Propeller Z80 CPM hybrid
Dr_Acula
Posts: 5,484
Yet another crazy idea from Dr Acula's shed!
One Z80 chip, two propeller chips, VGA, TV, SD card, touchscreen, 512k ram, I2C port, keyboard, audio.
The aim of this little project is to try to extend CP/M so it runs on a touchscreen.
Touchscreens are great for graphics but they are a bit tricky in that they need fast data transfer to be able to refresh a screen of text or move sprites around in a game. That generally means external ram. But I think there might be another way, if one uses a propeller chip and dedicates as much as possible of the hub ram to a graphics buffer. Ballpark calculations, say 100 ascii characters, 24k of hub ram gives 240 bytes per character. Each pixel is 2 bytes, so that is 120 pixels. 7x5 fonts are fine, 14x10 is too big, 12x8 fonts will fit.
It would be great to also have a VGA and TV display. And audio, and an SD card, and a keyboard etc etc, and after thinking about this a lot, I think a two propeller solution works quite well.
The Z80 chip is there, well, just because. It could be replaced with a propeller chip running a Z80 emulation and that might happen down the track.
Ever since I was a kid (1970s) a computer was a box on the desk with a screen (for my dad, a computer was a room full of equipment, and when you typed "LOAD", someone in another room went and physically got a big roll of paper tape and LOADED it. But I digress). So every few years up until very recently, computers got faster and the screens got bigger and the operating systems got slower. And then suddenly, a few years ago, people wanted mobile computers, and the whole paradigm changed. So it has been back to the drawing board and operating systems (such as Android) have had to be written almost from scratch.
So I figured, if people are writing operating systems from scratch, why not go back to CP/M, which is IMHO, simple enough that it is possible for one person to understand the whole thing. CP/M is quite simple behind the scenes - it has a whole lot of numbered BIOS and BDOS calls, and there is room for more to be added. Some of the later versions even had block memory moves, which is just perfect for moving sprites around on a screen.
But CP/M also has some flaws. It was written in an age where disk formats had not been standardised, and so its disk operating system is now incompatible with modern systems. No matter - CP/M was also designed to be modular, so let's take the numbered disk functions (open a file, write a record, close a file etc) and replace them with calls to a propeller chip running FSRW or Kye's disk object. This has the bonus of making CP/M much smaller, which leaves room for other clever things. The upside is that it should be possible for CP/M to load and run files off an SD card that has been formatted with FAT32, so no need to use a disk translation program.
The SD card, VGA, TV and keyboard are all standard propeller peripherals. There is an I2C header for connecting to more digital and analog I/O pins. There are three pins dedicated to interprop comms, and this could be an SPI interface which (theoretically) should match speed of the SPI interface to an SD card, so the second propeller can get SD files as well.
The traditional way of booting up a Z80 is with an eprom, but this means one needs an eprom programmer. So this design uses a couple of I2C expansion chips to move a boot program into ram and then start the Z80. The expansion chips also do the 3V to 5V translation, and also the pins can individually be set to HiZ once the bootloader starts. Finally, these chips also handle the memory banking. However, the I2C bus is slow, and so for faster comms to and from the Z80, there are 4 input and 4 output pins to a propeller chip.
In general terms, I'd like to see a version of CP/M running on a touchscreen.
This project is maybe only of interest to the hardcore retro computer enthusiasts, but for those that might be interested, I'm getting some boards made, and as with a number of previous projects, I'm happy to do a 'hardware for software' swap.
One Z80 chip, two propeller chips, VGA, TV, SD card, touchscreen, 512k ram, I2C port, keyboard, audio.
The aim of this little project is to try to extend CP/M so it runs on a touchscreen.
Touchscreens are great for graphics but they are a bit tricky in that they need fast data transfer to be able to refresh a screen of text or move sprites around in a game. That generally means external ram. But I think there might be another way, if one uses a propeller chip and dedicates as much as possible of the hub ram to a graphics buffer. Ballpark calculations, say 100 ascii characters, 24k of hub ram gives 240 bytes per character. Each pixel is 2 bytes, so that is 120 pixels. 7x5 fonts are fine, 14x10 is too big, 12x8 fonts will fit.
It would be great to also have a VGA and TV display. And audio, and an SD card, and a keyboard etc etc, and after thinking about this a lot, I think a two propeller solution works quite well.
The Z80 chip is there, well, just because. It could be replaced with a propeller chip running a Z80 emulation and that might happen down the track.
Ever since I was a kid (1970s) a computer was a box on the desk with a screen (for my dad, a computer was a room full of equipment, and when you typed "LOAD", someone in another room went and physically got a big roll of paper tape and LOADED it. But I digress). So every few years up until very recently, computers got faster and the screens got bigger and the operating systems got slower. And then suddenly, a few years ago, people wanted mobile computers, and the whole paradigm changed. So it has been back to the drawing board and operating systems (such as Android) have had to be written almost from scratch.
So I figured, if people are writing operating systems from scratch, why not go back to CP/M, which is IMHO, simple enough that it is possible for one person to understand the whole thing. CP/M is quite simple behind the scenes - it has a whole lot of numbered BIOS and BDOS calls, and there is room for more to be added. Some of the later versions even had block memory moves, which is just perfect for moving sprites around on a screen.
But CP/M also has some flaws. It was written in an age where disk formats had not been standardised, and so its disk operating system is now incompatible with modern systems. No matter - CP/M was also designed to be modular, so let's take the numbered disk functions (open a file, write a record, close a file etc) and replace them with calls to a propeller chip running FSRW or Kye's disk object. This has the bonus of making CP/M much smaller, which leaves room for other clever things. The upside is that it should be possible for CP/M to load and run files off an SD card that has been formatted with FAT32, so no need to use a disk translation program.
The SD card, VGA, TV and keyboard are all standard propeller peripherals. There is an I2C header for connecting to more digital and analog I/O pins. There are three pins dedicated to interprop comms, and this could be an SPI interface which (theoretically) should match speed of the SPI interface to an SD card, so the second propeller can get SD files as well.
The traditional way of booting up a Z80 is with an eprom, but this means one needs an eprom programmer. So this design uses a couple of I2C expansion chips to move a boot program into ram and then start the Z80. The expansion chips also do the 3V to 5V translation, and also the pins can individually be set to HiZ once the bootloader starts. Finally, these chips also handle the memory banking. However, the I2C bus is slow, and so for faster comms to and from the Z80, there are 4 input and 4 output pins to a propeller chip.
In general terms, I'd like to see a version of CP/M running on a touchscreen.
This project is maybe only of interest to the hardcore retro computer enthusiasts, but for those that might be interested, I'm getting some boards made, and as with a number of previous projects, I'm happy to do a 'hardware for software' swap.
1024 x 690 - 200K
Comments
I might be interested in purchasing one of the boards for future use though. Do you have a price for a bare board?
I think replacing the disk driver in cpm to use FAT would be a great idea. It's a wonder it hasn't been done already somewhere, or has it? Maybe worth googling!
As for booting, in the emulation, we only use a small 1KB (or less?) in high mem around $FC00 to load from the SD cpm boot sectors, and a jmp in low mem at $0000. So surely the prop could write this to sram, even from its own eeprom, or from the SD card as a cpm boot file.
Surely a prop would be simpler than using a real Z80 and of course, no buffering between 3v3 and 5v would be required. If you used this method, then I would expect we could mix'n'match cpm programs and prop pasm programs. Just a thought.
With that chip count, this project is probably best to wait for the Prop 2 ?
Why not use that one instead.
http://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCsQFjAA&url=http%3A%2F%2Fwavestation.voila.net%2Fos%2FHD64180.pdf&ei=RKHXUeunO-Sh4gTsnICYDg&usg=AFQjCNFvegE2VHn0HIRjTOHl59ZupLZGuw&sig2=eWTFKidAOXpeOesE3TQKkA&bvm=bv.48705608,d.bGE
People around here seem to think that it would be "more sensible to ..."
I recon that misses the point of using a Z80 in the first place! It was stupid to spend a whole month's wage on a SBC that gave 1KB of user RAM and even more dense to spend a few more on the upgrading of it.And here we are 3+ decades later ...
Incidentally have you seen this
http://www.retroleum.co.uk/20130706/enzos-cx80-z80-board/
Have you ever run across a CP/M app called "WireMaster" ? It was a wire wrap CP/M program...
Mike B. - North Carolina
re kwinn and buying boards, yes I'm getting 5 made so you can have one for free if you want. E&OE and I'm sure there will be tracks that are wrong and maybe the odd wire link will need to be added.
re jmg and waiting for the prop 2, yes I agree and we probably could fit the whole lot in a prop2. I keep checking the prop2 update threads and am looking forward to getting one.
re Sapieha, interesting chip. I'll do some more research.
re cavelamb, yes the Z80 could run the touchscreen directly. However there is the 5V to 3V problem and by the time you add several (3) more latches to do level translation a propeller ends up less chips. Also the touchscreen needs an SPI interface for the touch part, and then with VGA, TV, keyboard, SD card, there are not enough propeller pins, so the second propeller is needed, and then the second propeller has lots of spare pins and so may as well use them for talking to a touchscreen. I do have another design I am thinking about where the Z80 is kind of wrapped up in 74LVC chips, with BUSAK controlling the HiZ for those chips, so in effect it becomes a 3V Z80. The ram then runs at 3V instead of 5V, all the I/O is 3V (74HC as no need for more level translation) and interface with the propeller chips doesn't need level translation. That might end up with less chips overall, and it would be kind of cool to have the Z80 controlling a touchscreen directly. The touchscreens have an 8 bit and 16 bit mode, and they are advertised as having an 8080 type bus, so this should be very possible.
One thing the propeller helps a lot with is asynchronous comms. Certainly a Z80 can poll a keyboard, and a touch SPI at the same time, but add in serial comms and reading an SD card and it starts to need an interrupt driven system. The propeller is so handy for collecting data and storing it in a circular buffer for when it is needed. That is the propeller's strength. I guess its weakness is that a cog has 1/32 of the ram/code space of a Z80, so I'd like to think the Z80 has a place as well. Who am I kidding? It is just that I need to use all those chips sitting in the shed!
re w4fej and Wiremaster, no I haven't heard of that. Do you have a link?
I was actually thinking more about the EZ80 series, which I believe will run at 3 volts
(with 5 volt tolerant I/O pins). 50 Mhz clock rate. On-chip goodies.
There are several sub-species with different stuff.
<https://www.zilog.com/index.php?option=com_product&task=product&businessLine=1&id=77&parent_id=77&Itemid=57>
I know your pain, I have a couple of Z80s out in my garage. If the breeze is in the right direction, I can hear them calling to me ...
"re w4fej and Wiremaster, no I haven't heard of that. Do you have a link?"
Nope, no link. I was hoping you might have run across it. It was a CP/M app for wire wrapping prototypes etc. Was really a great application. You fed it a text file with part numbers and pin numbers and what other parts/pins the wires went to and it generated all the documents you needed to build and maintain (read change) the project. I was trying to find something like it for windows but I guess all the instant PCB houses have made wire wrap a historical method of prototyping..
I used to own serial number 13 IMSAI 8080 computer. I remember all too well when you had the FULL 64k of memory boards (8 boards) you could use the computer for a room heater !!
I had a really good database manager for CP/M (and MP/M) but it has disappeared or I would have sent it to you. It was multi-user and a WYSIWYG development environment.
Ah... CP/M, those were the days...
Mike B.
-Tor
A version of the sw is available here: http://www.classiccmp.org/cpmarchives/cpm/Software/rlee/L/LOOSECPM/005/
Wonderful tool, even if you are not wire wrapping. Great for point to point soldering using solderable magnet wire as well.
Gerrit
For interest sake, here is an excerpt from the Read.me:
BIGSAMPL is the wirelist for a CPU board. It is included
as an example you can run that will take some time to do.
It takes from 10 to 20 minutes, depending on disk density,
CP/M block/deblock factors, CPU speed, and outputs requested.
It also eats up a lot of disk space for temporaries and
outputs, so run it on a disk with 100 KB or so available.
On a 4 MHz Z80 with JADE Double D Controller, with default
outputs requested, it takes 15 minutes and 21 seconds.
If you want to build this maybe do it in modules - start with a bare propeller, use the prop terminal for debugging so that saves building the display and keyboard section, add an SD card, add the two MCP23017 chips and get the pins toggling on that, then add a Z80 and your favourite ram chip. Leave out the touchscreen for the moment, and can leave out the LVC chips too as it is possible to interface to the Z80 slowly via the MCP23107 chips and then later move to a faster SPI type interface. Hopefully in the next week or so I'll be able to get a tiny 10 line program into the Z80 and run it. I'm happy to share code etc as we go...
Rather than all that complexity, why not choose a 3v Z80,
A quick scan at mouser, finds good stocks in plcc68, of a Z8S180 - 33MHz 3.3V and with good peripherals included.
- could give a working platform, until the Prop 2 hits mainstream, which will be some months off.
DigiKey has them in stock in DIP64:
http://www.digikey.com/product-detail/en/Z8S18020PSG/269-4301-ND/928984
I think that is only 20MHz not 33MHz, and the shrink DIP64 is not so easy to find sockets for ... PLCC68 is 0.1" standard.
Digikey do have DIP64 sockets, but at an eye watering $8.15 each ....
PLCC68 are much better prices..
...reading this thread with great interest... go on... please....
http://www.singlechips.com/pdf/z8s180ps.pdf
It's more like 20-Mhz at 3 volts.
But a 20-MHZ Z80 is still a powerful beast today.
Z8SL180 comes in:
64 pin DIP
68 pin PLCC
80 pin QFP
Has interrupts!
Just add 5" or 6" touch pad (and a cpm boot disk on SD card)
It would be a real performer.
A CP/M touch pad.
But this is the Propeller forum (a-hem)
The Prop can provide I/O services for console I/O,
serial, video, Keys, mouse, RTC, whatever.
That's a lot of service from a single chip.
But how to communicate between Z80 and P8x32
without serious bottlenecks?
The Z80 side would prefer 8 bit parallel bytes for speed.
The I/O side Propeller runs serial ports, parts and such.
A different twist?
Using a Propeller as a programmable I/O device,
in byte-wide architecture...
Give the Propeller "Byte-Wide" access?
Like it was any other I / O chip?
8 data pins, 1 select (/CS), 1 direction (R/W) adds up to 10 pins.
Another 2 pins for internal device addressing: 12 pins.
The remaining I/O pins and cogs are for use to do something fun.
Console service: VGA, KEY, Mouse (sing it right) (sing it right).
SD card, RTC, BioAnalyzer, etc.
All the cool stuff a Prop can do...
Offered services as an intelligent I/O chip.
Maybe smaller package? Fewer pins req'd?
And respond to Z80 access as a byte-wide register array.
A slower memory access.
How fast could a Prop respond to a /CS request?
-Tor
(I must stop getting interested in "something else", before finishing anything).
I was tempted by a couple of seconhand Z180s but thought that if I was going to have to contend with all of the extra periferals and registers then an AVR emulating a Z80 wasn't too different, and I have a reasonable supply of the usual suspects.
I thought I was the only one who admitted to abusing the Propeller in ways like this.
It's always amazing to see just how robust the little Propeller is.. I've yet to fry one or toast the PLL.
Jeff
I've got a Z80 program to run today. Mimimal setup - one propeller/eeprom, one Z80, one memory chip, two MCP23017 chips (on the I2C bus). The Z80 is being clocked by the propeller which works fine with logic levels as the Z80 logic high is 2.0V.
Using two MCP23017 chips sure beats using an EPROM programmer with a UV eraser. And it saves buying a parallel eeprom programmer too.
To make things easier I have two variables Z80OUTA and Z80DIRA which behave the same as Spin's OUTA and DIRA. There are 32 I/O pins on the two MCP23017 chips and so it works out simpler to talk to them using familiar routines (behind the scenes the direction H/L is the inverse of Spin's).
This is the demo program
PUB Z80TinyTestProgram | i ' MCP23017 pins are (MSB to LSB) Reset.Busrq.Mreq.Rd.Wr.3 Bank.16 address.8 data = 32 pins ' online compiler http://clrhome.org/asm/ and use hexedit to view ' NOP ' LD A,5 ' LD (8),A ' HALT ' 00 3E 05 32 08 00 76 Z80Stop ' Stop the Z80 Z80WriteByte(0,$00) Z80WriteByte(1,$3E) ' ld a,5 Z80WriteByte(2,$05) Z80WriteByte(3,$32) 'ld ($0008),a Z80WriteByte(4,$08) Z80WriteByte(5,$00) Z80WriteByte(6,$76) ' halt Z80WriteByte(7,$00) Z80WriteByte(8,$00) ' this value should change to 5 if the program is working Z80WriteByte(9,$00) Z80OUTA := %01000000_00000000_00000000_00000000 ' reset low, busrq high, bank zero Z80DIRA := %11000111_00000000_00000000_00000000 ' reset, busrq and bank pins outputs, rest all HiZ MCP23017_Out Z80OUTA |= %10000000_00000000_00000000_00000000 ' reset pin high, Z80 can now run MCP23017_Out Z80BusrqLow ' bus request Z80DIRA := %11111111_11111111_11111111_00000000 ' control all the pins except data Z80OUTA := %10111000_00000000_00000000_00000000 ' control pins high except busrq which is low. Bank is zero MCP23017_Out ' output repeat i from 0 to 9 vt100.hex(z80ReadByte(i),2) ' memory dump crlfThe clock is a little pasm routine
PUB Z80Clock ' start the Z80 clock cognew(@zToggle, 0) 'Launch new cog DAT {Toggle P15} org 0 'Begin at Cog RAM addr 0 zToggle mov dira, Pin 'Set Pin to output mov Time, cnt 'Calculate delay time add Time, #9 'Set minimum delay here :zloop waitcnt Time, zDelay 'Wait xor outa, Pin 'Toggle Pin jmp #:zloop 'Loop endlessly Pin long |< 15 'Pin number zDelay long 20 'Clock cycles to delay - stops working if under 15 and a 4Mhz Z80 Time res 1 'System Counter WorkspaceThe full code is attached and all the z80 routines are down the bottom of the main routine which is KyedosZ80.spin. It is much longer than necessary as it is built around Kyedos so all the VGA/Keyboard/SD drivers are there ready to be used. Ultimately I'd like to do things like have the Z80 send a message to reload a new program into the propeller to change from (say) a VGA text driver to a VGA graphics driver.
When you were doing the "Cog-Jets" I thought that you were sort of saying that areas of the Hub could be clensed and then re-allocated (I also think that Local Roger was saying much the same recently). If I am not mistaken in this thinking, could there be some Hub RAM that could be made available to do Z80 RAM. I know that this would be smaller than CP\M could use but there could be a 3 chip Z80 system.
After all it took me about 1 year to save up for the "16KB" S100 board (that only had 8KB on it) so there will never, ever, be a need for more than 8KB, will there?
Working on a 2 bit comms system between the Z80 and prop (2 pins each way - clock and data, so 4 pins in total).
For the Z80 fans this will make sense. Poke a little 48 byte bootstrap program into memory using the 23017 chips, run it, then talk to the bootstrap program using a 2 pin clock/data system, send some bytes, then stop the Z80 and read them back from memory.
The simple bootstrap program should be enough to get a bigger comms program working, and then download CP/M. That is the aim anyway
PUB Bootstrap | i,n,c ' send a tiny program capable of receiving a block of data ' uses 4 Z80 pins, 2 each way. ' P0 = Prop to Z80. ' P1 = Prop to Z80. ' P4 = Z80 to Prop. ' P5 = Z80 to Prop. ' write this in the N8VEM program and compile using RASM, view with hexedit, copy and paste from hexedit as hex text ' .Z80 ' org 0h ; need this to start at zero, add other org statements as needed ' 'main: ' nop ; first byte ? gets corrupted to zero so put in a NOP ' ld sp,0FFFFh ; stack ' ld hl,0100h ; start storing data at 0100 like a CP/M program 'fetchbyte: ' ld d,0 ; byte coming in is stored in d so reset to zero ' ld b,8 ; load b with 8 to count the bits 'get8bits: ; do 8 times ' call fetchbit ; waits till data is clocked in, returns e = 0 or 1 ' ld a,d ; get previous d ' or e ; or with the returned bit ' ld d,a ; store back to d ' rrc d ; rotate right ' djnz get8bits ; do this 8 times ' ld (hl),d ; store to memory ' inc hl ; add 1 to hl ' jp fetchbyte ; get the next byte ' ' ; subroutines ' 'fetchbit: ; returns e = 0 or 1 ' in a,(0) ; ports are not decoded so any port number will work ' bit 1,a ; bit 0 is the data and bit 1 is the clock, wait till High ' jr z,fetchbit ; loop until the clock goes to 1 ' and 00000001b ; mask off other bits ' ld e,a ; store answer in e 'clockzero: ; wait until the clock goes to zero again ' in a,(0) ; read the port ' bit 1,a ; test the clock bit, wait till Low ' jr nz,clockzero; loop ' ret ; return ' ' ' end ; finish the program ' see the dat section below for the compiled program printstring(string("Start transfer")) crlf Z80Stop repeat i from 0 to 47 Z80WriteByte(i,byte[@Z80BootProgram][i]) DIRA |= %00000000_00000000_00000000_00000011 ' bit 0 is data and bit 1 is clock OUTA &= %11111111_11111111_11111111_11111100 ' both bits zero Z80Run ' run this program on the Z80 c := 0 ' counter repeat 100 ' debugging - error if go over 255, starts overwriting program at 0 n := c & $000000FF ' byte to send out, should appear at 0100 up c += 1 repeat 8 OUTA |= %00000000_00000000_00000000_00000010 | (n & %00000001) ' clock bit high, or with data bit delay.pause10us(1) ' ? make this shorter OUTA &= %11111111_11111111_11111111_11111100 ' clock low, data low cleared for next bit delay.pause10us(1) n >>= 1 ' shift Z80Stop Z80Dump(500) DAT Z80BootProgram byte $00,$31,$FF,$FF,$21,$00,$01,$16,$00,$06,$08,$CD,$1A,$00,$7A,$B3 byte $57,$CB,$0A,$10,$F6,$72,$23,$C3,$07,$00,$DB,$00,$CB,$4F,$28,$FA byte $E6,$01,$5F,$DB,$00,$CB,$4F,$20,$FA,$C9,$00,$00,$00,$00,$00,$00I did see something about booting a Z80 with no ROMs, I do not know if that was anything useful though.
The trouble is, you lot went and got me a Nascom running in one Prop and so that removed all of the urgency. Now when I start dreaming of another fool's errand it just doesn't have enough positives to stop me grass-hoppering onto something else.
I will have to smash up the working "KBD" CP\M and Nascom, that's what my ex-wife (and "family") probably did to the real ones. Bless.
The Altera CPLD (EPM7128) board worked, which means that the homemade ByteBlaster (parallel) does too. Next stop a Cyclone2 with a (Spantion?) EEPROM).
Alan
The mini80 is quite cunning. Note how he uses the Z80 as a counter to step through RAM addresses as he jams the boot code into the RAM. That's neat.