IBM PC 5150 - what happens when memory banks are empty? #50
Replies: 1 comment 7 replies
-
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.
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.
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).
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
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!
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
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.
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.
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 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! I have to try some of the hints you gave above.
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. |
Beta Was this translation helpful? Give feedback.
-
|
QDOS/86-DOS - looking at its BOOT.ASM it seems the boot vector is at 200h. Would it be possible to boot QDOS on IBM PC if BIOS is adapted accordingly? |
Beta Was this translation helpful? Give feedback.
-
|
There is PC adaptation of QDOS sources, but without binaries. I asked there if they can compile, but if you can help that's welcome too! For the 16K configuration the PC adapted QDOS has to be restored to boot from 200h. |
Beta Was this translation helpful? Give feedback.
-
In an emulator I'm trying to boot into PC DOS 1.00 with 16KB, which is reported as successful:
Per diagram of permanently connected U12 memory transievers:
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?
Beta Was this translation helpful? Give feedback.
All reactions