Celé vlákno · 4 zprávy

Ahoj,

zkoumam dnes trochu podrobneji PIO. Zdrojak na hrani je v priloze, nicmene tam neni zadna vizualizace chovani - vysledky pozoruju analyzerem.

Vsimnul jsem si zajimave veci:

Branu A nastavim do MODE3 a povolim ji generovani interruptu - je celkem jedno, jak pritom nastavim IO masku pro vstupy a vystupy, jake podminky LOW, HIGH), nebo jakou nastavim vstupni masku - pro vygenerovani popisovaneho ukazu muzu klidne ponechat vsechny piny v OUT rezimu a v maskou pro generovani interruptu je navic uplne vypnout, avsak podminku AND/OR musim vzdy nastavit jako "OR".

Nyni na CTRL port brany A poslu zmenu mode na kterykoliv jiny modus, nez je MODE3, napr. 0x0f - vystup bajtu. V momente, kdy to udelam, tak mi PIO posle signal /INT ... Dokonce i kdyz brane A pred zmenou modu nejprve zakazu generovani interruptu, pak zmenim na MODE0 a pak povolim interrupt (0x03, 0x0f, 0x83), tak i v takovem pripade posle PIO do Z80 pozadavek na falesny interrupt...

Kdyz jsem zkusil tento pokus na brane B (BTW: jeji I/O piny jsou pripojeny na invertory a pri nastaveni B jako vstupu je na nich trvale k videni log1), tak se to takhle nechova.

O to zajimavejsi mi prijde fakt, ze v MODE 0, 1 a 2 ma byt interrupt generovan pouze aktivaci vstupniho signalu /STROBE, ktery je u brany A pripojen natvrdo na Vcc, takze k jeho aktivaci spravne nikdy dojit nemuze.

Podle schematu zapojeni PIO-Z80 v MZ-800 mne nenapada zadny duvod proc by se to takhle melo chovat, pokud neobjevite zadnou pricinu ani vy, tak se asi bude jednat o nejakou mouchu v samotnem pijovi.

Jinak u Zdenka jsem tohle chovani nezkoumal, ale divil bych se, kdyby tam nejakou takovouto zaludnost mel implementovanu.

Pokud by jste si chteli s testovacim programkem pohrat a aktivovat interrupt pomoci rutinek ctc0_out0 a ctc0_out1, tak u Zdenka s rtim neuspejete. V mem soucasnem emu to sice funguje, nicmene ne uplne spravne, protoze tam prvni udalost pro int ignoruju, coz neni uplne shodne s tim, jak se chova Sharp.

Jeste dalsi zajimava vec, ktere jsem si vsimnul te to, ze pokud nastavim branu A jako vstupni, tak PA0 a PA1 se mi jevi byt trvale v log1, PA6 a PA7 mi vetsinou sdelovaly stav log0, nicmene na PA6 se mi obcas na nejakou dobu objevila i log1 (je to opet vstup do hradla, ktere je ovladano SW2 na zadni strane MZ800). Mel jsem tam chvili pripojeny i osciloskop a skutecne se tam ta uroven napeti obcas trochu zvedla v zavislosti na tom, jak jsem menil I/O a MODE ... bylo to vsak sotva na hranici pro log1 - to uz je ale asi ducharina, kterou se nema smysl pri emulaci zabyvat.

Michal

Tak dalsi zajimava vec ze sveta PIO:

Brana A je v MODE3, 4. bit (invertovany CTC0) je vstupni, podminkou pro 
INT je nastavena udalost, kdy na pinu bude log0. V CTC0 jsem nastavil 
output tak, aby bylo na vstupu do PIO log1 - k alarmu tedy nemuze dojit.

Nyni vsak muzu pijovi rict, ze znovu nastavuju branu do MODE3, ale ze 4. 
bit od ted chci mit vystupni. Z pinu tedy vyleze ven hodnota, ktera byla 
predtim vlozena do nezavisleho data output registru (po resetu se tam 
ulozi 0x00) - pokud je v output registru na 4. bitu uroven 0, tak dojde 
k poklesu napeti a PIO posle do Z80 /INT, coz znamena, ze umi vyprudit 
samo sebe.

Jinak jeste zajimavost, kterou jsem nevedel jiste, protoze ve starsim DS 
se o tom nepsalo a v novejsim jsem to prehledl: PIO nema pripojen signal 
RESET nicmene jej zrejme umi identifikovat sledovanim stavu /M1, /RD, 
/IORQ a CPUCLK. Pri psani emulatoru jsem tusil, ze se PIO resetuje, ale 
nevedel jsem jaky je jeho vychozi stav. Ted uz napr. vim, ze interrupt 
vector by mel zustat zachovan i po resetu.

Michal

Ahoj Michale

Ten Z80 PIO nema vyvedeny Reset protoze na to uz neni volny pin. Jen 
PLCC pouzdro ma primo vyvedeny Reset. Jinak se pouziva stejne hradlo 
jako  v Sharp MZ800, konktretne 74ls08.

Pekny dokument je 
http://smithsonianchips.si.edu/ice/OCR_ScanPE125/PE125(10379-K).pdf a 
tam by jsi se mohl inspirovat jak je to uvnitr zapojene. Je to sice jiny 
obvod (Z80-CTC) ale ze stejne serie a tak INT bude podobne zapojeny. 
Dalsi pekny dokument je http://smithsonianchips.si.edu/ice/s3.htm a nebo 
http://sirismm.si.edu/EADpdfs/NMAH.AC.0600.pdf. Chtelo by to zajet do 
toho muzea a tam v klidu si to precist.

Preji pekny vecer

Radek

Dne 23.01.2017 v 8:56 Michal Hucik - ORDOZ napsal(a):

> Tak dalsi zajimava vec ze sveta PIO:
>
> Brana A je v MODE3, 4. bit (invertovany CTC0) je vstupni, podminkou pro
> INT je nastavena udalost, kdy na pinu bude log0. V CTC0 jsem nastavil
> output tak, aby bylo na vstupu do PIO log1 - k alarmu tedy nemuze dojit.
>
> Nyni vsak muzu pijovi rict, ze znovu nastavuju branu do MODE3, ale ze 4.
> bit od ted chci mit vystupni. Z pinu tedy vyleze ven hodnota, ktera byla
> predtim vlozena do nezavisleho data output registru (po resetu se tam
> ulozi 0x00) - pokud je v output registru na 4. bitu uroven 0, tak dojde
> k poklesu napeti a PIO posle do Z80 /INT, coz znamena, ze umi vyprudit
> samo sebe.
>
> Jinak jeste zajimavost, kterou jsem nevedel jiste, protoze ve starsim DS
> se o tom nepsalo a v novejsim jsem to prehledl: PIO nema pripojen signal
> RESET nicmene jej zrejme umi identifikovat sledovanim stavu /M1, /RD,
> /IORQ a CPUCLK. Pri psani emulatoru jsem tusil, ze se PIO resetuje, ale
> nevedel jsem jaky je jeho vychozi stav. Ted uz napr. vim, ze interrupt
> vector by mel zustat zachovan i po resetu.
>
> Michal
>
> _______________________________________________
> SharpMZ mailing list
> SharpMZmail.ordoz.com
> http://mail.ordoz.com/mailman/listinfo/sharpmz
>
>

Ahoj,

pokracuji ve zkoumani obvodu. Nyni se metodou hazeni bomb do rybnika 
snazim zjistit co nastane, kdyz se deji veci, ktere se bezne 
nepredpokladaji. Napr. kdyz procesor v IM2 dostane interrupt, nicmene 
PIO v danou chvili zadny cekajici interrupt v zasobe nema, nebo jej sice 
ma, ale je zrovna potlacen.

BTW k potlaceni interruptu muze zrejme dojit alespon dvema zpusoby:

1) klasicky nastavenim disable interrupt (0x03) - tohle ovsem neni ani 
tak zakazani interruptu, ale spise jeho zneviditelneni. Pokud se v dobe, 
kdy je nastaveno "disable" odehraje nejaka udalost, ktera je schopna 
vyvolat interrupt, tak jej PIO ve sve interni logice normalne zpracuje a 
port prejde do specialniho stavu "interrupt pending" ze ktereho uz jej 
nedostane nic jineho, nez to, ze dojde ke zviditelneni cekajiciho 
interruptu (0x83) a pak musi nasledovat jeho prevzeti procesorem, ktery 
to na sbernici oznami aktivaci signalu /M1 + /IORQ. Dalsi moznosti jak 
se v PIO zbavit cekajiciho interruptu je 4. bit v ICRW viz bod 2, nebo 
HW reset procesoru, ktery si PIO umi identifikovat.


2) zapsanim Interrupt Control Word ( xxxx 0111 ) ve kterem je 4. bit 
nastaven "1" - tim dojde k okamzitemu smazani pripadneho cekajiciho 
interruptu. Nasledne se ceka na zapis masky, dokud ji nezapiseme, tak se 
PIO ke vsem udalostem chova jako mrtvy brouk a interrupt nikdy 
nezaeviduje. Ve chvili kdy zapiseme masku (treba i stejnou jaka byla 
predtim), tak se provede inicializace stavu - nazveme to treba interrupt 
state scan. Tento scan se provadi rovnez pri inicializaci MODE3 ve 
chvili, kdy vlozime bajt s I/O maskou a take ve chvili, kdy CPU prevezme 
interrupt, uz neni aktivni /INT, ale je aktivni /IEO, tzn.,  ze CPU 
prave zacalo vykonavat rutinu interruptu a jeste se na sbernici 
neobjevilo RETI.

Zadnym jinym zpusobem se jiz cekajiciho interruptu nezbavite. Nepomuze 
ani zmena stavu na sledovanych bitech/pinech. Ani zmena mode. Ani zmena 
interrupt function, ci urovne LOW/HIGH.

Dalsi zajimavost: pokud je interrupt function "OR" a maska je nastavena 
sledovani stavu vice nez jednoho bitu/pinu, tak PIO musi vzdy na vsech 
techto pinech nejprve zaregistrovat uplny klidovy stav. Do te doby, nez 
k nemu dojde, tak zadna zmenova udalost na pinech nevyvola interrupt.

Napr.:

1) nastavime ICRW: IENABLE, OR, HIGH, MASK => 10110111 => 0xb7
2) ocekava se maska - nastavme citlivost na dolni 4 bity: 0xf0

Dejme tomu, ze ve chvili, kdy byla vlozena maska, tak na stupnich pinech 
nebylo nic "0000" - klidovy stav.

1) Dojde k nejake zmene "0001" a ta vyvola interrupt - PIO je ve stavu 
interrupt pending a zadne dalsi zmeny na pinech jej nezajimaji.
2) CPU prevezme interrupt - provede se scan stavu "0001"
3) V dobe kdy jeste neprislo RETI nastane dalsi zmena "0000" a za ni 
bude nasledovat treba "0010" - PIO prejde do stavu, ktery je podobny 
tomu "interrupt pending" s potlacenym int.
4) Ve chvili, kdy prijde RETI, tak PIO prejde do viditelneho "interrupt 
pending"... pomerne castou praktikou je zakoncovat rutinu sequenci EI, 
RETI a tak vlastne okamzite po RETI nasleduje opetovny skok na zacatek 
prerusovaci rutiny - pokud se to opakuje, tak se vlastne vubec 
nevykonava program, ale jen interrupti rutina (par takto fungujicich 
programu jsem na Sharpu videl)

Ovsem muze byt i takovyto vyvoj:

1) Dojde k nejake zmene z "0000" na "0001" a ta vyvola interrupt, ktery 
je procesorem prijat
2) V dobe kdy jeste neprislo RETI nastane dalsi zmena "0011" a treba "1010"
3) Ve chvili, kdy prijde RETI, tak PIO prejde do rezimu, kdy stale ceka 
na klidovy stav a urovne na sledovanych pinech mohou divocit jak chteji, 
dokud nenastane "0000", tak tohle radeni zadny dalsi interrupt nevyvola


Jak uz jsem na zacatku psal, tak se nyni snazim vyzkoumat neco ohledne 
zpracovani IM2 callbacku, ktery nema z pohledu PIO opodstatneni. V 
priloze je testovaci zdrojak, kterym si nejprve nastavim CTC, i8255 a 
PIOZ80. Nasledne jsem schopen zavolat interrupt iniciovany od CTC2, nebo 
kteroukoliv z bran A/B v PIOZ80.

Pokud je procesor v IM2 a vygeneruju interrupt z CTC2, tak se na 
sbernici ocekava LSB cast interrupt vektoru na kterem je ulozena adresa 
prerusovaci rutiny.
Pole s vektory jsem si ulozil od adresy 0x3000. Jeho rozptyl jde od 0x00 
- 0x100. Kdyz mam popsano cele pole vektoru hodnotou 0x00, tak musi IM2 
interrupt vykonat vzdy CALL 0x0000. Na teto adrese mam kod pro nastaveni 
modreho borderu a zastaveni programu.
Postupnym repisovanim obsahu v poli vektoru jsem zjistil, ze takto 
ziskany LSB je sice nejake hausnumero, NICMENE jak se zda, tak pro danou 
konfiguraci je toto ziskane cislo vzdy konstantni, coz mi prijde zajimave.
V kodu, ktery je v priloze je to hodnota 0x20, coz zpusobi, ze propgram 
konci s cervenym borderem. Prozatim jeste nevim jaky hazard tuto 
magickou hodnotu zpusobuje - vzpomente treba na magickou hodnotu 
posledniho bajtu, kterou prectete z datovky, kdyz se pokusite cist z 
nepripojeneho portu. Cislo v ziskane LSB se zmeni, kdyz realokuju cely 
program, ci zmenim nastaveni PIO. Parkrat se mi stalo, ze jsem obdrzel 
hodnotu, ktera odpovidala vectoru z brany A - mohlo se jednat i o 
nahodu, nicmene ted mne napada, ze tohle budu umet lehce proverit.

Pri experimentovani s polem vektoru a s takto nahodne ziskanym LSB se 
muze stat samozrejme i to, ze se strefi jen jeden bajt z vektoru, 
program se nekam vykoleji, nicmene nejakym zazrakem se dostane k rutine 
se zmenou barvy borderu. K odhaleni takoveho stavu mam na zacatku 
programu cca 10s wait s cernymi pruhy v borderu. V tech 10s si zapnu 
analyzer, ktery mi pak ukaze co se delo, kdyz prisel interrupt. Pokud se 
vykonalo jen par instukci a pak prislo /IORQ (border: 0x06cf) a HALT, 
ktery je lehce identifikovatelny, tak sel program spravnou cestou. Pokud 
vsak vidim, ze po prijeti INT se na sbernici vykonavalo more ruznych 
instrukci, tak to znamena, ze se vektor strefil jen do jednoho bajtu a 
program se vykolejil.

Pokud se vam bude chtit, tak vyzkousejte na Sharpu prilozeny MZF, 
pripadne si s pasmo nakompilujte vlastni. Pokud vam program skonci s 
cervernym borderem, tak je pravdepodobne, ze se u vas choval stejne jako 
u mne (pripadne ze se jen sikovnym zpusobem vykolejil :)

Michal