Additions:
I don't remember where I found the following stuff:
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.
- put udumpfs.* in \os2\dll, dumpfs.* in \os2\boot, and replace
- Add IFS=DUMPFS.IFS to config.sys.
- Create a partition with LVM or whatever. LVM is such a terrible
"create a partition that can be made bootable" and then delete it
Make sure the partition is at least as large as your phyiscal RAM
- Format x: /fs:dumpfs (x: is whatever)
- add TRAPDUMP=X:,R0 (or whatever) to point the dump at the right
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
Deletions:
ad 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).
ad 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.
- put udumpfs.* in \os2\dll, dumpfs.* in \os2\boot, and replace
- Add IFS=DUMPFS.IFS to config.sys.
- Create a partition with LVM or whatever. LVM is such a terrible
"create a partition that can be made bootable" and then delete it
Make sure the partition is at least as large as your phyiscal RAM
- Format x: /fs:dumpfs (x: is whatever)
- add TRAPDUMP=X:,R0 (or whatever) to point the dump at the right
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
Additions:
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
"create a partition that can be made bootable" and then delete it
from boot manager (if installed).
Make sure the partition is at least as large as your phyiscal RAM
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
Additions:
To reduce effort:
Additions:
4. i686 (and compatable) and newer - 586 and older are out of luck
Additions:
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
OS/2 does care about the CPU (definitely) and the MB (to a lesser degree).
ad 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).
ad 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.
Additions:
1. Use free source from linux
2. Not code for FAT boot
3. No RIPL source
Additions:
4. Could a new loader be compiled like a device driver (dll)?
Additions:
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?
