Welcome, Guest. Please login or register.


Author Topic: NICK 2.0 projekt (Read 15629 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK 2.0 projekt
« Reply #15 on: 2012.February.11. 18:30:37 »
A Z80 gyorsítását az EP-ben az korlátozza, hogy a gép más részeit (elsősorban a DAVE-t) is gyorsítani kell. A gyakorlatban legfeljebb 7.12 (esetleg még 8 ) MHz-es Z80 órajelű EP konfiguráció fordul elő. Ez is gyakran csak az eredeti memória IC-k cseréjével működik megbízhatóan.

Amugy ha mar Z80 ... eZ80, 50MHz orajellel, atlagosan 4x gyorsabb meg ugyanazon orajelen is mint a Z80 lenne, de van ahol akar 10x is ... De teny, hogy ehhez total uj EP-t kene mar tervezni :)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK 2.0 projekt
« Reply #16 on: 2012.February.11. 18:44:11 »
De teny, hogy ehhez total uj EP-t kene mar tervezni :)
És az IO port kezelés miatt a programok 99.999%-át átirni...

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK 2.0 projekt
« Reply #17 on: 2012.February.12. 00:38:58 »
És az IO port kezelés miatt a programok 99.999%-át átirni...

Hat jah, de nem tartom kizartnak hogy valahogy _talan_ ki lehet kapcsolni az "utban levo" integralt i/o hulysegeket, vagy hasonlo. Ha semmi keppen nem megy, akkor gaz ...

Offline Tuby128

  • EP addict
  • *
  • Posts: 1485
  • Country: hu
Re: NICK 2.0 projekt
« Reply #18 on: 2012.February.12. 05:01:54 »
Most jutottam el oda, hogy lassan tényleg össze kellene kötni az EP-t a hardverrel. Sokat gondolkodtam, hogy hogyan oldjam meg a dolgot, végül a következõ megoldás mellett döntöttem:

- Ráforrasztottam a busz csatlakozóra egy ISA csatlakozót úgy, hogy az elsõ (9V) és utolsó (audio) lábakra nem kerül láb. A projekthez ezek a csatlakozók úgysem kellenek.

- Ezentúl ha bármit csatlakoztatni akarok az EP-hez elég csak a nyákot megcsinálni élcsatlakozósra és máris lehet használni.

Következõ lépés, elkészíteni a HW összeköttetést az élcsatlakozóval. Ehhez Altium Designer nyáktervezõt használok. Szerencsére nagyon segítõkész a program, így talán holnapra meg is lesz ami kell.

(Bár már ott tartanék, hogy a hardvert kellene felprogramozni. Mindegy, ez is mérnöki munka. Nem nagy, de legalább fejlõdöm.)
« Last Edit: 2012.February.12. 08:15:00 by tubybb »

Offline Tuby128

  • EP addict
  • *
  • Posts: 1485
  • Country: hu
NICK 2.0 projekt
« Reply #19 on: 2012.February.13. 02:16:09 »
A külsõ Nick 1MByte Statikus Ram memóriával rendelkezik. FF (255) szegmenstõl visszafelé fog elterülni a memóriában C0-ig (192).
 Mivel az alap 64KByte memória (FC-FF) kell a belsõ Nicknek, ezért a külsõ egységben ez a memóriaterület csak írható lesz. A külsõ Nick is innen dolgozik. A többi teljes sebességgel fog mûködni.
 A külsõ nick extrája az lesz, hogy az új videomódokban mind az 1MByte memóriát meg tudja címezni, így akár 640x480 / 256 színû felbontást elérhetünk vele. Vagy mégtöbb képet rajzolhatunk ki alacsonyabb memóriaigény esetén.

A külsõ Nick további extrája:
 Tervezek bele még egy elõjeles ofszet regisztert, amely azt hivatott megmondani, hogy vízszintes scrollozáskor az adott sor(ok) kirajzolását hány pixellel korábban/késõbb kezdje el. (ezzel teljesítem Zozo álmát, piszok gyors scroll lehetõséget biztosítva)

 Megcsinálom ugyanezt függõlegesen is, így a sorparméter blokkok LD sorait lehetne ofszetelni.
 Arra gondoltam hogy kiosztanék a Nick-nek plusz I/O címeket ahol ezt lehetne megadni.

Ha valakinek megvan az Enterprise Rom-visszafejtése (0.szegmens) legyen szíves nézze meg, hogy:
 84h-tól 8Fh-ig vannak-e szabad I/O címek?
(9.2 fejezet "IN/OUT címek")
« Last Edit: 2012.February.13. 05:12:15 by tubybb »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK 2.0 projekt
« Reply #20 on: 2012.February.13. 09:34:25 »
84h-tól 8Fh-ig vannak-e szabad I/O címek?

A 84h-8Fh I/O címeken a NICK portjai ismétlődnek (nem teljes a címdekódolás). Ezeket a ROM szerintem nem használja, de játékokban és demókban előfordulhat (valószínűleg csak nagyon ritkán).

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK 2.0 projekt
« Reply #21 on: 2012.February.13. 10:03:54 »
Ha valakinek megvan az Enterprise Rom-visszafejtése (0.szegmens) legyen szíves nézze meg, hogy:
 84h-tól 8Fh-ig vannak-e szabad I/O címek?
(9.2 fejezet "IN/OUT címek")


Amennyire en tudom: 80h-8Fh a Nick szamara vann fenntartva, de ebbol a Nick csak 80h-83h portokat hasznalja. Az erdekes kerdes, hogy letezik-e olyan elvetemult software, ami kihasznalja esetleg a "memoriavisszhang" jelenseget, azaz, hogyha igaz az pl, hogy nincs dekodolva a kerdeses tartomanybol a nick szamara hasznos, es 4 cimenkent "ismletodik" a nick regiszer "keszlet". Amugy amikor en csinaltam Nick2-ot (csak sw-esen, sajat emulator kezdmennyel), akkor vmi ilyesmi volt (emlek alapjan, mivel a serverem sajna "megsemmisult" jo par eve, amin ezek a cuccok is voltak ):

84h: keyreg, 76 decimalist ide irva beallitja az extended nick funkciokat (76 szerenyen a szuletesi evszamom)
85h: palette select register; kivalasztja a 256 EP szin kozul azt, amit olvasni/irni akar az ember
86h: palette data register; 2 byte olvashato/irhato minden fenti szinre (16 bit/colour info)
87h: extended nick control
  Itt voltak olyasmik (pontosan mar nem emlekszem), ahol egy 2 bit kivalasztja a "read rate"-et (x1=normal, x2, x4, x8),
  vagy egy masik a nem definialt videomodra engedelyezi a kozvetlen hi-color mode-ot (1 pixel = 2 byte, 65K szin)
  vagy egy masik bit pl azt csinalta hogy beallitotta az std EP palette-at a 256 szinre, masik ertekkel lehetove tette a 85/86h porton custom pal-t
  illetve pl x1 rate folott definialta hogy az egy slot alatt az LPB fetch soran beolvasott extra byte-ok legyenek-e extra infokra ertelmezve,
  vagy sem (sem = 16 byte, original LPB
88-89h: LD1 (?) offset, hozzadja mindig [scroll, stb]
8A-8Bh: LD1 (?) modulo, sor vegen hozzaadja (nagyobb kepben "latszik" a nick "ablaka" ...)

Mondjuk nem tudom mi ertelme volt, hogy leirtam ezeket, hatha otletnek jo valamire :) Sajnos pontosan mar - mint irtam - nincs meg, de valami ilyesmi volt. Es persze extra LPB byte-okban (>x1 read rate, illetve extended LPB engedve) volt par info pl a "hianyzo" 8 pal color
16 szinu modhoz, illetve annak beallitasa, hogy az extra read rate modban mire forditodik a beolvasott extra info: horizontalis felbontas
novelese, vagy egy uj (LD3) pointer alpapjan noveles, amivel pl DMA szeru dolgra lett volna jo, I/O portrol iras/olvasas iranyaba (pl akar
CPU fuggetlen digi lejatszas, ilyesmik), de ez csak terv volt.

Offline Tuby128

  • EP addict
  • *
  • Posts: 1485
  • Country: hu
Re: NICK 2.0 projekt
« Reply #22 on: 2012.October.24. 21:54:19 »
Ezt a topicot idén februárban nyitottam azért, hogy kicsit átbeszéljük és megfogalmazzam azokat a tulajdonságokat, amikkel bírnia kell a külső 2.0-ás NICK-nek.
 A projektem akkor időhiány miatt abbamaradt. Olyan nehézségekkel küzdöttem, hogy pl. nem tudtam tesztelni az elkészített hardvert, sőt a nyákgyártáshoz és forrasztáshoz szükséges berendezéseim is tönkre mentek.
 Akkor megfogalmazódott bennem, egy RS-232 adatcsatorna, amelyet az eszközbe (a NICK 2.0-t tartalmazó FPGA) integráltam volna addig, míg a fejlesztés és tesztelés folyik. Na ez tartott nekem nagyon sokáig, ugyanis az RS232 interfész sajnos nem bombabiztos (hibákat ejt az adatátvitel során, még akkor is, ha paritásellenőrzés be van kapcsolva) emellett nagyon lassúnak bizonyult, főleg miután a hibakiszűrés miatt további oda-vissza nyugtázást kellett beletenni. Emiatt az eszköz egyre több logikai cellát igényelt, és kinőtte az erre szánt IC-t, venni kellett egy nagyobbat, amit aztán egy NYÁK terezési figyelmetlenség miatt sikerült rövidre zárni, és szegényke megadta magát :) Így venni kellett még egyet.

 Amire nem gondoltam, és nem is próbáltam, hogy az EP 5V-os I/O TTL jelekkel dolgozik, az FPGA-m viszont 3.3V-os I/O-val. Szerencsére az FPGA tud 5V-ot fogadni, azt viszont már nem tudom, hogy a 3.3V-os jelszint mennyire lenne elég az EP-nek.

Offline Sulp

  • Newbie
  • Posts: 4
  • Country: hu
Re: NICK 2.0 projekt
« Reply #23 on: 2012.October.25. 11:06:23 »
Szia!

Attól is függ, hogy milyen FPGA-t szeretnél használni.Az FPGA adatlapján látszik a "0" és az "1" jelszintjei. Vil,Vih - Vol,Voh első körben ezeket kell összehasonlítani. 
A Xilinx Spartan2 5V,3.3V kompatibilis, az xc95xx cpld-k 5, 3.3,2.5 V, viszont a Spartan3, Spartan6 már csak 3.3V vagy kisebb jelszíntekkel kompatibilisek.
(Soros ellenállással lehet próbálkozni : http://www.xilinx.com/support/answers/19146.htm , de az álmoskönyv szerint nem túl szerencsés)
A Spartan2 viszont relative drága és az újabb Xilinx ISE már nem támogatja.
A legegyszerűbb:level-shiftereket betenni az fpga és a gép közé. Ekkor "csak" az időzítésekre kell figyelni (bár az FPGA-d mindenképpen nagyságrendekkel gyorsabb lesz, mint az EP)

A másik téma: neked "sima" UART vagy teljes RS-232 (vagy esetleg komplett 8251A) kell? Az előbbit minimális logikából meg lehet valósítani az fpga-ban, az utóbbi már trükkösebb lehet. A soros vonal figyelésénél pedig 16x vagy 64x mintavételezéssel szokás a startbitet (illetve annak közepét) detektálni (utána már lehet a baud-rate-el mintát venni)

Offline Tuby128

  • EP addict
  • *
  • Posts: 1485
  • Country: hu
Re: NICK 2.0 projekt
« Reply #24 on: 2012.October.25. 15:26:39 »
Először is én az Altera gyártót választottam, mert annál könnyebben jutotam a starter kithez.
 Nekem komplett RS-232 logika kellett, ezért készítettem az FPGA-hoz MAX232 kiegészítő panelt. Ami illeszti a 3.3V-os TTL jeleket a -12/+12 szintre.
 A start bit detektálást egy huszárvágással megoldottam, csináltam egy aszinkron élfigyelést, és amikor hosszú nyugalmi idő után bekövetkezik a start bit lefutó éle, akkor elindítom az órajel generátoromat.(természetesen amíg jön az adat ez az élfigyelés ki van kapcsolva). Ezt persze aztán tovább tökéletesítettem, és a mai napra elértem, hogy 24 órás egyfolytában üzemelés közben 4-5 hibát vétett, de már ezeket is "eltüntettem" ellenőrzőösszeg és nyugtázás használatával. Hátránya az lett, hogy kevesebb hasznos adat kerül át, kicsit nagyra nőtt a VHDL kód :) és vele a felhasznált logikai cellák mennyisége.

Offline Tuby128

  • EP addict
  • *
  • Posts: 1485
  • Country: hu
Re: NICK 2.0 projekt
« Reply #25 on: 2015.March.01. 22:01:52 »
A kapcsolási rajzot böngészve azon gondolkodtam, hogy a NICK vezérlése lehet, hogy ki van vezetve a bus-bővítőbe (lásd csatolt rajz)
Ezen rajz alapján találtam rá a
- EC0,EC1,EC2,EC3 és EXTC-ra

Én úgy gondolom, hogy EXTC az External Control rövidítése. Én azt szeretném megoldani, hogy külső NICK használata esetén legyen a belső NICK letiltható.
Vajon mire valók ezek az EC0...EC3 bemenetek? Az a bajom, hogy még azt sem tudjuk igazán, hogy be- vagy kimenetről van szó.
Valaki emlegette a külső sprite vezérlőt...
Hmm, kéne egy jó adatlap, vagy egy leírás.

Offline balagesz

  • EP user
  • *
  • Posts: 279
  • Country: hu
Re: NICK 2.0 projekt
« Reply #26 on: 2015.March.01. 22:05:31 »
Ezen rajz alapján találtam rá a
- EC0,EC1,EC2,EC3 és EXTC-ra
Én úgy gondolom, hogy EXTC az External Control rövidítése.

Ha minden igaz, az inkább External Color lesz. Ez a külső Sprite hardverhez lenne, de - ha jól tudom, majd Zozo kijavít - egyelőre nincs olyan hardver, ami használná.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK 2.0 projekt
« Reply #27 on: 2015.March.01. 22:07:04 »
Ha minden igaz, az inkább External Color lesz. Ez a külső Sprite hardverhez lenne, de - ha jól tudom, majd Zozo kijavít - egyelőre nincs olyan hardver, ami használná.
Így van.

Offline Tuby128

  • EP addict
  • *
  • Posts: 1485
  • Country: hu
Re: NICK 2.0 projekt
« Reply #28 on: 2015.March.01. 22:28:10 »
Milyen feledékeny vagyok, a belső Nick-et nem lehet leállítani, mert akkor elvész az a szinkronfrakvencia, amit István már korábban említett. És vannak dolgok, amik ezt pont használják.