@Mateoos - będzie mnóstwo czasu na Zlocie. Czas na decyzję do soboty w południe.

I też bardzo chciałbym nie zabierać z powrotem do Wrocławia tego Thomsona.

Poprawiony kod, bo był zabugowany i nie działał na prawdziwym Lynksie (A właściwie z oryginalnym ROMem)

Zrobiłem release z poprawką literówki i relatywną ściężką trace-loga do pliku ze skryptem.

https://github.com/laoo/Felix/releases/tag/v0.6.3

Zrobiłem test dla Lynksa kompresując jakiś losowy obrazek z sieci, wygenerowałem trzy wersje: z pętlą, z tablicami oraz z użyciem sprzętowego mnożenia i prawdę mówiąc "na oko" te dwa ostatnie są bardzo zbliżone. Nie potrafię od ręki policzyć czasu, ale w emulatorze policzyłem wykonane instrukcje i wyszło mi:

loop: 5527257
table: 3172612
math: 3045851

Z tym, że wersję ze sprzętowym mnożeniem można jeszcze podrasować, ale to trzeba testować na prawdziwym Lynksie, do którego nie mam teraz dostępu.

Załączam źródła, obrazek i binarki, teraz skompiluje się wersja z pętlą, łatwo przestawić na wersję z tablicami, ale wersja z mnożeniem wymaga hakowania źródeł, bo faktycznie MADS nie potrafi tego skompilować.

Za obliczenia odpowiada chip Suzy, który jest 16-bitowy. Wszystkie jego rejestry są 16-bitowe i mają tę samą właściwość - zapis młodszego bajtu zeruje starszy, ale nie jest to traktowane jako zapis do starszego bajtu, tylko jako zapis liczby 16-bitowej, gdzie starsze 8 bitów jest uzupełnione zerami. Zapis do A jest konieczny, gdyż w przypadku mnożenia pod zapis starszego bajtu pary AB podpięty jest start mnożenia. Z tego co widzę w unupkr jest poprawnie - najpierw zapis do D (co zeruje C), potem do B (zerując A) a na końcu do A startując mnożenie.

Wszystkie rejestry matematyczne są też do odczytu, mają jednak specyficzne funkcje. Rejestry AB i CD służą do przyjmowania argumentów dla mnożenia, za to jest do nich zapisywany wynik dzielenia. Nigdy tego nie sprawdzałem, ale zakładam, że po wykonaniu mnożenia są w nich niezmienione argumenty - tak przynajmniej zrobiłem w emulatorze i żadna aplikacja do tej pory się nie wywróciła na operacjach arytmetycznych, więc chyba tak jest.
Co do szczegółów działania można poczytać emulator: zapis i odczyt rejestrów oraz same obliczenia

Jeszcze jedna rzecz - w przypadku mnożenia bez znaku i bez akumulacji (domyślnie jest to wyłączone, można to aktywować w rejestrze SPRSYS) mnożenie trwa 44 cykle 16 MHz. Odczyt dowolnego rejestru Suzy zajmuje minimalnie 5 + 4 + 4 + 9 = 22 cykle, a np operacja RMW zerostronicowa minimalnie 5 + 4 + 5 + 4 + 5 = 23, więc "INC $xx; LDA H" powinno wystarczyć, ale trzeba byłoby to sprawdzić. Tak jak pisałem w drugim temacie - znajdę wystarczająco czasu, to napiszę test.

"Urządzenie" ma już wymyśloną minimalną funkcjonalność. Jest już zaimplementowane na brudno w Altirrze jako kolejna wersja / alternstywa dla rdzenia FX dla VBXE. Jesteśmy w trakcie implementowania tej funkcjonalności jako modyfikacją GTIA w rdzeniu Atari800 w MiSTerze ze względu na wygodę developiwania. Jak uruchomimy, to znaczniemy przenosić to do docelowego VBXE. Jeżeli się to nie uda, to znaczy, że projekt był przestrzelony, bo te minimum, które zaprojektowałem, to serio minimum którego próba obcięcia jest bez sensu. Ale będę się tym martwił jeśli to nastąpi, na razie na podstawie tego co wiem, że jest w rdzeniach FX jestem nastawiony optymistycznie - dlatego w ogóle to robimy.

To, czy rdzeń będzie opublikowany jako OpenSource - tego nie wiem. Ani ja o tym decyduje ani nie mam też zdania jak w tym konkretnym projekcie powinno być, coś mi się jednak wydaje że nawet jakby to otworzyć to i tak nic by z tego nie wynikło - mam za dużo otwartych projektów na githubie, żeby wierzyć, że komuś zrobi to różnicę. Na pewno mogę Cię jednak zapewnić, że jeśli projekt się powiedzie, to zostanie opisany i każdy będzie mógł napisać sobie grę używając tego rdzenia.

Jeśli chodzi o algorytmy komoresji to nie chce wychodzić jednak zbyt dalego poza kompresję jaka już jest, czyli wzięty z Lynksa RLE, który jest bardzo miły dla przepustowości pamięci, bo pozwala na czytanie mniej bajtów niż trzeba zapisać w pamięci obrazu, więc wychodzi lepiej niż kopiowanie i więcej nie trzeba.

VBXE ma już 18 lat (to już powoli retro bo jest starszy niż nasze Atari podczas rozkwitu sceny :)), więc próba tchnięcia w stary sprzęt nowego życia za pomocą świeżego firmware'u jest wg mnie jak najbardziej w duchu sceny.
Dodatkowo jest tego naklepane setki sztuk, więc może mieć to nawet wymiar dość praktyczny, jeżeli dałoby się tego użyć prościej.

Nie potrafię odpowiedzieć na to pytanie, ale nie wiem, czy jest to witalne zagadnienie. Skoro przez 18 lat nikt się tym nie interesował, to dlaczego nagle teraz miałby być wysyp zainteresowanych? Na razie są wczesne prace nad pomysłem, o którym myślę sobie od paru lat, mam prototyp funkcjonalności w Altirrze (więc od razu będzie emulacja) oraz pracujemy z Mateuszem nad prototypową implementacją w MiSTerze, jak będzie z wciśnięciem tego co wyjdzie do VBXE to zobaczymy. Jak się nie uda, to nie będzie tematu :)

Dekompresja jest w locie podczas rysowania sprajta. Szału nie ma, ale w zależności od sprajta kilkadziesiąt procent rozmiaru można być do przodu.

To zależy od narzędzi. Mamy już jakieś narzędzie do robienia rzeczy na Lynksa, tutaj blitter będzie dość kompatybilny z tym Lynksowym, więc narzędzia projektujemy analogiczne. Tu jest mój program do konwertowania PNG do sprajtów Lynksowych, mam już wersję dla "nowego rdzenia VBXE". Można poczytać co on potrafi - jest projektowany na generowanie scen, które mają wspólną paletę. Rozmiar sprajta z grubsza dowolny. Można trzymać wiele klatek animacji poziomo.

Dałoby się ciekawą pracę magisterską napisać analizując i porównując sposoby, w jakie była generowana grafika w konsolach 8 i 16 bitowych.
Przez 18 lat nikt nie wziął i nie napisał innego rdzenia do VBXE, każdy, który by się za to brał, miałby swoją wizję. Moja wizja jest rezultatem moich doświadczeń i przemyśleń i uważam, że jest dobra. Póki nie okaże się, że w VBXE zrobić tego się nie da, rewolucji na miarę "zróbmy NeoGeo" nie przewiduję, bo to zupełnie inna filozofia (no i NeoGeo swoją wypaśność zawdzięcza bardziej grubej rurze, którą lecą piksele z cartridge'a na ekran, a nie jakiejś finezji - a takiej rury w VBXE nie mamy).

Nie tylko wielbiciele BASICa zaglądają na to forum i różne mądre dyskusje tutaj już były. Jak nikt się nie znajdzie, to trudno. Jakieś tam swoje pomysły już mam.

A tego właśnie nie wiedziałem, czy pierwsze wgranie emutosa jest flaszerem czy programatorem. Tylko flaszer ingeruje w obszar opisu wgranych TOSów, więc rzeczywiście przy pierwszym uruchomieniu będzie wyglądał na pusty. Dodatkowo błąd weryfikacji też nie uaktualnia tego wpisu (że też będzie pusty).
Mam nadzieję, że niedługo powstanie więcej software'u, ale mam teraz urwanie głowy z milionem innych rzeczy i jeszcze nie dałem rady do tego usiąść.

Wygeneruj sobie flaszer fabrycznego 1.62 i zaflaszuj na inny slot. Flaszer po starcie wydrukuje gdzie jest emutos a które są wolne.

Jakby pojawił się błąd weryfikacji, to możesz albo powtarzać aż się zweryfikuje albo zignorować bo to false negative przy odczycie zaflaszowanego rdzenia - soft jest do korekty.

Jeszcze jedno - teraz kabelek jest potrzebny bo nie dopisałem w software opcji przełączania rdzenia, trzeba resetem.

Ja miałbym bez sprzętu przyjechać? Z roku na rok nawet przywożę więcej!