Re: [Freedos-devel] BIOS calls in 16bit protected mode

[Rugxulo <ru...@gm...>]

Hi,

N.B. I'm far from an expert, please no one scream at me for
misunderstanding what he means (or if it's more low-level than I
assume).

On Wed, Jun 13, 2012 at 10:24 PM, Kevin O'Connor <ke...@ko...> wrote:
>
> I've been working on an open-source BIOS project called SeaBIOS for
> the last few years:  http://seabios.org/
>
> I'm trying to track down some information on whether or not programs
> are known to call the BIOS in 16bit protected mode.

(naive) You mean directly or switch the computer? Are we talking 286
or 386 machines? For 286, I think? they had to use LOADALL or some
other fancy method (PS/2 addition ??) to do so. The DPMI spec supports
16-bit applications. (Though I never owned a 286 nor directly
programmed for one.)

ftp://ftp.openwatcom.org/devel/docs/dpmi10.pdf
http://www.delorie.com/djgpp/doc/dpmi/

> Specifically, I am trying to determine if there are legacy
> applications or operating systems that invoke standard BIOS real-mode
> interrupt handlers while in 16bit protected mode.  (The legacy
> real-mode entry points - like "int 0x13" - not the declared 16bit
> protected mode entry points defined by the PnP and APM specs.)

In DPMI, any BIOS call that is register-based can be called directly.
So I can do "mov ah,0EH ; mov al,'!' ", and it will work, without
having to call the DOS translation service (int 31h, 300h). Obviously
the 386 makes this easier with V86 mode.

> I am considering changes to SeaBIOS that would make 16bit protected
> mode callers much less likely to work.  (Specifically, enhancing
> SeaBIOS to use memory in the e-segment which is unlikely to be mapped
> in protected mode.)
>
> Most documents I've seen state that calling the real-mode entry points
> in protected mode will not work.  Though, I am aware that the PCI BIOS
> spec specifically requires this support for calls to "int 0x1a
> ah=0xb1".

It was claimed that Intel never thought anyone would want to go back
to real mode, BIOS, etc. But I guess too many legacy apps and
difficulty rewriting things (and costs, availability) affected that
decision. So you had weird hacks like LOADALL, which allegedly was
used heavily by OS/2 and even emulated by all BIOSes up through 486s.

So I'm sure there are others, but OS/2 1.x (and some random 3rd-party
DOS apps) were probably the biggest market for 16-bit protected mode
stuff, e.g. Borland Pascal 7. OpenWatcom also supports this, and
Japheth's HXDEV has some 16-bit pmode support in several flavors (and
the cooresponding DPMILD16.EXE and HDPMI16.EXE).

However, I know that most emulators don't handle 16-bit pmode very
well. For example, I don't think QEMU has full support for segments,
and even DOSBox failed on one 286 pmode app I tried (UCB Logo). Even
if you were willing to be ultra friendly to 16-bit pmode, I'm not sure
you'd find a lot of help. When people say 16-bit is "dead", they mean
both 16-bit real mode and pmode. (AMD64 supports a limited form of
16-bit pmode, supposedly, but no modern OS bothers with that. There is
some virtualization [VT-X] support for such things, but it's still a
crapshoot, esp. since not all cpus have it, e.g. this laptop here.)

> The advantage of making these changes is that it will allow SeaBIOS to
> use notably less stack space and therefore be more compatible with old
> applications that call the BIOS with very little stack space.  For
> example, these changes enable DOS 1.0 to boot and run under SeaBIOS.

Cool, but I think there's much less interest in DOS 1.0 than Borland
Pascal 7. The latter still seems to have plenty of users. Granted, FPC
(386+) is apparently easier to support for emulators, and thus all its
code can (mostly) be recompiled with ease. But outside of that, I
don't know of any huge users of 16-bit pmode anymore. You don't see a
lot of DOS extenders using 16-bit, most are 386+ only. But I'm sure if
you looked hard enough, you could find a few.

> What would really help is pointers to applications and/or program
> images that use 16bit protected mode calls to real-mode entry points.

You almost make it sound like you want hardware-oriented programs or
raw apps. I almost get the impression that you don't want userland
"application" software. So I'm not sure I'm directly helping here.

One of the big advantages of DPMI over VCPI was that it wasn't 386
only, so it supported 286s also. But, as I mentioned, the 386 has long
long long ago eclipsed the 286. So you won't generally find 286 pmode
apps, even for DOS.

Even OS/2 2.x seems to heavily prefer 386 LX instead of 286 NE. (Oops,
that reminds me, European MS-DOS 4.0 and Win16 both used NE also.
Oops, how could I forget Win16. Yeah, I guess you could drudge up a
bunch of Win 3.0 stuff, but you'd still need a DOS underneath, and
FreeDOS doesn't fully support that [standard mode only??] for various
undocumented reasons.)

> Specifications or documents detailing valid or invalid uses would also
> be helpful.

Outside of the DPMI spec, I dunno much else. I never used OS/2, so I
don't know where they keep their APIs, specs, etc. Maybe it's not
published online, that was ye olden days. If anybody would know, it
would be the OpenWatcom dudes (esp. michaln).

ftp://ftp.openwatcom.org/devel/docs/intel%20286%20programmers%20reference%20manual.txt

http://www.os2museum.com/wp/

I've actually heard that DPMI 1.0 is the "386 superset" version of the
older 0.9 (286) version. But Windows (and others) never fully
supported 1.0. Even some 286 DPMI hosts require a 386. Japheth's
dpmild16 is 286, but hdpmi16 requires 386. Win 3.1 was 286 or 386 but
Win 3.11 was 386 only. DPMIONE is 386 only, IIRC.

http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/specs/dpmispec.arj

(Not sure you need both 0.9 and 1.0, but just in case ....)

> For those that are willing to run tests, one can compare the standard
> SeaBIOS v1.7.0 image (for KVM/QEMU) at:
>
> http://git.seabios.org/downloads/get/bios.bin-1.7.0.gz
>
> to a test image with the new code at:
>
> http://git.seabios.org/downloads/get/bios.bin-test-20120613.gz

I don't know how much upstream is interested in 16-bit, and I'd be
surprised if you got any sympathy. I don't have any great test setups
or experience for it, so I'm not much extra help. Good luck anyways.