16KB RAM - COMMAND.COM can't load - needs a way to boot guest OS or BASIC

[Torinde]

Describe the bug

I get the following outcomes per RAM amount:

• 16KB RAM (minimum for IBM PC) - COMMAND.COM failure
• 32KB - gets to prompt, but most commands don't work (e.g. mem doesn't work, but cls works - maybe only the ones integrated in COMMAND.COM work, e.g. not enough memory for the external ones?)
• 48KB - mount works, imgmount gives help (probably works?); mem doesn't work - maybe good enough to boot a guest DOS early version?
• 64KB - mount gives help (probably works?); mem doesn't work
• 96KB - mem works
• 112KB - mem works
• 128KB - blank screen with blinking cursor
• 144KB - blank screen with blinking cursor
• 160KB - mem works

So, from 96KB onwards it seems working with an oddity at 128-144KB.
64KB and below have limitations or don't work. Even if DOSbox-X shell and especially some commands in EXE/COM files can't work with so little memory - there should be at least way to boot into ROM/Cassette BASIC, guest DOS, CP/M, UCSD p-System, etc.

16KB:

32KB:

96KB:

128KB:

160KB:

Steps to reproduce the behaviour

memsize = 0
memsizekb = 128

Expected behavior

No response

What operating system(s) this bug have occurred on?

Windows 10 21H2 x64

What version(s) of DOSBox-X have this bug?

0.84.1 Win64 SDL1 VS

Used configuration

No response

Output log

No response

Additional information

No response

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[rderooy]

I think to boot DOS (1.x) you needed at least 64kB. With less you could only use the integrated BASIC in the original IBM PCs (they even had a tape connector).

[joncampbell123]

I believe I fixed this around November when I found that DOSBox-X was always loading a code page file on boot even if none was specified. There was a bug in the code page loader that used 128KB of RAM while only allocating 96KB that would fail if conventional memory was below about 160KB. I fixed the code page loader to allocate what it uses, and I fixed DOSBox-X not to load any code page for the default code page 437. If you can compile the latest source code, you should be able to use such low amounts of memory again.

As for booting MS-DOS, my past testing says that MS-DOS/IBM PC-DOS can run in as little as 64KB of RAM, and MS-DOS 2.0 as little as about 96KB of RAM. Later versions need even more RAM.

[Torinde]

Thanks! And yes, now the 128KB and 144KB behave like 112KB/160KB/etc. The rest of the test results are the same as in the first post.
48KB is the lowest where I can run imgmount and PC DOS 1.00 boots. BASIC says 22688 Bytes free. BASICA - 17239 Bytes free. DONKEY.BAS runs with sound.

Some of the "music" BAS files appear to do nothing... although maybe I'm not running them correctly? edit: MUSIC.BAS is a menu from where those are chosen and then the music plays OK.

[Torinde]

At 32KB imgmount doesn't work, so I don't know how to boot guest DOS? According to here - PC DOS 1.00 should work with 32KB RAM.
At 16KB I still get the crash as shown on the top. According to the previous link: "if the system didn't have a diskette or diskette drive (which wasn't present on entry-level IBM PC), BOOT_STRAP routine starts BASIC via INT 18H. The interrupt vector for 18H defines beginning of the 40KB ROM as the entry point to the BASIC... 16KB of RAM was enough to run BASIC programs according to the reference (SYSTEM BOARD. 2-4)" But how do I initiate that in DOSbox-X?

[Torinde]

Tried DEBUG.EXE INT18h as explained in #3028, but at 32KB DEBUG.EXE doesn't work.
Managed to boot PC DOS 1.00 at 32KB - using the Mount image and Boot image commands from the Drive menu!
BASICA - 1196 Bytes free - even the smallest BAS files can't load. BASIC - 6304 Bytes free - some BAS files run.

So, what remains is only the 16KB mode - currently DOSbox-X gives "E_Exit" COMMAND.COM failure. Can I somehow boot directly in guest PC DOS or BASIC? E.g. to start DOSbox-X, but not load a shell and to allow me to use the Drive menu mount/boot commands? Or the integrated shell/COMMAND.COM to be adjusted not to crash?

[Torinde]

48KB RAM, tried using Command line options: dosbox-x.exe -c "boot DISK01.IMG" - works
32KB RAM - doesn't work, 16KB - COMMAND.COM error. So, it seems those -c commands are executed by the DOSbox-X COMMAND.COM as usual... is there some way to skip it and boot directly from PCDOS.IMG or from ROMBASIC.ROM ?

16KB - I entered BIOS before the COMMAND.COM error - and I see "Installed OS: DOS" - maybe here can be an option to select also "Guest image", "ROM/Cassette BASIC"?

Window menu is working, but all items in Drive are grayed out:

DOS menu - change floppy image gives error:

Can some of that functionality be enabled prior to COMMAND.COM loading?
Ideally of course I would like to see COMMAND.COM working at 16KB, not sure if that can be done (e.g. with reduced functionality or by using host memory behind-the-scenes somehow).

[RNMB15]

EDIT:
Could one implement a boot menu in bios post screen from dosbox-x that you can call up with F6, where you can choose to boot from the BASIC rom, hard disk or CD-ROM and the hard disks and CD-ROM image beforehand in the (dosbox comf) can specify?

[RNMB15]

And still more in dos boot menu: boot from diskette and a menu item, start DOSBOX-X internal shell.

[RNMB15]

This is how I imagine the boot menu.
boot.txt

[RNMB15]

Wäre es möglich, den (BASIC)-Befehl in der (internen DOS-Shell) hinzuzufügen, mit dem Sie das BASIC-ROM in der (internen DOS-Shell) starten können?

[Torinde]

Another potential solution for 16KB RAM: add a .conf option(s) for booting directly (without loading DOSbox-X DOS shell) into "Guest OS image" and/or "ROM/Cassette BASIC".

Of course, the it would be good also to fix the "E_Exit COMMAND.COM" to allow the menus to be used (even if the shell prompt itself is practically unusable like at 32KB).

[Torinde]

Maybe it'll be possible to boot with 16KB RAM via loading original IBM PC BIOS per #193

[Torinde]

On real PC - IBM DOS 1.0 should boot with 16KB according to this:

Motherboard configured for 16 KB RAM
Symptom / Result: 'PARITY CHECK 1' on-screen, plus floppy drive access LED on continuously, plus floppy drive spindle turning continuously. (See note 1 below.)
Note 1: There was a successful boot if all I did was simply populate the second RAM bank, leaving the motherboard switches set to 16 KB.

But if the second RAM bank is populated - is it sure that BIOS/DOS are using only 16KB (e.g. as set by the switches)?

[Torinde]

Newer DOSbox-X behaves differently than 2022.12.26:

Build from around 2024-04-20:

• 80KB and above RAM - reaches DOSbox prompt like 2022.12.26
• 64KB to 32KB RAM doesn't reach the DOSbox prompt. Still, can boot into PCDOS via "Drive\A\Boot from disk image". Sometimes seems to need first Drive\A\mount image, then Dirve\A\boot, then Reboot guest until it boots.
  
• 16KB - unlike 2022.12.26 doesn't give COMMAND.COM error, but reaches the same blank screen/blinking cursor like for 32KB. But can't boot: "Drive A: failed to boot"
  

Build from 2024-06-17:

• 32KB and above RAM - same as 2024-04-20
• 16KB - doesn't reach the blank screen/blinking cursor due to E_Exit DOS:Not enough memory for internal tables
  

So, something changed between 2022-12-26 and 2024-04-20 (DOSbox prompt unreachable, but you can try booting images with 16KB RAM from the blank screen) and something else changed till 2024-06-17 (16KB can't reach blank screen)

I would like DOSbox prompt to be reachable like in 2022-12-26 - at least for 32KB (and even 16KB, if possible) and to keep the ability to mount/try-to-boot images at 16KB (like in 2024-04-20).

As for booting DOS at 16KB - @joncampbell123, do you think the above comment about "second RAM bank populated, but unused" may help? Does such thing make sense in an emulator?

Can I check somewhere how much emulated RAM is utilized (so that I can see if my PC DOS image uses less than 16KB)?

Can I boot into ROM BASIC (without PC DOS)?

PS. PC DOS 0.90 and PC DOS 1.10 leave less free memory for BASIC than PC DOS 1.00, so the tests here were done with 1.00

[Torinde]

PC DOS 1.00 RAM usage - with 32KB RAM, 86Box booting the same image gives the same free RAM for BASIC/BASICA as DOSbox-X. 86Box booting to ROM/Cassette BASIC without floppy - 28636 bytes free.

So, 28636 (BASIC C1.00 free RAM) - 6304 (BASIC D1.00 free RAM) = 22332 bytes used by PC DOS?
Also, 32768 - 6304 (BASIC D1.00 free RAM) - 10880 (BASIC.COM filesize) = 15584 bytes used by PC DOS?

[joncampbell123]

DOS kernel makes an INT 1Ah call during startup. SS:SP set by the BIOS is 0x60:0x0000. When memsize is 64KB or less the INT 1Ah call puts the stack pointer past available memory, and it crashes.

[joncampbell123]

I fixed the initial stack pointer. Now I can bring memsize down to 24KB before E_Exit() happens because of failure to allocate DOS kernel structures.

[joncampbell123]

files= and fcbs= values by default automatically scale according to conventional memory size (640KB or less) which helps free up memory to allow the shell to run. Now my testing lets me bring it down to a 12KB memory size. Is that small enough?

Prior to the latest commit, 24KB was minimum only because the SFT table was by default so large (for 200 files). Obviously if you're trying to run such small amounts of RAM you're not going to open 200 files!

At one point, I think I had it working with memsize=0, memsizekb=4, but that's very tight and probably not going to happen for a bit.

[joncampbell123]

memsizekb=8 is possible now. memsizekb=4 prevents anything from running except the shell, which is no fun.

[Torinde]

With the build from 1 hour ago:
24KB - DOSbox prompt is OK, but can't boot guest OS. From Drive\A\Boot... gives the error box pasted in my previous comment. From "boot a:" says that 32KB is required for guest OS

22KB, 21KB - shows 24KB and seems to behave like 24KB (probably the settings step is 4KB?)

20KB - COMMAND.COM failed to allocate main body + PSP segment

16KB, 12KB - DOS:Not enough memory for internal tables (like in my previous comment) - maybe I have to manually enter a small value for files/fcbs, I'll try that next.

I see you just made some updates, will try them right away!

[joncampbell123]

Ha, got memsize=4 to work.

[Torinde]

In the build I used above (1h ago) - in the .conf files (all three of them) it's not written "Set to 0 to automatically use a reasonable default." for files/fcbs (and also they are at 100/200) - although I see you added that to the code c60a174 ?

[joncampbell123]

Does MS-DOS 1.x support booting on systems with less than 32KB of RAM?

[joncampbell123]

In the build I used above (1h ago) - in the .conf files (all three of them) it's not written "Set to 0 to automatically use a reasonable default." for files/fcbs (and also they are at 100/200) - although I see you added that to the code c60a174 ?

Haven't updated the sample files, yet. I'll do that now.

[Torinde]

Does MS-DOS 1.x support booting on systems with less than 32KB of RAM?

I couldn't do it in 86Box (see 86Box/86Box#4548), but there is a report that it's possible on real PC - although I wonder if the trick used for that really makes it use 16KB or actually it remains on 32KB RAM. Also, does that trick make sense in an emulator?

Can I see the free/utilized/present emulated memory in the debugger or somewhere else while running?

dosbox-x.exe -console launches DOSbox-X with the log console (by default it's not visible) - I got that by trial & error (looking for a way to see early error messages before I can click Debug\Show console) - would be good to list that option at least to dosbox-x.exe /? (where I didn't find anything about console)

[Torinde]

With the latest build bddfd4d VS64, as you say - DOSbox prompt appears down to 4KB! (and shutdown.com works :))

16KB (and lower) - can mount PCDOS image, but can't boot - DOSbox gives same message as above (32KB required).

640KB - I tried mounting CP/M 86 (version 1.00 and many others from winworld) - "cannot create drive from file" (imgmount) while console says "identified 'CPM.img' as C/H/S 40/1/8 512 bytes/sector"

[joncampbell123]

So, according to the IBM PC BIOS source code, the load address is 0x7C00, or precisely at 32KB - 1KB from the base of conventional memory. https://github.com/philspil66/IBM-PC-BIOS/blob/main/PCBIOS.ASM#L1355

So I imagine that if a PC had less than 32KB of RAM, the BIOS would just go straight to BASIC, right? Or... it might try to load and execute at 0x7C00 and crash because the memory isn't there?

Now, despite that, I am going to update the BOOT command to pick a lower memory address if less than 32KB, but with a warning to your logfile that depending on the OS it might not work.

@Torinde Try using IMGMOUNT to drive 0 or 1 (BIOS INT 13h drive numbers) and add "-fs none" to mount a disk image without requiring a FAT filesystem on it.

Also: http://www.dosdays.co.uk/topics/xt_dip_switches.php

[Torinde]

Thanks, CP/M works with the above!

Good that you'll make it possible to boot below 32KB, let's see what PC DOS will do...
Can you also make Cassette BASIC to run when there's no bootable image (if it helps, 86Box does that)? boot a:/c:/*: (when with no or non-bootable images) or boot --basic? (I tried boot --bios IBMROMBASIC-F6000h-1982-10-27.ROM - doesn't work)

MEM.EXE

• at DOSbox prompt, the MEM.EXE in DOSbox-X just returns to prompt when RAM is 64KB or lower.
• inside PC DOS 1.00 the MEM.EXE from SvarDOS either results in "E_Exit Something is messing up with the memory" or gives no output and looks as if it hangs.

Any suggestion how to check free/used RAM when at 64KB? Debugger has some memory ranges/maps, but I'm not sure what is RAM, what is shadow ROM, etc. (also it's tedious to convert/sum those manually)

[joncampbell123]

@Torinde Unmapped memory reads as 0xFF and writing does not change the value. Just like real PC hardware.

If you're using memsize=0 memsizekb=64 you should see memory up until 0x10000 (65536) bytes, or segment 0x1000 (65536/16) after which only 0xFF should be seen.

[joncampbell123]

@Torinde I suppose if the ROM image is present, the BOOT command could also direct INT 18h to a DOSBox callback that loads and runs the ROM BASIC image. The only test ROM BASIC image I have is the one from the PCem ROM collection that I'm not certain does cassette functions, but it does work, and it has the entry points at the correct images that BASIC.COM and BASICA.COM expect to find (yes, MS-DOS 1.x and 2.x BASICA.COM hard-coded ROM addresses to jump into BASIC).

[Torinde]

I'm not certain does cassette functions

86Box seems to emulate the Cassette functions (haven't tested it myself, but there is Cassette checkbox in settings and their IBM PC boots directly into BASIC when no FDD image is mounted).

you should see memory up until 0x10000 (65536) bytes, or segment 0x1000 (65536/16) after which only 0xFF should be seen.

Yes, I think I see that:

I tried also "BIOS MEM" command (as shown), but what I want to check is how much of the 64KB is occupied (by DOSbox BIOS and PC DOS) or how much of it is free. Can I do that somehow?

PS. Also, I assume Debugger has some codepage issue (related to my host?) because of the ??????? symbols

[joncampbell123]

I added code to load the OS lower in memory for < 32KB. I can confirm that MS-DOS/PC-DOS will not boot on such systems. It will crash. The primary reason is that the boot sector for MS-DOS immediately loads 0x7C00 into the stack pointer. There's clearly no support in MS-DOS for less than 32KB, therefore really the only thing an IBM PC with 16KB of RAM could do is just boot into BASIC.

[joncampbell123]

Nonetheless, I added support for BOOTing with too little RAM for those who like to experiment with that.

[joncampbell123]

PS. Also, I assume Debugger has some codepage issue (related to my host?) because of the ??????? symbols

Must be. Those are supposed to be horizontal lines. Ncurses (pdcurses in Windows) is supposed to render those as horizontal lines, which should be possible in Windows 10/11 using the console in Unicode mode.

[joncampbell123]

BIOS MEM is supposed to list only the memory allocation made in the BIOS area 0xE0000-0xFFFFF. DOSBox isn't supposed to occupy the memory of the guest OS when you've booted it. Once you boot a guest OS, the only data down there should be the interrupt table, BIOS data area, and the guest OS.

DOSBox-X (or any DOSBox) doesn't have a way to view the memory allocation chain of the guest OS, especially if you're running MS-DOS/PC-DOS 1.x or CP/M. They don't use the MCB chain like later DOSes do. I don't really know what they use, to be honest.

[joncampbell123]

When the DOSBox-X DOS kernel is running, DOS KERN will show the internal kernel allocation made during setup. DOS MCBS will show the MCB chain.

DOS MCBS is a command that all forks of DOSBox, including SVN, already have. DOSBox-X has improved it a bit.

[Torinde]

Via CHKDSK we establish that PC DOS 1.00 uses 12KB, so there's a chance for it to run at 16KB (let's see if dir at least works then) - free memory should be 4240 bytes, slightly higher than 4KB...

BOOT command to pick a lower memory address if less than 32KB, but with a warning to your logfile that depending on the OS it might not work.

I didn't get the warning in the log:

Identified 'PCDOS100.img' as C/H/S 40/1/8 512 bytes/sector
Booting guest OS stack_seg=0x03e0 load_seg=0x03c0
Alright: DOS kernel shutdown, booting a guest OS
CS:IP=0000:3c00 SS:SP=03e0:0100 AX=0000 BX=3c00 CX=0001 DX=0000
2978714 ERROR CPU:Illegal Unhandled Interrupt Called 1
2978718 ERROR CPU:Illegal Unhandled Interrupt Called 1
....and those errors continue till closing

CP/M86 1.00 couldn't boot either at 16KB.
I couldn't make UCSD boot at 1MB, so I didn't try at 16KB.
edit: anything other than Cassette BASIC is placed at 0x7C00 (~32KB) by the IBM PC BIOS.

The DIP switches link you gave above mentions at DIP block 1 different combos for 1/2/3/4 banks of memory (and also for 1/2/3/4 floppies - so you can have 4 FDDs?? I don't think DOSbox-X has that yet) - and then DIP block 2 has the same combination for the first four memory sizes??? How does that work? (edit: both DIPs are interpreted jointly)

Actually, I assume that's for the 64KB-256KB motherboard and not for the 16KB-64KB one (where exactly those switches would have different combinations).

And how do you interpret the successful report for PC DOS at 16KB?

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

How does the PC BIOS detect the memory size? Is it by trying to access next and next until it fails? Then how is the memory limit passed/enforced on DOS and the real mode programs?
a) Can it be that having the second memory bank populated allowed DOS to load, but then due to the switches being in 16KB position (is this DIP1 = one bank of memory and/or DIP2 = 16KB) memory was capped by BIOS at 16KB and the rest remained unused (after the boot sequence, reverse-engineering DOS 1.0 mentioning also 0x0600)
b) The successful report is actually wrong, because having the second memory bank populated means 32KB are used regardless of what the DIP switches are set to?
c) something else

the BOOT command could also direct INT 18h to a DOSBox callback that loads and runs the ROM BASIC image.

OK, let's try that.

Must be. Those are supposed to be horizontal lines.

Changing the font makes them dashes/horizontal lines (but ugly spaced/shaped, Microsoft didn't put lot of fonts to choose from in the console dialog box - and also didn't add the encoding sub-choice), so we can count that as host side problem.

[joncampbell123]

There are DIP switches on the motherboard of the original IBM PC. You're supposed to use the DIP switches to tell the BIOS how much memory there is, among other things. Then it does a memory test within that range to confirm it.

Yes, it's that primitive.

[joncampbell123]

Are you suggesting that IBM did some kind of thing where the 16KB memory configuration might have let the 16KB repeat more than once within the first 64KB?

Also, found this: https://retrocomputing.stackexchange.com/questions/5289/how-did-an-ibm-5150-with-16kb-ram-work

[Torinde]

The source codes of BIOS, boot sector and ibmbio.com plus information about the hardware are available (and there is source of slightly newer msdos.sys and command.com), so the mystery must be solvable.

Most interesting, 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.

Then the successful report makes more sense: if 2nd RAM chip is present, since it's always enabled, BIOS can store the boot sector at 0x7C00 (in the 2nd chip, at ~32KB). BIOS POST will "register" (as a limit?) only 16KB total RAM (because it's directed so by the SW1/2), but what's the consequence of that? Who controls the memory access - CPU, BIOS, DOS or individual program's executable file?

It seems CPU and BIOS allow to use addresses beyond the POST limit, because the boot sector code at 0x7C00 gets executed.

Then, I assume DOS receives the MEMORY_SIZE, IO_RAM_SIZE or similar from the BIOS and denies loading of programs declaring a need for more than that (for PC DOS 1.x the COMMAND.COM has the role to load executables).

@joncampbell123, what do you think?

If true, then it would be possible to make a program that initially requests only 4KB, but after it takes control does some trick to go beyond its allocated space (preferably it'll have to test/manage that unallowed address space by itself - somehow testing if a chip is present there? How will these U12 transceivers respond when using address of empty bank? (edit: answer not so crucial, memory can be tested regardless of the specific behavior?) Also, maybe the extra chip(s) were 'deselected' due to hardware faults user encountered in the past, so no address outside the 0x7C00 sector is guaranteed to work properly, so testing for that will be nice as well...)