Czyli różnica wynosi od 14 (FO0) do 26% (OSC), tymczasem na zdjęciu pajera różnica grubości pomiędzy pionowymi liniami hiresu wynosi na oko z połowę - widać to na tekście wyświetlanym przez SysInfo (listwa na górze, box z lewej, zwłaszcza litery D, M, T, A itp.)

PS. Oczywiście, w tej chwili się czepiam, wynik poprawki i tak jest rewelacyjny, bo po jej zaaplikowaniu wadliwe GTIA jest w ogóle w stanie wyświetlić czytelny obraz, i to w demach, które się nie patyczkują. Nawet jeśli zostają usterki, to są w sumie minimalne w porównaniu do nieskompensowanej wady.

Tia, pewnie dlatego, że to demo przełącza potem tryb na 15. Skutek jest, jak dla mnie, dziwny, bo tak jakby rozjeżdżała się synchronizacja pozioma. Sprawdzałeś może, czy na Unity jest tak samo?

PS. Ale hires w tym komputerze nadal paskudnie wygląda, mam wrażenie, że "dobre" GTIA generuje lepszy, tzn. piksele powinny być w miarę równej wielkości, a tu linie pionowe są raz grubsze, a raz cieńsze.

To by było niezłe. Ale sprawdź jeszcze, czy działa dobrze przy przełączeniu trybu w środku linii z gr.8 na gr.9 (demo Unity, SysInfo albo coś takiego).

Tak, ja rozumiem, ale jednak "skalę zjawiska" pokazałeś w sposób niezbyt polityczny: przykładem, który się dał bardzo łatwo zbić. Ogólnie, pamięć ekranu VBXE jest duża i to wie każdy, kto umie pomnożyć np. 320 przez np. 192. Ale od tego własnie jest blitter, żeby odciążyć w tym CPU.

Ośmielam się zatem domniemywać, że, na przykład (zważywszy istnienie blittera, który nie dość, że jest sam w sobie szybki, to jeszcze może działać na VRAM-ie "jednocześnie" z CPU), druciana wektorówka byłaby (nie sprawdzałem) na VBXE o wiele łatwiejsza do realizacji niż w trybach graficznych ANTIC-a.

I już nawet pominę, że przy użyciu VBXE można wyłączyć ANTIC, czyli zyskać te 20-30% szybkości CPU.

BTW. blitter VBXE można wykorzystać też w standardowych trybach graficznych ANTIC-a.

Jak mówię, dobry jest adapter od IDEa, tzn. to: http://atariki.krap.pl/index.php/Grafik ... pcb_2a.jpg Gdyby - teoretycznie - był dostęp do takowych, to freezery można byłoby wykonać w wersji XL.

Jakby były czarne, to ja chcę czarne. Co do rozmiaru, muszę się zastanowić. Chyba że umawiasz na przymiarki ;)

@wieczor: kabelka nie trzeba spawać, wersja XL odbiera 5 V z PBI, rzecz tylko w tym, żeby komputer to podawał.

Do grzebania w NV-RAM-ie jest, jak pisze Kroll, moduł CPX, albo program dostarczany przez Atari Corp. na dyskietce systemowej (SETUP.APP bodaj, czy jakoś takoś), ... chyba że mi się już myli, bo dawno Falconam na oczy nie widział. Ale myli mi się najwyżej z jakimś innym programem służącym do tego samego :)

@pin: bo pewnie w NVRAM-ie jest ustawione NTSC? M0 i M1 służą nie do przełączania trybów wyświetlania, tylko mówią Falconowi, jaki monitor jest podpięty (VGA, RGB, ST Mono albo TV).

Gdyby tego nie chcieli, to by sami je poprawili. Skoro nie poprawiają, to podaję sugestię, że poprawienie programu na własną rękę (przez zainteresowanego użytkownika) jest jak najbardziej możliwe i przypuszczalnie niezbyt trudne.

U mnie działa, zarówno z rdzeniem R jak i A. Sprawdź, czy nie pomyliłeś plików, S_VBXE.SYS, wielkość 7869 bajtów, data 29-03-10, czas 21:27:54.

W nowym rdzeniu zmienił się sposób numerowania wersji (są dodatkowe flagi), stąd ten problem. Info o tym wisi od paru miesięcy w Atariki (w dziale "Biblioteczka kodera" http://atariki.krap.pl/index.php/Wykryc ... ji_rdzenia ).

Candle: jest drobny błąd w opisie przykładu textmode.com, w rzeczywistości drajwerek NIE jest wymagany do jego uruchomienia.