Booting MartyPC with 16K of RAM

[dbalsom]

Here's some information on the 5150's dip switches, courtesy of minuszerodegrees:

https://www.minuszerodegrees.net/5150/ram/5150_ram_16_64_SW2.jpg

On the 5150, MartyPC will take the specified conventional memory size from the machine configuration and "round up" to the nearest valid DIP setting. Specifying 0x04000 bytes of RAM produces a DIP switch of 00011111, which looks to match the diagram.

Note that we cannot use the latest 1982 BIOS if we want to have less than 64K of RAM - that version of the BIOS assumes that all RAM banks are populated.

Even so, if we attempt to boot using the '81 BIOS and 0x4000 bytes of memory, we get an error:

[dbalsom]

If we refer here: https://www.minuszerodegrees.net/5150/ram/5150_ram_16_64.htm

The first two characters of the error code 04 indicate in which 4k block the RAM error occurred, however the first 16K of memory comprises blocks 0-3 of motherboard bank 0. Block 4 is in bank 1, and shouldn't be used if we only have 16K of memory!

The enabled banks of memory are controlled by switch block S1. This implies that we are not setting switches 3 and 4 correctly. With 16K of RAM, switch 3 and switch 4 should be ON.

debug output shows us how S1 is set:

[2024-06-22T17:54:39Z DEBUG marty_core::devices::ppi] DIP SW1: 10011000

Switch #3 is zero! Why?

pub const SW1_RAM_BANKS_1: u8 = 0b0001_1000;
pub const SW1_RAM_BANKS_2: u8 = 0b0001_0000;
pub const SW1_RAM_BANKS_3: u8 = 0b0000_1000;
pub const SW1_RAM_BANKS_4: u8 = 0b0000_0000;

This is a simple off-by-one error. The switches are numbered 1-indexed, but I calculated the bits as if they were 0-indexed. So all the bank masks are shifted one too far to the left.

[dbalsom]

Fixing that, we can get into ROM BASIC.

I was not able to get DOS 1.0 to boot with only 16K of RAM. It seems to attempt to execute at address 0; which is where the IVT lives, and gets stuck.

[Torinde]

The IBM BIOS loads the bootsector always at 0x7C00 (~32KB) and since IBM PC DIP switches are used only to inform BIOS about the memory size, but don't actually disable the RAM banks - it's possible to boot PC DOS 1.0 in a quasi-16KB/32KB mode, where two banks for a total of 32KB RAM are populated, but DOS/BIOS uses only 16KB.

Can you add a setting for "memory banks actual population", separate from "memory size selected by DIPs"? To replicate this behavior:

• 16KB DIP, only first bank populated: 'PARITY CHECK 1' on-screen, plus floppy drive access LED on continuously, plus floppy drive spindle turning continuously.
• 16KB DIP, first & second banks populated: There was a successful boot if all I did was simply populate the second RAM bank, leaving the motherboard switches set to 16 KB.
• All four banks are always accessible, regardless of DIP switches: diagram of permanently connected U12 memory transievers
  So, while BIOS/DOS limit should be decided by the DIP switches, the ability for memory access by programs should be linked to "memory bank actual population".
  And when attempting to read from an empty bank should get either only ones or only zeros or a random combination of ones and zeroes (regardless of previous write attempts)?
• authentic, but somewhat superfluous feature will be to simulate faults in memory chips - both for the regular range (per DIPs) and for the extra range (additional populated banks). Do you support that for the regular range already, e.g. simulate faults to see if BIOS memory check routines work as expected?

[dbalsom]

The IBM BIOS loads the bootsector always at 0x7C00 (~32KB) and since IBM PC DIP switches are used only to inform BIOS about the memory size, but don't actually disable the RAM banks - it's possible to boot PC DOS 1.0 in a quasi-16KB/32KB mode, where two banks for a total of 32KB RAM are populated, but DOS/BIOS uses only 16KB.

Can you add a setting for "memory banks actual population", separate from "memory size selected by DIPs"? To replicate this behavior:

Well, what I would probably implement is a DIP override, so the conventional memory size would be the actual memory you had in the system, but you could set the DIP switches however you felt like it instead of having MartyPC try to figure them out for you. That would let you do this sort of thing.

As for simulating memory errors - well, you saw that in action just a few posts ago. We got an error 201 which is a memory failure, because MartyPC returns FF on an open bus. As far as simulating parity errors, I don't really have any plans, although that would be neat. That's the kind of thing ideally someone contributes via PR so I can concentrate on bigger features.

[dbalsom]

DOS 1.10 boots with 32K of RAM:

[Torinde]

GLaBIOS also supports less than 64KB.