Adresové cykly u klasické '51

Pavel Troller patrol na sinus.cz
Neděle Červen 21 19:26:52 CEST 2015


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


Daląí informace o konferenci Hw-list