ZRC, Z80/RAM/CPLD, yet another minimal CP/M-ready, Z80 SBC

[Bill Shen]

ZRC is my latest idea regarding minimal CP/M-ready Z80 SBC.  It came out of the "shark jumping" experience, https://groups.google.com/forum/#!topic/retro-comp/4knnVMlhCxg  that with high speed serial port and automated load script, CF disk can be eliminated.  This assumes a large RAM to hold CP/M files and RAMdisk.  Thus the idea of DRAM controller on CPLD driving an inexpensive 2meg x 8 DRAM.  ROMWBW can be serially loaded into DRAM, RAMdisk is now larger because of larger memory.  6850 serial port is emulated in CPLD, so it should be able to run to 230400 baud.

Diskless approach maybe interesting, but eventually a CF disk is desirable to load all files quickly.  So I have an optional CF disk interface.

I expect to have spare logic on CPLD to experiment with other I/O features.
  Bill

[Greg Holdren]

Nice!

You think there is enough room to implement a SPI master controller after all the required logic?

Greg

[Mark T]

CPLD already has uart, dram controller and the bootstrap code so it must be almost fully used.

Maybe it could bitbang spi?

I guess micro sd card isn’t a possible replacement for CF as the bootstrap required would be too big.

Mark

[Bill Shen]

bit bang SPI is the default, maybe there are enough spare for shift register.  SPI SD card is too hard to do as a bootstrap device, but it can be the 2nd drive with help of software and SPI interface.
  Bill

[Greg Holdren]

I was thinking not so much for a SD card but for other SPI base peripherals. Ethernet to mount a disk (net boot maybe), CAN for control, shift regs to make a 3D LED cube etc. or whatever tickles someone.

Greg

[Alan Cox]

On Sunday, 7 June 2020 09:25:07 UTC+1, Greg Holdren wrote:

I was thinking not so much for a SD card but for other SPI base peripherals. Ethernet to mount a disk (net boot maybe), CAN for control, shift regs to make a 3D LED cube etc. or whatever tickles someone.

For boot you could probably drive an SPI EEROM from the minimal boot and use that to load a boot loader from SD card.

Alan

[Bill Shen]

ZRC is a bit of disappointment.  Somehow I got into my head that PLCC44 Z80 has the same pin assignments as DIP40 Z80 and lay out the board accordingly.  So that didn't work, but fortunately ZRC does have a modified RC2014 bus where most Z80 signals are brought out to the bus.  So I removed the PLCC Z80 and wired in the missing A8-A15 and used a Z80 CPU board to replace the on-board Z80.  Able to boot up and run memory diagnostic on DRAM successfully.  Next step is get a small serial loader to copy ROMWBW image from the serial port into DRAM and boot.
  Bill

[Bill Shen]

Rev1.1 of ZRC.  Fixed the problem with pin assignment of Z80 PLCC.  Have a serial bootstrap loader working loading a monitor program.  Now I'm working on getting a modified ROMWBW running on this hardware.  It has 2 meg of RAM, so I'm not sure what to do with extra 1Meg of memory.

One problem with this design is the DRAM is too slow to support Z80 at 22MHz.  I'm running it at 11MHz, hopefully it can run to 14.7MHz.

  Bill

[Bill Shen]

ZRC is running fine at 14.7MHz.  I have a RAM diagnostic testing & passing all 2 meg of memory.  I also have ported CPM2.2 and successfully ran zexall.com.  So now I am thinking about how to get ROMWBW to run on this hardware.  My thought is customizing the ROMWBW to work with my memory bank register which controls 64 banks of 32K RAM bank.  ROMWBW then generates the customized 512K flash image which I'll use BIN2HEX to convert it to Intel Hex file with extended segment addressing.  I'll modify my Hex loader to load the 512K Intel hex file into DRAM.  Once it is all loaded, I should be able to transfer control to 0x0 and ROMWBW should boot as if it is running out of EPROM at 0x0.  Frankly, I'll be amazed if all these steps worked as I've envisioned.
  Bill

[Bill Shen]

Thanks to Wayne Warthen, ROMWBW is now ported to ZRC.

The more I played with ZRC, the less attractive the serial bootstrap feature became.  Even with serial clock raised to 230K, it still takes 50+ seconds to load ROMWBW.  ZRC really works the best with the optional CF disk installed which makes it like a ZRCC (Z80+RAM+CPLD+CF), but with ROMWBW capability.  The drawback is it can only run at 14.7MHz instead of 22MHz because of the slow DRAM.

To store ROMWBW in CF drive, I reduced the size of first 8-meg slice by 512K so ROMWBW image is stored between the top of first slice and the directory of the 2nd slice.  I added a command to ZRC monitor that first load ROMWBW image in first 512K of DRAM, and then copy the image to CF.  With another ZRC monitor command, the ROMWBW can be recall from CF disk into memory and execute.    I'm still deciding whether I should bypass the ZRC Monitor, so ROMWBW will boot automatically after a reset or power cycle.  I probably will do that once the hardware and software have stabilized.

  Bill

[Bill Shen]

I don't think the idea of reducing the size of first slice by 512K and storing ROMWBW image in the freed space is a good idea because disk definition for all slices are the same, I can't easily change the capacity of the first slice without changing capacity of all slices.

What I propose to do instead is creating a 512K image file as first file of the first slice.  After the first slice is initialized with CLRDIR.COM, a file (named ROMWBW.IMG) is created with xmodem transfer of the ROMWBW image.  ROMWBW.IMG will be the first file of the slice so it is located in known location.  I also counting on the ROMWBW image being stored in CF drive in consecutive sectors, so then I can just copy it into memory as one contiguous 512K image. 

I like to know whether there is a better way of storing ROMWBW image in CF.

  Bill

[Richard Deane]

Are you using the old ROMWBW disk format (as in release version), or the newer 1024 dir format in the dev tree? This newer format has a partition header prepended on the concatenated slices so you may be able to have your boot image stored in a different partition or reserved area? Someone who knows more about partitions and headers may be able to provide more specifics. (See Wayne's recent comments in another thread for some details of the new format.)

Richard

[Bill Shen]

I'm currently using the 512 directory version of ROMWBW.  After ROMWBW.IMG is created using xmodem, this is what's on track 01, sector 00 of CF disk.  the data are stored on contiguous sector, starting from block 4; each block is 4K

read CF disk track:0x01 sector:0x00
+0000 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 01 00 00 80  .ROMWBW  IMG....
+0010 : 04 00 05 00 06 00 07 00 08 00 09 00 0A 00 0B 00  ................
+0020 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 03 00 00 80  .ROMWBW  IMG....
+0030 : 0C 00 0D 00 0E 00 0F 00 10 00 11 00 12 00 13 00  ................
+0040 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 05 00 00 80  .ROMWBW  IMG....
+0050 : 14 00 15 00 16 00 17 00 18 00 19 00 1A 00 1B 00  ................
+0060 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 07 00 00 80  .ROMWBW  IMG....
+0070 : 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 23 00  ........ .!.".#.
+0080 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 09 00 00 80  .ROMWBW  IMG....
+0090 : 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 2B 00  $.%.&.'.(.).*.+.
+00A0 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 0B 00 00 80  .ROMWBW  IMG....
+00B0 : 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 33 00  ,.-.../.0.1.2.3.
+00C0 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 0D 00 00 80  .ROMWBW  IMG....
+00D0 : 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3B 00  4.5.6.7.8.9.:.;.
+00E0 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 0F 00 00 80  .ROMWBW  IMG....
+00F0 : 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 43 00  <.=.>.?.@.A.B.C.
+0100 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 11 00 00 80  .ROMWBW  IMG....
+0110 : 44 00 45 00 46 00 47 00 48 00 49 00 4A 00 4B 00  D.E.F.G.H.I.J.K.
+0120 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 13 00 00 80  .ROMWBW  IMG....
+0130 : 4C 00 4D 00 4E 00 4F 00 50 00 51 00 52 00 53 00  L.M.N.O.P.Q.R.S.
+0140 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 15 00 00 80  .ROMWBW  IMG....
+0150 : 54 00 55 00 56 00 57 00 58 00 59 00 5A 00 5B 00  T.U.V.W.X.Y.Z.[.
+0160 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 17 00 00 80  .ROMWBW  IMG....
+0170 : 5C 00 5D 00 5E 00 5F 00 60 00 61 00 62 00 63 00  \.].^._.`.a.b.c.
+0180 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 19 00 00 80  .ROMWBW  IMG....
+0190 : 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00  d.e.f.g.h.i.j.k.
+01A0 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 1B 00 00 80  .ROMWBW  IMG....
+01B0 : 6C 00 6D 00 6E 00 6F 00 70 00 71 00 72 00 73 00  l.m.n.o.p.q.r.s.
+01C0 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 1D 00 00 80  .ROMWBW  IMG....
+01D0 : 74 00 75 00 76 00 77 00 78 00 79 00 7A 00 7B 00  t.u.v.w.x.y.z.{.
+01E0 : 00 52 4F 4D 57 42 57 20 20 49 4D 47 1F 00 00 80  .ROMWBW  IMG....
+01F0 : 7C 00 7D 00 7E 00 7F 00 80 00 81 00 82 00 83 00  |.}.~...........

In block 4  (track 1, sector 0x20), I can find the beginning of ROMWBW.IMG

>read CF disk track:0x01 sector:0x20
+0000 : C3 24 05 70 00 FF FF FF C3 F0 FF FF FF FF FF FF  .$.p............
+0010 : C9 FF FF FF FF FF FF FF C9 FF FF FF FF FF FF FF  ................
+0020 : C9 FF FF FF FF FF FF FF C9 FF FF FF FF FF FF FF  ................
+0030 : C9 FF FF FF FF FF FF FF C3 00 FF FF FF FF FF FF  ................
+0040 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
+0050 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
+0060 : FF FF FF FF FF FF ED 45 FF FF FF FF FF FF FF FF  .......E........
+0070 : 76 B5 01 07 80 00 A1 00 A5 00 00 00 00 00 00 00  v...............
+0080 : 52 4F 4D 57 42 57 20 76 33 2E 31 2E 31 2D 70 72  ROMWBW v3.1.1-pr
+0090 : 65 2E 32 31 2C 20 32 30 32 30 2D 30 37 2D 30 33  e.21, 2020-07-03
+00A0 : 00 57 42 57 00 52 4F 4D 57 42 57 20 76 33 2E 31  .WBW.ROMWBW v3.1
+00B0 : 2E 31 2D 70 72 65 2E 32 31 2C 20 43 6F 70 79 72  .1-pre.21, Copyr
+00C0 : 69 67 68 74 20 28 43 29 20 32 30 32 30 2C 20 57  ight (C) 2020, W
+00D0 : 61 79 6E 65 20 57 61 72 74 68 65 6E 2C 20 47 4E  ayne Warthen, GN
+00E0 : 55 20 47 50 4C 20 76 33 00 FF FF FF FF FF FF FF  U GPL v3........
+00F0 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
+0100 : C3 24 05 57 A8 31 10 07 07 CC 1C 10 10 00 00 00  .$.W.1..........
+0110 : 00 FF FF 04 00 00 00 00 00 00 00 00 00 00 00 00  ................
+0120 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+0130 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+0140 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+0150 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+0160 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+0170 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+0180 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+0190 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+01A0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+01B0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+01C0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+01D0 : 00 00 00 00 00 00 00 00 8F 8E 8D 8C 80 8B 04 0F  ................
+01E0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+01F0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

Copy it into RAM starting from 0x0 and then jump to 0x0, I do see ROMWBW executing.

boot CP/M
1--User Apps,
2--CP/M2.2:
3--CP/M3:
4--ROMWBW: 5 press Return to execute command
hZ

RomWBW HBIOS v3.1.1-pre.21, 2020-07-03

RC2014 Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1
512KB ROM, 512KB RAM

ACIA0: IO=0x80 ACIA MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 NOT PRESENT
MD: UNITS=2 ROMDISK=384KB RAMDISK=384KB
IDE: IO=0x10 MODE=RC
IDE0: 8-BIT LBA BLOCKS=0x0001E900 SIZE=61MB
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ACIA0:      RS-232            115200,8,N,1
Disk 0      MD1:        RAM Disk          384KB,LBA
Disk 1      MD0:        ROM Disk          384KB,LBA
Disk 2      IDE0:       CompactFlash      61MB,LBA
Disk 3      IDE1:       Hard Disk         --


RC2014 Boot Loader

Boot [H=Help]:

I'll check what 1024 directory version can offer.  Reserving 512K space on CF disk as a file does work, but it is making assumption of location of the file on disk and the file being contiguous.  I'm not sure how portable that are
  Bill

[Bill Shen]

This is a 15-second video of ZRC booting into ROMWBW.  The CF disk already have ZRC monitor and ROMWBW image installed.
The first 4 seconds of the video is ZRC powered up.  It counts down from 9 to 0 waiting for serial bootstrap input.  If serial bootstrap is not received at the end of the countdown, it then loads and runs the CF bootstrap code stored in master boot record.  The bootstrap, in turn, loads and run ZRC Monitor located in track 0, sector F8-FD of CF disk.

At the 6 second mark, a monitor command 'b4' is issued to boot up ROMWBW.  This command loads the ROMWBW image that's stored in first file of the first slice into lower 512K of DRAM and runs it.  This is the standard 512K ROM with 512 directory entries.  Directory of drive C shows the file "ROMWBW.IMG" which is the 512K ROMWBW image.

  Bill

[Wayne Warthen]

Nice video Bill.

Regarding the storage location for the image.  It may be worth playing with the new disk format.  Since that allows the CP/M slices to be stored in a partition that can be located anywhere, you could just create a custom "prefix" file that contains a custom partition containing the image to load.  Or you could just make the RomWBW partition start at least 512K beyond the start of the disk and put the image at the start of the disk.  Of course, all of this depends on the new disk format and would not work for anyone using the old format.  Your current approach is more generic.

-Wayne

[Bill Shen]

I'm revisiting ZRC, the ROMWBW-ready SBC with 2meg DRAM.  I made a minor pcb correction to eliminate a bodge jumper for serial port handshake.  Upgrade the ROMWBW to the latest, ver 3.1.1 pre.41.  The CPLD is a EPM7128S so it should have room for an I2C controller, SPI controller and WS2812B RGB driver.  I populated the WS2812B RGB LED (the 8 LEDs at top row of the board), the 4-pin I2C header above the RC2014 expansion connector and I plan to port an simplified SPI controller.  That should fill up the CPLD quite full.  The RC2014 expansion bus should be able to drive a VGARC video board or other video boards the RC2014 community is developing, so a 2-board standalone Z80 computer should be achievable. 
  Bill

[Douglas Miller]

I've been pondering an idea lately, regarding a "minimal computer". It should be possible to have a system with CPU, RAM, ROM, and one serial port. The ROM could contain CP/NOS (a variation of CP/NET with no local disks) and use the console serial port as the network interface. I'm envisioning a server program on the host that allows one to initially interact with the console directly, enough to boot CP/NOS at which point console I/O switches to using CP/NET packets. After switching to CP/NET, the server program provides console access via that method.

[Bill Shen]

You can build a simplistic clients out of Z280, utilizing its serial bootstrap mode:

Z280 has a serial-bootstrap mode where it waits for 256 bytes of serial data to be loaded in 0x0-0xFF and start execution once the 256th serial data is received.  So you can have an array of clients all waiting for the 256-byte bootstrap broadcast from the master processor.  Once the clients have received the bootstrap and running, master can send client-specific program for them to execute.  Two of Z280's 4 DMA channels can be assigned to UART transmit and receive, so the serial port can operate with low processor overhead.  By sharing system mass storage and clock, such simplistic client can be as simple as Z280+RAM.  Z280 has its own MMU, so the RAM can be 512K (or even larger) without external banking logic.
  Bill

[Bill Shen]

Alternatively, Z80 with serial bootstrap function implemented in CPLD can do the same thing as the previous post. ZRC as existed today probably can serve the "minimal computer" function you've envisioned.
  Bill

On Monday, February 8, 2021 at 7:47:26 AM UTC-7 Douglas Miller wrote:

[Douglas Miller]

Yes, the "free UART" of the Z180/Z280 is attractive. The serial bootstrap feature is also intriguing, although I was envisioning a serial connection to a "host PC" and would worry about possible garbage on the serial line (as various components power off/on or RESET) interfering with the boot image. Still, interesting possibilities.

I was thinking of a more "faithful" retro machine, but getting a minimal chip-count (and PCB real estate) is a valid goal as well. I was thinking of using my existing emulations to mock-up a virtual machine to develop the software. The actual details of the hardware can change/adapt pretty easily.

[Bill Shen]

Z280's serial bootstrap requires odd parity and has a primitive error detection that asserts transmit line (BREAK) when error is received.   In term of board real estate, the economical 100mm X 100mm 2-layer pc board can easily accommodate the necessary components.  50mm X 100mm board (2 boards per 100mm x 100mm panel) is even possible.  A Zx80 client with $10 worth of parts & pc board is not unrealistic.

I probably have hardware on hand that's "close enough" or can be easily modified to fit your concept.  Start a new thread, let's hash out the concept and work on some prototypes!
  Bill

[Bill Shen]

This is the schematic for WS2812B driver.  Each WS2812B needs 24 pulses, each pulse is nominally 1.2 uS where '1' is 67% high and '0' is 33% high.  Another word, '1' is represented by a pulse of 800nS high and 400nS low and '0' is represented by a pulse of 400nS high and 800nS low.  8 pulses per color of green, red, blue, in that order.  With clock of 14.7MHz, this actually workout just right with two Z80 instructions per pulse.  17 clocks to execute each pair because a wait state is inserted for instruction fetch.  So that's 68nS x 17= 1.16uS, which is close enough.

OUT (WS2812),A        ;most significant bit first
RLA                ;next bit
OUT (WS2812),A       
RLA
OUT (WS2812),A
RLA              
...8 pairs of instruction per color...

Anyway, the proof is having an actual working system as shown in the picture.

[Bill Shen]

Bit bang I2C is now implemented on ZRC.  Picture shows 128x64 OLED display driven by I2C.  The bit-bang I2C logic in CPLD is quite simple, basically an I/O decode (address=0x1D) and 2 flip flops.  There are some complication associated with reading SDA line to data bus D[0], but nothing CPLD can't solve.

Current CPLD design also has a 8-bit general purpose outputs which may be traded for a SPI function or something else.  The design is 99% full, so there are not much room for anything too sophisticated.  Instead of working on ZRC's CPLD, it may be more instructive trying to integrate it with other RC2014 peripherals.  ZRC already has 2 meg of memory, so no need for more memory; its clock is 14.7MHz so the list of compatible I/O is short.  A dual or quad serial board, video board, and sound board are boards I like to try out.

[Bill Shen]

I found out there is RAMSIZE parameter in ROMWBW configuration that can be set for different values than the default 512.  ZRC has 2 meg of RAM but no ROM.  The first 512K of the RAM is operating like ROM, so RAMSIZE should be set to 1536 (1.5meg)?

I did set RAMSIZE in cfg_rcz80.asm to 1536; ran "buildshared", "buildrom rcz80 zrc" and load the resulting ROM file into ZRC and boot.  It seems to run OK and I able to PIP 1.5meg of files to drive A: with verify.  However, the boot message shows "ROM VERIFY: 80 FAIL".  This message was not there prior to changing RAMSIZE (should point out that previous build was from ROMWBW released a year earlier).  What does ROM VERIFY FAIL means?
  Bill

[Wayne Warthen]

On Saturday, February 19, 2022 at 8:51:05 AM UTC-8 Bill Shen wrote:

I found out there is RAMSIZE parameter in ROMWBW configuration that can be set for different values than the default 512.  ZRC has 2 meg of RAM but no ROM.  The first 512K of the RAM is operating like ROM, so RAMSIZE should be set to 1536 (1.5meg)?

Yes, 1536 would be correct in this case.

 

I did set RAMSIZE in cfg_rcz80.asm to 1536; ran "buildshared", "buildrom rcz80 zrc" and load the resulting ROM file into ZRC and boot.  It seems to run OK and I able to PIP 1.5meg of files to drive A: with verify.  However, the boot message shows "ROM VERIFY: 80 FAIL".  This message was not there prior to changing RAMSIZE (should point out that previous build was from ROMWBW released a year earlier).  What does ROM VERIFY FAIL means?

Before I go into detail, this "FAIL" is benign in your case.  I should be able to fix it and will work on that today.

ROM VERIFY is a relatively new thing in RomWBW.  The idea is to verify that the contents of the critical banks of ROM have not become corrupted either during programming or over time.  This may seem unlikely, but I have fielded quite a few issues that turned out to be exactly this.

As early as possible in the boot process RomWBW now runs a simple checksum against the first 4 banks of ROM.  During the RomWBW build process, the last byte of each bank is set to a complimentary value that causes a checksum of the entire bank to be zero (if all bytes are correct on the ROM).  So, you should normally see a message like this:

ROM VERIFY 00 00 00 00 PASS

This indicates that 4 banks were checked and the checksum was "00" in all cases, so it passed.  In your case it is showing that the first bank (HBIOS) was not 00, so the test failed at that point.  The reason you are seeing this error is my fault.  I have not been careful to avoid changing bytes in the early boot process before moving the HBIOS to RAM.  For most system, this is fine because you can't change a real ROM byte.  But in the case of ZRC, the "ROM" is in fact "RAM".  So, I need to review what might be causing the changes and fix them.

Thanks,

Wayne

[Wayne Warthen]

On Sunday, February 20, 2022 at 10:27:09 AM UTC-8 Wayne Warthen wrote:

I did set RAMSIZE in cfg_rcz80.asm to 1536; ran "buildshared", "buildrom rcz80 zrc" and load the resulting ROM file into ZRC and boot.  It seems to run OK and I able to PIP 1.5meg of files to drive A: with verify.  However, the boot message shows "ROM VERIFY: 80 FAIL".  This message was not there prior to changing RAMSIZE (should point out that previous build was from ROMWBW released a year earlier).  What does ROM VERIFY FAIL means?

This indicates that 4 banks were checked and the checksum was "00" in all cases, so it passed.  In your case it is showing that the first bank (HBIOS) was not 00, so the test failed at that point.  The reason you are seeing this error is my fault.  I have not been careful to avoid changing bytes in the early boot process before moving the HBIOS to RAM.  For most system, this is fine because you can't change a real ROM byte.  But in the case of ZRC, the "ROM" is in fact "RAM".  So, I need to review what might be causing the changes and fix them.

Bill, when convenient, can you try the latest version of RomWBW?  Based on your screen shot, you are using v3.1.1-pre.148.  Using the latest v3.1.1-pre.158, the ROM VERIFY is PASSing on my ZRC.  I know I fixed a couple things in the last few code commits that may have fixed this, so maybe all is OK now.  My results below.

Like you, I was successful with the RAMSIZE set to 1536.  I can't believe I didn't think of this previously.  I will go ahead and make that change in the default build.

Thanks,

Wayne

987650321ZRC Monitor v0.7 7/24/20


>Boot CP/M
4--ROMWBW: 4 press Return to execute command
hZ

RomWBW HBIOS v3.1.1-pre.158, 2022-02-20

RC2014 Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, ZRC MMU
512KB ROM, 1536KB RAM

ROM VERIFY: 00 00 00 00 PASS

AY: MODE=RCZ80 IO=0xD8 NOT PRESENT

ACIA0: IO=0x80 ACIA MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 NOT PRESENT

MD: UNITS=2 ROMDISK=384KB RAMDISK=1280KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: 8-BIT LBA BLOCKS=0x0003D400 SIZE=122MB

IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ACIA0:      RS-232            115200,8,N,1

Disk 0      MD0:        RAM Disk          1280KB,LBA
Disk 1      MD1:        ROM Disk          384KB,LBA
Disk 2      IDE0:       Hard Disk         122MB,LBA

[Bill Shen]

Wayne,
Thanks for your help.  I updated with latest ROMWBW-dev and no more ROM Verify errors.
  Bill

RomWBW HBIOS v3.1.1-pre.158, 2022-02-20

RC2014 Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, ZRC MMU
512KB ROM, 1536KB RAM
ROM VERIFY: 00 00 00 00 PASS

AY: MODE=RCZ80 IO=0xD8 NOT PRESENT
ACIA0: IO=0x80 ACIA MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 NOT PRESENT
MD: UNITS=2 ROMDISK=384KB RAMDISK=1280KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC

IDE0: 8-BIT LBA BLOCKS=0x0001E900 SIZE=61MB

IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ACIA0:      RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          1280KB,LBA
Disk 1      MD1:        ROM Disk          384KB,LBA

Disk 2      IDE0:       CompactFlash      61MB,LBA

Disk 3      IDE1:       Hard Disk         --


RC2014 Boot Loader

Boot [H=Help]:

[Wayne Warthen]

On Sunday, February 20, 2022 at 4:44:13 PM UTC-8 Bill Shen wrote:

Wayne,
Thanks for your help.  I updated with latest ROMWBW-dev and no more ROM Verify errors.
  Bill

Excellent!

-Wayne 

[Bill Shen]

Alan Cox have mentioned a different banking scheme to support MP/M; that instead of 32K banks, 56K/8K partition may be more suitable for MP/M.  56K/8K is easy to do if lesser than 100% memory utilization is acceptable.  In addition, given memory is sufficiently large that part of the memory can be set aside for RomWBW banking scheme and other part of the memory for 56K/8K banking scheme.   Thus the same hardware can support both RomWBW and MP/M.

ZRC has one-chip 2meg-byte DRAM which is more memory than what existing applications can use.  So it is a good candidate to split the memory into 1 meg of 32K banks (32 banks) for RomWBW and 1meg for 56K/8K banks (16x56K banks, one common 8K bank) for MP/M.  ZRC's decoding is in CPLD so banking scheme can be reconfigured without hardware changes.

The 56K/8K split is inefficient because each bank is actually 64K but the upper 8K of every 64K bank is mapped to one common 8K memory.  There are 16 such 64K-banks thus 15 top 8K memory is inaccessible--a waste of 15*8=120KB memory.

The bigger issue is I don't know anything about MP/M, so I don't know how to utilize this newly created banking scheme.  This may be a case of "build it and they'll come"; OR I'll just need to learn about porting MP/M to ZRC.
  Bill

[Alan Cox]

> The bigger issue is I don't know anything about MP/M, so I don't know how to utilize this newly created banking scheme. This may be a case of "build it and they'll come"; OR I'll just need to learn about porting MP/M to ZRC.

MPM-II is sort of a halfway house between CP/M 2.2 and CP/M 3. Disk
BIOS much the same (weird flush interface), console is slightly
different because of the interrupt/polling/multi-tasking stuff and
there's some oddments for bank flipping etc.

Not that different to a CP/M BIOS to be honest. As far as MP/M is
concerned you've got a common space and some banks of whatever size.
For practical reasons you want the banks large to run CP/M apps so
you've got a decent TPA.

Alan

[Tadeusz Pycio]

I think Alan has approached the MP/M II subject too optimistically. If we don't use any tricks, the memory split will be 48/16kB, and 40/24kB when supporting 16 disks. In vanilla MP/M, the BNKXIOS area is COMMONBASE - which is well below B300h.

[Tadeusz Pycio]

I misspelled, the COMMONBASE area is below CD00h and the most economical split is 48/16kB, with full 16 drive support it is 44/20kB.

[Bill Shen]

I thought the idea of MP/M is let server takes care of disk I/O so BIOS on the client is smaller, so 8K common seems reasonable for such arrangement.  I've not done any MP/M; what hardware is your MP/M running on?  Can common area smaller with fewer disks?

CPLD is flexible so it is certainly possible to adjust the memory split to other values like 52K/12K.
  Bill

[Tadeusz Pycio]

As I mentioned earlier, a 48/16kB split is possible so for an MP/M user the TPA is 48kB, so less than on a typical CP/M. The biggest increase in TPA area is using CP/Net and a client with CP/NOS.

MP/M is built on BDOS 3 just like CP/M 3, although with some differences (DR made a fuss with the naming) because in CP/M 3 deblocking is in BDOS instead of BIOS as in MP/M and earlier versions of CP/M based on BDOS 2.

The computer on which I run MP/M is specially prepared (MMU) to use 4kB blocks:

[Bill Shen]

That is a great looking set of RCBus compliant boards.  So you are able to have 4K banks with UM74HCT612?  Very nice.  It seems to me Z280 with its native 4K MMU may also be suitable for MP/M.  I see you are also developing a Z280 board, possibly to replace the Z80/74HCT612 board?  I'm interested in your Z280 port of MP/M.
  Bill

[Mark T]

If 56K/8K is best ram option for MP/M, would it still be better to use 32K pages for flash?

When 16K/48K is used for MP/M or Fuzix under RomWBW, how are the 48K pages mapped from 512K ram and flash?

It would be interesting to try and design a module/sbc that avoids 74hct670, but still supports MP/M under RomWBW without software changes. So long as the chip count is still reasonable.

[Wayne Warthen]

On Saturday, July 29, 2023 at 12:28:37 PM UTC-7 Mark T wrote:

When 16K/48K is used for MP/M or Fuzix under RomWBW, how are the 48K pages mapped from 512K ram and flash?

RomWBW is only used as a "launcher" for Fuzix.  Fuzix would then reprogram the bank mapping as it desires.

-Wayne 

[Tadeusz Pycio]

Hi Bill,

The Z80 was originally going to get a different MMU, but by chance I managed to get hold of an HCT612, which has a similar organisation to the MMU in the Z280. I didn't really think about the choice as the bank switching routines will be similar for the Z80 and Z280. Yes, I plan to make an MP/M port for the Z280 in the near future.

[Alan Cox]

On Sat, 29 Jul 2023 at 20:28, Mark T <mark...@gmail.com> wrote:

If 56K/8K is best ram option for MP/M, would it still be better to use 32K pages for flash?

When 16K/48K is used for MP/M or Fuzix under RomWBW, how are the 48K pages mapped from 512K ram and flash?

Well 48/16K may be better Tadeusz has some good numbers there.

For the Fuzix case Fuzix grabs a few numbers off ROMWBW then takes it out back and shoots it. It maps 1-4 16K blocks for a process (depending upon declared memory needs), the top of which is a chunk of common code replicated in each upper bank. The kernel also has its own banks and it does bank switching between them as needed (modified sdcc compiler does all the hard work).

It's tricky to map either of them onto ROMWBW without changing some of the core assumptions in ROMWBW about how memory is mapped and I/O works. It would also only work for some platforms whereas right now ROMWBW runs on a lot of things.

Alan

[Bill Shen]

This is a reply to my post dated Feb 8 2021.

The post on Feb 8 2021 showed the software and logic schematic for driving WS2812B with the nominal 14.7MHz Z80 clock.  It was simple and preferred way of driving WS2812B by ZRC.  However, because RC2014 and their clones are all 7.37MHz Z80, I want to demonstrate that it is possible to drive WS2812B with 7.37MHz CPU clock.  Before they got buried and forgotten by my aging brain, I'm documenting it here with schematic and associated software and a short explanation (possibly meaningful only to myself) how to drive WS2812B with 7.37MHz Z80 clock.  

The test platform is ZRC populated with 7.37MHz oscillator.  The CPLD in ZRC is modified to add the circuitry for driving WS2812B with 7.37MHz clock.  The new driver circuitry is sufficiently complex, that I have to remove the I2C function and the 8 discrete output to free up enough CPLD resources.   The top_scm schematic shows the overall ZRC CPLD design.  The new WS2812B driver circuitry is the block at lower right labelled "WS2812_7MHz_driver".

WS2812_7MHz_driver schematic contains a 8-bit data latch to hold 8 bits of either red, blue, or green color data.  The latch is followed by 74151 8-to-1 multiplexer to select one bit of the color data.  At the lower half of the WS2812_7MHz_driver schematic is 7.37MHz divided by 3 to produce 2.4576MHz that has a period of 400nS (actually 407nS, but close enough) as specified by WS2812B datasheet.  WS2812's pulse modulation scheme specifies first 400nS to be high always; the 2nd 400nS is high if data=1 or low if data=0; and the third 400nS is always low.  The first, second, third phases of pulse modulator is controlled by the second divided-by-3 counter that selects "1" (first phase), "data" (2nd phase), and "0" (third phase) to assemble a 1200nS data-modulated pulse train.  Finally The 74151 multiplexer selects [2:0] are driven by divided-by-8 counter to go through all 8 data bits, most significant bit first.

The software write 8-bit of either red, blue or green color data to the data latch; delay enough time for the data to be shifted out; then write next color to the 8-bit data latch.

;test WS2812B
;9/2/23 ZRC clock is set to 7.37MHz
;more complex ws2812 driver hardware
WS2812 equ 1eh ;d[0] drives the PWM
org 1000h
ld hl,table ;point to table
jp wRGB7mhz

ld b,24 ;24 color bytes
wRGB7mhz:
;7.37MHz clock
;write a byte, then wait 72 clock before writing next byte
;ZRC insert a wait for instruction fetch so instruction timing is +1 clock
ld a,(hl) ;8
out (WS2812),a ;12
inc hl ;7
nop ;5
nop ;5
nop
nop
nop
nop
nop
djnz wRGB7mhz ;14
jp 0b400h ;return to monitor

table:
db 3,0,0
db 0,3,0
db 0,55,0
db 40,0,0
db 0,0,25
db 0,20,20
db 1,1,1
db 40,40,40


I won't bother taking a picture of the result because it looks the same as the picture posted on Feb 8 2021 (except the oscillator value is 7.37MHz).

  Bill

[Bill Shen]

SIMM 30 memory tester based on ZRC

I purchased many pounds of SIMM memory from an electronic surplus many years ago mainly for SIMM-72 memory sticks for several retro projects.  I revisited my SIMM collection recently and picked out 25 SIMM-30 sticks which are mostly 1 meg and few 4 meg memories.  So I'm looking for a tester for these SIMM-30.  Since ZRC is already wired for 2meg X8 DRAM, it is simple to rewire it for SIMM-30.  The CPLD has enough surplus I/O to replicate SIMM 30's multiplexed addresses, RAS, CAS, and write enable.  The CPLD design is modified to disable the on-board 2meg X8 DRAM and drive the SIMM-30 instead.  ZRC monitor has built in memory diagnostic, so that's sufficient to test the SIMM-30.

It works.

Now I'm thinking of a variant of ZRC with two SIMM-30 memory sticks.  The memory size can be as big as 32meg if each socket is populated with 16meg SIMM-30.  I think that's crazy for 14.7MHz Z80, but perhaps someone can think of an application.
Bill

[T Gerbic]

Probably could have just tested the SIMM-30s with the Retro Chip Tester.

Memory is cheap and plentiful these days. We could probably stick a gig on a Z80 with some kind of endless bank switching process. I struggle to find a practical use for more than 56K/60K with maybe one or two small banks. I really wish the Z80 had come with a flat 128K or 256K memory model and we could stick CP/M up at the top. I know there are more applications for larger amounts of memory but not for what I use my IMSAI for.

[Bill Shen]

RomWBW uses 1 meg of memory (512K ROM, 512KRAM), so 1meg SIMM 30 is useful, but larger than that may not be useful.  Only reason ZRC has 2meg of memory is because 2megx8 DRAM were salvaged from existing SIMM-72 sticks so they are basically free.  I have not found useful applications for the 2nd megabyte of memory other than a larger RAMdisk.
Bill

[Bill Shen]

I designed a version of ZRC with dual SIMM-30 socket.  The board is 50mmX100mm 4-layer PCB, 14.7MHz Z80, RomWBW ready, and with classic 40-pin C2014 connector.  I ordered and received a pair of 16meg SIMM-30 sticks so here is ZRC rev2 hosting a 16meg SIMM30 memory.  I can only test 8 meg memory because bank register is 8-bit for maximum of 256 banks of 32K memory.  256*32K is 8192K.  I need another bank register to go above 8meg, but need a way to switch both bank registers simultaneously.  Hmmm...

A reasonable question is why in the world do I ever need 32 meg of RAM for a 14.7MHz Z80?  I don't have a plausible answer, maybe someone can help me out.
Bill

[Bill Shen]

Having large amount of memory allow video data to be stored in RAM and play back faster and more consistently.  The monochrome 128x64 OLED only needs 1K bytes for a screenful of data, so video rate display can be done with direct access to CF disk.  128x128 4-bit grey scale OLED needs 8KB per screen, it is harder to support that with direct CF access.  Here is ZRC with SIMM30 displaying 128x128 in 16 grey levels.  To animate it, I stored 8KB images in successive banks of RAM, so it is easy and fast to move a frame of data to I2C interface.

So there, a make-believe justifications for huge memory!