Disassemblering av program till PLC

[säter]

Jag vill minnas, att han som läste ur Epromen, sa att det är så.

Fetstil? 77 är fetstil för mig.

[BEEP]

"Fetstil? 77 är fetstil för mig."
Det var min äldre webbläsare som inte visade det fetstilta.

Om jag förstått allting rätt så kommer checksumman ifrån epromet och de där tre nollorna efter adressen kommer ifrån epromläsaren?
:10033 000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF CD

[lillahuset]

BEEP: Läs på om Intel hex så kan du gruppera siffrorna korrekt. https://en.wikipedia.org/wiki/Intel_HEX

[sodjan]

Record type 00 i tabellen ger formatet.
Det du hade med i inlägget ska läsas:

Kod: Markera allt

:10 02D0 00 0FC1C519018800C14AC1C2C500C25CC1 B5
:10 02E0 00 C3C500C303C4C2C3C54AC407C4C5C2C3 8F
:10 02F0 00 C5685201695301016A5401016B550101 3E
:10 0300 00 6C5601016D5701016E58016F0A604B01 77
:10 0310 00 614C0101624D0101634E0101644F0101 15

D.v.s. 16 bytes (0x10), start på t.ex. 0x02D0, record type "data" (0x00) 16 data
bytes (t.ex. 0FC1C519018800C14AC1C2C500C25CC1) samt checksum (B5).

Jag antar att varje par av prom (t.ex 0L + 0H) ger ett helt 16 bits ord som sedan
kan vara 12 bitar adress + 4 bitar op-code. Kanske...

När man väl vet hur det ska tolkas så är det inget större problem att läsa
in alla 8 filerna i t.ex. ett Python script och sammanställa en lista.

[lillahuset]

Här finns lite info om "processorn": http://tinymicros.com/wiki/MC14500B

Speciellt handboken var lite intressant. Videon om en implementering med TTL var underhållande.

[säter]

Jag antar att varje par av prom (t.ex 0L + 0H) ger ett helt 16 bits ord som sedan
kan vara 12 bitar adress + 4 bitar op-code. Kanske...

Så har jag uppfattat det hela, efter att ha följt ledningsbanorna på kretskortet.
(Jag antar att du menar 0L + 0U?)

Jag måste ha fått funktionen på sådana här minnen helt om bakfoten.
Minnena har ju 10st adressledningar, det borde ge 1024st unika adresser i varje kapsel.
Varför finns det bara 64st adressrader med i Hexfilerna?

Minnena har ju bara 8 bitar data ut.
Hur kan det ge så långa hexvärden?

[säter]

Om jag förstått allting rätt så kommer checksumman ifrån epromet

Jag är ju rudis på detta, men jag trodde att checksumma var något som Eprom-brännaren lade in i filen.

[sodjan]

> (Jag antar att du menar 0L + 0U?)

Ja, jag blandade ihop "Lower/Upper" och "Low/High"...
Men jag menade i princip samma sak.

> Varför finns det bara 64st adressrader med i Hexfilerna?

Varje rad har 16 bytes. Första raden har från adress 0001 till 000F.
andra raden från 0010 till 001F. O.s.v. o.s.v... 16 x 64 = 1024.
Det är lätt att tro att det står 001, 002, 003 o.s.v. fast det faktiskt
står 0010, 0020, 0030 o.s.v. på varje rad.

> Minnena har ju bara 8 bitar data ut.

Ja.

> Hur kan det ge så långa hexvärden?

Som sagt, 16 bytes (adresser) på varje rad...

> Jag är ju rudis på detta, men jag trodde att checksumma var något som Eprom-brännaren lade in i filen.

Ja, det är det. Det finns *inte* lagrat i minnet utan räknas fram vid läsningen.

[kodar-holger]

Jag har micklat lite på lediga stunder idag och fick nyss ut en första naiv lista. Den borde jag inte visa någon eftersom den förmodligen inte ens tolkar bitarna i rätt ordning. Men jag laddar upp den ändå. Med naiv menar jag att jag pluttat ut argumenten på varje rad, oavsett om det är en instruktion som borde bry sig eller ej. Dessutom har jag läst vad säter skrivit att varje 16-bitarsord består av 4 bitar instruktion, 11 bitar adress och en bit checksumma. Jag får inte ihop 11 bitar med adressering av 4096 ord minne. Måste kolla avritad hårdvara.
Om man kollar en binärdump ser man också en del text i promarna. En bra disassembler hittar sånt genom att följa exekveringsvägar. Så det är andra argumentet för varför detta är en naiv lista. Exakt allt är tolkat som instruktioner.

Felaktig lista raderad. 17 nedladdningar

Nu är helgen slut och jag kommer nog inte få så många stunder närmsta två veckorna att pilla med detta. Jag började med en liten disassembler som gjorde listan ovan. Den är jag ännu mindre stolt över än listan i sig så den borde jag verkligen inte publicera. Men det gör jag ändå ifall nån vill städa och göra egna försök. Kommentarer på usel kodstruktur undanbedes vänligt men bestämt.

Gammalt program raderat. 12 nedladdningar.

Angående hex-filerna.
Varje rad innehåller informationen från 16 på varandra följande positioner i minnet.
64*16 = 1024.

Jag har långledigt i jul. Kanske kan pilla mer med detta då om ingen annan löst det före dess. När bättre output dyker upp kommer jag radera skräpet i detta inlägg.

[sodjan]

Jag vill rätta en tidigare skrivning som kan vara förvillande...

> Jag antar att varje par av prom (t.ex 0L + 0H) ger ett helt 16 bits
> ord som sedan kan vara 12 bitar adress + 4 bitar op-code. Kanske...

Bör vara:

> Jag antar att varje par av prom (t.ex 0L + 0H) ger ett helt 16 bits
> ord som sedan kan vara 12 bitar data + 4 bitar op-code. Kanske...

Processorn har ingen inbyggd programräknare utan den ligger separat i form
av vanliga binärräknare. Denna kan "ställas" till ett värde genom att "data"
från den aktuella adressen läses in i räknaren om op-code är = "JMP".
"JMP" triggar en speciell pinne på processorn som då används som
"set" signal till programräknaren... Väldigt "basic"...

Som kuriosa har jag för mig att jag en gång byggde något från Elektor
som var baserat på denna processor...

[sodjan]

Tjusigt Holger! Ett Ada program...
Jag får väl ta och skriva något i Cobol...

[säter]

Tusen tack för engagemanget Holger.

Dessutom har jag läst vad säter skrivit att varje 16-bitarsord består av 4 bitar instruktion, 11 bitar adress och en bit checksumma. Jag får inte ihop 11 bitar med adressering av 4096 ord minne

Blir det inte så här, när den 12'e biten "stjäls" till paritet, då kan man bara nyttja 2048 ord?

Hur fungerar det med paritet?
Är det liknande som på en hålremsa, så att man summerar alla bitar och är summan udda, då lägger man till en paritetsbit?

[säter]

Som kuriosa har jag för mig att jag en gång byggde något från Elektor
som var baserat på denna processor...

Ja men perfekt.
Du uttryckte dig lite annorlunda tidigare.

Jag kan själv inget
om MC14500B, vilket ju skulle underlätta...

[säter]

Om man kollar en binärdump ser man också en del text i promarna

Har du möjlighet att ladda upp denna binärdump, så att man kan läsa texten?

[sodjan]

> Du uttryckte dig lite annorlunda tidigare.

Ja, men det är ju ingen motsägelse *idag*...
Det jag vet just nu, kommer från dokumenten som
det har länkats till här i tråden. Jag minns inget från
Elektor projektet, sannolikt på 70-talet...