Az jutott eszembe, milyen jó lenne, ha lenne olyan beállítás, hogy a kép-et kimerevíti a Nick, tehát nem jelenik meg ezidő alatt semmilyen változás a képen, így ki lehetne kerülni a két kép használatát ezzel is picit gyorsítva a programot, és csökkenteni a memóriahasználatot. Nincs ilyen opciónk? Pl ha a 83-as port felső két bitje közül az egyiket nullázom, akkor nem frissül a kép, hanem ugyanaz marad a képernyőn?

Azt hogy? Nick-nek nincs sajat memoriaja (leszamitva par regiszter - gondolom) ahhoz hogy _valamit_ megjelenitsen, folyamatosan olvasnia kell a RAM-ot es az alapjan jeleniti meg a kepet. Ha nem akarod, hogy lassa a valtozast ugymond, akkor honnan venne az adatokat addig, amit meg kell jeleniteni?

Ami viszont eszembe jutott: RAM bovites stb, lehet fogyasztasnak is hasznalna miegymas ha megszabadulnek a DRAM-oktol illetve az egesz frissites RAS/CAS stb cucctol (esetleg kieshetne jo par IC) es az alaplapi memoriat is SRAM-ra cserelni valahogy a bovitessel egyutt? Ui akkor az az erdekes helyzet allhatna elo, hogy a 64K-s videoram-ra pl bepakolhatnek 128K-s SRAM-ot. Itt adodik a lehetoseg hogy pl mi van ha egy kis plusz logikaval azt mondom, hogy a Nick-nek meg lehetne mondani h a video RAM melyik felet lassa? Persze akkor mar uez lehetne CPU-ra is Es akkor lathatjak eltero feluket is! Ok, persze az "idealis" az lenne, ha a full RAM-ra lehetne nick-nek es cpu-nak ralatasa, nem ilyen "masodszintu lapozas" de imho ez mar tul mely beleturas lenne a gep lelkivalagaba, hisz a videoram-nal van h ott cpu/nick kozosen osztozik, mig a tobbi RAM-nal ez nincs, tehat itt a video ram es a "normal" RAM bovites ket kulon dolog lenne meg mindig.

zx81-en volt olyan hogy képrenyő kikapcs (hangyák megjelennek) és akkor kicsit gyorsabb lett

Mivel ott a proci rajzolta a képet, lefoglalva a nagyja CPU időt.

Mivel ott a proci rajzolta a képet, lefoglalva a nagyja CPU időt.

Nyilvan, de azert mas gepeken is okoz gyorsulast, ha a megjelenites tilthato, mivel akkor nem osztott a memoriahozzaferes a video subsystem es a CPU kozott es/vagy nagyobb orajellel is mehet a CPU ami nem lehetseges a video mellett. Ez utobbira jo pelda a Commodore 128 ahol a VIC-II nem megy 2MHz-en, bar a CPU atkapcsolhato arra (2MHz-en viszont VDC-vel megy!), vagy a Commodore +4, ahol a CPU orajele valtozik attol fuggoen hogy eppen hol tart a kepfelepites (tehat a kep kikapcsolasaval gyorsabb), de meg C64-en is valamivel gyorsabb kikapcsolt VIC mellett, preciz idozitesi rutinok/turobok stb ezert is kapcsoljak le a kepet. EP-n nem tudom lehetseges-e total megallitani a nick-et hogy ne is olvassa a memoriat, ezzel a video ram-ot is olyan sebesseggel erne el a CPU mint a "nem video RAM"-ot, nyilvan kep nem lesz kozben viszont

A BFh porton van egy bit, amely állítólag a beépített memóriát 16K-ra korlátozza, de ez hibásan működik

Szerintem csak nem frissítették a leírást
Ha azt a bitet beállítjuk, akkor az alaplapi ROM és Cartridge kivételével minden VRAM-nak lesz dekódolva, azaz a 08-FFh szegmenseken mindenhol a FC-FFh szegmensek ismétlődnek.
Ennek egy esetleges fejlettebb Nick esetén lehetne értelme, ami 64K-nál többet tud kezelni, és maga oldaná meg a VRAM további dekódolását, mondjuk 256K-ra.
Vélhetőleg eredetileg tényleg a 64/16k lehetett a terv, de aztán rájöttek, hogy úgyse fognak a már akkor is borzalmasan elavult 4116-os RAM-okkal foglalkozni, viszont felmerült, hogy mi van ha majd egyszer több VRAM kéne... így lecserélték a 16K opciót, csak a leírás nem frissült hozzá.

83h port felső bitjeinek sincs hatása a sebességre.

Pedig a 6-os bitnek pont ez lenne az értelme...

Pedig a 6-os bitnek pont ez lenne az értelme...

Ha a 6. bit ki van kapcsolva, akkor csak az aktuális LPB ismétlődik, de egyébként van kép.

Ennek vajon mire lenne jó?

Nem én terveztem a NICK-et. Mindenesetre, amíg 0 a bit, addig az aktuális LPB címe nem változhat, de egyéb hatását nem találtam. Azonban a 0->1 átmenete a 7. bit 0 állapota mellett az új LPT cím betöltését eredményezi a sor végén, az LPB-n belüli sorszámlálótól függetlenül. A lényeg, hogy a video kimenetet és RAM időzítést egyik bit sem kapcsolja ki, és csak az LPB címre van hatásuk. De a 7. bit állítgatásával érdekes hardver "hibát" is sikerült előhozni, már nem emlékszem, pontosan hogyan, ami egy teljesen fehér sort eredményezett a képen. Talán átmenetileg érvénytelen lett az LPB cím. Lehet, hogy a 6. bit funkciójának is ehhez van köze, például hogy ne történhessen véletlenül egyszerre növelés és újratöltés (aminek a két cím közötti AND művelet, vagy más hibás eredménye lehet).

És hol az a program?