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
Silly Venture 2024WE - wyniki Ponad sto prac wzięło udział w compo SV2024WE
Trwa Silly Venture 2024 w Gdańsku! Party się rozpoczęło, zajrzyj po link do streamów.
Flop 68 Po dwuletniej przerwie wraca Flop!
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
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.057 sekund, wykonano 24 zapytań