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
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
Opcje wyszukiwania (Strona 1 z 72)
Strony 1 2 3 … 72 Następna
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
xxl napisał/a:pewnie w weekend pojawi sie dla Atari :-)
https://github.com/pfusik/upkr6502
241 bajtów. Szybsze od 471-bajtowej depakowaczki Shrinklera.
No kod na Z80 wygląda nieźle... Na Lynxa słabiej.
Respect dla TeBe za danie cynku.
Poproszę dopisać:
Upkr: 1403 (upkr -9) https://github.com/exoticorn/upkr
RiverRaid.rom: 5945
Landscape.xex: 12480
Moje smult10 zostało zoptymalizowane o dwa cykle przy pomocy 256-bajtowej tablicy. Widzę też możliwość optymalizacji:
przy pomocy nielegala:
Znalezione posty [ 1 do 25 z 1,800 ]
Strony 1 2 3 … 72 Następna
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.065 sekund, wykonano 16 zapytań