Dette indlæg er alene udtryk for skribentens egen holdning.

Find en bitfejl (vil I ikke nok?!)

15. februar 2020 kl. 10:2331
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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.

Artiklen fortsætter efter annoncen

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

  1. 082c TEST_ROM_SUM:
  2. 082c a9 00 | | LDA #0x00
  3. 082e 85 39 | 9 | STA 0x39
  4. 0830 a8 | | TAY
  5. 0831 a9 08 | | LDA #0x08
  6. 0833 85 3a | : | STA 0x3a
  7. 0835 18 | | CLC
  8. 0836 71 39 |q9 | ADC (0x39),Y
  9. 0838 c8 | | INY
  10. 0839 d0 fb | | BNE 0x836
  11. 083b e6 3a | : | INC 0x3a
  12. 083d a6 3a | : | LDX 0x3a
  13. 083f e0 10 | | CPX #0x10
  14. 0841 d0 f3 | | BNE 0x836
  15. 0843 69 ff |i | ADC #0xff
  16. 0845 85 39 | 9 | STA 0x39
  17. 0847 d0 07 | | BNE ROM_ERROR
  18. 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.

Artiklen fortsætter efter annoncen

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.

31 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
31
27. februar 2020 kl. 11:39

Har i fået liv i det?

30
17. februar 2020 kl. 11:04
  • undtagen til sidst, der bliver carry sat.
28
17. februar 2020 kl. 10:47

Der er en CPX i den ydre løkke, den clearer vel carry?

27
17. februar 2020 kl. 10:29

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:

  1. def romsum(m):
  2. cs = 8
  3. for a in range(0x800, 0x1000):
  4. cc = cs >> 8
  5. assert cc in (0, 1)
  6. cs &= 0xff
  7. cs += m[a] + cc
  8.  
  9. cc = cs >> 8
  10. assert cc in (0, 1)
  11. cs &= 0xff
  12. cs += 0xff + cc
  13. return cs & 0xff

26
17. februar 2020 kl. 09:30

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?

25
17. februar 2020 kl. 09:24

De fremhævede bytes (0x0f90..0x0f93 og 0x0f98..0x0f9b) fremgår ikke under TABLE: i CBM900KBD.TXT.</p>
<p>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:

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

22
17. februar 2020 kl. 07:45

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?

21
17. februar 2020 kl. 02:45

Nå, det er vist bare formattering - de bytes fremgår jo af .CONST.

20
17. februar 2020 kl. 02:11

$ 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.

19
17. februar 2020 kl. 00:28

Sei og cli er vel bare enable og disable interrupt. Nok derfor de ikke er med i simulatoren

18
16. februar 2020 kl. 23:24

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.

16
16. februar 2020 kl. 18:07

Hvis der er fejl i tabellen, er der så anden konsekvens end at en af tasterne ikke vil fungere korrekt? Og kan du i så fald ikke bare sætte det til, finde frem til den defekte tast og derefter rette i tabellen?

14
16. februar 2020 kl. 15:00

Der er også RAM. De første 256 bytes er zero page, som kan adresseres direkte. De næste 256 bytes er stak, som bruges af JSR og interrupt.

13
16. februar 2020 kl. 14:46

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?

12
16. februar 2020 kl. 11:41

Har du forsøgt dig på CBM-Hackers mailinglisten, om der måske var nogen der havde oplevet noget tilsvarende?

10
15. februar 2020 kl. 17:32

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? :)

9
15. februar 2020 kl. 16:58

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.

8
15. februar 2020 kl. 15:35

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

6
15. februar 2020 kl. 14:58

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

5
15. februar 2020 kl. 14:37

Kun i den forstand at hans rom er en version fra en måned tidligere og at den formodentlig mangler halvdelen af indholdet :-/

men den første kilobyte ser ud til at have samme indhold som vores.

3
15. februar 2020 kl. 13:32

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.

2
15. februar 2020 kl. 12:37

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?

1
15. februar 2020 kl. 12:00

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"?