ArcadeOS Version 2.34 (January 2000) ==================================== DOS Frontend for Emulators, tech. doc Contents ======== .General .AOS Structure .Communication between the modules .AOS Arcade Monitor Modes .The Keyboard Remapper .The Jukebox Screen Saver .AOS System File Formats .AOS BIOS Extensions .Real Mode / Protected Mode DOS General ======= This document gives a brief overview of the more complex/interesting parts of AOS. It also describes the internal file formats used by AOS. NOTE: in some parts of this document, RM is used for shorthand for 'Real Mode' and PM is used for shorthand for 'Protected Mode' AOS Structure ============= NOTE:The structure of AOS has been pretty much determined by the way in which Real Mode DOS and Protected Mode DOS operate. See the section 'Real Mode / Protected Mode DOS' for more info on this subject ArcadeOS consists of 3 executables: arcadeos.exe (real mode app) arcadeos.bin (protected mode app) pmwrap.exe (protected mode app) arcadeos.exe: This is a real mode program, it installs AOS's BIOS and DOS extensions, runs arcadeos.bin (the main 'menu' part of AOS) and also launches all emus/apps. Why a small real mode program ? DOS is a Real Mode operating system, so to extend it - the best way to do it is to install any extra functionality we need in Real Mode. If AOS's extensions are installed in Protected Mode, we're basically opening a whole 'can of worms' ranging from performance problems, other real mode driver/TSR conflicts to straight forward crashes. Why launch emus/apps from arcadeos.exe, why not launch them directly from the main protected mode part of AOS ? This is due to the fact that to get a DOS app running in protected mode, we need a DOS extender and/or a DPMI server (see section Real Mode / Protected Mode DOS for more info) When launching a PM DOS app from another PM DOS app, you can get into real problems. This is especially true if you launch an app which uses a different DOS extender to the one the 'launcher' app is using. The problems may not even be immediatly apparent. In fact it's general possible to launch any PM DOS application from any other. *BUT* you might not be able to do it more than once during the 'lifetime' of the PM launcher application. To get round these problems, all apps are launched by AOS in Real Mode. arcadeos.bin: This is the 'front end' part of AOS, it's what you see when you use AOS. It's a 32bit PM application, basically to take advantage of the amount of memory available when running in PM. pmwrap.exe: This is a 'Protected Mode Wrapper' it allows the keyboard remapper to work in Protected Mode, and the 'Juke Box' screen saver to tell arcadeos.exe when a coin has been inserted. See 'PM Keyboard Remapper' for full details of what pmwrap.exe actually does Communication between the modules ================================= For AOS to work, there needs to be 2 way communication between arcadeos.exe and arcadeos.bin and arcadeos.exe and pmwrap.exe This is not a straight forward proposition, as one application will be running in Real Mode, the other in Protected Mode. Originally, this was done using temporary files, arcadeos.exe (or arcadeos.bin or pmwrap.exe) would generate a file then call one of the other AOS executables. This executable would then read in that file, and act on the commands/data in it. On exit, the new executable might also create another file to pass commands/data back down to arcadeos.exe Although straight forward, this was far from an ideal solution. Instead, AOS now includes BIOS extensions to allow aradeos.exe to talk to arcadeos.bin or pmwrap.exe, and arcadeos.bin or pmwrap.exe to talk to arcadeos.exe. There are 3 memory areas within arcadeos.exe and 6 BIOS functions, 1 each for reading and writing each area. These BIOS functions are visible from both RM and PM, all the PM parts of AOS need to is copy the data beeing written/read from/to low memory. Where both RM and PM applications are guaranteed to be able to see it. AOS Arcade Monitor Modes ======================== Probably the single most important feature of AOS (for me anyway), is it's ability to run on an arcade monitor - and it's ability to run other emus/app which do not directly support an arcade monitor mode. How does it do this ? The first feature, running directly on an arcade monitor, is fairly simple. It has it's own mode 13h (320x200 at 256 colours) setup to arcade monitor frequencies. The second, allowing other apps to run on an arcade monitor, is slightly more complex. To achieve this AOS uses an extension of the VGA2TV software driver idea. It hooks into BIOS and traps video mode requests, if a supported mode is requested, AOS calls the existing BIOS, then alters the timings of the mode so it can be displayed on an arcade monitor. This works fine for the simple case of an emulator/app requested a standard VGA mode, and AOS supports the 320x200 graphics mode and standard text mode in this way. But many emulators/apps used 'tweaked modes', these are resolutions that are not natively supported by BIOS. Generally they're used by emulators to support the resolution of the original arcade board/video console being emulated. These modes cannot be turned into arcade monitor modes using the above method, here's why.... Say Callus wants to setup a 384x224 tweaked mode, the first thing it does is call BIOS and sets up a standard 320x200 mode. AOS intercepts this calls, and alters the 320x200 so that it can run on an arcade monitor. BUT, Callus then directly 'tweaks' the very same VGA registers that AOS has just programmed to generate Callus' 384x224 mode. Our arcade monitor mode has been lost, and we end up with Callus' PC monitor 384x224 mode. To get tweaked modes running on an arcade monitor, we need to know in advance if a tweak mode is going to be set by the emu/app. Then, instead of just setting up the arcade monitor mode when the 320x200 mode request is recieved, we need to program the mode *after* the emu/app has setup its tweaked mode. This is exactly what AOS does. In the .app files the value of 'modexmode' tells AOS what tweaked mode the emulator is going to set. 'modexdelay' tells AOS how long to wait after it recieves a request for 320x200 mode before it sets up its arcade monitor mode. So, say 'modexmode' was set to 0 (standard 320x200) - the emu makes a request for mode 320x200. AOS checks if there's going to be a tweaked mode requested by looking at the value of 'modexmode'. In this case it's 0, no tweaked mode. So AOS sets up a 320x200 arcade monitor mode and returns to the emu. Now, say 'modexmode' was set to 6 ('tweaked' 384x256) - the emu makes a request for mode 320x200. AOS checks if there's going to be a tweaked mode requested by looking at the value of 'modexmode'. In this case it's 6, so there is a tweaked mode going to be set. AOS doesn't alter any of the VGA timings, instead it hooks into the timer interrupt and returns to the emu. The emu then sets up its tweaked mode, however - AOS has hooked the PC timer, so the next time this is called it checks if it needs to reprogram the VGA card to display an arcade monitor mode. It determines if it does or not by the value in 'modexdelay'. If the mode needs to be setup, AOS reprograms the VGA card to display the requested tweaked mode (in this case 384x256) on an arcade monitor. So that's basically it - The emu calls BIOS to setup a standard VGA mode, AOS decides if it needs to setup an arcade monitor mode at this point; or if it needs to wait. The emu then reprograms the VGA card to setup its tweaked mode, and AOS then reprograms it again to setup its arcade monitor tweaked mode. All finished? Not quite, what if the emu has hooked the timer interrupt and isn't chaining to the old one ? This would mean that our 'wait to set the arcade monitor mode' code would never get called, and we'd never get our tweaked arcade monitor mode. RAGE does exactly this, but ,luckily enough, since all of this code is localised in the RM portion of AOS; there is a way around it. Instead of setting up a timer, why not let the emulator set it's video mode - then on the next call it makes to either BIOS or DOS let AOS setup the arcade monitor mode ? This is exactly what AOS does in the case of RAGE, and it's what the special value 'modexdelay=99' is used to signify. When 'modexdelay=99' AOS doesn't try to hook into the PC timer interrupt, instead it sets a flag when the emu sets up a standard VGA mode. Now, on the next call that emu makes to DOS or BIOS, AOS checks this flag. If it's set, it then reprograms the VGA card to generate and arcade monitor mode. The Keyboard Remapper ===================== AOS's keyboard remapper is quite powerful, and as a result - fairly complicated. We'll start with a discussion of how a 'standard' DOS key remapper works, why this won't work with all the DOS emulators that I'm aware of, and how AOS trys to get round the problems. 'Standard' DOS Keyboard Remapper -------------------------------- The idea behind a remapper is simple - Intercept a user's keystroke(s), if a key was pressed that is to be remapped, send the remapped keystroke to the running application instead. Really, the only thing to decide is 'where' to intercept the keystroke, there's basically only 2 places 1. in BIOS 2. at the hardware interrupt level No. 1, BIOS , is by far the easiest so we'll start with that. Probably the best place to put our code is interrupt 16h, BIOS Keyboard I/O services, specifically function 0h 'Keyboard Read' All we need do is replace that function with our own. Now, everytime the app calls 16h to see which key was pressed by the user - our function gets called instead. We call down to the 'old' BIOS function, if the key returned by this matches something we need to remap, we return our remapped key.If it is any other key we just return whatever BIOS returns to us. Fairly straight forward. No. 2, hardware interrupt, is a bit more complicated; though not much. This time we replace interrupt 9h. This is the hardware keyboard interrupt and is called whenever a key (or command) is sent from the keyboard to the PC. Here, we need to read the values of various ports to determine the key pressed; if the key needs to be remapped - we discard the existing key press, then we need to send a command to the keyboard controller (again using ports) to 'fake' the pressing of the remapped key. (i.e. to 'stuff' our new key press into the keyboard controller, so that the emu/app thinks that it's been pressed) Other than avoiding infite loops i.e. key A is remapped to key B key B is remapped to Key A This could cause the remapper to get stuck in a loop, constantly remapping key presses it had generated itself. - Unless it was aware of where the incoming key press had come from (which AOS's remapper is) It's again fairly straight forward. Why 'standard' DOS key remappers won't work ------------------------------------------- Those are our two options, but there are problems with both.... 1.BIOS If we replace the BIOS interrupt, it will *only* work if the application is using BIOS to determine which keys are pressed. For all emulators (and just about all PC games in general) this won't be the case. The emu/app won't be using BIOS at all, it'll be using the hardware interrupt; so it doesn't matter what you do in your new BIOS function - as it will never be called. Emulators/games ignore BIOS because: It's slow, sets up things we're not really interested in (keyboard buffers, repeat rates etc) and doesn't allow you to tell easily if more than one key is being pressed at a time. It's much more sensible for the emu/app to use its own simple/fast keyboard handler at the hardware interrupt level and figure out which keys are being pressed itself. 2.hardware interrupt Even if the application isn't using BIOS, the hardware interrupt remapper will get called everytime there's a key press - so it should work for everything, right ? Again, no. Here's what happens:- You install your remapper on hardware interrupt 9h. It works fine, traps keys, remaps them - all lowlevel without a sniff of BIOS. Then MAME starts up, it makes a few calls to Allegro, which results in hardware interrupt 9h being replaced with Allegro's own keyboard handler. Your remapper will now never get called, it just got kicked out by Allegro. So how do we remap keys in DOS when the type of applications we want to remap are going to either: .never call our BIOS remapper or .kick out or hardware remapper after the application itself has started up ? The answer is, we have to be a bit sneaky. First, forget about a BIOS remapper, as it's never going to get us anywhere. We need to use a hardware interrupt remapper - but we need to install our remapper *after* MAME (or whatever) has installed its own keyboard handler. This is exactly what AOS does. AOS has already installed BIOS and DOS extensions in Real Mode, so it knows when MAME is trying to change video modes, open a file etc. AOS works on the assumption that if the emulator/app is setting a graphics video mode - it has at that point already installed it's own keyboard handler What if the app hasn't installed its remapper before it requests a graphics video mode ? That's what 'remapdelay' is for, to wait a specified period of time after a graphics mode is set before installing AOS's remapper. So, AOS starts MAME and waits for MAME to request a graphics mode. By this point MAME has installed Allegro's keyboard handler, which AOS then replaces with its own. It saves the address of the Allegro keyboard handler so it can 'chain' to it (i.e. call it if no remaps are needed for a given keypress) So , our remapper is in place - it's been installed at a low a level as we can get, and also after the app has installed its own keyboard handler. Which means we're finished ? Not quite.... There's still a little bit more work to do, there's the problem of Real Mode and Protected Mode.... Getting round the RM/PM problem ------------------------------- There's 2 basic types of interrupt on a PC, software and hardware. Software interrupts are generally initiated by an application (i.e. a request to open a file) Hardware interrupts are initiated by the 'system' itself (i.e. a timer) BIOS/DOS handles all these interrupts without really having to worry if they we're caused by software or hardware. But - what if the app is running in Protected Mode ? The performance hit of just switching back down into Real Mode and calling DOS/BIOS everytime we get a system generated (hardware) interrupt is going to be significant. So, instead, hardware interrupts are 'reflected' up to Protected Mode; and the DOS extender used by the PM app will handle the interrupt in PM. Thus avoiding the overhead of switching back down into Real Mode to service every hardware interrupt. Depending on the DOS extender, this may not be true for all hardware interrupts, but (in all DOS extenders I'm aware of) it is *always* true for int 9h, the interrupt we're interested in - the hardware keyboard interrupt. What does this mean for our remapper ? It means this. - even if we wait for MAME to install Allegro's keyboard handler, then replace it with our own remapper. If we install our remapper in Real Mode, it will still never get called. int 9h is a hardware interrupt, so the interrupt is reflected up to PM - and our RM code is never even looked at. So, before we install our remapper - we need to know if the emulator/app is going to be running in Real Mode or Protected Mode (hence 'remaptype' in the .app files) RM Keyboard Remapper -------------------- For Real Mode emus/apps, it's straight forward - arcadeos.exe simply waits for a video mode request then installs the Real Mode remapper. Problem is, just about all emu's are PM apps - so this will only be of use for a tiny percentage of them. PM Keyboard Remapper -------------------- As most emus are PM apps, we need to be able to install our remapper in PM. This is how AOS does it... arcadeos.exe is running in Real Mode, for reasons outlined in the section 'AOS Structure', so it can't install a Protected Mode keyboard remapper. But, it can detect when that remapper should be installed - so all it needs is an application running in Protected Mode which it can tell to install the remapper. This is , basically, what pmwrap.exe is. arcadeos.exe tells pmwrap.exe what to run, then lauches pmwrap.exe. pmwrap.exe launches whatever arcadeos.exe requested - and installs an interrupt in real mode which arcadeos.exe can call If MAME (or whatever) requests a graphics video mode, arcadeos.exe calls pmwrap.exe's real mode interrupt - (rather than installing the keyboard remapper itself) pmwrap.exe receives the call from arcadeos.exe and installs the keyboard remapper in Protected Mode. The above (complex) setup works for just about any application, there are a few exceptions though - and AOS still can't remap keys in RAGE and MagicEngine The Jukebox Screen Saver ======================== The Jukebox screen saver is simply a culimation of the above features of AOS. It picks random games and runs them for a short period of time. It then exits the game and picks another, unless a coin was inserted while the game was running. In which case the currently running game will not be automatically exited and the screen saver will effectively end. Here's how it works: .arcadeos.exe picks a random game and prepares to launch it using pmwrap.exe .arcadeos.exe launches pmwrap.exe .pmwrap.exe installs its protected mode keyboard handler (to enable remapping + check for coin inserts) Then runs MAME with the specified random game .arcadeos.exe intercepts the call from MAME to set a graphics video mode and installs the 'jukebox function' on the PC timer interrupt .the jukebox function installed by arcadeos.exe 'stuffs' key presses into the keyboard controller to get passed the MAME info/warning screens .pmwrap.exe intercepts any key presses made in MAME, if a coin is inserted it flags arcadeos.exe .after arcadeos.exe has got passed the first MAME screens, it sits and waits a specified period of time - the 'jukedelay' value in arcadeos.cfg .if arcadeos.exe doesn't receive the 'coin has been inserted' flag from pmwrap.exe - it inserts 'escape' into the keyboard controllerr, the MAME game is exitied and the loop begins again .if arcadeos.exe does receive the 'coin has been inserted' flag from pmwrap.exe - it removes the jukebox function from the PC timer interrupt and the currently running game will continue as normal AOS System File Formats ======================= AOS uses various files to store information about an emulator and its games. The files discussed here are used exclusively by the main PM part of AOS (arcadeos.bin). All formats are subject to change, the following describes the correct file formats for ArcadeOS Version 2.34 .RMS ==== .RMS files contain a list of all the ROMS found for a specific emulator. The file name will be .rms i.e. MAME.RMS. The format is as follows: Header ------ 10 bytes containing the following characters: RMS32BIT5 This identifies both that it is an RMS file, and the version number of the file format. Data Records ------------ After the header there will be 0 or more of the following records. Each record represents a ROM found for this emulator All sizes in bytes Name Description Size ---- ----------- ---- Game Name Short name of ROM i.e. file name 12 Display Name Long name of ROM 64 Parent Short name of Parent ROM (if clone) 12 Extension File extension i.e. zip 8 Orientation Orientation of the game 1 The bottom 3 bytes of this indicate the rotation of the game. The top 5 bytes indicate the custom list SaveOrient Original orientation/custom list of game 1 GameType Indicates if the game is a normal file, 1 directory or a zip Config items This is an array of 64 2 byte pairs, used 128 to store individual config items for this game Local Config Indicates if this game has any local 1 config items Changed Indicates if the record has been changed 1 and as a results needs to be updated File Position Position of this record within the file 4 Random Run Indicates if this game has already been 1 chosen by the various 'random game pick' functions in AOS NEOGEO.LST ========== This is a list of all the NeoGeo games supported by MAME, it is generated from MAME. The format is as follows: Header ------ NeoGeo.lst's header consists of the time and date stamp of the MAME executable used to generate it. This way, AOS can automatically update NeoGeo.lst if a different version of MAME is used. The header consists of 22 bytes i.e. ª21:40:50::12/17/1999| Data Records ------------ The data records within NeoGeo.lst are variable and delimited. There are 0 or more data records, depending on the number of NeoGeo games supported by the version of MAME used. The format is as follows: Name Description Size ---- ----------- ---- Start delimiter The character '^' 1 Game Name Short game name i.e. file name variable End delimiter The character '{' 1 i.e. ^NAM1975{ MAME.LST ======== This is a list of all games supported by MAME, it is generated from MAME. The format is as follows: Header ------ MAME.lst's header consists of the time and date stamp of the MAME executable used to generate it. This way, AOS can automatically update MAME.lst if a different version of MAME is used. The header consists of 22 bytes i.e. ª21:40:50::12/17/1999| Data Records ------------ The data records within MAME.lst are variable and delimited. There are 0 or more data records, depending on the number of games supported by the version of MAME used. The format is as follows: Name Description Size ---- ----------- ---- Start delimiter The character '^' 1 Game Name Short game name i.e. file name variable Item delimiter The character '{' 1 Display Name Long game name variable Item delimiter The character '{' 1 Parent Short name of game's parent (if clone) variable Info delimiter The characters '{@' 2 Game Info This stores 3 pieces of information about 1 the game in the 3 lowest bits, it also adds 32 to this value, to avoid the byte being set to 0 bit 0 - Game is rotated bit 1 - Game is okay bit 2 - Game is a vector bit 5 - always set to 1 i.e. ^SXEVIOUS{Super Xevious{XEVIOUS{@# MAMEINFO.LST ============ This contains information about all games supported by MAME, it is generated from MAME. The format is as follows: Header ------ MAMEinfo.lst's header consists of the time and date stamp of the MAME executable used to generate it. This way, AOS can automatically update MAMEinfo.lst if a different version of MAME is used. The header consists of 22 bytes i.e. ª21:40:50::12/17/1999| Data Records ------------ The data records within MAMEinfo.lst are variable and delimited. There are 0 or more data records, depending on the number of games supported by the version of MAME used. The format is as follows: Name Description Size ---- ----------- ---- Start delimiter The character '^' 1 Game Name Short game name i.e. file name variable Info delimiter The characters '{@' 2 General Info This stores 4 pieces of information about 1 the game in the 4 lowest bits, it also adds 32 to this value, to avoid the byte being set to 0 bit 0 - Game is okay bit 1 - Game is a vector bit 2 - Hiscore is okay bit 3 - Colour is okay bit 5 - always set to 1 Frequency Vertical refresh rate of the game 1 Players Number of players the game supports 1 Coins Number of coin inputs the game supports 1 Colour Depth Colour depth of the game 1 Item delimiter The character '{' 1 Colours Number of colours in the game variable Item delimiter The character '{' 1 Resolution Resolution of the game variable Item delimiter The character '{' 1 Controls Input controls used by the game variable Item delimiter The character '{' 1 Year Year of games manufacture variable Item delimiter The character '{' 1 Manufacturer Manufacturer of the game variable Item delimiter The character '{' 1 i.e. ^PACMAN{@-<{16{224x288{joy4way{1980{Namco{ AOS BIOS Extensions =================== As well as hooking into BIOS and DOS to perform some of it's functions, AOS also adds 18 functions to BIOS. These are called in the same way normal BIOS functions are called (thorugh int 10h). All of AOS BIOS functions require ah to be set to 255, so as not to clash with any existing BIOS functions. The 18 functions are (with function numbers [contents of al on entry]): .99 - Check Bios .100 - Set Monitor Type .101 - Center Screens .102 - Scanlines .103 - Allow VESA .104 - Set Timings for Arcade/TV Modes .105 - Set Timings for Scanline Modes .106 - Get Last Mode Set .107 - User Escape .108 - Setup ModeX Arcade Mode .109 - Block Video Mode Changes .110 - Set Jukebox Delay .111 - Store AOS Commands .112 - Store Emu Config .113 - Store Wrapper Commands .114 - Retrieve AOS Commands .115 - Retrieve Emu Config .116 - Retrieve Wrapper Commands Check Bios ---------- Description: Checks for existence of AOS BIOS extensions Inputs: al : 99 ah : 255 Outputs: If AOS BIOS extensions are present, bx is set to 24 Set Monitor Type ---------------- Description: Sets a flag which determines the type of video modes generated Inputs: al : 100 ah : 255 bl : mode type , 0=PC,1=Arcade/NTSC,2=PAL Outputs: None Center Screens -------------- Description: Centers all video modes based on values passed in Inputs: al : 101 ah : 255 bl : center x offset bh : center y offset Outputs: None Scanlines --------- Description: Sets a flag to determine if video modes will be 'scanline' modes Inputs: al : 102 ah : 255 bl : 0=no scanlines,1=scanlines Outputs: None Allow VESA ---------- Description: Allows/blocks VESA mode requests Inputs: al : 103 ah : 255 bl : 0=block VESA modes,1=allow VESA modes Outputs: None Set Timings for Arcade/TV Modes ------------------------------- Description: Sets horizontal and vertical timing values for arcade monitor and TV modes Inputs: al : 104 ah : 255 bl : horizontal timing value bh : vertical timing value Outputs: None Set Timings for Scanline Modes ------------------------------- Description: Sets horizontal and vertical timing values for scanline modes Inputs: al : 105 ah : 255 bl : horizontal timing value bh : vertical timing value Outputs: None Get Last Mode Set ----------------- Description: Returns the last video mode set Inputs: al : 106 ah : 255 Outputs: bx : last mode set User Escape ----------- Description: Indicates if user escaped out of last game, or if AOS exited it automatically Inputs: al : 107 ah : 255 Outputs: bx : 24=user pressed escape,0=AOS escaped from the game Setup ModeX Arcade Mode ----------------------- Description: Sets up flags in AOS so it can generate arcade monitor modes for ModeX or tweaked video modes Inputs: al : 108 ah : 255 bl : id of ModeX to set bh : delay before setting mode Outputs: None Block Video Mode Changes ------------------------ Description: Allows blocking of all video mode changes other than 13h (320x200 at 256 colours) Inputs: al : 109 ah : 255 bl : 0=don't block video modes,1=block video modes Outputs: None Set Jukebox Delay ----------------- Description: Sets the delay used in the Jukebox Screen Saver which determines how long each game is run for Inputs: al : 110 ah : 255 bl : jukebox delay Outputs: None Store AOS Commands ------------------ Description: Save a set of AOS commands, used for communication between the RM and PM modules of AOS. Inputs: al : 111 ah : 255 bx : segment of data to store dx : offset of data to store cx : size of data to store Outputs: None Store Emu Config ---------------- Description: Save an Emu's current config file contents, used for communication between the RM and PM modules of AOS. Inputs: al : 112 ah : 255 bx : segment of data to store dx : offset of data to store cx : size of data to store Outputs: None Store Wrapper Commands ---------------------- Description: Save a set of AOS wrapper commands, used for communication between the RM and PM modules of AOS. Inputs: al : 113 ah : 255 bx : segment of data to store dx : offset of data to store cx : size of data to store Outputs: None Retrieve AOS Commands --------------------- Description: Returns a set of previously saved AOS commands, used for communication between the RM and PM modules of AOS. Inputs: al : 114 ah : 255 Outputs: bx : segment of data retrieved dx : offset of data retrieved cx : size of data retrieved Retrieve Emu Config ------------------- Description: Returns a previously saved emu config file contents , used for communication between the RM and PM modules of AOS. Inputs: al : 115 ah : 255 Outputs: bx : segment of data retrieved dx : offset of data retrieved cx : size of data retrieved Retrieve Wrapper Commands ------------------------- Description: Returns a set of previously saved AOS Wrapper commands, used for communication between the RM and PM modules of AOS. Inputs: al : 116 ah : 255 Outputs: bx : segment of data retrieved dx : offset of data retrieved cx : size of data retrieved Real Mode / Protected Mode DOS ============================== Much of the complexities of AOS arise from DOS itself, and the way it has been 'extended' to keep up with the huge differences between the original PC, and the 'standard' PC of today. Without going into too much detail, the original PC (based around the 8086/8088) could only address 1MB of memory. Later variants of the 80x86 family, (80286, 80386, 80486, Pentium x) could address far more memory, but only if 'switched' to a special mode. This mode is called 'Protected Mode', it not only gives you more memory but also true multitasking enviroments, page swapping, virtual machines etc. This also gave rise to the term 'Real Mode', used to describe the original 8086/8088 way of looking at the world - Only 1MB of memory and no multitasking. All 80x86 chips can run in 'Real Mode'. MS Windows (from version 3.0 'enhanced mode' onwards) runs in Protected Mode, BUT - if you open a 'DOS Box' under any version of Windows; you are running in Real Mode (To all intents and purposes it is standard Real Mode. To be accurate, it's actually something called V86 Mode - Virtual 8086 Mode. This allows multiple encapsulated real mode environments to run on one machine). So, your DOS program running in it's DOS box knows nothing about anything else that is running on the PC and thinks you only have 1MB of memory. Why doesn't DOS see your 256MB of memory ? Why can't it multitask between applications ? Why can't one DOS app share data with another one ? Because DOS is a Real Mode OS, it was designed to run on a 8086. Other than a few sneaky tricks by MS to exploit the 80286 (UMB) and up - standard PC DOS sat on a Pentium III would run just as happily on a lowly 8086. There's a large legacy of software that relies on this, if DOS was to be re-written so it took full advantage of Protected Mode; most of this software would suddenly stop working. There are various options if you want to run a multitasking, PM environment on your PC - MS/PC-DOS isn't really one of them. OK - so DOS is still DOS, but why can't we just get access to all this extra memory and functionality the 80x86 chips offer us without re-writting DOS ? Why can't we just slip into PM when running our application,'patch up' DOS as needs be to handle our one running application, the slip back into RM when we've finished ? This is exactly what DOS extenders/DPMI do, and it's how most emulators work. DOS Extenders ------------- A PM DOS application (if it's going to do anything useful) is going to have to have access to DOS - otherwise most of the PC itself is going to be 'invisible' to the application. But DOS is a RM OS, so a PM application cannot call any DOS function directly. This is where a DOS extender comes into play. A DOS extender will (generally) do the following - .Switch the PC into PM .Run the PM DOS application .'Service' any DOS/BIOS calls made by the application .On program exit, switch back to RM How the DOS extender services calls made by the application depends on the extender itself, and the type of call made. It could just simply switch down into RM, and call the original DOS function. Or it could service the call entirely in PM, or it could do a mixture of the two, with both changes to DOS placed in RM, and extra functionality placed in PM. How much it uses a DPMI Server (discussed below) is also up to the extender. An extender could be written which doesn't use DPMI at all. Or it could choose to use a DPMI Server if one is detected, and use code contained within the extender itself (acting as a 'local DPMI Server') if no DPMI Server is found. DPMI ---- DPMI - DOS Protected Mode Interface. DPMI is basically a set of functions defined to allow various PM DOS applications to coexist peacfully. The idea is that there is one DPMI Server and one of more DPMI Clients. Each of the clients requests services from the server (to do with memory, interrupts,debug etc.) The server manages these requests between clients - handling any conflicts between the clients. The DPMI spec (version 0.9) consists of 77 functions. Examples of DPMI servers are: Windows 95 CWSDPMI For the most part - application programs can ignore the inner workings of DPMI. It's really only of interest to people writing DOS extenders, or lowlevel 'operating system' like code. Brian Lewis 2000 ++++++++++++++++