RomWBW for Z80 with 512K RAM 0K ROM

[Bill Shen]

A question for Wayne Warthen, but people wanting to build minimal RomWBW system may also be interested.

I have a Z80 with CF disk, 512K of RAM but no ROM.  I'm able to pull data from CF to fill the 512K RAM with RomWBW files prior to run  RomWBW.  I don't need RAM disk in RomWBW because I already have CF disk.  My question is how to configure the HBIOS so BuildROM.cmd can generate the .rom file which will be pre-loaded into 512K RAM before starting RomWBW?
  Bill

[Bill Shen]

Wayne,
I know I've down this road of minimal RAM/ROM before, but that was several years ago and I'm struggling to reconstruct our conversation.  What I did just now is splitting the 512K RAM into 256K ROM and 256K RAM.  The configuration file for HBIOS contains the following lines:

RAMSIZE .SET 256 ; SIZE OF RAM IN KB (MUST MATCH YOUR HARDWARE!!!)
ROMSIZE .SET 256 ; SIZE OF ROM IN KB (MUST MATCH YOUR HARDWARE!!!)
ROMSIZE_CHK .SET 256 ; ROMSIZE VALUE VERIFICATION (0=DISABLED)

MEMMGR .SET MM_ZRC ; MEMORY MANAGER: MM_[SBC|Z2|N8|Z180]
;
MDROM .SET TRUE ; MD: ENABLE ROM DISK
MDRAM .SET FALSE ; MD: ENABLE RAM DISK

This appears to work and RomWBW displays this at boot up:

RomWBW HBIOS v3.3.0-dev.10, 2023-09-27

ZRC [RCZ80_min] Z80 @ 22.118MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, ZRC MMU
256KB ROM, 256KB RAM
ROM VERIFY: 00 00 00 00 PASS

ACIA0: IO=0x80 ACIA MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 NOT PRESENT
VRC: IO=0x00 NOT PRESENT
MD: UNITS=1 ROMDISK=128KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: ATA 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:        ROM Disk          128KB,LBA
Disk 1      IDE0:       Hard Disk         61MB,LBA
Disk 2      IDE1:       Hard Disk         --


ZRC [RCZ80_min] Boot Loader

Boot [H=Help]: c

Loading CP/M 2.2...

CBIOS v3.3.0-dev.10 [WBW]

Configuring Drives...

        A:=MD1:0
        B:=IDE0:0
        C:=IDE0:1
        D:=IDE0:2
        E:=IDE0:3
        F:=IDE0:4
        G:=IDE0:5
        H:=IDE0:6
        I:=IDE0:7

        1569 Disk Buffer Bytes Free

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

A>dir
A: ASM      COM : CLRDIR   COM : DDT      COM : DDTZ     COM
A: DUMP     COM : ED       COM : LOAD     COM : PIP      COM
A: RELOG    COM : STAT     COM : SUBMIT   COM : XSUB     COM
A: ASSIGN   COM : MODE     COM : RTC      COM : SYSCOPY  COM
A: XM       COM : CPM      SYS : ZSYS     SYS


I'm happy with the result, but splitting 512K RAM into 256K ROM and 256K RAM wasn't the solution I've thought.  Somehow I dimly recall there was a different approach...  Then again my memory can easily be faulty so if this is the right solution, I'm perfectly happy with that.

  Bill

[Wayne Warthen]

Hi Bill,

The configuration I think you are remembering is what I call the "ROMless" boot option.  In this option, the system has no actual ROM.  The RAM is pre-seeded with the RomWBW core HBIOS and the bootloader.  This would accomplished by specifying the following lines in the config:

RAMSIZE .SET 512 ; SIZE OF RAM IN KB (MUST MATCH YOUR HARDWARE!!!)
ROMSIZE .SET 0 ; SIZE OF ROM IN KB (MUST MATCH YOUR HARDWARE!!!)
MDROM .SET FALSE ; MD: ENABLE ROM DISK

An example of this configuration is found in RomWBW/Source/HBIOS/Config/RCZ80_zrc_ram.asm.

The result of the build will create a .ROM file, but this is just the binary image that needs to be pre-loaded into RAM for RomWBW startup.  This will result in a system that uses 256K of RAM for system code and has a 256K RAM disk.

Is this what you are after?

Thanks,

Wayne

[Bill Shen]

Wayne,
Thanks for your reply.  That jogged my memory, it sounded very familiar.  In fact, I actually did try that set of configuration but it didn't generate the .rom file I expected.  I tried again now and got 42K .rom file.  I also tried BuildROM with the default rcz80_zrc_ram which also go 42K rcz80_zrc_ram.rom file.  That .rom file is too small to have the basic CP/M files on drive A.  I'm looking for configuration that will generate a .rom file that contains the essential CP/M files in drive A.  That way I can pre-load the RAM and start RomWBW with essential CP/M files in drive A.
  Bill

[Wayne Warthen]

Got it.  That is a new scenario for RomWBW.  In theory, RomWBW can startup "in place" which would accomplish what you want.  However, I need to find a way to construct the appropriate image as an output of the build process.  I need a little time to think through this.

There is a constraint for you though.  It will be necessary to launch RomWBW with bank n-2 already selected into the lower 32K of RAM.  You would need to select bank n-2, then jump to address 0.  Can you do this at the end of the preloading of RAM?

Thanks,

Wayne

[Bill Shen]

Wayne,
The hardware I'm working on is a modified Z80LCD that has 512K RAM instead of the default 128K RAM.  I've modified the CPLD so it is a ZRC but with 512K RAM instead of 2048K RAM.  I want to run RomWBW on this hardware such that RomWBW binary is stored on CF disk so it can be loaded into RAM before starting RomWBW.  I have the flexibility of selecting which bank to load RomWBW.

I know lots of my concept of RomWBW operation are before you've finalized RomWBW ver 3 and developed new concept of RomWBW auto-start with user selectable modes.  I may need to rethink about my previous concept of RomWBW operation and adjust to the current method.  The idea of RomWBW autoboot with user selected mode is very cool, but as a developer of new RomWBW-capable hardware, I know I may need to interrupt the auto-boot process and patch in diagnostic software and possibly new hardware to compensate for the new, unexpected hardware.  Hopefully I'm not throwing monkey wrench into the process!  Thanks,
  Bill

[Mark T]

Hi Bill,

I can try and dig out the source files that I used to build a 512k ram only variant of RomWBW. I think it was from 2021 so not recent. It was 384k ram disk, but the ram disk was preloaded with a selection of cpm files. This was for my single board cpm using ft245 to load battery backed ram. I think I changed some flags for the rom disk to make it writeable.

I have been playing with the hardware recently to fix the issue with wait states on z80 at 20mHz and now trying to get the shift register sdcard module reliable at 20MHz.

Mark

[Alan Cox]

On Thu, 28 Sept 2023 at 07:31, Mark T <mark...@gmail.com> wrote:
>
> Hi Bill,
>
> I can try and dig out the source files that I used to build a 512k ram only variant of RomWBW. I think it was from 2021 so not recent. It was 384k ram disk, but the ram disk was preloaded with a selection of cpm files. This was for my single board cpm using ft245 to load battery backed ram. I think I changed some flags for the rom disk to make it writeable.
> I have been playing with the hardware recently to fix the issue with wait states on z80 at 20mHz and now trying to get the shift register sdcard module reliable at 20MHz.

That would be interesting as it's essentially what is needed for both
the base ZX Spectrum Next and the 2063 (The other Z80retro). In the
case of the next it's pretty easy to build an image that the built in
loader would chuck into all the right banks, although it would be a
bit less than 512K in effect because there's a couple of 16K banks
lost to video and the like. For the 2063 it's basically what you
describe, 512K of RAM 32K fixed, 32K mappable and you'd load the image
(compressed as the SD is bitbang) and unpack it into the RAM.

Alan

[Mark T]

I might have a more recent version but this is a link to a thread where I attached a copy of the files on october 7, 2018. 

Doesn’t time fly.

https://groups.google.com/g/rc2014-z80/c/4e-e4GRH8uY/m/ybmgkS1QEQAJ

[Wayne Warthen]

Hi Bill,

I think I see a way to accomplish this.  I believe I can create a RAM image (that you must preload) that contains all of the functionality of a normal ROM+RAM system and include a 256K RAM disk prefilled with the normal CP/M apps.  The RAM image would include the normal RomWBW Bootloader, Debug Monitor, ROM Apps (Fourth, BASIC, etc.), so when the system boots, it would behave just like a normal ROM+RAM system.  All of the latest auto-boot, front panel, etc. would work as is.  Additionally, I think it will be possible to start the pre-loaded RAM image from bank 0, address 0.  Essentially, I am creating a combination of the existing RAM and ROM banks with a some rearranging.

In case anyone cares, the RAM image bank layout would look like this:

Bank            Usage
----            ------
0 Loader, dbgmon, ROM OSes
1 ROM Apps
2-9             RAM Disk Data
A-B             CP/M 3 Buffers
C               CP/M 3 OS
D               RomWBW HBIOS
E               User TPA
F               Common

The actual number of RAM Disk Data banks could be almost anything.  The above is just what a typical 512K RAM system layout would look like.

Does this all look good to you?  Does it fit your intentions?

Fair warning, I am seriously swamped right now.  This should not be horribly difficult, but requires some mucking around in things that are likely to break initially.  It is likely to take me a couple weeks to produce this.

Thanks,

Wayne

On Wednesday, September 27, 2023 at 8:50:19 PM UTC-7 Bill Shen wrote:

Wayne,

[Wayne Warthen]

Hi Mark,

Thanks for this.  It provided some excellent insight into the changes needed.  RomWBW has changed a fair amount since this was done, but my proposed solution borrows a few ideas from this.

Thanks,

Wayne

[Bill Shen]

Hi Wayne,
The RAM image bank layout looks great.  I do have a question about bank F (Common); does it contains active code from $B000-$BFFF?  The reason I ask is because my monitor resides there and RomWBW loader is part of the monitor.  I can clone the loader somewhere else, but ultimately it needs to reside somewhere in the memory, so loading 512K RomWBW run the risk of overwriting the RomWBW loader itself.  Loader is a small program, less than 256 bytes, so if I can find some unused space in Common, the loading process would be quite simple.  Alternatively, I can load Bank 0-E while executing out of high memory, then clone a loader in unused area in one of the bank (User TPA seems a good place) and finish loading bank F. 
The targeted hardware looks very much like ZRC and you may wonder why ZRC does not have this loader complication.  It is because ZRC has 2meg RAM and the monitor is located at top of the 2meg RAM, so it can load 512K without overwritten the monitor itself.
  Bill

[Bill Shen]

Mark,
I remember your 512K RAM SBC using FT245 to bootstrap.  Wow, that was 2018!  I think that was the first time I read about FT245.  Later I designed a 6502 SBC/flash programmer based on FT245 strapping drawing inspiration from your design.
  Bill

[Mark T]

Yes its been longer than I thought. I saw your 6502 using FT245, I think it needs a bit more attention to the 6502 dummy cycles. I have also seen variants of this on the web, some predate mine though I wasn’t aware of them at the time.

Some other variants I have been thinking about, but not tried to follow up, are to try a 6402 or maybe 74ls595 to boot from cassette tape.

[Wayne Warthen]

Hi Bill,

You are free to use $B000-$BFFF of the common bank.  To be totally accurate, this would be offset $3000-$3FFF of bank F, right?  Once RomWBW starts, it would be free to use this space, right?

Thanks,

Wayne

[Bill Shen]

Great!  Yes you are right, it is more accurate to describe the memory area as offset $3000-$3FFF of bank F.

  Bill

[Bill Shen]

Oh, yes, RomWBW is free to use that memory area.

  Bill

[Wayne Warthen]

Bill,

I think we are now in sync.  Now you just need to wait for me to work on it!

Thanks,

Wayne

[Wayne Warthen]

Hi Bill,

I have just published in RomWBW Development Snapshot v3.3.0-dev.58 at the RomWBW GiutHub Releases page.  This includes all of the work to produce the ROMless RomWBW image that we have been discussing.  Note, that the one thing missing is the actual RAM disk image.  That is actually a trivial thing to complete and I will be working on that in the next day or so.  In the current build, the RAM disk will just show up empty.  However, I wanted to check-in all of the "real" work so that you can test as desired.  My test case is a ROMless ZRC which has 2MB of RAM.  However, you can modify the config "RCZ80_zrc_ram.asm" to reduce the RAM size to the 512K we have been talking about.

Thanks,

Wayne

[Bill Shen]

Hi Wayne,
Thanks for the quick work!  I modified the config file rcz80_zrc_ram.asm so RAMSIZE is 512:

RAMSIZE .SET 512 ; SIZE OF RAM IN KB (MUST MATCH YOUR HARDWARE!!!)
ROMSIZE .SET 0 ; SIZE OF ROM IN KB (MUST MATCH YOUR HARDWARE!!!)

MEMMGR .SET MM_ZRC ; MEMORY MANAGER: MM_[SBC|Z2|N8|Z180]
;

MDROM .SET FALSE ; MD: ENABLE ROM DISK

BuildROM generated a 128K image which I loaded into first 128K memory.  Then I jump to 0x0.  This is what I got:

RomWBW HBIOS v3.3.0-dev.58, 2023-10-01

ZRC [RCZ80_zrc84] Z80 @ 22.118MHz

0 MEM W/S, 1 I/O W/S, INT MODE 1, ZRC MMU

0KB ROM, 512KB RAM

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

MD: UNITS=1 RAMDISK=256KB

FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: ATA 8-BIT LBA BLOCKS=0x0001E900 SIZE=61MB
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT

FP: IO=0x00 NOT PRESENT

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

Disk 0      MD0:        RAM Disk          256KB,LBA

Disk 1      IDE0:       Hard Disk         61MB,LBA
Disk 2      IDE1:       Hard Disk         --

ZRC [RCZ80_zrc84] Boot Loader

Boot [H=Help]: c

Loading CP/M 2.2...

CBIOS v3.3.0-dev.58 [WBW]

Configuring Drives...

        A:=MD0:0

        B:=IDE0:0
        C:=IDE0:1
        D:=IDE0:2
        E:=IDE0:3
        F:=IDE0:4
        G:=IDE0:5
        H:=IDE0:6
        I:=IDE0:7

        1561 Disk Buffer Bytes Free

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

A>dir
A: ASM      COM : CLRDIR   COM : DDT      COM : DDTZ     COM
A: DUMP     COM : ED       COM : LOAD     COM : PIP      COM
A: RELOG    COM : STAT     COM : SUBMIT   COM : XSUB     COM
A: ASSIGN   COM : MODE     COM : RTC      COM : SYSCOPY  COM
A: XM       COM : CPM      SYS : ZSYS     SYS

I can pip drive A contents to drive C, but when in drive C and do xmodem (XM r filename), I got
Bdos Err On A: File R/O

That's strange because I know drive C is read/write.

You have mentioned (Sept 27) needing to select bank n-2 before launch RomWBW.  I didn't do that, should I?  We also talked about avoiding my loader in bank F offset $3000-$3FFF (Sept 28), but that doesn't seem to be an issue here because the load file is 128K so it won't run into the loader at top of the 512K memory.  

Here is an intermittent bug: sometime it will boot into CP/M with "Formatting RAMDISK..." and the content of drive A is empty.

RomWBW HBIOS v3.3.0-dev.58, 2023-10-01

ZRC [RCZ80_zrc84] Z80 @ 22.118MHz

0 MEM W/S, 1 I/O W/S, INT MODE 1, ZRC MMU

0KB ROM, 512KB RAM

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

MD: UNITS=1 RAMDISK=256KB

FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: ATA 8-BIT LBA BLOCKS=0x0001E900 SIZE=61MB
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT

FP: IO=0x00 NOT PRESENT

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

Disk 0      MD0:        RAM Disk          256KB,LBA

Disk 1      IDE0:       Hard Disk         61MB,LBA
Disk 2      IDE1:       Hard Disk         --

ZRC [RCZ80_zrc84] Boot Loader

Boot [H=Help]: c

Loading CP/M 2.2...

CBIOS v3.3.0-dev.58 [WBW]

Formatting RAMDISK...

Configuring Drives...

        A:=MD0:0

        B:=IDE0:0
        C:=IDE0:1
        D:=IDE0:2
        E:=IDE0:3
        F:=IDE0:4
        G:=IDE0:5
        H:=IDE0:6
        I:=IDE0:7

        1561 Disk Buffer Bytes Free

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

A>dir

NO FILE

Thanks, Bill

[Tadeusz Pycio]

Will the RomWBW ROM-less version with 512kB RAM work with bootstrap mode for the Z280?

[Wayne Warthen]

Hmmm... multiple recent messages from me, seem to be missing from this thread.  Something screwy going on with Google Groups.  Sorry.  I will try to summarize things here.

Tadeusz, you asked whether ROMless support applies to Z280.  Yes, works great, but note a small issue below that I need Bill's help with on the ZZRC.

Bill, in your last email, you reported some anomalies with the RAM Disk image.  I suspect they are all related to the fact that the release you were testing did not have the actual RAM Disk images yet.  I am currently testing on ZRC and ZZRC.  It is generally working fine, but I have a couple comments below.

At this point, please make sure you are using RomWBW Development Snapshot v3.3.0-dev.60 from the RomWBW GitHub Releases Page.  This version has the ROMless support well tested and includes the RAM disk images.

The best way to test is to simply use one of the CF Card combo images from the Binary directory.  Just write the file onto the CF Card starting at the first sector and boot.

For ZRC (Z80), you would use "hd1k_zrc_ram_combo.img".  This is setup to use 512K of a ZRC.  This is what I have done most of my testing on and I think this should be equivalent to the new Z80LCD.

For ZZRC (Z280), you would use "hd1k_zzrc_ram_combo.img".  This is setup for a normal ZZRC Z280 w/ 512K RAM.  This is also testing out just fine for me.

NOTES:

• The ZZRC CF Loader seems to be copying only 256K from the CF Card into RAM (instead of the expected 512K).  All of the critical boot banks are copied, but only half of the RAM Disk image is copied.  So, the RAM Disk directory looks complete, but the files in the second half of the drive are missing/corrupt.  Can you look into this?
• The ZRC actually has 2048K of RAM.  As I said above, the ROMless build only uses 512K.  This is simply because the CF Loader only copies 512K to RAM, so there is currently no way to use a larger RAM image.  Let me know if you want to discuss ways to improve this.  Since the Z80LCD has only 512K, it should not be an issue on that device.

Sorry for the long message -- trying to catch up on everything.  I hope this post does not disappear.

Thanks,

Wayne

[PauldB]

I'm following this conversion of Bill's 'Z80LCD' and 'ZRC' modules to a ROM-LESS Z80 module with great interest. 

I'm looking forward to building such a beast :-)

What will the new module will be called? I see references to 'zrc_ram' and 'zrc84'.

Thanks,
Paul

[Bill Shen]

Paul,
The Z80LCD has evolved into EPM7128S in PLCC84 and 512K RAM plus a number of additional peripherals.  ZRC84 was its temporary name, but I think I'll name it ZRC512.

The name of various but similar boards are confusing because they were originally conceived 3 years ago and have evolved in different directions.  They are all based on the original RC2014 bus, 102mmX51mm pc board, no flash memory, uses CPLD as glue logic and bootstraps from CF disk.  I'm going to summarize them here.  

ZRC, 14.7MHz Z80 with 2meg DRAM plus I2C and WS2812B.  RomWBW capable.  Originally designed without CF disk, but that concept was abandoned and now has CF disk in the default configuration.  

ZZRCC, 14.7MHz Z280 with 512K RAM plus I2C.  All through-hole components.  RomWBW capable.

ZRCC, 22MHz Z80 with 128K RAM.  All through-hole technology.  It is not RomWBW capable.  

I'm contemplating two more designs:
ZRC512, 22MHz Z80 with 512K RAM plus I2C, RTC, and WS2812B.  All through-hole components.  RomWBW capable.
Z1RCC, 18.4MHz Z180 with 512K RAM.  All through-hole components.  RomWBW capable.

ZRCC has a special version (rev1.3) with fast SMT RAM and nominal 29.5MHz clock but capable of 33MHz with selected Z80; I think Z1RCC will also have a special version with fast SMT 512K RAM and operating frequency of 36.8MHz.
  BIll

[Bill Shen]

Wayne,
Thanks for dev.61.  I have not tried the combo CF image yet, but I went through the process of editing the configuration file (it is rcz80_zrc_ram with CPU clock set to 22MHz and renamed to rcz80_zrc512); and generated the RCZ80_zrc512.rom file using buildROM script.  I converted RCZ80_zrc512.rom to Intel Hex rcz512.hex but edit out the last 32K (last 32K is all 0xE5) so the hex file won't overwritten the loader located in bank F.  The resulting hex file is loaded and ran from 0x0.


This looks great.  I'll try the CF image next and I'll also tackle the loading problem with 512K Z280.

I'm happy that this version of RomWBW uses 512K of ZRC memory.  I thought the other 1.5meg of RAM can be reserved for other operating systems.  I've thought of something a while ago, but I can't remember what...it'll come to me, hopefully.
  Bill

[Bill Shen]

BTW, xmodem now works perfectly.  I can transfer large file without any problem.
  Bill

[Wayne Warthen]

Excellent.  Glad it is working for you Bill.

These changes are going to be useful for others as well.

Thanks,

Wayne

[Bill Shen]

Wayne,

Another update, when plugging in the RTC prototype board, the RomWBW will auto detect the RTC and calculate the CPU clock as 21.992Mhz.  Close enough to the actual 22Mhz oscillator.

Thank you for offering RomWBW in RAM-only configuration.  I believe a fast, small bootstrap ROM can also be incorporated in PLD such as 22V10 to boot from CF.  22V10 has a more friendly development environment.  That capability plus a large, fast RAM can resulted in small, simple, yet fast Z80/Z180/Z280 RomWBW-capable SBC that can be reprogrammed by changing the CF images, or swapping to different operating environments by changing the CF disk.

  Bill

[Tadeusz Pycio]

Having corrected my silly mistake of overwriting the Z280's control microcontroller software, I am now trying to follow the ZZRCC path. I was left to figure out how to load RomWBW using Bill's software. I wonder if I can create a bootloader that bypasses these intermediate RomWBW loading steps, that would probably be the most convenient solution. Another conundrum is whether it is possible to use RomWBW with 640kB of RAM, but this will wait until the possibility of changing the bootstrap software contained in the microcontroller's EEPROM from within CP/M is resolved.

[Tadeusz Pycio]

The RomWBW bootloader works fine, but I think there are the disk handling issues that Wayne mentioned. However, I will try to build a bootloader that bypasses these intermediate loading steps.

[Bill Shen]

Wayne,
I think I understand why only 256K of RomWBW is copied to RAM in Z280 case.  This is because Z280 rev0.5 monitor handles the saving and restoring of RomWBW image from CF disk to RAM.  Rev0.5 only saves and restores 256K of RomWBW image.  This is because the previous RomWBW for ZZRCC only generate 256K ROM (RCZ280_nat_zzr.rom).  You may recall there was a hole in RomWBW code from 0x5000-0x7FFF and I stored a loader there to help me copy RomWBW image from CF to RAM.  It is unclear to me why I did that when RomWBW image is only 256K, but I think because RomWBW image was 512K at one time and I was looking for unused block of memory to store a loader.

Now I know the top 32K of RomWBW is empty prior to startup; the RomWBW image is 512K-32K=480K.  So the monitor and image loader can all reside in top 32K of memory to save/restore 480K RomWBW image without worrying about being overwritten.  The updated monitor should work with both older Z280 RomWBW (RCZ280_nat_zzr.rom) as well as the current RomWBW (RCZ280_zzrc_ram.rom).

Do you have a suggestion how I can handle the RomWBW image better?

*****************************
I tested RCZ280_zzrc_ram.rom by generating it using buildROM and cut out the top 32K of data (they are all 0xE5); use the monitor to load the 480K image into RAM and jump to 0x0.  I got this:  xmodem works but the baud rate needs to change to 57600bps.  RCZ280_zzrc_ram appears to work, I just need to update the monitor to save/restore 480K image to/from CF.  --Bill

[Wayne Warthen]

Hi Bill,

OK, great, this is good progress.

You are absolutely correct that it is not necessary to load all 512KB from CF to RAM.  The top 32KB of RAM is always going to be used as the common RAM and will never need to be pre-loaded.  So, your approach of loading 480KB will work perfectly.  And, yes, it should work fine for old and new RomWBW images.  Your monitor can occupy any/all of the top 32K of RAM.  When RomWBW is launched from bank 0, address 0, the top 32K of physical RAM will be repurposed as the common ram.

I assume you will produce an updated version of the ZZRCC monitor.  No rush, but I will integrate that into the pre-built combo disk image when it is available.

Regarding XModem, I do now remember that the baud rate needs to be reduced when using the built-in Z280 serial port.  The bank switching overhead of the Z280 is higher than the Z80 or Z180, so interrupt processing has trouble keeping up with high speed serial.

By the way, I guess I somehow got confused and started referring to ZZRCC as ZZRC at some point.  Not sure why that happened.  Anyway, I will be renaming the references in my source to consistently use ZZRCC in the near future.

Thanks,

Wayne

[Bill Shen]

Wayne,
Since a updated monitor/loader is needed, I thought maybe it is time to have a loader that boots into RomWBW directly after power up.  Since RomWBW CP/M reserve first megabyte of CF disk for non-CP/M software, my thought is having a collection of system software in the first megabyte of CF disk that includes RomWBW image, monitor, diagnostics, and CF disk utilities like RomWBW image loader.  The bootstrap software in the Master Boot Record is modified to load and run different system software.  In this case, it can load and run the RomWBW image loader instead of the monitor.  To select which software to run at power on, a configuration software (also reside in the system track of CF disk) can select and update the Master Boot Record.  If CF locked up because of software bugs, it can be re-imaged with the original CF image.  You may already have thought about this when you reserved 1 megabyte of CF disk for non-CP/M software; I like to hear your plan.  Thanks,
  Bill
PS, since the collection of system software in the 1st megabyte are likely to change frequently, there need a mechanism to update it and keep track of it.  This part may be messy...

[Alan Cox]

On Sat, 7 Oct 2023 at 14:05, Bill Shen <coinst...@gmail.com> wrote:

Wayne,
Since a updated monitor/loader is needed, I thought maybe it is time to have a loader that boots into RomWBW directly after power up.  Since RomWBW CP/M reserve first megabyte of CF disk for non-CP/M software, my thought is having a collection of system software in the first megabyte of CF disk that includes RomWBW image, monitor, diagnostics, and CF disk utilities like RomWBW image loader.  The bootstrap software in the Master Boot Record is modified to load and run different system software.  In this case, it can load and run the RomWBW image loader instead of the monitor.  To select which software to run at power on, a configuration software (also reside in the system track of CF disk) can select and update the Master Boot Record.  If CF locked up because of software bugs, it can be re-imaged with the original CF image.  You may already have thought about this when you reserved 1 megabyte of CF disk for non-CP/M software; I like to hear your plan.

The first part of a disk with a PC style partition table consists of

master boot record

2047 sectors (usually - 63 on very old partitions) for the operating system load area

So if you put it after the MBR you are actually using the space intended for the OS to load before the first partition (and RomWBW speaks partitions). That would

mean you'd end up with the bootstrap on sector 0 followed by the partition table (it does fit) then the image and still in a totally PC compatible way.

Alan

 

[Bill Shen]

Ah perfect;  2047 sector is 1 meg and the CF bootstrap code is small so it won't run over the partition table at high area of the Master Boot Record.
  Bill

[Paul dB]

On Friday, 6 October 2023 at 03:31:01 UTC+2 Bill Shen wrote:

I'm contemplating two more designs:
ZRC512, 22MHz Z80 with 512K RAM plus I2C, RTC, and WS2812B.  All through-hole components.  RomWBW capable.
Z1RCC, 18.4MHz Z180 with 512K RAM.  All through-hole components.  RomWBW capable.

Bill, on the ZRC512, you're using WS2812B 'NeoPixels'. Aren't these SMD parts? If so, perhaps, as an option for those wanting a 100% through-hole parts board, a compromise could be made by superimposing a 5mm LED footprint over the 5x5mm WS2812B footprint on the PCB. As the center of the square footprint would be empty, there might be enough space for the extra 2 LED holes there. Perhaps share the 2 LED traces with 2 of the 3 traces needed to control the WS2812B. Then the CPLD could be programmed to output the right signals for the type of device to be mounted. Would this work?

Also, instead of using a single-color LED, a 5mm, red/green, bi-color LED could be used, ie, Mouser: 859-LTL-293SJW. Here, like an ordinary LED, only 2 traces would be needed since the the direction of the current determines which color (red or green) lights up. Of course each LED requires a series current-limiting resistor. For 8 LEDs, perhaps two 8SIP isolated-resistor arrays would save some board space. 

Thanks,

Paul

[Wayne Warthen]

Hi Bill,

Yes, as Alan has already made clear, RomWBW basically just observes normal MBR partition table conventions.  Aside from the actual partition table itself in sector 0, you can use any of the space in the first 1MB of the disk.  Actually, you also need to make sure the normal MBR signature bytes 0x55, 0xAA are at the very end of sector zero.

I include the 1MB "prefix" with RomWBW and the RomWBW combo image has it already in place.  So, I do need to know how to construct the 1MB prefix from the components.  This just means I need to know the starting location and length of the CF Loader and the RomWBW image.  If a monitor is included, I will also know the details for that.  FYI, there is a file called "ZRD Disk Layout.txt" in the .../Source/ZRC folder of the RomWBW distribution that documents the (current) prefix.

I think that the current layout was dictated by an old approach of including the RomWBW image inside the actual CP/M disk image itself.  So, you may want to use more generic offsets if you change things.

Thanks,

Wayne

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/07f2247b-84a0-431a-95f7-e8cf7b979e78n%40googlegroups.com.

[Mark T]

Neopixels are also available in through hole F5 package, if you want a through hole only design.

https://www.sparkfun.com/products/12999

[Bill Shen]

Thank you Mark!  I was about to reply to Paul dB that surely a through-hole version of WS2812B would be available, or alternatively, I'll cut up a commercial Neopixel strip and find a way to mount it.  That PTH addressable LED from sparkfun is the answer.
  Bill

[Bill Shen]

Wayne,
Thanks for pointing out ZRC_disk_layout.txt.  That's a very good way to describe data organization in the first megabyte of the CF disk and I like your notes describing the process of booting up ZRC.  For ZZRCC, ZRC512, and later Z1RCC and RomWBW-capable version of Z80ALL, I will stick to that basic layout.  It is really cool to have all these space to host various system software.

I will update monitor with that layout in mind; and I'll save and restore RomWBW image assuming it is 480K.  I'll work on a RomWBW image loader and tweak the CF bootloader to load & run RomWBW immediately after power up.  Thanks,
  Bill

[Wayne Warthen]

Sounds good to me Bill.

Thanks,

Wayne

[Paul dB]

On Sunday, 8 October 2023 at 03:09:07 UTC+2 Mark T wrote:

Neopixels are also available in through hole F5 package, if you want a through hole only design.

https://www.sparkfun.com/products/12999

Thanks for the info Mark. That's one of the things I like about this group, there's always something new to learn :)

Paul

[Bill Shen]

Wayne,
I think rev0.6 of ZZRCC monitor is ready, except I have a question.  As I was updating the ZZRCC disk layout, I noticed you placed the RomWBW Partition Table at sector 0 byte 256-511.  I had thought the partition tables starts from $1BE to $1FD, followed by disk checksum of $55AA at $1FE-$1FF.  Such arrangement reserves bootstrap program from $0-$1BD.  In the specific case of ZZRCC bootstrap program, it is small enough to fit $0-$ff, but I'm worrying that other RomWBW-capable SBC may have a larger bootstrap that won't fit $0-$ff, so I'm wondering whether RomWBW has reserved $100-$1BD for other uses.

Attached is the ZZRCC_disk_layout_for_RomWBW.txt with question mark for starting address and size of RomWBW partition table.
  Bill

[Wayne Warthen]

Hi Bill,

On Thursday, October 12, 2023 at 6:36:12 AM UTC-7 Bill Shen wrote:

I think rev0.6 of ZZRCC monitor is ready, except I have a question.  As I was updating the ZZRCC disk layout, I noticed you placed the RomWBW Partition Table at sector 0 byte 256-511.  I had thought the partition tables starts from $1BE to $1FD, followed by disk checksum of $55AA at $1FE-$1FF.  Such arrangement reserves bootstrap program from $0-$1BD.  In the specific case of ZZRCC bootstrap program, it is small enough to fit $0-$ff, but I'm worrying that other RomWBW-capable SBC may have a larger bootstrap that won't fit $0-$ff, so I'm wondering whether RomWBW has reserved $100-$1BD for other uses.

Thanks for the work on v0.6 of ZZRCC monitor.

Yes, you are correct about the location of the partition table.  it exists from $1BE-$1FD followed by two byte signature.  When I put together the layout and the image building script, I found it easier to just use 256 byte chunks.  However, there is no reason that needs to be that way.  I will happily change it such that $000-$1BD is available for bootstrap code.  $1BE-$1FF.  Practically speaking, I am going to generate an empty first sector, then overlay your binary starting from $000, then overlay the partition table starting at $1BE.  So, as long as your code does not extend past $1BD, all is well.  Does this make sense?

I will try to update the image generation script and the ZZRCC_disk_layout_for_RomWBW.txt file in GitHub later today.

Thanks,

Wayne

[Bill Shen]

Wayne,
Thanks for the clarification of master boot record.  Normally I have a dedicated program to manage the bootstrap program in MBR, but since I plan to modify the bootstrap program to boot directly to RomWBW after power on, I want to incorporate the MBR write routine in ver 0.6 of ZZRCC monitor.  The MBR write routine first reads the MBR to a 512-byte buffer, writes the bootstrap program up to $1BD into MBR, then copies the original MBR data from $1BF to $1FF.  It is similar to your script that builds MBR.

Now I have a patched version of rev 0.6 ZZRCC monitor that boots directly into RomWBW after power on. 

Attached is the updated ZZRCC_disk_layout_for_RomWBW and version 0.6 ZZRCC monitor.  Thanks,
  Bill

[Wayne Warthen]

Hi Bill,

I have updated the dev branch with the changes that allow you to use most of the first sector.  Note that instead of allowing up to $1BE, I am allowing up to e$1B8.  This is because there is a disk serial number field at $1B8 that I need to use to avoid some weird issues.

Thanks,

Wayne

[Bill Shen]

Wayne,
I've tried the latest RomWBW 3.4 dev .9.  The ZZRCC CF image is working very well.  I'm studying the build.cmd for ZZRCC so I can update the monitor as well as adding more programs to the prefix.dat.  You have a very nice set up.  I'll do work locally and merge back to you once they are stable.  

I have several other RomWBW-capable designs that are boot-from-CF, so I'll use the ZZRCC build template for these designs.  I'm transitioning to 1024 directories CP/M (hd1k) for all my designs related to RomWBW.  Thanks,
  Bill

[Wayne Warthen]

Sounds great Bill.  Glad it is working for you.

-Wayne

[7alken]

hi Wayne, while this is about romless system (I am considering it too, but experimenting now on breadboard), I have Bill's, RIZ180W at 3V3 using 39VF040 flash chip - I added it to updater.asm this way (and Will is adding it to flash.com also):
.DW $BFD7 ; 39VF040  8

btw, as I now finally properly read all the RomWBW docs, its not "quite super modern", its simply "just super"  - having in mind something related to slices/assign/clrdir, hope I will be able to contribute something too

Petr

[T Gerbic]

Speaking of a little more modern, the current RomWBW has CP/M 2.2.  Any plans to swap this out for CP/M 3 with a small banked memory which would allow up to 60K of TPA.  Or is banking going to be a problem with the different hardware the ROM might be used with? If so unbanked CP/M 3 itself would be an improvement.

I have now used RomWBW on three processor cards and it is really great but in all other instances I use CP/M 3.

[Wayne Warthen]

Hi Petr,

On Sunday, October 15, 2023 at 4:21:16 PM UTC-7 tge...@gmail.com wrote:

Speaking of a little more modern, the current RomWBW has CP/M 2.2.  Any plans to swap this out for CP/M 3 with a small banked memory which would allow up to 60K of TPA.  Or is banking going to be a problem with the different hardware the ROM might be used with? If so unbanked CP/M 3 itself would be an improvement.

I have now used RomWBW on three processor cards and it is really great but in all other instances I use CP/M 3.

RomWBW fully supports CP/M 3 and ZPM3.  Also a few other OSes.  For direct booting from ROM, only CP/M 2.2 and ZSDOS are supported.  To use the other OSes you must prepare a disk from the RomWBW disk images and boot to the slice containing your desired OS.  I can provide more detail, but suggest you start with RomWBW User Guide which is included in the RomWBW distributions in the Doc directory.

Thanks,

Wayne 

[Bill Shen]

Wayne,
I'm delighted how well 0K ROM 512K RAM worked out for ZZRCC.  So using the ZZRCC template I want to revisit my earlier designs and upgrade them to ROMless, 512K RAM RomWBW.  (RomWBW is like the BORG--resistance is futile)  On my list are upgrading ZRC512 (Z80), Z1RCC (Z180), and Z80ALL (Z80), thus making the Romless RomWBW available for Z80, Z180, Z280, and all-in-one standalone Z80 computer.

Starting with ZRC512, I think I am successful getting RomWBW CF image build for ZRC512 which is basically ZRC but with 512K RAM.  I like you to look over my addition/modifications:  
1.  Build ZRC512 ROM using BuildROM script with zrc512 configuration (it is same as zrc_ram but with CPUOSC of 22000000).  This produces RCZ80_zrc512.rom
2.  Create a BuildZRC512.cmd script which is same as BuildZZRCC.cmd script, but putting all files in the subdirectory ZRC512.
3.  Create a subdirectory, ZRC512, under RomWBW\Source.
4.  In RomWBW\Source\ZRC512 are
  * Build.cmd  <--same as ZZRCC\Build.cmd but refer to ZRC512 instead of ZZRCC
  * Clean.cmd <-- no change
  * zrc512_cfldr.bin  <--Binary file of Master Boot Record up to location 0x1B8.  Modified to work with ZRC512
  * zrc512_mon.bin  <--Binary file of monitor for ZRC512, it is ZRC monitor being revised rapidly
  * zrc512_ptbl.bin  <--Same as zzrcc_ptbl.bin, no change.

With these additions, I'm able to run "BuildZRC512" in powershell and create "hd1k_zrc512_combo.img" which is 50MB image that can be copied to a CF disk using Win32DiskImager.  Inserting the resulting CF disk in ZRC512, it will boot into ZRC512 monitor, then boot into ZRC512 version of RomWBW with RAMdisk in drive A and drive B-G contains various files.  I'm including the various ZRC512 modifications in the attachment for your comments.  Thanks,

  Bill

--Resistance is futile, RomWBW is inevitable

PS, Google won't let me attach the files.  I'll send it via email

[Paul dB]

Bill and Wayne, fantastic team work! 

Just shows what can be done using Wayne's magnificent 'HAL' (RomWBW) combined with 'Thinking outside of the box' electronics from, among others, Bill :-)

Oh, and Bill's new signature '--Resistance is futile, RomWBW is inevitable' 8-)

Thanks

Paul

[Wayne Warthen]

Hi Bill,

So sorry.  I don't know why, but I did not see this post until now.  Everything you did sounds exactly right.  I'm very pleased it is all working and I would be happy to support the other designs you mention as desired.

I never got an email with the attachments.

Thanks,

Wayne 

[Bill Shen]

Hi Wayne,

For some reason I can’t post the ZRC512 files with powershell files and binary files, and my email to you failed to deliver as well.  I replaced the binary files with Intel hex files and still not uploading and blocked from emailing.  If I remove the powershell files, too, there are nothing left.  What I’ll do is creating a homepage with ZRC512 and load the files there.  

I’m currently working on Z1RCC which is Z180 version of ROMless 512K RAM for RomWBW.

  Bill

[Wayne Warthen]

On Friday, October 20, 2023 at 5:53:58 PM UTC-7 Bill Shen wrote:

For some reason I can’t post the ZRC512 files with powershell files and binary files, and my email to you failed to deliver as well.  I replaced the binary files with Intel hex files and still not uploading and blocked from emailing.  If I remove the powershell files, too, there are nothing left.  What I’ll do is creating a homepage with ZRC512 and load the files there.  

Yeah, Google/Gmail is really picky about attachments.

I’m currently working on Z1RCC which is Z180 version of ROMless 512K RAM for RomWBW.

Sounds great.

I have company for a few days, so I may not be very responsive.

Thanks,

Wayne 

[7alken]

Hi Bill,

always happy to see your new things, that Z1RCC dead-bug is cool )) ... waiting here for EPM3064 arrival, still afraid to touch my breadboard and modify the logic into PLD 22LV10 at least ... it was for a while on hold, as I had other things here to solve; probably better to try connect CF first regulary (and test it on 3V3) over the AHC logic. I need some batch timeframe to focus again ))

thanks for all your effort!

7alken

[7alken]

I dont have access to the retrobrewforum yet, here for "norwestrzh" user I have in KiCad 6(!) the SDIP64 symbol (V9938) and SDIP64 footprint drawn by me:
(its complete adapter for breadboard)
dont know if symbol/footprint import will be okay, I have here installed also KiCad7 but dont use it yet (has issues?), as the conversion back to 6 is not (easy) possible...
7alken

[Bill Shen]

Thanks for the KiCAD library for shrinkDIP64.  I've forwarded the design file to Roger ("norwestrzh").

Z1RCC prototype has reached the end point of running ROM-less RomWBW so I've started its pc board design as well as the ZRC512 board layout.  ZRC512, Z1RCC, and ZZRCC are ROM-less RomWBW implementations for Z80, Z180, and Z280, respectively.  They are all through-hole technology and 2"x4" pc boards with classic 40-pin RC2014 bus.
  Bill

[Bill Shen]

Wayne,
My last entry on the topic of Z1RCC in retrobrewcomputer forum described the process of generating RomWBW CF image for Z1RCC.  It included all the binary as well as the powershell scripts that I wasn't able to email or post on Google forum.
  Bill

[Wayne Warthen]

Thanks Bill.  I will pick up your work from there and add to RomWBW repository.  When I am done, I will let you know so you can test.

Thanks,

Wayne

[Wayne Warthen]

Hi Bill,

I have integrated your work on Z1RCC into the RomWBW development branch.  I have published RomWBW Development Snapshot v3.4.0-dev.15 which is available on the RomWBW GitHub Releases Page.  You will find "hd1k_z1rcc_combo.img" in the Binary directory.  Since I don't have the hardware, it would be helpful if you could test this.

Thanks,

Wayne

[Bill Shen]

Wayne,
Thanks for the updated RomWBW to accommodate Z1RCC.  I downloaded dev.15 and run "buildshared" followed by "buildrom" with parameters of "RCZ180" and "z1rcc", then I run "buildz1rcc" to produce the image file "hd1k_z1rcc_combo.img".  Copy the image file to a new CF disk and it will boot the monitor as it should.  However when I typed "b4" to boot RomWBW, it does boot, but with the wrong serial port speed.  The serial port speed should be 57.6K, but RomWBW's serial port is 19.2K.  I can change the terminal's speed to 19200 and type 'r' to reboot system.  (see the screen capture below)

The hardware does have a RTC and I know RomWBW does detect the RTC, but somehow the CPU's speed is calculated as 8.42MHz.  It should be 9.22MHz.

I've struggled with this issue and wanted to ask you about it.  What I did was patch RomWBW's failsafe value for CNTLB to 0x0 (originally it was 0x20), so when RomWBW couldn't figured out the correct CPU clock, it will use the failsafe value of 0x0 for CNTLB which resulted in 57600 serial port.

My hardware is one of a kind and this is probably the first Z80180 in shrink DIP64 that runs RomWBW, so it maybe difficult for you to troubleshoot this problem.  I'm solving this problem with two approaches:
1.  Z1RCC pc board is currently being fab at JLCPCB.  If the problem persisted in pc board version, I can ship you a board.
2.  I have also designed another version of Z1RCC using Z8S180 which is the same CPU used in SC126.  I'll receive the pc board at the same time as Z1RCC pcb.  I want to see if RTC works correctly with Z8S180, then go from there.

Another data point for you to think about.  ZRC512 is Z80 version of Romless RomWBW.  It also has a RTC, but RomWBW is able to calculate the CPU speed correctly using the RTC and the resulting serial port is correct.  ZRC512 is currently one of a kind prototype, but I will also receive pc board version of ZRC512 at the same time so I'll check out the RTC for Z80 ROMless RomWBW as well.

BTW, when RomWBW boots the first time, it will display the RTC clock values, but with 'R' command (Reboot System), RTC clock values are not displayed.

Below is screen capture of RomWBW.dev-15 generated CF disk
-------------------------------------------------------------------------------------------------
Z1RCC Monitor ver 0.2a 10/23/23


>boot CP/M
4--RomWBW: 4 press Return to execute command
àààüüüüàààüàüààüààüààüàààààààààüààüàààààààààüàüààààüàüààüààüààààààààüüàüààààüààüààààüàààààüàüüàààààààààààààüàààààüàààààààüàüààààààààààààààüàààààààüàüàààààààààààààüàüàüààààààààüüàüàààààààüààüààààààüàààüàüàààüàààààüàààààüàààüààüààààüüàààüàüàüààààààààüààààààüààààüàüààüàààüààüààààààüààüààààààüüàüàüàààüààüààüàààüàààààààüààààààààààààüààààààüüüàüàààààüààüüàààüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüàüààüàààààüàààüàààààààààààààààààüààààààüàààüààààààààààààààààààààüàüààüàààààààüüàààààààààüàààààààüàüàààààààààüàààààààüàüààààààààüàüààààüàüüüüààüüààààüüüüàüàààüüààh

  L           - List ROM Applications
  D           - Device Inventory
  R           - Reboot System
  I <u> [<c>] - Set Console Interface/Baud code
  V [<n>]     - View/Set HBIOS Diagnostic Verbosity
  <u>[.<s>]   - Boot Disk Unit/Slice

Boot [H=Help]: r

Restarting System...

RomWBW HBIOS v3.4.0-dev.15, 2023-10-30

Z1RCC [RCZ180_z1rcc] Z80180 @ 8.420MHz IO=0xC0
0 MEM W/S, 2 I/O W/S, INT MODE 2, Z180 MMU
0KB ROM, 512KB RAM

ASCI0: IO=0xC0 ASCI MODE=115200,8,N,1
ASCI1: IO=0xC1 ASCI MODE=115200,8,N,1
MD: UNITS=1 RAMDISK=256KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: ATA 8-BIT LBA BLOCKS=0x0001E900 SIZE=61MB
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT
FP: IO=0x00 NOT PRESENT

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ASCI0:      RS-232            115200,8,N,1
Char 1      ASCI1:      RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          256KB,LBA
Disk 1      IDE0:       Hard Disk         61MB,LBA
Disk 2      IDE1:       Hard Disk         --


Z1RCC [RCZ180_z1rcc] Boot Loader

Boot [H=Help]: c

Loading CP/M 2.2...

CBIOS v3.4.0-dev.15 [WBW]

Configuring Drives...

        A:=MD0:0
        B:=IDE0:0
        C:=IDE0:1
        D:=IDE0:2
        E:=IDE0:3
        F:=IDE0:4
        G:=IDE0:5
        H:=IDE0:6
        I:=IDE0:7

        1509 Disk Buffer Bytes Free

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

A>dir
A: ASM      COM : CLRDIR   COM : COMPARE  COM : COPY     COM
A: DDT      COM : DDTZ     COM : DUMP     COM : ED       COM
A: FDISK80  COM : FILEATTR COM : FILEDATE COM : FLASH    COM
A: INITDIR  COM : LDDS     COM : LDP2D    COM : LINK     COM
A: LOAD     COM : MBASIC   COM : NULU     COM : PIP      COM
A: PUTDS    COM : RELOG    COM : RMAC     COM : STAT     COM
A: SUBMIT   COM : SUPERSUB COM : TD       COM : UNARC    COM
A: XSUB     COM : ZAP      COM : ZCAL     COM : ZDE      COM
A: ZPATH    COM : ZSCONFIG COM : ZXD      COM : ASSIGN   COM
A: MODE     COM : RTC      COM : SYSCOPY  COM : XM       COM
A: FDU      COM : FORMAT   COM : SURVEY   COM : SYSGEN   COM
A: TALK     COM : TIMER    COM : CPUSPD   COM : CPM      SYS
A: ZSYS     SYS

[Tadeusz Pycio]

Unfortunately, the Z80180/HD64180 is not as flexible as the Z8S180 in terms of serial port speed. Its speed settings under RomWBW need to be divided by 2 on older processors to get them correct, and note that not all typical speeds will be available. RomWBW has a procedure to detect the type of processor and based on this you may be tempted to change to get the actual speed to match the set one, but I don't know how much of a software hassle this is.

[Wayne Warthen]

Hi Bill,

Some comments below...

On Monday, October 30, 2023 at 8:28:31 PM UTC-7 Bill Shen wrote:

Thanks for the updated RomWBW to accommodate Z1RCC.  I downloaded dev.15 and run "buildshared" followed by "buildrom" with parameters of "RCZ180" and "z1rcc", then I run "buildz1rcc" to produce the image file "hd1k_z1rcc_combo.img".  Copy the image file to a new CF disk and it will boot the monitor as it should.  However when I typed "b4" to boot RomWBW, it does boot, but with the wrong serial port speed.  The serial port speed should be 57.6K, but RomWBW's serial port is 19.2K.  I can change the terminal's speed to 19200 and type 'r' to reboot system.  (see the screen capture below)

OK, well, the good news is that it is basically working!  That is always 90% of the battle.

The hardware does have a RTC and I know RomWBW does detect the RTC, but somehow the CPU's speed is calculated as 8.42MHz.  It should be 9.22MHz.

This is odd.  The clock speed measurement is pretty simple.  It uses the number of times the code loops while waiting for the "seconds" digit of the RTC to tick.  I just confirmed that the measurement is working perfectly on one of my Z180 systems that is running the latest code.  So, the code loop has not changed.  Are you comfortable that your RTC is keeping reasonably accurate time?  Is anything in your design adding wait states?  I'm not talking about the Z180 programmable wait states -- I mean something external to the Z180.  

I've struggled with this issue and wanted to ask you about it.  What I did was patch RomWBW's failsafe value for CNTLB to 0x0 (originally it was 0x20), so when RomWBW couldn't figured out the correct CPU clock, it will use the failsafe value of 0x0 for CNTLB which resulted in 57600 serial port.

Yes, the incorrectly measured CPU speed is the root of this problem.  Since the ASCI port baud rates are directly derived from the CPU clock, RomWBW must know the accurate clock speed to compute the divisor correctly.  If we cannot figure out why the CPU speed is measured incorrectly, I could add a config to disable CPU speed measurement (even though the RTC is there).  In that case, the CPU speed would just be assumed to be whatever is specified in the config file.  Let me know if you want me to do that.  Not hard.

My hardware is one of a kind and this is probably the first Z80180 in shrink DIP64 that runs RomWBW, so it maybe difficult for you to troubleshoot this problem.  I'm solving this problem with two approaches:
1.  Z1RCC pc board is currently being fab at JLCPCB.  If the problem persisted in pc board version, I can ship you a board.
2.  I have also designed another version of Z1RCC using Z8S180 which is the same CPU used in SC126.  I'll receive the pc board at the same time as Z1RCC pcb.  I want to see if RTC works correctly with Z8S180, then go from there.

Interesting.  Could the DIP-64 Z180 have different opcode cycle timings?  It will be helpful to see what the two boards from JLCPCB do.  Tadeusz points out that the Z80180 is an older processor and is not typically used on the Z180 systems of RomWBW.  I am pretty sure I checked the Z80180 at some point, but maybe that is the issue.  Does the Z80180 have different instruction timings than the Z8S180?

Another data point for you to think about.  ZRC512 is Z80 version of Romless RomWBW.  It also has a RTC, but RomWBW is able to calculate the CPU speed correctly using the RTC and the resulting serial port is correct.  ZRC512 is currently one of a kind prototype, but I will also receive pc board version of ZRC512 at the same time so I'll check out the RTC for Z80 ROMless RomWBW as well.

Also interesting.  The loop counting code is necessarily different for Z80 vs. Z180 due to instruction timing differences.  With that said, I still don't know why your Z180 would not work consistently with all the other Z180 systems I support that have RTC clock speed measurement.

BTW, when RomWBW boots the first time, it will display the RTC clock values, but with 'R' command (Reboot System), RTC clock values are not displayed.

This may be a bug in the ROMless startup mode.  Doing a (R)estart on a ROMless system just restarts using the in-place HBIOS image in RAM.  The HBIOS was not originally designed to do this -- it expected to be reloaded from a fresh copy from ROM (which inherently clears all data fields).  I had to make a few fixes just to get it working.  I bet the RTC driver has a problem with this type of restart.  I will look into it.

Thanks,

Wayne

[Tadeusz Pycio]

Interesting.  Could the DIP-64 Z180 have different opcode cycle timings?  It will be helpful to see what the two boards from JLCPCB do.  Tadeusz points out that the Z80180 is an older processor and is not typically used on the Z180 systems of RomWBW.  I am pretty sure I checked the Z80180 at some point, but maybe that is the issue.  Does the Z80180 have different instruction timings than the Z8S180?

This can be ruled out, all processors in the Z180 family have identical instruction execution times.

[Wayne Warthen]

On Tuesday, October 31, 2023 at 2:04:52 PM UTC-7 Tadeusz Pycio wrote:

Interesting.  Could the DIP-64 Z180 have different opcode cycle timings?  It will be helpful to see what the two boards from JLCPCB do.  Tadeusz points out that the Z80180 is an older processor and is not typically used on the Z180 systems of RomWBW.  I am pretty sure I checked the Z80180 at some point, but maybe that is the issue.  Does the Z80180 have different instruction timings than the Z8S180?

This can be ruled out, all processors in the Z180 family have identical instruction execution times.

Thanks Tadeusz.

-Wayne 

[Wayne Warthen]

On Tuesday, October 31, 2023 at 1:33:13 PM UTC-7 Wayne Warthen wrote:

BTW, when RomWBW boots the first time, it will display the RTC clock values, but with 'R' command (Reboot System), RTC clock values are not displayed.

This may be a bug in the ROMless startup mode.  Doing a (R)estart on a ROMless system just restarts using the in-place HBIOS image in RAM.  The HBIOS was not originally designed to do this -- it expected to be reloaded from a fresh copy from ROM (which inherently clears all data fields).  I had to make a few fixes just to get it working.  I bet the RTC driver has a problem with this type of restart.  I will look into it.

Confirmed this is a bug in the ROMless startup of RomWBW.  I have it fixed and it will be included in my next release.

Thanks,

Wayne 

[Bill Shen]

Wayne,
I timed the RTC with a stop watch.  The prototype RTC is sitting on top of several active pc traces, so the clock is fast, gaining 5 seconds for every 60 seconds.  Most likely this is why CPU speed measurement is messed up.  The PC board version has an exclusion zone around the RTC so hopefully it will be more accurate.  I'll wait for the PC board to show up which should be next week.
  Bill

[Bill Shen]

DS1302 datasheet calls for exclusion area under the crystal.  That really is quite important.  ZRC512's DS1302 is accurate because the prototype board is stand off from rest of the pc board while DS1302 for Z1RCC is nestled right in the middle of the pc board and it run 10% faster while powered up.  It is fairly accurate when power off. 

Pictures of Z1RCC prototype and ZRC512 prototype with RTC marked.
  Bill

[Wayne Warthen]

OK, this explains the issue with CPU speed measurement.  Your results are interesting.  I knew about the exclusion zone, but did not expect the impact to be so dramatic.

Thanks,

Wayne

[Bill Shen]

Received Z1RCC pc board and built one up as shown in the attachment.  On the pc board is an exclusion area around DS1302 oscillator so the clock is now accurate.  ROM-less RomWBW detected the RTC and calculated the clock correctly and set the serial clock to 57600.

One remaining problem is the serial ports are still reporting 115200 when it is operating at 57600.  I'm unable to change serial port clock setting either through the configuration file parameter or RTC autodetect.
  Bill

[Wayne Warthen]

Hi Bill,

On Tuesday, November 7, 2023 at 5:56:46 AM UTC-8 Bill Shen wrote:

Received Z1RCC pc board and built one up as shown in the attachment.  On the pc board is an exclusion area around DS1302 oscillator so the clock is now accurate.  ROM-less RomWBW detected the RTC and calculated the clock correctly and set the serial clock to 57600.

Glad to hear the RTC accuracy issue was resolved.

One remaining problem is the serial ports are still reporting 115200 when it is operating at 57600.  I'm unable to change serial port clock setting either through the configuration file parameter or RTC autodetect.

So, for a Z180 running at 9.216 MHz, the highest possible baud rate for the built-in ASCI serial ports will be 57600.  I assume that your config file specifies 115200 baud.  The boot messages are indicating the target baud rate.  I suspect the ASCI driver is using it's failsafe mode because it was unable to achieve the target baud rate.  At present, RomWBW is not smart enough to reflect the actual baud rate in this scenario.  The problem is that in failsafe mode, the driver just uses a fixed divisor that it knows will work, but it is not smart enough to compute the actual baud rate in reverse.

You should probably set the serial baud rate to 57,600 in the config file since this is what can actually be achieved.  If you do that, then the boot messages should be accurate.

Thanks,

Wayne 

[Bill Shen]

This is the overclocked version of Z1RCC.  It is a 2"x4" 4-layer pc board.  The processor is changed to Z8S180 and the fast CY7C1049 RAM replaced AS6C4008; CPLD is the same 64-macrocell EPM7064S, in fact, it is the same CPLD design inside.  It has the same features of Z1RCC including RTC and I2C, except the clock is raised to 36.8MHz, 4 times Z1RCC.  The ROM-less RomWBW image is same as Z1RCC, but RomWBW is able to autodetct and raised CPU clock to 36.8MHz but keeping the serial baud clock at 115200.   The expansion bus is the classic 40-pin RC2014 bus, but I don't think it is very useful at 36.8MHz bus clock.
  Bill

[Wayne Warthen]

That thing should be really fast.  😀

-Wayne

[Bill Shen]

It is quite fast.  It can copy with verify the cpm22 slice (hd1k_cpm22) which has 1meg of files to another slice in 28 seconds; and it is fast enough to do xmodem at 115200 without hardware handshake.   Doing XM without hardware handshake may be quite useful since hardware handshake seems to be a recurring issue.
  Bill

[Andrew Lynch]

Hi Bill
Nice! What sort of data transfer rates are you obtaining? I'd think XModem without the handshaking the transfer rates would be quite high.

Thanks, Andrew Lynch

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/retro-comp/b0788926-41cd-42aa-8b88-a40c47e4f65an%40googlegroups.com

.

[Bill Shen]

I can transfer 1024K file in 1 min 54 seconds, so that's about 9K/sec.  11K/sec is the max speed, but disk writes slow down the transfer a bit.
  Bill

[Andrew Lynch]

Hi Bill
Yeah, that's pretty fast. About twice what I was seeing on earlier testing. The hardware handshaking option helps a lot, but plain old faster CPU clock really does the heavy lifting to improve serial transfer speed.

I am still experimenting with ways to accelerate data transfer. The latest idea has been using a CH376S on the Multi IO board with USB and microSD. Ultimately though it is still limited by the CPU clock speed over its parallel interface. Maybe DMA can help somewhat.

Although I noticed that transferring the RomWBW hd1k_combo.img to a USB thumb Flash drive literally took only 2 seconds for like a 50MB file. That's with my crusty old Linux notebook (Acer Aspire 1 circa 2010) so that's impressive

Thanks, Andrew Lynch

https://groups.google.com/d/msgid/retro-comp/e129938a-9f00-4fa4-b329-1078acbbc17dn%40googlegroups.com

.

[Bill Shen]

I'm using FT245 USB-parallel adapter on a 6502 project and you are right, it is astonishingly fast.  I'm thinking of streaming video data over FT245 to be played on 6502.
  Bill

[Tadeusz Pycio]

The XMODEM protocol is slow whether the hardware flow control is in operation or not. Higher transfers can be achieved with XMODEM 1k (YMODEM) or ZMODEM. Its performance is not affected by the operation of the flow control (it only starts to work when the buffer overflows). Most of the time is wasted on acknowledgements of receipt of short 128B packets (ACK or NACK in case of failure).

[Mark T]

I have ft245 on a 512k ram only z80, its very easy to make it appear to RomWBW as an ACIA, but for bootstrap it also feeds instructions to the z80 to write a bootloader to ram then continue to download 512k RomWBW. I have it running at 20MHz after replacing the 74ls156 with a couple of 74lvc1g3157 and a 74lvc1g125. It takes less than 20 seconds, I’ll try and get a more accurate time.

Currently trying to get sdcard interface running at 20MHz, swapped 74ls595 for 74ahct595 and 74ls165 for 74als165. Trying to find out why it works with crystal oscillator but not an oscillator module.

[Bill Shen]

Interesting project.  It appears to be a ROM-less, 512K RAM Z80 design that bootstraps from FT245 then loads and runs ROM-less RomWBW with FT245.  All done without programmable logic.  I hope to hear more about it.
  Bill

[Tadeusz Pycio]

I'm tempted to try to build a romless Z80 system using the attiny4313 I've used before on a Z280 system (there it used the built-in serial bootstrap function in the Z280) using code injection. I don't know if this makes any sense, other than educational, with the price and availability of flash memory. The only advantage is the smaller size of the microcontroller, which may allow you to build an SBC like Sergei's Z80-512k, but I haven't checked whether this is possible.

[Bill Shen]

The standard board is 50x100mm, so there are interests in fitting as much functions as possible in the standard format.  Yet people prefer through-hole designs, so eliminating the flash allows RomWBW capable SBC in standard board format that are through-hole design. (I consider using PLCC in through-hole socket as a through-hole design)

Depending on the design, zero flash also eliminate the rather expensive and special purpose flash programmer.  An interesting challenge may be a through-hole RomWBW SBC that does not need programmer and in 50x100mm format.

  Bill

[Bill Shen]

This is yet another RomWBW for Z80 with 512K RAM and 0K ROM, but what's interesting about it is the Z80 is operating at 3.3V and its clock is 22MHz!  The current draw while running zexall is 49mA.

What motivated this 3.3V RomWBW design is the EPM570 CPLD prototype board that I needed to prove a batch of 3.3V EPM570 CPLD are good.  After the EPM570 were proven, I was searching for a project to use this CPLD.  Through past experimentation I know the standard CMOS Z80 can operate at 3.3V at 7.37MHz, and ZRC512 is a easy-to-prototype RomWBW-capable Z80 SBC, so that's the design I decided on.

This prototype design (3VRomWBW) consists of EPM570 CPLD, Z80, 512K RAM, CF, oscillator, and DS1302 RTC.  The design is same as ZRC512, so the existing software can be reused.  What surprised me was Z80 can operate much higher than 7.37MHz.  It appeared to work at 25MHz, but not 29.5MHz.  So I settled for a default frequency of 22MHz, which happened to be the same frequency for the 5V ZRC512.

Like the 5V ZRC512, the CPLD contained the bootstrap ROM, serial port (6850 emulation), RTC interface, 16 banks of 32KRAM, RAM decode, and CF interface. CPLD resource utilization is 23%, so the design could have used a smaller and cheaper EPM240 instead.

This is 3VRomWBW prototype booting RomWBW configured for ZRC512.  RTC is working; zexall is passing, disk copy with verify is working, and xmodem file transfer is working.  It is all good at 3.3V 22MHz.  I'm quite surprised by this result.
  Bill

[Wayne Warthen]

That is a very nice result Bill.  I am very surprised you were able to run Z80 at 22MHz using 3V3.

-Wayne

[Bill Shen]

The result is definitely unexpected.   I have known Z80 and KIO can operate below 3V, but 22MHz at 3.3V is surprising.  I've added another feature: bit-bang SD card by emulating a part of PIO in CPLD.  Bit bang file transfer is actually decent, about 20KB/sec bit-bang @ 22MHz.
https://www.retrobrewcomputers.org/forum/index.php?t=msg&th=804&goto=10677&#msg_10677
  Bill

[7alken]

very nice Bill :-) my 3V3 breadboard was getting dust for months ))

[Tadeusz Pycio]

I mentioned the other day that I'd like to bypass the intermediate steps of loading RomWBW during serial bootstrap of the Z280. I think the only solution is to use DMA to rewrite the entire RomWBW to RAM from CF. This will require a minor change to RomWBW to include a "JP 0000" or "JP HB_START" instruction in the final space of the first 256 bytes of RAM for this to follow the DMA process (the PC would specify the next instruction that was already changed by this process). I should have some free time soon so I will try this method, unless someone has spotted an error in my reasoning.

[Wayne Warthen]

Adding a JP instruction at the end of the first 256 bytes of RomWBW should not be a problem.

-Wayne

[Bill Shen]

I always used the CF disk for 512K RAM 0k ROM RomWBW because the code to bootstrap from CF disk is tiny and easily fit in the logic fabric of a CPLD.  I didn't think it is possible to fit the much larger SD bootstrap code in CPLD logic fabic.  However, I'm currently exploring EPM240 CPLD which has an internal 1KB flash.  So I wonder whether 1K bytes is large enough to initialize SD, copy RomWBW image from SD to 512K RAM and jumps into 0x0 to execute?
  Bill

[Alan Cox]

On Tue, 30 Apr 2024, 04:38 Bill Shen, <coinst...@gmail.com> wrote:

I always used the CF disk for 512K RAM 0k ROM RomWBW because the code to bootstrap from CF disk is tiny and easily fit in the logic fabric of a CPLD.  I didn't think it is possible to fit the much larger SD bootstrap code in CPLD logic fabic.  However, I'm currently exploring EPM240 CPLD which has an internal 1KB flash.  So I wonder whether 1K bytes is large enough to initialize SD, copy RomWBW image from SD to 512K RAM and jumps into 0x0 to execute?

Easily. You can squash an SD init into under 256 bytes unless you've got things like big bitbanging routines to fit in too. Probably room to fit in a mini-monitor as well 8)

https://github.com/EtchedPixels/RC2014-ROM/blob/master/68HC11/romsd.s is how I do it on various different chips (that example is HC11 but it's easy enough to read I think). With a command send routine and a few preformatted commands there isn't much you need. To load more than the first sector you care whether the SD is byte or sector addressed and add 1 or 256 to the offset in the request. I always just load the first sector and run it in my bootloader because that's far more flexible and I find it's easier to debug any fancier loader off SD than keep programming chips.

Alan

[Bill Shen]

I had a question about construction of 3VZ80 based on rev1.1 artwork posted on 3VZ80 homepage.  To answer the question, I searched high and low but couldn't find rev1.1 pc board, but built up another 3VZ180 with existing rev1.0 pc board.  Only later did I realize I've never ordered rev1.1 pcb because the difference is so minor.  So I placed an order for JLCPCB.  It is a 2-layer board, $2 for 5 boards; there is a special on low-cost 8-13 days shipping, $1.50, tax $0.29 for a total of $3.79.  11 days later I have the pc boards, amazing!

I thought there was another question, but I've forgotten it!  I am posting the pictures of rev1.1 built here.  It has a tiny, tiny difference from the rev1.0 pictures posted on 3VZ80 homepage, I probably won't bother update the homepage pictures.

I don't think I've introduced this board on the retro-comp forum.  Briefly, it is a Z80 mezzanine board for EPM240 dev system.  It has 512K RAM plus a 512byte bootstrap flash inside EPM240 CPLD.  Bootstrap flash contains sufficient code to load RomWBW system file from SD card into RAM and boot into RomWBW.  It has a RTC interface and I2C interface.  The unusual part of the design is Z80 operating at 3.5V at 16MHz which is shockingly reliable for CMOS Z80 acquired randomly on eBay.
Bill

[Jeff Greer]

Brilliant work, as always, Sir.

Thank you.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/5e951007-562b-4efe-b709-4dadd0e33788n%40googlegroups.com.