Weird ZX81 Behavior Cased By ROM

[bwinkel67]

My primary TS1000 started misbehaving. Whenever I did any sort of INKEY$ loop, it would quit with either error 2 or 4. I thought it was a RAM wobble issue but after lots of contacts cleaned, the problem persisted. I decided to try switching out various ICs and discovered the ROM was the culprit.

The simplest failure example was this:

Code: Select all

10 LET K%=INKEY%
20 IF K%="" THEN GOTO 10

The machine would error out with either a 2 or 4 code. With a different ROM it worked. All my ROMs seem to be the same, as I ran a checksum and they all had the identically value.

Code: Select all

10 FAST
20 LET A = 0
30 FOR B = 0 TO 8191
40 LET A = A + PEEK B
50 NEXT B
55 PRINT “ROM TEST”
60 PRINT A
70 PRINT SQR 0.25

All three had a value of 855106 and printed 0.5 for the squarer root call. So question, why would a bad ROM chip, with its checksums ok, cause this kind of behavior?


Here are pics of each. The Motorola one is the bad ROM.

[1024MAK]

I’m not sure why, but your post has no attached pictures...

Note that the forum does have a limit on the file size of attachments.

Mark

[bwinkel67]

I changed the pics to PNG....

[Moggy]

You have a 622 2nd issue ROM, a final issue 649 and the Motorola one I believe is also a 649.

Some ROM faults can be caused by tarnished pins so try cleaning the ones on the ROM that appears faulty.

More ROM info can be found halfway down this thread courtesy of Mark.

https://www.sinclairzxworld.com/viewtop ... 693#p14693

[bwinkel67]

I did clean the pins on the Motorola ROM and no change. It also seems to give the best picture through RF when RAM pack installed. I've noticed over time that if the a RAM wobble occurs, the picture interference gets less. So somehow it seems that ROM is impacted RAM.

[bwinkel67]

You have a 622 2nd issue ROM, a final issue 649 and the Motorola one I believe is also a 649.

They all have the same checksum...isn't the content in all three the same?

[1024MAK]

That checksum program will give the same result for both the 622 and 649 ROMs.

550 ROM checksum is 854885 SQR is 1.3591409
550 ROM with hardware bodge is ??? (not tested)
622 ROM checksum is 855106 SQR is 0.5
649 ROM checksum is 855106 SQR is 0.5

Mark

[1024MAK]

The 550 is the first (and original) ROM. It has a bug in the maths routine, hence the silly result for the square root function.

Some ZX81s have a daughter board that corrects the above bug by overriding a single byte with a different value when the Z80 executes it.

Sinclair corrected this bug in the 622 version. But this has a problem with the PAUSE command.

Hence a third (and final) version, 649, which corrects this.

Mark

[bwinkel67]

Hmm, then somehow a reordering of instructions could cause the same checksum. Or, some unlikely occurrence of taking away and adding instruction that results int he same value. I'm going to re-try computing the checksum using this modified code:

Code: Select all

10 FAST
20 LET A = 0
30 FOR B = 0 TO 8191
40 LET A = A + ((B+1) * PEEK B)
50 NEXT B
55 PRINT “ROM TEST”
60 PRINT A
70 PRINT SQR 0.25

[bwinkel67]

So with my new checksum program (maybe more accurately a really primitive hash) the three ROMs now give different value:

ROM 1 = 3424166000
ROM 2 = 3424958100
ROM 3 = 3424957100

Btw, I'm running a somewhat dated EigthyOne (i.e. I downloaded the latest a few years back and I don't tend to update -- I'm running v1.26) and its default seems to be ROM 2. Any reason for that?