{"id":807,"date":"2020-12-06T18:13:00","date_gmt":"2020-12-06T18:13:00","guid":{"rendered":"https:\/\/www.ecsdump.net\/?page_id=807"},"modified":"2020-12-06T18:13:00","modified_gmt":"2020-12-06T18:13:00","slug":"miscldrnotes2","status":"publish","type":"page","link":"https:\/\/www.ecsdump.net\/?page_id=807","title":{"rendered":"MiscLdrNotes2"},"content":{"rendered":"

Removing the Mystery from SEGMENT : OFFSET Addressing<\/a><\/p>\n

Things to do:<\/p>\n

1. Get freeLDR compiling and working with OW
\n2. Find out how much room I have between 0001:0000 and the start of microFSD.
\n3. Disassemble os2boot \u2013 how does it load os2ldr? Can I have more segments?
\n4. Could a new loader be compiled like a device driver (dll)?<\/p>\n

To reduce effort:
\n1. Use free source from linux
\n2. Not code for FAT boot
\n3. No RIPL source
\n4. i686 (and compatable) and newer \u2013 586 and older are out of luck<\/p>\n

0x00000000 \u2013 0x000003FF : Real mode interrupt vector table
\n0x00000400 \u2013 0x000004FF : BIOS data area
\n0x00000500 \u2013 0x00007BFF : Unused
\n0x00007C00 \u2013 0x00007DFF : Floppy boot sector is loaded in here
\n0x00007E00 \u2013 0x0009FFFF : Unused
\n0x000A0000 \u2013 0x000BFFFF : Video RAM video memory
\n0x000B0000 \u2013 0x000B7777 : Monochrome video memory (multiple pages)
\n0x000B8000 \u2013 0x000BFFFF : Color video memory (multiple pages)
\n0x000C0000 \u2013 0x000C7FFF : Video ROM video BIOS
\n0x000C8000 \u2013 0x000EFFFF : BIOS shadow area
\n0x000F0000 \u2013 0x000FFFFF : System BIOS<\/p>\n

http:\/\/en.wikipedia.org\/wiki\/BIOS_interrupt_call<\/a><\/p>\n

http:\/\/mirror.href.com\/thestarman\/asm\/index.html<\/a>
\nhttp:\/\/www.osdev.org\/osfaq2\/index.php\/InterruptsForDummies<\/a><\/p>\n

http:\/\/my.execpc.com\/CE\/AC\/geezer\/osd\/boot\/<\/a><\/p>\n

http:\/\/bioscentral.com\/<\/a>
\nhttp:\/\/perso.orange.fr\/pierrelib\/handbooks\/<\/a><\/p>\n

http:\/\/my.execpc.com\/~geezer\/osd\/ram\/index.htm#layout<\/a><\/p>\n

I don\u2019t remember where I found the following stuff:<\/p>\n

OS\/2 does care about the CPU (definitely) and the MB (to a lesser degree).<\/p>\n

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).<\/p>\n

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 \u201cenable OS\/2 RAM >16MB\u201d which is present in several BIOS versions is a clear sign that OS\/2 uses certain computer-specific properties.<\/p>\n

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

GENGRADD is a proof that OS\/2 still uses the Video VESA BIOS to switch certain \u201creluctant\u201d video cards into graphics mode (this does not mean that all GRADD graphics is done through the BIOS).<\/p>\n

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.<\/p>\n

OK, >2gb dumps. First of all, with exactly 2gb installed, you can probably
\nuse the standard stuff, since
\nmost systems take some memory off the top for shadowing. That said, I just
\nuploaded dumpfs.zip to testcase.<\/p>\n

Summary:<\/p>\n