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 only if 49:96 test 10 > is nonzero and SWITCHES /K is not present) > > - int 13 functions 0 to 3 and 8 to access disks (either diskette > or harddisk style), also further functions if you want diskette > change detection or LBA harddisk access and so on: functions 15 > to 18, 4, 5, 41 to 43, 48, 4b can be used then. Those are: > 4 verify, 5 format, 15 get (floppy) type, 16 detect (floppy) > change, 17 set (floppy) format, 18 set (floppy) media type, > 41 detect LBA support, 42 read LBA, 43 write LBA, 48 get LBA > drive params, 4B get CDROM boot info, 0 reset, 1 status, 2 read, > 3 write, 8 get drive params. > > I hope this list of BIOS things needed to boot DOS is at least > semi-complete and I hope it overlaps a lot with things which > were planned to be in the OLPC "legacy BIOS support" anyway :-). > > Eric > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- Steve Holton [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
