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.

[kiwisincebirth]

General Update: Been a bit slow going, debugging assembled code is not easy,
and struggled for several days on a bug which turned out to be reused label
shared across an .EQU and a LABEL: on a line of code causing JP instruction to
basically JP to completely the wrong place.

The HBIOS code is developed (functional) and somewhat tested. It possess

1. An new section in HCB ($30) containing the data
2. SYSGET and SYSSET routines
3. Routines to read and write HCB to NVRAM
4. Initialisation logic called once on boot
5. 1 byte Parity check using XOR, calc includes Header,Data,Version

As well as this

1. Definitions for 2 Switches relating to Auto Boot
2. A ROM application which also builds a CP/M application
   that maintains the 2 switches

HBIOS

The HCB acts as a buffer to NVRAM through which writes (and first read) are actioned.
Initialisation can fail, for multiple reasons (no hardware, no values in NV Ram,
or CRC mismatch) and leave the HCB entries in a Default State

There is a staus byte (first byte of HCB), The status byte also acts as a Header byte
used when written to RTC. The HCB status can be in one of 3 states

• $0 - RTC Hardware not FOUND, non-recoverable status
• $1 - RTC Exists, but not initialised, or fails checksum
• "W" - Fully initialised Using RTC for switch storage.

For the 2 API's when the NVR is not initialised:

• For GETS they function without error, returing default
• for SETS (writes) they fail (error) without NVRAM.

To make NVR Ram operational an explicit SYSSET RESET - HBIOS call which sets default values
and writes these to NVRAM - This is required on first use, and also if checksum fails.
I also have a companion SYSGET which reports the overall state of NVRAM
i.e. has it been initialised.

I have placed Initialisation Logic quite late in the startup
after a section called - "FINAL DEVICE INITIALIZATION" -
It requires RTC to be functional, which happens with all the other drivers
Moving it earlier would be preferred, so other drivers could take advantage
but it would require the RTC startup logic to also be moved with it.

Only RomLDR is using it (once I add it), so the ordering is not an issue.
Once switches are created, needed by other drivers this will become an issue.

Switches

For the Auto boot, I have divided the settings into 2 seperate Switches,
couple of reasons.

1. Aligns to existing Build Config (2x) Values BOOT_TIMEOUT (integer)
   and BOOT_DEFAULT (string)
2. 2 bytes were cramp, ie. disk unit, and timeout were a bit constricted
3. Gave an opportunity to develop multiple switches and test 8 vs 16 bit values.

A slight issue I have with mapping build config "BOOT_DEFAULT" (which is a string)
into a 2 byte Unit/Slice or single byte (Char), is difficult in Assembler Expression.
and would require writing some startup code to parse the string.

Trying to map old to new config is not worth the effort, IMHO,
I just default it to "H"elp, (in NVR) which of course can be changed.
In RomLoader I intend to honour either config (NVR first, build config second)

[kiwisincebirth]

Here are the updated switch definitions

CB_SWDEFBOOT .DW 0 ; (WORD) DEFAULT BOOT NVR OPTIONS. USED By ROMLDR

Bit 15	Bits 14-8	Bits 7-0
1 = Rom App	-undefined-	App to Boot (Char)
0 = Disk	Disk Unit (0-127)	Disk Slice (0-255)

CB_SWAUTOB .DB 0 ; AUTO BOOT NVR OPTIONS. USED By ROMLDR

Bits 7-6	Bit 5	Bit 4	Bits 3-0
-unused-	1 = Auto Boot Enabled	-unused-	0 = Immediate Boot with no delay
-unused-	1 = Auto Boot Enabled	-unused-	(1-15) Timeout (seconds) before boot
-unused-	0 = Auto Boot Disabled	-unused-	-undefined-

[wwarthen]

Hi @kiwisincebirth,

This sounds pretty good. I have not looked at the code yet, so will provide more feedback after I do that.

Regarding BOOT_DEFAULT, it is intended to be more like a default command line for RomLdr. As such, it really cannot be mapped to a simple binary value. Given the current constraints of NVRAM space, I don't think it makes sense to try and capture that setting in NVRAM. I think that (currently) if the Auto physical switch is set, then BOOT_DEFAULT will be ignored. For now, maybe the same logic can apply to the NVRAM settings. The interaction of these things is getting complicated.

It sounds like there is a lot of code to work through, so give me a little time to review.

Thanks! Wayne

[wwarthen]

Hi @kiwisincebirth,

Well, as usual, your code is very clean and easy to follow. I don't see anything that is likely to cause harm to any existing functionality, so I am going to go ahead and merge this. I do see a few minor issues that need to be corrected to get a clean build in all build environments. I will make those changes shortly after the merge.

At a high level, I only have a couple notes...

It is not an issue per se, but I continue to worry about consumption of the limited HBIOS code space. This check-in seems to add about 236 bytes. Fleshing out the full potential of the NVRAM config is likely to add quite a bit more. I don't know what to do about this, it is just a background concern.

I am not sure I understand the reason for supporting WORD (16-bit) sized config values. It does allow grouping some settings, but it also adds to the code complexity. I am not asking to change this, but just make sure that it is warranted.

Thanks! Wayne

[kiwisincebirth]

I am not sure I understand the reason for supporting WORD (16-bit) sized config values. It does allow grouping some settings, but it also adds to the code complexity. I am not asking to change this, but just make sure that it is warranted.

No strong case for it, it is just a grouping of 2 related variables. In the example Unit and Slice. I haven't looked at other variables to know if it is a common use case,

if no other candidates then maybe good reason to remove, save space in HBIOS. However it will ADD code to the Client side code that now has to make 2 seperate API calls. its just a case of where you add additional complexity

[kiwisincebirth]

You may want to look at tasty basic, it should proably include "layout.inc", as currently it duplicates its LOC and SIZ EQU statements.

[wwarthen]

You may want to look at tasty basic, it should proably include "layout.inc", as currently it duplicates its LOC and SIZ EQU statements.

Definitely. Thanks.

[wwarthen]

So... I ran into some problems after the merge when I tested the full build. I have dealt with them temporarily, but need to think about better long-term fixes:

1. HBIOS ran out of space building one of the standard configurations (DUO). For now, I removed one of the default hardware drivers, but this is indicative of the HBIOS space issue.

2. I like what you did with putting SysConfig in a subdirectory. However, the current Makefile structure did not like it. The core problem is that SUBDIRS are processed after the components. So, sysconfig.bin was not ready when needed at the point that the ROM binaries were being constructed. I seriously hacked up the Makefile to make it work for now.

3. Because sysconfig.com is now needed by the disk images, we now have a dependency between the disk images and the ROM building. Specifically, the ROM processing must now precede the disk image processing. I changed this for now, but I definitely do not want this long term. I have specific reasons that I want the disk images processed before the ROM images.

4. The program name "sysconfig" is 9 chars which is problematic for a CP/M filesystem. I did not try to fix this. It won't be right on the disk images for now. However, it is easy to fix by just renaming to a smaller name.

Thoughts no these issues:

1. Nothing to do right now. However, ultimately, something is going to need to give. Increasing the HBIOS space would be quite painful and eliminate some useful features (like .COM loading of test HBIOS).

2. For now, can we put sysconfig back in the HBIOS directory (like romldr)? I know it is not as clean, but I need to do some serious work on the Makefile structure to make this work reasonably well.

3. I now realize that my idea of making SysConfig both a ROM App and a CP/M App was flawed. Not only does it cause the dependency issue, it also means that SysConfig may not be cutomized per platform. Over time, I suspect that will be important. I think it would be best to make it a ROM App only.

4. Easy. Rename SysConfig. SysConf would work, but I really don't care.

Let me know what you think of my suggestions above.

Thanks, Wayne

[kiwisincebirth]

@wwarthen

First off - I did forget to mention that the CMD files were a best attempt, I only tested the makefiles.

1. Space - HBIOS could technically be paired down, removing everything except for the initial load of the HCB table, moving everything else into (API code, write to NVRAM) into sys config itself. It would sort of make my end goal at bit more difficult -> My end goal was to have a CPM command i.e. "reboot 2.10" 2.10 being unit/slice, or even "reboot zpm" where zpm is used in a lookup table.. but basically for this to work need to reliably write to NVRam and force reboot.

2. I reran make after make clean. and yes see the issue . It was a bit of a silent error, the build didn't stop. cat: SysConfig/sysconfig.bin: No such file or directory

2a. Alternately - Consider moving it to Source/Apps or to /Source itself (alongside tasty basic). Both locations means it can be sequenced before the HBIOS and Images build.

3. SysConfig may not be cutomized per platform. Over time, I suspect that will be important. -

Trying to think ahead, IMHO, the only thing I can think of would be be important include or exclude a switch based on underlying config. e.g. I don't have a floppy drive, disable the driver and the floppy type switch disappears, -OR- Platform Z has a custom config only needed by the platform itself.

In reality it is probably sysconfig that is going to want All the platform specific changes, it has all the code in it that deals with specific switches. The code in HBIOS is mostly generic, primarily because the Switch ID (passed in API) is just used as index to the HCB table, there isn't any real explict mapping (except for 8/16 bit). A word of Caution!! would to not put any IFDEF's in the HCB table itself, since this will impact the offsets, which are currently hard coded in hbios.inc.

On balance (a) I think it is fair to move sysconfig it into the HBIOS folder. (b) I dont see any issue in having the COM file, it will just be a custom implementation which matches the Rom image (c) Can exclude the com file from disk image(s), to break the dependancy.

4. renaming it is fair, not sure how it ended up being 9 chars.

mark.

[kiwisincebirth]

I have completed rom loader changes, and tested

1. Fully configured NVRAM boot options
2. NVRAM set back to all FF's, thus no NV RAM config.
3. Disabled DSRTC driver

In all cases tested startup and autoboot functions correctly based on settings with fallback to Build Config, when NVRam not initialised. Also tested the SysConf app also full setup of variables.

I Cannot test FP Switches (missing specific hardware), but since the code is seperate and happens before my changes I don't see any potential issue.

Final Outcome to your comments from above

1. Noting Changed
2. & 3. Moved SysConfig up to HBIOS, reverting build ordering changes, and removing sysconfig.com from disk images
3. SysConfig renamed to SysConf -> still can build a COM file, but no longer included on disks images

I highly suggest reviewing an testing my build changes

I have started on the UserGuide and order MD documents.

[wwarthen]

This sounds great @kiwisincebirth.

I am out of town for the next 10 days. I don't think I will be able to do any reasonable review/testing of this until I return. I apologize, but I will work on it as soon as I return.

Thanks, Wayne

[kiwisincebirth]

@stickbreaker

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 did extend the implementation to 7 bit Unit, and 8 bit Slice, so would accomodate most users.

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.

The read and write routines have been implemented as routines that could easily be swapped out if needed. You would just need to put in a compiler directive and link it to your platform config

[kiwisincebirth]

@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.

If you look at the latest PR it is functionally complete (pending documentation), if you wanted to test please take a look.