Find en bitfejl (vil I ikke nok?!)

Ude i datamuseum.dk er tastaturet på vores Commodore 900 er holdt op med at virke.

Vores Commodore 900 er en af perlerne i vores samling, en utrolig sjælden prototype på den UNIX computer som Commodore opgav til fordel for Amiga og PC10 produkterne.

Inde i tastaturet sidder der en Rockwell R65001EAB3 "piggyback" processor med en 2716 EPROM.

Den havde jeg ikke opdaget da jeg læste de andre EPROM'er fra maskinen for snart mange år siden og nu ligner det at den har glemt en bit.

Jeg har udlæst EPROM'en og disassembleret koden og den laver en checksum af EPROM'en:

082c                            TEST_ROM_SUM:
082c  a9 00        |    |               LDA     #0x00
082e  85 39        | 9  |               STA     0x39
0830  a8           |    |               TAY
0831  a9 08        |    |               LDA     #0x08
0833  85 3a        | :  |               STA     0x3a
0835  18           |    |               CLC
0836  71 39        |q9  |               ADC     (0x39),Y
0838  c8           |    |               INY
0839  d0 fb        |    |               BNE     0x836
083b  e6 3a        | :  |               INC     0x3a
083d  a6 3a        | :  |               LDX     0x3a
083f  e0 10        |    |               CPX     #0x10
0841  d0 f3        |    |               BNE     0x836
0843  69 ff        |i   |               ADC     #0xff
0845  85 39        | 9  |               STA     0x39
0847  d0 07        |    |               BNE     ROM_ERROR
0849  4c 8b 08     |L   |               JMP     MAIN

Når jeg udfører den beregning, ender jeg med A=0x01 i lokation 0x845

En eller anden byte har fejlagtigt den laveste bit sat, fordi EPROM'en er blevet glemsom.

Her er en binær kopi af EPROM'en.

Her er min disassemblering af koden i den.

Er der en 6502 haj til stede blandt publikum, som kan spotte hvilken bit det er galt med ?

/phk

PS: Hvis der er fejl i disassembleringen må I også gerne påpege det, den er lavet med mit PyReveng3 toolkit.

Kommentarer (31)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Chris Bagge

Der er jo i DDHF's hjemmeside en reference til Bo Zimmermann. Som jeg kan læse af teksten der så har han to maskiner af slagsen, som han vist ikke kan få liv i. Kunne man evt. få udlæst EPROM fra hans keyboards eller låne et af dem eller er det for "u-sportsligt"?

  • 6
  • 0
#3 Poul-Henning Kamp Blogger

Kunne man evt. få udlæst EPROM fra hans keyboards eller låne et af dem eller er det for "u-sportsligt"?

Vi har allerede kontaktet ham om det og hvis vi er heldige giver det en uafhængig bekræftelse af den eventuelle løsning vi kan komme op med ved inspektion.

Kunne det være en idé at variere forsyningsspængdingen til chip/tastaturet fra 4,75 til 5,25 V og se om det er muligt at midlertidigt at få den læst ud?

Det er en blandt flere "hacks" jeg overvejer hvis vi ikke kan finde løsningen på anden vis. Jeg tror dog ikke meget på netop denne, fordi 5V spændingen allerede hænger lidt lavt i keyboardet.

  • 1
  • 0
#9 Poul-Henning Kamp Blogger

Er vinduet på eprommen dækket lystæt helt til ? Jeg havde en 6502 styring, som kun fejlede på bordet (under arkitektlampen:)

EPROM'en er muret ret godt inde i tastaturet, så det tror jeg ikke er problemet.

Kan du NOP'e ROM checket og se hvor i koden noget går galt?

Min plan er at prøve at rette 0xaec, som jeg tror er checksum-tilpasningen.

Alt tyder på at fejlen ligger fra TABLE: og frem i din disassembly. Knap 128 bytes at lede i.

Ja, forudsat hans "read" er OK.

Det er lidt suspekt at han kun har den første kilobyte, for uden de to tabeller ville hans tastatur bare sende 0x00 eller 0xff hele tiden.

  • 1
  • 0
#10 Henrik Jacobsen

Ja, forudsat hans "read" er OK.

Er det ikke ret så sandsynligt, i betragtning af at I matcher på alle bytes? Ellers har han en læsefejl i samme bit som er hoppet i din prom.

Hvis din udmærkede antagelse om hvor checksum byten er placeret holder , så er summen også ens. Altså sandsynligvis samme indhold hele vejen.

Mon ikke bare han kom til at klikke 2708 da han læste? :)

  • 1
  • 0
#13 Per Lauge Holst

Så vidt jeg staver mig igennem, så forsøger koden, at ADC "add with carry" (A=0, C=0) på 0800-08FF, derefter et increment af indholdet i adressen 0x3a, så ADC loopet kan ske frem til adressen 0FFF, men da det er en ROM, så kan indholdet af adresserne ikke muteres - og der køres med A=0 og forhåbentlig C=0 på det hele. Så hvad er pointen?

Akkumulator bliver derefter adderet med 0xFF (-1) og C (0?), som gemmes i 0x39

Den eneste grund til efterfølgende at have A = 1 må være, at både A og C er 1, men A bliver ikke ændret, og C bliver kun muligvis sat i fbm. CPX #0x10 med 0x10

Er det fordi koden ikke eksekveres på skrivebeskyttet ROM? Eller har jeg glemt for meget 6510?

  • 2
  • 0
#18 Thomas Kjeldsen

Jeg fandt en 6502 emulator og har justeret den lidt så den kan loade din ROM-fil.

Emulatoren er online her: https://tlk.github.io/6502js/

Choose file: EPROM_C900KBD_R2_3_29_05_84.bin, Flash ROM-file, Run.

Hexdump og disassembly ligner umiddelbart dine resultater.

Når jeg starter emulatoren ser det ud til at den passerer TEST_ROM_SUM hvorefter den stopper ved PC=$08c3.

Jeg har ingen erfaring med 6502 så det er meget muligt jeg har overset noget. Fx ignoreres SEI og CLI instruktionerne da de ikke er implementeret.

  • 1
  • 0
#20 Thomas Kjeldsen

$ hexdump -s 0x078c EPROM_C900KBD_R2_3_29_05_84.bin | head -n 1 000078c 4c 5e 49 02 0f 1e 53 41 20 4a 01 03 10 1f 52 4f $

De fremhævede bytes (0x0f90..0x0f93 og 0x0f98..0x0f9b) fremgår ikke under TABLE: i CBM900KBD.TXT.

Der mangler flere bytes herefter, men ellers stemmer det med resultatet fra 6502js.

  • 1
  • 0
#22 Per Lauge Holst

Har du en anden chip at prøve med? For de fleste ting peger på at akkumulatoren på sær vis er blevet 1.

Nu blev min kommentar om selvmuterende ROM jo til, om der også er RAM - naturligvis er der det, ellers ville det slet ikke give mening med indirekte adressering via zero page Problemet, som jeg ser der er, at 0800-0FFF bliver ADCet - forhåbentlig med C=0, hvilket i mit hoved hverken giver mening for RAM eller ROM. Hvordan A så bliver 1 på chippen og 0 i simulator?

  • 1
  • 0
#25 Poul-Henning Kamp Blogger

De fremhævede bytes (0x0f90..0x0f93 og 0x0f98..0x0f9b) fremgår ikke under TABLE: i CBM900KBD.TXT.

Der mangler flere bytes herefter, men ellers stemmer det med resultatet fra 6502js.

Det er fordi '.CONST' entries normalt er "compact" så de ikke fylder den fortolkede dels antal linier.

Du kan se at de har disse bytes med helt ude til højre.

Her er den samme linie med "compact" slået fra:

0f8c                            TABLE:  
0f8c  4c 5e 49 02  |L^I | .CONST  0x4c,0x5e,0x49,0x2,0xf,0x1e,0x53,0x41  
0f90  0f 1e 53 41  |  SA|  
0f94  20 4a 01 03  | J  | .CONST  0x20,0x4a,0x1,0x3,0x10,0x1f,0x52,0x4f  
0f98  10 1f 52 4f  |  RO|  
0f9c  29 52 3b 04  |)R; | .CONST  0x29,0x52,0x3b,0x4,0x11,0x20,0x2c,0x53  
0fa0  11 20 2c 53  |  ,S|
  • 1
  • 0
#26 Mogens Kjær

Carry bliver brugt på en lidt (6502) utraditionel måde i koden. Normalt bruges den til 16 bit aritmetik, hér nulstilles den før løkken, så hver gang summen bliver >255 lægges der én til i næste løkkegennemløb. Til sidst lægges 255 plus carry til. Har du taget hensyn til carry i din beregning?

  • 1
  • 0
#27 Poul-Henning Kamp Blogger

Carry bliver brugt på en lidt (6502) utraditionel måde i koden. Normalt bruges den til 16 bit aritmetik, hér nulstilles den før løkken, så hver gang summen bliver >255 lægges der én til i næste løkkegennemløb. Til sidst lægges 255 plus carry til. Har du taget hensyn til carry i din beregning?

Ja, men åbenbart ikke godt nok...

Det her er min python version af checksummen:

def romsum(m):  
    cs = 8  
    for a in range(0x800, 0x1000):  
        cc = cs >> 8  
        assert cc in (0, 1)  
        cs &= 0xff  
        cs += m[a] + cc  
   
    cc = cs >> 8  
    assert cc in (0, 1)  
    cs &= 0xff  
    cs += 0xff + cc  
    return cs & 0xff
  • 1
  • 0
Log ind eller Opret konto for at kommentere