I suspect it's rather close to "x86 processor; recommended - floppy disk and 64K+ memory"… 😀

In general you were supposed to write your own io.sys/fdisk/format/sys/etc, so for one you get control on the disk format and all of the few built-in drivers (which on a genuine PC are in turn outsourced to the BIOS but don't have to*);

In particular console output is limited to quite less than the least common denominator of even MDA & CGA, so I suspect your non-80x24 text mode is quite plausible (again at the DOS level, I suspect quite many interactive programs bypass that!)

* In other words, while many people - like us 😀 - say "DOS compatible" meaning "non IBM compatible, whatever that means", they're really two independent classifications… in fact if you have the full source like with FreeDOS even my first sentence is probably wrong and you could likely port it to a completely incompatible architecture, I suspect!

Probably the lowest common denominator is 80x8(6) CPU, 64k and text mode. Not everything has graphics.

If you stick to Dos system calls to write your application, then things will tend to 'just work' - see the NEC PC98 series with a completely different IO and memory scheme, and command line tools from 'normal MS-DOS' that just speak Dos calls will quite happily run on it without modification.

Then you have some.of the wacky early 'portable' x86 systems where you don't even have a full screen worth of text output. Simple tools will still work on them as long as they are well behaved.

Get to the point of games, or other direct hardware hitting code, however, and all bets are off. It's a miracle that things standardised to the point that they did!

I had a suspicion that io.sys was the prime "shim" between BIOS and the rest of the OS, alternatively a large monolithic driver or as some might say a whole bunch of int21h routines in loose formation. Between teardowns like this https://www.softwarelitigationconsulting.com/ … mbling_dos.html and Miscrosoft dumping DOS 1.1 and 2.0 sources on github under MIT license, I might have something to go on.

Oddly when this idea first crossed my mind, I thought I was going to have to get into old DR-DOS source dumps to figure anything out.... though knowing what was going on in it's predecessor Concurrent DOS which was multiplatform, might have been insightful.

It just dawned on me that the LCD I wanted to use is the same resolution as the Atari Portfolio, and also with simple hackery of the industrial board, I was probably not going to get a full 640k, so it seems like it might be a good plan to aim for sorta kinda Portfolio platform, as at least there are lists of stuff known to work and not.

However, this might get more backburnered than it was, since the Pocket386 made it's appearance and grabbed my attention, so might be getting my weird portable jollies on with that for a long while and not circle back around to this for ages.

AFAIK, the early MS-DOS compatible but not quite IBM PC compatible machine were usually bundled with a customized licensed MS-DOS version.

Maybe it could be worth decompiling and comparing some of those DOS versions/builds to get some insight. I suspect that at least some of those were highly customized.

Ryccardo wrote on 2024-02-25, 19:27:

In particular console output is limited to quite less than the least common denominator of even MDA & CGA, so I suspect your non-80x24 text mode is quite plausible (again at the DOS level, I suspect quite many interactive programs bypass that!)

🙂👍

Many DOS compatibles do try to be high-level compatible, ie they may support CP437, basic MDA compatibility (cursor control, but no attributes) and basic CGA video modes/memory layout.

In case of CGA, that's the 320x200 4c mode (Mode 4) and the 640x200 mono mode (Modee 6) at the BIOS level.

CGA registers are either being ignored or their equivalents are being located on different places on the host system.

If CGA palettes (1 and 0) are being supported, they're not necessarily having same colours as on an IBM PC.
They use whatever the native graphics hardware has to offer.

(-I'm thinking of the BBC Master 512 here, which had different CGA colours-)

The unofficial, third-palette (bg colour, white, red, cyan) is usually not available (Mode 5 and color burst hack) .

High/low Intensity versions of the three palettes may also not being supported.

All in all, the experience is like CGA on EGA/VGA: synthetic. Merely the basic stuff works as expected.

The reason CGA is being supported at all is because its graphics routines being part of PC BIOS, I suppose.

Makers of DOS compatibles apparently recognized their relevance as some kind of an industry standard, like ASCII code, VT100 terminal emulation or RS-232.

The addition as a bonus didn't hurt much, given its simplicity. But that's pretty much all, I suppose.

The only other thing I can think of are ANSI Escape Sequences.
Something like ansi.sys could work on DOS compatibles in a platform-independent way.

Speaking of text output, another issue back then was that the direct video i/o wasn't IBM compatible (different memory location).:

Computers like the c't-86, the Robotrons or the Alphatronic PCs (Alphatronic PC16 by Triumph-Adler) required their Norton Commanders to be patched.

Because Norton Commander didn't use MS-DOS or BIOS for character i/o.
That price had to be paid for being responsive on slow PCs, I suppose.

Edit: That's why MS-DOS compatibles got "PC emulator" programs throughout rheir lifetime.
When the IBM PC became ubiquitous, they tried to make things look more IBM PC 5150 -like to the application software.

It sometimes worked good enough, for well written applications.
Applications that did comply to official IBM documentation usually worked.

For serial communications, FOSSIL drivers could be used to get commercial programs going on non-IBM PCs.