 
   This is a test EFI build of QSINIT.
   It CANNOT boot OS/2 (use ArcaOS or see below :))
   But it works and still the same 32-bit runtime, running in 64-bit EFI.

   Put QSINIT.EFI and QSINIT.LDI to the /EFI/BOOT directory on EFI
boot partition and launch QSINIT from EFI shell.

   You can also rename QSINIT.EFI to BOOTX64.EFI (OS loader default name)
(on a clean disk or USB stick).

   Another way is creation of a GPT formatted USB stick (can be done in BIOS
version). Then set partition type to "EFI Bootable", format it to FAT/FAT32
and copy both files to the /EFI/BOOT directory.

   This will be a nice test drive (EFI BIOS should detect it and show in the
list of boot sources as "UEFI:device_name" or something like that).

   Some UEFI firmwares can detect /EFI/BOOT even on active MBR partition.

   QSINIT apps are binary compatible between BIOS and UEFI versions.

   And (YES!!) - now you can play tetris in EFI! :)

  -- = * Troubleshooting * = --------------------------------------------

  1. By default - QSINIT switches system to graphic mode with own console
     emulation. If something wrong - create /EFI/BOOT/QSSETUP.CMD with
     string:

        SET VESA = ON, NOFB

     to use EFI drawing code or just 

        SET VESA = OFF

     to disable own graphics console at all and use EFI`s one.

     F10 in the menu will reset mode to the default UEFI console (also for the
     case where incorrect graphics mode information causes screen distortion).

   2. By default - QSINIT calls VMTRR to enable write combining, else virtual
      console (both QSINIT and native EFI /EFI has no REAL text mode/) is VERY
      slow.

      If EFI console with VMTRR is slower, than without - just reset MTRR from
      QSINIT menu and send me a log (it can be saved to any FAT32 partition
      via "log save" command).

   3. To exit back to EFI shell without reboot - exit by ESC from menu to
      the first copy of CMD.EXE, then type "exit".

   4. QSINIT "safe mode" can be activated by /SM key from EFI shell.
      I.e. launch "QSINIT /SM"

   5. PCI COM ports address space may be disabled in UEFI, so DBPORT option
      can be void, try to use DBCARD instead.

   6. Though UEFI system volume is FAT or FAT32, it is unaccessible for
      write access from QSINIT. The reason is a danger of simultaneous access
      from the UEFI firmware and QSINIT. "BOOTMOUNT = RW" INI file option or
      /BM+ command line key will force the system volume to be writable, BUT
      remember that this can certainly damage the FAT/FAT32 structures in it.

   7. National language characters are not allowed in the UEFI executable path
      (the default is \EFI\BOOT, but this can also be altered, so just take
      this in mind).

===========================================================================

  -- = * Boot OS/2 * = --------------------------------------------------

   Since the ArcaOS UEFI loader is based on QSINIT from Dec 2018, QSINIT can
be slightly modified to run the BIOS emulation layer from it ;)

   Remember that this is still a raw experimental functionality, and nothing
is guaranteed. And the current version does not have the code for EFI variable
access.

   You need to take these files from OS2LDR.BIN (ZIP archive) of ArcaOS loader
and pack them to the same path in QSINIT.LDI (also a ZIP archive):

      bootrm.exe
      bootrm.ini
      os2boot\os2dbcs
      os2boot\os2boot
      dll\pci.dll
      msg\FONT.F16
      msg\FONT.F08

   Before packing make some changes to bootrm.ini:
      - add the following line in [config] section:
           fixcfg = fixcfg b:\temp\config.sys -vga
      - remove this line in [_setup] section:
           call cfgproc.cmd

   Any other module from the ArcaOS loader (like CSMVIEW or BOOTOS2) will most
likely trap QSINIT due to markable differences at the binary level between the
loaders.

   If you have a BOOTRM.EXE file in QSINIT.LDI, the boot menu will show a line
"Boot with BIOS emulation", try it ;) (expect it to ask you for the volume with
OS/2 installed).

   This works in both BIOS and UEFI mode. In BIOS mode, this emulation will
replace the original BIOS, which can be useful in some cases.

   Remember that you need OS2\MDOS\VEFI.SYS and OS2\DLL\BVHEFI.DLL even
in BIOS boot via this emulation! It`s because these modules are not actually
designed for UEFI boot, but for full video virtualization.

   The diffences in CONFIG.SYS are:
      VESA boot:
         DEVICE=C:\OS2\MDOS\VSVGA.SYS
         SET VIO_SVGA=DEVICE(BVHVGA,BVHSVGA)
      
      Virtualized video boot:
         DEVICE=C:\OS2\MDOS\VEFI.SYS
         SET VIO_SVGA=DEVICE(BVHEFI)

   This "virtualized video" boot is possible not only in UEFI, but in BIOS mode
too. So, there are 4 possible modes:
   UEFI:
      * emulated video
         This is normal EFI boot mode.
         Fullscreen console is a graphical console.
         VDM video is virtualized via VEFI.SYS.
         No mode switching at all.

      * VESA BIOS
         This only works with PCs that can boot Win7 in UEFI mode. Win7
         expects a VESA BIOS, so many PCs end up with a chaotic situation
         where the PC BIOS is missing and BIOS data is garbage, but the
         video BIOS data is valid and fully initialized.
         
         Well, the magical BOOTRM.EXE handles such situations as best it can.
         So try via menu or "BOOTRM.EXE -ob" and see the result ...

         This has both good and bad sides - you will have normal mode
         switching, but you will lose the VDM stability that fully virtualized
         video provides in the mode described above.

   BIOS:
      * emulated video
         This is useful for some combinations of BIOS PC and a new video card
         that has broken VGA.               

         It looks the same as in UEFI - you set the screen mode in the loader,
         and then work in a fully virtualized fullscreen console and VDM.

      * VESA BIOS
         This is almost a normal BIOS boot, with one exception - the BIOS
         is replaced with an emulated one.

         This still can be useful. For example, any VDM startup on one of my
         PCs hangs just in the BIOS code (segment F000) and such a boot (which
         replaces this BIOS) allows using VDM at all.

   Note that you do NOT need to edit CONFIG.SYS to switch between VESA and
virtualized video boot. The kernel copy of CONFIG.SYS will be automatically
updated for both SET VIO_SVGA and VSVGA/VEFI lines.

   This also means that this loader can be used to boot a BIOS-based system
in EFI mode and an EFI-based system in BIOS mode WITHOUT editing CONFIG.SYS
(just make sure that the BIOS-based system has VEFI.SYS and BVHEFI.DLL files
in the right places).


   Also note that you need a different way to set up the default boot volume.
The volume letter or GUID must be used with the "/@defvolume=..." parameter,
example for launcher.cfg:
     QS v1 = \EFI\BOOT\QSINIT.EFI /@defvolume=C:
     QS v2 = \EFI\BOOT\QSINIT.EFI /@defvolume=5efa1149-a61b-47b5-45ae-b68740d5f1d3

   You can see that the DEFVOLUME shell variable in QSINIT defines the default
boot volume, just like in the ArcaOS loader. This can be used in any batch files
inspired by your imagination ;)

   About supported options:
   * ALT_VIDEO must be placed in \EFI\BOOT\OS2LDR.CFG, \EFI\OS2\OS2LDR.CFG
     will never be found by QSINIT (or just place QSINIT itlsef in \EFI\OS2)

     Not sure if this key is documented somewhere, just comment it out
     for the emulated video boot and set to 1 or 3 to try VESA BIOS mode.

   * LOGOMODE better to be placed in the target`s volume OS2LDR.CFG

   * RAMDISK options work as in QSINIT - i.e., qssetup.cmd has a priority
     over OS2LDR.CFG

   Why is this necessary at all (except for the cases described above):

   * QSINIT has some features that are missing in ArcaOS loader - like QC,
     unicode file API, JFS format, exFAT and ISOFS support, ISO/VHD image
     mounting, arithmetic expressions in IF and SET, etc. This can be useful
     for some boot time scripting, error fixing and/or emergency backups.

   * You can try to boot OS/4 kernel ;)
     This WILL NOT work now (probably except in VESA mode) - until the OS/4
     team removes their own OEMHLP driver. Anyway, this is for you to test,
     since any new revisions of this wonderful kernel hang on *ALL* my test
     PCs. I can`t even verify that it works with QSINIT at all.

   * ArcaOS loader is stricted to be solid and easily supported. But this
     BIOS emulation layer supports wider customization for various (strange
     or rare) needs. You can do it here ;)

   * another feature (provided by OS2BOOT\OS2BOOT from the ArcaOS loader
     we packed above) is the ability to edit the boot copy of CONFIG.SYS
     for ANY kernel and in ANY boot type (not only the BIOS emulation above!).
     
     Just press Alt-E in the kernel selection menu and it will open CONFIG.SYS
     in the SysView editor in QSINIT just before the kernel is started (since
     a text editor is definitely missing in IBM kernels ;)). This OS2BOOT will
     then be used to send the edited CONFIG.SYS to the kernel.

     Note that works only for HPFS and JFS boot partititons.


   p.s. you can do some funny things, based on knowledge about Dec 2018. Get
the QSINIT version from this time (like QS\Archive\QS_LDR_474.ZIP on ftp),
take TETRIS.EXE from it and type AOSLDR over the second QSINIT string in it
in any binary editor. Then pack it in OS2LDR.BIN and add its launch to
BOOTMENU.INI. Voila - you have Tetris in your ArcaOS loader ;)

  -- = * GPT notes * = --------------------------------------------------

   The first thing about GPT is that you *CAN* boot OS/2 in BIOS mode from
a GPT disk. Even the BIOS hosted version of the Arca OS loader can boot from
a GPT disk, despite the fact that the GPT handling code has been removed from
it.

   The only thing you need is to update the partition boot code from the old
one written when formatting HPFS to the one provided by QSINIT. By the way,
you will lose the ability to boot OS/2 1.x kernels (yes, the original HPFS
boot code has special support for that, so no OS/2 1.x on GPT ;)).

   JFS boot code should work as is.

   Then any HPFS/JFS partition can be just added to any loader (e.g. GRUB
chainloader+1) or booted using the boot code of a GPT disk (it still has the
same MBR with real mode boot code as a MBR disk). But in this case you also
need to update that code.

   Open SysView, go to the "Disk Management" and select "Replace MBR code" for
this disk. You can also update HPFS boot code here - select the partition and
"Update bootstrap" in the action list for it (but *NEVER* do this for JFS, you
can read the reason in the "Update bootstrap" dialog help).

   Another thing you can do in the "Disk Management" is changing a drive letter
for GPT partitions with Arca OS GUID (select "LVM drive letter" in partition
actions).
