The IBM PS/1 model 2011 has 4 EPROM chips in the motherboard (1 Megabit each) that contains the sytem BIOS, the VGA BIOS and a ROMDISK with PC-DOS 4.0 boot files. The system BIOS and the VGA bios are mapped in E000-FFFF but the other 128 KB seems to be mapped at the end of the 16 Mb addressable space. How can I dump that 128 kb? With debug I can only access to the first megabyte...
-
Please review our updated Terms and Rules here
How can I dump ROM code mapped in the last 16 Mb of a 286?
- Thread starter nestor
- Start date
Chuck(G)
25k Member
I've seen utilities for 386 and above, but not 286, so you may have to roll your own using INT 15H, Function 87H to perform a block move of the BIOS image to lower memory.
I think I don't have enough knowledge in DOS programming to do it by myself. If there is a program that allow to do it in a 386, I can test it in the PS/1 2121 that have a similar ROM layout and is a 386sx based machine.
Do you remember what utility works in a 386?
Do you remember what utility works in a 386?
Chuck(G)
25k Member
I can look in my files, but I seem to recall that the 386 puts the ROM in a different physical address. Maybe I can whip something up for you in the meantime.
Thanks Chuck. I think 80286 and 80386SX both look for the ROm in the same physical address, as they share the same physical space.
There is no information about the chipset, it is a mix of custom IBM and VLSI chips...
Here (Figure 2) is where I read where is mapped the ROM disk
Here (Figure 2) is where I read where is mapped the ROM disk
Well, according to this patent they are using int 15h/87h themselves to access that memory space. It is not a trivial task and requires a lot of (obsolete) low level programming skills. I personally wouldn't do it for fun. But I do confirm that on a 386 CPU it is much easier to read that memory. If you don't need a program that does specifically that task on a 386 you might consider using an old 32-bit os or even dos extender with a corresponding debugger. Anyway if you are ignorant in x86 assembly language you'd better use an EPROM programmer to read the ROM directly.
Chuck(G)
25k Member
Say what? Since when is assembly programming obsolete? It's actually very simple--just put together a couple of GDTs, call INT 15h/87h to do the move and you have your data. I'm certain that the job could be accomplished in C as well, using the <dos.h> library functions.
Is the modern approach to computer science now all Java, Scheme and Python? Does no one who doesn't remember where he was when JFK was assassinated think that learning a machine's instruction set and internal operation is important?
It is trivial--what will you wager that I can't do it in 100 lines of C code?
GDT is only one - that's why it is global. Do it and then claim it is not trivial
I hate when people speak about things they've never done themselves. BTW:that BIOS of PS/1 should have a ready made subroutines that do the job
Chuck(G)
25k Member
GDT is only one - that's why it is global. Do it and then claim it is not trivial
Back in 1988, I wrote an EMS emulator (used XMS to provide a simulation of EMS 4.0) and marketed it. I know what a GDT is and what it looks like. I say it is trivial. It was much more trivial than writing routines to manage handles and allocation.
And what's this stuff about "obsolete" skills?
What was the name of this EMS emulator or was it an EMS driver for a certain chipset with mapping capabilities? For 386 I remember only QEMM386, 386MAX and EMM386. In creating of which of these were you participating in? I said obsolete skills since nobody needs such skills nowadays. Back in 1988 I had only JUKO XT so I wrote almost LIM EMS 3.2 emulator for it (no mapping support in hardware). Let me remind you that at the time BIOSes were very buggy for 15h/87h and had differences between 286/386 implementations. I might be wrong but XMS drivers also provided their own replacement of these services.
Last edited:
Chuck(G)
25k Member
There was at least a C&T chipset could provide EMS emulation (with a driver of course). The problem with using INT 15/87 calls is that unless the BIOS uses the 286 version of LOADALL, interrupts stay off for the entire transfer, potentially meaning lost timer ticks, COM interrupts, etc. Most 286 systems go through the insane write-cause-in-CMOS-then-go-through-a-full-system-reset sequence, which takes a comparatively long time. 386 of course, doesn't have the problem.
At any rate, here's something (source and executable) that dumps the last 128K of a 16M memory space. It works on my 286; it'll fail on 386+ boxes with less than 16M of memory because there's nothing at the dump location--you'll err out with an 01 error (memory parity error).
I compiled using 16-bit Microsoft C (8.00d) and libraries. If you use a different compiler, you may need to tweak the code a bit.
At any rate, here's something (source and executable) that dumps the last 128K of a 16M memory space. It works on my 286; it'll fail on 386+ boxes with less than 16M of memory because there's nothing at the dump location--you'll err out with an 01 error (memory parity error).
I compiled using 16-bit Microsoft C (8.00d) and libraries. If you use a different compiler, you may need to tweak the code a bit.
MikeS
Veteran Member
Umm, I think you're the one claiming it's not trivial...... Do it and then claim it is not trivial
Well then, since you started this by claiming it is not trivial then presumably you have done it yourself already, so why not post your code and share it with the rest of us.
Last edited:
I would gladly do this but not for free. I would customize one for you! But I don't think you're interested in it since you haven't downloaded the ChuckG's code.
MikeS
Veteran Member
I kinda figured you wouldn't get it... ;-)I would gladly do this but not for free. I would customize one for you! But I don't think you're interested in it since you haven't downloaded the ChuckG's code.
Cheap provocation. It wouldn't work for me
Chuck(G)
25k Member
It won't matter; the BIOS code checks for parity error status on port 61h; it does not rely on NMI, even though the documentation says otherwise. (cf. 5170 BIOS code in module BIOS1).
Another way to attack the issue is to use the 80286 LOADALL. Probably now better documented than the INT 15 services.