Adresové cykly u klasické '51

Pavel Troller patrol na sinus.cz
Pondělí Červen 22 06:23:17 CEST 2015 

Zdravim,
  je to mincovni telefonni automat :-).
    Pavel

> 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
>>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list

Daląí informace o konferenci Hw-list