To niewiele zmienia, bo te układy CMOS to przełączniki analogowe, w stanie włączonym przezroczyste dla przepięć. Same zresztą też są wrażliwe na ESD.

Core 1.3 z poprawką dot. resetowania przerzutnika hi-res przy ustawianiu trybu GTIA - za chwilę.
Tymczasem inny problem. Doszedłem do punktu, w którym trzeba by ustalić format obrazu w wersji cyfrowej. W tej chwili obraz o standardowej szerokości 160 cykli koloru, czyli 320 pikseli hi-res i maksymalnej możliwej wysokości 240 linii jest przeskalowany do rozdzielczości, w zależności od wersji core, 640x480 lub 1280x960 pikseli. To daje standardową proporcję rozmiarów obrazu 4:3, ale maskuje wszystko, co ewentualnie mogłoby być wyświetlone po bokach, w trybie szerokim. Gdyby uwzględnić całe dostępne pole w trybie szerokim, obraz miałby rozdzielczość 1536x960 pikseli (lub 768x480) i proporcje 16:10. Ale przy okazji objąłby wszystkie ewentualne śmieci, pojawiające się w wielu programach, a normalnie nie wyświetlane przez żaden szanujący się TV. W Atari800Win przyjęty został format 336x240 co po przeskalowaniu 4:1 daje 1344x960 pikseli i proporcje 14:10. Czy to wystarczy, czy jednak warto byłoby zostawić więcej - 352x240, 360x240? A może jednak całe 384x240?

Dopóki Poczta Polska ponownie nie "zaktualizuje" cennika, nadal obowiązuje 25zł. To jest koszt wysyłki w obie strony. Decyzja, czy czekać na rev.C należy do Ciebie.

I na koniec docelowa (mam nadzieję) Sophia Rev.C z wyjściem cyfrowym DVI. Dystorsja koszmarna, bo obiektyw super zoom zupełnie się do takich zdjęć nie nadaje.

To jest akurat dość kiepska pod względem czasu reakcji matryca. 20ms od 10% do 90% jasności. Rozdzielczość 640x480, przekątna 10.4" Obraz przeskalowany do rozdzielczości natywnej. Większe matryce prawdopodobnie także udałoby się w podobny sposób przystosować, ale niekoniecznie każdą.

Wyjścia monitorowego nie ma, ale miejsce na gniazdo na płycie jest. Wystarczy wlutować i wywiercić otwór w obudowie.

BIOS nie może blokować flashowania samego siebie, bo jeśli się wysypie w stanie zablokowanym, to już tak zostanie. Ewentualnie mógłby programowo blokować flaszowanie SDX, ale wielkiego sensu w tym nie widzę, a właściwie żadnego. Ogólnie - nie ma w IDE+ mechanizmu pozwalającego na poziomie sprzętowym zablokować zapisu do FLASHA. Jedyne zabezpieczenie to protokół programowania pamięci.

W tej chwili pracuję nad paletą NTSC i kiedy będzie gotowa, podejmę próbę upchnięcia obu palet. Szansa niewielka, ale niezerowa. Wykrywanie PAL/NTSC jest zrobione, więc gdyby implementacja się powiodła, układ sam sobie wybierze odpowiednią paletę. Dla zachowania kompatybilności, 16 poziomów jasności jest teraz włączane bitem 3 PMCTL.

Można.

Są trzy możliwości:
1. Przysyłasz pocztą do przeprogramowania. Koszt ok. 25zł.
2. Kupujesz programator USB Blaster i wtyk Micro Match 10-pin. Koszt na szybko (allegro) ok. 60zł, na wolno (ebay) ok. 30zł.
3. Przyjeżdżasz na Wapniaka. Koszt jeszcze bliżej nieokreślony.

Much better.

W Cavelord sprawa oczywista, ale w Knight Lore to nie jest kwestia drugiego koloru w hires. Brązowy kolor pochodzi tam z grafiki P/M i dlaczego jest niewidoczny na tle negatywowego hiresu, będę wyjaśniał. Wygląda na pierwszy rzut oka na nieprawidłowe działanie priorytetów, ale dlaczego - trudno powiedzieć. To akurat wydawało mi się, że dobrze odwzorowałem, z nieudokumentowanymi włącznie.