Dzięki chłopaki za odzew :)
@grzybson: Myślałem o bankowaniu po 8kB ze względów oszczędnościowych - rozmiary buforów jakie używam lepiej dałoby się poupychać w takich bankach i ostatecznie zająłbym mniej pamięci, ale po przemyśleniu to rzeczywiście nie jest chyba warte włożonego wysiłku i lepiej od razu nastawić się na 1 MB ROMu bankowane po 16 kB.
@inni_pytający_się_o_wersję_plikową_PORTB: Jak najbardziej chcemy wypuścić wersję plikową, ale tutaj w grę wchodzi kwestia... hmm... "polityczna", bo jakie były reakcje na party version? "A dlaczego to hur wymaga tyle ramu dur!!1", "E tam, tak to każdy potrafi. Wyczynem to byłoby zmieścić się w 64 kB tak jak na komodore" i tego typu dyrdymały. Więc ja wiem już teraz, że wersja, która będzie wymagała czegoś więcej niż stock atari na bank spotka się z krytyką. Oczywiście można machnąć na to ręką, ale włożyliśmy w projekt na tyle dużo wysiłku, że chcemy zrobić to porządnie, stąd pomysł wersji kartridżowej (chociaż pewnie kartridż 1MB też będzie krytykowany, bo komodorowski zajmuje mniej), a w drugiej kolejności, na bazie wersji kartridżowej wersja plikowa na dodatkową pamięć. Nie jestem pewien jeszcze ile, ale w 512 kB zmieścimy się z zapasem, nie wiem tylko o ile da się zejść mniej (liczba roboczych banków wymagających do działania silnika nie jest duża, a resztę danych można albo doczytywać, albo trzymać spakowane).
W celach deweloperskich w sumie nie potrzebuję emulować pełnego kartridża 1 MB, bo do testów przecież nie trzeba mieć na pokładzie wszystkich poziomów i wszystko da się przetestować jak będą powiedzmy trzy. W tej chwili mam w atari Ultimate 1MB. Da się nim udawać jakieś kartridże i jeśli tak, to jakie duże? A SIDE2? Tam da się udawać kartridż 256 KB, czy coś źle rozumiem? Ewentualnie z innych proponowanych co można w miarę bez problemu nabyć? Na www.mega-hz.de widzę że The!Cart można kupić za 60 euro... w sumie źle to nie wygląda.

No i o to chodziło. Żeby maszyna pomagała, jak człowiek zrobi jakąś wierutną głupotę, bo nie wiem jak inni, ale ja nieomylny nie jestem. Dziękować!

A to to ja wiem, że zrobiłem bład, zgłaszam tylko, że mads ten kod zaakceptował jako poprawny.

Zasadniczo...

Ale zagadnienie wygląda mi na skomplikowane, bo jednak organizacja pamięci video w snesie i jego scrolling wydaje się bardziej przewidywalne niż w Atari. Chyba raczej trzeba byłoby pójść w analizę kolejnych klatek wychwytując podobieństwo w postaci przesunięć - tak jak robią do kodeki.

Zanim kupiłem konwerter z pierwszego posta (na szczęście umówiłem się ze sprzedawcą że będę mógł oddać), testowałem urządzenie kolegi:

Ono działa poprawnie. Jakość dla mnie była zadowalająca. Od biedy dałoby się stosować je jako przejściówkę HDMI, bo ma takież wejście. Cena tylko sporo większa. I gabaryty.

Konwertery, jeśli ktoś chciałby kupić, żeby nie wszedł na minę, bo nigdzie nie piszą, czy konwerter konwertuje RGB czy tylko composite.

Zaczynanie tego wątku było błędem, bo skoro nawet Fox nie zrozumiał intencji, a ludzie zaczynają narzekać dlaczego vbxe niem ma obrotów i skalowania, to wnioskuję, że w naszym światku nie ma jednak gruntu na merytoryczną dyskusję na ten temat.

Tego się spodziewałem, ale tak jak napisałem na początku, chciałem się spytać, bo nie jestem na bieżąco, a przebrnąć przez kilkuletnie zasoby forum mi się nie udało. Nie wiedziałem też, jak bardzo upchany jest rdzeń, bo skądinąd wiem, że rdzeń Rapidusa zajmuje tylko ułamek zasobów.
No i TeBe nie bulwersuj się tak, bo to przecież oczywiste, że nie chodziło mi o przyjazność dla programisty, która jest rewelacyjna, bo prościej oprogramować się tego nie da, tylko o przyjazność dla CPU, aby miał mniej danych do przewalenia
generując jakąś zawartość.

Udostępnij takiego zepsutego ATRa to będzie można myśleć co się zepsuło i ew. odzyskać pliki, jeśli to możliwe. Przy raportowaniu błędów do podstawowa sprawa, bo samo powiedzenie, że jest błąd niewiele niestety mówi.

Czyli w PALu wszystko się pięknie mieści! Dzięki PIN, jesteś jedynym człowiekiem na świecie, który nie położył lagi na temat i wysłał screena, a jankesom, którzy marudzili że im się w NTSC na monitorach nie mieści, nie chciało się fotki cyknąć...

Dla formalności zrobiliśmy update do wersji 1.0.1 poprawiający odgrywanie muzyczki na NTSC oraz zamieściliśmy alternatywną wersję z węższą pierwszą i ostatnią linią (tutaj PAUSED i z progressem na dole), w nadziei, że tym razem zmieści się na monitorach.

A te VBXE to jednak żyleta...

Mam pewne wątpliwości co do pogarszania sprawności dekompresora, aby mógł poradzić sobie ze strumieniami, których nikt przez 17-lat jego istnienia nie napotkał.
Czy byłaby szansa, aby wyróżnić w kodzie zbiór ficzerów pozwalających na warunkową kompilację włączającą lub wyłączającą wsparcie dla tych egzotycznych danych wejściowych? Może nawet dałoby się napisać narzędzie, które analizując skompresowany strumień generowałoby odpowiednie makra, coś jak optymalizacja RMT.

marc458: z tego drugiego to ja byłbym już zadowolony. Mora pewnie jest przez jakieś niejawne skalowanie, może jakbyś pogrzebał w ustawieniach, to dałoby się ją wyeliminować.