ROMUPLOAD from Emu48: Bad CRC in Bank 1
John H Meyers
(the units which have the incredible "serial port hardware bug")
in a packing case, where it has been sitting for a year or two,
and found a PC which can still communicate with it,
I decided to have a go at upgrading it from 1.17 to 1.19-6,
and since I already have 1.19-6 on my emulator,
why not, I thought, just type a ROMUPLOAD command
on that emulator, and let it upload its rom to my real calc?
Apparently this was not so great an idea after all,
since immediately after the expected end-of-download message
"System may not be installed properly" on the calculator,
when I select "Download Pack" as instructed, I do not get
"System Present," as assumed by the instructions;
instead I get "Error - Full Check Bad CRC,"
while the emulator still waits for something else to happen.
Testing "Full ROM" [#7] on the calculator now gives,
sure enough, "Object with bad CRC, Bank 1"
After wasting more time erasing banks again and repeating,
with identical results, I finally thought to try the "Full ROM"
test on the emulator -- bingo! the emulator's ROM also has that
same "bad CRC" in its own bank 1, even though it has been
operating all this while.
It is possible, I reflect, that I may have applied the last
ROM updates to the emulator using program "upd49rom.exe"
(which updates the emulator's "rom.e49" file from a ".flash" file),
so perhaps I should go back and reinstall the emulator's original
ROM, for comparison, without relying on that program at all.
So now I'm setting aside my current rom.e49 (or rom.49g) file,
I'm copying the original 1.19-6 emulator ROM file (possibly from
epita.fr?) in its place, and I'm restarting the emulator,
and guess what -- already an "Object with bad CRC, Bank 1,"
although this is the *original* emulator ROM file for 1.19-6,
untouched by anyone, directly downloaded from "the source."
I also did another 1.19-6 download from www.hpcalc.org
and got identical md5 checksums on its emulator rom file
which was dated 2001/10/03:
d5fddb6f16b443b6749a36996b1053f8 rom.49g [new]
d5fddb6f16b443b6749a36996b1053f8 rom.e49 [old]
The flash files also match:
d881753cebe3318f86e5b5615e301ebf hp49119-6.flash [new]
d881753cebe3318f86e5b5615e301ebf hp491196.fla [my old one]
But the emulator ROM file apparently comes with a built-in
"Object with bad CRC, Bank 1,"
and this in turn appears to "infect" any calculator
which tries to download ROM from the emulator.
Is there any way to fix the bad ROM in the emulator?
I thought perhaps to try to re-upload to Emu48 a good ROM from my
calculator (meanwhile re-updated via FDP.EXE from the flash file),
but I can't seem to get the emulator to go into that mode
which is required to get to the "no system" menu.
Any ideas?
Ciao.
.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Christoph Giesselink
short answer to your problem:
Please _remove_ the
Patch "BEEP.49G"
line in your KML script. The ROM is patched for beep emulation.
But I must confess that one Emu48 version, but I don't know which one (any
final or beta in the last time) made the PATCH changes permanent on my
systems. In such case I update the ROM on the PC with the "upd49rom.exe"
tool to fix this.
Cheers
Christoph
"John H Meyers" <jhme...@miu.edu> schrieb im Newsbeitrag
news:3E1AC65B...@miu.edu...
John H Meyers
> Please _remove_ the Patch "BEEP.49G" line in your KML script.
This indeed corrects the "Bad CRC in Bank 1," thanks!
I wonder whether there exists a second patch
which could correct the CRC to match the first patch
(perhaps by changing something other than the CRC itself,
so that it could remain constant for all ROM versions)?
[r->] [OFF]
Christoph Giesselink
> Christoph Giesselink wrote:
>
> > Please _remove_ the Patch "BEEP.49G" line in your KML script.
>
> This indeed corrects the "Bad CRC in Bank 1," thanks!
>
> I wonder whether there exists a second patch
> which could correct the CRC to match the first patch
> (perhaps by changing something other than the CRC itself,
> so that it could remain constant for all ROM versions)?
Changing another unused byte(s) to get the correct CRC is quite impossible,
therefore we use CRC's to protect the data. The only solution is to modify
the CRC itself. The calculation methods, or better the position of the CRC's
are different in the calculators emulated by Emu48, so there's no general
solution. When you know the position of the CRC in ROM you can patch the CRC
by the same way like the beep patch (by adding one or more lines in the
patch file). And here you are right, that only works for one ROM revision. I
use this method in the HP28C skin for Emu28 for example.
In a Lewis chip family calculator emulator (not published) I use the
technique that after patching (and only then) all ROM CRC's are
automatically updated. This is possible because all emulated calculators
(with only one very minor exception) use the same calculation scheme and the
same positions of the CRC's in ROM.
Cheers
Christoph
Eric Smith
> Changing another unused byte(s) to get the correct CRC is quite impossible,
Why is it quite impossible? In a block of data, a change to a bit in
any position (byte and bit) has a predictable effect on the bits of the
CRC. While it may not be the case that a single byte change can be
found to get the desired CRC, it is almost certainly possible to find a
small number of changes to unused bytes to obtain any desired CRC.
Jean-Yves Avenard
"Eric Smith" <eric-no-s...@brouhaha.com> wrote in message
news:qh65syn...@ruckus.brouhaha.com...
> Why is it quite impossible? In a block of data, a change to a bit in
> any position (byte and bit) has a predictable effect on the bits of the
> CRC. While it may not be the case that a single byte change can be
> found to get the desired CRC, it is almost certainly possible to find a
> small number of changes to unused bytes to obtain any desired CRC.
The idea of a CRC is that it is "impossible" and not just *quite* impossible
to get the same CRC for a block when changing only one byte in it
Jean-Yves
Eric Smith
> Why is it quite impossible? In a block of data, a change to a bit in
> any position (byte and bit) has a predictable effect on the bits of the
> CRC. While it may not be the case that a single byte change can be
> found to get the desired CRC, it is almost certainly possible to find a
> small number of changes to unused bytes to obtain any desired CRC.
"Jean-Yves Avenard" <m...@privacy.net> writes:
> The idea of a CRC is that it is "impossible" and not just *quite* impossible
> to get the same CRC for a block when changing only one byte in it
True. But that wasn't the question that was posed. If you patch one byte
in a CRC'd block, can you find another "unused" byte to change that will
make the block come out to the same CRC? In general, if you have only one
"unused" byte to work with, the answer is no. However, it is not that
difficult to come up with changes to a small number of "unused" bytes that
will result in the desired CRC.
Each individual bit of the data block changes a particular subset of bits
in the CRC, such that flipping that data bit flips the corresponding CRC
bits. The precise mapping of the data bits to the CRC bits is determined
by the CRC polynomial. This characteristic is why a CRC should not be used
as a MAC (Message Authentication Code) for encrypted communication, and is
part of the reason that WEP (Wired-Equivalent Privacy) on encrypted 802.11
wireless traffic is so easy to crack.