Disassemblering av program till PLC

[exile]

Det finns fler knepigheter om man titta på statistiken som jag har genererat, om vi antar adresserna 1024-2047 är ram så finns det platser som enbart skrivs till
exempel 1128 till 1136.
Givet vis kan det vara för fel sökning mm (delvis flippa dips och läs av ram leden)

men på några ställen läs "ramet" utan att någonsin skrivas till vilket är märkligare
exempel:
1668,1866,1867 (eller är det några bugar?)

eller kan man garantera att ramet alltid tomt när man startar?

Givet vis kan mitt antagande vara fel att ramet sitter på helt andra adresser men i så fall vart?

[säter]

Intressant att ResultRegister har en egen lysdiod.

2012_12220312.JPG

[kodar-holger]

Nu sitter det ju något över fönstren på promarna, men jag skulle akta mig väldigt noga för att slå blixten rakt på så där. Sätt gärna på något helt ogenomskinligt också utöver det som redan sitter.

Att Result Register har egen led är nog lite en följd av att det är enkelt eftersom den finns direkt tillgänglig ut från ICUn. Säkert bra att ha vid enkelstegning också.

Att ta reda på vart RAM och I/O finns verkar logiskt nu. För att sälla mig till alla troende här så inbillar jag mig att enklast är att söka i riktining från ramet efter en signal som troligen heter /CS. Borde vara ansluten till en avkodare, typ en 74138 eller något sånt.

När du listar in och ut-signaler får du gärna göra det i någon form av kalkylprogram där du skriver en signal per rad. Och funktion (in/ut) i en egen cell. Då blir den lättare att fixa till något maskinläsbart format för att stödja våra olika disassemblers.

[säter]

Sätt gärna på något helt ogenomskinligt också utöver det som redan sitter.

På de nya, klonade, Epromen klistrade jag dit maskeringstejp.
Duger det?

Att Result Register har egen led är nog lite en följd av att det är enkelt eftersom den finns direkt tillgänglig ut från ICUn. Säkert bra att ha vid enkelstegning också.

Jag ska undersöka lite närmare om det kan finnas möjlighet att enkelsteppa.

När du listar in och ut-signaler får du gärna göra det i någon form av kalkylprogram där du skriver en signal per rad. Och funktion (in/ut) i en egen cell. Då blir den lättare att fixa till något maskinläsbart format för att stödja våra olika disassemblers.

Ok, så en vanlig texteditor duger inte?
Några tips på något enkelt program annars?

[säter]

Att ta reda på vart RAM och I/O finns verkar logiskt nu. För att sälla mig till alla troende här så inbillar jag mig att enklast är att söka i riktining från ramet efter en signal som troligen heter /CS. Borde vara ansluten till en avkodare, typ en 74138 eller något sånt.

Saxat från den gamla tråden.

Däremot har det skett lite framsteg med adressledningarna till RAM-minnet.
Som ni ser på ritningen så kommer dessa 10st ledningar från utgångarna på 3st Multiplexers.

Adresspinne A0-A9 på RAM-minnet motsvaras av I/O-ledning 0-9. (samma som lysdioderna)

Ingångarna (B) på Muxarna är anslutna till I/O-ledningarnas Bussdrivare.
Ingångarna (A) på Muxarna är anslutna till 5V via 10st DIP-switchar.
Man kan alltså switcha mellan aktuell I/O-adress och den fasta adress som DIP-switcharna är ställda på?
Utgångarna från Muxarna (Y) är inverterande och bär av till RAM-minnet.

Varför i hela friden har man inverterat adressen till RAM-minnet?
För att allt ska bli så bakvänt som möjligt eller?

I/O-ledning (10), den enda lediga som återstår, verkar vara kopplad till Select A/B på Muxarna.
Det måste vara den adressledningen som väljer om I/O-bussen eller DIP-swicharna ska kopplas in till RAM?

Varför har man lagt ner så mycket jobb för att kunna switcha till en fast adress i RAM-minnet?
Det övergår mitt förstånd.

Ram.PDF

[kodar-holger]

Har tittat igenom dina ritningar från gamla tråden. Intressant.

Du skrev om ENT i räknarna. Jag tror helt enkelt att RCO på "första" räknaren är kopplat till både ENP och ENT på andra, och sen är ju alla ENP hopkopplade medan RCO går till nästföljande ENT. ENP = Enable Parallel, ENT = Enable Tricke. Det var så man skulle koppla om jag inte minns fel från digitalteknikkursen 1987....

Man har nog inte inverterat adresserna till RAMet med flit utan det är bara så '158 chippen funkar. Och eftersom man alltid gör lika spelar det ingen roll. Kan hålla med om att kopplingen med dip-switcharna är lite lurig. Men vi kanske får en förklaring så småningom.

I räknardiagrammet ser man load och clear dra iväg. Dom är intressanta. Jag misstänker att clear går till reset och load till FLGF (pinne 9) på ICUn. Mycket troligt via några buffrar för enligt datablatet har MC14500 inte så mycket drivförmåga mot TTL-chip.

Angående seriekopplade buffrar kan det varit ett sätt att skapa en fördröjning.

Finns det något i dokumentationen om alternativa inställningar på dip-switcharna som styr räknarnas startadress?

Texteditor duger om du har väldig diciplin. Tänkte det kunde vara enkelt att få bättre ordning i typ Excel eller OpenOffice Calc. Bättre med dokumentation som man får mickla med än ingen alls.

[bearing]

Handbok på tyska:
http://wdr-1-bit-computer.talentraspel.de/index.html

På samma webbplats finns en simulator
http://wdr-1-bit-computer.talentraspel. ... m-pc_.html

Den är skriven 1989 i turbo-pascal. Fungerar fint på min XP-dator.

Dock finns bara 7 I/O i den här simulatorn. 1-4 är utgångar resp. ingångar. Utgångarna 5-7 är ihopkopplade med ingångarna 5-7, vilket ger 3 st register/RAM att jobba med i simulatorn. Källkoden finns. Kanske något att utgå ifrån om en mer avancerad simulator ska skrivas.

Jag har simulerat första raderna i säters program, men bytt ut adresserna för att kunna köra i simulatorn.

Kod: Markera allt

ORC   0
IEN   0
OEN   0
LD    2
STO   7
XNOR  6
OEN   0
LD    7
STO   3
XNOR  0
OEN   0
LD    7
STO   6
JMP   0

Här använder jag adress 7 som adress 1/temp, 6 som adress 1152, 3 som adress 1024, och 2 som adress 256. Programmet fungerar som jag trodde förutsatt att adress 1 är ett temp-register i säters system.

Går att singelstega genom programmet och se vad som händer med RR (ER på tyska), D, utgångar/ingångar, m.m.

(Stjärna (*) betyder etta, för att likna en tänd lysdiod.)

[säter]

Jag tror helt enkelt att RCO på "första" räknaren är kopplat till både ENP och ENT på andra

Det kan mycket väl vara en ledningsbana på framsidan mellan ENP och ENT på krets nr:2.
Den är i sådana fall helt dolt under kretsen, och omöjligt att se på fotot.

[säter]

Texteditor duger om du har väldig diciplin.

Till en början har jag skrivit en enkel textfil med in- och utgångskortens funktioner listade.
Det är inte så många funktioner faktiskt.
Jag antar att en del inte ens har några villkor, utan går direkt vidare till en utgång.

Det är 4st ingångskort med 32st funktioner på varje.
Motsvarande är det 3st utgångskort med 32st funktioner på varje.

Ställ gärna frågor om funktionsbeskrivningarna, så hjälper jag till att gissa.

NIIGATA-PLC.txt

[säter]

I räknardiagrammet ser man load och clear dra iväg. Dom är intressanta. Jag misstänker att clear går till reset och load till FLGF (pinne 9) på ICUn

LOAD kommer från utgången på en NOR-grind.
Den ena ingången på NOR-grinden kommer direkt från JMP på processorn.
Den andra ingången på NOR-grinden kommer från en inverterare, som har ingången oansluten.
Jag tycker det verkar mysko, och lämnar det tillsvidare.

Det verkar som att RTN och FLGF på processorn är oanslutna.
Med reservation för felgissning.

[bearing]

Vilken adress får I/O?

[bearing]

men på några ställen läs "ramet" utan att någonsin skrivas till vilket är märkligare
exempel:
1668,1866,1867 (eller är det några bugar?)

Kan ju vara buggar, dom kanske bara påverkar oanslutna utgångar, d.v.s har därför aldrig upptäckts.

Vad betyder IEN 1024?
D.v.s vad har argumentet för funktion?
Kan det också vara en bugg?

[exile]

Texteditor duger om du har väldig diciplin.

Till en början har jag skrivit en enkel textfil med in- och utgångskortens funktioner listade.
Det är inte så många funktioner faktiskt.
Jag antar att en del inte ens har några villkor, utan går direkt vidare till en utgång.

Det är 4st ingångskort med 32st funktioner på varje.
Motsvarande är det 3st utgångskort med 32st funktioner på varje.

Ställ gärna frågor om funktionsbeskrivningarna, så hjälper jag till att gissa.

NIIGATA-PLC.txt

Om jag antar att jag har gissat rätt I/O så bör det bli följande.
N1 har 256-287
N2 har 288-319
N3 har 320-351
N4 har 352-383

T1 har 256-287
T2 har 288-319
T3 har 320-351

kolla man på min "statestik" på t2 verkar det passa ganska bra

Kod: Markera allt

Adr	rd	wr	No	use
288	1	0	1
289	1	0	2
290	1	0	3
291	1	1	4	MAGAZINE INDEX CW COMMAND
292	1	1	5	MAGAZINE INDEX (C)?CW COMMAND
293	1	1	6	MAGAZINE RAPIDLY
294	1	1	7	NC POWER OFF
295	1	1	8	BRAKER OFF
296	1	1	9	OIL HOLE COOLANT
297	1	1	10	SHUTTER OPEN COMMAND
298	1	1	11	SHUTTER CLOSE COMMAND
299	1	1	12	CARRIER QUICK START
300	1	1	13	X-B APC POS. 
301	1	1	14	PALLET READY
302	1	1	15	PALLET CLAMP
303	1	0	16
304	1	1	17	IN CYCLE
305	1	0	18
306	1	0	19
307	1	0	20
308	1	0	21
309	1	0	22
310	1	1	23	M FUNCTION
311	1	1	24	DGN 1 
312	1	1	25	DGN 2
313	1	1	26	DGN 4
314	1	1	27	DGN 8
315	1	1	28	DGN 10
316	1	1	29	DGN 20
317	1	1	30	DGN 40
318	1	1	31	DGN 80
319	1	0	32

För mig känn det den mest naturliga planeringen med den informationen som jag har för till fället
T3 verkar oxå stäma bra.
Det enda som inte verkar stämma är T1 READY ON finns inte skrivet till om man antar min tolkning av adresserna...

[exile]

men på några ställen läs "ramet" utan att någonsin skrivas till vilket är märkligare
exempel:
1668,1866,1867 (eller är det några bugar?)

Kan ju vara buggar, dom kanske bara påverkar oanslutna utgångar, d.v.s har därför aldrig upptäckts.

Vad betyder IEN 1024?
D.v.s vad har argumentet för funktion?
Kan det också vara en bugg?

Kan vara men det kan även vara en form av reset av "mjukvaran" delvis vet man vad alla ingångar är om ien är "av" på så set kan man sätta minnet i ett känt läge. (om man har gjort mjukvara räknare mm) men det är lite av spekulation

Det skulle även stämma bra om man kolla på den första raderna av koden,
Delvis att 256 är ingången READY på N1 kortet som med en annan variabel påverkar 1024 (som antags vara en "reset" signal)

Eller så är jag ute och cyklar

[exile]

Kan hålla med om att kopplingen med dip-switcharna är lite lurig. Men vi kanske får en förklaring så småningom.

Det jag har funderat på om det är någon form av realtids debugning, delvis kan man välja valfri adress och se vilket tillstånd den har. Det skulle även förklara varför A10 går till muxen.
Givet vis en gissning.

Edit: skriver som kratta