Enterprise Forever

:HUN => Hardver => Topic started by: Tuby128 on 2023.April.11. 11:36:20

Title: Nick 2.0
Post by: Tuby128 on 2023.April.11. 11:36:20
Nick 2.0

 Gondolkodtam hogyan lehetne továbbfejleszteni a Nick-et, úgy hogy a meglévő módokat ne változtassam.
 Az egyik amire szükség van feltétlenül, hogy több mint 8 bites legyen a video memória adatbusza.
 Ennek köszönhetően egy karakterszélesség alatt nem 3 byte memóriahozzáférés, hanem ennek többszöröse érhető el.
 Mondjuk lehetne a nick 2.0 majd 24 adatbites.
 
 A nick 40 karakteres "szöveges" módját ki kellene terjeszteni, hogy a 80 karakteres módot is szöveges módban támogassa. Ehhez a TEXT 40 LD2 mutatójának legfelső bitjét használnám, mert az mindig nulla.
 Ha ez a bit aktív, az LD1-ről nem 40 hanem 80 karaktert olvas és a karaktermező ugyanott lenne mint text 40-nél. Az EXOS-t kell csak hozzáigazítani.

 Van egy nem használt mód a nickben:
 Kiterjeszteném a NICK memóriahozzáférését az EP teljes 4MB memóriájára.
 Ez a nem használt mód kiterjesztett-grafikus mód lenne. Ebben a módban az LD 1 pointert és az LD2 egyik  bájtját együtt kezelném. Így egy 20 bites címet alkotva ami az EP teljes memóriájában bárhova mutathat.
 A színmódok közül a 4 színű mód pixelméretével lehetővé tenném a 256 szín megjelenítését.
 Tegnap számolgattam graphics 4-ben a maximális képpont kb: 336x252 képpont lenne ami 256 szín esetén képpontonként 1byte, így 83KB memória kellene. Ezt csak a nick fent leírt címzés kiterjesztésével lehet elérni, tekintve hogy alapból csak 64k-et tud.
 Ha egy programhoz "frambuffer" kell, ami azt jelenti, hogy az egyik képet mutatom míg a másikat rajzolom, akkor így 2*83KB=166KB fog kelleni csak a képnek.
 A framebuffer támogatását úgy oldanám meg, hogy két sorparaméter tábla (LPT) lenne, és ha a Z80 jelez, hogy elkészült, akkor váltana a másikra a Nick 2.0.

Mindebből következik, hogy a Z80 memóriahozzáférése független lenne a NICK-től, nem lenne várakozás. Ezt vagy gyorsabb memóriával és időzítéssel oldanám meg, vagy kettős hozzáférésű (dual port) memóriával.

 A hardveres sprite kezelésen még gondolkodom, hogyan lehetne az egész képre kialakítani. Ha lesz "frambuffer" lehet hogy nem lesz szükség nagy hardveres támogatásra, csak gyors mezőmásolásra. Tehát hogy a Z80 egy-két I/O utasítással megadja a sprite helyét a memóriában, x/y felbontását, és hogy hova kell másolni. NICK 2.0 pedig elvégzi a háttérben, majd jelez megszakítással ha kész.

 Ezzel gyakorlatilag egy feturbózott Amiga környékére katapulna az Enterprise számítógép.

 Ilyen szép video képességekkel már szükséges lehet a CPU-t 80 MHz környékére felhúzni.

 
Title: Re: Nick 2.0
Post by: Ep128 on 2023.April.11. 23:10:39
Nick 2.0
 Van egy nem használt mód a nickben:
 Kiterjeszteném a NICK memóriahozzáférését az EP teljes 4MB memóriájára.
 Ez a nem használt mód kiterjesztett-grafikus mód lenne. Ebben a módban az LD 1 pointert és az LD2 egyik  bájtját együtt kezelném. Így egy 20 bites címet alkotva ami az EP teljes memóriájában bárhova mutathat.

Nem szakértek hozzá, de... Ebből nem lenne gubanc (itt-ott fagyás) a "lefelé kompatibilitás" témában? Avagy hogy oldanád meg, hogy a memória olyan részeihez férjen hozzá, amik esetleg már egy adott programon belül foglaltak?
Title: Re: Nick 2.0
Post by: ergoGnomik on 2023.April.12. 08:26:20
Ez a NICK 2.0 egy elég alapos átdolgozása lenne a teljes rendszernek. Nem tudom ki hogyan van vele, de a 24 bites adatbusz nekem meglehetősen furcsának tűnik. Nem bonyolítaná az el túlságosan a címbusz kezelését? Valami okának csak kell lenni, hogy általában a mai rendszerek adatbuszai kettő egész számú hatványa bájt szélesek. (A videokártyák 192, 320 meg 384 bit széles adatbusza az más, mert három, öt vagy hat független 64 bites memória alrendszerből állnak össze.)

Egyébként egyszer-kétszer én is gondolkodtam hogyan kellene hasonlóképp "felturbózni" az Enterprise-okat. Ennyire merész gondolataim nekem nem voltak, tán a fantázia hiánya miatt. Az utóbbi időben azután arra jutottam, hogy igazából talán legjobb úgy szeretni ezeket a gépeket, ahogyan vannak. Még ha létre is jön valamiféle mindenkivel egyetértésben meghatározott műszaki tartalom a feljavításra és az gyártásba is kerülne, akkor sem lesz benne minden EP-ben. Úgy meg csak egy amúgy is kicsi közösségen belüli még apróbb klikk jönne létre. Vagy legalábbis nekem ez az érzésem.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.April.16. 05:59:51
Sikerült az EP32 emulátort átépíteni, úgy hogy Graphics hires 4 módban 256 színnel tudok megjeleníteni.

Egyelőre a 256 színű módot változtattam meg, majd később a helyére teszem.

 Érdekesség, hogy ha kiadom a GRAPHICS hires 4 parancsot, akkor egy 40 karakter széles és 20 sor magas grafikus lapot nyit meg, ami 40*8 * 20*9= 57600 képpont, amennyiben minden képpont 256 színű lehet, akkor ez 57600 Byte = 56 KB. A jó öreg Nick 64Kb -os így kivonva a 56KB = 8KB marad mindenre (rendszerváltozók, text 40 mód, maga a sorparaméter tábla etc.). Ez vajmi kevés. Ezért az emulátor most 4 x 64KB videomemórián fut, ami a F0 - FF szegmenseken terül el.
 A LD2 pointer alsó bájtjával tudok a 64KB-okat ugrani. Kipróbáltam ha 64KB határon definiálok egy LPT Blokkot, akkor a sor kiolvasásakor szépen folytatja a következő szegmesen.

 Mivel az exos nem kezeli az új módot, nekem kell a sorparaméter tábla LD1 és LD2 címeit igazítani.

 Már bekészítettem egy BMP képet, amit sikerült EP-féle 8 bitre átkonvertálnom. Majd holnap ha lesz idöm betöltöm a memóriába, megnézem hogyan mutat a kép az emulátoron. Még ki kell találnom, hogyan ismerem fel a 16KB-os szegmenshatárt ha képet másolgatok a memóriába. A BMP fájl lentről felfelé épül fel.

 Számolgattam, a Nick lehetőséget ad maximálisan 44 karakter széles és 28 karakter magas képet létrehozni (a status sor is benne van) ez akkor
(28*44) 252px*352px  = 89 KB memóra. Néhány ekkora kép tárolása már lehet hogy több floppit is igényel :D
 Ha esetleg igény lenne 16 bites grafikára, akkor ennek duplája 178KB kell.

 Nagyon nagy szerencse hogy annak idején így tervezték meg az EP-t, mert ezt kevés módosítással sikerült elérnem az emulátorban.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.April.16. 16:02:46
Hála LGB segítségének sikerült betölteni basicben egy EP-re módosított BMP file-t a memóriába.

Csatolmányban az eredeti 24 bites kép.
Az átalakított képet nem lehet már megnyitni, mert nem szabályos BMP. Ezért azt nem tudom ide feltölteni.
A végeredményt viszont igen. 256 színű kép. 52KB videomemóriát foglal :D (A jenleg 256KB-ból :P)

Sajnos nekem nincsenek ismereteim, hogyan kell lebutítani egy 24 bites képet 8 bitesre, az ep speciális R:G:B - 3:3:2 felépítése és azok súlyozott értéke miatt úgy tünik nem alkalmas a gyorsan összedobott konverterem szép képet visszaadni.
 Még majd dolgozom ezen a 24 -> 8 bit konverzión.
Title: Re: Nick 2.0
Post by: ergoGnomik on 2023.April.16. 16:35:25
A piros és zöld csatornában vagy egyszerűen eldobod az alsó öt bitet, vagy a színtartományból az alsó egy tizenhatodot (nevezzük mondjuk az elsőnek) a 0-hoz rendeled, a felső egy tizenhatodot (legyen a tizenhatodik) a 7-hez rendeled, a közbeeső tizenhatod párokat meg ahhoz az értékhez, amit közre fognak (második és harmadik az 1-hez, negyedik és ötödik a 2-höz, stb.)

A kék csatorna trükkös, mert az EP-ban egyenetlenül van felosztva. Ott is számolhatsz valami hasonló tartományokat, mint a másik két színre és aszerint rendelgeted hozzá a négy effektív értéknek (0, 2, 5, 7) megfelelő 0-tól 3-ig terjedő színkódhoz. Ami a valószínűleg kimaradó középső színtartományra esik, azt egy a két középső színből összeállított pepita mintájú, az eredeti képpel megegyező méretű virtuális képből veszed a konvertált képpont pozíciója alapján.

Ha még így sem jó az eredmény, akkor marad a kézzel javítgatás. Vagy kilesed az ep128emu képkonverteréből IstvanV hogyan csinálta a színek átalakítását.
Title: Re: Nick 2.0
Post by: ergoGnomik on 2023.April.16. 17:21:02
Kicsit próbáltam számolgatni a kék csatornára. 0..36 tartomány lehetne a 0, 37..109 tartomány az 1, 146..218 tartomány a 2 és a 219..255 tartomány a 3. A 110..145 tartományt pedig ditherezni az 1 és 2 színekkel.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.April.16. 17:46:31
Megvan mit rontottam el. Fordítva vannak a bitek az EP-n. A legkisebb helyiértéken lévő a legerősebb. A PCs RGB-nél pedig a legnagyobb helyiértékű a legerősebb.
Most változtatom éppen kép-konverteremet.

Nick leírás:
RED= b0 * 4/7 + b3 * 2/7 + b6 * 1/7
GREEN= b1 * 4/7 + b4 * 2/7 + b7 * 1/7
BLUE= b3 * 2/3 + b5 * 2/3

Szerkesztve Tuby128 kérésére, az utolsó sor helyesen:
BLUE= b3 * 2/3 + b5 * 1/3
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.April.16. 17:55:15
SIKER!

Title: Re: Nick 2.0
Post by: Tuby128 on 2023.April.16. 18:33:45
Most hogy van egy snapshot-om ebben a különleges módban a memóriáról. Ezt be tudom tölteni majd az FPGA-ba (ha elkészül) a NICK 2.0, és akkor azonnal lesz képem is.
Title: Re: Nick 2.0
Post by: ergoGnomik on 2023.April.16. 19:24:00
Jól néz ki! :smt023 Azonban lehet, hogy csak az én szememmel van valami baj, de nekem kicsit sárgásnak tűnik az új változat. Ez vajon mitől lehet?
Title: Re: Nick 2.0
Post by: szipucsu on 2023.April.16. 19:32:35
Sikerült az EP32 emulátort átépíteni, úgy hogy Graphics hires 4 módban 256 színnel tudok megjeleníteni.
Eléggé jól néz ki!
Lesz majd hardver is, amely támogat ilyen videomódot?
It looks very cool!
Will there be a piece of hardware that supports a video mode like this?
Es sieht sehr cool aus!
Wird es eine Hardware geben, die einen solchen Videomodus unterstützt?
¡Se ve muy bien!
¿Habrá hardware que apoya un tal modo de video?
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.April.16. 20:37:46
Hardver az biztos lesz. Szoftvert kellene írni, meg az exost hozzáigazítani. Az talán nagyobb munka.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.April.17. 12:46:27
Van valakinek valamilyen ötlete, hogyan csináljam meg a sprite kezelést?
 Tegnap nézegettem a Nintendo Super NES (SNES) megoldását.
Feltölt a memóriába egy hatalmas tömböt, amin 8x8 16x16 stb pixeles képek (csempék) vannak egymás mellett. Mindegyiknek van egy címe ID, és a háttérre ezeket lehet felpakolni a ID számuk alapján.
 A SNES-nél a 0. Szín transzparens. Tehát ahol 0 van megadva, ott átlátszó a háttér. Ez azért fontos mert 3 hátteret lehet egymásra tenni. Pl egy hegyvonulatos képre rá lehet szuperponálni egy szivárványt. Így mindkettő látszik.
 Lehet még sprie-okat definiálni akik szintén csempékből állnak. Meg lehet adni hogy mélységében hol legyen, ugyanis a megrajzolt palota mögé repülő madarak is ilyen sprite-ok.

 Ez a csempés módszer gyakorlatilag olyan mint a Nick Text 40 módja, csak több színnel, több karaktertel.
 Sajnos a Nick TEXT módszerével csak egy hátteret lehet létrehozni. Jó volna ha 2-3 text 40-es képet össze lehetne másolni.

 Ami még fontos lenne a scrollozás függőlegesen és vízszintesen. Arra gondoltam, hogy a Nick 2.0 kaphatna néhány új I/O portot amivel egy utasítással el lehet mozgatni pixelenként az összes LPT sor által kijelzett képet mind vízszintes mind függőleges irányban a memóriában. Tehát egy out x,y utasítás után a Nick 2.0 y pixellel eltolva kezdi olvasni az adatokat a memóriából. Ugyanez vertikálisan is.
 Mindezzel rengeteg Z80 munkát meg lehet spórolni.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.April.18. 19:24:49
Nick 2.0 feature:
 2 video kimenet. Két LPT tábla. Az egyikben nyitva maradhat a szokásos szöveges mód, a másikban is hasonlót fel lehet építeni, de még jobb ha a teszprogram kimenete a másikon fut (grafikus mód) ezzel igazán kényelmes lehet a programozás.
 Nagy kihívás lesz a memoria management ennyi adat olvasásához, de van egy ötletem.

Nyilván lesz a Nick 2.0-án alternatív dvi-d kimenet(ek).

 
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.April.21. 21:53:52
Ismét továbbgondoltam a fejlesztést, összegyűjtöttem ezeket a gondolatiamat.

A grafikában egy objektum ráhelyezése egy meglévő háttére úgy történik, hogy az alakzat pl. labda  egy téglalap alakú vászonra van rárajzolva, és ugye az alakzaton kívüli pixeleket nem akarjuk a háttérre másolni. Ezért létezik egy ún maszk, amely ugyanolyan pixel méretű mint az eredeti kép, és azt adja meg melyik pixeleket kell másolni.
 Fejlettebb rendszereknél ez a maszk nemcsak 0 és 1 lehet, hanem áttetszőséget is lehet szabályozni: pl. kék vízesés átlátszik. Ennek a szakkifejezése "alpha blending".
 Vannak rendszerek ahol megspórolták a maszkot, és kijelölték az egyik színt láthatatlannak, a többi pedig felülírja a hátteret.

 Azokon a rendszeken, ahol nincsen beépített sprite vezérlés, a processzor elkészíti vagy átmásolja a hátteret a video memóriába, majd erre rámásolja a mozgó tárgyakat akár maszkot használva. A probléma az, hogy a felülírt hátteret vissza kell állítani a következő képen, hogy újra rákerülhessenek a tárgyak az új pozícióban. Minél magasabb a háttér felbontása és bitmélysége, annál több időt igényel a visszaállítás.

 Az már egy előrelépés lenne ha lenne egy scrollozható háttér, és egy olyan előtér amire felmásolhatóak lennének a tárgyak, így csak törölni kellene az előteret a következő képváltás előtt. Csak törlés alatt azt értem hogy nem kellene fenntartani a memóriában a háttérből egy érintetlen példányt amivel felülírjuk a módosított képet. A nick 2.0 pedig ezt a hátteret és előteret rajzolná fel egymásra.
 Nem gondolnám hogy két sorparaméter táblát kellene fenntartani előtérnek és háttérnek, de az is baj, hogy nem nagyon van hely LD3 adatmezőnek a sorparaméter táblában.
 Esetleg a nem használt módban az utolsó 8 byte szín mezőt lehetne felhasználni LD3 és akár további pointereknek.

 
Title: Re: Nick 2.0
Post by: Zozosoft on 2023.April.22. 10:59:23
Javasolnám, hogy tanulmányozd az eredeti Nick-ben a külső színbemenetek működését, amire vonatkozik a SPRITE nevű EXOS rendszerváltozó. Rájönnél, hogy ezt az egész háttér kérdést már megoldották, és beépítették az eredeti Nick-be. Csak a spritéket kéne odakötni az EC drótok végére.
Title: Re: Nick 2.0
Post by: ergoGnomik on 2023.April.22. 12:34:23
Igazad van Zozo, csakhogy Tubynak azt a sprite kezelő logikát is meg kell valahogyan valósítania. Vagy legalábbis nekem úgy jött le, hogy nem egy kiegészítőt tervez az eredeti gépekhez, hanem egy teljesen új hardvert.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.November.09. 02:57:08
Jól néz ki! :smt023 Azonban lehet, hogy csak az én szememmel van valami baj, de nekem kicsit sárgásnak tűnik az új változat. Ez vajon mitől lehet?

Azért sárga, mert az EP-n a 8 biten a pirosnal és a zöldnek adtak 3 bitet , a kéknek csak 2-őt. Emiatt a kék nem tudja követni a másik két színt és hiányzik, ilyenkor sárgás lesz a kép.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.November.26. 16:28:11
Kiderült, hogy nem azért sárga. Azért volt sárga, mert elrontottam a PC-re C-ben írt kép konverter programot.

A hétvégén kicsit programozgattam. Találtam egy képet a neten, ami 24 bites színmélységű, és gondoltam átkonvertálom. Először borzasztó lett (lásd csatolmány). Ennek az az oka, hogy ahol 24 biten színátmenet van, ott a 8 bitesre levágás miatt sima egyszínűt ad.
 Ekkor kezdtem keresgélni, hogy milyen matematikai megoldással lehet "dithering"-ezni. Kétféle megoldás van, az egyik a 2x2 vagy 4x4-es mátrix alapú (mint kiderült nekem nem jó, mert sormintát hagy a képen), vagy pedig a Floyd-Steinberg eljárással, amit szerintem mindenki ismer.

 Már majdnem elkezdtem írni a programot hozzá, amikor kiderült, hogy ha Photoshop megkapja az "indexelt színlistát", melyet az EP tud, akkor ő is elő tudja állítani a ditherelt képet.
 Elkezdtem kézzel felvenni az EP színeket a phtoshop-ba, majd a 19. szín után (237 van még hátra) rájöttam, hogy az úgyis egy fájlba menti, megnézem a formátumát. Kiderült hogy nagyon egyszerű, mert egy indexelt színhez 3 darab Byte tartozik (piros-zöld-kék), majd a lista legvégén megadja hogy hány valid (használt) szín van. Írtam rá egy kis programocskát, ami létrehozta az EP 256 színét.
 Ezután a 320x240-es (lekicsínyített, de továbbra is 24bites) képre elkészítettem a dither-elt változatot. Ezt utána betöltöttem a módosított EP emulátorba.
 Kicsit változtatni kellett a Basic betöltőmön, mert a kép 320*240*1byte= 76800 Byte =  75kB, ami már nem fér el 4db "video" lapon, a basic betöltőm nem állt készen a 5. 16kB lapra. De pár órás hibakeresés után megcsináltam.

 Rendszer:
Enterprise Emulátor 256 kB (F0-FF szegmensek) - RAM amely a NICK 2.0-nak teljes mértékben címezhető a Graphics hires 4 képpont méretű, de 256 színű módban.
A képet az F4 szegmenstől F7 szegmensekig tároltam, majd amikor növeltem a függőleges megjelenítést, akkor az F8 szegmenset is felhasználtam.
Alapvetően a rendszer az 1. szabad szegmenst használja (az én esetemben a F0) ezért azt nem is bántottam.
A video memóriába sem akartam írni (FC-FF), mert azt felül szokták írni a grafikai rutinok.
 Azt csinálja a Basic betötőm, hogy nyit egy video lapot a képernyőre (mint helyfoglalót, amit nem változtat meg a rendszer) majd ennek módosítja a sorparaméter tábláját.
Ennek előnye, ha bármi gond van, akkro nyomok egy SHIFT+F5-öt és visszakapom a szöveges módot, látom a hibaüzeneteket stb.


Title: Re: Nick 2.0
Post by: Tuby128 on 2023.November.26. 18:30:57
Még egy-két példa netről szedett nagyfelbontású kép konvertálva.
Title: Re: Nick 2.0
Post by: szipucsu on 2023.November.26. 21:46:26
Azért nem rosszak ezek a képek!
Graphics hires 2 módban lenne brutális 255 szín.
These pictures are not bad!
255 colours in graphics hires 2 mode would be brutal.
Diese Bilder sind nicht schlecht!
255 Farben mit Graphics hires 2 Modus wären übercool.
¡Estas imágenes no son males!
255 colores en modo Graphics hires 2 serían brutal.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.November.27. 05:34:28
Nem tudom. Hires 2-ben a pixel nem négyzet alakú hanem függőlegesen hosszúkás. Ezt már korábban kifejtetettem, hogy hires 2-ben csak interlace használatával lenne a pixel négyzet.
 Másik dolog, hogy a 320x240 méretnél ahogy írtam 70kB körül van a kép mérete. Hires 2-ben 140kB lenne, interlace-szel pedig 280kB. Az azért nagyon sok, nemcsak betölteni, hanem kezelni is.
 Vizsgálgattam az akkori és későbbi japán hardverek felbontását, talán csak később a playstation 1 próbálkozott a teljes pal felbontás kihasználásával. De ott sem minden játékban.

 Még egy dolog amit meg kell említeni, hogy a tűéles képek, amiket közzétettem azok az emulátorból származnak. A TV-n ezek szépen megszűrve jelennek meg, a képet tovább javítva.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.December.26. 00:13:33
Újabb dolgon töröm a fejem, a scrollozást kellene javítani hardveres támogatással a NICK 2.0-ban.

Abból indulok ki, hogy egy teljes képernyős grafikus képet az LPT egyetlen blokkjában mint 240 soros grafikus kép deklarálnám.
Az adatmező memóriacíménél megadom, hogy hol kezdődik a memóriában, ahogyan a klasszikus NICK ezt tudja is.

Szeretném viszont megrajzolni a pályát a memóriában sokkal nagyobbra, mint amennyit a képernyő mutatni tud. Majd a látható képet mozgatnám "eltolás" byte-okkal. Az elotlás max akkora lehet mint a megrajzolt "nagy kép". Ezt sem x sem y irányban nem tudom 1 byte-on ábrázolni, legalább 1 byte és 1 bit kellene, de akkor már lehet 2 byte.

 A csatolmányba tettem néhány képet. A fekete vonalak a byte-okat jelentik a memóriában, ami egy hatalmas "hátteret" ír le. Minden új sor a kép új pixelsorát jelent, az egyik sor vége és a másik eleje egymás mellett vannak a memóriában. (mintha Asmon dump lenne).
 A piros négyzet a képernyő mérete által megjelenített byte-okat mutatja. Minden ami a piros négyzeten belül van, az meg lesz mutatva a képernyőn. Ami kívül esik, az nincs megmutatva, de elő van készítve.
 Azért lenne jó így csinálni, mert a piros képernyő mozgásakor a Z80-nak egy ideig semmi dolga nem lenne azon kívül, hogy lépteti a NICK eltolás vektorát. Közben előkészítheti a képernyőtartalmat a háttéren annak tudatában, hogy a játékban éppen merre járunk. Ezzel sokkal finomabb mozgást érnénk el, illetve csökkentenénk a Z80 munkáját.

 Az első képet megnézve látszik, hogy a klasszikus Nick ezt nem tudja a poszt elején említett egysoros deklaráció mellet, mert nem "ugorja át" a piroson kívül eső sorokat. Van ugyan rá lehetőség, de akkor sajnos minden pixelsort egyenként kellene a sorparaméter táblában deklarálni, ami akkor 240sor * 16byte = 3,75KB lenne. Ezt a 240 sort írogatni is kellene. Sok munka a Z80-tól.
 Másik dolog, hogy amikor a háttér egy sorának végéhez ér, akkor nem az utána következő sort kellene betölteni, hanem ugyanazt. (2. és 3. kép a csatolmányban)

Tehát az egyik újítás a NICK 2.0-nál ez lenne, hogy meg lehetne adni teljes háttér-szélességet, hogy a következő sor kezdőcímét ki tudja számolni az előző alapján: hozzáadná a háttér szélességet az előző sor kezdőcíméhez.
Ugyanezt megadjuk az pixel oszlopok miatt.

Tehát a sorparaméter tábla blokkja így nézne ki:

F900: x00 x01 x02 x03 x04 x05 x06 x07 x08 x09 x10 x11 x12 x13 x14 x15

x00: sor magassága (2-es komplemens) - innen jön a látható kép magassága
x01: sor módja (Nick 2.0 hires 4, 256 színnel -- 1 képpont=1byte)
x02: bal margó
x03: jobb margó (ebből a két értékből kapja meg a NICK a látható kép szélességét)
x04: kép kezdőcíme memóriában alsó byte
x05: kép kezdőcíme memóriában középső byte
x06: kép kezdőcíme memóriában felső byte (összesen 24byte - de nincs mind használva)
x07: foglalt/tartalék
--- itt kezdődnek a színdeklarációk, mivel 256 színnel dolgozunk, nincs szükség színre, elhasználjuk másra
x08: kép kezdőcím eltolása x irányba alsó byte
x09: kép kezdőcím eltolása x irányba felső byte (ezt kell növelni/csökkenteni a Z80-nak ahhoz hogy vándoroljon a látható kép X irányban)
x10: kép kezdőcím eltolása y irányba alsó byte
x11: kép kezdőcím eltolása y irányba felső byte (ezt kell növelni/csökkenteni a Z80-nak ahhoz hogy vándoroljon a látható kép Y irányban)
x12: háttér kép x mérete szorozva 2
x13: háttér kép y mérete szorozva 2 (azért kell a szorzás, hogy 8 biten ábrázolni lehessen max: 512-t)
x14: foglalt/tartalék
x15: foglalt/tartalék


Gyors számítás: ha háttér kép mérete 512x512 és képpontonként 1 byte (256 szín), akkor a háttérhez 512*512*1= 256k memória kell
Ez rengeteg, de a címbusz kiterjesztésével lehetséges.
SRAM használatával pedig a Z80 késleltetés nélkül képes a videomemóriába írni, ezzel minden követ elgörgettünk, hogy gyönyörű EP játékokat játszhassunk.
Title: Re: Nick 2.0
Post by: ergoGnomik on 2023.December.26. 06:52:41
... ezzel minden követ elgörgettünk, hogy gyönyörű EP játékokat játszhassunk.
Sajnos nem. :( Legfeljebb gyönyörű EP 2.0 játékokat. Kérdés, hogy hogyan lesz mindenkinek ilyen gépe és ki fogja írni azokat a játékokat? :(
Title: Re: Nick 2.0
Post by: Ferro73 on 2023.December.26. 08:57:41
... ezzel minden követ elgörgettünk, hogy gyönyörű EP játékokat játszhassunk.
A CPU meg legyen min 10MHz és legalább 2db.
Talán a bírnák az a mennyiségű másolást bájt mozgatást.
~LDIR (bájt*5)+4 /CLK 256*1024*5 1310720 clk , 4MHz 1sec 1000000 :) :)
Title: Re: Nick 2.0
Post by: Ferro73 on 2023.December.26. 09:15:51

~LDIR (bájt*5)+4 /CLK 256*1024*5 1310720 clk , 4MHz 1sec 1000000 :) :)
Nem CLK hanem M azaz CLK/4 vagy 5
Title: Re: Nick 2.0
Post by: gflorez on 2023.December.26. 10:40:03
Sajnos nem. :( Legfeljebb gyönyörű EP 2.0 játékokat. Kérdés, hogy hogyan lesz mindenkinek ilyen gépe és ki fogja írni azokat a játékokat? :(

Igazad van. Még ha lehetséges is lenne Nick és Dave továbbfejlesztett verzióit elkészíteni, csak néhány demó használná ki ezeket.

Nézd meg például a gigantikus Spectrum jelenetet, az ULA+ és az alternatív videomódokkal, amelyeket FPGA magokon lehetne megjeleníteni. Szinte nincs olyan program vagy játék, ami hasznot húzna belőlük.

És mégis, több trükköt húznak ki a stock gépből, mint valaha.

---

You are right. Even if it were possible to make improved versions of Nick and Dave, only a few demos would take advantage of them.

Look at the gigantic Spectrum scene for example, with ULA+ and alternative video modes that could be displayed on FPGA cores. There are almost no programs or games that could take advantage of them.

And yet, more tricks are being pulled out of the stock machine than ever before.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.December.26. 11:57:58
Gflorez think on the Tomamto made Banana game. And its sequal. The only thing which stops us to develop is the complexity and missing hardware support.
 
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.December.26. 14:52:14
A CPU meg legyen min 10MHz és legalább 2db.
Talán a bírnák az a mennyiségű másolást bájt mozgatást.
~LDIR (bájt*5)+4 /CLK 256*1024*5 1310720 clk , 4MHz 1sec 1000000 :) :)

Nem értetted meg szerintem a dolgot.

Ezeknél a régi gépeknél a max képfrissítés 25Hz (nem muszály ilyen gyorsan, lehe ennek a fele is). Ha 25Hz-zel scrollozza a képet 1 pixellel, akkor csak 1024 pixelt kell kirajzolni oszloponként erre van 1/25Hz=40ms ideje.
 Ha nem így csinálnám, hanem a teljes kép átírást választanám, akkor a CPU-nak 320x240 kép esetén 76.800 pixelt kellene kirajzolnia.
 Melyik a jobb 76k pixel kirajzolása vagy 1024db ?
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.December.26. 14:55:45
Sajnos nem. :( Legfeljebb gyönyörű EP 2.0 játékokat. Kérdés, hogy hogyan lesz mindenkinek ilyen gépe és ki fogja írni azokat a játékokat? :(

Senki nem vesz EP-t. Nagyon drága, akinek meg van, annak a dobozok ott porosodnak a másik szobájában.
Nehéz összekötni mai TV-vel. Kell neki a hely. Csak néhány elvetemült van, aki valódi gépet tart CRT tv-vel a szobában.
A kérdésedre a válasz:
1. Nem lesz mindenkinek ilyen.
2. Az fogja írni, aki letölti az EMU-t és kipróbálja, miket lehet.
Title: Re: Nick 2.0
Post by: gflorez on 2023.December.26. 17:06:32
Sorry, only in English:

I think that the logical way is to go for FPGA. Some time ago I put here a link about a Spanish non-profit add-on named Poseidon (http://retrowiki.es/viewtopic.php?f=120&t=200039734) where to connect a cheap Chinese QMTech FPGA.

It will have a cut down price of about 100€, that added to the QMTech FPGA will amount less than 200€. Ok, a box if necessary will cost les than 20€.

At the moment there are more than 10 converted cores including the EP.

For me, one of the most important features of this FPGA add-on is the big expansión conector at the side, enough for an Enterprise expansión port. Yes, it is intended for connecting real computer hardware through a level shifter intermediary PCB. The computer cores could become hybrid with this FPGA. This is not new, for example, classic Spectrum hardware can be connected to the ZXNext or its NGo clone.

I am not writing about something to be launched on the future, Kyp(and all the Retrowiki FPGA team) are just now testing thoughtfully the prototypes, and very soon Manuferhi will put the price in his web (https://manuferhi.com/c/poseidon).

Enhanced versions of Nick and Dave will live happily inside a FPGA, I have no doubt.
Title: Re: Nick 2.0
Post by: Ferro73 on 2023.December.26. 17:28:34

Ezeknél a régi gépeknél a max képfrissítés 25Hz (nem muszály ilyen gyorsan, lehe ennek a fele is). Ha 25Hz-zel scrollozza a képet 1 pixellel, akkor csak 1024 pixelt kell kirajzolni oszloponként erre van 1/25Hz=40ms ideje.
 Ha nem így csinálnám, hanem a teljes kép átírást választanám, akkor a CPU-nak 320x240 kép esetén 76.800 pixelt kellene kirajzolnia.
 Melyik a jobb 76k pixel kirajzolása vagy 1024db ?
Hát ezt már tényleg nem értem.
A két margó között, hogy fog elférni a 320 pixel bájt?
Mennyire lenne kompatibilis a régi LPT táblával?
Ennyi erővel lehetne Dual NICK.
Bár még nem látom át.
Valami olyasmi lenne mint az EXOS EDITOR:,DISPLAY csak az függőleges?
Vízszintesen pedig minden .....
Akkor minek NICK2 a  VGA vezérlő integrálása lehet eredményesebb lenne.
Title: Re: Nick 2.0
Post by: Tuby128 on 2023.December.26. 21:21:16
"A két margó között, hogy fog elférni a 320 pixel bájt?"

Onnan indul a dolog, hogy nem jó topikba írtam tegnap. A Nick 2.0-ba akartam, már szóltam a modiknak, de gondolom karácsonyoznak.
Ha megnyitod a NICK 2.0 topicit és elmész a legvégére, akkor láthatod a képeket amiket az általam kitalált módban készítettem. Ekkor a két margó között 320 képpont lesz 256 színnel/pixel:
https://enterpriseforever.com/hardver/nick-2-0/
Szóval már mintám van rá.

"Mennyire lenne kompatibilis a régi LPT táblával?"
Az LPT táblában van egy nem használt mód. Azt szeretném erre az új színmódra elhasználni, a diszlokációval (képtolással) együtt. Ebben a módban a NICK akkor nem 64kB memóriával, hanem 256kB vagy mégtöbbel rendelkezne.
 
"Ennyi erővel lehetne Dual NICK."
 Nincs kizárva, hogy a klasszikus nick a Nick 2.0-val együtt működjön.

"Valami olyasmi lenne mint az EXOS EDITOR:,DISPLAY csak az függőleges?"
Igen, most hogy mondod. Ott is ez van, pontosan!

"VGA vezérlő integrálása lehet eredményesebb lenne."
 VGA vezérlőre nem vállalkozom. Ezt csinálja más.
Title: Re: Nick 2.0
Post by: Tuby128 on 2024.January.04. 15:50:23
Továbbgondotam a témát.
 Általában a Z80-as rendszerekkel az a baj, hogy hiába fejlesztek ki 8bit/pixel, vagy ettől magasabb képmegjelenítést, ha a memória töltögetése rengeteg processzoridőbe telik, és a Z80 nem igazán tud ekkora mennyiségű adattal dolgozni.
 Az EP karakteres megjelenítési módja (más gépeknél a csempe alapú rendszer) pont erre van kitalálva. Meghatározott csempeméretek esetén megsprórolható rengeteg byte.
 320x240 és 1byte/pixel esetén a videomemóriában kell 72KB hely. Ez csak a "frame buffer, tehát amit látunk". Emellett szükség van memóriára, ahol a képelemeket tárolom. A játék nagyságától függően ez lehet akár ennek 2-3-4 szerese. Mai hardverrel nem probléma 3MB-ig kiterjeszteni a memóriát, csak nem szabad elfelejteni, hogy 8 MHz-es CPU-val dolgozunk, neki is van más dolga.
 HA 8x8-as "karakterekkel dolgozom, akkor a 72KB / [8pix x 8pix ]  = 1,12 KB elég a képtartalom vezérlésre. 16x16 csempe esetén ennek fele kb. 0,6 KB elég.

A másik dolog, hogy sok játéknál a padló/falak stb. ismétlődő sormintával rendelkeznek, tehát felesleges ezeket rajolgatni nagy mennyiségben.

 Tehát arra jutottam, hogy az új módban, ahol 256 színnel dolgozok, kiterjesztem választhatóan 8x8 pixeles vagy 16x16 pixeles "karakteres módra", ahol a LD1 címen lévő 1BYTE/karakter adathalmazzal kijelölöm, hogy az LD2 címen lévő 8x8 vagy 16x16 és 1byte/pixel képecskékből melyiket kérem a képernyőre.

 További extra a látható kép diszlokációja (eltolása x és y irányban) lehetséges lesz, azaz megadható, hogy egy adathalmazt hol kezdjen el olvasni. Ezzel a könnyű és gyors scrollozást szeretném bevezetni, mint ahogyan az EDITOR működik a basicben. Az egyszerűség és gyorsaság kedvéért úgy fogom megoldani, hogy kiad egy
OUT 8C,xx utasítást, ahol a 8 bit így néz ki
(MSB) xxxxyyyy (LSB)
xxxx egy előjeles eltolási érték ami lehet min:-6 és max:+6. A "1000" értéket megadva reseteli az eltolást 0-ra.
Egyszer kiadva az eltolási paracsot, csak egyet tol a képen. A következő eltoláshoz ismét ki kell adni. Az eltolás parancs megvárja amíg a félkép befejeződik és csak utána lesz érvényes, hogy ezzel elkerüljük a sorok közötti elcsúszást (screen tearing).

 Még egy extra kellene szerintem, hogy az LD1 és LD2 mellett bevezetném az LD3 mezőt, ahonnan egyszerre olvasná a pixeleket az LD1-gyel, és a kedves programozó döntené el, hogy a két háttérképet hogyan kombinálja:
00: LD3 nincs megjelenítve
01: LD1 hátul LD3 elöl (LD2-ben valamelyik szín a 256-ból nem írja felül (áttetsző) a LD1 pixeleit)
10: teszt: LD1 és LD3 összeadódnak, és azt jelenítjük meg
11: teszt: LD1 és LD3 pixelei kivonódnak, és azt jelenítjük meg
 
 A sprite ok tárolásán gondolkodok még. Nem hiszem hogy a háttérrel kellene spekulálni. Kellene egy 8x8-as SPRITE táblázat, ahol deklarálni lehet a SPRITE-okat, és eldönteni, hogy hol legyenek megrajzolva: LD1 háttér mögött, LD1 és LD2 között, LD2 előtt.
 Erre nem nagyon tudok más megoldást, mint NICK 2.0-ban tárolt SPRITE táblázat, és memóriában tárolt alakzat. A sprite mérete még kérdéses, majd a tesztek megmutatják meddig lehet elmenni.
Title: Re: Nick 2.0
Post by: Tutus on 2024.January.05. 11:07:50
Erre nem nagyon tudok más megoldást, mint NICK 2.0-ban tárolt SPRITE táblázat, és memóriában tárolt alakzat. A sprite mérete még kérdéses, majd a tesztek megmutatják meddig lehet elmenni.
Nick 2.0 ...
Mondanál erről valami infót? Kivel gyártatod majd le?
Nem tudom, olvastad-e az Issue7 ezzel kapcsolatos infóit?
Szerinted jó az, ha két úton indulunk? Te a Nick 2.0-val, mi meg a másikkal?
Jó lenne, ha ez a kis közösség összetartana :)
Title: Re: Nick 2.0
Post by: ergoGnomik on 2024.January.05. 11:38:18
Persze, hogy olvasta! Még hozzá is szólt, ha olvastad az erről nyitott fórumtémát. A két projekt teljesen eltérő irányban halad. Az Issue 7 kompatibilis kíván maradni az eredeti hardverrel, de kiegészítené az alaplapot a ma elérhető szolgáltatások egy részével és esetleg hozzáadna kompatibilitást nem megváltoztató újabb bővítményeket. A Nick 2.0 teljesen új alapokra helyezett, látszólag a rendszer szűk keresztmetszeteit jelentősen kitágító, felülről részlegesen kompatibilis Enterprise változat szeretne lenni.
Title: Re: Nick 2.0
Post by: Tutus on 2024.January.05. 12:22:43
Persze, hogy olvasta! Még hozzá is szólt, ha olvastad az erről nyitott fórumtémát. A két projekt teljesen eltérő irányban halad. Az Issue 7 kompatibilis kíván maradni az eredeti hardverrel, de kiegészítené az alaplapot a ma elérhető szolgáltatások egy részével és esetleg hozzáadna kompatibilitást nem megváltoztató újabb bővítményeket. A Nick 2.0 teljesen új alapokra helyezett, látszólag a rendszer szűk keresztmetszeteit jelentősen kitágító, felülről részlegesen kompatibilis Enterprise változat szeretne lenni.
Oké, értem én :) A kérdés igazán arra volt kihegyezve, hogy hogyan valósítja meg ezt kézzel fogható Nick 2.0 formájában :)
És hogyan cseréli majd le a meglévő, régi Nick helyett?
Ha én (mi, mint közösség) lemondtunk erről a projektről, akkor? ... Oké, én örülnék ha sikerülne!
Én ezzel kapcsolatban semmi segítséget és támogatást nem kaptam (kb. hülye ötlet volt részemről, úgy érzem...).

Az Issue7-nél is: ki garantálja majd azt, hogy a donor alaplapból sérülésmentesen kiforrasztja majd a Nick-et és Dave-et?
Ezt senki nem kérdezte, de én most felvetem ezt! Lehet, hogy rossz helyen, de majd átteszem az Issue7 topicba is ezt a kérdést.
Title: Re: Nick 2.0
Post by: Tuby128 on 2024.January.05. 15:04:11
Oké, értem én :) A kérdés igazán arra volt kihegyezve, hogy hogyan valósítja meg ezt kézzel fogható Nick 2.0 formájában :)
És hogyan cseréli majd le a meglévő, régi Nick helyett?
Ha én (mi, mint közösség) lemondtunk erről a projektről, akkor? ... Oké, én örülnék ha sikerülne!
Én ezzel kapcsolatban semmi segítséget és támogatást nem kaptam (kb. hülye ötlet volt részemről, úgy érzem...).

Az Issue7-nél is: ki garantálja majd azt, hogy a donor alaplapból sérülésmentesen kiforrasztja majd a Nick-et és Dave-et?
Ezt senki nem kérdezte, de én most felvetem ezt! Lehet, hogy rossz helyen, de majd átteszem az Issue7 topicba is ezt a kérdést.

Issue 7-re Kvaczko ezen megoldásával lehetne nick-et (és dave-et) varázsolni.
https://enterpriseforever.com/hardver/enterprise-issue7-alaplap/msg89892/#msg89892

 Régi alaplapokra nincs nagyon megoldás mert TQFP tokozású régi nick helyére nem tudunk semmilyen pcb-t tenni. Esetleg a Z80 furatszerelt helyére tennénk egy olyan FPGA-t amiben a Z80 és a Nick integrálva vannak. Így a Nick memóriahozzáférése megtörténne egy helyen, nem zavarná a Z80 a dave-et, és fordítva.

 A harmadik megoldás egy külső nick lenne a expansion konnektoron. Nyilván meg kell oldani, hogy a video megszakítás valahogy visszajusson a EP lapjára. Illetve ha nincs benne NICK, akkor a video memória olvasása nagyon problémás a Dave miatt. Külső Nick-nek igazán nincs sok értelme.
 A Z80 helyére kell a trükközést betenni, nincs más megoldás.
Title: Re: Nick 2.0
Post by: Ep128 on 2024.January.05. 22:32:06
Ez az, hogy eleve nem is kellene kiforrasztani semmit sehonnan. Le kellene gyártatni újra a NICK -et és a DAVE -et is. A fene sem akar régi alaplapokat gyilkolászni és "hátha sikerül" -alapon nekiesni a kiforrasztásoknak.
Title: Re: Nick 2.0
Post by: Tuby128 on 2024.January.05. 22:45:30
Ez az, hogy eleve nem is kellene kiforrasztani semmit sehonnan. Le kellene gyártatni újra a NICK -et és a DAVE -et is. A fene sem akar régi alaplapokat gyilkolászni és "hátha sikerül" -alapon nekiesni a kiforrasztásoknak.
Szerintem pedig le kellene adni a rendelést újabb 100.000 Enterprise 128-ra. Jó reklámmal azonnal el is lehetne adni az egészet:
https://www.youtube.com/watch?v=QOAbKfxwkjk
Title: Re: Nick 2.0
Post by: Ep128 on 2024.January.06. 22:36:35
Szerintem pedig le kellene adni a rendelést újabb 100.000 Enterprise 128-ra. Jó reklámmal azonnal el is lehetne adni az egészet:
https://www.youtube.com/watch?v=QOAbKfxwkjk
Vicces vagy, mint tengeralattjárón a rácsos ablak...
(Ha 100 db. -ot sikerülne legyártatni mindkettőből, az unokáinknak is elég lenne.)
Sem az eredeti alaplapok szempontjából, sem a NICK / DAVE szempontjából nem jó 5let a "kiforrasztósdi"! Tutus is említette már, kért is segítséget, hogy nézzünk szét, hol lehetne megoldani az újragyártást, de eddig kb. nulla embernek volt ötlete. :-(