dongfeng
Veteran Member
Only one of them is broken. I have no idea how it happened, but the top layer of the chip has broken away. Like removing the top layer of a sandwich.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Copying BIOS (EPROM burner)
- Thread starter dongfeng
- Start date
Only one of them is broken. I have no idea how it happened, but the top layer of the chip has broken away. Like removing the top layer of a sandwich.
modem7
10k Member
Debug
Debug
For writing files, DEBUG uses two registers, BX and CX, and is therefore capable of writing more than FFFFh bytes. For example, to write 64K bytes, put 0001 into BX and 0000 in CX (00010000 = 64K).
And so my initial problem wasn't with the W command. Instead, the problem was with the M (move) command. When I tried "M F000:0 10000 0100", Debug errored on the "10000" portion, i.e. a count of 64K bytes (10000h). Eventually I found a web site that stated that Debug interprets "0000" as 64K, and so I then found that "M F000:0 0000 0100" moves 64K bytes.
And so at this point I was moving (copying really) a 64K block of RAM, and creating a 64K file. The problem then was that the file contents were not as expected. And so there is something else going on. Thinking about it now, the cause might be that my moved 64K block is going over a segment boundary. I'll look into it later.
Debug
For writing files, DEBUG uses two registers, BX and CX, and is therefore capable of writing more than FFFFh bytes. For example, to write 64K bytes, put 0001 into BX and 0000 in CX (00010000 = 64K).
And so my initial problem wasn't with the W command. Instead, the problem was with the M (move) command. When I tried "M F000:0 10000 0100", Debug errored on the "10000" portion, i.e. a count of 64K bytes (10000h). Eventually I found a web site that stated that Debug interprets "0000" as 64K, and so I then found that "M F000:0 0000 0100" moves 64K bytes.
And so at this point I was moving (copying really) a 64K block of RAM, and creating a 64K file. The problem then was that the file contents were not as expected. And so there is something else going on. Thinking about it now, the cause might be that my moved 64K block is going over a segment boundary. I'll look into it later.
Chris2005
Banned
"For writing files, DEBUG uses two registers, BX and CX, and is therefore capable of writing more than FFFFh bytes. For example, to write 64K bytes, put 0001 into BX and 0000 in CX (00010000 = 64K)."
Which versions? I'd be embarrassed to find out I'd been missing something the whole time. I had expected that what was saveable was restricted to the active data segment (debug's data segment, which is where the code is loaded up). Ah well, live and learn.
Which versions? I'd be embarrassed to find out I'd been missing something the whole time. I had expected that what was saveable was restricted to the active data segment (debug's data segment, which is where the code is loaded up). Ah well, live and learn.
modem7
10k Member
Don't know, but it goes back to at least DOS 3.1
Yep. Been VB programming for many years. About six or so months ago, someone watching me code brought to my attention a time saver that apparently is widely known to VB programmers. Embarrassing!
modem7
10k Member
Splitting 64K up into odd/even components
Splitting 64K up into odd/even components
When running it, browse to the 64K file then click on the 'odd/even' button. Two files (32K each in this case) will be created - one containing the odd address bytes, the other containing the even address bytes.
Get Nige to burn each 32K file to a suitably speed rated 27256 EPROM.
Splitting 64K up into odd/even components
Attached is a little program I knocked up to do the split of the 64K file (into odd and even portions).modem7 said:
When running it, browse to the 64K file then click on the 'odd/even' button. Two files (32K each in this case) will be created - one containing the odd address bytes, the other containing the even address bytes.
Get Nige to burn each 32K file to a suitably speed rated 27256 EPROM.
dongfeng
Veteran Member
I have the dumped System Rom now :D
I've attached them to this message, both with and without the headers. Without the headers the file size is 64.0 KB (65,536 bytes), so it seems to tie up ok.
I've attached them to this message, both with and without the headers. Without the headers the file size is 64.0 KB (65,536 bytes), so it seems to tie up ok.
dongfeng
Veteran Member
That is great, thank you so much! Everyone has been very helpful on this thread, I really appreciate it
`Attached the "split" system ROM, if it is of interest to any readers.
Now to get them burnt to a suitable EPROM and keep my fingers crossed that it actually works!!!
modem7
10k Member
The 27256's in your picture are rated at 120nS. The replacements should be 120nS or faster. It's very unlikely that the old 200nS versions that Nige and I have will do the job. Therefore, I suggest that you take Nige up on his offer of buying suitably rated units.
dongfeng
Veteran Member
I have done! Also am sending Nige the surviving ROM so he can double check everything copied across properly