1 Ostatnio edytowany przez mono (2014-02-02 21:09:09)

Część i czołgiem Towarzystwu!
Miałem swego czasu napad podczas oglądania TOMEK-8 cartridge tech-demo aby sprawdzić, na ile wydajnie dałoby się coś podobnego zrobić z wykorzystaniem znanego i lubianego VBXE.
Cóż, jak pomyślałem tak też niedawno uczyniłem i oto: http://mono.atari.pl/vbxe/t8vbxe.zip

W mojej implementacji program ładuje grafiki z dysku, po czym przepisuje je do VRAM i zleca VBXE wygenerowanie grafik przesuniętych o 1,2,3..7 pikseli. CPU zajmuje się tylko aktualizacją pozycji obiektów, określeniem na podstawie pozycji x i y którą grafikę (będącą w jego VRAM) ma pokazać i gdzie, oraz wygenerowaniem blit-listy dla VBXE. VBXE podczas każdej ramki TV wykonuje tę listę i maluje obiekty w swoim VRAM na zorganizowanym tam ekranie wirtualnym o rozmiarze 208+256 x 60+208+60 pikseli (to jakieś 58 * 328 = 19024 bajty), po czym na końcu kopiuje kawałek tegoż ekranu na fizyczny ekran widziany przez ANTICa. Dzięki temu CPU nie musi obcinać obiektów do rozmiaru ekranu i marnować niepotrzebnie cykli. Kompletny obraz malowany jest przez ANTICa co oczywiście spowalnia CPU.
Oczywiście gdyby wszystko zostało przerzucone na barki VBXE (wyświetlanie grafiki na overlay'u), to nie trzeba byłoby generować przesunięć (akurat to niczego by nie zmieniło i obiekty zajęłyby w VRAM taki sam obszar), CPU miałby więcej czasu na swoje obliczenia i wszyscy żyli by długo i szczęśliwie. Nie o to jednak mi chodziło, a chciałem właśnie sprawdzić możliwości współpracy VBXE (blittera) z ANTIC'em przy malowaniu zwykłej grafiki Atari.
Parafrazując Nosty'ego mogę powiedzieć, iż na ekranie dzieje się:
- 12 obiektów o rozmiarach 40x27 pikseli,
- 12 obiektów o rozmiarach 56x54 piksele,
- 12 obiektów o rozmiarach 72x57 pikseli,
- 12 obiektów o rozmiarach 88x43 pikseli
+ okazjonalnie gwiazda śmierci (2 obiekty), teksty (1 obiekt) no i tło (1 obiekt).
Liczę kształt, jak i maskę jako osobne obiekty.
W celach poglądowych wprowadzone zostały też wskaźniki obrazujące zajętość:
- blittera VBXE (pasek po lewej stronie ekranu),
- CPU (paski po prawej stronie ekranu - 1 pasek to jedna ramka TV, 2 paski to dwie itd.).
W początkowej fazie z przycinaniem obiektów do ekranu, liczeniem pozycji z częścią ułamkową (ale blitowaniem obiektów od razu na ekran ANTICa) wszystko zajmowało CPU ponad 4 ramki :/ Obecnie obsługa tych 52 obiektów mieści się w ramce (arytmetyka na liczbach całkowitych, koordynaty obiektów na liczbach naturalnych co eliminuje arytmetykę U2, tablicowane dzielenie przez 8, oraz adresy początków linii dla ekranów wirtualnego i rzeczywistego).

Nie wiem, jak Nosty urządził sobie swój kod i jakie rzeczy robi mu processor na TOMKU, a czym dokładnie zajmuje się CPU, ale widać że wąskim gardłem przetwarzania jest CPU w Atari :/ Niestety. (No i oczywiście umiejętności koderskie człowieka) Tak więc "Imperial March" trzeba sobie puścić z empetróchy (a taką fajną muzykę Pinokia miałem na podorędziu w TMC... :/).

Jak to uruchomić? Otóż wymagania są określone dość klarownie:
- Sparta DOS X w wersji 4.4x (ja używałem 4.46),
- VBXE z rdzeniem FX 1.2x (mam 1.24a),
- Atari XL/XE z minimum 64KB RAM,
- jakiś nośnik dyskietkowy (przykro mi, ale przez moje lenistwo z magnetem to to nie podziała).

Jeśli ktoś chciałby się przyjrzeć kodowi, to udostępnię go każdemu chętnemu (obecnie trzeba zamailować), a w późniejszym terminie wygeneruję jakiegoś zipa i instrukcję jak i czym to kompilować.

Pozostaje mi, jako autorowi życzyć Wam wszystkim smacznego i zachęcić do szczerej krytyki (wyrazy wdzięczności, zachwytu, bluzgi, faki w demach, etc. mile widziane) ze szczególnym uwzględnieniem Nosty'ego gdyż bardzo podoba mi się jego projekt i moralnie wspieram go z całych sił.

Edit: Zapomniałem napisać jak to uruchamiać:

1. Załadować sterownik VBXEFXS.SYS, który tworzy w pamięci RAM cienie dla rejestrów VBXE (będzie o tym osobny wątek w terminie późniejszym).
UWAGA!
Sterownik ten gryzie się z S_VBXE.SYS więc zaleca się niewspółistnienie.

2. Załadować T8VBXE.COM.

Edit 2: Spieszę jeszcze nadmienić, iż jedyny emulator supportujący VBXE - Altirra 2.50 test 22 ma buga (blit w trybie 4 AND) i obiekty nie będą pokazywane poprawnie.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

2

... nieźle to demko dopaliło na Rapidusie. Jak na 6502 mieści się max w 1 ramce, tak na '816 potrzebuje 20-25% z tego ;)

Kontakt: pin@usdk.pl

3

Pinku nagraj parę nowych filmów z rapidusem w akcji....!

4

nie mam czym, bo próbowałem właśnie starą (pi) Nokią i jakość tego jest dramatyczna :( (format *.3GP)

Kontakt: pin@usdk.pl

5

Gratulacje mono :-) a tyle razy mówiłeś, że nie umiesz pisać demek :-)
Pytanie techniczne, jak trzymasz grafikę dla „latających obiektów” – 1x i robisz jakiś magiczny shift blitterem czy jest zwielokrotniona w odpowiedniej wersji dla danej fazy ?

@swinkamor12: Amiga tak zresztą jak ST jest 32 bitowa bo procesor jest 32 bitowy, int w C jest 32 bitowy, a to po ilu bitach się komunikuje z resztą jest nieistotne.

6 Ostatnio edytowany przez mono (2014-02-02 23:29:02)

Dzięki :) Bo nie umiem dema :) To jest tylko mała (i pierwsza) wprawka dla VBXE napisana w celach porównawczych i z ciekawości. Rewelacyjna maszyna!

Grafika dla latających obiektów jest zwielokrotniona w VRAM po klatce dla odpowiedniej fazy. Prekalk robi VBXE po załadowaniu z dysku klatki bazowej tak, że potem VBXE tylko przerzuca dane na ekran wirtualny w odpowiednim trybie.

Edit: Najbardziej w całej zabawie podoba mi się to, że Atari ma 62K do dyspozycji na program, bo cała grafika znajduje się w VRAM.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

7

mono napisał/a:

Rewelacyjna maszyna!

Ano, też jestem tego zdania. Pewne rzeczy, których nie da się blitterem zrobić za jednym zamachem, da się właśnie - czego świetny przykład dałeś - załatwić paroma kolejnymi blitami.

KMK
? HEX$(6670358)

8

mono napisał/a:

Rewelacyjna maszyna!

Też tak myślę

Grafika dla latających obiektów jest zwielokrotniona w VRAM po klatce dla odpowiedniej fazy. Prekalk robi VBXE po załadowaniu z dysku klatki bazowej tak, że potem VBXE tylko przerzuca dane na ekran wirtualny w odpowiednim trybie.

Tak, i tu widać możliwości TOMKA-8 i jego PIC-a. Jeśli będzie istniała możliwość wgrania własnego wsadu do T8 to myślę, że zobaczymy efekty jakie będzie trudno zrealizować blitterem z VBXE. W końcu PIC to procesor z prawdziwego zdarzenia i z tego co pamiętam z zegarem 60-70 MHz.

@mono – demko nie trzyma synchronizacji z ramką, tak na oko wystarczy opóźnić startowanie blittera o pół ekranu i powinno już przestać rwać :-)

@swinkamor12: Amiga tak zresztą jak ST jest 32 bitowa bo procesor jest 32 bitowy, int w C jest 32 bitowy, a to po ilu bitach się komunikuje z resztą jest nieistotne.

9 Ostatnio edytowany przez mono (2014-02-02 23:59:50)

Jeśli masz na myśli mrugnięcie od czasu do czasu, to jest to spowodowane procedurą, która wykonuje tzw scenariusz - włącza/wyłącza obiekty do wyświetlania dla procedury przetwarzającej. Nie dopracowywałem tego, bo interesowało mnie jedynie sprawdzenie na ile można sobie pozwolić CPU a na ile blitter w jednej ramce.
Blitter odpalany jest w linii VCOUNT=$10.

Edit: Procedura scenariusza obrazowana jest na brązowo na końcu prawego paska. Zazwyczaj to jedna linia ekranu więc jej prawie nie widać, ale czasem szarpnie i wtedy na moment widać spory blok. To jest moment rozsynchronizowujący z ramką.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

10 Ostatnio edytowany przez ajcek (2014-02-03 00:17:59)

Nie, chodzi mi o to, że pierwsze 30-70 linii (w zależności od ilości obiektów) jest z poprzedniej klatki a kolejne są już z następnej. Nie rzuca się to bardzo w oczy ale jak się przyjrzeć to widać :-)

To zjawisko widać zwykle w linii w której blitter kończy pracę

@swinkamor12: Amiga tak zresztą jak ST jest 32 bitowa bo procesor jest 32 bitowy, int w C jest 32 bitowy, a to po ilu bitach się komunikuje z resztą jest nieistotne.

11 Ostatnio edytowany przez mono (2014-02-03 00:25:02)

Aaaaa. To tak - blitter w końcowej fazie robi copy z ekranu wirtualnego to rzeczywistego i jest wyścig z ANITCem. To prawda - załatwi to odpalenie tegoż blita np na VBLKD, ale wtedy nie zobaczę tak ładnie lewego wskaźnika :)

Edit: To też oczywiście da się obejść. Policzyć czas trwania blita w liniach ekranowych i potem namalować wskaźnik w dowolnym miejscu ekranu, ale jak mówiłem - to "demo" ma na celu tylko zobrazowanie możliwości. Nie jest to pełnoprawne ładne demo w prawdziwym tego słowa znaczeniu :)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

12

No i jest już Altirra pozbawiona buga.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

13 Ostatnio edytowany przez seban (2017-04-21 22:54:35)

Cześć!

Wygląda całkiem fajnie i dobrze :)

Dla nie potrafiących tego uruchomić przygotowałem video: T8VBXE Video (codec h264, 50fps). Warto użyć np. VLC ( http://www.videolan.org/vlc/ ) do odtwarzania aby zachować płynność i pełen frame-rate (50fps), odtwarzanie w przeglądarce (przynajmniej) u mnie kończy się jakąś szarpaniną.

pozdrawiam
Seban

14

Dzięki Seban.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

15 Ostatnio edytowany przez mono (2015-01-24 20:30:01)

Zaktualizowana wersja używająca VBXEFXS lub S_VBXE.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje