Welcome, Guest. Please login or register.


Author Topic: NICK (Read 99243 times)

Online Zozosoft

  • EP addict
  • *
  • Posts: 13375
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 20.0 Firefox 20.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #255 on: 2013.May.16. 13:04:49 »
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!" :-D
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.

Online Zozosoft

  • EP addict
  • *
  • Posts: 13375
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 20.0 Firefox 20.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #256 on: 2013.May.16. 14:05:01 »
Elsőként lássuk mit csinál a NICK amikor háborítatlanul dolgozik (piros a RAS, sárga a CAS):

Szépen látszik, hogy 2 bájtot beolvas, majd szabadon hagyja a videómemóriát. Gondolom többen sejtik már, hogy ezekbe a szabad lukakba van a Z80-nak esélye hozzáférni a videómemóriához :-)

Első tesztként kinullázva a videómemóriát, NOP-okat hajt végre a CPU, normál 4Mhz-en.

Látható, hogy lassú a proci, minden második luk szabadon marad.

6Mhz-en már minden lehetőséget kihasznál:


Jöjjön egy bonyolultabb feladat:
Code: [Select]
ld hl,4000h
f31 ld (hl),a
jr f31

4Mhz-en egy programciklusban 4 kihasználatlan lehetőség marad:


6Mhz-en már csak 3:


8Mhz-en már csak 2:

Online Zozosoft

  • EP addict
  • *
  • Posts: 13375
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 20.0 Firefox 20.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #257 on: 2013.May.16. 16:43:41 »
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:


Itt a MUX jel is, ami ugyanolyan hosszú mint a RAS, csak kicsit el van tolva:


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:


Nick órajel és CAS:


Nick órajel és MUX:


Ö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:

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

Online Zozosoft

  • EP addict
  • *
  • Posts: 13375
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 21.0 Firefox 21.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #258 on: 2013.June.11. 21:38:37 »
A frissen szerzett vadi új Nick:
9277-0
9279-1

Offline dolargaan

  • EP fan
  • *
  • Posts: 112
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 21.0 Firefox 21.0
    • View Profile
Re: NICK
« Reply #259 on: 2013.June.11. 21:54:54 »
Szép. :) Legalább a kiforrasztással nem kell duplán nyűglődni, ha ezzel javítasz egy lapot.

Online Zozosoft

  • EP addict
  • *
  • Posts: 13375
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 21.0 Firefox 21.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #260 on: 2013.June.12. 09:08:34 »
Quote from: dolargaan
Szép. :) Legalább a kiforrasztással nem kell duplán nyűglődni, ha ezzel javítasz egy lapot.
Pontosan :-)
Kár, hogy nem volt belőle még pár darab... meg Dave is jöhetne néhány.

Online Zozosoft

  • EP addict
  • *
  • Posts: 13375
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 22.0 Firefox 22.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #261 on: 2013.August.16. 12:00:58 »
Quote from: lgb
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 :oops:

István viszont tudhat valami trükköt, az ep128emuban ez van:
Code: [Select]
 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:
Code: [Select]
 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

Offline Z80System

  • EP addict
  • *
  • Posts: 3842
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 28.0.1500.95 Chrome 28.0.1500.95
    • View Profile
Re: NICK
« Reply #262 on: 2013.August.16. 12:06:11 »
Vagy csak a Laci ( scroll demo szerzoje ) epp reszeg volt ... meg kell tole kerdezni.
Z80 System

Online endi

  • EP addict
  • *
  • Posts: 7021
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
    • Honlapom
Re: NICK
« Reply #263 on: 2013.August.16. 12:14:10 »
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 :)
A diplomás magyar programozó megcsinált egy pacmant egy év alatt, majd lefikázta a világ legjobb játékait. :D

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 18.0 Firefox 18.0
    • View Profile
Re: NICK
« Reply #264 on: 2013.August.16. 13:00:29 »
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.

Online endi

  • EP addict
  • *
  • Posts: 7021
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
    • Honlapom
Re: NICK
« Reply #265 on: 2013.August.16. 13:19:37 »
Quote from: IstvanV
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...
A diplomás magyar programozó megcsinált egy pacmant egy év alatt, majd lefikázta a világ legjobb játékait. :D

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 18.0 Firefox 18.0
    • View Profile
Re: NICK
« Reply #266 on: 2013.August.16. 13:26:07 »
Soron belül változó keretszín vagy BIAS pontos időzítéséhez például hasznos lehet.

Online endi

  • EP addict
  • *
  • Posts: 7021
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
    • Honlapom
Re: NICK
« Reply #267 on: 2013.August.16. 13:34:36 »
Quote from: IstvanV
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 diplomás magyar programozó megcsinált egy pacmant egy év alatt, majd lefikázta a világ legjobb játékait. :D

Online endi

  • EP addict
  • *
  • Posts: 7021
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
    • Honlapom
Re: NICK
« Reply #268 on: 2013.August.16. 13:37:35 »
hülyeséget írtam, lehet hogy csak 10x lehet
A diplomás magyar programozó megcsinált egy pacmant egy év alatt, majd lefikázta a világ legjobb játékait. :D

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 29.0.1547.55 Chrome 29.0.1547.55
    • View Profile
    • http://lgb.hu/
Re: NICK
« Reply #269 on: 2013.August.16. 15:08:44 »
Quote from: IstvanV
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 ...