Tryb overlay ma tę "wadę", że można go mieszać z normalnymi trybami ANTIC-a, więc pewnie trudno byłoby uniknąć np. drobnych oszustw (ogólnie np. ANTIC i mapa kolorów, ale w paru miejscach retusz kantów overlayem). Chyba że electron przygotowałby specjalną wersję rdzenia, w którym overlaya nie dałoby się włączyć ;)

Tak.

Owszem, to (TF 2005) zapamiętuje stany rejestrów I/O i można je podejrzeć albo zmodyfikować.

Magazyn wychodzący raz na rok ma 53 numery??! Czyli co, wychodzi od 1957 roku? ;P

atra już sformatowałem, poprawiwszy uprzednio ręcznie pozycję DUP.SYS w katalogu - dlatego, że to, jak się okazało, była moja jedyna dobra kopia MyDOS-a 4.50, więc musiałem ją odzyskać :/

DOS.SYS się będzie bootował dobrze mimo przesortowania, bo w bootsektorach jest zapisany numer pierwszego sektora zajętego przez ten plik, a na to sortowanie katalogu nie wpływa. Jak DOS.SYS się zaczynał od sektora nr 4, albo 550, to po sorcie nadal się będzie zaczynał od 4 (albo 550). Kod bootsektora nie odczytuje katalogu, więc nie ma pojęcia, jaki "powinien" być numer pliku DOS.SYS. Nie zauważa zatem, że się on nie zgadza.

DUP.SYS natomiast - tak samo jak każdy zwykły plik - się nie odczyta, bo numer pozycji w katalogu przestanie się zgadzać z numerem zapisanym przy tworzeniu tego pliku.

Taka sytuacja:

Nr Nazwa
0  DOS.SYS
1  DUP.SYS

DUP.SYS jest drugi w katalogu więc ma nr 1 (licząc od zera). A więc, w każdym sektorze pliku DUP.SYS każde pierwsze 6 bitów linku sektorowego (bajt 125 sektora SD/ED albo 253 DD) będzie miało wartość $01, bo taki jest numer tego pliku (a numerem pliku jest pozycja jego wpisu w katalogu).

Teraz, załóżmy że katalog przesortujemy i po sortowaniu mamy taką sytuację:

Nr Nazwa
0  DUP.SYS
1  DOS.SYS

DOS.SYS się odczyta przy boocie, bo bootloader nie czyta katalogu, więc w nosie ma, czy pozycja w katalogu i numer pliku się zgadzają. Natomiast DOS.SYS po uruchomieniu próbuje otworzyć DUP.SYS jako normalny plik. Ten plik ma w katalogu nr 0 (bo jest na pierwszej pozycji) ale w sektorach danych (w pierwszych 6 bitach linku) ma zapisany nr 1. Więc następuje mismatch, błąd nr 164, plik nie daje się odczytać.

Przemieszczenie pliku w katalogu jak najbardziej "wpływa". Bo: nr_wpisu_w_katalogu = nr_pliku, a nr_pliku jest zapisany w sektorach danych pliku i musi się zgadzać z nr_wpisu_w_katalogu, bo inaczej DOS zgłasza błąd 164.

No a u mnie nie. MyDOS 4.50, dyskietka (ATR w zasadzie) w single, formatowana tymże MyDOS-em, z zapisanym MyDOS-em funkcją H. Potem dodane pliki, i sort, w którego wyniku DUP.SYS się przemieścił w katalogu.

MyDOS się owszem bootuje z tego, ale tylko do BASIC-a. Próba wejścia do menu się nie udaje. Spod BASIC-a OPEN #1,4,0,"D:DUP.SYS" daje odpowiedź ERROR-  164.

Pod SDX się czyta spoko.

Jest coś w rodzaju błędu w SpartaDOS X 4.42, i chyba w ogóle we wszystkich wersjach. Odkrył to niejaki rdea6 z AAge.

Problem dotyczy programu SORTDIR.COM. Służy toto do sortowania katalogów. Otwiera katalog R/W, wczytuje do pamięci, sortuje, zapisuje z powrotem, zamyka, koniec. Działa świetnie.

Ale niestety dokładnie tak samo świetnie działa na dyskietkach Atari DOS-u (MyDOS itd.). Robi dokładnie to samo, tzn. otwiera plik katalogu i widzi go jako katalog Sparty (bo sterownik ATARIDOS.SYS robi translację danych w obie strony, przy odczycie z formatu Atari na format Sparty, przy zapisie odwrotnie). Więc sortowanie się udaje.

Tylko że taka dyskietka jest potem nieczytelna pod MyDOS-em :P Pod SDX to i owszem, ATARIDOS.SYS ją przypadkiem czyta prawidłowo, ale MyDOS wywala error 164. Bo fizyczna pozycja pliku w katalogu musi (pod MyDOS-em) się równać numerowi pliku zapisanemu w 3-bajtowych linkach w sektorach tego pliku.

MyDOS to sprawdza a Sparta (tzn. ATARIDOS.SYS) nie. Sparta sprawdza tylko zgodność numeru pliku pomiędzy poszczególnymi jego sektorami, natomiast olewa pozycję w katalogu.

W każdym razie, sortować katalogi proszę sobie tylko na dyskach w formacie Sparty, póki co.

No ale niedziałanie konkretnych 3 gierek to jest jednak wina mojego sprzętu - w każdym razie mają prawo nie działać, bo - przepraszam, zapomniałem - nie mam dolutowanego słynnego kabelka udostępniającego pamięć od $8000 do $FFFF dla MEMAC A. Więc pewnie to jest przyczyną.

pajero, jeśli chodzi tylko o to, że Śniegowy ma TF, no to chyba nie on jeden :P

Jeśli ktoś ma rdzeń 1.22, a stęsknił się za demem Mr. Propera, to może zadziała plik dołączony do tego posta. To oczywiście póki Madteam nie uaktualni binarki na swojej stronie.

PS. Z "przypadkiem", którym działają produkcje XXL-a: coś w tym jest, wczoraj ściągnąłem JSW, NightDriver i NightShade (czy jakoś tak) ze strony Madteamu i niestety, na rdzeniu 1.22R nie chodzą. Może wymagają A?

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.