386POWER 1.01 TECH REF WHAT'S THIS ? 386Power is a simple unified interface to DPMI and VCPI dos extender services. It kicks your program in 32bit protected mode and gives you an application programmer interface similar to that of PMODE 386 by Thomas "Tran" Pytel. Nothing strange, initially i started coding a library for PMODE386 but after some troubles with things relating the dos-ext. i decided to make sort of dos extender on my own. This documentation ...well i had not much time left... it will get better in future releases After reading ALL THIS FILE (look in the end for some TECHNICAL things you have to absolutely know). look into TECH.DOC for a programmer reference and more info about the inner working of 386P. For more info about the companion XGE code (graphics, sound, etc. etc.) look the other text files for an overview and into the .INC files or into the sorce code for deeper info. Look into EXAMPLES.DOC for the info needed to get fully running examples. WHAT IT DOES: Well, the 386power module kicks your program in 32bit protected mode and allocates memory and segment descriptors for you, then it gives you a SIMPLE interface you can use to call dos/bios functions. The XGE (eXtended Game Engine) modules (read: all the other stuff) are a collection of things you may find useful if you wanna work in protected mode to devenlop your game engine. You may wonder why i insist talking about game engines instead of "programs". The reason is simple: If you think to devenlop a brand new assembly program for every game you will make ... you are nuts. Instead identify the type of game you want to make (a boardagame with animations, a beat 'em' up, a shoot 'em' up, a simulator etc. etc.), make a game engine for it, complete the g.e. with the graphics the sound , the soundtrack and at last the finite state machines (actually a bunch of lookup tables) you need to describe the game rules and animations and LO! YOU GET A COMPLETE GAME! Then, if your game is successful you can quickly make a sequel, maybe enhancing a little the game engine, adding new graphics and new finite state machines for new rules and/or "actors". Else if it fails but you think the initial idea was correct, you will concentrate on the actual game coding (the g.e. is allright) cutting the devenlopement time. FROM WHERE IT COMES FROM: This code has been produced following the information obtained from ... a) DPMI 1.0 and 0.9 specs (uploaded from Internet) b) The Ralph Brown Interrupt list (uploaded from Internet) Valuable source of informations for the VDS and VCPI specs c) The PMODE386 dos extender by Thomas Pytel a.k.a. Tran from Renaissance (i looked in pmode.doc and reverse engineered the source to understand how to connect properly with DPMI and VCPI, it's not as simple as the technical documentation says. ) I even COPIED some chunks from PMODE source code. So i don't totally "own" 386Power code, but nor you neither Tran. d) All the people that reported me bugs and program quirks I cannot list them all , but the first one needs a special mention: Alex Yu from Taiwan WHO OWNS IT ? As i said, 386Power code is not all mine, i've copied some algorithms from PMODE dos-extender by Tran. The XGE code instead is all mine. What i own is the 386Power product name and big chunks of code into it, if you use 386Power you HAVE to give credits to me (Lorenzo Micheletto) and to Tran (Thomas Pytel). Simply do not remove the "diagnostic" messages and if you put a "credits" screen on your program include me and Tran and you are OK. If you do this, you can freely use 386Power on anything you want ( except viruses or trojan horses, i hate those losers that think they are smart just because they can write such beginners stuff ) You can even alter the sources, but if you do this you have to change the product name (but leave partial credits to me and Tran) OR specify it is an altered version. My numering procedure is as follows: 386P Rev. XX.YZW Where XX is the revision major number Y is the revision minor number Z is the revision "minor bugfix" number W is the revision "cosmetic update" number If you modify 386Power you have to add a "secondary revision" identifier i.e. if you modify 386P 01.020 you can call it 386P 01.020:01.000 and "mark" your updates to the original code in the second revision number. Of course if you make radical alterations you'd better change the product name to avoid confusion. WHAT'S PART OF 386Power is part of the XGE (eXtended Game Engine) project i started 5 months ago, after i decided to move to extended mode for game devenlopement. XGE consist of: a) Public domain stuff 386Power Interface to DPMI or VCPI protected mode services. FLAT 386 programming model Automatic irq reflection under VCPI 386File Simple file i/o from protected mode. vdma Virtual DMA support 386Video basic graphics functions 386mouse basic mous efunctions 386joy joystick 386keyb "raw"keyboard support 386arg command line scanner 386menu full screen menu support PCX PCX decoder. Pix Basic pixel and rectangle plotting under mode-x Picture Routines to handle linear bitmaps and Transparency-run-lenght-encoded sprites under mode-x CharIO Multicolor Character I/O u Pattern Tile handling SOME THINGS YOU'D BETTER REMEMBER: DPMI DPMI is a strange beast, it virtualize things, so some things that under VCPI run as expected becomes quite fuzzy under ring 3. Minimize OUT and privileged instructions to avoid problems and always keep in mind you are running on (badly) virtualized hardware. When running under DPMI , 386P tries to allocate all lockable memory (so you can use extended memory for irq code/data and avoid disk swapping). IF YOU USE EXTENDED MEMORY FOR STORING IRQ CODE/DATA YOU'D BETTER LOCK THE CHUNKS OF MEMORY YOU ABSOLUTELY NEED. INTERRUPT VECTORS Under 386Power you have THREE SETS of interrupt vectors The V86 interrupt table The Protected Mode interrupt table The OldInt (OLD V86 INTerrupt) table OldInt gets initialized when 386P starts with the vectors found in the dos interrupt table (the V86 interrupt table) When you call int 33h from protected mode you actually call AN INTERRUPT VECTOR IN THE OldInt TABLE !!! If an IRQ happens while in 32bit mode, the protected mode table is used. If an interrupt happens in V86 mode, and you run under DPMI, the irq is reflected to protected mode, else under VCPI the real mode handler is called. Here comes the OldInt table. Every IRQ not supported in protected mode gets redirected to the OldInt table (initially equivalent to the V86 table). If you change the ISR from prot. mode you don't have to save the old V86 MODE irq (it is already into the OldInt table, and it will be restored into the V86 table at program termination). What's more, from inside a protected mode irq handler you can call the "old" real mode irq using int 33h (from prot. mode) without having to worry about "infinite irq loops". Foggy, isn't it ? We'll the first time you have to chain&bypass an ISR you'll be happy there are 3 int tables! PARAMETER PASSING CONVENTION: Parameters for procedures in the companion XGE assembly code files are assigned in the following order EDI = pointer to destination OR base offset of destination screen ESI = pointer to source data (usually bitmap data) EAX = x position OR 1st parameter EDX = y position OR 2nd parameter ECX = x-width OR 3rd parameter EBX = y-width OR pointer to characters OR 4th parameter EBP = 5th parameter The reason i use registers is that xge code mostly interract with hardware or executes "basic" operations, usually it does not call other subfunctions so it is faster is all the parameters it need are already into registers. INT 32h FROM REAL MODE: Calling int 32h from real mode the flag register WON'T BE UPDATED by the result of the function called, nor the virtual registers will be passed. The int 32h system must be used only to pass control to prot. mode code, the less you use it, the better.