Elkezdtem nézegetni hogyan működik a videó memória elérése, Nick - Z80 megosztása.

Elsőként vegyük szemügyre ezen terület kapcsolási rajzát. Mint látható a Nick eleve közvetlenül a dinamikus memória IC-k vezérlésére lett tervezve, önnállóan állítja elő a szükséges RAS, CAS jeleket, valamint a multiplexereket vezérlő MUX jelet is.
Összehasonlításként itt a belső 64K bővítő rajza, amelyen látható a DRAM-ok Z80-hoz illesztéséhez további plusz áramkörök kellenek, amik előállítják az emlitett RAS, CAS, MUX jeleket. (Z80-hoz EPROM vagy SRAM illeszthető közvetlenül.)
Amikor a Z80 éri el a videó memóriát, akkor szintén a Nick végzi ezeknek a jeleknek előállítását.

Alapból a Z80-as cím és adatbusz el van szigetelve a Nick és videómemóriák által használt cím és adatbusztól.
Az alaplapon U5, U6, U7 jelű IC-k végzik ezt a feladatot, a főnök pedig a Nick: az ACCESS nevű jellel tud engedélyt adni arra, hogy a Z80-as busz kapcsolódjon a videó buszhoz.
Erre nem csak a videómemória eléréséhez van szükség, hanem a Nick regisztereinek írásakor is.
A dologban jelentős része van még Davenek is, ő dekódolja az egész alaplap számára a címeket, így ő veszi észre, hogy a Z80 valami olyat akar csinálni, amihez a Nicknek is köze van, ezt a VRAM és VIO jelekkel jelzi: "Hé, Nick szomszéd! Ez a Z80 gyerek akar valamit tőled!"
Erre a Nick nagy valószínűséggel azt mondja: "Várjon egy kicsit, most nem érek rá!" Mivel a Nick az erősebb, a Z80 várni fog Gyakorlatban ez úgy néz ki, hogy a rendszer órajelből, ami a Nick 61-es lábára érkezik, a Nick állítja elő a kettővel osztott CPU órajelet a 64-es lábon (alapgépen 8Mhz a rendszer, 4Mhz a CPU órajel). Amikor azt mondja a Z80-nak, hogy várjon egy kicsit, akkor egész egyszerűen nem ad neki órajelet.
Majd amikor már ráér, akkor elsőként "kinyitja a kaput" az ACCESS jellel, hogy a Z80-as cím és adat busz összekapcsolódjon a videó busszal, majd generálja a szükséges RAS/CAS/MUX jeleket a videómemória részére, és végül engedi a Z80-nak, hogy elvégezze a kívánt műveletet.

Következő fejezetben megnézzük mindezt oszcilloszkópos méréseken, hogyan is néz ki a gyakorlatban.

Hogyan működik a DRAM címzés?
-ki kell tenni a címbuszra a címet, a memóriákat címző multiplexereket RAS-ra kapcsolni
-kis várakozás után, amikor már biztos, hogy a memóriák címbuszán a RAS cím van ott, mehet a jelzés a RAS vezeték alacsonyra állításával
-várni kell, amíg a memória elraktározza a RAS címet (ennek idejét RAS to CAS delay-nak nevezik a memóriák adatlapján)
-multiplexereket CAS-ra kapcsolni
-kis várakozás után, amikor már biztos, hogy a memóriák címbuszán a CAS cím van ott, mehet a jelzés a CAS vezeték alacsonyra állításával
-várni kell míg a memória készen áll a művelet elvégzésére (access time from CAS néven nevezik)
(Az IC-ken feltüntetett elérési idő az "acces time from RAS", ami lényegében a "RAS to CAS delay" és "acces time from CAS" összege)

Kinagyítva így néz ki a Nick RAS-CAS jelei, jól láthatóan a CAS kicsit később lesz aktív, majd a művelet végén egyszerre kapcsolnak ki:
[ Guests cannot view attachments ]

Itt a MUX jel is, ami ugyanolyan hosszú mint a RAS, csak kicsit el van tolva:
[ Guests cannot view attachments ]

Az időzítésekhez célszerű megnézni a Nick órajelhez való viszonyukat. Az órajelről István kiderítette, hogy 14237536.2676056338 Hz, egy órajelciklus tehát 70,236... ns.

Nick órajel és RAS:
[ Guests cannot view attachments ]

Nick órajel és CAS:
[ Guests cannot view attachments ]

Nick órajel és MUX:
[ Guests cannot view attachments ]

Összefoglalva: egy Nick slot 16 órajelből áll. (Mint a Nick leírásból tudjuk egy sorban 57 slot van, abból az első 8 alatt olvassa az LPT-t, 46 a képernyő adat, maradék 3 meg memória frissítés)
3 hosszú a RAS (első bájt beolvasása) tehát kb 210 ns-os memória eléréssel dolgozik a Nick.
2 "pihenő"
3 hosszú a RAS (második bájt beolvasása)
ezután 8 pihenő, majd ebbe jön be a Z80 elérése, majd látni fogjuk, hogy ennek az időnek az első 2 és utolsó 2 ciklusnyi ideje is pihenő, azaz két videó RAM hozzáférés között mindig 2 Nick órajelnyi pihenő van.
A CAS 1 órajellel később követi a RAS-t, és 2 hosszú.
A MUX 0.5 órajellel eltolva követi a RAS-t. Azaz félórajelnyi belenyúl a pihenőbe. Ezután a maradék félórajelnyi lehet a tényleges pihenő, a következő órajelben mehet ki az új cím a címbuszra.
Tehát így nézhet ki:
1. ciklusban kimegy a cím
2. ciklus kezdetén aktív lesz a RAS
2.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
3 ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
5 ciklusnál kikapcsol a RAS és CAS
5.5 ciklusnál kikapcsol a MUX
6 ciklusban kimegy a cím
7. ciklus kezdetén aktív lesz a RAS
7.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
8 ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
10 ciklusnál kikapcsol a RAS és CAS
10.5 ciklusnál kikapcsol a MUX

Itt jön a Z80 ideje:
[ Guests cannot view attachments ]
Látható, hogy a hozzáférés ugyan az, csak 1 Nick órajelnyivel hosszabb.
Folytatva ez előbbit:
1. ciklusban kimegy a cím
2. ciklus kezdetén aktív lesz a RAS
2.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
3 ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
5 ciklusnál kikapcsol a RAS és CAS
5.5 ciklusnál kikapcsol a MUX
6. ciklusban kimegy a cím
7. ciklus kezdetén aktív lesz a RAS
7.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
8. ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
10 ciklusnál kikapcsol a RAS és CAS
10.5 ciklusnál kikapcsol a MUX
11. ciklusban kimegy a Z80-as cím
11.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
12. ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
15 ciklusnál kikapcsol a RAS és CAS
15.5 ciklusnál kikapcsol a MUX

Szép. Legalább a kiforrasztással nem kell duplán nyűglődni, ha ezzel javítasz egy lapot.

Pl talan a scroll demo volt ilyen amit epp neztem, a debug ablak azzal van teli, hogy: "Reading undecoded port 0x82". Ez mondjuk erdekes, elvileg - tudtommal - nick registerek nem visszaolvashatoak, tehat a scroll demo nem tudom miert akarja azt a portot olvasni, van otletetek, hogy ezzel mit akar elerni?

Na ez egy jó kérdés, eddig én is úgy tudtam felesleges olvasgatni a Nick portjait

István viszont tudhat valami trükköt, az ep128emuban ez van:
 uint8_t Nick::readPort(uint16_t portNum)
  {
    (void) portNum;
    return dataBusState;
  }
A kérdéses helyen azt látom, hogy C0h-t olvas a Scroll Demo (ep128emuban), amiből valami várakozási értéket generál:
 1189  DB 82        IN    A, (82)
 *118B  E6 07        AND   07
  118D  3C           INC   A
  118E  47           LD    B, A
  118F  10 FE        DJNZ  118F

ezeket ki kell deríteni addig amíg még van működöképes EP a világegyetemben, mert utána már nem tudhatjuk meg

Időzítési célra ennek úgy lehjet értelme, hogy például egy nem látható (a kerettel azonos színű, de nem keret) sorban a video adat egy számsor, amit az aktuális vízszintes pozíció olvasására lehet használni.

hm hm... ez érdekes...

Soron belül változó keretszín vagy BIAS pontos időzítéséhez például hasznos lehet.

Egyik demómban csináltam ilyet, de persze nem ezzel az időzítéssel, mert nem is tudtam róla akkor.
De amúgy még nem biztos hogy ez jó lehet. Ugyanis a Z80 sebességével sajnos soronként kb 20x lehet megváltoztatni a bordert vagy a biast (vagy 30? nem emlékszem), és ez olyan kevés hogy "ugrálhat" akkor is ha ilyen időzítést használ.
Mindenesetre jó lenne kipróbálni.
Amúgy az Ork megademo 2-ben volt ez az effekt, a biast állítottam így, emuból kép (persze rossz):

A NICK portjainak (80h-8Fh) az olvasása azt a byte-ot adja vissza, ami az adatbuszon maradt, azaz amit a NICK utoljára olvasott a memóriából (ezt az ep128emu nem emulálja) vagy a NICK I/O portokra utoljára írt értéket.

Időzítési célra ennek úgy lehjet értelme, hogy például egy nem látható (a kerettel azonos színű, de nem keret) sorban a video adat egy számsor, amit az aktuális vízszintes pozíció olvasására lehet használni.

En azt hittem, hogy minden "olvasasra nem dekodolt" portra igaz (pl ahol nincs is semmi, se olvasasra, se irasra), hogy az adatbusz allapotatol fugg, hogy a "semmi" olvasasa mi lesz, illetve az is befolyasolja, hogy milyen hw van a gepre dugva (pl az adatbuszra van-e fel-/lehuzo ellanallasok kapcsolva, stb). Vagy akkor ez itt kulon eset a nick-re ezek szerint egy kisse ...