Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Fujisan 1.1.6 Ukazała się aktualizacja Fujisan, nowoczesnego frontendu dla emulatora Atari800 z obsługą FujiNet.
A7800DS 5.2a Nowa wersja emulatora Atari 7800 dla konsol DS/DSi przynosi poprawki błędów i lepszą synchronizację.
Barbarian na Atari 8-bit już blisko Vega kończy prace nad nową konwersją kultowego Barbariana.
System Error tematem konkursu 24h Compo Poznaliśmy temat nowej edycji konkursu 24h na Atari.area. Czas na tworzenie!
Edytor poziomów Montezuma's Revenge Lew Daney udostępnił narzędzie pozwalające na tworzenie własnych piramid w kultowej grze na Atari.
Opcje wyszukiwania (Strona 1 z 73)
Strony 1 2 3 … 73 Następna
Skoro badlines to opcja wpływająca na wyświetlanie, to czy nie powinna być zapisywana w pliku *.MCM ?
Wspomnę, że alternatywą dla YT i "dem muzycznych" jest ASAP.
Lekki offtopic: właśnie się dowiedziałem, że matematycy ciągle pracują nad mnożeniem: https://en.wikipedia.org/wiki/Multiplication_algorithm
Dzięki!
xedisk poprawiony. :)
Czym wrzucić pliki na ATR z katalogami MyDOS z linii poleceń?
xedisk sypie się.
Którego kompilatora C używasz?
Nic mi nie wiadomo gotowych procedurach do muzyki do zawołania z C. Prawdopodobnie będzie trzeba dopisać z 5 linijek asemblera.
RMT łatwo przenieść w dowolne miejsce pamięci, z SAP będzie trudniej.
Czyli w skrócie: bierzesz RMT, ustawiasz mu adres ładowania (przy pomocy RMT lub asapconv), bierzesz player RMT w asemblerze i go kompilujesz.
Masz już własną procedurę VBLK? Muzykę zwykle odtwarza się na VBLK.
Przesunięcie arytmetyczne w prawo i skasowanie znacznika C:
Znalazłem na https://codebase64.org/doku.php?id=base:3d_rotation
Pin napisał/a:A nie jest tak, że na Atari kostka jest "rozsypana" od złożonej do nie złożonej, wrzucone w tablicę i hej do przodu? ;)
Nie zrozumiałem Twojej wypowiedzi. W każdym razie cały kod jest tu: https://github.com/pfusik/numen/blob/ma … /rubik.asx
@xxl, dzięki za rozmowę na party!
Moje pierwsze podejście do ZX0: 139 bajtów kodu vs 219 XXLa "nie-stream"
Obiecująco wygląda też ZX02, który jest modyfikacją ZX0 pod 6502: https://github.com/dmsc/zx02
- są tam aż trzy procedury do wyboru. Wyniki Mono wskazują, że pakuje bardzo podobnie do ZX0 - dlaczego nie ma ich w pierwszym poście?
willy napisał/a:Istnieje jekis PACKER ktory w miare szybko jest w stanie pakowac dane na 6502?
Co to znaczy "w miarę szybko" ?
http://atariki.krap.pl/index.php/FlashPack jest w miarę szybki
Kompilator C generuje kod na taki procesor, jaki mu się wskaże.
Ja pytałem, jak zwięźle pisać wspólny kod w asemblerze na różne procesory.
Fox napisał/a:Zapis do A lepiej byłoby zrobić STZ, ale xasm nie ma, DTA nie chcę zaciemniać, a w mads blokuje mnie https://github.com/tebe6502/Mad-Assembler/issues/40 :)
Wtedy możnaby całe mnożenie wystartować przed aktualizacją "probs", czyli w trakcie mnożenia robimy 30 cykli potrzebnych operacji na 6502.
mads poprawiony, STZ wstawione wcześniej, czekanie na SPRSYS usunięte. Dodatkowo tryb adresowania pośredni nieideksowany. Sprawdzisz?
Super, dziękuję!
laoo/ng napisał/a:z tablicami oraz z użyciem sprzętowego mnożenia i prawdę mówiąc "na oko" te dwa ostatnie są bardzo zbliżone.
To jest spodziewane. Natomast bez tablic kod jest mniejszy i nie wymaga tych 2 KB na tablice.
laoo/ng napisał/a:wersja z mnożeniem wymaga hakowania źródeł, bo faktycznie MADS nie potrafi tego skompilować.
Już potrafi.
Dziękuję za wyczerpujące wyjaśnienie!
W upkr jest tylko mnożenie 8x8, więc znaki 16-bitowe są bez znaczenia. O akumulacji myślałem, ale najpierw chciałbym wiedzieć, czy działa bez niej. Poza tym niezależność od konfiguracji (znakowości i akumulacji) ma wiele zalet.
Zapis do A lepiej byłoby zrobić STZ, ale xasm nie ma, DTA nie chcę zaciemniać, a w mads blokuje mnie https://github.com/tebe6502/Mad-Assembler/issues/40 :)
Wtedy możnaby całe mnożenie wystartować przed aktualizacją "probs", czyli w trakcie mnożenia robimy 30 cykli potrzebnych operacji na 6502.
https://www.monlynx.de/lynx/lynx9.html
Writing to B,D,F,H,K, or M will force a '0' to be written to A,C,E,G,J, or L, respectfully. Therefore, if you only have 8 bits in a particular number, there is no need to write the upper byte to '0'. (except for signed multiplies)
Writing to A will start a 16 bit multiply.
W upkr potrzebuję mnożenia 8x8. Jestem skonfudowany stwierdzeniem, że zapis do B zeruje A. Czy to startuje mnożenie, czy i tak trzeba zapisać do A? Jeśli tak, to jaki ma sens pisanie o zerowaniu A?
Czy te rejestry są też do odczytu?
218 bajtów.
Opcja 305 bajtów kodu z akceleracją mnożenia dwukilobajtową tablicą. 133 ramki zamiast 214 na testowym obrazku.
Bonus: tę tablicę można potem wykorzystać do mnożenia bez znaku.
Edit:
I mnożenie na Lynxie. Uwaga, nie testowałem.
Kto ma doświadcznie z kodem, który można zasemblować zarówno na gołe 6502, np.
a przy asemblacji na 65C02 korzysta z jego instrukcji i trybów adresowania, np.
Drugi przykład:
Chodzi mi o to, żeby nie pisać za każdym razem asemblerowego ifa.
Czy znacie asemblery, które mają pseudoinstrukcje lub specjalną składnię w tym celu?
Ewentualnie zestawy makr - jakie sami używacie lub gdzieś widzieliście.
Uruchom z wiersza poleceń.
224 bajty. Doszła opcja --invert-new-offset-bit - zmniejsza kod o jeden bajt.
Dodałem README. @xxl - przestaw linka w pierwszym poście na https://github.com/pfusik/upkr6502
Kiedyś napiszę README (prawdziwy programista nie pisze dokumentacji ;)
236 bajtów na kod (może być w ROMie, nie modyfikuje się)
319 bajtów na bufor (najlepiej od granicy strony)
14 bajtów na stronie zerowej, z czego na początku standardowo wskaźniki na spakowane i gdzie rozpakować
Trochę wolne, ale analogicznie jak w Shrinklerze dam dopałkę mnożenia tablicą kwadratów jako opcję.
236 bajtów i kilka procent przyspieszenia. Co do opcji, spójrz trochę wyżej.
Dopiszesz wyniki i link w pierwszym poście?
To wstępna wersja, mogą być błędy. I pewnie da się jeszcze nieco wycisnąć.
Fajnie, że paker ma taki tuning.
-9 = najwyższy stopień kompresji
-b = pobieranie wejścia po bicie, dzięki czemu mamy mnożenie 8x8, bez tego 12x8
--invert-continue-value-bit = oszczędza jeden bajt kodu depakowaczki, nie zmienia rozmiaru spakowanych danych
--simplified-prob-update = upraszcza pewien fragment dekodera, z tego co widzę kosztem kompresji niektórych danych słabszej o promile
Znalezione posty [ 1 do 25 z 1,806 ]
Strony 1 2 3 … 73 Następna
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.064 sekund, wykonano 23 zapytań