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.

@as: darowizny chętnie przyjmuję, ale tu akurat to nie jest kwestia pieniędzy. :)

@willy: o ile ja rozumiem, to ma być konfigurator do karty, wywoływany przez naciśnięcie określonego klawisza przy reset, pozwalający z menu poprzestawiać różne jej parametry i zapisać je do flasha. Jest na to przeznaczone "nowe urządzenie" nr 0. Pewne rzeczy zostały już napisane przez laoo, który nie wiem dlaczego nie chce tego pociągnąć dalej.

Raczej żaden z języków wysokiego poziomu nie wchodzi tu w grę, ale też nie wydaje mi się, żeby dobremu koderowi robiło to różnicę.

A nie można wykorzystać patentu z YM/AY, że mamy specjalny rejestr, do którego program zapisuje nr rejestru I/O, który chce odczytać, a drugim rozkazem odczytuje z niego daną? To eliminuje problem "ciągłego pollingu", ale czy to przydatne, musiałby się np. mono wypowiedzieć.

Ode mnie 30 PLN.

@Sikor: czy mógłbyś umieścić na stronie adres party place w jakimś widocznym miejscu? "Mapka" jest jakaś mało czytelna. Dzięki!

Hmm. Mógłbyś rozwinąć? O ile jeszcze w ogóle cokolwiek pamiętam, True Color Falcona to chyba dość dobry przykład na tryb chunky: 1 piksel opisany jest przez jedno, 16-bitowe słowo w pamięci obrazu. A taka organizacja obrazu stanowi przykład trybu chunky na en.wiki: