386POWER 0.999 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 i decided to make sort of dos extender on my own. This documentation is a beta earlier that the code it describes :} it will get better in future releases (386POWER+XGE rev. 1.000 will be out in June/July 1994 if everything goes wrong ...) 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 (mode-x, etc. etc.) look into the .INC files or into the sorce code. Look into EXAMPLES.DOC for the info needed to get fully running examples. 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) The VGA mode-X library XLIB (not the X-windows XLIB) WHO OWNS IT ? As i said, 386Power code is not all mine, some portions have been copied 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. It features: FLAT 386 programming model BIMODAL IRQ support by way of triple level irq handling Incoming features: VIRTUAL DMA support from the dos-ext. Automatic irq reflection under VCPI 386File Simple file i/o from protected mode. 386Video Mode-X vga support with triple buffered display pages Timekeeping support and basic PWM sound system and VOC decoder. Raw keyboard support, to detect any key pressed without the bios limits. N.B. The PWM stuff is still experimental, i have to work more on this. PCX PCX decoder of 256 colors 320x200 images. Pix Basic pixel and rectangle plotting under mode-x Picture Routines to handle planar bitmaps and Transparency-run-lenght-encoded sprites under mode-x CharIO Character I/O under mode-x Pattern Tile handling under mode-x (still working on it) b) Extra stuff not included, listed here to give you an idea of what's left out if you plan to make a game. VBlit Virtual screen support, background refresh system and video effects. BlitOpt Blit Optimizer to reduce the bytes moved from virtual screens to physical display pages. AutomaT Finite state engine to animate things. 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). Windows has some problems (it says there is more available memory than actually is) so to allocate ext. mem i use a loop and every time the program tries to allocate memory, it writes a message to screen, so don't panic if at program startup you see lots of messages saying that function 501h has failed, sooner or later it will be successful or the program will end after getting under EXTMIN. In the next release i will fix this. After function 501h is successful, function 600h is called to lock the memory block allocated, but i don't check if it is successful because i lock it just to avoid disk swapping. IF YOU USE EXTENDED MEMORY FOR STORING IRQ CODE/DATA YOU'D BETTER LOCK AGAIN 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, the V86 table is used (under VCPI) or if the irq is not supported it gets reflected to the prot. mode table (this USUALLY happens if you run under DPMI). As you can guess this means troubles if you want to change ISR routines and want your stuff to work under VCPI and DPMI. 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 under V86 mode you don't have to worry about irq reflection, you can chain the old interrupt with a pseudo-call to OldInt (located in the code16 segment) from V86 mode OR you can call the old protected mode IRQ handler (when running under prot. mode) so it can call OldInt. 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 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 4th parameter EBP = 5th parameter 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, the less you use it, the better.