Z80 single board CPM for RC2014

928 views
Skip to first unread message

Mark T

unread,
Sep 13, 2018, 11:32:33 AM9/13/18
to RC2014-Z80
 
Just built up prototype of single board CPM using z80 and FT245. FT245 is going to imitate the 6850 ACIA. Prototype is using my FT245 board for RC2014 as a breakout board for surface mount USB and FT245 in SSOP but plan is to use a waveshare breakout board for this. The waveshare board just arrived the day after I finished wiring the prototype.

I'm aiming to fit the minimum number of components into a standard RC2014 outline that will run a variant of RomWBW. As with Bill Shen's ZZ80RC it has only 512K RAM with battery backup, so initially I'll build a 256K ROM variant with 128K ROM disk and 128K RAM disk and change this later to a pre-installed 256K RAM disk when I get a bit more confidence making changes in RomWBW.

Imitation of the 6850 ACIA is limited to data addressing and status register, no control register or interupt mode. Also including driving /WAIT if attempting to read from the FT245 when there is no data available, but not on attempt to write data to reduce the interface logic which is currently using a 74LS156 although I'm still considering change to 74LS141/5 or discrete logic. I reduced the address range from 0x80 to 0xBF of the RC2014 ACIA to 0x80 to 0x87 and mirrored at 0xA0 to 0xA7 (which hopefully supports RomWBW detection). This includes the RAM page write address at 0x82 and disable bootstrap mode with read/write (or IntAck) at 0x83.

In bootstrap mode every read made by the Z80 is taken from the FT245, but writes will still be directed to output ports and memory. Bootstrap instructions are sent to the Z80 to write a bootloader into high memory, then jump to the bootloader and exit bootstrap mode. The bootloader then loads the following binary into memory. The simple example attached was used to run BASIC, using Grant Searle's Basic for his FPGA z80 converted from intel hex to binary using HXD. This simple bootloader requires reset after the transfer with bootstrap mode disabled.

Using the FT245 for bootstrap does not require any delays in teraterm, so bootload is very fast, blink and you'll miss it. Obviously it will slow down as the image size increases but should still be no more than a few seconds.

I'm going to include connections for /RXF and /TXE to user pins, so interupts could be added later via a CTC. Also option to connect /PAGE_RESET to a user pin, so it could be reset by /NMI fetch from 0x0066 or /INTACK.

I'm waiting for MAX818 to control the battery backed RAM, so using an ADM694 for testing. This controls reset, but does not protect the RAM CE. The /MREQ at PFI input is just buffered to the RAM /CE at the PFI output.

I've only tested with Basic, so still haven't tested the RAM page control yet which simply uses a 74LS173 to select one of the sixteen pages from the 512K when A15 is low. When A15 is high the last 32K in the RAM is selected by the pull up resistors. This should be a good fit with the paging mechanism of hbios in RomWBW.

It seems my Z80 is only a 10MHz device labelled as 20MHz. Source was ebay so I guess that's to be expected. It runs at 11.0592MHz but not at 12MHz. Also possible its my wiring, 74HCT04 oscillator or bad circuit design.

Also planning to make a PIO board talk to this z80 board via the same connections as the FT245 breakout board, so included connections for /HALT and /WAIT to the no connection pins of the 20 pin header to allow these to be monitored by the PIO.

I've almost completed the pcb layout, standard RC2014 outline is really tight but looks like it should be possible. There might be no room for decent silkscreen labelling. I'm still considering if a barrel jack connector for power will be included by removing the pin1 cutout and I need to squeeze in an option link for reset connection to the 20 pin header. Also possibly need pull ups on /TXE and /RXF as these are tristated when the FT245 is reset or suspended.

Mark
WIN_20180911_182241.JPG
RC2014_Z80_Bootstrap_512K_proto.pdf
RC2014_Z80_Bootstrap.png
bootloader.asm
bootstrap.asm

Steve Cousins

unread,
Sep 13, 2018, 1:46:28 PM9/13/18
to RC2014-Z80
Looks an interesting project, Mark.

Tom Szolyga

unread,
Sep 13, 2018, 2:41:48 PM9/13/18
to RC2014-Z80
Interesting design.  One suggestion:  The 74HCT04 is probably too slow to run in a 12MHz Osc circuit.  Try replacing it with a 74AC04.  This part is easily 3 times faster and the "AC" vs "ACT" comes closer to meeting the Z80 clock high level spec.  (Check the datasheet, it is not exactly TTL level compatible).  You might find that your Z80 will run faster than 11MHz.

Tom

karlab

unread,
Sep 13, 2018, 2:54:08 PM9/13/18
to RC2014-Z80
Hi
I have had no problem running 74HCT04 at 20Mhz
Karl

Mark T

unread,
Sep 13, 2018, 3:09:42 PM9/13/18
to RC2014-Z80
Thanks Tom, I might try the 74AC04, it looks like its available at Sayal.

Maybe I should also try reducing the caps, 22pF might be too big for higher frequencies but all I had in my parts bin and Sayal price a pack of three caps for more than 74HCT.

Plan is to move to an oscillator module, either 8/14 pin dil size, but just wired up for the crystal so I could try different values.

Clock seemed to be running at 12MHz, but not at 20MHz, but that was just using a logic probe.

Mark

Mark T

unread,
Sep 13, 2018, 3:11:00 PM9/13/18
to RC2014-Z80
Hi Karlab,
What load capacitors are you using at 20MHz?

Mark

Karl Albert Brokstad

unread,
Sep 13, 2018, 3:44:36 PM9/13/18
to rc201...@googlegroups.com
22pF
karl



--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/348d392f-39a1-4c94-bce9-d5e677e24ec0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark T

unread,
Sep 17, 2018, 2:29:16 PM9/17/18
to RC2014-Z80
I was able to get RomWBW running on the prototype.

Created a new platform in RomWBW as it seemed the easiest way to modify the memory paging. Also forcing detection of the ACIA as I didn't implement a control register to simulate ACIA reset.

HBX_BNKSEL_INT:
    OUT    (MPGSEL),A        ; SET LOW 32K PAGE
    RET

ACIA_DETECT2:
    XOR    A
    RET

Set RAMSIZE and ROMSIZE to 256K to fit the 512K RAM and modified

BID_ROM0    .EQU    $00
BID_RAM0    .EQU    $88

I was having problems with the ROM disk creation using cpmcp, as it doesn't seem to allow me to change the diskdefs to support 128K disk image, so I created 128K blank image but continued using wbw_rom512 and manually check that I don't include too many files in the image. I'm guessing I need to rebuild cpmcp.exe to include new definitions. I stripped out a lot of the files to keep to a 128K file image.




romwbw.png

Alan Cox

unread,
Sep 17, 2018, 6:21:56 PM9/17/18
to rc201...@googlegroups.com
> I was having problems with the ROM disk creation using cpmcp, as it doesn't seem to allow me to change the diskdefs to support 128K disk image, so I created 128K blank image but continued using wbw_rom512 and manually check that I don't include too many files in the image. I'm guessing I need to rebuild cpmcp.exe to include new definitions. I stripped out a lot of the files to keep to a 128K file image.


cpmtools reads the file at runtime so I guess it's some other problem.

The design is interesting although having no serial int is painful for
things like nice BASIC program stops. For CP/M you also need to be
careful which bank you put things in and how it is arranged as you'll
need to keep a part of bank 0 for the bootstrap, and make sure it's
not the CP/M banks because CP/M will want to have its own jump at
address 0. Not a blocker just something to be aware of. The nice thing
is a classic disk loaded CP/M is going to fit in a 16K bank with
loader so it'll reboot real fast

Alan

Mark T

unread,
Sep 17, 2018, 7:10:38 PM9/17/18
to RC2014-Z80

I might have been changing the wrong diskdefs file, I just found one in source/hbios. I'll try again later.

I just modified it to keep hbios in page 0 instead of copying to ram, used the ram page that was freed to expand the ram disk from 128K to 160K. Still pretty much a learning excercise at the moment but seems strange that RomWBW uses RAM and ROM size to calculate disk sizes at runtime, I changed it to calculate at assembly to make it easier to determine correct RAM and ROM disk size as I change the other bank IDs.

I connected /RXF and /TXE to user pins so I could connect to CTC for interupts later. I don't think I can fit a control register and logic to simulate 6850 interupts but could possibly fit schottky diodes from /RXF and /TXE to /INT. I didn't check the FT245 spec yet to see if logic low is low enough to meet 0.8v threshold with diode drop included.

Also included option to reset memory page from user pin.

Downloading 256K bytes is about 3 seconds, so similar to baud rate of 874,000 through serial if including start and stop bits.

Mark

Mark T

unread,
Sep 17, 2018, 7:31:50 PM9/17/18
to RC2014-Z80

Thought I'd add that I'm only running the Z80 at 3.57MHz for now, so thats possibly limiting the download speed.

Bill Shen

unread,
Sep 17, 2018, 7:31:54 PM9/17/18
to RC2014-Z80
Mark,
Are you having problem with BLS of 1024?  While working on CP/M BIOS for my ZZ80RC which only has 512K of memory, I want to use the memory more efficiently so I use a BLS of 1024, but I can't get cpmtools to generate the correct image with BLS of 1024.  ( I generate an image using cpmcp and then extract files using cpmcp from the image and the files extracted are corrupted)  So I changed the BLS to 2048 and everything is working fine.
  Bill

Mark T

unread,
Sep 17, 2018, 7:45:41 PM9/17/18
to RC2014-Z80
Thanks Bill,
I didn't change the block size, just copied the rom_wbw512 to rom_wbw256 in the diskdefs file and changed from 12 tracks to 4, but it kept telling me that rom_wbw256 was invalid.

Fairly sure I was changing the wrong file, didn't see the one in hbios folder.

I'll watch out for the blocksize issue, if I get to that level of optimisations.

Mark

Wayne Warthen

unread,
Sep 18, 2018, 1:10:00 PM9/18/18
to RC2014-Z80
Nice to see RomWBW adapted to this platform.  :-)

On Monday, September 17, 2018 at 4:10:38 PM UTC-7, Mark T wrote:

I just modified it to keep hbios in page 0 instead of copying to ram, used the ram page that was freed to expand the ram disk from 128K to 160K. Still pretty much a learning excercise at the moment but seems strange that RomWBW uses RAM and ROM size to calculate disk sizes at runtime, I changed it to calculate at assembly to make it easier to determine correct RAM and ROM disk size as I change the other bank IDs.

Runtime calculation of disk sizes is prepatory to allowing RAM size of system to be probed and sized dynamically at startup.  Some platforms supported by RomWBW can be configured with different RAM capacities.  The code to support this is a work in progress.  For your purposes, it makes sense to preconfigure the RAM size at assembly time.

-Wayne

Mark T

unread,
Sep 19, 2018, 3:09:44 PM9/19/18
to RC2014-Z80
Changing the diskdefs file in the HBIOS source directory solved the problem with creating a different size Romdisk.

I removed two of the duplicate copies of OSIMG from the rom image, also removed BID_AUX as it didn't seem to be needed. So I now have 16 x 32K banks.
Bank 0 - HBIOS - downloaded to RAM - not copied to a separate page
Bank 1 - OSIMG - downloaded to RAM
Bank 2 to 10 - 256K Romdisk downloaded to RAM
Band 11 to 13 - 128K Ramdisk
Bank 14 - TPA
Bank 15 - Common memory

On a minimum system it might just be possible to combine HBIOS and OSIMG into a single page, but I think its best to keep the flexibility of adding new devices into HBIOS.

I tried modifying MD_CAP to return the size of the ram and rom disks. After much headscratching about why the bootscreen showed 256K Romdisk and 128K Ramdisk, while Cpm only saw a 192K Romdisk and 64K Ramdisk, I discovered this doesn't work correctly as CBIOS is still using HCB_RAMBANKS and HCB_ROMBANKS with a fixed offset of 4. Rather than modify CBIOS I changed the way I set HCB_RAMBANKS and HCB_ROMBANKS in HBIOS to include the fixed offset of 4. Hopefully this doesn't break anything else.

I also needed to reset the values of CIO_CNT, DIO_CNT and VDA_CNT to zero, as these are normally initialised by the copy from rom to ram. Without initialisation of these values every press of the reset button added a duplicate set of devices to the device list.

I'm creating a 320K rom image, then concatenating with a bootstrap loader to load this into 10 blocks of the 512K ram, and then start executing from 0 in bank 0.

Bootstrap loader is created manually, so I'm working on automating this with a build script.
Mark

Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted

Mark T

unread,
Oct 7, 2018, 12:28:45 PM10/7/18
to RC2014-Z80

Attaching hbios.zip which is a copy of the hbios folder within RomWBW containing the changes I made to build a 384K bootstrap image for my single board Cpm prototype. After unzipping RomWBD to your local drive, verify that RomWBW builds correctly, then replace the hbios folder with the attached.

You'll also need to change the extensions on cmd and ps1 files in the folders, I added txt extension to try and stop the attachment of zip file from being blocked.

It may be a usefull reference for fir anyone else experimenting with ROMWBW in a 512K RAM only system such as the ZZ80RC by Bill.

I created a new platform name PLT_MT so searching through the files for this should identify where I made my changes.

Mark
HBIOS-copy.zip

Mark T

unread,
Dec 22, 2018, 10:09:32 PM12/22/18
to RC2014-Z80

I finally built up one of the boards and confirmed its working with the same 384K binary image that was working on the prototype.

The board is a bit crowded, topside silkscreen is almost impossible to read.


RC2014_Z80_Bootstrap_v1.pdf
WIN_20181222_215212 - Copy.JPG

Bill Shen

unread,
Dec 23, 2018, 9:22:23 AM12/23/18
to RC2014-Z80
Very interesting design.  How fast were you able to run the Z80?
  Bill

Mark T

unread,
Dec 23, 2018, 12:32:25 PM12/23/18
to RC2014-Z80
Only running at 8MHz to verify the pcb for now. Prototype was running at a maximum of 11MHz but I was suspecting the Z80s sourced from ebay. I recently received a couple more from utsource, together with a batch of other interesting ICs, that are supposed to be 20MHz so I'll try again when I have chance to build up a crystal oscillator as I have quite a wide range of crystals but only the 8MHz module.

Mark

Mark T

unread,
Dec 31, 2018, 2:58:20 PM12/31/18
to RC2014-Z80

I tried to run at higher clock frequency again. Same as the prototype it runs at 11.0592MHz but not at 12MHz.

Limit seems to be due to the 74LS156 propagation delay of 51ns during M1 fetch from memory, worst case for the Z80 as the read cycle is only 1.5 clock cycles, minus 40ns for /RD active and 12ns for data setup.

AS6C4008-55 access time is 30ns from /OE or 55ns from /CE.

Estimated maximum clock frequency, 3 / (2 * (40ns + 51ns + 30ns +12ns)) = 11.278MHz

If the propagation of the 74ls156 could be reduced the limit would be, 3 / (2 * (40ns +9ns +55ns +12ns)) = 12.93MHz so not a whole lot better.

Anybody know if there is a faster SRAM available in 512K x 8?

Another option might be to use /M1 to start the fetch half a clock cycle earlier but that needs extra gates and probably loses as much as it gains.

Mark

Bill Shen

unread,
Dec 31, 2018, 4:50:35 PM12/31/18
to RC2014-Z80
Hmm, that doesn't feel right.  The worst case delay is for process, voltage & temperature extremes.  In room temperature with nominal 5V the delay should be significantly lower. 

Most parts are designed to be functional from 4.5V to 5.5V, so you can raise the voltage to 5.5V which speeds up both CMOS & TTL parts.   But if the problem is due to noise, then raise voltage will actually create more noise and cause more problems.  CMOS speeds up at low temperature so a 3/8" bolt from freezer to top of the RAM is a quick way of cooling down the RAM.  TTL, on the other hand, slows down at lower temperature.  In a mixed logic family design, CMOS and TTL parts may temperature compensate each others.

Have you tried the industrial temperature version of AS6C4008?  Its access time is 55nS from -40 to +85C, so access time in room temperature is faster than the equivalent commercial part..
  Bill

Mark T

unread,
Dec 31, 2018, 9:37:57 PM12/31/18
to RC2014-Z80
I think I spotted the problem, I'm still using an ADM694 for the reset and memory protect instead of the MAX818. They have similar pinout but instead of the CE protect of the MAX818 the ADM694 has a Power fail detect and I just left this to buffer MREQ to RAM CS. I misread the spec for the propagation delay, the 9ns is for the ADM691/3/5 which has CE gate in a 14 pin DIP. The propagation delay on the power fail comparator looks to be 50-200ns.

I was having some problem finding the MAX818 at a reasonable price in an 8 pin dip, so I got a few in SOIC8 but didn't get around to wiring one in yet.

Mark

Mark T

unread,
Jan 2, 2019, 1:32:40 PM1/2/19
to RC2014-Z80

I wired an SOIC MAX818 deadbug style onto the back of the board in place of the ADM694 and again it runs at 11.0592MHz but not at 12MHz.

I just found that 74ALS156 is available, but digikey has minimum order of 200. Its available in one off quantities from Farnell.

I'll probably try discrete logic first to confirm if that improves the max clock frequency.

Mark

Mark T

unread,
Jan 3, 2019, 1:10:38 PM1/3/19
to RC2014-Z80
I tried adding a 74LS125 input connected to BSMODE, /en from z80 read, output driving /RD. This is as close as I could get to an open collector OR gate,and also why I used the 74LS156. When not in bootstrap mode the 74LS125 acts as open collector buffer from z80 read to /RD on the ram. It does mean that it drives /RD high when in bootstrap mode but there are no other outputs trying to pull /RD low at this time.

Again it runs at 11.0592MHz but not at 12MHz.

Then I tried Bill's suggestion, which was much easier and should have been my first step. I was measuring 4.92v on the 5v from the USB power supply, swapped it to a different USB supply that measured 5.32v. Just using a cheap pocket DVM so this is not calibrated, but OK for a relative measurement.

Now it runs at 12MHz both with or without the 74LS125.

I need to get some more crystals to see how fast it will run now. Next frequency I have in stock is 20MHz.

Mark

Bill Shen

unread,
Jan 3, 2019, 10:35:09 PM1/3/19
to RC2014-Z80
Perhaps the first USB power supply is not well regulated and has large ripple voltage on top of the 4.92V that is almost tripping the voltage supervisor even at 11MHz.  Moving it from 11 MHz to 12 MHz pushed it over the edge.  The 2nd USB supply has more voltage margin.  I'd try the 20MHz oscillator with the 2nd USB supply.
  Bill

Tom Szolyga

unread,
Jan 4, 2019, 2:42:50 PM1/4/19
to RC2014-Z80
Hi Mark,

I have had similar problems with the 5V output level from various USB power supplies.  I decided to switch to using a 5V power module with a barrel connector.  They are generally rated for 5V @ 2.5A.  They have eliminated "flakey" problems with my systems.

Tom

Shaun ONeil

unread,
Jan 4, 2019, 9:42:59 PM1/4/19
to RC2014-Z80
I've observed a lot of problems with ubiquitous usb chargers, usually with the raspberry pi.  It seems that "supplies" and "chargers" aren't the same thing.  In a great many phone chargers I've found the voltage lags at higher current draws. For the devices they're intended for, this isn't a problem because the charging controller on the device limits the voltage anyway - so as long as the voltage is above requirement (which isn't 5V, it usually tops at 4.2V), the controller cares more about watts than volts.

So for a power supply, if it claims 5V @ 2.5A, you expect 5V up to a maximum 2.5A.  For a charger, a claim of 5V @ 2.5A will charge a phone at 12.5W - but when pushed, you may find it's producing 4.5V @ 2.8A.  My phone won't notice, my Pi will.

It's a shame that today's defacto 5V "power supply" was never intended as such.

Mark T

unread,
Jan 7, 2019, 3:23:45 PM1/7/19
to RC2014-Z80

I was able to get some more crystals from a local store, unable to get it running at 14.195MHz, but runs OK at 12MHz.

Swapped out the second USB charger for an old homebuilt supply from 20 years ago, voltage is measuring a bit high at 5.55v, but that could be my uncalibrated DVM, or because I don't have enough load on the supply. Also added extra 2.2uF caps on the SRAM and Z80 supply pins.

Disconnected the 74LS156 from the /RD and replaced with a 74F32 OR gate from BSMODE and /ZRD.

Instead of using /MREQ from the Z80 to the CE input of the MAX818, added a 74AHC1G00 to invert /IORQ to generate the CE input. This should give an earlier CE to the SRAM.

Next step is to try adding 74AHCT1G08 prior to the 74F32 to allow the OE to be activated at the start of M1 which is about half a clock cycle ahead of the RD, but not confident this is going to help.

Mark



Mark T

unread,
Jan 8, 2019, 3:27:52 PM1/8/19
to RC2014-Z80

Added two of 74AHC1G00 to generate OE to the SRAM as early as possible, still only able to run at 12MHz but not at 14.195MHz.

Tried with four "Z84C0020PEC", two from ebay and two from UTSOURCE. I was hoping for better results from UTSOURCE but these seemed to be in worse condition than the ones from ebay, the pins seem much softer than any other 40 pin DIP ICs that I've used.

Attached schematic is the latest attempt. I don't think there is anything else to try other than adding wait states.

Mark

RC2014_Z80_Bootstrap_v1.pdf
Reply all
Reply to author
Forward
0 new messages