Svenska ElektronikForumet

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

kodar-holger skrev: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.

exile skrev: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

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

bool temp;

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

bearing skrev: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 skrev: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.

bearing skrev: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.

En liten del kan ha varit batterimatat...

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

säter skrev:

bearing skrev: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?