51

Odp: atari800 v. 2.0.0

Jellonek: tylko że Numen na ZX81 nie istnieje, a ja na poparcie moich słów mam działający program.

To, że mam rację, możesz łatwo sprawdzić wg mojej sugestii powyżej: wziąć maszynę o analogicznej mocy obliczeniowej (3,8 MIPS) i przy użyciu dowolnego kompilatora C zaimplementować w tym języku engine 6502 - jeśli osiągniesz w tym silniku 50% szybkości mojego, to osobiście Ci pogratuluję i odszczekam.

EDIT: Istnieje też alternatywa, emulec gdzieś tam się wala po sieci w postaci binarnej (o ile pamiętam 150k pliku wykonywalnego), możesz wziąć disasembler i zajrzeć.

Jeśli natomiast nie chce Ci się tego robić, ale za to wolisz twierdzenia o Numenie na ZX81, to - jak to już zresztą zostało dośc dawno temu powiedziane - dalsza dyskusja jest bezprzedmiotowa.

Ostatnio edytowany przez drac030 (2006-01-05 16:36:57)

KMK
? HEX$(6670358)

52

Odp: atari800 v. 2.0.0

Fox napisał/a:

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.

Do użycia MMU w celu bankowania pamięci nigdy nie doszedłem, porzuciłem dalszą pracę nad tym programem sporo wcześniej, kiedy się przekonałem, że host jest za wolny na to, co chcę zrobić. Teraz (68060/66 MHz) jest prawdopodobnie wystarczająco szybki, no ale mi się już nie chce.

KMK
? HEX$(6670358)

53

Odp: atari800 v. 2.0.0

jellonek napisał/a:

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.

https://www.youtube.com/watch?v=jofNR_WkoCE

54

Odp: atari800 v. 2.0.0

Ja dodam jeszcze iz uzywanie jednostek vektorowych jest C (zwlasza o 128bitowych rejestach np. VU w PS2, Altivec w G4 czy  SSE w intelu) jest bardzo utrudnione, a przyspiesza program na poczatek 4 x. Asm bedzie zyl wiecznie :-).

55

Odp: atari800 v. 2.0.0

rzeczywiscie - meła kulpa - w tych przypadkach assembler wydaje sie byc niezastapiany (np. jako wstawki w C :D ) ale co do stosowania jednostek wektoryzujacych - dobry kompilator powinien ,,zauwarzac'' odpowiednie konstrukcje i je wektoryzowac (np. przetwarzanie nastepujacych po sobie 4 konstrukcji operujacych na 4 kolejnych slowach - i robiacy na nich np. jednakowa operacje - np. mnozenie (przy powiekszaniu), dodawanie (przy powiekszaniu/przesuwaniu), czy inne)...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

56

Odp: atari800 v. 2.0.0

a nawet "zauważać".

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

Odp: atari800 v. 2.0.0

Fox napisał/a:

Przy okazji: w emulatorze taki ficzer jest stosowany lub nie w zależności od procka. Kto posiada wiedzę o tym, czy opłaca się go stosować na konkretnych prockach, proszony jest o uzupełnienie/korektę poniższego fragmentu Atari800:

 alpha* | arm* | hppa* | ia64 | mips* | sparc*)
     enable_unalignedwords=no
     ;;
 i*86 | m68* | powerpc* | x86_64)
     enable_unalignedwords=yes
     ;;

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.

Ostatnio edytowany przez Adam Klobukowski (2006-01-05 22:59:28)

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

58

Odp: atari800 v. 2.0.0

dely: dziekuje za zwrocenie uwagi (ale coby w archivum pozosalo - przyznajac sie do bladu - nie zmienie)
adam: w takim razie enable_unalignedwords=yes jest jak najbardziej na miejscu we wspomnianym kontekscie?

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

Odp: atari800 v. 2.0.0

jellonek: zleży co sie dokładnie myśli pod tym pojęciem

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

60

Odp: atari800 v. 2.0.0

Przyznam, ze niewiele pojmuje z Waszej dyskusji ;)
Chcialem tylko powiedziec, ze nie rozumiem ludzi, ktorzy uznaja za normalne ze do emulacji 8-bitowej 2MHz maszyny potrzeba P3 600MHz (a i tak sie przycinaja dema jak ktos powiedzial).
Rozumialbym to w ustach ludzi, ktorzy zaczynali swoja przygode z komputerami od Win98 a nie od Atari!
To chyba jakis zanik sztuki programowania na swiecie nastapil :/
Przeciez na Atari ST (16bit 8Mhz) odpalalem emulator XT (czylu 16-bit), ktory chodzil z szybkoscia 1MHz! Czyli przelozenie szybkosci bylo 8:1.
Potem na Atari ST byl emulator (fakt, ze baaardzo marny) Atari 800, czyli przelozenie szybkosci zegarow bylo podobne (no i procesor 16bit).
Potem na Pentium 100MHz pod DOSem gralem z powodzeniem na pacyfiST'cie w gry Atari ST. Czyli znow, przelozenie szybkosci bylo 12:1 (i procek w PC o kilka technologii lepszy od motorolki 68000).

A teraz uznajecie za NORMALNE ze na procku 200MHz (o 20 lat nowszym i 100x szybszym) nie mozna zaemulowac Atari 8-bit?!
I prosze mi nie tlumaczyc ze szybkosci taktowania w roznych prockach i systemach nie mozna porownywac. Wiem co to asembler, risc i watki. Chodzilo o ogolna ilustracje zjawiska coraz bardziej zasobozernych programow. W koncu kazdy kolejny procek, na ktory byl pisany emulator nie dosc ze jest szybszy (MHz) to jeszcze ma nowoczesniejsza architekture.

Dla spokojnosci odpalilem znowu wczoraj emulator ST na moim 200MHz pockecie  i wylaczylem automatyczne gubienie klatek. Ustawilem na zero. Ten emulator nie potrafi pokazac szybkosci oryginalu ale wyswietla ilosc klatek. Wylaczylem tez dzwiek (bo u mnie cos charczy). Gralem pol godziny w PANG'a w wielkim komfortem i gra chodzila _idealnie plynnie_. Zaryzykuje ze bylo to 100% oryginalu. Licznik klatek oscylowal caly czas wokol wartosci 30-40/s.
CZYLI DA SIE! (przelozenie szybkosci prockow ARM do 68000 w MHz to 24:1)

(a w Atari800 nie moge znalezc nawet opcji calkowitego wylaczenia emulacji dzwieku _na ppc_ - moze ktos wie jak to zrobic?).

61

Odp: atari800 v. 2.0.0

Nosty: to proste->kiedyś, jak brakowało pamięci (standard) optymalizowano kod, teraz jak czegoś brakuje każdy ma gdzieś optymalizację i po prostu zwiększa minimalne wymagania ;)
"640KB w zupełności wystarcza" Rachunek Brama, firma MałyMiękki ;)

Ostatnio edytowany przez Sikor (2006-01-06 09:00:17)

Sikor umarł...

62

Odp: atari800 v. 2.0.0

nosty, to nie jest takie proste. W takim emulatorze atari800 większość mocy maszyny zżera prawdopodobnie nie tyle sama emulacja CPU, co fakt, że emulator musi też utrzymać proporcje czasowe rozkazów i w ogóle działania całości. Czyli, LDA #$02 / CLC / ADC #$02 nie ma tylko dodawać dwa do dwóch, ale jeszcze zrobić to w sześć cykli wirtualnego czasu. To tak tytułem prostego przykładu.

Poza tym faktem jest owszem, że dzisiejsze procesory są nowsze i lepsze, ale zwróć uwagę, że 6502 jest procesorem ośmiobitowym, a rozkazy operują na pojedynczych bajtach. W związku z tym spora część mocy obliczeniowej takiego 32-bitowego procesora jak Motorola 68030 się przy emulowaniu takiego LDA/STA po prostu marnuje, bo co z tego, że procesor jest w stanie machnąć 32-bitowe move, skoro to w normalnym silniku 6502 w zasadzie nie zachodzi (aczkolwiek można posztuczkować, pewnie, wszystko można). Itd.

Ostatnio edytowany przez drac030 (2006-01-06 09:08:32)

KMK
? HEX$(6670358)

63

Odp: atari800 v. 2.0.0

jellonek napisał/a:

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.

https://www.youtube.com/watch?v=jofNR_WkoCE

64

Odp: atari800 v. 2.0.0

Adam Klobukowski napisał/a:

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.

https://www.youtube.com/watch?v=jofNR_WkoCE

65

Odp: atari800 v. 2.0.0

nosty, emulator emutalorowi nierowny,
w starym winstonie tez moglem sobie pograc na P233, i nie przeszkadzalo mi gubienie klatek, dzwiek z pupy czy brak emulacji blittera, kbd cpu, ste sound itp)

aktualne wersje pacifista i steema zrzeraja o niebo wiecej mocy niz poprzednie wersje dzieki temu ze sa bardziej dopracowane (chociaz nie emuluja 100% sprzetu ST), prawie idealnie maja docyklowany CPU per raster, dzwiek tez juz jest bliski orginalowi.

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

Odp: atari800 v. 2.0.0

aktualne wersje pacifista?

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

67

Odp: atari800 v. 2.0.0

pewnie chodziło mu o SainT-a :)

I Ty zostaniesz big endianem...

68

Odp: atari800 v. 2.0.0

ops, pomylka


miker ma racje :)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

69

Odp: atari800 v. 2.0.0

Jak najbardziej.

Tia, jasne. Czesc mu sie uda ale  to tylko przypadkiem. W C nie ma danych typu vektor sorry, sa co prawda rozszerzenia
ale to nie jest standart. Juz widze jak np. operacje permutacji dostepne w altivecu sa wykorzystywane przez kompilator :-D
Wybacz ale reczna sterowanie VU wypada zdecydowanie lepiej - popatrz w zrodla np. Mplayera. - ciekawe czemu jest kika roznych wersji w asm w  zaleznosci od procesora moglby przeciez uzyc jednej przenosnej.

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.

masz zapewne na mysli intrinsic function - przenosnie jak nie wiem co roznie dobrze moge sobie __asm__ uzyc zadna roznica.

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.

Mi na PS2 procedura dostala kopa x6. wiec da sie. Trzeba pamietac o nieblokowaniu potoku, i jednostek load/store a takze
wiedziec jak dziala przewidywanie skokow. Co do szkoda zachodu no coz faktycznie taniej jest kupic nowy hardware, ale czasem jest to niemozliwe - np. PS2 :-).

70

Odp: atari800 v. 2.0.0

"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. ;)

https://www.youtube.com/watch?v=jofNR_WkoCE

71

Odp: atari800 v. 2.0.0

fox: zart z "kup se nowy sprzet" moze tu byc baaardzo zle zrozumiany... lepiej sie powstrzymaj od tego typu komentarzy.

co do stosowania wektorow - cos mi sie po glacy kojarzy jak by to mozna bylo stosowac w emulacji antica (gdyby duchow nie bylo :/)

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

72

Odp: atari800 v. 2.0.0

Fox napisał/a:

"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. ;)

Ok w kontekscie emulacji atari 100 % racji. Pozytek sredni.

73

Odp: atari800 v. 2.0.0

Wydaję mi się, że temat dyskusji nieco się oddalił. Może wizualnie przypomnę o temacie :-)

http://img516.imageshack.us/img516/4531/cimg00956ws.th.jpg

Ostatnio edytowany przez alex (2006-01-08 18:10:39)