Looking around for programs to test my one working ZX81 (and one nearly working) I found this post where a checksum of the ROM is calculated, and a message printed if the ROM is the early bugged SQR version, the later fixed one, or if the ROM might be bad. Useful!
viewtopic.php?p=23479#p23479
I played it into my 2K ZX81 from the java tapeutils program running on a Linux laptop. It loaded OK.
When I run it, it displays 855106 ROM FAULT
Heart sinks. Oh.
And yet.. looking at the program.. the output of 855106 apparently indicates the ROM is the "NEW" ROM and thus ok.
40 IF T=855106 THEN PRINT "NEW ROM"
But it doesn't do that for me, it only prints "ROM FAULT" from line 60
PRINT T gives me 855106
So why does the test at line 40 fail?
I added line 21
21 IF T=855106 THEN PRINT "YES"
and the program now prints YES followed by ROM FAULT!
If I edit line 40, delete the existing value 855106 and retype 855106...
it now prints "NEW ROM OK"
I loaded the program a second time, it behaves the same way - the test fails.
Any idea what is going on here?
Thanks
Ian
CHKROM.P curiously reports ROM FAULT when result is 855106
Re: CHKROM.P curiously reports ROM FAULT when result is 855106
According to the original thread there should be a FOR instead of LET(somwhere).
For reference the following peeks can also be used for simplicity.
3875 returns 253 old ZX81 ROM, 205 new ZX81 ROM
5274 returns 128 old ZX81 ROM, 42 new ZX81 ROM
For reference the following peeks can also be used for simplicity.
3875 returns 253 old ZX81 ROM, 205 new ZX81 ROM
5274 returns 128 old ZX81 ROM, 42 new ZX81 ROM
- 1024MAK
- Posts: 5165
- Joined: Mon Sep 26, 2011 10:56 am
- Location: Looking forward to summer in Somerset, UK...
Re: CHKROM.P curiously reports ROM FAULT when result is 855106
If you mean my post in that topic, that was referring to a typo in the BASIC program in the first post, which the poster has since corrected. So that comment about the missing FOR is no longer relevant.
The ZX81 stores the number in a BASIC line in two versions (see chapter 27 in the ZX81 BASIC Programming manual). You can only see one version (the user entered/displayed decimal). What you can’t see is the machine readable binary version (stored as a floating point number in five bytes). It would appear that for some reason, the binary numbers in the program are not the same value as the displayed versions.
Mark
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Amp
Standby alert
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer being good this year.
ZX81 Chip Pin-outs
ZX81 Video Transistor Amp
Standby alert
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer being good this year.
Re: CHKROM.P curiously reports ROM FAULT when result is 855106
Note: Memotech cards (Memotext & Memotech If Centronics) and the G007 card can change the ROM BIOS checksum. Memotech HRG too, but you had to set the IOrq on the setup.
Xavier ...on the Facebook groupe : "Zx81 France"(fr)
Re: CHKROM.P curiously reports ROM FAULT when result is 855106
Ah thank you. I tried a few more things and was hedging towards an answer like this, without understanding exactly what was going on.1024MAK wrote: ↑Tue Dec 29, 2020 1:07 am
The ZX81 stores the number in a BASIC line in two versions (see chapter 27 in the ZX81 BASIC Programming manual). You can only see one version (the user entered/displayed decimal). What you can’t see is the machine readable binary version (stored as a floating point number in five bytes). It would appear that for some reason, the binary numbers in the program are not the same value as the displayed versions.
Mark
I once had a similar problem with a BBC micro and a Teletext adaptor - a short downloaded telesoftware program listed ok and looked ok but refused to run. Retyping each 'ine exactly as it appeared would allow it to work.
Given the curious screen grab in the original post of the x81 rom test program I wonder if this .p file came from an emulator with a bug?
I discovered that all it takes to fix the problem is to EDIT line 40 then press NEWLINE no need to change anything.
Do the same for all lines that are testing variable T against a value and it all works correctly.
Ian