• Please review our updated Terms and Rules here

Dumping ROM chips with DEBUG.EXE

M

Malvineous

Experienced Member
Joined
Jun 18, 2010
Messages
119
Location
Brisbane, Australia
Hi all,

To save removing the ROM chips from my 286 board and dumping them in an external device, it seems like an easy option is (or was, until I tried it) to just use DEBUG.EXE to write the ROM data to a file.

Unfortunately when I try this, it either drops every second byte, or the machine locks completely!

I am doing this:

Code: 
n BIOS.BIN  ; Write to a file called BIOS.BIN
rbx
1           ; Write 0x10000 bytes (64kB) - upper 16-bits
rcx
0           ; Lower 16-bits
w F000:0    ; Write now, starting from F000:0000

When I do this, the machine locks up almost immediately and I end up with a zero-byte file. Dumping the memory to the screen with the "d" command works fine. Writing less data (a few hundred bytes) also locks the machine up. I tried it with ROM BIOS shadow on and off with no difference.

If I try to dump the video ROM instead, by changing the address to C000:0 then the system doesn't lock up, but every second byte is 0x00 in the resulting file! Again, using "d" to dump the memory to the screen shows it all looks fine.

Is there some trick to correctly setting up DEBUG's "w" command?
 
Of course now I post about it I find a workaround, but I'm still interested in any explanations for the behaviour I've seen!

The workaround is to copy the data into conventional memory and dump it from there:

Code: 
m F000:0 FFFF 1000:0  ; Copy 0xFFFF bytes from F000:0000 to 1000:0000
rbx
1                     ; Write 0x10000 bytes (64kB) - upper 16-bits
rcx
0                     ; Lower 16-bits
w 1000:0              ; Write copied data to file, starting from 1000:0000

Copying the data to memory segment 1000 is "probably" safe - at least nothing was using that memory on my machine at the time. You can't use DS:0000 for this because DEBUG puts the filename you set with "n" here, so the first few bytes of the dump will be lost if you do.

Doing this I was successfully able to dump both the system ROM and the video BIOS ROM without problems.
 
Yes, the procedure will work on any machine that can run DEBUG, but it can only dump ROM chips that appear in the PC's address space. Since the BIOS ROM is always mapped to segment F000, that one is easy to dump and will work on pretty much any machine.

I also put in a network card with a boot ROM on it, however I had to find the card's configuration utility and enable the ROM socket before it appeared in the PC's memory space. Once I'd done that I could dump it with DEBUG easily enough - I configured the card to place the ROM in segment C800, so dumping from C800:0000 got me the content. I didn't have to use the "m" command to copy the memory in that case, it happily wrote the data straight from the ROM segment.

Since BIOS ROMs and network boot ROMs are generally electrically compatible, having a network card with an active boot ROM socket can be a nice easy way to dump a wide variety of (E)EPROMs.

Keep in mind that often, and in the case of my 286 motherboard, there are two ROM chips, a "hi" and "lo" one. The data alternates between chips, so bytes 0, 2, 4, 6, etc. are in one chip, and bytes 1, 3, 5, 7, etc. are in the other, a bit like a RAID0 array. So when you dump with DEBUG you get the complete image with bytes 0, 1, 2, 3, etc. suitable for use with emulators, disassemblers, etc. but should you ever have to burn it back onto two separate chips, you'll have to split the file back into the hi+lo/odd+even parts.
 
Thank you for that fantastic explanation! This is something I've always wanted to try, I am not familiar with assembly or the debug command at all but your explanation is excellent and easy to visualize. Much appreciated!
 
This doesn't apply to 286s, but keep in mind that later BIOSes (e.g. Award Modular BIOS) are actually compressed on the chip and what ends up in F000 is not the whole BIOS.
 
Malvineous said:
m F000:0 FFFF 1000:0 ; Copy 0xFFFF bytes from F000:0000 to 1000:0000
[/code]
Click to expand...

0xFFFF = 65535, not 65536. You won't have the last byte of the BIOS.

Dump 8000h twice:

r cx
8000
m f000:0 8000 100 (sic!)
n bios1.rom
w 100
m f800:0 8000 100
n bios2.rom
w 100
 
Gabucino said:
0xFFFF = 65535, not 65536. You won't have the last byte of the BIOS.
Click to expand...

It's actually a "range", not a length, so think of it more as the address of the last byte that gets copied. "m F000:0 FFFF" will copy from F000:0000 to F000:FFFF, *including* both those bytes, so 65536 bytes all up. You definitely get the last byte!
 
I've used a program called GetRom that saves the ROM contents from a PC, XT or AT to file(s). You just run it and it's done. Easiest dump in town.
 
Plasma said:
This doesn't apply to 286s, but keep in mind that later BIOSes (e.g. Award Modular BIOS) are actually compressed on the chip and what ends up in F000 is not the whole BIOS.
Click to expand...

I happened to end up dumping an Award 4.51PG chip from a 486 a little later on, and you're right. The chip starts with an LHA archive, and when you expand that, it contains a file (called "original.tmp" in my case, weirdly) with the standard 64k image seen at F000:0000.

So how does the boot process work in this case? Does something different appear at the end of segment F000 at poweron, the CPU starts executing that, and the as part of that process the LHA archive gets expanded into shadow RAM, located at F000:0000? That's kind of an interesting solution to fitting more data onto the flash chip while retaining backward compatibility.
 
Malvineous said:
It's actually a "range", not a length, so think of it more as the address of the last byte that gets copied. "m F000:0 FFFF" will copy from F000:0000 to F000:FFFF, *including* both those bytes, so 65536 bytes all up. You definitely get the last byte!
Click to expand...

You're right. I mixed it up with CX containing FFFF.
 
So how I can dump my IBM XT 286 ROM chips into two files correctly? I think this has not become clear to me.

(Using DEBUG, of course)

(With this?:

r cx
8000
m f000:0 8000 100
n bios1.rom
w 100
m f800:0 8000 100
n bios2.rom
w 100)

Thanks in advance.
 
You must log in or register to reply here.
Back
Top