Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Altirra 4.50 test4 Nowa wersja testowa emulatora Altirra przynosi poprawki interfejsu oraz wsparcie dla środowiska Wine.
8. edycja Atari Homebrew Awards Ruszyło głosowanie na najlepsze gry wydane w 2025 roku na konsole i komputery Atari.
AspeQt-2K26 Nowoczesny fork klasycznego AspeQt wspierający Qt 6 i TNFS
Fujisan 1.1.3 Fujisan 1.1.3 to nowa odsłona emulatora opartego na libatari800, skupiona na integracji z FujiNet.
Śnieżna planeta w Cosmic Hero 2 Zelax prezentuje postępy nad kontynuacją klasyka. Zobacz mroźną planetę w Cosmic Hero 2.
atari.area forum » Posty przez Fox
Hm, to przy okazji jeszcze uzupełnianie nazw plików TABem (nawet winda to ma, tyle że zje*ne), Ctrl+L zamiast Ctrl+Clear, Ctrl+D zamiast Ctrl+3 (efektem w shellu jest logout)... ;)
A poważnie to nie można w SDX zwyczajnie najechać kursorem na poprzednią komendę o ile jeszcze jest na ekranie?
Stary patent. Nawet heyah ma taki wygaszacz pod windę na stronie.
Bardziej hardcorowe byłoby np. wyświetlanie w kodzie Graya.
Albo ósemkowo (zegarek powinien wyglądać normalnie, żeby nie wzbudzać podejrzeń). :)
Albo LFSR (czyli to co jest w POKEYu do generowania zniekształceń) zamiast licznika.
FP atarowskie wykorzystuje inny porządek niż naturalny dla 6502 (mantysa jest zapisywana od najstarszego bajtu do najmłodszego).
Mantysa jest w BCD, a 6502 ma operacje BCD tylko 8-bitowe, więc ciężko mówić o jakimś naturalnym porządku bajtów. >;->
piotrv: jeśli chodzi o wykładnik, to przecież może on być wykładnikiem 4 , 16 czy wręcz 256 a nie 2 i od razu będzie większy zakres liczb. Jeśli wybierzesz wykładnik 256 to operacje w rodzaju dodawania powinny dostać kopa (wydajnościowego), nawet jak dołożysz bajt na mantysę żeby nie tracić na dokładności.
Szkoda, że liczby FP nie są little endian - można byłoby lepiej wykorzystać 816,
Jeśli sam implementujesz FP, to możesz jak najbardziej wybrać reprezentację little-endian.
a dla 6502 to chyba wszystko jedno.
W przypadku CC65 korzystniejsze wydaje się big endian - tj. wykładnik w akumulatorze (dla intów i longów jest tam LSB).
Nie szybkie tylko krótkie. Cztery podstawowe operacje arytmetyczne oraz konwersje z/na int w niecałych 256 bajtach kodu, logarytmy i exp w 512 bajtach - całkiem nieźle. Na 6502.org nie znalazłem najtrudniejszych operacji dla takiej reprezentacji floatów: konwersji z/na string.
W jakimś bajtku pisało chyba, że Indus GT to marka LDW w USA - fizycznie stacja jest identyczna z LDW2000.
667 bajtów - najprostszy program który zrobiłem - czekanie na wciśnięcie klawisza
Sporo zajmuje właśnie ten crt0, który m.in. pobiera linię poleceń z różnych DOSów (w tym tak archaicznych jak DOS XL). Źródło tego (w pliku .s) jest w źródłach cc65.
Wynika z tego że moja prosta funkcja zajeła jakieś 300 bajtów
A kompilowałeś z opcją -O (optymalizacja) ?
printf("a[%d]=%d\n", i, a[i]);
Jeśli printf ma służyć tylko do formatu %d, to przesada go stosować.
piotrv: 4 lata temu floaty w cc65 były "TODO" i pewnie nic się nie zmieniło. W planach było użycie standardowych 32-bitowych IEEE big endian (czyli wykładnik trzymany w akumulatorze, mantysa w rejestrze X i sreg). Ulrich stwierdził, że podstawowym problemem nie są procedury dla 6502, lecz przeróbki kompilatora (w którego wnętrznościach orientuje się tylko on sam).
Emulację floatów przy pomocy funkcji stałoprzecinkowych w C zdecydowanie odradzam - szybciej będzie chodzić BASIC, szczególnie Turbo BASIC.
Jeszcze odnośnie instrukcji XCHG AL, AH. Wykonuje się ona "zawsze" 1.5 cykla (latency) i ma 1 cykl throughput. ROL AX,8 wykonuje się 1 cykl na większości procesorów, albo 4 cykle (to jest tylko na rodzinie procesorów 0xF2). Ponadto nie występuje tutaj coś takiego jak "problem emulacji rejestrów", bo jest wykorzystywana tylko część rejestru a nie całość. Jedyne co może wystąpić to "partial registry stall" albo "registry stall", czyli np.:
rol eax, 8
mov al, ahdruga instrukcja, czeka na wynik pierwszej, gdyż wartość 'ah' jest zależna od wykonania poprzedniej instrukcji. Bynajmniej nie wynika to z podziału rejestrów. Problem pojawia się jedynie w sytuacji gdy chcemy użyć rejestru, który wcześniej posłużył jako rejestr docelowy.
"Problem emulacji rejestrów" ZTCW pojawił się w PPro i ciągnął się co najmniej do PIII (wiele osób jeszcze je ma). Kiedy zniknął? Z odczytem ah z zapisanego eax ZTCW nie było większego problemu (najwyżej zwykły "registry stall"). Problem był, gdy zapisaliśmy ah i odczytywaliśmy ax lub eax (czyli w przypadku xchg al,ah, po którym zapewnie chcemy użyć ax).
Na początek może być mono.
Po prostu ja kiedyś zapisałem z 15 plansz i nie mogłem ich wczytać (chyba RK się wieszał przy wczytywaniu). Zdaje się, że później czytałem, że ktoś też miał taki problem, ale nie dam głowy.
Gdyby ktoś sądził, że "XCHG AL, AH" będzie szybsze od ciągu tych 5 instrukcji:
http://www.codingnow.com/file/pentopt.htm#19_1
Racja, ROL się ślimaczył tylko na 186 i 286:
ROL Rotate bits left
operands bytes 8088 186 286 386 486 Pentium
reg, 1 2 2 2 2 3 3 1 PU
mem, 1 2+d(0,2) 23+EA 15 7 7 4 3 PU
reg, cl 2 8+4n 5+n 5+n 3 3 4 NP
mem, cl 2+d(0,2) 28+EA+4n 17+n 8+n 7 4 4 NP
reg, imm 3 - 5+n 5+n 3 2 1 PU
mem, imm 3+d(0,2) - 17+n 8+n 7 4 3 PU*
* = not pairable if there is a displacement and immediateZa to RCL (czyli ROL z 6502) wygląda, że jeszcze w Pentium miał złożoność liniową:
RCL Rotate bits left with CF
operands bytes 8088 186 286 386 486 Pentium
reg, 1 2 2 2 2 9 3 1 PU
mem, 1 2+d(0,2) 23+EA 15 7 10 4 3 PU
reg, cl 2 8+4n 5+n 5+n 9 8-30 7-24 NP
mem, cl 2+d(0,2) 28+EA+4n 17+n 8+n 10 9-31 9-26 NP
reg, imm 3 - 5+n 5+n 9 8-30 8-25 NP
mem, imm 3+d(0,2) - 17+n 8+n 10 9-31 10-27 NPJeszcze XCHG dla ciekawskich:
XCHG Exchange register/memory with register
operands bytes 8088 186 286 386 486 Pentium
reg, reg 2 4 4 3 3 3 3 NP
reg, mem 2+d(0-2) 25+EA 17 5 5 5 3 NP
mem, reg 2+d(0-2) 25+EA 17 5 5 5 3 NP
acc, reg 1 3 3 3 3 3 2 NP
reg, acc 1 3 3 3 3 3 2 NP
in above: acc = AX or EAX only(zaczerpnięte z http://security-protocols.com/programmi … pcode.html)
"intrinsics" są oczywiście równie przenośne jak asm. VU w PS2 pewnie rzeczywiście lepiej programować w asmie (nigdy nie twierdziłem inaczej), jednak do emulacji Atari raczej na niewiele się zda (a wątek dotyczy asm vs C w kontekście emulacji Atari). Co do problemów z nowym hardware, to wkrótce będzie PS3 i wszyscy zapomną o PS2. ;)
Ja z kolei jestem lajkonikiem jeśli chodzi o MIDI. Zasadniczo potrzebny jest algorytm zamiany rejestrów AUDCx, AUDFx i AUDCTL na to, co jest w MIDI. Może być nawet w Pascalu lub BASICu. Edit: po polsku też. :)
Muzy z samplami raczej odpadają, natomiast stereo i kilka razy na ramkę warto uwzględnić. Częstotliwość wołania playera 6502 może być definiowana w SAPie z dokładnością do skanlinii (= 1773447 Hz / 114).
Podejrzewam, że największym problemem będą tablice mapujące zniekształcenia i filtry POKEYa na instrumenty MIDI. Ale może koledzy muzycy pomogą?
napisać program który będzie generował plik na podstawie muzyczki cmc
Czemu ograniczać się do CMC ?
Może tak ASAP2MIDI ?
Zalezy co sie rozumie pod pojeciem unalignedwords. Jesli chodzi o nieparzyste adresy to na m68k bodaj od 020 jest to mozliwe, ale wolne. Jesli chodzi o inny align (adres zawsze parzysty) to nie powinno byc problemow z wydajnoscia.
Rzeczywiście nie wyraziłem się jasno. Chodzi o to, czy dostęp do niewyrównanego słowa (16- lub 32-bitowego) jest najwyżej 4-krotnie wolniejszy od wyrównanego. Mniej-więcej taka jest granica, przy której opłaca się używać w Atari800 dostępu do całych słów, które potencjalnie mogą być niewyrównane (zazwyczaj są wyrównane).
Czyli ficzer "unalignedwords" odpada jeśli procesor w ogóle nie daje dostępu do niewyrównanych słów lub daje tylko dzięki pomocy systemu operacyjnego, który obsługuje wyjątek dostępu do niewyrównanych słów.
co do stosowania jednostek wektoryzujacych - dobry kompilator powinien ,,zauwarzac'' odpowiednie konstrukcje i je wektoryzowac
Jak najbardziej. A jeśli ich nie zauważa ani nie zauwarza, to można użyć w C "intinistic functions",
czyli wywołań funkcji, które kompilator zamienia na odpowiednie instrukcje asma.
4-krotne przyspieszenie to bajki. Procesory są zoptymalizowane pod kątem przetwarzania "zwykłych" instrukcji (np. często mają więcej potoków dla nich). Sam kiedyś robiłem testy, w których na Dureniu 700 procedura na zwykłych instrukcjach 386 była kilkadziesiąt procent szybsza od procedury z użyciem MMX, chociaż w przypadku MMXowej było wykonywane kilkukrotnie mniej instrukcji. Na Pęntlum III 500 MMX miał przewagę zaledwie kilku procent - szkoda zachodu.
mozesz tez powiedziec na zastosowanie jakiej konstrukcji nie pozwala C?
ja mogę powiedzieć jakich konstrukcji asemblera nie ma bezpośrednio w C: zamiana słów (xchg), zamiana kolejności bajtów (bswap), obroty (rol, ror, rcr, rcl), operacje BCD (daa, das) i na cyfrach dziesiętnych (aaa, aas, aam, aad), dzielenie z resztą (jedna operacja, dostępny wynik dzielenia i reszta). Obroty i operacje BCD mogą się przydać w emulacji 6502, ale bez przesady, przecież programy na Atari rzadko używają takich ficzerów.
Fox - mylisz sie. Znaczy moze i gubio ale za diabla tego nie widac. A na Atari800 juz przy 1:3 widac jak cholera.
Podaj dokładne nazwy i wersje tych emulatorów oraz na jakim sprzęcie je uruchamiasz.
drac030: Zgadza się. Np. pisząc if-a nijak nie można wytłumaczyć kompilatorowi, że warunek będzie np. w 90% spełniony. W asemblerze jest tu większe pole do popisu. To jednak może tłumaczyć 50% a nie 600% różnicy w wydajności. Taką różnicę w przypadków programów na Atari "migających" bankami pamięci mogłoby tłumaczyć użycie sprzętowego mechanizmu stronicowania, zamiast przepisywania pamięci. Jednak sprzętowe stronicowanie można również osiągnąć w C wywołując odpowiednie funkcje systemowe. Co więcej, w asemblerze też trzeba wywołać te same funkcje systemowe, o ile emulator pracuje pod kontrolą systemu operacyjnego (a nie np. DOSa).
Fox napisał/a:Na 99% nie spotkałem się nigdy na giełdzie jednocześnie z Tobą, Mikerem i Lewisem.
A jednak!!!
kto jeszcze był i po co się spotkaliśmy?
I wtedy padło to słynne "napisz se".
Apropos czego? Ciężko mi sobie wyobrazić, abym coś takiego powiedział Tobie, Mikerowi albo Lewisowi.
Twoje stwierdzenie posłużyło jakiś czas później do tytułu pewnej produkcji, gdzie znajdują się wyłącznie wypowiedzi z atariarea, zresztą jest ona w bazie ;)
Czyli nie było w niej "napisz se" ?
Fox- mógłbyś na chwilę podłączyć paddle do atarki, żebym mógł coś sprawdzić?
Sikor coś się tłumaczy, że nie ma jak podłączyć żadnej z wielu swoich atarek do telewizora, ale że może mi pożyczyć paddle
Fox- ale ja nie chcę pożyczać, dobra, dzięki, zapomnij
Sikor (jak to Sikor) - ja i tak nie używam, a Ty może zrobisz jakąś grę
Fox- hahaha
Sikor- no weź
Fox- ale nie będę miał czasu, żeby się spotkać i oddać
Sikor- możesz trzymać ile chcesz
Fox (nie chcąc robić przykrości) - no dobra...
Jednak kontakt z PG jest tak trudny, że nie mam cierpliwości czekac na email pół roku.
Widocznie PG "wziął urlop". W każdym razie obecnie odpisuje szybko, nawet w przeciągu kilku minut.
Z tego co m i ostatnio odpisał PG pomysł jest dobry, ale na samych pochwałach i małych uwagach email się skończył. Skąd mam wiedzieć, że wysłane przeze mnie informacje co SAPów czy same rpy będa umeiszone w archiwum.
Jeśli wysłałeś mu SAPy i/lub informacje o autorach, a on podziękował, to znaczy, że będą umieszczone.
atari.area forum » Posty przez Fox
Wygenerowano w 0.061 sekund, wykonano 23 zapytań