Rom Loader - Slice Inventory

[kiwisincebirth]

I am wondering if this small utility is useful. The reason for it is to provide a list of bootable media, the existing Device Inventory doesn't really do this. It comes in useful when I have to boot from a slice I don't normally use, and prevents me having to guess, or remember it, or find a post-it note somewhere

It takes around 230 bytes in Romldr. It works by interrogating Sector 3 of each slice looking for valid signature, and printing the Volume label. The labels below were manually set using ZP/ZAP, but it is easy enough to update Loader.asm (there are 5 of them) with the correct labels, excepting NZCOM/Z3PLUS which don't have a loader.

Of course a small CP/M application to set the label would also be useful.

Boot [H=Help]: h

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

Boot [H=Help]: s

Unt/Sl Drive           
------ ----------------
2.20   CP/M 2.2
2.21   ZSDOS 1.1
2.22   NZCOM
2.23   CP/M 3.0
2.24   ZPM3
2.25   Z3PLUS
2.26   QP/M 2.7
3.10   Unlabeled
3.11   Unlabeled
3.12   Unlabeled
3.13   Unlabeled
3.14   Unlabeled
3.15   Unlabeled
3.16   Unlabeled

[wwarthen]

Hi @kiwisincebirth,

This is very useful and something I had always intended to do. This was the original concept for the label field of the third sector.

The problem is that we don't have 230 bytes of space available in RomLdr (when all of the features like AUTOCON and DSKY are enabled). The size of RomLdr is constrained by the need to include it in the Application Load (.com) variants of RomWBW which must fit within the TPA in order to load.

Both DbgMon and RomLdr are needed in the Application Load binary. It looks like there might be some slack in DbgMon that we could trade off. Not thrilled with this idea though because there are definitely some enhancements that DbgMon could benefit from that will need that space.

Thanks, Wayne

[wwarthen]

@kiwisincebirth,

If you want to add this functionality within conditionals, that would be fine. That way, it could be optionally used in those configurations that have the space for it.

Thanks, Wayne

[wwarthen]

An even better idea... Create a new ROM app that does this. It would look the same to a user -- they just pess a letter in RomLdr. I still have an entire 32K bank of ROM available for ROM apps.

Thanks, Wayne

[kiwisincebirth]

An even better idea... Create a new ROM app that does this. It would look the same to a user -- they just pess a letter in RomLdr.

Works for me

I still have an entire 32K bank of ROM available for ROM apps.

I had considered the use of Rom Bank 3, aligning it to how rom bank 2 (from build perspective), ie. making it a more general purpose, and when needed, lace applications in this bank. Had also considered defining and partition the banks. i.e.

• Rom Bank 2 is for General Applications i.e. forth, basic, tbasic, game, easteregg, userrom.
• Rom bank 3 is for System Capability i.e. S100, NetworkBoot, RomUpdater, NVRConfig, Device/Slice Inventory, Fonts

While the above looks like a good split, where an app is located is arbitrary, so not actually that important.

I saw (and commented on a PR) which seeks to use the third rom bank for fonts. The PR seems to move away from treating bank 3 as general purpose, and making it very specific. IMO would be better to make bank 3 more general purpose first, then move things into it.

[wwarthen]

Hi @kiwisincebirth,

Your concept of how to divide binaries between ROM banks 2 & 3 looks about right to me.

I commented on the ROM bank PR and I think that will bring it in sync with your suggestion.

Getting back to the Slice Inventory app, I certainly like it, but would prefer to hold off until after v3.5. There are now multiple things pending a better definition of the use of ROM bank 3. I would like to deal with the holistically in v3.6.

Thanks, Wayne