Removing the Mystery from SEGMENT : OFFSET Addressing

Things to do:

1. Get freeLDR compiling and working with OW
2. Find out how much room I have between 0001:0000 and the start of microFSD.
3. Disassemble os2boot – how does it load os2ldr? Can I have more segments?
4. Could a new loader be compiled like a device driver (dll)?

To reduce effort:
1. Use free source from linux
2. Not code for FAT boot
3. No RIPL source
4. i686 (and compatable) and newer – 586 and older are out of luck

0x00000000 – 0x000003FF : Real mode interrupt vector table
0x00000400 – 0x000004FF : BIOS data area
0x00000500 – 0x00007BFF : Unused
0x00007C00 – 0x00007DFF : Floppy boot sector is loaded in here
0x00007E00 – 0x0009FFFF : Unused
0x000A0000 – 0x000BFFFF : Video RAM video memory
0x000B0000 – 0x000B7777 : Monochrome video memory (multiple pages)
0x000B8000 – 0x000BFFFF : Color video memory (multiple pages)
0x000C0000 – 0x000C7FFF : Video ROM video BIOS
0x000C8000 – 0x000EFFFF : BIOS shadow area
0x000F0000 – 0x000FFFFF : System BIOS

http://en.wikipedia.org/wiki/BIOS_interrupt_call

http://mirror.href.com/thestarman/asm/index.html
http://www.osdev.org/osfaq2/index.php/InterruptsForDummies

http://my.execpc.com/CE/AC/geezer/osd/boot/

http://bioscentral.com/
http://perso.orange.fr/pierrelib/handbooks/

http://my.execpc.com/~geezer/osd/ram/index.htm#layout

I don’t remember where I found the following stuff:

OS/2 does care about the CPU (definitely) and the MB (to a lesser degree).

a) The OS2LDR contains code to detect the CPU type rather precisely, and the OS2KRNL has some critical code in multiple versions for 386, 486 and P5 versions (such as copy routines).

b) OS2LDR apparently has to switch the CPU into protected mode, and therefore must enable the A20 line. Like himem.sys (R.I.P.), the loader appears to use different methods for switching, corresponding to the mess with the A20 gate in former MB versions. OS2LDR also identifies the amount of memory available, and does this by trying out several BIOS interrupts. The function “enable OS/2 RAM >16MB” which is present in several BIOS versions is a clear sign that OS/2 uses certain computer-specific properties.

IBMINT13.I13 is a proof that even a running OS/2 may, under certain circumstances use BIOS features.

GENGRADD is a proof that OS/2 still uses the Video VESA BIOS to switch certain “reluctant” video cards into graphics mode (this does not mean that all GRADD graphics is done through the BIOS).

The first boot disk contains several BIOS replacement versions to work around bugs in old PS/2 BIOS code. But this is IMK only to get the system installed, because the installation uses much more BIOS services than the later running system (the running system has already a boot loader and a working mini-FSD on disk which will pretty fast take over control), so basically the only relevant services needed are INT13 services to get the whole IPL done.

OK, >2gb dumps. First of all, with exactly 2gb installed, you can probably
use the standard stuff, since
most systems take some memory off the top for shadowing. That said, I just
uploaded dumpfs.zip to testcase.

Summary:

• • put udumpfs.* in \os2\dll, dumpfs.* in \os2\boot, and replace

\os2dump with \os2dump.hd

• • Add IFS=DUMPFS.IFS to config.sys.
  • Create a partition with LVM or whatever. LVM is such a terrible

utility that the best I can suggest is use

from boot manager (if installed).

size.

• • Format x: /fs:dumpfs (x: is whatever)
  • add TRAPDUMP=X:,R0 (or whatever) to point the dump at the right

drive.
That ought to do it. Note that I was too lazy to add EA support to the IFS,
so the workplace shell gets upset if you try to
look at the drive with a drives object. Use a command prompt or PMDF or
whatever to get to the dump.

This is beta (at best) software. I am almost certain that there is still a problem with dumpfs trapping with some configuration of partitions. I will listen to sensible and not too time-consuming suggestions and will accept bug reports (though I make no particular guarantee about response time).

• • Scott