Using DEBUG to get BIOS?

[leeb]

Has anyone been able to use DEBUG to get the BIOS of their system?

I have successfully found the BIOS and have seen the drive table (at F000:D817-or-such) but being able to save it is foreign to this CP/M user...

 

[Chuck(G)]

Absolutely. Here's how you do it.

First of all, determine the segment address of where your BIOS starts. In the 5150, it's FE00.
Next, figure out how long (hex) your BIOS is in bytes. In the case of the 5150 BIOS, it's 8K, or 2000 hex.
Finally, you need a name for the file you want to put it in. Let's call this MYBIOS.BIN

In the following, the stuff put out by DEBUG will be in normal font and your entries will be in boldface. Narration will be in italics.

First, start DEBUG; it will respond with a hyphen prompt. You tell it name of your file:]/i]

C>DEBUG
-NMYBIOS.BIN

Tell it how many bytes will be in the file. This involves putting the count in the CX register. You tell DEBUG which register you want to modify; it responds with the contents and a colon prompt. You give it a new value, the length of your BIOS:[/i[]

-RCX
CX 0000
: 2000

Then, you copy your BIOS into RAM (some versions of DOS have problems writing from the end memory, so it's best to copy the BIOS to location 100 in your TPA. You have to give the DEBUG move command the destination, the length and the source address (your BIOS segment address):

-M100 L2000 FE00:0
Then, you tell DEBUG to write the file out

-W
Writing 02000 bytes

Finally, you quit DEBUG and you're back to DOS.
-Q
C>

That's all you need to know!

 

[modem7]

An earlier related thread:
http://www.vintage-computer.com/vcforum/archive/index.php/t-4784.html

 

[leeb]

An earlier related thread:
http://www.vintage-computer.com/vcforum/archive/index.php/t-4784.html

My apologies... I usually search first but I was brainless in this instance...

So presuming the bios is 64K (as I undertand it is) I would leave CX at 0000? It makes sense to me but sometimes 'my logic is uncertain'...
On the move function.. If I set it to 0100 is it going to copy ALL FFFF+1 bytes or will it wrap? (Perhaps it too was in the other thread, but I am heading out soon for a PET scan and I wanted to ask anyway. Silly me!)

I DO appreciate the info! I want to attempt a modification of the drive table to accept larger (and newer!) drives... and this is the first step!

Thanks again!
Edit: I suppose I could copy only the 1st half (F000:0000 -> F000:7FFF) into one file and then the 2nd half (F000:8000 -> F000:FFFF) to another... could do this in CP/M in my sleep but with DOS Im such a NOOB...

Edit 2: Well, it did in fact address this issue and I will likely be doing the 32k 'chunk and splice' since it also told me how to put them back together (tho COPY itself would have done that)!

RANT1: Im beginning to HATE this touchpad's scroll bar! When I hit it while typing/editing it kicks me out of the edit/reply area and I have to hope I can get back to it without retyping everything!! (like I had to do this time! ) I have to turn the touchpad OFF and then turn it back ON!!! /RANT
:mrgreen:

 

[Chuck(G)]

If you have more that FFFF bytes to write, then BX holds the upper 16 bits of the count. The move function will move only up to FFFF bytes at a time, so you'll have to do 2 moves to do it--and do a little arithmetic. So for example, to move from F000:0 to DS:100 for 64K bytes you'd use:

The first step is to see what your DS register is. You do this by typing:

-R

And you'll get a complete register display that looks something like this:

AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=13BC ES=13BC SS=13BC CS=13BC IP=0100 NV UP EI PL NZ NA PO NC
13BC:0100 0000 ADD [BX+SI],AL DS:0000=CD

Note that this says that my DS is 13BC. So now I do the first part of the move to 13BC:0100:

-M13BC:0100 L8000 F000:0

And then, I do the second part of the move by adding 0800 (32K) to both segment addresses. If you're not handy with hexadecimal numbers, DEBUG has an "H" command that will give you the sum and difference of two 16 bit numbers:

-H13BC 0800
1BBC 08BC

So, I now know that my new target address of 32K past 13BC:0100 is 1BBC:0100. Now I can do my move:

-M1BBC:0100 L8000 F800:0

64K is 10000 hex, so I need to set BX to 0001 and leave CX at its current value, 0000:

-RBX
BX 0000
:0001

Everything's all set up, so I finish up with my W and Q commands to write and quit as above.

 

[MikeS]

My apologies... I usually search first but I was brainless in this instance...

So presuming the bios is 64K (as I undertand it is) I would leave CX at 0000? It makes sense to me but sometimes 'my logic is uncertain'...

Just to make sure: You're not confusing bits with bytes by any chance? Note that RAM & ROM chips are usually labelled and referred to in bits; i.e. a 64K (EP)ROM (e.g. 2764, 68764 etc. as used in PC/XTs) is only 8K bytes.

 

[leeb]

Well, I have now officially wiped my hard drive.
the W command apparently is different in 6.22
or I simply 'broke' it.

Just to make sure: You're not confusing bits with bytes by any chance? Note that RAM & ROM chips are usually labelled and referred to in bits; i.e. a 64K (EP)ROM (e.g. 2764, 68764 etc. as used in PC/XTs) is only 8K bytes.

Well, Im sure 'the book' says 64k, so I'll have to look at the number of the chip in the schematic.

Either way, I gotta figure out how to write it PROPERLY before I attempt it again! :shock:

 

[MikeS]

Well, I have now officially wiped my hard drive.
the W command apparently is different in 6.22
or I simply 'broke' it.

Well, Im sure 'the book' says 64k, so I'll have to look at the number of the chip in the schematic.

Either way, I gotta figure out how to write it PROPERLY before I attempt it again! :shock:

Well, you didn't tell us what kind of system or what kind of BIOS so we're doing this the hard way with guessing and twenty questions. PCs and XTs usually use 64Kbit chips (8Kbytes) but I see you're talking about a drive table so it must be at least an AT; many of those were indeed 64KB, but often in two 32KB (256Kb) chips. So just what have you got there?

And no, the W command, in fact pretty well all debug commands, have remained unchanged through all versions.

 

[Chuck(G)]

No way--there is a form of the W command that writes absolute sectors to disk, but it's very different (i.e. W 100 0 2 will clobber your C: drive boot sector).

You don't think I'd give you directions without checking it out first on a running system?

64K EPROM = 8K bytes by 8 bits. Which is what I referred to in the first place.

If you've got doubts, just boot from a floppy (just make sure that DEBUG is on it).

Maybe my mistake in all of this is assuming that people know what they're doing.

 

[MikeS]

...
64K EPROM = 8K bytes by 8 bits. Which is what I referred to in the first place.

Yeah, I know that you're talking about an 8Kx8 BIOS, but since he didn't care to tell us what kind of BIOS he's talking about but mentions a drive table, I wonder if he's in fact talking about a 2x32Kx8 64Kbyte ROM set.
PC=64Kbits (8Kbytes, 1x64K ROM)
AT=64Kbytes (2x256K ROM)

And I'm not sure what he means by "writing it properly"... I assume that it's clear that you can't "write" to the BIOS ROM (READ-ONLY memory)

Maybe my mistake in all of this is assuming that people know what they're doing.

Hmmm...

 

[leeb]

Well, you didn't tell us what kind of system or what kind of BIOS so we're doing this the hard way with guessing and twenty questions. PCs and XTs usually use 64Kbit chips (8Kbytes) but I see you're talking about a drive table so it must be at least an AT; many of those were indeed 64KB, but often in two 32KB (256Kb) chips. So just what have you got there?

And no, the W command, in fact pretty well all debug commands, have remained unchanged through all versions.

No way--there is a form of the W command that writes absolute sectors to disk, but it's very different (i.e. W 100 0 2 will clobber your C: drive boot sector).

You don't think I'd give you directions without checking it out first on a running system?

64K EPROM = 8K bytes by 8 bits. Which is what I referred to in the first place.

If you've got doubts, just boot from a floppy (just make sure that DEBUG is on it).

Maybe my mistake in all of this is assuming that people know what they're doing.

Geez... you needn't get so snotty about it.
Yes, I did not provide enough information and I am sorry for that. Right now I am working with 3 different laptops and as a result I have managed to amalgamate the machines together. the 2810 is a 286 which supposedly has a 64k ROM with the number 27c102jk.

The 2nd is an 1800 which is also a 286 but has a 27c210...
The one I am attempting to read/modify is the 1500hd running a V20 CPU but I cannot tell you the number of the ROM as I do not have the machine open.

Chuck... I did not say NOR attempt to imply that your instructions caused the drive wipe. IF it came across that way, I apologize for that as well.
I did not see the complete post and made the mistake of believing that the W command would be adequately documented in the 'help'... If it IS I misread it...

And when it comes to delving into the depths of the PCXT/AT I do NOT know what Im doing. NOR am I upset about the drive 'damage' as there was nothing that could not be lost... I merely documented the fact that I screwed up.

Please do not feel it necessary to aid me any further.
I will resolve this question myself...

Edit: BTW... I do now have what I believe is a complete image of the BIOS in file form (actually 2 of them). I only need to confirm the checksum is right and then 'get dangerous' some more. :D

 

[Chuck(G)]

Sorry Leeb, I was having a bad day and went off on you. It won't happen again.

Had I been thinking clearly, I would have given you the following BASIC program:

10 REM Program to dump any area of memory
20 LINE INPUT "Enter hex starting segment - ";A$
30 K = VAL( "&H"+A$)
40 IF K <> 0 THEN 70
50 PRINT "Input error, try again"
60 GOTO 20
70 INPUT "Enter number of KB to dump";L
80 IF L > 0 THEN 110
90 PRINT "Length must not be zero!"
100 GOTO 70
110 LINE INPUT "Enter file name to dump to - ",F$
120 ON ERROR GOTO 170
130 OPEN F$ FOR OUTPUT AS #1
140 CLOSE #1
150 OPEN F$ FOR RANDOM AS #1 LEN=1
160 GOTO 190
170 PRINT "Could not create ";A$;"--try again"
180 GOTO 110
190 ON ERROR GOTO 0
200 FOR C=1 TO L
210  DEF SEG = K + 64*(C-1)
220  FOR M = 0 TO 1023
230    PRINT #1, CHR$(PEEK(M));
240    PUT #1
250  NEXT M
260 NEXT C
270 CLOSE #1
280 PRINT "All Done!"
290 END

It'll dump anywhere in memory and runs under all versions of GWBASIC, BASICA, etc.

 

[MikeS]

Sorry Leeb, I was having a bad day and went off on you. It won't happen again.

Gee, I didn't think you "went off;" he said several times that he doesn't know what he's doing so yeah, looks like you did indeed make a wrong assumption, which you're just acknowledging.

Me, I don't even bother to reply when the answer to a question can easily be found in any of the previous threads on here about this very same question or with a few seconds of googling. If I had answered, since the question was only "has anybody dumped a BIOS with debug" I would just have said "Yes;" if I was in a really good mood I might even have pointed him to one or two of those previous threads.

If instead of asking about doing it the hard way with debug he'd just asked how he could go about dumping the BIOS ROM in one of his ATs I might have posted a pointer to any of the BIOS tools out there that anyone could find in a few seconds of googling, like Mike B's tool or this one for example (BIOS 1.35.1):

http://www.bioscentral.com/misc/downloads.htm

Since he prefers to use debug and is in a "never mind, I'll do it myself" snit anyway he obviously won't have any use for anything like that, but perhaps the next person with the same question will indeed check the relevant old threads first and appreciate finding it here.

 

[Chuck(G)]

Somewhen, I wrote a utility (probably in the late 80's) that scanned the entire region from C000-FFFF and dumped all BIOS extension ROMs as well as the BIOS itself. It determined the BIOS size by working backwards from the BIOS checksum and then the extension ROMs by the usual 55 AA... scanning. I should have gone digging for that one instead.

 

[leeb]

... Had I been thinking clearly, I would have given you the following BASIC program: ....

Thank you for the code... although I no longer need it as I properly followed the instructions you provided earlier, I will keep it in case I need it again.

(MikeS)
Thank you for the link. I have downloaded it and will see if it is useful to me.
Please notice the 'do it myself snit' came only after the intelligence insult (deserved it may be).
I hereby promise to leave Mount Olympus immedately.

All I need do now is determine the checksum and learn how to modify it.

I do sincerely thank you (all of you) for your help.

 

[MikeS]

Thank you for the code... although I no longer need it as I properly followed the instructions you provided earlier, I will keep it in case I need it again.

(MikeS)
Thank you for the link. I have downloaded it and will see if it is useful to me.
Please notice the 'do it myself snit' came only after the intelligence insult (deserved it may be).
I hereby promise to leave Mount Olympus immedately.

All I need do now is determine the checksum and learn how to modify it.

I do sincerely thank you (all of you) for your help.

Aw, we're all just here to help each other and have a little fun doing it; I think (hope) you'll find that tool useful.

What are you actually planning to do? Patch the drive table and burn new EPROMs? Are they in fact upper/lower pairs as most ATs are? Have you got the EPROMs and a burner? Here's where an ICE or battery-backed NVRAM comes in handy.

IIRC, at least with PC/XT ROMs, the checksum, or rather the value needed to generate a 0 checksum, was in the last byte; after a mod something (the POST?) would find the checksum error and report the value and (again, IIRC) you just had to add that to the existing byte to correct it. Sorry if I'm misremembering; it's been a long time since I patched a BIOS (mostly just to insert my company name in systems that I sold ;-) ).

Maybe someone else can confirm or correct?

FWIW I was going to do that when I had to replace the drive on my Toshiba 3100e (with only two entries in its table, neither useful) and even still have the debug dumps and notes somewhere, but I decided to do it the easy way instead with a DDO and never had a problem; still use it today.

 

[leeb]

Aw, we're all just here to help each other and have a little fun doing it; I think (hope) you'll find that tool useful.

What are you actually planning to do? Patch the drive table and burn new EPROMs? Are they in fact upper/lower pairs as most ATs are? Have you got the EPROMs and a burner?

I was going to do that when I had to replace the drive on my Toshiba 3100e (with only two entries in its table, neither useful) and even still have the debug dumps and notes somewhere, but I decided to do it the easy way instead with a DDO and never had a problem; still use it today.

That is exactly what I would like to do. (ALL) these are laptops (Tandy) that have a single PLCC chip. The 2810 also uses a single PLCC and the numbers for the 2810 and 1800 were previously listed. The 2810, I have realized, is a UV EPROM and could be overwritten once saved off... properly! :roll:

The DDO route would be preferred but it seems impossible to put in a larger drive if it cant be acknowledged by the BIOS first... something of a catch-22...

No, I do not have the spare chips NOR the burner... at this time. Im attempting to play 'zombie master' to multiple machines and am a bit scatterbrained so any ACTUAL attempt to be that creative will require some more time.

*beginning the climb down*

 

[leeb]

I relent!!!

I relent!!!

After having gone thru 13 pages of threads in searches, (and googling till Im blind!) I beg aid in this question.

Before I attempt to make changes to the drive table I want to ensure that I can fix the checksum. Unfortunately I cannot seem to get the proper checksum NOW (which I understand is SUPPOSED to be the last byte of the BIOS...) even before any mods get made!

I was successful in getting a dump of the BIOS (both thru debug and the bios1351 program), and they fc as duplicates...

I attempted to build a quick&dirty qbasic program to come up with the checksum but obviously I dont know how to do that either...

Is it not supposed to be a modulus-256 value or am I completely deluded?

If I am correct, the checksum is supposed to resolve to zero... which is not what I come up with.

It is a single-chip (PLCC) bios but I do not know right now the exact chip... will have to open the machine again first. It is SUPPOSED to be 64k (bytes) if MSD can be trusted to be correct.

I have done searches out the wazoo for checksum programs but only find the 'newer-more elaborate' types...

 

[Chuck(G)]

Yes, you sum modulo-256 every byte but the last, but then you create the stored checksum by subtracting the sum from 0 (2's complement) and store it as the last byte.

However, about the only ROM BIOS checksum you can reliably compute this way is the one that runs for the 2000 (hex) bytes between FE00:0 and the end of memory. Any other checksums are strictly vendor-dependent, both in their length and location.

Whose BIOS do you have?

 

[leeb]

Yes, you sum modulo-256 every byte but the last, but then you create the stored checksum by subtracting the sum from 0 (2's complement) and store it as the last byte.

However, about the only ROM BIOS checksum you can reliably compute this way is the one that runs for the 2000 (hex) bytes between FE00:0 and the end of memory. Any other checksums are strictly vendor-dependent, both in their length and location.

Whose BIOS do you have?

It is a phoenix bios... 2.52.01 and as I understand it, it starts at f000:0 but SEEMS to be only 32k (0-7FFF) and then it repeats down to f000:FFFF.
The Speedstor program claims the drive table is at F000:d81f and it can be found there but I also find it 8000h earlier at 581f...
The last 3 bytes of either section are FF FE 00.... and the 00 is supposed to be the checksum...

The FIRST 2000h bytes are nothing but FF... spot for the old BASIC perhaps?

Even if I attempt to checksum only half of the mirror it ends up 1/2 of the original value of A4h (or 0 - A4 = 5Ch). Excluding the checksum byte makes no change since it is 00...

... and if I leave off the first 2000h of 'FF' THEN process the remaining first 24k it still does not end up zero...
I admit Im completely confuzzed... will have to pull the chip and find out what it is... but the bios1351 program AND debug AND MSD.exe gave me the same data... it IS possible, I suppose, that they are ALL wrong..

AAAARRRRGGGHHHH! :shock: