Re: [Freedos-user] Running Free DOS on the OLPC XO
On Tue, May 20, 2008 at 12:14 PM, Florian Xaver <[EMAIL PROTECTED]> wrote: > I would buy a OLPC XO if it would support FreeDOS... ;-)) I hate it when people say that ;-) I'm not going to sell you mine, but once the DOS support is into a released firmware load, I'll definitely post a note here to let people know. You should buy one off of eBay now, before the new demand pushes the price sky high. ;-) -- 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/vse012070mrt/direct/01/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Running Free DOS on the OLPC XO
I would buy a OLPC XO if it would support FreeDOS... ;-)) Bye Flo 2008/5/17 Steve Holton <[EMAIL PROTECTED]>: > Greetings all- > > 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. > > The OLPC XO seems much more suited to running DOS-type applications > and this seems like it could be a good fit. > > 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? > > And, of course, are there aspects of this (good or bad) I haven't grasped? > > Thanks in advance. > > -- > 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/vse012070mrt/direct/01/ > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > > > -- Passts auf, seits vuasichtig & losst eich nix gfoin! (Kurt Ostbahn) http://www.drdos.org - http://www.flox.at.tf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Running Free DOS on the OLPC XO
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 :-). Eric > > 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. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Running Free DOS on the OLPC XO
Steve Holton wrote: > 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? Kevin O'Connor is currently porting Bochs BIOS to gcc: http://git.linuxtogo.org/?p=kevin/legacybios.git Robert Riebisch -- BTTR Software http://www.bttr-software.de/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Running Free DOS on the OLPC XO
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 c
Re: [Freedos-user] Running Free DOS on the OLPC XO
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. 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 ;-). 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/vse012070mrt/direct/01/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
