Shop OBEX P1 Docs P2 Docs Learn Events
Propeller Z80 CPM hybrid — Parallax Forums

Propeller Z80 CPM hybrid

Dr_AculaDr_Acula Posts: 5,484
edited 2014-04-26 07:54 in Propeller 1
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.
«13456789

Comments

  • kwinnkwinn Posts: 8,697
    edited 2013-07-05 21:24
    That's a very nice idea, and a nice board. I have fond memories of building my first computer (8080) from a kit and eventually upgrading to 16K of ram and two 5.25 inch floppies so I could run CPM. I learned an awful lot about computer hardware, software, and digital electronics from building that system. I would love to help out, but unfortunately am too busy to take on any more projects.

    I might be interested in purchasing one of the boards for future use though. Do you have a price for a bare board?
  • Cluso99Cluso99 Posts: 18,066
    edited 2013-07-05 21:32
    Very interesting Drac.

    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.
  • jmgjmg Posts: 15,140
    edited 2013-07-05 21:37
    Dr_Acula wrote: »
    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.

    With that chip count, this project is probably best to wait for the Prop 2 ?
  • SapiehaSapieha Posts: 2,964
    edited 2013-07-05 21:50
    Hi. Dr_Acula

    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

    Dr_Acula wrote: »
    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.
  • cavelambcavelamb Posts: 720
    edited 2013-07-06 00:03
    Or use the Z80 to run the touch screen directly?
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2013-07-06 06:50
    Dr_A

    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/
  • w4fejw4fej Posts: 264
    edited 2013-07-06 07:33
    Hey Doc:

    Have you ever run across a CP/M app called "WireMaster" ? It was a wire wrap CP/M program...

    Mike B. - North Carolina
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-07-06 19:59
    Thankyou for all the kind words and for indulging a 'retro-nerd' :)

    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?
  • Cluso99Cluso99 Posts: 18,066
    edited 2013-07-06 20:31
    Drac: You could always use an eZ80F93 (Mouser 692-EZ80F93AZ020EG $4.75 qty 1). It is 3v3 and 20MHz - only problem is LQFP100.
  • cavelambcavelamb Posts: 720
    edited 2013-07-06 22:37
    Dr. A,

    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&gt;
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2013-07-07 01:23
    Dr_A

    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 ...
  • w4fejw4fej Posts: 264
    edited 2013-07-07 07:03
    Hi Doc:

    "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.
  • TorTor Posts: 2,010
    edited 2013-07-09 07:42
    Drac, I love that project of yours. It's exactly the kind of projects I'm interested in. What made me aware of the Propeller in the first place was the Propeddle project which combines a 6502 with a Propeller.

    -Tor
  • GerritvGerritv Posts: 1
    edited 2013-07-28 13:36
    I have a copy (pdf) of the Wiremaster manual. And version 4.03 of the software.

    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.
  • blittledblittled Posts: 681
    edited 2013-07-29 19:14
    Dr. Acula, could you post the schematic? I have a stash of Z80's and a nice Breadboard/powersupply set up so I may try to breadboard it so I can modify that into a ZX81 system. Thanks!
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-07-29 23:01
    Hi blittled, the schematic is on post #1 (just under the board layout) but I have found a minor fault with that - it needs pullups on the Z80 control lines as need to keep the ram disabled when doing a busrq. I am still working through the software for that board - slowly getting it all working. Have most of the MCP23017 pins working now. I've also got a second version of the board that is being made now which replaces the second propeller with 74xx chips, so the Z80 controls the touchscreen more directly. That saved some pins for the inter prop comms, so I used those pins to talk to a SPI serial ram chip. I have an idea that it could run GCC in cached XMM mode on the propeller and BDS C on the Z80 and then you could have the whole system running the same language.

    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...
  • jmgjmg Posts: 15,140
    edited 2013-07-30 01:02
    Dr_Acula wrote: »
    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.

    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.
  • localrogerlocalroger Posts: 3,451
    edited 2013-07-30 16:26
    jmg wrote: »
    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
  • jmgjmg Posts: 15,140
    edited 2013-07-30 17:16
    localroger wrote: »

    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..
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2013-07-30 17:17
    Dr_Acula wrote: »
    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...

    ...reading this thread with great interest... go on... please....
  • cavelambcavelamb Posts: 720
    edited 2013-07-30 18:10
    jmg wrote: »
    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.


    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! ;) (And memory) (and other stuff too)

    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?
  • TorTor Posts: 2,010
    edited 2013-07-31 03:59
    A Z180 is not the same as a pure Z80.. a Z80 needs only 40 pins. I can't find Z80 as 3.3V though.

    -Tor
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2013-07-31 12:27
    I did stress-up a Prop to 4.2 Volts (with no problems) and dip a CMOS Z80 down to that, hoping that a 10MHz Z80 would at least do 4MHz or so. For the sake of all the other peripherals it would be better to pick one or the other rails.

    (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.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2013-07-31 15:03
    I did stress-up a Prop to 4.2 Volts (with no problems).

    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-07-31 20:47
    I've had a few PMs suggesting it may be possible to run a standard Z80 at 3.3V. I've not tried it but if anyone wants to do the experiment it would be very interesting to see what the results are.

    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
        crlf
    

    The 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 Workspace
    

    The 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.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2013-08-01 00:03
    Dr_A

    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?
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-08-04 07:15
    Not sure about using hub ram with a real Z80 - takes a lot of pins and propeller pins are precious - most are spoken for already!

    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,$00
    
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2013-08-04 14:51
    you know me, two chips is one too many ...

    I 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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-08-04 16:31
    Interesting thoughts Toby. Is this the website you were thinking about? http://www.shaels.net/index.php/mini80/mini80-general/119-mini8o-overview using a propeller with a Z80, running the Z80 at reduced voltage, bootstrapping without a rom, clocking the Z80 with a propeller. At least I am not alone with these crazy ideas :)
  • Heater.Heater. Posts: 21,230
    edited 2013-08-04 18:01
    Dr_A,

    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.
Sign In or Register to comment.