Enterprise Forever

:HUN => Hardver => Kijelző => Topic started by: Tuby128 on 2012.February.10. 15:31:53

Title: NICK 2.0 projekt
Post by: Tuby128 on 2012.February.10. 15:31:53
Tisztelt Fórumozók!

 Azért nyitottam ezt a topicot, hogy idõközönként beszámoljak arról, hol jár a NICK 2.0 projectem.
(Kérem a moderátorokat ne integrálják be ezt a témát másik topicba, mert itt csakis errõl a témáról szándékozom disputálni.)

 A projekt célja:
Olyan külsõ videoegység létrehozása, amely lehetõséget nyit az ENTERPRISE számítógép PC-s monitoron való megjelenítésre.

 A külsõ videoegység kezdeti tulajdonságai:
- Buszbõvítõ egységhez történõ csatlakozás
- Teljes NICK-sorparaméter tábla kompatibilitás (kivéve a vertikális szinkront és az interlace módot)
- Írható külsõ memóra amibõl a videoegység a megjelenítendõ képet generálja
- 800 x 600-as PC monitor felbontás

 Késobbi tervek:
- Változtatható PC-monitor felbontás (1024x768, 1280x1024 ... stb)
- Extra videomódok a sorparaméter táblában
- PS/2 billentyûzet csatoló, amely az I/O hívásokra válaszolva

(a lista nem teljes késõbb bõvíteni fogom)

Title: NICK 2.0 projekt
Post by: Tuby128 on 2012.February.10. 15:32:37
Jelenleg ott tartok, hogy elkészült a megjelenítõ HW kód és betöltöttem a hardverbe.
Programozható logikai kapukat használok, melyeket hardverleíró nyelven konfigurálok.

Elsõként azt tûztem ki célul, hogy egy 800x600-as képet jelenítsek meg PC monitoron 60Hz-es felbontásban.

A kimenet egy 8 ellenállásos RAMDAC az ENTERPRISE videomegjelenítésével azonos kombinációban.

A hardverhez csatlakozik egy 1MByte-os memória, amely a késõbbi videomemória célját szolgálja.

A próbakódot úgy írtam meg, hogy a bekapcsolás utáni memóriaszemetet jelenítse meg a képernyõn. Minden pixel a memóra egy 8 bites rekeszének felel meg, tehát 256 színû.

 Az LCD monitoromon kapott képet a csatolmányban prezentáltam.

Következõ lépés: A HW összekapcsolása az ENTERPRISE buszával.
Title: Re: NICK 2.0 projekt
Post by: IstvanV on 2012.February.10. 15:54:49
- Teljes NICK-sorparaméter tábla kompatibilitás (kivéve a vertikális szinkront és az interlace módot)

Tehát a több képernyős LPT-t használó animációk (mint például néhány demóban) se működnek ?
A video megszakításokat megvalósítja (egy LPT-n belül több is lehet), pontos időzítéssel ?
Title: Re: NICK 2.0 projekt
Post by: Tuby128 on 2012.February.10. 16:14:05
Tudtam, hogy elõ fognak kerülni a NICK egyéb tulajdonságai is.

1. Mit értesz több képernyõs LPT alatt?

2. Video megszakítással azért nem fogalalkozom, mert nem veszem ki a NICK-et és nem is iktatom ki, tehát a Nick továbbra is elvégzi. (Senki sem szeretné, ha kiforrasztanánk a szeretett Enterprise számítógépébõl.)
Title: Re: NICK 2.0 projekt
Post by: Zozosoft on 2012.February.10. 16:26:15
1. Mit értesz több képernyõs LPT alatt?
Az hogy egy LPT táblában nem csak egy kép lehet leírva, hanem tetszõleges: kép,szinkron,kép,szinkron,kép,szinkron... addig amíg nem jön egy reload bit, addig nem kezdi az elejérõl a Nick.
Ennek egy speciális esete az interlace.
Title: Re: NICK 2.0 projekt
Post by: Tuby128 on 2012.February.10. 16:31:35
Elemezzük tovább kérlek!

Megértettem a mûködést. Csak nem tudom kinek van erre szüksége.

1. Mire jó egy többképernyõs kép?
2. Milyen elõnyei vannak?
3. Mennyire memóriapazarló?
4. A demókon kívül mi használja?
Title: Re: NICK 2.0 projekt
Post by: IstvanV on 2012.February.10. 16:48:15
1. Mire jó egy többképernyõs kép?

Egyszerű animációt lehet megvalósítani vele, amely CPU használat nélkül jelenik meg.

Quote
2. Video megszakítással azért nem fogalalkozom, mert nem veszem ki a NICK-et és nem is iktatom ki, tehát a Nick továbbra is elvégzi. (Senki sem szeretné, ha kiforrasztanánk a szeretett Enterprise számítógépébõl.)

Akkor nem jól értettem a NICK 2.0 célját :oops:, azt hittem az eredeti teljes helyettesítésére készül, pl. olyan géphez is, amelyben a NICK elromlott. Így valóban kevésbé fontos a kompatibilitás, ha valami nem működik, az továbbra is használható a (rosszabb minőségű) eredeti video kimenettel.
Title: Re: NICK 2.0 projekt
Post by: Tuby128 on 2012.February.10. 17:06:44
Mivel monitorkat lehet venni potom pénzért, az Enterprise számítógép újra elfoglalhat egy sarkot a szobában letakarva, és várva gazdáját, hogy bármikor újra használja õt.

Én rendelkezem KM-switch eszközzel, amelynek segítségével egy billentyûzet-egér-monitor együttessel több gépet tudok használni, azok között átkapcsolni. Alig várom már, hogy a 2. gép az Enterprise lehessen.
Title: Re: NICK 2.0 projekt
Post by: Zozosoft on 2012.February.10. 18:21:54
Akkor nem jól értettem a NICK 2.0 célját :oops:, azt hittem az eredeti teljes helyettesítésére készül
Én is  :oops:
Title: Re: NICK 2.0 projekt
Post by: lgb on 2012.February.10. 19:07:35
Egyszerű animációt lehet megvalósítani vele, amely CPU használat nélkül jelenik meg.

Akkor nem jól értettem a NICK 2.0 célját :oops:, azt hittem az eredeti teljes helyettesítésére készül, pl. olyan géphez is, amelyben a NICK elromlott. Így valóban kevésbé fontos a kompatibilitás, ha valami nem működik, az továbbra is használható a (rosszabb minőségű) eredeti video kimenettel.

Hat igen, es pl jol jott volna olyan esetben ha "EP rebuild" project van, pl Z180-al, esetleg eZ80-al :) Akkor a nick adott lenne, vhdl/verilog dolgokba - valaki hozzaerto, nem en :) - bele is lehet irni picit, ha itt valami maskepp kene az illesztes miatt: lassan keszen lenne az uber-brutal EP 2.0, mar csak mondjuk a Dave hianyozna. Ha zonban valaki a hanggal nem foglalkozik, akkor max memory mapping, meg megszakitasok reszt kene megcsinalni, es mar - igaz hang nelkul - tesztelni is lehetne. Bar imho, akkor ha mar FPGA be lehetne melle tolni. Kesobb esetleg opcionalisan a CPU emulaciot is, es kesz a szep alom: a C64DTV-hez hasonlo "kompakt" EP, advanced tulajdonsagokkal! Csak mondjuk lehetne tv mimenet helyett jo kis whatever (VGA, HDMI, tudomisen). Szoval egy teljesen kompatibilis megoldas azert nagyon sok lehetseges jovobeli project-et is tudna szulni, plusz egy deffektes EP-et (Nick kaputt) is megmenthet, stb stb. Persze, ehhez full kompatibilitas kene.

Amugy szep pelda a C64 Chamelon project (vagy mi is), ahol a VIC-II-t "duplikaltak": ugy lett kvazi VGA kimenet, hogy a buszra kapcsolodik az FPGA-s cuccos, es mivel cycle exact VIC-II emulacio van, garantaltan az lesz annak "kimeneten" amit a gepbe epitett VIC-II mutatna. En azt gondoltam, valami ilyen keszul itt is ...

Ha felreertettem, es eddig feleslegesen "vitatkozgattam" itt, akkor bocsanatot kerek, nem allt szandekomban flame-elni.
Title: Re: NICK 2.0 projekt
Post by: lgb on 2012.February.10. 19:14:13
Elemezzük tovább kérlek!

Megértettem a mûködést. Csak nem tudom kinek van erre szüksége.

1. Mire jó egy többképernyõs kép?
2. Milyen elõnyei vannak?
3. Mennyire memóriapazarló?
4. A demókon kívül mi használja?

Azert a memoriazabalasrol: most kepzeld el, hogy van egy kep, sync, kep, sync, stb, reload valahol soka :) Ha a pointerek majdnem mindenhol ugyanazok, csak nehol van kulonbseg, akkor nem tul memoriazabalo, es ezzel nagyon szepen lehet nulla CPU-t hasznalo animaciot csinalni (felteve ha nem tul nagy a kulonbseg a kepek kozott, kulonben tenyleg tul sok memoria kellene). Ez az amire azt mondom, hogy ez a nick szepsege, ami miatt az egesz EP megfogott (amellett, hogy a memoriakezeles milyen elegans es szep szinten, nem olyan "ganyolt" mint a custom hackelt megoldasok C64-nel, stb). Ezert is kezdett erdekelni az EP, annak ellenere, hogy valojaban en "nem is voltam EP-s".

Az, hogy a demokon kivul mi hasznalja, jo kerdes: de akkor ilyen elven kizarni programokat, volt mar parrol szo, ami "extra" nick dolgokat csinal lasd pl iview. Es persze pont azt se felejtsuk, hogy pont egy ilyen project mint a nick2 katalizalhatna talan az ep-re uj programok irasat (mivel "profi" megjelenites is lenne, osszehasonlitva a tv kimenettel), es pont ekkor jonne jo a kompatibilitas, hiszen azert az ember szeretne, ha a "regi" gepen is menne (kiveve persze, ha valami extra nick2 feature-t hasznal, mint x2 read rate, es hasonlo otletek, amirol mar irtam, de persze az mas kerdes).
Title: Re: NICK 2.0 projekt
Post by: Tuby128 on 2012.February.11. 16:35:02
Tegnap elõvettem az egyik lestrapált EP-met (természetesen én strapáltam le tizenpár év alatt), és átalakítottam az antenna kimenetet színes video kimenetre. Ez lesz a tesztgépem. EP 128 issue 6.

 Elsõ dolgom volt, hogy megnézzem mennyire tartja be a Z80 a specifikációt.
Írtam egy Assembly programot:

Code: [Select]
DI
LD HL,5000h
back LD A,(HL)
LD A,(HL)
LD A,(HL)
LD A,(HL)
LD A,(HL)
LD A,(HL)
LD A,(HL)
.
; ezt még vagy 8000-szer egymás után
.
LD A,(HL)
LD A,(HL)
JP back

Arra voltam kíváncsi, hogy hány órajel az utasításbekérés, és mennyi a végrehajtás.
A kód futtatásakor elõvettem az oszcilloszkópot, és rámértem az !M1 és !RD lábakra kétsugaras módban. Valóban a katalógus szerinti specifikációt mértem, így pontos idõzítési értékeket tudok, amelyek megkönnyítik a külsõ NICK memóriavezérlõjének implementálását.

A következõ szabályokat találtam:
Memória olvasásakor:
1. Egy órajelciklus ideje van a memóriavezérlõnek az adatokat szolgáltani, ha ezt nem tudja, akkor a WAIT lábbal késleltetni kell a processzor mûködését.
2. Addig kell a buszon tartani az adatokat, amíg !MREQ és !RD alacsony szintû.

Memória íráskor:
1. !MREQ és !WR lábak lefutóélére a buszon érvényes adat van, ami 1 órajelcikluson keresztül lesz ott.

Az I/O utsítások ugyanígy mûködnek, csak !MREQ helyett !IORQ a jelvezeték.

Projektemben az I/O utasításokat is figyelnem kell, mert a külsõ Nick csak így fogja tudni, honnan töltse be a sorparaméter táblát.
Title: Re: NICK 2.0 projekt
Post by: Zozosoft on 2012.February.11. 16:38:02
OUT 191,12 után is nézd meg. És nem mindegy, hogy a HL normál vagy videó memóriába mutat.
Title: Re: NICK 2.0 projekt
Post by: Tuby128 on 2012.February.11. 17:05:16
Ez a DAVE 0BFh regisztere, amely a következõ paraméterekkel rendelkezik:

b7 - b4 - nem használt
b3 - memóriahozzáférés módja (felsõ bit)
b2 - memóriahozzáférés módja (alsó bit)
b1 - Bemeneti órajelfrekvencia: 0 = 8MHz, 1 = 12MHz
b0 - Beépített RAM: 0 = 64K, 1 = 16K

memórihozzáférés módja:
11 - nincs várakozás
10 - nincs várakozás
01 - várakozás csak M1-nél (utasításolvasás), kivéve a VideoRam-ot
00 - várakozás minden memóriamûveletnél, kivéve a VideoRam-ot

OUT 191,12 - Nincs várakozás memóriamûveletnél

Egyébként direkt nem videomemóriát használtam a tesztre, mert tudom, hogy a Nick ciklust lop.
Csak azért kukkantottam rá az oszcilloszkóppal, hogy leellenõrizzem azt kapom-e, amit a specifikáció szerint elvárok, és igen, azt kaptam. Tudom, mennyi idõm van elõvenni a ramból az adatot.

Terveim szerint, az új videomódban minden képpont 256 színû lesz. Idõzítés szempontjából ez a legmegterhelõbb. Minden képpont elõtt memóriahozzáférésre van szükség. Két memóriahozzáférés közt, pont elfér egy plusz, egy CPU memória memóriahozzáférés. Sajnálatos, hogy a Z80 nem 40Mhz-en fut, mert ez az extra nem lesz maximálisan kihasználva.

Nincs 40 MHz-es Z80 valahol a világban?
Title: Re: NICK 2.0 projekt
Post by: IstvanV on 2012.February.11. 17:26:32
Nincs 40 MHz-es Z80 valahol a világban?

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.
Title: Re: NICK 2.0 projekt
Post by: lgb 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 :)
Title: Re: NICK 2.0 projekt
Post by: Zozosoft 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...
Title: Re: NICK 2.0 projekt
Post by: lgb 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 ...
Title: Re: NICK 2.0 projekt
Post by: Tuby128 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.)
Title: NICK 2.0 projekt
Post by: Tuby128 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")
Title: Re: NICK 2.0 projekt
Post by: IstvanV 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).
Title: Re: NICK 2.0 projekt
Post by: lgb 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.
Title: Re: NICK 2.0 projekt
Post by: Tuby128 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.
Title: Re: NICK 2.0 projekt
Post by: Sulp 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 (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)
Title: Re: NICK 2.0 projekt
Post by: Tuby128 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.
Title: Re: NICK 2.0 projekt
Post by: Tuby128 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.
Title: Re: NICK 2.0 projekt
Post by: balagesz 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á.
Title: Re: NICK 2.0 projekt
Post by: Zozosoft 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.
Title: Re: NICK 2.0 projekt
Post by: Tuby128 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.