IBM PC 5150 - what happens when memory banks are empty?

[Torinde]

In an emulator I'm trying to boot into PC DOS 1.00 with 16KB, which is reported as successful:

There was a successful boot if all I did was simply populate the second RAM bank, leaving the motherboard switches set to 16 KB.

Per diagram of permanently connected U12 memory transievers:

SW1 and SW2 are used simply to inform the POST of bank population. They do not enable/disable RAM banks.

Do you know how will these U12 transceivers respond when using address of empty bank? (context of the question)
(asking you, because I saw "5150 Cassette tape support" as supported)

PS. does GLaBIOS support 16KB models?

[640-KB]

In an emulator I'm trying to boot into PC DOS 1.00 with 16KB, which is reported as successful:

There was a successful boot if all I did was simply populate the second RAM bank, leaving the motherboard switches set to 16 KB.

What seems to happen if you only have 16K and attempt to boot DOS is the BIOS will copy the boot sector from the disk to 0:7C00 and then jump to it without checking if it's valid code, so long as the floppy disk read was successful. If there was no memory there the PC, it would just (normally) read back as all 0xFF and execute that, effectively "crashing" as detailed here. This could have been checked for (in fact it is on hard drives) if DOS 1.0's boot sector had a MBR signature (0xAA55 at the last byte in the boot sector), however that wasn't added until DOS 2. Note: GLaBIOS does have a build-time option (MBR_CHECK) to check for this on floppy disks, however since it would cause DOS 1.0 to not boot it's off by default.

In theory the BIOS could also check that 0:7C00 is not all 0xFFs, but I don't believe that was done in the original BIOS, so they likely determined it wasn't worth doing for just that 16K RAM use case... and just crashing was fine!

Now, if you have the memory switches set to 16K it's going to test and clear only 16K. There may be more memory available, but the BIOS isn't bothering to look at it so what's going to happen there is that 5150/GLaBIOS (see below) will attempt to test up to the max amount of memory set on the switches. INT 19h only copies the boot sector to 0:7C00 and jumps to it, so in this case that memory is present and so the jump will (probably) succeed and start executing. However, the memory size reported by the BIOS in the BDA (at 0040:0013) will say 16K so even if DOS starts it might only believe it has 16K of memory (not sure what it would do in that situation). Another problem you may run into (on real hardware) is parity errors because that 16-32K of memory has not been cleared and re-written to, so the parity bits will be indeterminate from cold power up which means any access to them is likely to cause an NMI/parity error.

Per diagram of permanently connected U12 memory transievers:

SW1 and SW2 are used simply to inform the POST of bank population. They do not enable/disable RAM banks.

On GLaBIOS I do read and decode those switches to set the max RAM size to test, so whatever is selected there will be the maximum RAM that it will attempt to test and use. If you select more than there actually is, it will just stop testing once it reaches a memory segment that is likely not installed - the way that the 5160 and clones work.

Do you know how will these U12 transceivers respond when using address of empty bank? (context of the question) (asking you, because I saw "5150 Cassette tape support" as supported)

Reading your comment here, that's pretty much what I was saying above, so I'd say that's accurate. Just with the caveats of DOS thinking there's only 16K of memory and a good chance of parity errors causing boot to fail pretty quickly I'd expect.

I'm not sure exactly how the transceivers respond if RAM chips are not installed, however I would expect that you may not be able to use an ISA card for RAM in that address space (16K-64K / seg 0x0400-0x0FFF).

PS. does GLaBIOS support 16KB models?

Yes, I have a real 16K-64K 5150 and have tested GLaBIOS thoroughly on it and works well. The cassette support in GLaBIOS refers the INT 15H, AH=0-3 calls that let BASIC read and write to an attached cassette player on the 5150. Otherwise, the BIOS really doesn't care how much memory you have since it's job is just to test and count it and tell DOS or BASIC how much it believes is there.

I just tested this on 86Box and works fine with 16k. However, as a side note, I noticed that it gives a DMA TC0 error which is due to the fact that it expects the DMA refresh counter to complete at least one cycle during POST, but testing only 16K doesn't actually give enough time for that, so it gives this error. Apparently only the original 5160 BIOS performed this test, so I'll omit this in future 5150 builds for consistency. This would only ever happen with 16K of RAM and is only a warning message - it wouldn't affect the ability to boot.

[Torinde]

Thanks for the thorough reply!

tested this on 86Box and works fine with 16k

What did you select in 86Box in order to use GLaBIOS?
For me, 86Box with regular IBM BIOS boots BASIC, but I can neither get the 'PARITY CHECK 1' error, nor boot PC DOS via the quasi-16KB/32KB mode.

Logically, this 'PARITY CHECK 1' string should be coming from the IBM BIOS since even the boot sector isn't loaded when having only 16KB RAM... (0x7C00 is non existing), but per the same report this string appears when attempting to boot DOS 3.10 at 32KB and 48KB. Any idea why?

with the caveats of DOS thinking there's only 16K of memory and a good chance of parity errors causing boot to fail pretty quickly I'd expect.

I thought BIOS will check the first 16KB, so DOS thinking there are only 16KB should not result in boot failure. I expected failures to be possible only if a special program (specifically designed for the case of more-RAM-present-than-reported-by-BIOS) tries to use more than 16KB (thus going into the unchecked region). Is that incorrect?

the parity bits will be indeterminate from cold power up which means any access to them is likely to cause an NMI/parity error.

Does that mean that on reading from the memory parity is always checked and if not matching comes this error? Does that mean that to boot from 0x7C00 you have to get lucky in the parity matching? Or first do a boot with DIPs at 32KB, then change DIPs and warm reboot?

I'm not sure exactly how the transceivers respond if RAM chips are not installed

For reading from non-existing RAM, I imagine the result will be zeroes or ones or random combination of zeroes and ones. So, for the range beyond the limit set by BIOS/DOS the "special program" should:

• for one address per chip - write zeroes, read back and compare, then write ones, read back and compare - to ensure the chip exists
• for the whole range corresponding to the chips existing - do the same memory check as BIOS POST - to ensure chips are healthy
• use the "healthy" addresses as extra memory beyond the 4KB provided by DOS.

[Torinde]

I managed to start GLaBIOS in 86Box. but I can't select 16KB RAM. Only from 64KB to 640KB (maybe the GLaBIOS "machine" is defined as XT).

If I keep the Floppy controller as "None" (instead of "Internal") it first gives POST Error 1000, FDC - but then says "Disk Boot Fail" (which I didn't expect when there aren't any HDD or FDD controllers connected):
.

If I put the Floppy controller to "Internal", but don't give an image file - it doesn't boot into BASIC (maybe the "machine" doesn't have ROM BIOS associated with it), but just restarts after the "Disk Boot Fail" monster message.

If I give it a PC DOS 1.00 image it boots to DOS prompt and works. But if I run BASIC or BASICA - it starts to beep-beep-beep without stopping.

I'll open an Issue at 86Box about the above items, but posting also here since you wrote that for you it works...

[Torinde]

What about special version of GLaBIOS that copies the boot sector not to 0:7C00, but to the equivalent at 16KB? Do you think unmodified PC DOS will boot in such situation?

[640-KB]

I managed to start GLaBIOS in 86Box. but I can't select 16KB RAM. Only from 64KB to 640KB (maybe the GLaBIOS "machine" is defined as XT).

Yes, that makes sense since it uses the XT, not the PC machine type. One thing you could do is go into the machines/ibmpc folder and make a backup of either of the U33 ROMs and then replace one with the 5150 (8P) build of GLaBIOS making sure to name it the original name. That would actually give you both the 16K memory increments and the ROM BASIC too!

If I keep the Floppy controller as "None" (instead of "Internal") it first gives POST Error 1000, FDC - but then says "Disk Boot Fail" (which I didn't expect when there aren't any HDD or FDD controllers connected):

Yeah, by default GLaBIOS will behave like the 5160 BIOS and some of the other clones where it will expect that there is a floppy drive controller and not having one is an error. Technically, only the 5150 really "allowed" there to be no FDC since the 5160s were at that point all shipped with floppy controllers. The 5150 used switch 1 (IPL) on the setting DIP block to designate there is no floppy controller installed, but that was removed on the 5160s and beyond (though unofficially brought back later with some high density controllers but that's another story). Since the drive count DIP switches only went from 1-4 you couldn't actually tell the XT BIOS that you have 0 drives.

That said, you can build from source and disable the FDC check and test in GLaBIOS by setting the FDC_ENABLE or POST_TEST_SEEK to 0 which will bypass it. Let me know if you want, I can make you a build for that. There is also a FDC_IPL_SW build option that restores the same functionality as the 5150 with making switch 1 mean there's no floppy controller, but I'm not sure if that's enabled on the released builds on the github.
 

If I put the Floppy controller to "Internal", but don't give an image file - it doesn't boot into BASIC (maybe the "machine" doesn't have ROM BIOS associated with it), but just restarts after the "Disk Boot Fail" monster message.

That's because the IBM Cassette BASIC ROMs aren't part of the GLaBIOS machine on 86Box (which I'm good with due to their non-FOSS status). The way 86Box works though, in order to add another ROM to an existing machine you would have to edit the machine in the source and make your own build of 86Box. Or do what I did above and just replace the 8K BIOS ROM file on either the IBM XT or IBM PC and you can at least test things out that way and see if they work like you expect.

If I give it a PC DOS 1.00 image it boots to DOS prompt and works. But if I run BASIC or BASICA - it starts to beep-beep-beep without stopping.

I actually believe that is expected, where DOS will actually "crash" trying to boot with 16K of RAM due to not having memory at 0000:07C0 (a SE post about it). Apparently, IBM didn't really spend much time worrying about this, just expecting that it was made clear that you need 32K of RAM to run DOS.

What about special version of GLaBIOS that copies the boot sector not to 0:7C00, but to the equivalent at 16KB? Do you think unmodified PC DOS will boot in such situation?

That would be interesting to try. I would guess that DOS has that address hard coded somewhere, but I really have no idea if that's the case or not. I did find this post that states that DOS could potentially "run" in 16K of RAM, assuming that 0:7C00 did still at least contain the boot block (which would be the case in the method the OP describes). I'll give it a try sometime (though frankly I don't give it high odds that it will work).

640KB

[Torinde]

Thank you! I have to try some of the hints you gave above.

If I give it a PC DOS 1.00 image it boots to DOS prompt and works. But if I run BASIC or BASICA - it starts to beep-beep-beep without stopping.

I actually believe that is expected, where DOS will actually "crash" trying to boot with 16K of RAM

No, that test was at 64KB - the lowest 86Box setting I could select.

From the same PC DOS 1.00 image both BASIC and BASICA work when using 86Box 5150 machine with 32KB.