Z FTDI i odpowiednimi procedurami SIO (patch Hiasa, SIO IDE+) HS=0 idzie spokojnie, mogą tylko przeszkadzać dodatkowe szykany sprzętowe po drodze, w rodzaju sławnych kondensatorów (czy czego tam) przyczepionych do gniazda SIO. Z moich trzech Atarek, przy niezmiennych warunkach zewnętrznych (ten sam soft po obu stronach, ten sam kabelek, ten sam pecet przyczepiony z drugiej strony) w jednej chodzi HS=0(*), w drugiej HS=6, w trzeciej dopiero HS=8.

* ale tak po prawdzie, HS=1 jest rzeczywiście stabilny, przy HS=0 transmisja czasem potrafi zerwać, co jest niefortunne przy przesyłaniu długich plików (plik "długi" = kilka MB).

Raczej bym podejrzewał, że różne egzemplarze CA mają różnie wyregulowane (czytaj: niewyregulowane) napędy, co skutkuje tym, ze jedna stacja nie umie odczytać dyskietek drugiej, niezależnie od tego, czy to TOMS czy nie. Znam też jeden przypadek stacji CA-2001, która nie jest w stanie odczytać nawet dyskietek sformatowanych i zapisanych plikami przez siebie samą, więc coś może być na rzeczy (jest to stacja bez przeróbek).

Na reset zrobiony na zielonym ekranie musi czasem zgubić ustawienia, bo taka jest dziejowa konieczność. Ja wójt to wama mówię. Tak samo się _czasem_ stanie, jeśli mając na ekranie menu IDE+ wyłączysz zasilanie.

Przyczyną jest zastosowany zegarek, który trzyma datę i godzinę, i ma NV-RAM na ustawienia, ale odczyt daty/godziny następuje tylko przez wczytanie tejże do wyżej wspomnianego NV-RAM-u. W związku z tym BIOS odczytuje ustawienia do wewnętrznej pamięci RAM, a potem odczytuje czas/datę, żeby je wyświetlić na ekranie menu.

Jeśli wciśniesz mu w tym momencie RESET albo wyłączysz prąd, NV-RAM nie będzie zawierało ustawień menu, tylko cośtam (czas i datę, czyli dane z punktu widzenia menu przypadkowe). Przy następnym uruchomieniu BIOS odczytuje zawartość NV-RAM i, żeby sprawdzić, czy pamięć zawiera ustawienia, liczy sumę kontrolną. Ta suma zgadza się tylko wtedy, kiedy w NV-RAM-ie znajdują się ustawienia zapisane funkcjami BIOS-u IDE+.

Jeśli suma się nie zgadza, przywracane są ustawienia fabryczne.

Wydaje mi się, że to problem ze sterownikiem w ROM-ie Karinki, na pewno od niego pochodzi ten (niezbyt mądry) nr błędu. Zgaduję, że za pierwszym razem stacja nie przestawia się w dobrą gęstość, albo coś takiego. Napisz do truba, na pewno będzie wiedział lepiej, bo dłubał w tym dokładnie.

EDIT: w przyszłym tygodniu zwiozę następną porcję sprzętu, w tym Karinkę, to zobaczę, o co w tym chodzi.

@montezuma: dodano do listy rzeczy do zrobienia.

Jak stwierdzili przedmówcy, zależy to od stacji.

1) w gołej LDW 2000/CA-2001: http://atariki.krap.pl/index.php/Progra ... _i_CA-2001

2) w stacjach TOMS też się na pewno da, ale nie znam szczegółów. Jak wyżej, trzeba stacji wepchnąć kawałek programu (napisanego w asmie Z80), protokół jest inny niż w LDW/CA, ale zasada podobna.

3) w gołej 1050 można przesuwać głowicę komendą $23 (DIAG1): http://atariki.krap.pl/index.php/Lista_ ... eracyjnych

Tyle razy o tym gadaliśmy, że powinno być jasne, że nie "w granicach Polski", i tez powinno być jasne, co moim zdaniem ma nam to dać i dlaczego chcemy/musimy próbować to osiągnąć. Nie słuchałeś, siadaj, dwa :P

Oczywiście, na nasze miejsce wleźli już Niemcy, nie przejmując się zupełnie, czyja to gierka i o co w niej chodzi: po prostu wykorzystali sytuację. Ciężko to będzie odkręcić latami, a wystarczyło dobrze podziałać przez parę miesięcy. Ale oczywiście, po wioskowych głupkach z PO nie można się spodziewać niczego poza kurczowym trzymaniem się koryta i myśleniem, że jak się zamknie oczy, to reszta świata ma ciemno.

Pokrywy na emulator też są w ofercie? Na pewno byłby duży popyt :P

@laoo: to, co napisałeś dość istotnie zmienia mój pogląd na sprawę, bo dotąd jakoś umykała mi informacja, że to menu jest już w zasadzie zaprogramowane, tylko jest z nim jakiś problem. Myślałem, że nic nie ma i trzeba wszystko pisać od nowa.

Na filmie jakoś bardzo widać, że program nie robi dwubuforowania :] Na monitorze to cokolwiek lepiej wygląda. Może to też zależy od obrazka. Osobiście polecałbym beau.bmp z drugiej paczki (acz to pewnie za ciemne).

EDIT: nie zgadzały mi się obliczenia z wynikami, więc pomierzyłem czasy drugi raz i dokładniej. Renderowanie 1 klatki:

a) bez VBXE: 1,68 ramki

b) z VBXE: 2,13 ramki

Parę osób w Głazach widziało już na Rapidusie u Pasia, jak to określił mazi, "patriotyczne demo": rotozoomer z motywem o widocznym charakterze państwowotwórczym.

Dodam, że pierwotnie ten a nie inny motyw został wybrany dlatego, że z kilkunastu różnych bitmap wyglądał najlepiej po redukcji do 2 kolorów. Ale szybko doszedłem do wniosku, że taki motyw jest równie dobry jak każdy inny, zwłaszcza że było akurat w okolicach 13 grudnia :)

Dzisiaj program postanowiłem doprowadzić do kultury tak, żeby się już nadawał do publicznej prezentacji. Oto on:

http://drac030.krap.pl/r3b.arc

Wymagania:

1) Atari

2) 65C816 (im szybciej taktowany, tym lepiej, powiedzmy, że 10 MHz i więcej jest zalecane)

3) 48k pamięci podstawowej + 64k "liniowej"

Opcjonalnie: VBXE

Program zawiera w sobie 256-kolorową bitmapę. Jeśli zostanie wykryte VBXE, włączany jest tryb low-res o rozdzielczości 128x96 i dalej wiadomo. Jeśli nie ma VBXE, program robi redukcję kolorów do 2 i prezentuje (dokładnie ten sam) efekt na ekranie 128x96 w dwóch kolorach (GR.6). Można wymusić pominięcie inicjowania VBXE przytrzymując klawisz Shift podczas startu r3.exe.

Dodatkowa featura polega na tym, że pod DOS XL, Real.DOS, SpartaDOS, SpartaDOS X programowi można w linii poleceń podać nazwę pliku BMP do rotowania (i zoomowania). Obrazek musi spełniać wymagania:

1) typ Windows bitmap (BMP)

2) rozmiar 256x256 pikseli

3) 8 bitów na piksel

4) brak kompresji

(jakby co: konwersje z np. IrfanView do 256x256x8bpp i zapisane jako BMP spełniają te warunki).

Powierzoną bitmapę program traktuje jak swoją, to znaczy, jeśli nie ma VBXE, dokonuje na niej brutalnej redukcji liczby kolorów do B/W. Jak wiadomo, nie zawsze to wychodzi, wiele zależy od obrazka. W każdym razie na bitmapie "domyślnej" algorytm działa dobrze, a wcale nie jest pod nią w żaden sposób rasowany. W archiwum jest przykładowy plik BMP, który też jako tako po tym wygląda (acz niewykluczone, że trzeba najpierw obejrzeć wersję full color, żeby widzieć, co to jest).

Dane techniczne:

1) rotowana bitmapa: 256x256 pikseli, 256 kolorów

2) okienko: 128x96, B/W lub 256 kolorów, zależnie od sprzętu

3) szybkość renderingu przy 20 MHz:

* b/w: ok. 2 ramek na klatkę

* 256 kolorów: ok. 2,5 ramek na klatkę

Zważywszy że w tym drugim wypadku pamięć obrazu jest 8x większa, a w obu jej szybkość wynosi 1,77 MHz, może nie jest to taki zły wynik.

Nie wątpię też, że da się to zrobić lepiej, zważywszy dema z ostatniego Forewera. Ja po prostu wygóglałem jakiś amigowski algorytm i zaaplikowałem go do 816.

EDIT: program działa też na Altirze, System->CPU Options->65C816 20 MHz (klik), System->Memory size->High Memory->4 MB (klik), System->Video->VBXE (klik)

EDIT 2: aktualizacja linku.