Adresové cykly u klasické '51

[Michal Gregor]

Tohle jsem nekde uz videl.
Co to je za pristroj?

Michal Gregor


Dne 21.6.2015 v 19:26 Pavel Troller napsal(a):
> Zdravim,
>    dekuji za detailni rozbor a analyzu.
>    Mne nejde ani tak o to to udelat, mne jde o to usoudit, zda v leta
> hotovem reseni neco takoveho nahodou neni uz udelano. A zda se, ze asi
> ne, protoze by to bylo hodne narocne a tak moc slozity ten hardware
> zase neni (ikdyz na '51 system je slozity az beda :-) ).
>    To zarizeni ma v zasade 2 rezimy. Budto jede z ROM, nebo z RAM. RAM
> je zalohovana a po zapnuti napajeni se spusti program z ROM, zkontroluje
> (pomoci MOVX), zda v RAM je platny image a pokud ano, kamsi cosi zapise
> (je tam neco jako externe udelany strankovaci registr) a tim prepne na
> dalsi vykonavani programu z RAM. Kdyz chce ten program cist i nadale
> data, stale pouziva MOVX, jako by jel z ROM.
>    Situaci komplikuje to, ze v zarizeni je zasuvka, do ktere se da pripojit
> "diagnosticky modul". Ten muze obsahovat taky pamet (ROM) a pokud ji
> obsahuje a uzivatel si to preje (zvoli patricnou diagnostickou funkci),
> zarizeni provede upgrade image v RAM z pameti v tom modulu. Z modulu se
> cte pomoci MOVC, do RAM se zapisuje pomoci MOVX (MOVC ani zapisovat neumi).
> Za pozornost stoji, ze v urcite fazi upgrade ta upgradovaci rutina
> upgraduje postupne i sama sebe - sama lezi v tom upgradovanem prostoru.
>    Je pravdou, ze pred startem te rutiny opet cosi zapisou do te strankovaci
> logiky podobne, jako kdyz prepinaji z ROM na RAM (vedou do ni asi 4 bity,
> umi i zakazat zapis do podstatne casti RAM, pokud se prave neupgraduje),
> ale strukturu toho strankovaciho obvodu neznam. Zajimalo mne tedy, odkud
> se vlastne vykonava behem toho upgrade ten program. Zda z RAM, nebo z ROM
> v tom modulu. Ze zakladni ROM to urcite neni, ta neni tak velka a adresy,
> kde je ta upgradovaci rutina, vubec neobsahuje. Ta upgradovaci rutina v
> RAM je, ale nejspis tedy z RAM nebezi, a patrne se bude muset kryt
> mimimalne jeji pocatecni adresa v RAM a v te upgradovaci ROM, jinak by se
> behem prepnuti z RAM do ROM modulu tim zapisem do strankovaciho registru
> program zabehl.
>    Po skonceni upgrade strankovaci logiku zresetuji a skoci do hlavni ROM,
> ktera zkontroluje, zda je novy image platny a pokud ano, tak ho normalne
> spusti.
>    Toz na vysvetlnenou, proc mne to zajimalo...
>      Zdravi Pavel
>
>> Takto prvoplanovo sa dekodovat fetch prvej instrukcie u '51 neda. U
>> niektorych klonov (Philips/NXP, SST/Microchip, Dallas) by sa dal ziskat
>> vnutorny stav pomocou nezverejnenych rozsireni ktore su tam kvoli
>> debuggingu, ale ako vravim, su nezverejnene t.j. by sa museli reverznut
>> alebo z niekoho znaleho (co ja nie som) vymlatit.
>>
>> Mozno by sa dalo vyuzit aj instrukcia vzdy fetchuje dvakrat v instrukcnom
>> cykle (kazdych 6 hodinovych cyklov u klasickej 12-clock '51), a u
>> jednobytovych instrukcii sa v druhom fetchi neinkrementuje adresa. No
>> lenze podobne je to u trojbytovych instrukcii, ale tam samozrejme je to
>> este viac ex-post-ovitejsie ;-), a tiez u dvojbytovych - dvojcyklovych; no
>> proste by si bolo treba nakreslit vsetky kombinacie a vsetky moznosti
>> inkrementu adries a skusit odhadnut, ci sa z toho da unikatne to MOVC
>> dekodovat. Inak ani inkrement adresy nie je trivialne dekodovat, bo to
>> kazia skoky...
>>
>> Mimochodom, MOVC nie je jedna instrukcia ale dve - ani ten komparator
>> instrukcie by nebol uplne trivialny najma ak nie je poruke '688...
>>
>> wek
>>
>>
>>
>>>   ano, jistě, to mne také napadlo. Ale myslím, ľe úplný dekodér instrukcí,
>>> který by na to byl potřeba, tam není. Ono by to ąlo snáze, pokud by '51
>>> měla signál M1 jako třeba Z80, ale ten pokud vím nemá a není asi snadné
>>> ho dekódovat.
>>>   "Chytrostí" se zde rozumí jen běľné obvody maximálně úrovně MSI. Nic
>>> programovatelného. Jde o design z 80. let minulého století, kdy to CPU
>>> byla asi největąí "chytrost", která v tom je.
>>>   Taky se kloním k závěru, ľe to asi bez "extrémní chytrosti" nejde a tedy
>>> ľe pokud chci přistupovat k určité paměti, ze které chci brát instrukcí
>>> MOVC data, tak v ní musím ten program skutečně vykonávat (samozřejmě
>>> pominu-li moľnost např. na adrese 1000H mít vybraný jeden čip a na adrese
>>> F000H jiný, ale to je jaksi normání způsob a nesouvisí to s tímto dotazem).
>>>
>>> Zdraví Pavel
>>>
>>>> "Chytrost" to je co? Programovatelná logika?
>>>>
>>>> Napada mne dekodovat instrukce a pokud se detekuje instrukce MOVC A, na A+DPTR
>>>> tak v dalsim cyklu to prepnout na jinou pamet.
>>>>
>>>> Ale bude to mazec - nektere instrukce maji jeden byte jine vice.
>>>>
>>>>
>>>> Michal Gregor
>>>>
>>>>
>>>>
>>>>
>>>> Dne 20.6.2015 v 12:08 Pavel Troller napsal(a):
>>>>> Zdravím,
>>>>>     analyzuji tu nějaký kód klasické '51 a potřeboval bych vědět jeden HW
>>>>> detail, který teď přesně nevím:
>>>>>     Lze rozpoznat čtecí cyklus při vykonávání instrukce MOVC A, na A+DPTR
>>>>> od běľného čtení kódu (instruction fetch) ?
>>>>>     Zajímá mne, zda lze při pouľití nějaké přídavné chytrosti v adresovém
>>>>> dekodéru specificky tento cyklus rozpoznat a poslat na sběrnici data z
>>>>> jiné paměti, neľ je ta, z níľ se aktuálně vykonává program.
>>>>>     Samozřejmě znám instrukce MOVX, které přistupují k externí RAM, ale
>>>>> zde by ąlo o jeątě jiný, daląí paralelní adresový prostor.
>>>>>
>>>>> Zdraví Pavel
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>