Hi
Tom Walker wrote:
> Just to add to the endless confusion, mine gives a sum of
> 7d5eae5f1e9f0b06680f559edd14508d732e8d87.
To sum up,
42c3dd0ae43149849b674ea025cb2206512a5b4a My "good" 3.70.
7d5eae5f1e9f0b06680f559edd14508d732e8d87 My "bad" 3.70.
7d5eae5f1e9f0b06680f559edd14508d732e8d87 Tom's 3.70.
a1218ab6bd2f965d317522be68112d9ae3742fa0 David's first 3.70.
e6b0e9d7797f5df6edd95a85978fa1a92fc7fef6 David's wife's 3.70.
e7cb05c9925dd0d7d9d5ff6f74244066c5c87e34 Musus Umbra's 3.70.
Tom's matches one I already had, labelled "bad". Can't recall why,
would have to investigate. The only one Google's heard of is my "good"
one, so that doesn't help.
Given the ones I have to hand,
$ sha1sum *
a1218ab6bd2f965d317522be68112d9ae3742fa0 david
e6b0e9d7797f5df6edd95a85978fa1a92fc7fef6 davidwife
7d5eae5f1e9f0b06680f559edd14508d732e8d87 mybad
42c3dd0ae43149849b674ea025cb2206512a5b4a mygood
$
they all claim to be 3.70.
$ egrep -ao 'MOS Utilities[^)]+\)' *
david:MOS Utilities 3.70 (30 Jul 1996)
davidwife:MOS Utilities 3.70 (30 Jul 1996)
mybad:MOS Utilities 3.70 (30 Jul 1996)
mygood:MOS Utilities 3.70 (30 Jul 1996)
$
David's two are quite close in that not many words differ:
$ hex() { hexdump -ve '/4 "%08x\n"' "$@"; }
$ diff <(hex david) <(hex davidwife)
399740c399740
< eba0320d
---
> eba079d1
400061c400061
< eaa03152
---
> eaa07916
400185c400185
< eba03048
---
> eba0780c
401401c401401
< eba02b94
---
> eba07358
402609c402609
< 1aa0269e
---
> 1aa06e62
402624c402624
< 1aa0268f
---
> 1aa06e53
403278c403278
< eba02437
---
> eba06bfb
$
They all look like ARM instructions to me. Perhaps someone would like
to disassemble. An alternative view, without the offsets:
$ sdiff -s -w40 <(hex david) <(hex davidwife)
eba0320d | eba079d1
eaa03152 | eaa07916
eba03048 | eba0780c
eba02b94 | eba07358
1aa0269e | 1aa06e62
1aa0268f | 1aa06e53
eba02437 | eba06bfb
$
Taking those line numbers from diff and converting them back into byte
offsets, we get
$ diff <(hex david) <(hex davidwife) |
> sed -n '/^[0-9]/s/c.*//p' |
> awk '{print ($0 - 1) * 4}'
1598956
1600240
1600736
1605600
1610432
1610492
1613108
$
Those locations look to be in the Pinboard module.
$ LC_ALL=C strings -t d david |
> awk '$1 >= 1590000 && $1 <= 1613108' |
> fgrep \)
1593250 Int'l Keyboard 0.36 (27 Jun 1994)
1597225 Pinboard 0.66 (09 Jan 1995)
$
Anyone recall 3.70 bug fixes to do with Pinboard? Is it in RISC OS
Open's sources? Perhaps the change history gives a clue.
There's no way on 3.70 hardware that the ROM can be masked with patched
RAM is there? So soft-loaded stuff is skewing what's being saved? I'm
sure there isn't, and it's only on the Iyonix that copy stuff from flash
into RAM, and patches it, where the original flash is then no longer
accessible.
I'll examine the differences between the other files later; they're
bigger.
Cheers,
Ralph.
_______________________________________________
Rpcemu mailing list
[email protected]
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu