Front Panel Switch Enhancement

[kiwisincebirth]

Motivation: When I boot i have to type the name of the disk and slice. and 90% of the time it is the same. While I can customise the ROM and set a default, this is not very user friendly.

Alternatives: Front panel switches, while posible, does reqire additonal hardware, and have found drive selection not very flexible. i.e. I have my OS's on Slices 10-15, and data on slices 0-9, this means I get all data drives mapped consistently starting at D: an a single os drive mapped to A: Clearing booting slices above 7 is not possible using switches, so wont work.

Idea:

In Systems with RTC that has NV RAM store the FP Switches in NVRAM replacing need for physical switches

Extend the Switches themselves from 8 -> 16 bits, to store additional data to improve the boot experiance. 16 bits works well with current API's - that return switches in L, and leave H = 0, which in souce code a comment says for future. Potentially physical switches could extend to 16 bits also, if really needed.

Additional switches 8->16 could be used for

• Specifying Timeout for Auto Boot, (curenlty there is no timeout for switchs)
• Improved Disk/Slice selection
• amnything else ?

A CP/M app, (or ROM app) to change switch data in RTC NVRAM would be required

During boot (romldr) RTC NVRam would be read, and if detected would use the switches to :

2 Modes of operation during boot

• Auto Boot - "with timeout" - will boot using switches if timeout occurs Menu is displayed, if timeout > 0
• Manual Boot - Defaut option (pressing ) comes from Switch data currently default comes from ROM (configured during build)

If RTC NVRAM is present, and switches esist in NVRAM, then The above Replaces the the use of the following in ROM build config.

• BOOT_DEFAULT - string - Typically "H"
• BOOT_TIMEOUT - seconds before default boot occures.

Otherwise the above values would be used as they are today.

Switches

H Register (New) contains

Bit 7 - = "1" - Virtual/Extended front panel, identifies 16 bit switches Bit 6 - Reservered - Future Bit 5 - Reservered - Future Bit 3-4 - BOOT_TIMEOUT in seconds (0-3) 0=immediate, applies to auto boot Bit 0-2 - Disk Unit to Boot (0-7), 8 drives should be enough?

L Register (Changed) is:

Bit 7 - (unchanged) CRT/SER CONSOLE Bit 6 - (unchanged) SEC/PRI CONSOLE Bit 5 - (unchanged) AUTO/MENU BOOT - Auto boot / Default Boot Options Bit 4 - (unchanged) DISK/ROM - Disk or Rom Boot Bit 3 - (replaced) FLOP/HD - Replaced with Disk Unit in H Register Bit 0-3 - (changed) DISK / Slice to Boot (0-15) was just bits 0-2 (0-7) Bit 0-2 - (unchanged) ROM / application to boot

Changes

With 16 bit switches manual boot switch sets the default pressing options. But "H" can still be configured. Currently with 8 bit Manual turns off the Auto boot. the code here is quite different and could be consolidated.

NVRAM

Byte1 -> Header byte indicating type of data, and bytes used i.e. 3, like directory entry Byte2 -> H Register contents Byte3 -> L Register Contents Byte4 -> Checksum (XOR=0), of H, L, to confirm that data is valid

Header Byte (1): I Dont know if NVRam is used for anything else, and have included this (if nothing else exists), to allow other users of NVRAM to store data and not just overrite other user data. There colud also be a Byte 0 signature to identify this as NVRAM that has being used in this way, but maybe overkill.

[wwarthen]

Hi @kiwisincebirth,

The use of NVRAM is long overdue and was always intended to be a way to store individual system configuration.

I generally like the where you are going with the concept of extending the bit switches via NVRAM. I do need to be clear that we cannot redefine the meaning of any of the existing 8 switches on a system without NVRAM. The current switch functions are the result of prior community discussion, and more importantly, they are labeled on the front panel being produced by Spencer Owen. I really can't change the definitions out from under him or the community.

With that said, it seems reasonable to find a way to modify the behavior of the switches if (and only if) the NVRAM contains supplemental configuration data. For example, perhaps the 8 values currently available for slice could refer to disk/slice pairs in NVRAM. In other words, if NVRAM exists and has been properly configured, the 8 values for slice become an index to refer to the disk/slice to boot as configured in NVRAM. This is just an example. I have not thought a lot about this and I am not specifically pushing for this idea.

An application will need to be created to view/modify the NVRAM configuration data. This should be a ROM-hosted application to ensure it is always available and easy to access.

It is possible for a user to program the NVRAM incorrectly and wind up with an unbootable system. Even a hardware change could cause this. So, there needs to be some kind of failsafe process to do a "clean" boot.

I do believe a checksum is appropriate and it should include the ROM version being booted as part of the calculation. This is to protect us from the NVRAM content definition changing in future releases. It will, of course, force a user to rerun the NVRAM configuration tool upon ROM upgrade. I think that is reasonable.

Let's continue discussing this.

Thanks, Wayne

[MartinR-UK]

I really like this idea and have long thought that the RTC NVRAM, where it exists in a system, could be used for just this sort of configuration thing. I don't have the necessary skills to help with design or coding etc, but I'm very happy to help test code against my SC126 system if it helps.

[kiwisincebirth]

I do need to be clear that we cannot redefine the meaning of any of the existing 8 switches on a system without NVRAM. The current switch functions are the result of prior community discussion, and more importantly, they are labeled on the front panel being produced by Spencer Owen. I really can't change the definitions out from under him or the community.

I do agree with you here I do realise the importance of backward compatibility

With that said, it seems reasonable to find a way to modify the behavior of the switches if (and only if) the NVRAM contains supplemental configuration data.

The initial post I think covered this. Bit 3 (FLOP/HD) was the only change, since 1 bit to select the disk unit was too constricting, i moved it into the upper byte and extended it to 3 bits to select the unit #. This left an unused bit to extend the slice into 4 bit precision, which is just adding a bit. clearly the existing code would have understand difference between 8 and 16 bit values.

It is possible for a user to program the NVRAM incorrectly and wind up with an un-bootable system. Even a hardware change could cause this. So, there needs to be some kind of failsafe process to do a "clean" boot.

I was trying to avoid this if possible by how it is designed, were you thinking of a specific example? Did you have something in mind for "failsafe process" ?

I think a useful task would be to identify a list of candidate config values that could be stored in NVRAM ? ideally common things users would change, but not things that would break the boot if incorrect (e.g. no IO addresses)

I have been reading other posts that suggest there may be a lot more candidates for configuration, e.g. RAM Drive Size, Floppy Disk Type. However these wont fit in 16 bytes.

Thus

I think my initial thought/design might be a bit constrictive, ie.e 16 bits (actually 15), is not really enough. Thus I am thinking a new API for getting and setting 8/16 bit switch values.

#### SYSGET (&SET) Subfunction 0xC0 -- Get Switches (SWITCH)

| **Entry Parameters** | **Returned Values** |
|----------------------|---------------------|
| B: 0xF8              | A: Status           |
| C: 0xC0              | HL: Switch Value    |
| D: Switch Key        |                     |

where Switch Key is an id (from known list) which identifies which bytes(s) in NVRAM to return, and is it a 8/16 bit value. This API would handle all the translation, verification of checksum, initialisation, etc, but at the end of the day is just a wrapper around the RTC apis

For the auto boot capability, the NVRam switches could take precedence but if disabled H: Bit7 = 0; then the FP switches can be used as normal. Here is what Auto boot could look like if implemented in the API as Above

H: Bit 7 - AUTO BOOT Auto boot (True overrides ignores FP switches) default=false -> Same as FP Bit 6 - DISK/ROM - Disk or Rom Boot -> Default -> ROM -> Same as FP Bit 5-4 - BOOT_TIMEOUT in seconds (0-3) 0=immediate -> default=3 Bit 3-0 - DISK UNIT to Boot (0-15) -> default = 0 Bit 3-0 - ROM / application to boot -> default = "H" -> same as FP L: Bit 7, 6 - Reserved? Bit 5-0 SLICE ( 6 bits ) - For Disk Boot, the Slice Number

Other things:

WizNet - I have also read that CPNET WizNet code stores config in NVRAM, which could be problematic ?

Space - Also a DS1302 only has 31 bytes (others seem to be >), so we have to be mindful of this, since adding lots of config could quickly consume this storage.

[wwarthen]

Hi @kiwisincebirth,

I am generally happy with the direction you are proposing. I think I misunderstood your original comments regarding the L register. I had interpreted the L register definition and the "changed" bits to imply the definition of the physical switches change also. Sorry for my misunderstanding.

I want to take a little more time to review and consider the specifics of the bit values you are proposing. Part of this process needs to be fully fleshing out the desired NVRAM configuration settings, so I want to start a list of everything to be addressed. I really do want to keep this simple, so the list should be fairly small, but there are some key items that I really think would be helpful.

I also want to think a bit more about the interaction between the physical switches and the NVRAM on a system that has both. On a system that has both, it seems more intuitive to me that the physical switches would take precedence. However, I realize this doesn't solve your problem of expanding the disk and slice value ranges.

One last comment at this point. The NVRAM API is kind of a mess. I never thought it through properly. It was fine originally when there was only one RTC/NVRAM device being supported. It really fell apart when additional devices were added. The good news is that nothing really uses NVRAM yet, so now is the ideal time to straighten it out.

Oh, and regarding the CPNET WizNet. It is using it's own/separate NVRAM, so that is not an issue for this exercise.

I will provide some more thoughts as soon as possible.

Thanks, Wayne

[wwarthen]

OK, so here are a few more thoughts now that I have had a little more time to think through this.

First of all, here is a starting list of stuff I think should be configurable via NVRAM in addition to the items you have already mentioned.

• CPU speed (HBIOS has the concept of 4 logical speeds: half, full, double, and quad), 2 bits total.
• Wait states (memory and I/O), 4 bits each, 1 byte total
• Serial Port configuration (1 byte per port should do it, baud, parity, stop bits, and flow control), 4 ports, 4 bytes total
• Floppy drive unit type (none, 3.5DD, 3.5HD, 5.25DD, 5.25HD, 8DD), 4 bits per drive (allows for expansion) and 4 floppy drives, 2 bytes total.

Understanding that the physical switch definitions are not changing, I am not too concerned with trying to keep the first byte of NVRAM the same as the switches. As long as the switch settings can be mapped into the NVRAM byte definitions in a straightforward way, it is fine. In fact, you might consider allowing a full byte for slice since there can be 256 slices on a disk. I have a couple systems that have more than 8 disk drives

Probably obvious, but the NVRAM configuration program should be part of the ROM to ensure it is always available and is in-sync with the ROM. If the NVRAM definition should change, this would ensure the running ROM and config program are matched. We will need to find a place to put this application in the ROM. There is a spare bank (32K) in ROM that is available for most systems. For ROMless systems, a small bank layout change is required. There is also a "tiny" memory layout that cannot accommodate this at all -- a CP/M program version of the config program will need to suffice.

I am not sure that an API is really required here. The NVRAM data would be for internal HBIOS use. HBIOS has an area called the HCB (Hardware Control Block). It is used for this type of data already. I think it would be simplest if an NVRAM image was copied to this area at boot and is then available as simple memory accesses by the HBIOS as needed. If there is no NVRAM, the default values would be used (from the build config file).

As currently proposed, an NVRAM bit would indicate that the NVRAM overrides the physical switches. Intuitively, it seems like the physical switches should override the NVRAM as desired. Yes, I know that is problematic given the physical switch definitions. It is the case that the physical switches were intentionally defined such that all zero bits is equivalent to no physical switches present. I am wondering if NVRAM settings could apply if the physical switch settings are all zero. If any switches are set to 1, then the physical switches would override the NVRAM. This would only apply to the NVRAM settings that overlap withy the physical switches. Other NVRAM settings (serial port config, floppy config) would always be active.

Regarding my failsafe concern. An example of this would be if the user configured an immediate auto-boot to an IDE device. If the IDE device failed, the user could be stuck in a situation where booting the system goes right to a device failure. In some cases, the system may be able to detect and recover from such a failure, but that depends on the nature of the failure. I may be making too big a deal of this. In a worst case scenario, a user could remove the NVRAM battery to erase the NVRAM.

Those are my thoughts for now.

Thanks, Wayne

[kiwisincebirth]

I also want to think a bit more about the interaction between the physical switches and the NVRAM on a system that has both. On a system that has both, it seems more intuitive to me that the physical switches would take precedence.

At this early stage, I agree. The only overlap with switches is the auto boot, so i don't believe it is problematic, if FP Switches Bit 5 "AUTO" is set then process as does today, otherwise check for NV Ram Auto Boot config. The code that processes auto boot itself can remain the same

One last comment at this point. The NVRAM API is kind of a mess. I never thought it through properly. It was fine originally when there was only one RTC/NVRAM device being supported. It really fell apart when additional devices were added. The good news is that nothing really uses NVRAM yet, so now is the ideal time to straighten it out.

Will use API's as they are today for the present, but let me know what future state might look at.

the NVRAM configuration program should be part of the ROM to ensure it is always available and is in-sync with the ROM

I am using usrrom.asm as basis for A rom app, currently builds and flashes OK. it in the same rom bank as usrrom, it looks easy to move. The hardest part was fining an unused alpha character for the menu option.

Boot [H=Help]: L

ROM Applications:
  ...........
  X: XModem Flash Updater
  W: RomWBW Config
  U: User App

Boot [H=Help]: W

Loading RomWBW ConfigUser App...

Configure NVRAM
Press a key to return to Boot Loader.

Small Computer SC126-mp [SCZ180_sc126_map] Boot Loader
Boot [H=Help]: 

I am not sure that an API is really required here. The NVRAM data would be for internal HBIOS use

The reason i think this might be necessary, is romldr.asm (which handles auto boot), and rom config application (which i based off usrrom.asm), both use RST 8 calls to access HBIOS. Also if a CP/M app is going to configure NVRAM, do we really wanting it to write directly using existing HBIOS RTC API's.

[kiwisincebirth]

@wwarthen

FYI: I am just working on the autoboot feature at present, keeping aligned with everything discussed.

Updated definition

Byte 0:
Bit 7 - AUTO BOOT Auto boot, default=false
Bit 6 - DISK/ROM - Disk or Rom Boot -> Default=ROM
Bit 5-4 - BOOT_TIMEOUT in seconds (0-3) 0=immediate -> default=3
Bit 3-0 - DISK BOOT Unit to Boot (0-15) -> default = 0

Byte 1:
Bit 7-0 DISK BOOT SLice Number to Boot -> default = 0 
Bit 7-0 ROM BOOT (alpha character) Application to boot -> default = 0 translates to "H"

[wwarthen]

Sounds good @kiwisincebirth.

I am fine with using an API at this point. romldr does currently interrogate and manipulate the HCB for various information. I suggest you proceed as you plan for now, but I may look at eventually keeping a shadow copy of the NVRAM in the HCB... someday...

Thanks, Wayne

[stickbreaker]

@wwarthen

it is fine. In fact, you might consider allowing a full byte for slice since there can be 256 slices on a disk. I have a couple systems that have more than 8 disk drives

I think more than 8 bits should be allocated to identifying Boot Device/Slice.

With my current home brew, I am going wild with SPI devices, in addition to original SDCard, I have 31 SPI devices on the bus, multiple SDCards,, Flash (512kB clear up to 512MB), Battery Backed SPI RAM as floppy devices (512KB per device, currently 4 at a time).

With my current setup I use 8 bit Device and 8 bit Slice values.

I don't know if any of this will hit mainstream, I am playing around with a 8bit parallel i2C controller, so, it is possible that I could use I2C EEPROM as storage devices,

I think you should add an API that retrieves the config values, The API code could be board specific. Not just assuming the RTCC has RAM. I am possibly thinking about Boot Sector (SDCard) configuration, I have thought about having a boot slice value in the boot sector partition record so I can just configure each SDCard to boot to an individual Slice when inserted. The HBios "boot device" would point to the Specific SDCard/SPI device an the actual booted slice would be identified from on device storage.

Chuck.