On Fri, May 16, 2008 at 10:37 PM, Eric Auer [EMAIL PROTECTED] wrote:
Hi Steve!
I was wondering if there were any interest in seeing Free DOS
running on the OLPC XO?
For background, the OLPC has under development a version of Open
Firmware which will support the legacy INITS Windows requires to run.
I'd like to be sure these features are useful for something more than
just their intended purpose, and also to be sure the complete set is
properly implemented.
Very nice idea! The OLPC has 1200x900 in 7.5 inch (b/w reflective and
rgb backlit), Geode CPU (x86 compatible), VGAcam, WiFi, SD card slot,
only 1+1 Watt (CPU+backlight), 256+1024+1024 MB RAM+flash, 1.6 kg, and
a fancy child friendly GUI based on Linux and Python (and javascript,
smalltalk, csound, logo, abiword, firefox-xulrunner, adhoc network).
Still some countries insisted that they could be Windows dual boot so
OLPC and MS made that possible (XP on a 2 GB SD card I believe...).
Forgive me for being new, but I really know rather little about the
technical requirements, but this seems like a perfect time to learn.
Is there any interest among list subscribers in something like this?
Sure :-). Now that MS stuff has to run on OLPC anyway... Problem is
that for example the graphics are totally un-DOS, but as long as the
MS-on-OLPC project provides BIOS functionality, quite some DOS apps
can potentially run on OLPC. Basically all which does not use direct
hardware access but uses only the BIOS.
This is a little bit different, but hopefully in a good way.
In this case, the Open Firmware re-design to provide the BIOS hooks is
happening right now.
I'm seeking feedback from the Free DOS community to ensure the
redesign meets the needs of (and works right for) Free DOS when it's
finished.
(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.)
Our FAQ has an item about the possibility of running DOS on x86 CPU
based embedded or otherwise custom computers. For example one FreeDOS
user made a BIOS extension to run FreeDOS on a Tandy style PC which
normally requires a special MS DOS 2 version because the main BIOS
of that PC has almost no features ;-).
Perfect example.
So what's the wishlist? If you were writing (the hooks for) a BIOS and
wanted to be sure it works well with Free DOS (and everyone else be
darned) what would you want to see? What horrors would you want to
avoid?
Is there a reference implementation of what a BIOS should be, if the
primary customer is going to be Free DOS? I wonder if we can get the
XO to be that reference implementation?
Are there tools you use to see what services a BIOS offers, and to
verify it offers them correctly? These would be useful for testing
and proving the BIOS hooks for the XO's Open Firmware.
If a manufacturer offered to completely document their BIOS for you in
excruciating detail, what would you want to know?
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?
The answer, back in 2004, was: Generally yes as long as you have a
proper DOS compatible BIOS. The latter means supporting some of the
40:xx BIOS data area fields (probably optional... a quick look tells
me that we now use 40:17 shift state, 40:4a / 40:84 screen size,
40:0e EBDA location, 40:13 RAM size, 40:6c time of day, 40:71 ctrl-c
ctrl-break flag, 40:1a / 40:80 keyb buffer location). Of all those,
basically only 40:71 is not limited to certain boot time things like
debug if shift or full screen menu or move ebda or wait for
menu choice or resize keyb buffer. So 40:xx is relatively unused.
DOS also writes to low memory areas at 40:xx, 50:xx, 70:xx and some
interrupt vectors (mainly 20..2f, maybe IRQs at int 8..f, some fault
handlers at int 0..6). DOS apps can use more stuff, for example more
40:xx values, int 8 / int 1c timing, various other int handlers. DOS
is supposed to be able to hook int 10, 13, 15, 19, 1b.
Next are the required BIOS interrupts for DOS:
- int 11 / int 12: just return fixed values based on system type
(AX bit flags like floppy/EGA presence, COM/LPT count / AX RAM size)
- int 14 / int 17: only accessed if you want to use COM/LPT ports
(not actually interesting for OLPC if you ask me)
- int 19: only relevant for certain styles of reboot...
(only relevant to know that DOS hooks this)
- int 1e: a data table, only if you want to use floppy...
(if no floppy: still good to know that DOS edits this)
- int 1a functions 0 to 5 to access the clock (in ticks and in
BCD, read and write, might be possible to use a reduced set)
- int 10 function e to show text on the screen - the TTY function
(also functions 2, 6, 0, 11.1n if you use menu or screen options:
2 sets cursor position, 6 scrolls, 0 sets mode, 11 sets font)
- int 16 functions 0 to 2, 10, 11, latter two
