• Please review our updated Terms and Rules here

Minimum Hardware for an MS-DOS PC

pearce_jj

Veteran Member
Joined
May 14, 2010
Messages
2,808
Location
UK
I'm thinking of putting together a motherboard design to provide an 8088 CPU and some ISA slots as a very minimal loosely IBM compatible PC.

The design will make use of my storage and RAM boards (two slots) but does not need to be compatible with really anything else; it just needs to boot from XTIDE Universal bios and run some scripts in auto exec there on. Ideally it would have CGA adapter compatibility and PCXT keyboard, but this is not essential.

Hence looking to understand - what is the minimum hardware needed to get a machine to boot to DOS via XTIDE Universal BIOS? Likewise, what would be needed to get IBMs PC/XT BIOS working?

Writing a dedicated ROM to continually read some sectors from the storage adapter into RAM is another option, then perhaps there is nothing more required than power supply and clock?
 
Sorry I have no knowledge to impart but I would love to see this idea a reality
 
The design will make use of my storage and RAM boards (two slots) but does not need to be compatible with really anything else; it just needs to boot from XTIDE Universal bios and run some scripts in auto exec there on. Ideally it would have CGA adapter compatibility and PCXT keyboard, but this is not essential.

Perhaps you could look at the PCjr instead of the PC, in your case?
The PCjr is not fully PC-compatible because some of the hardware is missing or simplified, but it does run DOS, and can be booted from an IDE device (the jrIDE for example).
The PCjr has more advanced audio and video than the PC, but I guess you could create a lowest common denominator system, which only has PC speaker and MDA or CGA support, and also missing the DMA controller like the PCjr etc. It should work well enough for commandline DOS support at least.
 
Thanks for the input. The lack of slots in that design doesn't matter as ISA is directly attached to the 8088. However I need to understand the absolute minimum support logic required to get the thing to boot.

For example XTIDE Universal BIOS doesn't need any interrupts, but presumably I would need PIC and system timer to have any chance of getting IBM's BIOS to run.
 
Just because the IDE bios doesn't use interrupts doesn't mean the rest of the system doesn't need them. Pretty sure you need a PIC to process ctrl+break from the keyboard. You need some kind of date/time so is that the real time clock other wise time stamps on files will be wrong.

What about floppy emulation to get the data onto the Hard Disk?

Something to plug the keyboard into?
 
The only thing a PC Jr really skips on is a DMA controller and a keyboard controller. The rest of the hardware is there in some form or other. It has most of an ISA bus. It has interrupts. It has the timers. The video and floppy controllers are a little different but recognizable.

Take a look at the Flea86 ... That was pretty minimal. It is in the board archives and here:

http://www.fleasystems.com/flea86.html
 
Well, another thing that is interesting about the PCjr is that the video memory is shared with system memory, which probably makes the video circuit simpler to design, especially if you just stick to MDA.
 
Thanks.

serial console would also be an option, if that might make things simpler ie no keyboard or CGA. Actually I'd sooner not use an ISA graphics card if at all possible, since that's very likely to be a big source of noise with its own timing circuits.

Floppy not required. Literally this board only has to move data to and from memory from the storage card, preferably with some form of console for debugging. And in future do 'stuff' with other ISA cards, so some form of IBM compatibility is preferable simply because I know how to program with Turbo Pascal and the XTIDE UB already exists.
 
To get the full list of what a PC needs, look at the BIOS listing. The BIOS listing has all of the code that initializes the system from a cold start. That is going to include setting up the interrupt table, programming the timers, programming the interrupt controller, setting up the DMA controller, initializing any on-board video, determining what is on the system (reading the system switches), etc.

Then figure out what you can simplify. But you need to be more clear with what you want to run and what you don't need.

For example - video. You said CGA would be nice. That implies a video buffer at B800:0000 and a 6845 controller with registers at a very specific place. But if you wanted to simplify the hardware you could just go for BIOS level compatibility. And if you went further and said no graphics you could cut out even more, or possibly just implement a serial terminal under the covers.

The PCjr DMA tradeoff is another good example. The PCjr gets away without a DMA chip and it is using the video circuitry to refresh the system memory. That works fine until you want to add more memory; then every memory expansion not refreshed by the video circuitry needs to provide its own DRAM refresh controller. So initially there might have been a cost savings, but not on expanded systems. And then there is the performance penalty of the shared video memory. If you can't live with the performance problems then that solution is not for you. (But in a modern solution this might not be an issue.)

Floppy and hard drive access - BIOS level compatibility should be fine unless you want to run specific diskette drive software such as things that copy copy-protected diskettes. The PCjr jrIDE controller and all SCSI controllers provide a BIOS level interface to hard drives and that works well. The PCjr floppy drive is effectively only compatible with the PC at a BIOS level.

So, what do you want to do with this system? Do you need to be able to run arbitrary programs? How many things are you willing to simplify before you wind up writing all of the software by hand?
 
It's worth noting that the RAM card that pearce_jj is using uses SRAM, so refresh is a non-concern...

Now, the big question is... do you want to do this the way MS-DOS compatibles (which were not necessarily PC-compatible) actually did it back in the day, where they used a customized IO.SYS aimed specifically at their hardware, or do you want a higher level of PC compatibility than that?

If you're only targeting MS-DOS compatibility, with a custom IO.SYS, then you could probably just build a minimum-mode 8088, too, I'd think? (Or can a minimum-mode 8088 support the XT-CF card for storage?)
 
It's worth noting that the RAM card that pearce_jj is using uses SRAM, so refresh is a non-concern...

Yes - the PCjr was brought up as a historical example of this thought exercise. Hence my disclaimer " (But in a modern solution this might not be an issue.)" ...
 
Thanks for all the input! So there is a straight trade off between hardware complexity and software complexity in achieving a very approximately MSDOS compatible platform. My gut feel is that it will be quicker to solve the hardware puzzle that the resultant software puzzle, so perhaps my question can be redefined to

What would be the minimum configuration to run the simplest PC BIOS?

It sounds like the PCjnr BIOS might be the simplest as there is no DMA to worry about. As noted above, the system will use SRAM so that is no issue luckily.

For console, I'd prefer to connect via serial or indeed any way that doesn't involve using an old piece of hardware. Everything in this system must be new. Actually it doesn't need any human interface at all other than for development, so maybe that should live on an ISA card too.
 
Silly question, James, but what good would a MS-DOS PC be to anyone if it doesn't run any but the simplest MS-DOS console applications?

And why an 8088? Wouldn't an all-in-one CPU, such as one of the 80C188 with built-in peripherals be a more logical choice?

I have a little box here from ASAP that fits between a printer and a PC that has a NEC V40 in it, with 256K each of PROM and DRAM, as well as a floppy controller and a Yamaha DSP for FAX reception. I ported CP/M-86 to it and used the V40's serial interface to provide a console. I thought about MS-DOS, but what good would the thing have been after all was said and done?

In fact, the better choice would have been to emulate a PC using a modern MCU. Consider the box that Valentin built around an 8052--very high PC compatibility; could run games and generated its own display. Yet it was nothing more than an emulator.

Pardon the thinking aloud. I just remembered the first IBM PC that I bought--64K of DRAM, one (single sided) floppy and an MDA and keyboard. Yet I managed to do productive work on it. But it wasn't easy.
 
In the early days of the IBM PC there were three level of compatibility based on the API available.

MS DOS compatible, that is to say the box would run a version of MS DOS, usually specifically written for its hardware. Only code written at the MS DOS level and/or ported to the machine's specific hardware would run on it. Oddly quite common earlier on but required machine specific copy of Lotus 1-2-3 for example.

IBM PC BIOS compatible. As above plus would run code written to the BIOS hooks. Not actually that commonly implemented.

As above plus hardware compatible with the IBM PC. Would run IBM PC DOS and applications written for the IBM PC e.g. Lotus 1-2-3. The classic "clone".
 
Silly question, James, but what good would a MS-DOS PC be to anyone if it doesn't run any but the simplest MS-DOS console applications?

It seems that is more or less how MS-DOS was originally envisaged: they had OEM versions for each vendor, so as long as it was an 8088-system, there was room for custom hardware.
This is also how CP/M worked, and that is what DOS was originally modeled after.

But yes, in practice, a lot of software would access the IBM PC hardware directly, and it even bit IBM themselves in the posterior when they released the PCjr. In practice, MS-DOS became the de-factor IBM PC hardware standard, and a lot of 'real world' DOS applications won't run on anything that isn't 100% compatible.
Mind you, if you just want to write your own applications, there's nothing that keeps you from treating DOS as it was intended, and sticking only to the DOS and BIOS APIs as a sort of hardware abstraction layer.
 
In my use case, MSDOS and BIOS compatibility are conveniences since this means that I can write the software to run in it more easily, but it actually isn't essential.

That said, I really like the 80C188 idea! The closer I can get to system on a chip the better really. But I need to be able to do the PCB layout.
 
Back
Top