1 Ostatnio edytowany przez drac030 (2017-08-02 17:39:04)

Tebe się bawi w testy, pobawię się i ja.

Kopiowanie danych po pamięci hektarem kodu. 65C816/1,77 MHz.

Bufor źródłowy znajduje się pod (przypadkowo wybranym) adresem $35a7, docelowy pod $36a7, a bufor wyrównany do granicy 256 bajtów pod $3800. Wielkość buforów: 256 bajtów.

1. Zwykle 8-bitowe lda $xxxx / sta $yyyy, najszybsza metoda dostępna dla 6502. 8 cykli na bajt, niecałe 20 linii skaningowych.

2. To samo, ale każda para rozkazów kopiuje word. 5 cykli na bajt, 12,5 linii (5 cykli na bajt).

3. Jeden z buforów (tu źródłowy) został wyrównany do granicy 256 bajtów i wskazany jako strona zerowa: lda $xx / sta $yyyy. 11,5 linii (4,5 cyklu na bajt)

4. Bufor źródłowy jako strona zerowa, docelowy jako stos: pei ($xx). 9 linii (3,5 cyklu na bajt)

5. To samo co 4, tylko bufor źródłowy wyrównany do granicy 256 bajtow. Niecałe 8 linii (3 cykle na bajt).

6. Bufor źródłowy jako strona zerowa (bez wyrównania), bufor docelowy jest wskazany rejestrem Y: lda $xx / sta $yyyy,Y. Niecałe 14 linii (5,5 cyklu na bajt)

7. Bufor źródłowy jest wskazany rejestrem X, a docelowy rejestrem Y: lda $xx,X / sta $yyyy,Y. Tyle samo co powyżej.

8. Jak 7, tylko bez użycia adresowania strony zerowej: lda $xxxx,X / sta $yyyy,Y. 15 linii skaningowych (6 cykli na bajt).

9. Przesłanie blokowe mvn. 7 cykli na bajt, 17,5 linii skaningowej (słabo, ale i tak szybciej od nr 1, a kod zajmuje tylko kilka bajtów).

Metodę nr 9 można bez większych ograniczeń stosować na całej pamięci (16 MB).

Metody nr 1, 2, 8 można zastosować na całej pamięci (16 MB), ale tylko w obrębie konkretnego segmentu 64k.

Metody nr 3, 6, 7 wymagają, żeby jeden z buforów znalazł się w obrębie pierwszych 64k.

Metody nr 4 i 5 wymagają, żeby oba bufory były w obrębie pierwszych 64k. Poza tym lepiej mieć przy tym wyłączone przerwania, bo mogą być niespodzianki :)

--

Refleksja: przykład nr 4 i 5 dobrze obrazuje, jak dobrym pomysłem jest zaimplementowanie w procesorze rejestrów adresowych, które się "same" inkrementują lub dekrementują, i o ile wydajniej można wtedy wykorzystać dokładnie tę samą magistralę: w przykładzie nr 1 procesor połowę (dokładnie, 4 cykle z każdych ośmiu) czasu spędza na pobieraniu z pamięci niewiele różniących się od siebie adresów.

EDIT: poglądowo dorzuciłem zrzut ekranu z tego samego programu działającego na 21 MHz. Oba zrzuty oczywiście z Altirry, ale na Antonii rzecz wygląda dokładnie tak samo jak na pierwszym z załączonych obrazków.

EDIT2: literówki.

Post's attachments

C256.ARC 11.23 kb, liczba pobrań: 6 (od 2017-08-02) 

copy256.png 2.17 kb, nikt jeszcze nie pobierał tego pliku. 

copy256_21mhz.png 1.42 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.
KMK
? HEX$(6670358)

2

Tylko że 65C816 to jest 16 bit.
Wiesz takie rzeczy jak w miarę normalne c, segmenty, wskaźniki krótkie, długie i tego typu sprawy.
Oczywiście na siłę można używać tego jak 6502, ale sam rozumiesz, to nie to.

3 Ostatnio edytowany przez drac030 (2017-08-02 18:23:04)

Proszę mnie poprawić, jeśli się mylę w obliczeniach:

1) Motorola 68000/8 MHz, move.w (a0)+,(a1)+ = 12 cykli, czyli 6 cykli na bajt. Jakieś 1,2 MB/s. Dane muszą być wyrównane do granicy słowa.

2) 65C816/1,773 MHz (zegar wolniejszy 4,5 raza), metoda nr 5: 577 KB/s. Dane muszą być wyrównane do granicy strony. Bez wyrównania (metoda nr 4) to tylko 500 KB/s.

P.S. Zaczynam rozumieć, dlaczego 65C816 wywołuje taką agresję u co prymitywniejszych amigowców :)

KMK
? HEX$(6670358)

4 Ostatnio edytowany przez Adam Klobukowski (2017-08-02 19:46:28)

drac030 napisał/a:

1) Motorola 68000/8 MHz, move.w (a0)+,(a1)+ = 12 cykli, czyli 6 cykli na bajt. Jakieś 1,2 MB/s. Dane muszą być wyrównane do granicy słowa.

O ile się nie mylę, move.l (a0)+,(a1)+ = 20 cykli czyli 5 cykli na bajt, czyli około 1.6MB/s.
Przy pomocy movem da się chyba jeszcze szybciej, ale nie jestem w stanie policzyć.

Btw. 65C816 zostal wprowadzony na rynek 4 lata po 68000, więc nic dziwnego że ma usprawnienia.

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

5

Adam Klobukowski napisał/a:

O ile się nie mylę, move.l (a0)+,(a1)+ = 20 cykli czyli 5 cykli na bajt, czyli około 1.6MB/s.
Przy pomocy movem da się chyba jeszcze szybciej, ale nie jestem w stanie policzyć.

Oczywiście masz rację. A ja też powołałem się na przypadek specjalnej optymalizacji. Na Motoroli move jest bardziej uniwersalne i nie trzeba się zastanawiać, na jakiej pamięci się je wykonuje. Nadal, przykład nr 8 to 288 KB/s. Przy zegarze 8 MHz bylibyśmy tylko trochę z tyłu za Motką.

Btw. 65C816 zostal wprowadzony na rynek 4 lata po 68000, więc nic dziwnego że ma usprawnienia.

To są usprawnienia, ale tylko w stosunku do 6502. W stosunku do 68000 ten procesor jest dokładnie piętro niżej (8/16 w stosunku do 16/32). O tym, moim zdaniem, że on mimo tego może nadal konkurować z 68000 (oczywiście na dłużą metę odpadając, ale jednak nie tak bardzo jak 6502), stanowi synchroniczna magistrala i jej zasada, że 1 cykl = 1 bajt. W Motce 68k mamy chyba 1 word = 4 cykle i tu można coś ugrać.

KMK
? HEX$(6670358)

6

Hej!

Tak trochę nieco obok, tematu... wypakowałem plik .com z archiwum ARC, używając narzędzia "disk explorer" wbudowanego w altirra, przełączyłem emu na 65816 (1.79MHz / 21MHz). Uruchomiłem plik.... jednak widzę tylko czarny ekran. Po włączeniu debuger-a widzę że CPU poszedł w maliny i wisi na jakimś przypadkowym BRK pod adresem $FB0C. Może unarc wbudowany Altirra (2.90) źle rozpakował mi plik .com?

7

ARC dla Windows http://www.izarc.org/

plik c256 wrzucamy do ATR-a, w formacie SDX

Firmware -> Operating Systems -> XLOS (DracOS)
Attach Cartridge -> SDX447_sdx128.car

i działa :)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

8 Ostatnio edytowany przez seban (2017-08-03 16:12:54)

eeee... to potrzebna sparta i DracOS?

EDIT1: rozpakowałem linuksowym arc... wynik ten sam a więc potrzebne pewnie to co piszesz. sprawdzę.
EDIT2: no tak... ze spartą (4.48) + dracOS 2.37 zaczęło działać.

dzięki za wskazówki.

9 Ostatnio edytowany przez drac030 (2017-08-03 16:36:17)

No tak, program przełącza się w native mode od razu na samym początku. Żeby się nie sypnął, potrzebny jest OS z obsługą przerwań w trybie natywnym. Zapomniałem o tym napisać, bo mój komp ma taki konfig cały czas.

SDX nie jest potrzebna do uruchomienia tego, powinno pójść pod każdym loaderem i DOS-em.

EDIT: ale kiedy mamy już SDX, przesłanie pliku do Altirry jest prostsze.

System -> Devices -> Add -> Serial I/O bus devices -> PCLink *klik* -> OK *klik* -> Settings *klik*

Wybieramy podkatalog dla serwera PCLink. OK *klik* OK *klik*

Z dysku SDX Toolkit http://sdx.atari8.info/index.php?show=e … ad_special wyciągamy sterownik PCLINK.SYS i kopiujemy sobie na dysk, z którego bootujemy Altirrę. Wczytujemy sterownik z palca albo z CONFIG-a.

COPY PCL:FOO.BAR ściąga plik FOO.BAR znajdujący się w wyżej wybranym katalogu na dysk emulowanego Atari. Można też odpalić bezpośrednio.

KMK
? HEX$(6670358)

10 Ostatnio edytowany przez voy (2017-08-03 21:57:27)

Można też archiwum ARC przepakować programem ArcConvert na cokolwiek innego: https://sourceforge.net/projects/archiv … on%200.70/

Powszechnie wiadomo, że kamień potrafi myśleć. Na tym fakcie opiera się cała elektronika.

Terry Pratchett - Równoumagicznienie

11

[offtopic mode ON]:

jeżeli chodzi o dekompresję *.arc po stronie PC ,to pod *.nix jest oczywiście arc, np. w repozytorium dla debiana:

apt-get install arc

i mamy na pokładzie:

ARC - Archive utility, Version 5.21q, created on 06/27/2013
Usage: arc {amufdxerplvtc}[biswnoq][g<password>] <archive> [<filename> . . .]
Where:     a   = add files to archive
     m   = move files to archive
     u   = update files in archive
     f   = freshen files in archive
     d   = delete files from archive
     x,e = extract files from archive
     r   = run files from archive
     p   = copy files from archive to standard output
     l   = list files in archive
     v   = verbose listing of files in archive
     t   = test archive integrity
     c   = convert entry to new packing method
     b   = retain backup copy of archive
     i   = suppress image mode (translate EOL)
     s   = suppress compression (store only)
     w   = suppress warning messages
     n   = suppress notes and comments
     o   = overwrite existing files when extracting
     q   = squash instead of crunching
     g   = Encrypt/decrypt archive entry

Adapted from MSDOS by Howard Chu

ale również działa disk explorer z menu Tools w Altirra, obsługuje on także format ARC ;)

No i oczywiście wbudowany w SpartaDOS unarc ;-)

12

Adam Klobukowski napisał/a:

Przy pomocy movem da się chyba jeszcze szybciej, ale nie jestem w stanie policzyć.

Movem ma trochę pokręcone tryby adresowania. Zakładając normalne jego użycie, czyli dwa rejestry adresowe na adres skąd i dokąd oraz a7 dla stosu mamy:
    movem.l    (a0)+,d0-d7/a2-a6
    movem.l    d0-d7/a2-a6,(a1)
    lea    52(a1),a1
To nam daje 240 cykli na 13 4bajtowych słów, więc 4.62 cykla na bajt.
Programowo na 68k chyba się nie da tego szybciej zrobić.

13

Bardzo ciekawe wyliczenia, poproszę podobne dla wypełniania obszaru pamięci danym bajtem.

Ciekawie byłoby też uwzględnić blitter VBXE.

Czy jest instrukcja odwrotna do PEI (stos -> pamięć) ?

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

14

Takiej listy dla wszystkich możliwych kombinacji nie mam. Np. wypełnianie stałą wartością można zrobić przez pea $xxxx (również znane jako pea #$xxxx) po ustawieniu wskaźnika stosu na koniec wypełnianego obszaru. Rozkaz zajmuje 5 cykli, a zapisuje 2 bajty, więc mamy 2,5 cyklu na bajt.

Reszta raczej normalnie, czyli np. lda #$xxxx / sta $yyyy zajmie >=8 cykli (3 cykle lda, 5 cykli każde następne sta). Jeśli na adres danej strony ustawimy wskaźnik D, wtedy sta zajmie 1 cykl mniej. Itd.

Instrukcji odwrotnej do PEI nie ma, ale można w razie potrzeby zamienić miejscami wartości rejestrów D i S. Nie wiem jednak, czy zajdzie taka potrzeba, bo wskaźnikiem stosu można zaadresować 64k i wskaźnikiem strony zerowej tyleż.

KMK
? HEX$(6670358)

15

Czyli najszybsze wypełnianie 16-bitowym STA ZP 2 cykle/bajt? I chyba z taką samą prędkością 16-bitowe PHA?

PEI jak widzę ma 8-bitowy adres bez indeksowania. Dlatego zamiana D i S może się przydać.

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

16

Ad sta zp i pha - tak, takie zwykłe zapisy bez indeksowania zajmują w trybie 16-bit więcej o cykl potrzebny na zapis dodatkowego bajtu (kiedy adres strony zerowej jest wyrównany do granicy stron).

KMK
? HEX$(6670358)