Help porting ROMWBW to ZZRCC

[Bill Shen]

ZZRCC is a Z280-based minimal SBC.  It has a Z280 operating in 8-bit Z80-compatible mode, 512K RAM, CF disk, and a CPLD that contains a tiny (32 bytes) boot ROM.  The CPLD also handles address decoding and setting up Z280 to Z80-compatible mode at reset.  The 512K RAM is aliased 32 times over Z280's 16-meg memory space, i.e., 512K memory blocks starting from 0x0, 0x8_0000, 0x10_0000, 0x18_0000, so on to 0xF8_000 are all mapped to the same 512K RAM. 

When powering up ZZRCC, the tiny ROM in CPLD loads and runs the program located in CF's master boot record, which, in turn, loads and runs bigger program from CF disk.  This bootstrap mechanism allows the 512K ROMWBW image to be loaded into RAM and execute.  So now the 512K RAM is filled with ROMWBW image, what about RAM usage?  Looking into ROMWBW listing (this is ROMWBW_nat_zz.rom generated for RCZ280 with nat_zz configuration), I can see the RAM is mapped to top 32K of 512K, so the top 32K of ROMWBW image will be altered with HBIOS operations, but that's OK because that is some files in ROM disk which ZZRCC really doesn't need because it already has a CF disk.

So I went ahead and loaded the image of ROMWBW_nat_zz and ran from 0x0.  I see ROMWBW boots up and sign on.  'h' at Boot Loader gives a list of commands that seem to all work fine.  I can run some ROM Applications such as Monitor and BASIC, but I am not able to run CP/M 2.2 nor Z-System nor 'Play a Game'.   So I suspect CP/M and Z-System have different RAM mapping that corrupted different parts of the ROMWBW image and crashed the computer.

I need help figuring out RAM usage of CP/M and Z-System.  Thanks,

  Bill

[Wayne Warthen]

Hi Bill,

Happy to help.  Definitely an issue of conflating the RAM and ROM memory maps in RomWBW.

I'm going to need to think this through just a bit.  I will get back to you shortly.

-Wayne

[Wayne Warthen]

Here is a table of the ROM and RAM banks presented in a way that let's you see how they would overlap.  It seems like you should be able to load an OS one time and it should work.  After the first time, the ROM image of all the OSes would be trashed.  So, I'm still trying to think through what is breaking when you try to load an OS.  "Play a Game" should be even simpler.  Still thinking about this.

Bank ROM RAM

---- --- ---

0 HBIOS (IMG) RAMDISK

1 ROMLDR+MON+CP/M2+ZSYS RAMDISK

2 FTH+BAS+TBAS+PLAY+USR RAMDISK

3 RESERVED RAMDISK

4 ROMDISK RAMDISK

5 ROMDISK RAMDISK

6 ROMDISK RAMDISK

7 ROMDISK RAMDISK

8 ROMDISK BUF (CPM/3)

9 ROMDISK BUF (CPM/3)

A ROMDISK BUF (CPM/3)

B ROMDISK BUF (CPM/3)

C ROMDISK AUX (CPM/3)

D ROMDISK HBIOS (EXEC)

E ROMDISK TPA-LO

F ROMDISK COMMON (TPA-HI)

[Wayne Warthen]

When you select CP/M from the loader prompt, do what exactly to you see?  A normal load looks like the following.  I would like to know if you get any of these lines at all.

-Wayne

Boot [H=Help]: c

Loading CP/M 2.2...

CBIOS v3.1.1-pre.52 [WBW]

Configuring Drives...

        A:=MD1:0

        B:=MD0:0

        C:=SD0:0

        D:=SD0:1

        E:=SD0:2

        F:=SD0:3

        G:=SD0:4

        H:=SD0:5

        I:=SD0:6

        J:=SD0:7

        1585 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

B>

[Wayne Warthen]

On Thursday, March 4, 2021 at 12:38:24 PM UTC-8 Wayne Warthen wrote:

When you select CP/M from the loader prompt, do what exactly to you see?  A normal load looks like the following.  I would like to know if you get any of these lines at all.

Sorry, typos.  "do what exactly to you see?" --> "what exactly do you see?"

[Bill Shen]

Wayne,
When loading CP/M2.2, I see the line "Loading CP/M 2.2..." then hang
When loading Z-System, I see the line "Loading Z-System..." then continuous transmission of non-printable characters.  The screeb cursor remain where it was but there are steady stream of serial data coming out of ZZRCC
When loading Play a Game, I see the line "Loading Play a Game..." followed by continuous transmission of non-printable character similar to Z-system's response.
  Bill

PS, thanks for the RAM/ROM bank table.  I definitely don't need RAM disk; a small ROM disk with XMODEM and disk initialization would be nice, but there are different way to load software into CF disk as well.  Hopefully this will free up room for RAM to coexist with ROMWBW image.

[Mark T]

If the ROM disk is actually in ram then you can configure it so that it is a preloaded ram disk. Then after you load the image you can delete any files you no longer want and make space for something else.

[Bill Shen]

Mark T,
"ROM" disk is in fact in RAM, so you are exactly right that it can be made writable with appropriate patch to the BIOS.  I know you've done something like this with ROMWBW for your Z80 SBC so I am hoping Wayne and you can both help me navigate the "single RAM" Zx80 SBC for ROMWBW.
  Bill

[Wayne Warthen]

On Thursday, March 4, 2021 at 5:22:34 PM UTC-8 Bill Shen wrote:

Mark T,
"ROM" disk is in fact in RAM, so you are exactly right that it can be made writable with appropriate patch to the BIOS.  I know you've done something like this with ROMWBW for your Z80 SBC so I am hoping Wayne and you can both help me navigate the "single RAM" Zx80 SBC for ROMWBW.

Yes, I think the general idea is a RAM drive that just happens to be "pre-filled" with content.  RomWBW already checks the RAM drive at boot to see if it is valid and, if so, leaves it alone.  Based on the bank assignments that already exist, I think this means a pretty small RAM drive -- 128K.  Small, but big enough to have a few files.

However, the first order of business is to figure out what is going wrong with the boot scenario.  Even though the banks are "overlapping", I don't see why you are not getting at least to a CP/M banner.  I might be able to recreate the ZZRCC memory map with a few hacks on my system and see what happens.

This is going to take me a little while and my time is limited over the next few days, so please be patient.

Thanks,

Wayne

[Alan Cox]

However, the first order of business is to figure out what is going wrong with the boot scenario.  Even though the banks are "overlapping", I don't see why you are not getting at least to a CP/M banner.  I might be able to recreate the ZZRCC memory map with a few hacks on my system and see what happens.

This is going to take me a little while and my time is limited over the next few days, so please be patient.

This sounds horribly similar to the problems I had with Karl's Z280 module in 8bit mode. I tried all sorts of cache setting, cache off, flushes and other tricks but some times when jumping in and out of banks I was switching the processor just seemed to go into hyperspace. Under a Z80 emulator with the odd few Z280 instructions and bits added it worked pefectly.

I never got to the bottom of that one as in the end I gave up, so I don't know for sure the real cause.

Alan

[Bill Shen]

Wayne,
Thank you for your help.
  Bill

[Bill Shen]

Alan,
This is the same software that runs correctly in ZZ80MB, which has the same Z280 in 8-bit Z80 mode and a 512K ROM in 0x0 and a separate 512K RAM in 0x800000.  In ZZRCC the ROM and RAM mapped to the same RAM device, but it should run if there are no conflicts in memory usage.  Whatever the issue may be, at least the failure is deterministic so that should make debugging easier.  Intermittent problem is the worst of hardware/software problems.
  Bill

[Wayne Warthen]

OK, turns out that the issue with "Play a Game" was a simple deficiency in the "Play a Game" code itself.  It was not saving the HL register when calling HBIOS which it should have.  The new Z280 serial driver is destroying HL.

Still a mystery what is happening with CP/M and ZSDOS, but making progress.

-Wayne

[Bill Shen]

You are right, I did not test "Play a Game" with ROMWBW_nat_zz on ZZ80MB.  I did it now and it also hung on my ZZ80MB hardware.
  Bill

[Wayne Warthen]

I have been unable to recreate the problem Bill is seeing.  So I have asked him to provide me with a ZZRCC, which he has kindly agreed to.  As soon as I get the hardware, I will track this issue down.

-Wayne

[Bill Shen]

Aaugh!  Wayne, my apology!

In the process of cleaning up comments of a special ROMWBW loader I realized I've used a buffer area for holding incoming Intel Hex data that destroys memory content in 0xC000 to about 0xC020.  Once I relocated the buffer to area not used by ROMWBW, then it all starts to work.  This is the screenshot of ROMWBW running in ZZRCC.  I'm able to issue 'C' and boot up CP/M2.2!

Here is the long version:
I used bin2hex to convert ROMWBW.ROM to ROMWBW.HEX with /4 option ("Generate HEX file using ext. linear address records (HEX386)").  I have an Intel Hex loader that can load Intel Hex file with extended linear address.  In order not to overwrite the loader, I place it in ROMWBW's unused area in 0x5000 and cut out the part of ROMWBW hex file that loads into 0x5xxx.  What I didn't remeber is I also used a buffer area located at 0xC000 to hold received data and then DMA it to final destination.  This resulted in ROMWBW code in 0xC000- 0xC020 being corrupted.  Once I relocate the buffer area to 0x6000 which is also unused area of ROMWBW, things start to work now.

Sorry about that.

  Bill

[Wayne Warthen]

No problem Bill.  I am just very happy to hear it is working!

I have to say that I see how this would have corrupted CP/M 2.2, but it does not seem like it would have corrupted ZSystem.  Is ZSystem working now?

I still need to do something to improve the situation with the RAM/ROM disks for this platform.

-Wayne

[Bill Shen]

ZSystem seems to work as well.  ZZRCC uses the same CTIO2 output as CTS handshake.   I am able to run xmodem file transfer with hardware handshake under CP/M and ZSystem.
  Bill

[Wayne Warthen]

On Saturday, March 6, 2021 at 11:24:36 PM UTC-8 Bill Shen wrote:

ZSystem seems to work as well.  ZZRCC uses the same CTIO2 output as CTS handshake.   I am able to run xmodem file transfer with hardware handshake under CP/M and ZSystem.

Well, you can't argue with success!  I suspected that XModem would work at 115200 baud on the ZZRCC because of the fast CPU clock.  It comes very close to working with a 12MHz clock.  Since the ZZRCC has almost a 15MHz clock, that is enough.  Glad you verified this.

I am working on some changes to RomWBW to allow generating a better image for the ZZRCC.  Hope to post something in the next day or two.

I assume that the RomWBW image loaded from CF does not need to be 512K, right?  Since the ZZRCC will only be using a 128K ROM disk image, a 256K RomWBW image is all that is needed.

-Wayne

[Fred Weigel]

I am thinking about this -- and I am confused.

I run CP/NET with serial transport at 38400 baud...  or 3840 characters per second.  My Altair-Duino is 2.5Mhxz  (or so).

But... assuming 2Mhz (for simplicity) - we have 520 cycles per byte. Both CP/NET and XMODEM will transmit around

128 characters, plus a bit for header, then wait for ack/nak. *if* we catch the first character. a 2Mhz 8080 can do it... at

115200... It comes to around 100 cycles per byte,  10 to 20 instructions...  (judge 5 or 10 clocks per instruction).

If checksum cannot be computed in the same time, take a second pass. You need only capture the packet...

Note: no display, no debug, just poll for charin, get put into buffer:

lxi h,buf

mvi c, len

top in status ; 10

ani rdy ; 7

jz top ; 10

in data ; 10

mov m,a ; 7

inx h ; 5

dcr c ; 5

jnz top ; 10

is the loop for 8080 - annotated with cycle counts. Total is 64 cycles per byte, so 115200 is "doable" for xmodem

on 2Mhz 8080.

Of course, there is the (lots of time) between receiving last packet byte and sending the ack. If your xmodem is

structured to send the ack right away, you *may* miss the next packet! That would be a "wrong" implementation.

250000 bps would be TOO FAST for 2Mhz 8080. A 12 Mhz cycle should be able to support XMODEM at roughly

1.5 mbit transmission rate. 15Mhz should support closer to 2 megabits/second

Or are you bit-banging the stream with Z80? Which may be why the speeds seem off by an order of magnitude.

Sorry -- I may just be missing context...

FredW

[Wayne Warthen]

Hi Fred,

Yeah, the issue here is the overhead imposed by a few things.  The version of XModem supplied with RomWBW is designed to work with a wide variety of hardware.  It does this by relying on the RomWBW HBIOS to abstract all interaction with the serial port.  RomWBW imposes a bunch of overhead in this scenario including API routing, bank switching on every call, and an interrupt driven receive buffer.

I realize this seems like a ridiculous amount of overhead to read/write bytes on a serial port.  The primary goal of RomWBW is to dynamically support a lot of different hardware.  The cost to do this abstraction is significant.

Keep in mind that none of this precludes the use of a custom XModem program tailored for specific hardware.  My point is that RomWBW does not really get in the way if you want to do this.  But the XModem I supply is intended to simply "work" on any hardware supported by RomWBW.

Thanks,

Wayne

[Wayne Warthen]

Hi Bill,

I just checked in an update in the dev branch at GitHub for RomWBW.  I am not yet able to test on the real hardware of course, but I hope this works for you.  It essentially removes the conflicts of the bank overlaps and allows construction of a ROM that has no ROM disk.  You can build a ZZRCC ROM with the following build command:

Build RCZ280 nat_zzr 256

The 256 on the end is important.  The resultant ROM image will be 256K and the size of the RAM disk will be 128K.  The RAM disk should be prefilled with some reasonable files.

[Wayne Warthen]

One other thing.  I tried to reflect the real oscillator speed in the configuration.  I failed because the 29MHz+ oscillator will not divide down into a divisor that gives me a 50Hz timer counter.  So, for now, the system thinks it is running at 24MHz even though it is actually running faster.

-Wayne

[Fred Weigel]

Wayne

Got it! Thanks! I started with the Altair 8800 -- and just got into it again -- back to hobby mode, from "professional developer"

(javascript, java, php) that I do as a day job (to avoid "retirement"). And, as a hobby, I am back to 2Mhz Z80 (8080 -- Z80 only because I really like Turbo Pascal ! ). I find that the need to strip abstraction for performance is refreshing.

FredW

[Wayne Warthen]

On Sunday, March 7, 2021 at 4:59:52 PM UTC-8 fred_...@hotmail.com wrote:

I find that the need to strip abstraction for performance is refreshing.

 

Yeah, I agree.  Of course, I am always open to creative suggestions on how to retain a reasonable abstraction and still improve performance!  Feel free to suggest or contribute.

-Wayne

[Bill Shen]

Wayne,
Downloaded v3.1.1-pre.56 and followed your instruction to generated a 256K RCZ280_nat_zzr.rom.  I used bin2hex with /4 option to convert it to RCZ280.hex and edited the .hex file to delete the data (they are all 0xFF) in address ranges 0x5000-0x6FFF so they won't overwrite the ROMWBW loader that resides in 0x5000.  Load RCZ280.hex and run from 0x0.  I have a working ROMWBW!  Drive A is RAM drive with many files preloaded; drive B: to I: are CF drives.  I can upload files with xmodem with hardware handshake enabled.  The best serial baud for loading is still 57600 which can load file at 3.3KB/S.  With serial baud of 115200, the effective transfer rate is about 1.3KB/S

I also tried ZSystem, it seems to work as well.  I'm not familiar with operating ZSystem to check things out.

It is looking good.  Now I need to figure out how to save RCZ280_nat_zzr.rom in CF and have a fast way of booting ROMWBW.
  Bill

[Bill Shen]

Hardware, software, and procedure for loading ROMWBW v3.1.1 pre.56 are documented at the bottom of the ZZRCC homepage.

In a nutshell: Install R5 with 100 ohm resistor, modify CP2102 USB-serial adapter with CTS handshake, and use ROMWBWldr to load modified RCZ280.
https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:zzrcc:applications:run_romwbw

[Wayne Warthen]

My latest dev branch check-in automates the creation of a ZZRCC specific combo hard disk image as well as the ZZRCC RomWBW hex load file.

Everything seems to be working great for me including loading OSes from CF.

-Wayne

[Bill Shen]

Wayne,
It all works very well, a big thanks to you.  I will add a new boot command in ZZRCC monitor to quickly boot ROMWBW from CF drive.  Maybe a better solution is just to boot straight to ROMWBW from power on.
  Bill

[rwd...@gmail.com]

Bill,

I look forward to building my pcb up, and am just checking for the right components.

I note that the BOM states C1 = 10uF (microfarad) Tantalum filter cap, but the schematic states C1 = 100pF - seems like a large difference - which is the correct value?

I am really pleased to see that RomWBW is now supported.

Richard

[rwd...@gmail.com]

Re: BOM ZZRCC - photos show 7032 CPLD but BOM refers to 7064 CPLD; As I have several 7032 I hope they are sufficient.

Richard

On Tuesday, 9 March 2021 at 15:16:46 UTC Bill Shen wrote:

[Bill Shen]

Richard,
Thank you for looking over the BOM and schematic.  C1 is indeed 100pF, it is C6 that should be 10uF.  The CPLD is 7032SLC, not 7064SLC.  I've made the correction to both BOM and schematic.
  Bill

[rwd...@gmail.com]

thanks Bill

[rwd...@gmail.com]

BOM: male header P5 described as 2*5 but looks like 1*4

Richard

On Sunday, 14 March 2021 at 19:22:26 UTC Bill Shen wrote:

[Bill Shen]

P5 was a 2x5 male header for programming CPLD, but it was removed during pc board layout because the lack of space.  The 1x4 female header you referring to is collection of 4 test points,T3, T4, T5, and T6, forming the I2C connector.  So I updated the schematic as well as BOM and assigned the 4 test points as P5 and describe it as '1x4 female header'.    Haha, that works.
  Bill

[Bill Shen]

Wayne,
I took advantage of the 8K 'hole' in ROMWBW from address 0x5000 to 0x6FFF to store pre-ROMWBW code and buffer areas for DMA/MMU.  ROMWBWldr resides in 0x5000 and its DMA buffer and MMU window is in 0x6000.  ROMWBWldr has two entry points:
1.,  0x5000 loads ROMWBW in Intel Hex Extended Linear format into RAM; creates a directory in CF disk (LBA 0x100-0x120); copies the 512K RAM contents to CF disk (LBA 0x120-0x420) and then jumps to 0x0 to start ROMWBW.
2.,  0x5003 restores ROMWBW image in CF disk (LBA 0x120-0x420) to 512K RAM and jumps to 0x0 to start ROMWBW.  When you do a 'DIR' command in ROMWBW of disk B, you'll see the 512K file, ROMWBW.IMG

ZZRCC Monitor is now rev0.3 which contains a new 'b4' command that first recalls ROMWBWldr from CF disk to 0x5000 and then jumps into 0x5003 to restore ROMWBW image.  For 'b4' command to work, the ROMWBW must be previously loaded into CF disk with ROMWBWldr

I noticed XM does not work (return to CP/M prompt without doing anything) in  v3.1.1--pre.62.  XM does work in v3.1.1--pre.56.

  Bill

[Bill Shen]

I don't have much time for retrocomputing during the summer time, but I have had the distinct pleasure of spending several rewarding weeks working with Wayne Warthen to port ROMWBW to ZZRCC.  I believe we've reached a stable version of ROMWBW that works well on ZZRCC.  It is currently on Wayne's Github page under the 'dev' branch.  Here is a quick instruction:

After download and unzip ROMWBW-dev, open a DOS window in the "Source" directory and type:

build RCZ280 nat_zzr 256

When build is completed, you'll find the CF image "hd1024_zzr_combo.img" in the 'Binary' directory.
copy the image to CF disk, I use Win32DiskImager that's included in ROMWBW distribution.
Insert the CF disk in ZZRCC, make sure the bootstrap jumper is installed and power up.  You will see version 0.5 of ZZRCC sign on and then type 'b4' to boot up ROMWBW.  You'll find disk A to G already filled with treasure trove of software which I'm still exploring.  These drives all have 1024 directories

ZZRCC has no EPROM, so the idea is using CF disk as EPROM and Win32DiskImager as the EPROM programmer.  This way 50 meg of data (or more) can be written to CF quickly and you can change EPROM by simply swap out a different CF disk. 

ZZRCC is open source hardware, you can find the design files here:https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:zzrcc

I'm reluctant to provide ZZRCC kit due to limited time in the summer, but feel free to order pc boards and build up your own and I'm happy to answer questions.  I will think seriously about providing ZZRCC kits during the winter months.  This is such a great capability, it would be a shame to not share it with more people.

  Bill

[Kurt Pieper]

Hello Bill,

I am delighted to read your message.

My research into the z280 also piqued my interest.

I am a cautious person by nature and tend towards z280 kits. I built 6 kits (z80, z180) and all of them worked immediately.

Great experience and have fun programming.

Good luck with your further activities.

Kurt