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.
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"?
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?
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.
Hej Poul-Henning
Er følgende nyttigt?:
Various roms for the Commodore C900 (Z8000) computer: http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/c900/index.html
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.
Kan du NOP'e ROM checket og se hvor i koden noget går galt?
Er vinduet på eprommen dækket lystæt helt til ? Jeg havde en 6502 styring, som kun fejlede på bordet (under arkitektlampen:)
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.
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? :)
Har du forsøgt dig på CBM-Hackers mailinglisten, om der måske var nogen der havde oplevet noget tilsvarende?
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?
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.
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?
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.
Sei og cli er vel bare enable og disable interrupt. Nok derfor de ikke er med i simulatoren
$ 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.
Nå, det er vist bare formattering - de bytes fremgår jo af .CONST.
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?
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|
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?
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 & 0xffDer er en CPX i den ydre løkke, den clearer vel carry?
Har i fået liv i det?
