• Please review our updated Terms and Rules here

How can I dump ROM code mapped in the last 16 Mb of a 286?

N

nestor

Veteran Member
Joined
Jul 23, 2010
Messages
509
Location
Spain
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...
 
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?
 
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.
 
Not sure if any of [url="http://www.vintage-computer.com/vcforum/showthread.php?11310-how-to-dump-BIOS-to-a-file]these tools[/url] would do what you're looking for.
 
barythrin said:
Not sure if any of 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.
Click to expand...

Thanks Chuck. I think 80286 and 80386SX both look for the ROm in the same physical address, as they share the same physical space.
 
You'd better consult the chipset datasheet because the chipset is capable of remapping the address space in your case.
 
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.
 
george said:
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. .
Click to expand...

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?
 
Chuck(G) said:
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?
Click to expand...

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 ;)
 
george said:
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 ;)
Click to expand...

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?
 
Chuck(G) said:
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?
Click to expand...

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:
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.
 

Attachments

Why don't you disable the NMI via bit 7 of port 70h in order to avoid parity errors?
 
george said:
... Do it and then claim it is not trivial ;)
Click to expand...
Umm, I think you're the one claiming it's not trivial...
I hate when people speak about things they've never done themselves.
Click to expand...
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:
MikeS said:
Umm, I think you're the one claiming it's 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.
Click to expand...
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. ;)
 
george said:
Why don't you disable the NMI via bit 7 of port 70h in order to avoid parity errors?
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top