Welcome, Guest. Please login or register.


Author Topic: NICK (Read 225339 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #210 on: 2012.February.09. 08:39:30 »
A "nem használt" módban esetleg a paletta byte-ok felhasználhatók más célra ?


Hasonlo "orult" otletem volt egyszer, hogy a harom (?) utolso nem hasznalt nick slot-ot (dram frissites, vagy mi is van ott) egy "nick+"-on lehetne arra hasznalni "custom data" olvasasara, igy pl akar lehetne digital sample lejatszas nulla CPU idovel :-P persze erdekes, hogy a dave "hang" dolgai mellett a nick hogy jon ide, de a nick legalabb kezdemenyezhet memoria olvasast, a dave ugye nem .... Nyilvan ehhez bufferelni kell persze, hiszen nem "folyamatos" az olvasas ahogy kell, hanem minden scanline vegen (?) lehet csak. Stb stb.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #211 on: 2012.February.09. 09:25:58 »
Igen szerintem is ennek 2x üzemmódnak lenne értelme. Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül. És hozzá még hw spriteok varázsolni... (sprite rendszerek terén körbe kéne nézni Z80-as konkurenciánál, mert ha sikerülne valamely létezõ masinát leutánozni, akkor onnan lehetne áthozni játékokat is. Pl ha jól tudom MSX környéken érdemes lenne nézelõdni.)

Offline Tuby128

  • EP addict
  • *
  • Posts: 1485
  • Country: hu
Re: NICK
« Reply #212 on: 2012.February.09. 19:03:09 »
Hardveres sprite vezérlõvel lehetõség nyílik a grafikus felhasználói felületen a nyílmutató mozgatására különösebb processzorhasználat nélkül.
 PC-n úgy oldja meg a Windows GUI, hogy: (mondok példát)
Van egy 600x500-as ablak, amiben ki van feszítve egy azonos méretû bitmap, és ez a háttér. Ebben szeretnénk elhelyezni egy piros teli kört, melynek átmérõje 50 képpont. Mivel a kör egy 50x50-es bitkép a körön kívûl esõ (de még az 50x50-es ablakban lévõ) pontok 0-ra vannak megválasztva.
Amikor ezt kirajzolom, akkor ezek a nullák is rákerülnek a képre, és nem kör jelenik meg, hanem fekete négyzet benne egy körrel. Bármilyen módot választottam a kirajzolásra (bitenkénti OR vagy AND vagy XOR), a négyzet akkor is kirajzolva maradt.
 Ezután hosszasan keresgélve találtam egy olyan függvényt, amely a következõket engedte meg:
Ha készítek az 50x50-es bitképhez egy "maszkot", ami ugyanolyan méretû, és ahol azt akarom, hogy kirajzolásra kerüljön ott '1'-ek vannak ahol pedig nem ott nullák. Így akár "lyukas" ábrák is készíthetõk.
 Ehhez már egyre bonyolultabb HW kell, vagy egyre erõsebb CPU.

 Úgy veszem észre, fõleg nálad Zozo, hogy minden perifériális mûveletet hardveresen akarsz megoldani, hogy a Z80-nak a lehetõ legkevesebb mûveletet kelljen végrehajtania.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #213 on: 2012.February.09. 22:19:38 »
Igen szerintem is ennek 2x üzemmódnak lenne értelme. Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül. És hozzá még hw spriteok varázsolni... (sprite rendszerek terén körbe kéne nézni Z80-as konkurenciánál, mert ha sikerülne valamely létezõ masinát leutánozni, akkor onnan lehetne áthozni játékokat is. Pl ha jól tudom MSX környéken érdemes lenne nézelõdni.)

Sajna a sprite kezeles eleg trukkos. MSX-eknel is valami olyan volt h limitalt mennyi sprite tartozkodhat egy scanline-ba (a veges rendelkezesre allo ido miatt), C64-en meg pl konkretan igen komoly idozitesi gondok adodnak amikor a VIC-II ugy dont, hogy neki tobb ido kell (viszont ott nincs korlat, 8 sprite barhol lehet, nyilvan sprite multiplexinggel tobb is lehetseges pl raster irq-bol allitgatva menet kozben).

De a legfobb problemat ott latom, hogy a sprite milyen olyan mar kevesbe LPT/LPB specifikus, hiszen pont az a lenyege, hogy "barhol" lehet, es egyszeruen oda is rakhato (1-2 reg atirasaval). Szoval ez viszont mar az a tema, amihez tenyleg kulon I/O port kell. Plusz kell Nick v2.0-nak ido hogy olvassa a sprite pixel adatokat kulon ... Esetleg olyan "extra" eljaras, hogy LPB extra byte-jaiba (mondjuk ha x2 uzemmod aktiv, vagy magasabb, akkor oda lehet ilyet is tenni) "encode"-oljuk magat a sprite adatot, igy annyi sprite lehet ami ebbe belefer. Igy viszont egy frame alatt nem valtozhat, ami mondjuk kevesbe is problema imho, mert ugyse lathatoak nagyobb frissitessel :) Plusz akkor maga a sprite pozicionalis is lehetne (elvileg) valahol (hmm vsync mod alatt, hasonlo?), es akkor onnan "felszedi" minden frame elejen, igy nem kell kulon globalis I/O regiszter, hanem az LPT egy kvazi jol definialt helyen vannak benne ezek az adatok is. Esetleg bevezetni egy LD1, LD2 melle egy LD3-at: szinten az extra LPB byte-okba, es az mutat a sprite terulet kezdetere, stb stb, whatever.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #214 on: 2012.February.09. 22:28:07 »
Hardveres sprite vezérlõvel lehetõség nyílik a grafikus felhasználói felületen a nyílmutató mozgatására különösebb processzorhasználat nélkül.
 PC-n úgy oldja meg a Windows GUI, hogy: (mondok példát)
Van egy 600x500-as ablak, amiben ki van feszítve egy azonos méretû bitmap, és ez a háttér. Ebben szeretnénk elhelyezni egy piros teli kört, melynek átmérõje 50 képpont. Mivel a kör egy 50x50-es bitkép a körön kívûl esõ (de még az 50x50-es ablakban lévõ) pontok 0-ra vannak megválasztva.
Amikor ezt kirajzolom, akkor ezek a nullák is rákerülnek a képre, és nem kör jelenik meg, hanem fekete négyzet benne egy körrel. Bármilyen módot választottam a kirajzolásra (bitenkénti OR vagy AND vagy XOR), a négyzet akkor is kirajzolva maradt.
 Ezután hosszasan keresgélve találtam egy olyan függvényt, amely a következõket engedte meg:
Ha készítek az 50x50-es bitképhez egy "maszkot", ami ugyanolyan méretû, és ahol azt akarom, hogy kirajzolásra kerüljön ott '1'-ek vannak ahol pedig nem ott nullák. Így akár "lyukas" ábrák is készíthetõk.
 Ehhez már egyre bonyolultabb HW kell, vagy egyre erõsebb CPU.

 Úgy veszem észre, fõleg nálad Zozo, hogy minden perifériális mûveletet hardveresen akarsz megoldani, hogy a Z80-nak a lehetõ legkevesebb mûveletet kelljen végrehajtania.

Na ez erdekes velemeny :) Te mondod, hogy tul kene lepni a vsync-en meg par probleman, erre viszont pont a "tullepesert" panaszkodsz, ha mas temaban mas teszi ezt :) Imho akkor van ertelme vmit hw-esen megoldani, ha az amugy nem tul bonyolult: marpedig sprite nagyon sok 8 bites gepen volt, tehat nem lehetetlen megoldani nyilvan. Plusz, erdekes, hogy modern PC-kben kb mindent "nem a CPU" csinal (lasd 3D grafika, fizikai gyorsitas, stb), az talan nem gaz, ha adsz egy kis pluszt egy regi gepen is (foleg, mivel ott nagyobb szukseg van ra, eleve gyengebb a cpu mint egy mai pc-n!), felteve, ha amugy ez csak extra, amit nem kotelezo hasznalni, es nem hasznalva azt 100% a kompatibilitas.

Masreszt, azert modern PC-re irt, modern GUI-k sok esetben szinten sprite szeru entitasokat hasznalnak, csak ott a vga kartya csinalja. Meg ha csak 2D-only-ban gondolkozunk ott is van hardware-es BES altalaban (Back-End Scaler, esetleg color space koverzioval mint YUV stb, color key), kulonbozo copy/stb muveletek, es hasonlok. Ilyen mar egy viszonylag "oskori" kartyan is van, mint amilyen az S3 Trio pl (na jo, persze egy Trident 8900-ashoz kepest - ha jol remlik h mi is volt nekem anno -, ez mar haladas ...).

Offline geco

  • EP addict
  • *
  • Posts: 7219
  • Country: hu
    • Támogató Támogató
Re: NICK
« Reply #215 on: 2012.February.10. 09:29:11 »
Igen szerintem is ennek 2x üzemmódnak lenne értelme. Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül. És hozzá még hw spriteok varázsolni... (sprite rendszerek terén körbe kéne nézni Z80-as konkurenciánál, mert ha sikerülne valamely létezõ masinát leutánozni, akkor onnan lehetne áthozni játékokat is. Pl ha jól tudom MSX környéken érdemes lenne nézelõdni.)

Igen, MSX, abból is az MSX II lenne érdekes, meg az Amstrad CPC+.

Offline Pgyuri

  • EP fan
  • *
  • Posts: 156
Re: NICK
« Reply #216 on: 2012.February.10. 15:04:44 »
Üdv,

Előre is elnézést kérek a hozzászólásomért, én csak egy egyszerű ZX szoftveres vagyok, tessék figyelembe venni.

Teljesen megértem lelkesedését hardver guruknak a téma iránt és jó is az elmélkedés, de ...

... számomra megfoghatatlan, mire is lenne jó ezt a kedves kis Enterprise-t bővíteni ilyen grafikai és sprite dolgokkal:

1; Először is nem lenne senki, aki írna új játékokat, amelyek kihasználnák.
2; Ha lenne is, akkor se lesz mindenki gépe átalakítva ehhez az újdonsághoz.
3; A régi játékok "tuning"-olásának sincs értelme.

Ilyen ötletek mindig is voltak a régi gépekhez, pl. real-time óra bővítés, de az is minek, mikor egyetlen egy program se kérdezi le.

A témához kapcsolódóan idézet egy korábbi hozzászólásból (talán itt lesz a helye Zozo):

"Idézném a Speccyalista napon elhangzott beszélgetés részletét:

 PGyuri: Mire tervezték az EP-t?
 Moldani: A világ legjobb számítógépét akarták megcsinálni!"

Nos ez egyértelműen nem sikerült, mert ha azt szerették volna, akkor egyrészt a SPRITE fogalmát nem hagyták volna ki (mondjuk tervez(het)ték hozzá), de a leglényegesebb elemet akkor se felejthették volna el, mégpedig a

               gyors horizontális scroll lehetőségét !

Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyő mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függőleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi). De kihagyták, elfelejtették. Spectrumon sokat gondolkoztam, hogy ottani hardver mestereinket meggyőzöm egy interface készítésével, amely képes a scroll műveletét elvégezni a processzor helyett, de mindig arra jutottam, hogy úgyse lenne rá program, így felesleges még a gondolatával is foglalkozni.

Ettől függetlenül szívesen olvasom Nick úr minden lépését :)

Pgyuri

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #217 on: 2012.February.10. 15:24:37 »
               gyors horizontális scroll lehetõségét !

Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyõ mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függõleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi). De kihagyták, elfelejtették.

Igen, ezért is javasoltam korábban:
Quote
Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #218 on: 2012.February.10. 15:38:51 »
Amit a NICK gyárilag tud sprite ügyben: van neki 4 bites szín bemenete, ami ki van vezetve a rendszerbuszra. Szintén a buszon vannak a szinkronjelek, és a videóórajel, ennek segítségével lehetne a külsõ sprite hw szinkronban a képpel, hogy a megfelelõ helyen adja a megfelelõ szín információt.
A 80h regiszteren lehet szabályozni, hogy mi történjen a külsõ színekkel:
-mindig a kívül megadott szín jelenik meg
-a külsõ szín jelenik meg, ha a képen a 8-15 színek vannak használva
-a külsõ szín jelenik meg, ha a képen a 8-15 színek vannak használva, vagy ha 0-7 külsõ színek vannak használva
-a külsõ szín jelenik meg, ha a képen a 8-15 színek vannak használva, vagy ha 0-3, 8-11 külsõ színek vannak használva
(Ezt állíthatjuk a Sprite EXOS változóval.)

Mivel gyakorlatban még nem készült (vagy legalábbis nem jelent meg) ezt kihasználó hw, így nem tudni, pontosan mi is történne enne használatával, különös tekintettel a különbözõ színmódokra. Nem tartom elképzelhetetlennek azt se, hogy esetleg 2 szín módban is legyenek 16 színû sprite-ok.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #219 on: 2012.February.10. 20:03:04 »
... számomra megfoghatatlan, mire is lenne jó ezt a kedves kis Enterprise-t bővíteni ilyen grafikai és sprite dolgokkal:

Imho azert, mert ha valaki realizalja a cucot egy FPGA-ban, ami ugye vmi leiro HDL nyelven leirja a hardware-t, akkor a dolgok oroszlanresze az lenne, hogy megcsinalni - lehetoleg pontosan! - azt amit az eredeti Nick tudott, es semmi tobbet. Ez azert nem olyan kis munka, ha belegondolunk. De szerintem legalabbis ezen a szinten az lenne a cel, hogy legyen EP "tokeletes minosegu" videokimenettel pl monitorok szamara, illetve deffektes Nick helyettesitesere stb. Nu, ehhez kepest mar nem olyan nagy szam, ha egy-ket extrat beletesz az ember, ha mar az egesz "vaza" adott. Akkor meg jon a "miert ne" kategoria. Jo peldanak tartom erre a C64DTV-t: ugye az uzleti cel az volt hogy legyen egy kis joystick dimenzioban merheto cucc rajta csomo jatek, C64-es kesz. Erre Jeri Ellsworth csinalt valamit, ami fura dolognak hathat: pl 2Mb memoria van, uj videomodok, kothetsz ra PS/2 billentyuzetet, drive-ot, stb. A kerdes ugyanaz, amit te is emlitesz: ezt minek, ha egyszeruen megvolt a cel azzal is, hogy egy sima C64-et ugy emulalni, ahogy anno ment. A valasz Jeri reszerol is ez volt: nem olyan sok extra plusz megcsinalni ezt, ha mar az erdeti emulacio ugy is megvan, akkor miert ne?

Quote
1; Először is nem lenne senki, aki írna új játékokat, amelyek kihasználnák.
2; Ha lenne is, akkor se lesz mindenki gépe átalakítva ehhez az újdonsághoz.
3; A régi játékok "tuning"-olásának sincs értelme.

Magyaran, nincs ertelme semmi de semmi ujnak. Ertem en, hogy valaki igy latja, en nem :) Szamomra a "8 bit kerdese" nem annyi, hogy nosztalgia, eljuk ujra a multat, pont ugy ahogy volt (kvazi idoutazas), hanem: az uj korban hasznaljuk fel, az uj technikakba integraljuk bele, azaz ne (csak) mint muzeumi targyat kezeljuk, hanem probaljuk megmutatni, hogy modern kornyezetben is jo hobby, pl ethernet illesztes, stb stb. Ezen tovabb haladva: ha megszunt az eredeti CBM ceg (Commodore Business Machines), vagy a Sinlair Ltd stb (marmint abban az ertelemben ahogy anno volt, tudom most is van valami Sinclair nevu ceg), akkor en akkor latom "elonek" a 8 bit scene-t, ha az fejlodik, mintja az azt taplalo cegek meg mindig kiadnak az ujabb es ujabb hw-ket. Mivel ilyen nem tortenik (a C64DTV hatareset - bar sok szempontbol tekintheto egy "hivatalos" uj C64-nek is), ezt magunknak kell elvegezni. Ha ilyen nincs, akkor viszont ez csak a regi idok visszaidezese a jelennel valo kapcsolat nelkul. Na en igy fogom fel, de ismetlem: ez az EN velemenyem, nyilvan nem kotelelzo vele egyet erteni :) Sw oldalrol is: uj OS irasa, tcp/ip networking stb.

Quote
Ilyen ötletek mindig is voltak a régi gépekhez, pl. real-time óra bővítés, de az is minek, mikor egyetlen egy program se kérdezi le.

Ez nem igaz. Meg a C64-nak is van ugymond belso oraja, mashol is lehet, ha maskepp nem, hat software-esen. Ez anno is letezett. Amiben jo lehet egy realm-time ora: kepes ezt beallitani, hogy nullarol induljon minden bekapcsolaskor. Ez imho mar egy ertelmes cel, ha mast valaki nem is lat bele :)


Quote
A témához kapcsolódóan idézet egy korábbi hozzászólásból (talán itt lesz a helye Zozo):

"Idézném a Speccyalista napon elhangzott beszélgetés részletét:

 PGyuri: Mire tervezték az EP-t?
 Moldani: A világ legjobb számítógépét akarták megcsinálni!"

Nos ez egyértelműen nem sikerült, mert ha azt szerették volna, akkor egyrészt a SPRITE fogalmát nem hagyták volna ki (mondjuk tervez(het)ték hozzá), de a leglényegesebb elemet akkor se felejthették volna el, mégpedig a gyors horizontális scroll lehetőségét !

Ez azert kisse radikalis :) Nyilvan soha nem lehet tokeleteset alkotni. Meg ha vegtelen penz/ido lenne ra, akkor sem. Hat meg ha az eroforrasok nem vegtelenek! Az EP viszonylagosan nem tul nagy nepszerusege annak "koszonheto", hogy tul sokaig keszult a bejelentes es eredeti tervekhez kepest, anno tenyleg durvan hangzott, mire megjelent, akkor sem volt rossz, de megis tul sok ido telt el. Nyilvan huzhattak volna meg tovabb, hogy meg tobb dolgot pakoljanak bele, de meddig? Mar igy is keso volt. Plusz sprite: akartam irni, de latom Zozo megelozott: erre gondoltak, a kezdemenye ugymond benne is van, az EXTCOL dolgok. Ha jol tudom (Zozo imho jobban tudja, majd kijavit, ha nem): ez pont azert keszult, hogy akkor legalabb kesobb lehessen hozza "kivulrol" ilyet lleszteni, ha mar bele nem kerulhetett. Azaz ebbol - szerintem - az kovetkezik, hogy igenis gondoltak ra, csak nem maradt ra ido (?), penz (?), de azt, hogy ezt belepakoltak meg, mutatja, hogy meg akartak hagyni a lehetoseget, hogy utolag legalabb konnyen illeszheto legyen.

Masreszt: azt hogy talalsz egy, ketto, par problemat: igen. Tokeletes dolog nincs, ilyen elven mondj egy dolgot a vilagon, ahol sikerult barmibol a tokeleteset megalkotni :) Imho nincs ilyen, a vilag tokeletlen. Mindenhol van egy kis folt, problema, stb. Meg ha az almok szepek is.

Ne azt nezd, hogy nem sikerult elerni - az amugy is lehetetlen - celt, hogy legyen tokeletes. Hanem azt, hogy mit sikerult elerni, osszehasolitva a hasonlo ar/celkozonseg/stb kategoriaba eso gepekhez kepest. Nos igen, itt csorbul kicsit a dolog, hogy tul sokaig "jott kifele" az uj gep. Meg igy sem rossz azonban szerintem! osszehasonlitas alatt meg teljesitmenyt, tudast, feature-oket, bovithetoseget stb ertek konkretan.

Quote
Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyő mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függőleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi). De kihagyták, elfelejtették. Spectrumon sokat gondolkoztam, hogy ottani hardver mestereinket meggyőzöm egy interface készítésével, amely képes a scroll műveletét elvégezni a processzor helyett, de mindig arra jutottam, hogy úgyse lenne rá program, így felesleges még a gondolatával is foglalkozni.

Ertem en a fajdalmadat a horizontalis scroll kapcsan, de imho ez egy igen egyszeru dolog. Nem hinnem, hogy azert hagytak ki, mert ezt annyira nehez lehetett volna megoldani. Talan ido nem volt ra, nem gondoltak bele, stb; az ember nem tokeletes. Ez kisse mas, mint a sprite: imho azt nehezebb megoldani, ott mar konkretan penz/anyag/ido problema sokkal jobban jelentkezhet.
« Last Edit: 2012.February.10. 20:07:04 by lgb »

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #220 on: 2012.February.10. 20:50:57 »
Ilyen ötletek mindig is voltak a régi gépekhez, pl. real-time óra bõvítés, de az is minek, mikor egyetlen egy program se kérdezi le.
Ez EP esetén rossz példa :-) Eleve az EXOS-nak rendes óra+naptára, ami 2079.12.31-ig mûködik, órakártyát több program is kezeli, pl a Zozotools másodpercenként szinkronizálja a szoftveres órát a hardvereshez. Egy rendes lemezes rendszer esetén ez hasznos dolog, hogy lehet tudni melyik fájl mikori.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #221 on: 2012.February.10. 21:03:00 »
Ez EP esetén rossz példa :-) Eleve az EXOS-nak rendes óra+naptára, ami 2079.12.31-ig mûködik, órakártyát több program is kezeli, pl a Zozotools másodpercenként szinkronizálja a szoftveres órát a hardvereshez. Egy rendes lemezes rendszer esetén ez hasznos dolog, hogy lehet tudni melyik fájl mikori.

Jah, C64-nel pl az IDEDOS stb eseten pont ugyanigy hasznos az ilyen feature. :) Persze, ha valaki csak arra hasznalja, hogy "megnezhetem mennyi az ido", akkor sok ertelme nincs. De akkor PC-n sem, ilyen elven: ott is megnezhetne az ember karorajan/mobiljan stb :)

Offline Tuby128

  • EP addict
  • *
  • Posts: 1485
  • Country: hu
Re: NICK
« Reply #222 on: 2012.February.10. 21:45:38 »
Az lenne a kérdésem, hogy a sorparamétertáblában "64-es karakterkészlet" mód használata esetén a Nick mely karakterkódtól meddig jelenít meg a képernyõn információt?
Az IS-basic ezt használja egyébként?

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #223 on: 2012.February.11. 00:08:36 »
Az lenne a kérdésem, hogy a sorparamétertáblában "64-es karakterkészlet" mód használata esetén a Nick mely karakterkódtól meddig jelenít meg a képernyõn információt?

A 64 és 128 karakteres módok figyelmen kívül hagyják a karakter kód felső 2 vagy 1 bitjét, tehát a karakterkészlet "ismétlődik".
Azonban az ALTIND0 és ALTDIN1 biteknek nincs ilyen hatása, ezért lehetséges 256 karakteres 4 színű módban, hogy a 0-63 és 128-191, illetve 64-127 és 192-255 karakterek más palettát használjanak.

Quote
Az IS-basic ezt használja egyébként?

Az IS-BASIC 128 karakteres módot használ, 2x2 színű palettával (ALTIND1).

Offline Tuby128

  • EP addict
  • *
  • Posts: 1485
  • Country: hu
Re: NICK
« Reply #224 on: 2012.February.13. 05:07:59 »
Készítettem egy NICK specifikációt a lábkiosztással. Még hiányos.