Disassemblering av program till PLC

[säter]

Det verkar vara jämn paritet. D.v.s. med checkbit inräknad är det ett jämnt antal ettor.

Perfekt.
Det var just det jag ville kolla upp med binärkoden.

Om vi räknar prom-parens bitar som 0-15 vilket är ganska normalt i branchen där bit 0-7 ligger i 0l, 1l ... och 8-15 i 0h, 1h... så:
Bit 11 är checksummebit
bit 12-15 instruktioner i "rätt" ordning. D.v.s. bit 12 går till I0 på ICUn 13 till I1 o.s.v. Det borde betyda att avkodade instruktioner i min lista är rätt.

Vad bra.
Då har jag nog fattat rätt.

Vad blir nästa steg?
Klura ut adresserna till RAM-minnet?

Jag ska även göra en lista på alla ingång- och utgångsfunktioner på maskinen.

[BEEP]

_

[säter]

BEEP, det vore bra om du kommenterade det du postar.

[lillahuset]

[bearing]

Ja, inte ens av filnamnen kan man lista ut något, då de inte uppdateras med varje revision =)
ephf = Epiphany for Forum?

Jag antar att det är nyaste revisionen av upptäckta mönster i hex-filen.

[bearing]

om jag får gissa så tror jag adresserna är uppdelade på följande.
1024 till 2047 är RAM, verkar använda 1024 till 1989 delvis 966 bitar.
256 till 1023 till I/O, som det ser ut så används 256 till 383 delvis 128 I/O (alla kanske inte används i maskinen men finns i programmet)
0-255 diverse saker på "kortet" eller vad man ska kalla det för fasta värden som noll, räknare mm
här verkar följande användas:
0 verka bara läsas? fast värde? används ofta
1 Används flitigt, men till vad, läs & skriver till
3 inte så ofta läs & skriv
4 sällan läs
5 sällan läs
6 sällan läs
7 läs

Gissar att 1 är ett temporärt register.

Första halvan av koden består av många cykler av följande, med början på 256, 1024 och 1152, och med ökande adresser.

Kod: Markera allt

3     LD    256
4     STO   1
5     XNOR  1152
6     OEN   0
7     LD    1
8     STO   1024
9     XNOR  0
10    OEN   0
11    LD    1
12    STO   1152

Vilket betyder följande i "psuedokod", om jag tänker rätt.

Kod: Markera allt

bool temp;

temp = *256;
if (*1152 == temp)
{
  *1024 = temp;
}
*1152 = temp;

Adress 1152 borde alltså inte vara RAM, för då skulle det ju inte vid programstart ha något vettigt värde att jämföra med adress 256.

[BEEP]

"BEEP, det vore bra om du kommenterade det du postar."
Jag försöker få fram mönster genom att lägga in radbrytningar och färgläggning av siffror som återkommer.

[BEEP]

Ja, inte ens av filnamnen kan man lista ut något, då de inte uppdateras med varje revision =)
ephf = Epiphany for Forum?

Jag antar att det är nyaste revisionen av upptäckta mönster i hex-filen.

E Prom Hex File

[säter]

Adress 1152 borde alltså inte vara RAM, för då skulle det ju inte vid programstart ha något vettigt värde att jämföra med adress 256.

Ja, är det inte RAM, så kan det knappast vara något annat än ingångar från I/O-kortet?
Eller?

[Jan Almqvist]

En sak som jag tror mej minnas nu är att i den riktigt gamla PLC:ern fanns det inga numeriska variabler. Skulle man ha någon slags räknare fick man väl bygga den själv? Sida upp och sida ner av kod med liknande utsende...

[exile]

Första halvan av koden består av många cykler av följande, med början på 256, 1024 och 1152, och med ökande adresser.

Kod: Markera allt

3     LD    256
4     STO   1
5     XNOR  1152
6     OEN   0
7     LD    1
8     STO   1024
9     XNOR  0
10    OEN   0
11    LD    1
12    STO   1152

Vilket betyder följande i "psuedokod", om jag tänker rätt.

Kod: Markera allt

bool temp;

temp = *256;
if (*1152 == temp)
{
  *1024 = temp;
}
*1152 = temp;

Adress 1152 borde alltså inte vara RAM, för då skulle det ju inte vid programstart ha något vettigt värde att jämföra med adress 256.

Ja, det verkar lite skumt men vart skulle man annars placera adresserna på ramet? givet vis kanske man inte använder hela utrymme på ramet men det verkar en aningen slösaktigt (ramet är på 1kx1bit om jag inte mins helt fel), och det skulle bli lätt att integrera (delvis lite adress logik). givet vis kan ramet var splitat men varför?



Visst kan adress 1 vara ett temp register men varför inte använda ramet som tempregister? är ramet en valbar möjlighet? (jag menar hur dyrt kan det ha varit på den tiden med 128byte? mindre än 200kr?)

[Jan Almqvist]

En liten del kan ha varit batterimatat...

[säter]

En liten del kan ha varit batterimatat...

Jag har inte sett något batteri på PLC'n.

[bearing]

Ja, det verkar lite skumt men vart skulle man annars placera adresserna på ramet? givet vis kanske man inte använder hela utrymme på ramet men det verkar en aningen slösaktigt (ramet är på 1kx1bit om jag inte mins helt fel), och det skulle bli lätt att integrera (delvis lite adress logik). givet vis kan ramet var splitat men varför?



Visst kan adress 1 vara ett temp register men varför inte använda ramet som tempregister? är ramet en valbar möjlighet? (jag menar hur dyrt kan det ha varit på den tiden med 128byte? mindre än 200kr?)

Du har nog rätt, verkar mer troligt att RAM är kontinuerligt.
Om koden körs flera gånger om kommer alla bitar inta samma värde som *256 efter två cykler, men *1024 kommer ha det gamla värdet en cykel. Så om vi antar att programmet loopas kontinuerligt under drift kanske det inte spelar någon roll om det börjar med ett slumpvärde, då det blir "rätt" efter några cykler.

Och ja, det är ju inte säkert att *1 är ett register. I några exempel jag sett har de lägsta adresserna varit ingångar respektive utgångar, och skiljda åt. D.v.s STO 1 skriver till en utgång, LD 1 ger värdet på en ingång. Och utgångarna sitter inte nödvändigtvis ihop med ingångarna. I så fall kan det ju vara något helt annat som händer i den här koden.

[exile]

Adress 1152 borde alltså inte vara RAM, för då skulle det ju inte vid programstart ha något vettigt värde att jämföra med adress 256.

Ja, är det inte RAM, så kan det knappast vara något annat än ingångar från I/O-kortet?
Eller?

Jag säger inte att ditt antagande är fel men ett program som loopar runt hela program slingan varje gång, och verkar sakna start kod för noll minnet. (det skulle även vara ganska dyrt i form av kod efter som man får nolla bit för bit med en egen istruktion)
Så kan det vara att den helt enkelt inte bryr sig vilket läge den är utan "rättar" upp sig efter ett par var, en sådan kod skulle dessutom vara mer tolerant mot störningar.

Men som sagt jag gissa...

Edit: He, för långsam igen bearing han före