Expanding ROM drive

[stickbreaker]

I'm in the process of building a Z180 board based on Steven Cousins SC503, I am going to use AM29F016B EEProms (4) to give me about 8MB of storage, It will use an IO port to control which 512KB block is mapped into the Z180 memory space (0:7FFFF).

I have read through the CBIOS.asm and see the assumptions about the size of available ROM,

My first question is whether it would be a good Idea to leave the ROM device driver as is and create a new device driver that handles all of the extra ROM space (7.5MB)?

Second would it be better to subdivide in multiple slices? The AM29F016B has a 64KB erase sector size, I want to make this a R/W drive,
A sector Erase takes about 1s, each byte programmed is about 7us, so a full sector erase and rewrite would be about 1.5s. And, a 0 to 1 bit write requires a full sector erase, so a 64KB temp buffer is need to handle a sector erase, Either a RAM buffer or triangle through another ROM sector.

I'm of two minds about the R/W support, making it act like a RAM drive could end up with a Barrage of Erase/Write cycles( unused dir entry is not 0xFF). The other option is a standalone command line program that copies a file, list of files, to this ROM drive.

Any suggestions?

Chuck.

[wwarthen]

Hi @stickbreaker,

I'm in the process of building a Z180 board based on Steven Cousins SC503, I am going to use AM29F016B EEProms (4) to give me about 8MB of storage, It will use an IO port to control which 512KB block is mapped into the Z180 memory space (0:7FFFF).

Interesting. That is a lot ROM!

I have read through the CBIOS.asm and see the assumptions about the size of available ROM,

Yeah, the routine in CBIOS (and CP/M 3 BIOS) to adjust the DPB is limited and would not handle an 7.5MB ROM disk properly.

My first question is whether it would be a good Idea to leave the ROM device driver as is and create a new device driver that handles all of the extra ROM space (7.5MB)?

I need to clarify what you mean by device driver. Normally, I think of the device driver as the device support in the RomWBW HBIOS which is not part of the CBIOS. I think the existing driver (md.asm) should handle the increased size of the ROM disk OK. I don't recall anything size dependent in that driver. @b1ackmai1er added some support in md.asm for writing to EEPROMs, but I don't think it would handle your situation because it assumes a 4K erase sector size.

If you are referring to CBIOS (and CP/M 3 BIOS), it will certainly need to be adjusted. I would be inclined to hard code the ROM disk DPB and comment out MD_INIT.

Second would it be better to subdivide in multiple slices? The AM29F016B has a 64KB erase sector size, I want to make this a R/W drive, A sector Erase takes about 1s, each byte programmed is about 7us, so a full sector erase and rewrite would be about 1.5s. And, a 0 to 1 bit write requires a full sector erase, so a 64KB temp buffer is need to handle a sector erase, Either a RAM buffer or triangle through another ROM sector.

It probably won't work well to divide the ROM into multiple slices. RomWBW assumes that slices only apply to very large media and that the media will be sliced as 8MB CP/M filesystems. Creating smaller slices would require reviewing and adjusting a lot of code. Accommodating the large erase sector size is going to be painful. At a minimum, you would need to maintain a 64K blocking buffer that is only written as needed. Doing so will require a 64K chunk of RAM which will need to be stored across multiple 32K banks. You seem to understand this stuff pretty well, so you could take a shot at it, but it won't be easy.

I'm of two minds about the R/W support, making it act like a RAM drive could end up with a Barrage of Erase/Write cycles( unused dir entry is not 0xFF). The other option is a standalone command line program that copies a file, list of files, to this ROM drive.

I agree about the barrage of read/write cycles. FLASH memory does have a limited R/W cycle. A standalone program could take steps to minimize this, so I guess that would be better. However, that would be a non-trivial program to write.

Any suggestions?

I would certainly start by developing the read-only support. You will need to adjust:

• HBIOS bank select routine
• Memory layout configuration settings
• CBIOS ROM disk DPB

Once that is working, you will have a better understanding of the RomWBW disk handling and can consider R/W support.

Thanks, Wayne

[stickbreaker]

Thanks for the reply, I'll study md.asm,

After booting, is the ROM only accessed as the ROM Drive? If I page out the first 512kb will that cause any issues?

I am worried about function calls to/from ROM, my understanding currently is that HBIOS pages in/out the lower 32KB of RAM for its own use. Is there any direct reference to ROM during HBIOS calls(other than when accessing ROM Drive)?

I read through your code a couple of time (probably missed a lot), I did not see anywhere you used the DMA controller to move data? All I saw were using the MMU to change memory mapping, have the CPU move data within it's 64k range then remap. I was looking for examples of DMA usage.

One of my CLI "Ideas" was to use a "temp" RAM file as a big buffer. Create a 64k+ Ram file using CBIOS, directly search the 512KB RAM memory space for the "temp" actual data, use this found address for DMA buffer moves. By using the DMA, the memory does not need to be visible to the CPU,
When I needed to erase a 64k sector I would create the RAM temp file, find it, page to the ROM sector that needs updating, do a DMA to copy the ROM data, Start the Sector erase, use DMA to update the "temp file" with all the changes, wait for the Erase to complete (port polling of RY/BY pin, the ROM Chip is unavailable during this Erase cycle). then use CBIOS reads to loop one byte at a time, writing the "temp" file back to the ROM sector with a 4 byte DMA sequence, port RY/BY polling for each written byte.

I could page back in the normal ROM block between DMA sequences if needed.

Are you using the DMA? Do I need to concern with DMA configuration changes/consistency? My reading of HBIOS left the impression that all access to memory outside of "standard" mapped 64k is via "remap lower 32K to needed 1MB block, read byte to register, remap Lower 32k back to "standard" save data from register, repeat".

Chuck.

[wwarthen]

Hi @stickbreaker,

After booting, is the ROM only accessed as the ROM Drive? If I page out the first 512kb will that cause any issues?

It is correct that nothing actually runs from the ROM. All of the code in the ROM is copied to RAM to run. However, the ROM is still required if you return to the Boot Loader after starting a ROM application or OS. The ROM is required to reload the Boot Loader and to load any ROM-based application or OS if chosen.

I am worried about function calls to/from ROM, my understanding currently is that HBIOS pages in/out the lower 32KB of RAM for its own use. Is there any direct reference to ROM during HBIOS calls(other than when accessing ROM Drive)?

There is no direct reference to the ROM by HBIOS or an operating system other than the ROM drive.

I read through your code a couple of time (probably missed a lot), I did not see anywhere you used the DMA controller to move data? All I saw were using the MMU to change memory mapping, have the CPU move data within it's 64k range then remap. I was looking for examples of DMA usage.

At present, I am only using DMA to copy memory on a Z280. I intentionally do not do this for Z80 because most of the Z80 systems I support do not have a DMA controller. I have always intended to implement DMA memory copies for Z180, but have not gotten to it.

One of my CLI "Ideas" was to use a "temp" RAM file as a big buffer. Create a 64k+ Ram file using CBIOS, directly search the 512KB RAM memory space for the "temp" actual data, use this found address for DMA buffer moves. By using the DMA, the memory does not need to be visible to the CPU, When I needed to erase a 64k sector I would create the RAM temp file, find it, page to the ROM sector that needs updating, do a DMA to copy the ROM data, Start the Sector erase, use DMA to update the "temp file" with all the changes, wait for the Erase to complete (port polling of RY/BY pin, the ROM Chip is unavailable during this Erase cycle). then use CBIOS reads to loop one byte at a time, writing the "temp" file back to the ROM sector with a 4 byte DMA sequence, port RY/BY polling for each written byte.

Something like this is certainly possible on a Z180. Not possible on Z80. Does not sound trivial and could not become part of the generic RomWBW distribution. 😀

I could page back in the normal ROM block between DMA sequences if needed.

I think it would be a RAM block, but yes.

Are you using the DMA? Do I need to concern with DMA configuration changes/consistency? My reading of HBIOS left the impression that all access to memory outside of "standard" mapped 64k is via "remap lower 32K to needed 1MB block, read byte to register, remap Lower 32k back to "standard" save data from register, repeat".

I am only using DMA for Z280, so there is no conflict with your goal. My current mechanism for moving memory between banks is to use a bounce buffer of 64 bytes. LDIR operations are used to do the actual moves. Yes, it is repeated as needed, but the 64 byte buffer is reasonably optimal. It is unusual for any more than 128 bytes (logical CP/M sector) to be moved at one time so there is actually not as much bank flipping as you might think.

Thanks, Wayne

[stickbreaker]

@wwarthen

Something like this is certainly possible on a Z180. Not possible on Z80. Does not sound trivial and could not become part of the generic RomWBW distribution. 😀

Ya, I don't think my custom board will ever be distributed. I looked through md.asm, flashlib.inc and hbios.asm; looks like the max 32k blocks of ROM is 128 (0x00:0x7F) my layout would exceed this, so I'll have to decide if 4mb is enough or if I need to find a way to fudge the block numbers.

Thank you for the quick replies 😀
I'll build my board and see how much customization is required to boot the Z180 (sc503). I can see a glimmer of just stretching the ROM Drive out to 3.75MB without too much effort. If I can get readonly ROM Drive at 3.75MB that'll give me something to work with to generate a file manager app for the ROM drive. It'll be fun to see if I can remember my Turbo Pascal 3.01 skills (38 years ago!).
🫢

Chuck.

[lynchaj]

HiIf you're interested in using DMA with large ROM and/or RAM banks, I'd suggest building a duodyne system first to help design, test, and proof-of-concept your ideas so they can be rolled into RomWBW. duodyne supports a Z80 processor with two DMA channels, along with a ROMRAM board that can store up to 4MB of Flash ROM and/or Static RAM.  Also, you can have multiple ROMRAM boards in your system for greater memory capacity. You can use the DMA with the Flash memory ROM drive for memory-to-memory transfers so it sounds like a good test bed for your ideas.  Plus, if you get them working, they can be added to RomWBW to the benefit of all the supported platforms. Especially since the duodyne hardware and software has already been developed and tested, I think it would make a good platform for your idea of expanding the use of DMA.  A minimal system is comprised of a Z80 processor, ROMRAM, and 4-slot or 8-slot backplane. You can find duodyne information here: https://github.com/lynchaj/duodyne Good luck with your project whatever you decide to do.  Thanks, Andrew Lynch On Wednesday, May 22, 2024 at 10:57:26 PM EDT, Wayne Warthen ***@***.***> wrote: Hi @stickbreaker, After booting, is the ROM only accessed as the ROM Drive? If I page out the first 512kb will that cause any issues? It is correct that nothing actually runs from the ROM. All of the code in the ROM is copied to RAM to run. However, the ROM is still required if you return to the Boot Loader after starting a ROM application or OS. The ROM is required to reload the Boot Loader and to load any ROM-based application or OS if chosen. I am worried about function calls to/from ROM, my understanding currently is that HBIOS pages in/out the lower 32KB of RAM for its own use. Is there any direct reference to ROM during HBIOS calls(other than when accessing ROM Drive)? There is no direct reference to the ROM by HBIOS or an operating system other than the ROM drive. I read through your code a couple of time (probably missed a lot), I did not see anywhere you used the DMA controller to move data? All I saw were using the MMU to change memory mapping, have the CPU move data within it's 64k range then remap. I was looking for examples of DMA usage. At present, I am only using DMA to copy memory on a Z280. I intentionally do not do this for Z80 because most of the Z80 systems I support do not have a DMA controller. I have always intended to implement DMA memory copies for Z180, but have not gotten to it. One of my CLI "Ideas" was to use a "temp" RAM file as a big buffer. Create a 64k+ Ram file using CBIOS, directly search the 512KB RAM memory space for the "temp" actual data, use this found address for DMA buffer moves. By using the DMA, the memory does not need to be visible to the CPU, When I needed to erase a 64k sector I would create the RAM temp file, find it, page to the ROM sector that needs updating, do a DMA to copy the ROM data, Start the Sector erase, use DMA to update the "temp file" with all the changes, wait for the Erase to complete (port polling of RY/BY pin, the ROM Chip is unavailable during this Erase cycle). then use CBIOS reads to loop one byte at a time, writing the "temp" file back to the ROM sector with a 4 byte DMA sequence, port RY/BY polling for each written byte. Something like this is certainly possible on a Z180. Not possible on Z80. Does not sound trivial and could not become part of the generic RomWBW distribution. 😀 I could page back in the normal ROM block between DMA sequences if needed. I think it would be a RAM block, but yes. Are you using the DMA? Do I need to concern with DMA configuration changes/consistency? My reading of HBIOS left the impression that all access to memory outside of "standard" mapped 64k is via "remap lower 32K to needed 1MB block, read byte to register, remap Lower 32k back to "standard" save data from register, repeat". I am only using DMA for Z280, so there is no conflict with your goal. My current mechanism for moving memory between banks is to use a bounce buffer of 64 bytes. LDIR operations are used to do the actual moves. Yes, it is repeated as needed, but the 64 byte buffer is reasonably optimal. It is unusual for any more than 128 bytes (logical CP/M sector) to be moved at one time so there is actually not as much bank flipping as you might think. Thanks, Wayne — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>