Dzięki!
xedisk poprawiony. :)
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
maxYMiser FM v1.67 Nowa wersja trackera.
Echa Forevera 23 Wyniki konkursów dla platformy Atari.
Atari Font Maker V1.16.14.4 Narzędzie do projektowania zestawów znaków dla Atari właśnie otrzymało aktualizację
Ruszyła strona Silly Venture 2k25SE Party place pozostaje bez zmian.
Zmarł mOdmate Zmarł mOdmate
atari.area forum » Posty przez Fox
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:
anc #$fe
ror @
Znalazłem na https://codebase64.org/doku.php?id=base:3d_rotation
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?
Inny pomysł:
opt f-
org $A000
opt f+
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.
Dzięki! Zrobiłem tak: https://github.com/pfusik/upkr6502/comm … a7fbe69307
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ę!
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.
wersja z mnożeniem wymaga hakowania źródeł, bo faktycznie MADS nie potrafi tego skompilować.
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.
LDA (ptr,X) ; X=0
a przy asemblacji na 65C02 korzysta z jego instrukcji i trybów adresowania, np.
LDA (ptr)
Drugi przykład:
STX foo ; X=0
STZ foo
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
Trochę to trwało, ale mamy rANS w wydaniu Upkr: http://www.atari.org.pl/forum/viewtopic … 04#p315204
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.
atari.area forum » Posty przez Fox
Wygenerowano w 0.060 sekund, wykonano 19 zapytań