Jen bych doplnil, ze pokud vim, tak ty "prohazene" radky na Spectru byly kvuli tomu, aby se neseslo na delsi dobu zobrazovani a refresh RAM (nebo neco takoveho???). Taky program v dolnich 32k, ve kterych byla bitpama obcas popobihal ponekud "trhane", jak si zobrazovaci cip zabiral sbernici ;-)
Pokud ma atribut a pod nim umistena bitmapa tutez cast radkove adresy, je mozne ji zavest do DRAM v dobe /RAS a druhy byte pak cist zrychlenym cyklem jen zmenou /CAS (tzv. page-read mode). Tj. nacteni dvojice atributu (tak pracovala ULA v 48k/128k kazdych 16T) je provedeno za 6 pristupu misto za 8.
O refresh zde vubec nejde, puvodni model issue 1 pocital s refreshovanim jen ze strany CPU (!) v dobe nezobrazovani, a az pozdeji se zjistilo, ze i vlastni beh ULA nad vycitanou VRAM k udrzeni informace bohate staci (issue 2 - chybi tu uz zbytecna weak vazba na /rfsh cpu).
A ted to prohazeni - ULA zkratka pri postupu snimkem udrzuje spodnich 7 bitu (vram zx byla 2^7 x 2^7 organizovany blok dram - didaktik M/hobbit ULA musi udrzovat 8, ale organizace vram tomuto vyhovuje) konstantnich po dobu zobrazovani jedne linky se spol. atributy. Proto je navazujici radek o 256b vyse, etc. Samozrejme, CPU mohl mit adresy ve vram multiplexeru prohazene stejnym stylem (A6..A7 <-> A8..A10), a pak by se bitmapa jevila pro CPU stale jako linearni, ale za soucasneho navrhu vycitaci logiky by byla atributova cast uz v adr. prostoru nekompaktni, co by byl nuz do zad puvodnimu BASICu, ktery se delil s VRAM o 1 16k banku od #4000-#7fffh.
A to je pravy duvod, uvedomte si, ze v dobe issue 1 navrhari o refreshovani samotnou ULA neuvazovali, a dokonce takto prohazena VRAM ma z hlediska fyzickeho obcerstvovani daleko HORSI vlastnosti, nez tupe vycitana bitmapa na 8T...
zxm.speccy.cz
ci5.speccy.cz
www.pandora.cz - konference Speccy - stale zijeme ;)
