Error in HP 48sx J rom ?

[Yellow]

When I use the latest j rom for the 48sx there is an error in the IROM.
( click/hold ON, click D, click C)
Instead of telling me that it is OK, I get the following:

IROM 0DA4F

(to get out of the test, click/hold on, click C)

Full self test: click/hold ON, click E. error: fail 00002
(to get out of the test, click/hold on, click C)

I do not get therse errors when using ROM E.
(to find out whci rom version you have loaded: click/hold ON, click D, click back(arrow left), click/hold EVAL.)
Anyone any idea?

Nick

[Christoph Giesselink]

(07-27-2020 04:40 PM)Yellow Wrote:  When I use the latest j rom for the 48sx there is an error in the IROM.
( click/hold ON, click D, click C)
Instead of telling me that it is OK, I get the following:

IROM 0DA4F

(to get out of the test, click/hold on, click C)

Full self test: click/hold ON, click E. error: fail 00002
(to get out of the test, click/hold on, click C)

I do not get therse errors when using ROM E.
(to find out whci rom version you have loaded: click/hold ON, click D, click back(arrow left), click/hold EVAL.)
Anyone any idea?

Nick

Use a proper emulator or a proper ROM image. The Emu48 binary package contains a console program which can check the CRC of a HP48 ROM image.

convert.exe ROM.48S

[Yellow]

Hi Christoph,

I use your latest version Emu48.162 with the 48sx J rom from https://www.hpcalc.org/details/4371 .

With 48sx E-rom the IROM is OK.
With 48sx J-rom the IROM is not ok. However, with the android app, this Jrom is good.
Odd.

in dos box: convert.exe ROM.48S the ROM CR passed CRC 0602. and it was converted...
Let's check again:

IROM 0DA4F.

Humm - not good.
Tried the following:

in dos box: convert.exe ROM.48S romfile
copy ROM.48s ROM.48s_j
copy romfile ROM.48S

Now the errors are gone. Very good!!
The file size increased to 512kb

I do not understand why there are no errors with the E-version of the rom.
Something could / should be written in the faq I suppose...

Thanks for the reply and showing me the convert executable. What does it do actually?

Nick

[Giuseppe Donnini]

The problem stems from the fact that the HP-48 ROM images officially released by HP are actually *not* pure ROM images, but ROM images overlaid with garbage originating from an MMIO chip. Because of this, all eleven official HP-48 ROM images produce invalid checksums.

We are all extremely grateful to HP for having released these ROMs, nevertheless, it remains a real shame that such a blunder could happen. The person who dumped these ROMs obviously had no clue about the memory chip configuration of the HP-48!

Thankfully, when a file is converted with CONVERT.EXE, the area between #00100h and #0013F is automatically zeroed out. However, if CONVERT.EXE is used as a mere checking tool (with no second argument), it does not complain upon encountering non-zero nibbles in the default MMIO chip area. I think it would be helpful if this behavior was changed.

On the other hand, ROM2EMU.EXE from the FILETOOL package, also by Christoph Gießelink, is a more general tool which is not specialized on HP-38 and HP-48 ROM images and, therefore, does not check nor alter anything during the conversion process.

So what happened is that you probably run CONVERT.EXE to create your revision E EMU image, but instead used ROM2EMU.EXE to create the corresponding revision J file.

[Christoph Giesselink]

(07-28-2020 02:09 AM)Yellow Wrote:  Thanks for the reply and showing me the convert executable. What does it do actually?

In the early days of Emu48 the program only accepted unpacked ROM images. An unpacked ROM image, in difference to a packed ROM image, use only the lower 4 bit of a byte. So a HP48SX packed ROM image has a size if 256KB whereas the unpacked size is 512KB.

convert.exe was designed to convert different ROM images file formats of the HP38G, 48SX and 48G into the unpacked format of Emu48. Meanwhile Emu48 accept also packed ROM images, which are automatically detected and converted inside Emu48 temporarily into the unpacked variant.

What does convert.exe exactly. The syntax is

convert.exe <ROM-file> [<unpacked-ROM-file>]

where <ROM-file> is a ROM image file in a suitable format. convert.exe then tries to detect the <ROM-file> format and convert this file internally to the unpacked format used by Emu48 v1.x. Then the IO-address-area is filled with zero bytes and the internal CRC's of the ROM image in RAM are verified. 2nd, if the optional <unpacked-ROM-file> parameter is given, the internal unpacked ROM image is copied into this file. Without the 2nd argument it's just for verifying the CRC's.

Why I'm speaking about a suitable format. Back to the middle/end of the 90'th there where some HP48 emulators which all need a ROM image. So the first process was to make a ROM image from your own calculator(s). This was a long and boring process. The first method I saw and used was described in Derek S. Nickel VOYAGER.ZIP package using the internal memory scanner of the HP48SX. Because the HP48G has no internal memory scanner, a separate tool for download the HP48G ROM was necessary. The first HP48 emulator I used was x48 v0.4.0. from Eddie C. Dost where I already had the HP48SX dump from the VOYAGER package and made a HP48G dump with the ROMDump program delivered with the x48 package. After switching to Emu48 v0.99 I was able to convert my images for the x48 to the Emu48 format.

The ROM CRC could only be valid if the Emu48 KML script contain no ROM Patch command. In old environments the BEEP patch was done to support beeping. Meanwhile the beep simulation was replaced by an emulation and so the beep patch is obsolete and your get a KML script warning using the beep patch. But there are still variants of ROM patching for example to disable the 10min auto-off feature of the calculator. All patches destroy the CRC's. In older very versions of Emu48 it was possible that such a ROM patch stay permanent. So maybe you used a j-image version which got this defect in an earlier usage.

Some final words why I prefer the E over the J version on the HP48SX. Without doubt, the J version is the faster and has less bugs then the prior versions, but to to accomplish this many code was moved inside to get room for the modifications. With moving this code many unsupported ROM entry points for SysRPL and assembly programs became illegal. And that's the reason why early SysRPL programs on the HORN-disks don't work in connection with the J version, because they were designed to run on an A version. Version E was the last version where many of the unsupported ROM entry points stay on the old position and so you have a good chance to run programs written for the A-D versions on a E version. When somebody wrote a SysRPL program which is compatible with the J version, most times the programmer was aware about these differences and used entry points valid for the J and the more common E version of the ROM.