• Please review our updated Terms and Rules here

Whats the bare minimun to boot DOS?

N

NicolasF

Experienced Member
Joined
Jun 28, 2006
Messages
255
Location
Argentina
Hi,

I need to develop a system that will be able to boot DOS with the absolute minimum.
Since I haven't been able to find a project like this I'll have to develop both the firmware and the board.
My guess for the hardware would be:

  • 1Mb of static RAM
  • CPU 8088
  • UART1 (used as both monitor and keyboard)
  • UART2 (a micro-controller with an SD card will emulate a floppy drive. The SD will have disk drive images)

maybe I can get away with using the PIT, and PIC I'm not sure about that...

And the BIOS layout would be:

  • CPU check routines
  • RAM check
  • Interrupt vector initialize
  • DOS bootstrap loader
  • INT 10 - Video (this one will route all characters to UART1)
  • INT 16 - Keyboard (routine all typed chars to UART1)
  • INT 13 - Disk services

Will this work?
 
It will work, I'm sure you can boot DOS in this way. But a lot of programs expect to find real video so they can speed up thing by handling the video memory directly. In other words: your system certainly won't be IBM compatible and you have to accept the consequences.
But personally I like your idea: one can compare it with the bare CP/M systems like Sergey's Easy-Z80.
 
Right, it wont be IBM compatible. I was also thinking about trying to simulate the system using Proteus, it has an 8086 processor and I could also add a time and an interrupt controller.
 
3.3 using the commodity I/O skeleton (IBMBIO or IOSYS)? You might want to look at the MSDOS 6.0 source, since it's widely available, to see what "gotchas" are lurking in that code.
 
You probably could get away with 256MB of RAM. But since you're getting 1MB, that covers the entire range that the processor can address. So, you'll need to cover the top part with your bios/boot rom.
If you're not going to have a video card, then you'll need to include a uart and a terminal. I presume you're going to code your own bios, since real ones will want to check every chip on the board and will freeze if anything doesn't work.
 
Since you're using static RAM, you could probably portion off a large chunk of that as a battery-backed RAM-disk, and boot DOS off a ROM. Leave maybe 128 or 256k for DOS, map the rest to a RAM disk. IIRC there were some palmtops (HP?) that did that. And since you don't have to worry about the upper memory block since you're using serial instead of a CRT controller with video ram, you have the rest to store programs, files, etc.
That would avoid the microcontroller, SD card, and the second UART.
And if it's PC-incompatible already, you could go full hog, and implement some sort of paging for the ram-disk, and get 2, 4, or more MB of "disk". File transfers could be done over the same serial you use for the terminal.
 
Fwiw, the Tandy 2000, which loaded most of it's bios from disk, supported 768k ram. With hardware and software tweaks, it could use 896k. Clearly it wasn't IBM compatible, except at the bios or dos function call level.

An interesting board, but also not ibm compatible, was the Radio Electronics RE Robot Brain (80188 based). I have some firmware files. It uses a serial terminal for output also. I have to e-mail the guy who built one (the whole robot). I hope he's still available to chat.
 
I don't know if I have an electronic copy or not--my copy is paper--fan-fold 14" greenbar and lots of it. I'll see what I can find. You did catch my post about the MS guide to DOS 2.0 OEMers, right?
 
1ST1 said:
That would be a lot! Early PCs came up with not more than 128 kB.
Click to expand...

Oops yes that was a typo, I meant 256kB. This forum won't allow me to correct it. I will need to be more careful if and when I say something else.
I wonder if 64kB would work with Dos 1.0 (or is it PCDOS?).

And, when quoting, it doesn't include the original quote, leaving this one out of context. Grrr.
 
SBC-188 can boot MS-DOS 6.22. Its BIOS actually implements INT 10h and INT 16h emulation using serial port.
What did it take:
- IBM compatible BIOS. Note that even the entry point addresses are important. DOS calls some BIOS services using CALL <entry_point> instead of INT.
- Other than obvious INT 10h, INT 13h, and INT 16h, you'll need to implement INT 11h, INT 12h, and stubs for INT 14h, and INT 17h.
- I think I spent a couple of evenings debugging BIOS and DOS interactions to make it boot...

As others have mentioned, this will boot DOS, and run some console-based DOS utilities, but way too many programs access the hardware directly, and especially display memory.
 
Well, if you provide RAM in the display area and limit the display ID to MDA, one could interrupt whenever the display area is written. I tried that back in the 5150 days, replacing an MDA with some memory and some software. It worked back then.
 
sergey said:
As others have mentioned, this will boot DOS, and run some console-based DOS utilities, but way too many programs access the hardware directly, and especially display memory.
Click to expand...
This!

On non-standard systems, some with more than 640k conventional DOS memory, things can get really interesting if programs just assume video memory to be present in the A or B segment.
 
sergey said:
IBM compatible BIOS. Note that even the entry point addresses are important. DOS calls some BIOS services using CALL <entry_point> instead of INT.
Click to expand...
Do you know which BIOS services are called by address instead of INT? I have an 80186-based system running MS-DOS 3.10, and eventually I'd like to get a newer version of DOS working on it. But if the BIOS is strictly incompatible, this won't be possible.

I noticed that MS-DOS 6 will talk to a PIC-style interrupt controller in its early code, but I don't know if one is strictly required afterwards.

FreeDOS will definitely not boot with 256 KB or memory; its startup code is relocated at a higher address. I don't remember if 384 KB of RAM are sufficient.
 
You must log in or register to reply here.
Back
Top