This adds a loader for RomWBW based on the SC126 code. In contrast to the SC126 loader, it loads the kernel from disk offset 0x3000, same as the SCM loader. This allows to create a single disk image that works for both SCM and RomWBW.
The second commit adds a rule to create a combined disk image. The disk image rule also adds a boot command string at offset 0x17c pointing to hda1, so that the boot device does not have to be typed during boot.
The RomWBW loader contains code that will switch the I/O port base to Z180_IO_BASE before starting Fuzix. That code expects the RomWBW I/O base to be 0xc0. On my fairly new SC111 system that is the case. According to my limited research, older RomWBW versions did also use 0xc0 on SC111. The I/O base values will be printed during boot like this:
ROMWBW IO=0xC0 FUZIX IO=0x40
The RomWBW loader supports debug LEDs. Since SC111 does not have LEDs on a fixed I/O port, this is disabled by default.
This adds a loader for RomWBW based on the SC126 code. In contrast to the SC126 loader, it loads the kernel from disk offset 0x3000, same as the SCM loader. This allows to create a single disk image that works for both SCM and RomWBW.
The second commit adds a rule to create a combined disk image. The disk image rule also adds a boot command string at offset 0x17c pointing to hda1, so that the boot device does not have to be typed during boot.
The RomWBW loader contains code that will switch the I/O port base to Z180_IO_BASE before starting Fuzix. That code expects the RomWBW I/O base to be 0xc0. On my fairly new SC111 system that is the case. According to my limited research, older RomWBW versions did also use 0xc0 on SC111. The I/O base values will be printed during boot like this:
ROMWBW IO=0xC0 FUZIX IO=0x40The RomWBW loader supports debug LEDs. Since SC111 does not have LEDs on a fixed I/O port, this is disabled by default.