Hi Steve,

> I'm seeking feedback from the Free DOS community to ensure the
> redesign meets the needs of  (and works right for) Free DOS...

Nice, thanks :-)

> (I'm thinking this makes a change; a BIOS developer willing to make
> design changes to meet the needs of Free DOS, rather than the other
> way around.)

Indeed. Still it might be useful to have patches to let FreeDOS
work on somewhat simplified BIOSes, just in case :-). So feedback
in that direction is also okay, as long as frequently used BIOS
functions are still available to FreeDOS.

> So what's the wishlist? If you were writing (the hooks for) a BIOS

Well the things mentioned in my previous mail already get you
quite far, in particular if you include those for which I said
that DOS can work without them if it has to. But there is more
than the BIOS functions used by the kernel. In particular, a
typical DOS system also has extra drivers for mouse, keyboard
and memory, and probably some more drivers I forgot to mention.
To give some names: cutemouse, keyb, mkeyb, himemx, jemm386.
You typically want to support at least memory size info and
PS/2 style mouse and keyboard handling.

The OLPC probably has no CDROM/DVD/floppy, but you can add BIOS
support for the memory card slot of the OLPC, for example. The
card could be treated as harddisk, for now without hotswapping.

For screen output, tools like NANSI and MODE show examples of
ways to access hardware and BIOS, but those are often quite
"old, strange interfaces" oriented. I do not know how VGA or
VESA compatible the OLPC graphics are and whether people want
to use the OLPC for, say, old DOS games. Talking about those,
the sound hardware of the OLPC will not be compatible to old
games anyway. For new software, a MPXPLAY sound driver would
be nice. There is no common use BIOS sound interface you can
implement, so you cannot "fix things" on the BIOS side. For
graphics and text, it would be nice to have at least a text
mode style framebuffer (array of char/color byte pairs) but
if that cannot be done, a JEMM386 JLM module might act as a
driver to create a virtual text framebuffer and update the
OLPC graphics screen whenever the text changes. The standard
text mode is 80x25 but others might be used, too. Also, some
graphics modes like 320x200 8bit/pixel byte array MCGA mode
might be easier or more often used than others like CGA and
similar in games, while VGA 640x480 4 bitplanes mode might
be more often used in other apps. For most graphics modes,
DOS apps often use direct hardware access instead of asking
the BIOS to set a pixel or change the palette, mainly caused
by the big overhead of calling the BIOS for every pixel. If
you support VESA framebuffers or MCGA, you get a mix of both:
VESA apps are supposed to ask the BIOS for most "config" but
get a byte/word/dword array pointer to manipulate the image.

> Is there a reference implementation of what a BIOS should be

As said in another mail, the Bochs/Qemu BIOS and VGA BIOS might
be a good example, now also ported to C. The old version had
more ASM which made it use less stack - was harder to maintain.
You could also look at Dosemu which is written mostly in C but
Dosemu interfaces more between DOS and Linux than between DOS
and (real or simulated) hardware.

> Are there tools you use to see what services a BIOS offers,
> and to verify it offers them correctly?  These would be useful

Depends. You can test quite a bit by just letting DOS boot and
do a trace of all BIOS calls and return values etc to see if
they did what they should do.

> If a manufacturer offered to completely document their BIOS

Sources like RBIL (Ralf Brown's Interrupt List) already compile
lots of information of what BIOSes and DOS do for you, so in
general it already helps to have a compatible BIOS and a list
of implemented features / interrupt functions for that. It also
helps to know which data areas are used, like 40:xx memory, CMOS
setup storage, flags stored in the chipset or in the BIOS/flash,
and so on. Well-documented hardware is always a nice extra :-).


> > http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=General_Information/277
> > "Will FreeDOS work on a custom embedded system based on 80c188XL?"

PS: Feel free to contact me if you have questions about the
requirements of certain drivers/apps apart from the DOS kernel.

This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
Freedos-user mailing list

Reply via email to