╨╧рб▒с>■  IJ■   H                                                                                                                                                                                                                                                                                                                                                                                                                                                ▄еhWр eєt$ОєqА╕А╕╕Б╕Б╕Б╕Б╕БТВTТВцДцДцДцД ЁДТВLНD Е"Е"Е"Е"Е"Е$FЗ<ВИа3Л5Л5Л5ЛQЖЛ╘ZМ╘.НРНXшН<LН╕Б"Й;<"Е"Е"Й"ЙLНЇК╕Б╕Б"Е ЕЇКЇКЇК"Й╥╕Б"Е╕Б"Е3Л╟/v;╠╗╠БJВ|╕Б╕Б╕Б╕Б"Й3ЛЇК?ЇКUsing the SuperVGA Kit This section provides an overview of the SuperVGA Kit, and provides background details on the SuperVGA Kit functionality and how to utilize this functionality in your own applications. Note that the SuperVGA Kit is no longer a supported SciTech Software product, and for maximum portability you should attempt to move all your SuperVGA Kit code across to use the real MGL API. However the SuperVGA Kit is still provided, and this documentation is provided for developers who are content to use this API. What is the SciTech SuperVGA Kit? The SciTech SuperVGA Kit is a Software Development Kit for working with VESA VBE compliant SuperVGA graphics cards under both DOS and Windows. This SDK includes full support for all standard VBE devices, as well as devices that support the new VBE/AF Accelerator Functions specification. Although VBE 2.0 or VBE/AF 1.0 is required to get the maximum performance out of this library, it does provide full support for existing controllers that support the VBE 1.2 and lower specifications. The SciTech SuperVGA Kit provides support for both 16 bit real mode and 32 bit protected mode development under MS-DOS, and both 16 and 32 bit protected mode under Windows 3.1 and Windows 95. Under Windows 3.1 and Windows 95 the SuperVGA Kit is provided as both 16 and 32 bit DLLТs, and as statically linkable libraries. If you wish to use the static link libraries under 16 bit Windows, please read the special section related to this below. SuperVGA Kit components The SuperVGA Kit consists of a number of header files and static link libraries for DOS and Windows applications, or as 16 or 32 bit DLLТs for Windows applications. Table 1 lists the files that comprise the standard SuperVGA Kit library package (see installation section for details on where the files will be located). FilePurposeSVGA.HMain SuperVGA Kit header fileSVGAMGL.HSuperVGA Kit Compatibility Library header fileVESAVBE.HHeader file for VESA VBE 1.2/2.0 interface moduleVBEAF.HHeader file for VBE/AF 1.0 interface moduleSVGA.LIBStatic link libraries for default calling conventionsSVGAMGL.LIBSuperVGA Kit Compatibility LibrarySSVGA.LIBWatcom C++ static link libraries for stack calling conventionsSSVGAMGL.LIBWatcom C++ SuperVGA Kit Compatibility Library for stack calling conventionsSVGA62.LIB16 bit SuperVGA Kit for Windows import librarySVGA62F.LIB32 bit SuperVGA Kit for Windows import librarySVGA62.DLL16 bit SuperVGA Kit for Windows DLLSVGA62F.DLL32 bit SuperVGA Kit for Windows DLLTable  SEQ Table_A- \* ARABIC 1 Note that in order to use the SuperVGA Kit for Windows, you will also need the WinDirect package (described below) to shut down and restore GDI. Using Windows 16 bit static link libraries In order to support 32 bit linear framebuffer access from 16 bit Windows code, the SuperVGA Kit includes special 32 bit linear framebuffer assembler functions. These functions are 32 bit assembler code that reside in a completely separate 32 bit code segment. Before any of the 32 bit code can be run, the SuperVGA Kit code calls a special function in the 32 bit code segment that will convert the selector for that segment to a 32 bit code segment selector. However current 16 bit C compilers donТt know about 32 bit code segments, and by default will automatically merge the 32 bit code segment with your applications normal 16 bit code segments. When this happens, the same selector will be used for the 32 bit code segment and any of the merged 16 bit code segments! Naturally the code will not run correctly, and your program will crash. The solution is to ensure that when you link your application that you tell your linker to turn off the code segment packing option during the link, which will solve the problem. An alternative solution is to always use the provided 16 bit DLL rather than linking with the static link library for 16 bit Windows code. Building applications with the SuperVGA Kit To build an application using the SuperVGA Kit, you will need to include the SVGA.H header file in your code, and link your application with both the SVGA.LIB and PMODE.LIB libraries for your DOS Extender (see section of PM/Pro library for more details). You will need to ensure that you select the correct libraries for the specific compiler and calling conventions that you are using. For Windows code you will need to link with the PM/Pro DLL import libraries because the PM/Pro library is only provided as DLLТs for Windows. If you are compiling Windows code and wish to use the DLL version of the SuperVGA Kit, you will need to #define SVGA_DLL when you compile all source modules that include the SVGA.H header file, and link with the SuperVGA Kit DLL import libraries for your compiler. The DLL import libraries have the same name as the DLL files for this release of the SuperVGA Kit with the .LIB file extension (i.e. SVGA60.LIB or SVGA60F.LIB for the 6.0 release). Note that for Windows code using the DLL libraries you will not need to link to the PM/Pro library files unless you make explicit calls to these library functions, as the SuperVGA Kit DLLТs are already linked to the PM/Pro library DLLТs. The SciTech SuperVGA Kit comes with full source code, so you can also directly include the source code for the SuperVGA Kit in your own programs rather than linking with the pre-compiled libraries. However you will need Turbo Assembler 4.0 or later in order to assemble the provided assembler source code (extract the object files from the provided libraries with your compilerТs librarian if you donТt have Turbo Assembler). If you donТt wish to use the entire SuperVGA Kit libraries in your application but wish to support VBE 2.0 in your applications, we highly recommend you link in and use the VESAVBE.C module as your main interface to VBE 2.0. None of the code in VESAVBE.C is speed critical, and this module takes care of fixing minor bugs in slightly varying VBE implementations to make the high level interface consistent. This module also takes care of isolating protected mode applications from the need to deal with pointers to real mode memory locations by mapping all such data into the default data segment automatically. SuperVGA Kit compatibility library If you have developed an application using the SuperVGA Kit and you would like to move up to the full MGL API, you can get started quickly with the SuperVGA Kit compatbility library. This is a small library that exports an identical API to the original SuperVGA Kit, but you link your code with the MGL libraries rather than the SuperVGA Kit libraries. If you do use the compatibility library, we recommend that you eventually port your code over to the full MGL API, as the SuperVGA Kit compatibility library is not portable to Windows and will not work with the DirectX libraries. The full source code to the compatibility library is provided as part of the standard MGL distribution, so you can use that source code as a guide to helping you port your code from the SuperVGA Kit API to the full MGL API. Using the SuperVGA Kit Compatibility Library In order to ease the porting effort required to move your code from the SuperVGA Kit API over to the SciTech MGL API, we have provided a small SuperVGA Kit Compatibility Library (with source code). This library implements the entire SuperVGA Kit API but implements all the mode initialization and graphics output functions using SciTech MGL. To use this library, all you need to do is compile your code as normal, and then simply relink with both the SVGAMGL.LIB and the appropriate MGL libraries (i.e. MGLLT.LIB for the MGL/Lite libraries). If however you are using the WinDirect compatibility libraries for event handling under DOS, you will need to include the SVGAMGL.H header file instead of the standard SVGA.H header file. This file contains some translation macros and functions to translate the event handling functions from the WinDirect API to the SciTech MGL API. Initializing the SuperVGA Kit Before you can use the SuperVGA Kit, you need to call the SV_init initialization function. This function takes a flag that indicates whether you wish to search for and use VBE/AF services where available, and will return a pointer to the SuperVGA KitТs global device context block. This global device context block maintains all the state information for the SuperVGA Kit, and can be used to directly access many of the SuperVGA KitТs internal variables for maximum performance. Note that this is slightly different to the previous 5.x releases of the SuperVGA Kit where all global variables were available directly. Since the SuperVGA Kit has been updated to support both 16 and 32 bit DLLТs under Windows, the interface was changed to include a global device context block pointer returned to the application. The reason for this is that you cannot share global variables directly in 16 bit DLLТs (you can for 32 bit DLLТs, but many compilers do not currently support this). The advantage to the new interface is that you can change from the static link libraries to the DLL version of the SuperVGA Kit simply by adding the #define SVGA_DLL and recompiling and linking your code. Starting a graphics mode Before you can start any graphics mode, you must first find the mode number of the graphics mode that you wish to start. The SuperVGA Kit does not define any standard mode numbers, and it is up to your application code to read through the list of available graphics modes and to search for a graphics mode with the desired resolution and color depth using the VBE_getModeInfo function. The SuperVGA Kit allows you to start a graphics mode using either the banked framebuffer, a virtual linear framebuffer or a hardware linear framebuffer on the graphics card (depending on the underlying VBE driverТs capabilities). When the SuperVGA Kit is initialized, it will interrogate the graphics card and determine if it supports a hardware linear framebuffer. If it does support one, the linearAddr variable in the global device context block will be set to the value of the physical address of the linear framebuffer (this is not a CPU address, so donТt try to write to it!!). It is then up to your application to pass the svLinearBuffer flag to the SV_setMode function when you start the graphics mode, and it will enable the hardware linear framebuffer mode. If a hardware linear framebuffer mode is not available, the SuperVGA Kit checks to see if it is possible to initialize a virtual linear framebuffer using the 386 virtual memory manager (not possible under DOS boxes and some DOS extenders). If this is possible, it sets the haveVirtualBuffer flag in the global device context block to true, indicating that the virtual linear buffer is available. When you initialize a graphics mode, the SuperVGA Kit will check the useVirtualBuffer flag you pass to the set mode functions to determine if the virtual linear framebuffer should be used. If this flag is set to true the virtual linear framebuffer mode will be initialized and the virtualBuffer flag in the global device context will be set to true to indicate that the virtual buffering mode is currently active. Once the graphics mode is initialized, you can draw to it using the supplied SuperVGA Kit graphics output functions (not very spectacular) or you can write your own high speed rendering code to render directly to the linear framebuffer regions. Note that if you are using the SuperVGA Kit under Windows, you must call the WinDirect WD_startFullscreen function before you initialize a graphics mode, and you must call WD_restoreGDI to return back to normal Windows mode. Failing to do so will cause the SuperVGA Kit to write to the display concurrently with GDI and will cause GDI to eventually lock up. Starting a virtual scrolling graphics mode If you wish to use hardware virtual scrolling with the SuperVGA Kit, you must initialize the graphics mode using the SV_setVirtualMode function rather than the usual SV_setMode function. The virtual scrolling version of this function takes two extra parameters that define the virtual height and virtual width of the graphics mode that you wish to initialize, and will attempt to start the graphics mode with the specified virtual dimensions. If the graphics hardware cannot handle a virtual mode of these dimensions, this function will fail. Once the virtual scrolling mode has been initialized, you can use the SV_setDisplayStart function to set the display start address for the mode, allowing you to scroll the visible window into the framebuffer memory using the hardware panning registers. Changing the color palette In order to change the color palette for the current graphics mode, you will need to call the SV_setPalette function. It is important that you use this function to set the hardware palette, as VBE 2.0 and VBE/AF devices may be running in a NonVGA graphics mode in which case directly programming the standard VGA registers is not possible. Performing double buffering In order to perform double buffering with the SuperVGA Kit, you must pass the svDoubleBuffer flag combined with the number of the graphics mode you wish to initialize when you call SV_setMode or SV_setVirtualMode. This flag is necessary to correctly inform the VBE/AF drivers that you wish to perform double buffering, so that the drivers will correctly set aside enough framebuffer memory to hold the double buffers and decrease the size of the available offscreen framebuffer memory used for storing bitmaps etc. If the mode is incapable of double buffering the mode set will still work correctly, however the mode will be set up for single buffered operation. Once a double buffered graphics mode has been started, the mode will be set up with the active and visible buffers both set to the first buffer in framebuffer memory and the system is essentially in normal single buffered mode. To perform double buffering you simply make calls to the SV_setActiveBuffer and SV_setVisibleBuffer functions to change the active and visible buffers. The active buffer is the buffer where all output will currently be drawn, and the visible buffer is the one that the graphics card is currently displaying. For double buffered animation you set the active buffer to a hidden buffer so that you can draw to it without the user seeing the draw occur on the display, and then switch the visible buffer to the hidden buffer to instantly display the new frame. If you are doing double buffering and you wish to render directly to the framebuffer, you will need to use the originOffset and bankOffset variable in the global device context block to determine where the currently active buffer starts. In banked modes these define the starting 64Kb bank and offset with that 64Kb bank for the currently active buffer, while in linear framebuffer modes the originOffset variable points directly to the start of the active buffer in the 32 bit linear address space. Drawing pixels, lines and text The SuperVGA Kit provides a few limited functions for drawing graphics output, such as pixels, lines and text. These pixel output and line drawing functions are written in highly optimized assembler code so they are very fast. However the primary purpose of the SuperVGA Kit is not to provide a rich set of graphics primitives, so only solid, single pixel lines are supported. The text output function is written in C and calls upon the pixel output functions to draw the text, so it is not particularly fast. Note that the SuperVGA Kit provides two methods of drawing pixels and lines. The first method is via the standard functions and can be used to draw pixels and lines at any time within your code. The second set of functions are provided for drawing fast batched pixels and lines, and provide routines that will draw pixels and lines as fast as possible when you need to draw multiple lots of each different primitive. To use the batched drawing functions, you must call the SV_beginPixel or SV_beginLine functions first, and then call the fast variants of the normal drawing functions. When you are finished rendering you must call SV_endPixel or SV_endLine to return to the normal mode of operation. The batched functions are important for obtaining the maximum performance when drawing lines and pixels on VBE/AF devices, especially when the line drawing is being performed in software (for VBE/AF devices you need to arbitrate direct access to the framebuffer with the GUI engine). Direct framebuffer access One of the powerful features of the SuperVGA Kit is that it provides your applications with direct access to the hardware video memory framebuffer regions. Access is provided either via a banked framebuffer architecture or via a high performance linear framebuffer architecture on graphics hardware that supports it. This means that you can use the SuperVGA Kit to perform all the low level housekeeping and mode initialization functions required to get up and running in SuperVGA modes, and then use your own high performance rendering code to render directly to the hardware framebuffers. A banked framebuffer is provided by VBE 1.2 and earlier compliant devices and also by VBE 2.0 and VBE/AF devices that donТt support a hardware linear framebuffer. In order to access the huge amount of video memory on the graphics card directly, we need to map each section of video memory into a 64Kb bank located in the first 1Mb of memory. In order to change the active bank, you need to call provided SV_setBank function with the index of the bank that you wish to make active. If you are writing high performance assembler code, you should call the assembler SV_setBankASM version of the bank switching function which takes itТs parameters in CPU registers rather than on the stack. Once you have changed the active bank to the location where you wish to perform your drawing, you can then draw directly into the framebuffer via videoMem pointer provided in the SuperVGA Kit device context block. Note that if you are performing double buffering, the originOffset and bankOffset variables in the device context block are used to indicate where in video memory the currently active buffer begins, and you will need to offset all your drawing code into the framebuffer using these variables (check the _SVGASDK.ASM module for details on how this is done in assembler code). If the application is running in a 32 bit protected mode environment, we can simplify access to the video memory on the graphics card by using either a hardware or virtual linear framebuffer. A hardware linear framebuffer allows the application to directly access all of the memory on the graphics card in one contiguous chunk, rather than having to deal with moving a sliding 64Kb window into the framebuffer. A virtual linear framebuffer is enabled by using the 386+ CPUТs virtual memory features to create what appears to be a linear framebuffer, but is actually a region of virtual memory that automatically maps the controllers 64Kb banked aperture when the application directly accesses portions of the virtual framebuffer. If a linear framebuffer mode is started with the SV_setMode function, the videoMem variable of the global device context block will point to the start of the linear framebuffer region, and you can use this variable to render directly into it. Note that if you are doing double buffering the originOffset variable is set to point directly to the start of the currently active buffer in linear framebuffer memory, and the videoMem and bankOffset variables are no longer used. Virtual linear framebuffer access It is possible that when the graphics mode has been initialized, it has been initialized with a linear framebuffer virtualized in software (if you passed the useVirtualBuffer flag to true for the mode set). If you intend to directly render to a virtual linear framebuffer, there are a few caveats that must be understood. First, there is an overhead involved in the page faulting mechanism that is used to automatically map the graphics memory, so it wonТt be as fast as highly optimized bank switched code (but it comes very close). If you are simply copying blocks of data to the framebuffer in a left to right and top down fashion, the copying will not cause very many page faults and hence the overheads will be small if not negligible. If however you are drawing random lines on the screen, you will find that the overhead involved in the page faulting and bank switching will slow down performance (but it is not that much slower than high speed bank switched assembler code; perhaps 5-10%). Second, you simply cannot perform a WORD or DWORD memory access that crosses a 64Kb bank boundary. Doing so causes an infinite page fault loop that will hang the machine. The infinite loop occurs because the CPU page faults on the second half of the memory access, which causes a bank switch to occur. Then the entire instruction is re-started and causes a memory access to the previous 64Kb bank which has now been mapped out. Another page fault occurs and the instruction is re-started again and we are back where we started. Hence it is vitally important that any virtual linear framebuffer rendering code ensure that all memory accesses are aligned to either a BYTE, WORD or DWORD boundary to avoid the infinite page fault loop. Using the VBE/AF Accelerator Functions The SuperVGA Kit provides transparent support for both VBE 2.0 and below devices, and VBE/AF Accelerator Functions. It will automatically use the VBE/AF graphics accelerator for clearing the framebuffer and drawing lines if the hardware supports that functionality in the current graphics mode (and you set the useVBEAF flag to true when the graphics mode was started). However the VBE/AF specification also provides support for a much larger array of primitives than just these two functions, such as patterned rectangle fills, polygon fills and transparent BitBlt functions. If a VBE/AF device has been detected and is currently being used by the library, the global variable AFDC will be set to a pointer to the VBE/AF device context block for the currently loaded driver. You can then use the supplied VBE/AF C based API in the VBEAF.H header file to directly call these functions, or you can use the sample assembler code in the _VBEAF.ASM module to write your own high performance accelerated graphics functions. Note that although we provide a C based API for VBE/AF acceleration in the SuperVGA Kit, the specification passes values to the driver in a combination of registers and parameter blocks that is highly tuned towards calls from tight assembly language loops. For absolute maximum performance in your code, please read the VBE/AF specifications and write your own assembler functions to interface directly with the VBE/AF device driver functions. In order to allow your acceleration code to run correctly, you must also observe a few rules to ensure correct arbitration between the graphics accelerator hardware and any code that renders directly to the framebuffer. By default when a mode is initialized, it is set up for hardware accelerated rendering and you cannot directly access the framebuffer. Before you do any direct framebuffer access, you must call the SV_beginDirectAccess function to ensure mutual exclusion to the framebuffer, and when you are done call SV_endDirectAccess again to return to normal hardware acceleration mode. If you do not do this, there is a chance that the data stored in the framebuffer will get corrupted, or even worse it is quite possible to lock up the graphics controller hardware requiring a hard reboot. Developing for Maximum Compatibility This section contains information relating to developing application software with maximum compatibility in mind, without sacrificing performance or features. Although the VBE standard defines how the specification should work, there are many different flavors of hardware out in the field. It is very important that you design your application with the following special cases in mind so that you application will run on the widest variety of hardware possible. Note that many of the issues in this section are only related to directly programming for the VBE 1.2/2.0 interfaces. If you are doing all your development with the native MGL API, SciTech MGL insulates you from many of these issues. However some issues such as being aware of the different types of hardware configurations that will be out there (such as hardware that cannot do page flipping) affect MGL applications as well. Check if VGA Compatible Before Touching Any VGA Registers Cards Affected: ATI Mach32 and Mach64 Diamond Viper series (Weitek P9000 and P9100) Diamond Edge 3D (NVidia NV1) IBM XGA IIT AGX Matrox Millenium Number Nine Imagine 128 Most newer cards Many developers find that there is an irresistible urge to push the boundaries of performance, and they will try anything and everything they can to attain these goals. One of the things that is commonly done is to perform weird and wonderful feats of magic using some of the standard VGA registers. This does work, and work well on some graphics cards, but not on all cards! If the graphics controller is based on a NonVGA graphics hardware technology (and many popular ones are), in the SuperVGA graphics modes the VGA registers simply do not exist anymore, and attempting to synch to these registers will put your code into an infinite loop. So be forewarned that doing any fiddling with the standard VGA registers is asking for trouble on certain graphics card that use NonVGA controllers to program the SuperVGA graphics modes (and lots more of these are coming out). There is however a solution for VBE 2.0 and VBE/AF controllers. There is a bit in the VBE modeInfoBlock for every graphics mode that indicates whether that mode is a NonVGA mode or VGA compatible mode. If this bit is set indicating that a NonVGA controller is being used to program the desired graphics mode, you must not do anything related to re-programming any of the standard VGA registers. In these cases you must fallback onto generic code that will perform all itТs graphics card interaction through the standard VBE 2.0 services. NOTE: The SciTech MGL API insulates developers from this issue. Check if VGA Compatible Before Directly Programming the DAC Cards Affected: ATI Mach32 and Mach64 Diamond Viper series (Weitek P9000 and P9100) Diamond Edge 3D (NVidia NV1) IBM XGA IIT AGX Matrox Millenium Number Nine Imagine 128 Most newer cards Another area of concern is programming the color palette. Once again the same problem occurs when programming the palette for NonVGA controllers; the VGA palette registers no longer exist and attempting to program the palette via these registers will simply do nothing. Even worse attempting to synch to the vertical or horizontal retrace will also cause the system to get into an infinite loop. Hence if you need to program the color palette, you should always try to use the supplied VBE 2.0 and VBE/AF palette programming routines rather than programming the palette directly. If you must have your own palette programming code, make sure you check the NonVGA attribute bit as discussed above, and if a NonVGA mode is detected you will have to program the palette via the standard VBE 2.0 or VBE/AF services. NOTE: The SciTech MGL API insulates developers from this issue. Handling Graphics Cards with Only Memory Mapped Registers Cards Affected: Alliance ProMotion 3210/6410 Number Nine Imagine 128 Some newer cards One area that is not very well covered in the VBE 2.0 specs is support for controllers that only have memory mapped registers rather than IO mapped registers. For these controllers there are a number of small issues that need to be handled in order to make sure that the 32 bit VBE 2.0 relocateable functions work correctly. If order for these functions to work, a selector to the memory mapped registers must be passed in the ES register to the bank switching and display start address programming routines, and in the DS register for the palette programming routine. If this selector is not passed, the code will not be able to correctly access the necessary memory mapped registers and your application will probably crash. Note that the UniVBE and our UVBELib device support libraries have some special case code that will work correctly if DOS4GW is used, but not with any other DOS extender. However you should make sure you code correctly handles these situations, as it may end up running on a different VBE implementation that does not have special case code for DOS4GW. Please look at the code in the SVGASDK.C and _SVGASDK.ASM source files in the SuperVGA Kit that perform this function (VBE20_setBankAES etc.). It is possible to handle these situations correctly without impacting the performance on controllers where this is not an issue. This is also an issue that needs to be solved now, because there are a number of new graphics controllers coming out that have only memory mapped registers. NOTE: The SciTech MGL API insulates developers from this issue. д╨/ер=жазаиайакл■       y*)*T*U*u*}* ++е,╢,e-v-9.F.Є/Ў/U0Y096G6<<<<=(=б@и@╛A┬AGGyGДGH%H&I.IаIмI▒I╗IN N▐NъN_OgOlOvOUPeP░S╢S╘T┌T┘WсWHYLYЧiЬi№mn▓t╖tєt u√√∙√ўўўўўўўўўўўўўўўўўўўўўўўўўўўўўўўЇЇЇЄuUБVБVБauDL╨1╘ь, 1 9 : A _ ` j Щ Ъ д ╓ ╫ ▀  K L X { | Ж ┼ ╞ ╙  + Z [ g Ц ■Р$~№Р$№Р$·Р$P№Р$№Р$·Р$P№Р$Ў ЎЕ тЕ ▐▐ЕтЕ▐▐ЕтЕ▐▐ЕтЕ▐▐ЕтЕ▐▐ЕтЕ▐▐ЕтЕ▐▐ЕтЕ▐▐ЕтЕ▐▐ЕтЕ▐▐Е╕l└з╗ ╛┼б ■(Ц Ч в ╞ ╟ ╙ ў °  м ╫ г#aНЮKїY|▐д╤я ="[":$∙&'Ф(Ф+╛.│/1D1c3`4{4╧5ы5В8ьЕшшЕьЕшшЕьЕцР$╪фР$тР$PфР$фР$фР$тР$PфР$ф Р$фР$фР$тР$PфР$фР$тР$PфР$фР$тР$PфР$ф Р$тР$PфР$ф Р$ф Р$фР$фР$тР$PфР$фР$тР$PфР$тР$PфР$╕l└з╗ ╛┼б ■(В8У;З=ж=д?`B|CЦCхEсJХO╖O∙PЭSоU{VвVуXЭZY\y_z_а_oacUcec{cйc╞c╬c╓cшcdddМe}gЧi╫ij#j9jgjДj■ Р$■Р$№Р$P■Р$■ Р$■Р$№Р$P■Р$■Р$■Р$№Р$P■Р$■Р$■Р$■Р$№Р$P■Р$■Р$■Р$■ Р$■Р$·■Р$■Р$№Р$P°Р$ ЎР$ЎР$ЎР$ЎР$ЎР$ЎР$ЎР$ЎР$ЎР$■Р$■Р$■Р$■Р$№Р$P°Р$ ЎР$ЎР$ЎР$,ДjМjФjжj╛j╧j╨j\l№m?■   єq  ХА$ _Toc348880559 _Toc355891174 _Toc370720259 _Toc355891175 _Toc370720260 _Toc355891176 _Toc370720261 _Toc355891177 _Toc370720262 _Toc355891178 _Toc370720263 _Toc370720264 _Toc370720265 _Toc355891179 _Toc370720266 _Toc355891180 _Toc370720267 _Toc355891181 _Toc370720268 _Toc355891182 _Toc370720269 _Toc355891183 _Toc370720270 _Toc355891184 _Toc370720271 _Toc355891185 _Toc370720272 _Toc348880560 _Toc355891186 _Toc370720273 _Toc348901750 _Toc355891219 _Toc371391084 _Toc348901751 _Toc355891220 _Toc371391085 _Toc348901752 _Toc355891221 _Toc371391086╘╘м м aaYYд=∙#∙#..`1`1╧2╧2З:З:|@|@ХLХL{S{S{S```╫f╫f╫f№j№jpїq? Rob Baham2\\SERVER\ADMIN\docs\MGL\Using the SuperVGA Kit.doc @HP LaserJet 4M Plus\\HP_Network_Printers\HPLASER4MHPPCL5MSHP LaserJet 4M PlusHP LaserJet 4M PlusФ@g XX@MSUDNHP LaserJet 4M Plusф;d HP LaserJet 4M PlusФ@g XX@MSUDNHP LaserJet 4M Plusф;d А}DРTimes New Roman РSymbol &РArialРBook Antiqua"1А╨hК· Жх3 f{ї] 0Г╚ !<Using the SuperVGA Kit Rob Baham Rob Baham  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFG■   ¤   L■   T■                               ■                                                                                                                                                                               Root Entry<"╘ь      └`         └FуGH ╚╗╟/v;╠╗KА,WordDocument  ╨Р$    ,:      └`    $ОCompObjX╝<x:`                  jxSummaryInformation╨Р$(        <xЪ╫╘■    ■    ■                                                                                                                                                                                                                                                                                                                                                                                                                                                                           ■       └FMicrosoft Word Document MSWordDocWord.Document.6Ї9▓q╨╧рб▒с■ рЕЯЄ∙OhлС+'│┘0дШа└╠рь°  , T ` l xДМФЬфUsing the SuperVGA Kit╛K Rob BahamJechar Normal.dot Rob BahamD4АMicrosoft Word for Windows 9DocumentSummaryInformationПР8            ХЦЧШЩ ша_906462884зийклмноп░            └F ▄ЇО7╠╗П7╠╗╛┐└_906462883╟╚╔╩╦╠═╬╧╨            └FП7╠╗р╫.П7╠╗▐▀р_906462882чшщъыьэюяЁ            └Fр╫.П7╠╗р╫.П7╠╗■ ■ ╒═╒Ь.УЧ+,∙о0╕HP`hp xА ИфSciTechм╚0 Using the SuperVGA Kit5E@МЖG@@Мь║V╟╗@v╒g;╠╗ {ї]╨╧рб▒с>■  ■ ╒═╒Ь.УЧ+,∙о0╕HP`hp xА ИфSciTechм╚0 Using the SuperVGA Kit╨╧рб▒с