Dlaczego C64 jest aż tak wolny?

[Cyprian]

Zrobiłem porównanie w asmie dekompresji plików LZ4 dla C64 (Vice 3., Apple IIe (AppleWin1.30.20.0) i Atari XL(Altirra). Poniżej czas dekompresji mierzony próbkami 44,1kHz:
- XL: 229 920 próbek;
- IIe: 275 744 próbek;
- C64: 299 808 próbek.

Wyszło mi że dekompresja na IIe zadziałała z prędkością 108,73% C64, a w drugą stronę C64 z prędkością 91,97% IIe.

[hobocti77x_]

Czyli potwierdziło się, że Apple II jest o ok. 8% szybsze niż C64.
A te testy były robione przy włączonym ekranie i włączonych przerwaniach?
Bo o ile w Apple II nie ma to żadnego wpływu na szybkość, to już w C64, a zwłaszcza Atari, ma ogromny.

Prędkość można też porównać z innej strony. W systemie PAL i NTSC czas jednej linii ekranu jest taki sam i wynosi 64 µs, co prawda dopuszcza się niewielkie odchyłki, o ile pamiętam, to dopuszczalna odchyłka wynosi 8%.
I tak wyświetlenie jednej linii ekranu w C64 (PAL) trwa 63 cykle CPU, w Apple II (PAL/NTSC) 65 cykli, Atari aż 114 cykli.
Wynikałoby z tego, że Atari powinno być ok. 80% szybsze, ale tak nie jest z powodu ANTIC-a.

[Cyprian]

A te testy były robione przy włączonym ekranie i włączonych przerwaniach?

Ekran włączony, hires na wszystkich kompach, przerwania zablokowane instrukcją "SEI"

I tak wyświetlenie jednej linii ekranu w C64 (PAL) trwa 63 cykle CPU, w Apple II (PAL/NTSC) 65 cykli, Atari aż 114 cykli.
Wynikałoby z tego, że Atari powinno być ok. 80% szybsze, ale tak nie jest z powodu ANTIC-a.

na Atari cykle procesora podkradane są przez ekran ale też odświeżanie pamięci - 9 cykli na każdą linię.
Z właczonym ekranem hires A8 uzyskało 132,54% wydajności konkurenta a C64 75,45% konkurenta. Z wyłączonym ekranem A8 miało 164,6% mocy C64.

kod źródłowy powinien być w ZIPie w wątku który zapodałem wcześniej.

[Cyprian]

Zrobiłem porównanie w asmie dekompresji plików LZ4 dla C64 (Vice 3., Apple IIe (AppleWin1.30.20.0) i Atari XL(Altirra). Poniżej czas dekompresji mierzony próbkami 44,1kHz:
- XL: 229 920 próbek;
- IIe: 275 744 próbek;
- C64: 299 808 próbek.

Wyszło mi że dekompresja na IIe zadziałała z prędkością 108,73% C64, a w drugą stronę C64 z prędkością 91,97% IIe.

I jeszcze wynik z Atari Lynx: 92 320 próbek
Tu porównanie w stosunku do Lynx:
Lynx 100,0%
XL 40,2%
IIe 33,5%
C64 30,8%

[hobocti77x_]

Hmm, porównywanie komputerów z lat 70. i początku 80. z konsolą z 1990?
No to jeśli już, to powinno się uwzględnić w przypadku Apple II różne akceleratory, które były dostępne i to nie tylko jako ciekawostki. Zresztą w połowie lat 80. był dostępny np. ZipChip i to nawet od kilku producentów, który oprócz procesora 65C02 z zegarem do 10 MHz posiadał także do 8 kB pamięci CACHE, a jego częstotliwość można było zmieniać programowo.
Był także Apple IIc Plus z takim procesorem z zegarem przelacznym miedzy 1 i 4 MHz w formie komputera czy samego PCB do modernizacji, a także Apple IIGS z procesorem 65816, który także był dostępny jako samo PCB do modernizacji Apple IIe.
Ale to chyba wybiegamy za daleko

A wracając do testów rozkazu SEI w przypadku Atari, jak i C64, pozbawia dostępu do klawiatury, ale także zakłóca timery, co właściwie eliminowało te komputery z wielu zastosowań komputerów do pracy.
W każdym razie napisałem aplikację dla VIC sprawdzającą, ile cykli zabiera C64 obsługa przerwań i wyszło, że w ciągu 1 sek.
Dodatkowa strata to 14054 cykle i to bez rozpoznawania wcisnietego klawisza co z pewnoscia podkrada dodatkowe cykle.

[Cyprian]

Spokojnie, to tylko test wydajności procesor/pamięć (stąd SEI), a nie konkurs piękności sprzętu.

Mam jeszcze na celowniku C= Plus/4, C128, BBC Micro, /|\ 7800, 65816 również. Korci mnie jeszcze SNES.
Co do Lynx to jest on z 1987 roku.

[hobocti77x_]

Hmm, procedura testowa:
ATARI:

Kod: Zaznacz cały

.macro BeepON
	lda	#$1F
	sta	$D201		// Pokey AUDC1 volume
.endm

.macro BeepOFF
	lda	#$10
	sta	$D201		// Pokey AUDC1 volume
.endm

I niby to samo c64:

Kod: Zaznacz cały

.macro BeepON() {
	lda	#$0F
	sta	$D418 		// SID filter / volume
}

.macro BeepOFF() {
	lda #$FF
	sta $D406
	sta $D406+7
	sta $D406+14
	lda #$49
	sta $D404
	sta $D404+17
	sta $D404+14

	lda	#$00
	sta	$D418 		// SID filter / volume
}

Od razu widac ze ta dla Atari wykona sie kilka razy szybciej niz dla c64 nawet na przy takim samym taktowaniu CPU.

[Cyprian]

BeepON wykonywane jest tylko raz na początku a BeepOFF tylko raz na końcu testu.
Po między nimi jest jest kod LZ4 który trwa ~6,5 sekundy. To jest ~6 000 000 cykli procesora. Myślę więc że te dodatkowe ~30 cykli w BeepOFF nie za bardzo zmienią wynik.

[Cyprian]

wygląda to tak:

Kod: Zaznacz cały

	BeepON()


//Main loop
Main_Loop:
//LZ4 init
		lda	#<LZ4_DataA8		// LZ4 Source Start
		sta	LZ4_SRC
		lda	#>LZ4_DataA8
		sta	LZ4_SRC+1

		lda	#<LZ4_Data_EndA8	// LZ4 Source End
		sta	LZ4_END
		lda	#>LZ4_Data_EndA8
		sta	LZ4_END+1

		lda	#<ScreenData		// Destination
		sta	LZ4_DST
		lda	#>ScreenData
		sta	LZ4_DST+1


//LZ4 go
		jsr	lz4_decode


		dec	Licznik
		beq	Neverending_Loop


//LZ4 init
		lda	#<LZ4_Data
		sta	LZ4_SRC
		lda	#>LZ4_Data
		sta	LZ4_SRC+1

		lda	#<LZ4_Data_End
		sta	LZ4_END
		lda	#>LZ4_Data_End
		sta	LZ4_END+1

		lda	#<ScreenData
		sta	LZ4_DST
		lda	#>ScreenData
		sta	LZ4_DST+1


//LZ4 go
		jsr	lz4_decode


		dec	Licznik
		beq	Main_Loop_End


	jmp	Main_Loop
Main_Loop_End:


	BeepOFF()


Neverending_Loop:
		nop
	jmp Neverending_Loop  
	 

[hobocti77x_]

Zrobiłem mały test na symulatorze 65816, nad którym od jakiegoś czasu pracuję. Działa on na STM32, dla 65816 jest dostępne 512 kB RAM.
W tej chwili dostępne są dwa porty SERIAL. Prędkość szacuję na 5-6 MHz. W tej chwili nie uruchomiłem jeszcze pamieci CACHE, więc prędkość pewnie uda się zwiększyć.
Emulowane są wszystkie znane anomalie i błędy 65816.
Działa BCD.
Test na załączonym pliku.

Record_2025_01_18_16_45_37_736.zip

(260.38 KiB) Pobrany 734 razy

[Cyprian]

ciekawe,
da radę włożyć to w płytę główną zamiast 6510/6502?

[hobocti77x_]

Jak na dzień dzisiejszy, to raczej nie planuję zrobienia z tego układu zastępującego procesor.

Rozważałem taką ewentualność, ale ma ona sporo wad.
Po pierwsze, trzeba otwierać komputer, a to już zmniejsza ilość ewentualnych użytkowników.
Po drugie, mimo wszystko ograniczyłoby szybkość wykonywania kodu do częstotliwości magistrali, jedyny zysk byłby taki, że rozkazy miałyby mniejszą liczbę cykli.
W końcu, aby zastąpić procesor, musiałbym dodać dokładną emulację, jeśli chodzi o cykle 6510/6502.

Raczej myślę o czymś w rodzaju akceleracji z dostępem do RAM dawcy w trybie DMA, ale to za jakiś czas.

W każdym razie, tak jak jest, może współpracować z każdym komputerem posiadającym 1 port szeregowy i program typu terminal.
W tej chwili układ obsługuje 2 porty szeregowe, z tym że jeden służy do wprowadzania danych i obsługi terminala.
Drugi jest w zasadzie wolny dla użytkownika, o ile nie jest używany wbudowany debugger dla 65816, choć był on pomyślany jako tymczasowy i możliwe, że go usunę.
Jest jeszcze kilka portów 8- i 16-bitowych, ale część chcę pozostawić, aby programy mogły je wykorzystać do swoich celów.
W sumie mam już nieco zaawansowaną symulację 8080 i chcę wprowadzić możliwość stosowania kodu 6502, 8080 oraz ARM w przydzielonych obszarach RAM.

Raczej ma to być taka lekko niezależna od emulacji platforma dla kogoś, kto chciałby zapoznać się z różnymi procesorami.
W tej chwili w zasadzie układ działa jak emulator https://sbc.rictor.org/kowalski.html i można pod nim programować i testować gotowe obrazy do uruchomienia na tym układzie.
Z programow jakie dzialaja to monitor 65816 oraz EhBASIC.
Uklad dziala na STM32h750vbt6 pCB jak tu
https://www.aliexpress.com/item/1005002 ... 32h750vbt6

[KB777reborn]

ciekawe,
da radę włożyć to w płytę główną zamiast 6510/6502?

-> MCL64, które zresztą YTM nieźle rozbudował: https://www.c64scene.pl/viewtopic.php?t=3673

[Cyprian]

ciekawe,
da radę włożyć to w płytę główną zamiast 6510/6502?

-> MCL64, które zresztą YTM nieźle rozbudował: https://www.c64scene.pl/viewtopic.php?t=3673

fajny temat

[hobocti77x_]

'takie rozwiazanie jak MCL64 ma powazna wade.
W pewnym momencie osiagnie sie punkt od ktorego nie da sie kuz zwiekszac szybkosci.
Aby zachowac zgodnosc w c64 kazdy zapis musi byc jenoczesnie wykonany do pamieci buforowej jak i RAM c64.
Innymi slowy jesli dojdzie do zapisu a taki mozna wykonac raz na cykl to emulator musi czekac na wolny cykl dostepu do RAM a w przypadku c64 moze to trwac nawet 40 cykli zegara 1Mhz
Jesli w kolejce beda dwa rozkazy z zapisem do RAM to na wykonanie beda potrzebowac 2 cykle magistrali a to znacznie zmniejsza wydajnosc.

[hobocti77x_]

Zrobilem dokladny test LZ4 z pomoca oscyloskopu cyfrowego ustawiajac 0 na wyjsciu przed startem i 1 po zakonczeniu testu emulatora 65816.

Cala test wykonal sie w 464.1 ms czyli ze 44100Hz*0.464s daje ok. 20462 cykle

[ytm]

'takie rozwiazanie jak MCL64 ma powazna wade.
W pewnym momencie osiagnie sie punkt od ktorego nie da sie kuz zwiekszac szybkosci.
Aby zachowac zgodnosc w c64 kazdy zapis musi byc jenoczesnie wykonany do pamieci buforowej jak i RAM c64.
Innymi slowy jesli dojdzie do zapisu a taki mozna wykonac raz na cykl to emulator musi czekac na wolny cykl dostepu do RAM a w przypadku c64 moze to trwac nawet 40 cykli zegara 1Mhz
Jesli w kolejce beda dwa rozkazy z zapisem do RAM to na wykonanie beda potrzebowac 2 cykle magistrali a to znacznie zmniejsza wydajnosc.

Dopuszczając w MCL64 przyspieszenie procesora tracimy 100% zgodność z C64 i można się pobawić w podział na "slow" (I/O i pamięć którą czyta VIC: zapis odbywa się do RAM teensy i do RAM c64) i "fast" (zapis tylko do RAM teensy).

SuperCPU miało kilka opcji synchronizacji takiej szybkiej pamięci (tej dla CPU) z wolną (tą dla VIC):

Kod: Zaznacz cały

Location        Note    Purpose
$D074  (53364)  (1)     GEOS Optimization (mirror VIC Bank 02, $8000-$BFFF)
$D075  (53365)  (1)     VIC Bank 01 Optimization (mirror $4000-$7FFF)
$D076  (53366)  (1)     BASIC Optimization (mirror $0400-$07FF)
$D077  (53367)  (1)     No Optimization (default; mirror all memory)

Najszybsza opcja dla MCL64 to przepuszczanie do C64 tylko odczytów/zapisów z I/O - wtedy zamiast C64 dostajemy coś w rodzaju terminala opartego na Teensy+VIC+CIA.

ytm

[Cyprian]

Zrobilem dokladny test LZ4 z pomoca oscyloskopu cyfrowego ustawiajac 0 na wyjsciu przed startem i 1 po zakonczeniu testu emulatora 65816.

Cala test wykonal sie w 464.1 ms czyli ze 44100Hz*0.464s daje ok. 20462 cykle

moim programem?
jeśli tak to piękny wynik

[hobocti77x_]

Tak test zrobilem twoim programem , dokladnie dostosowalem wersje dla ATARI doadjac jedynie ustawienie na starcie I/o na 0 i po wykonaniu programu na 1.
Do pomiaru czasu wykozystalem analizator logiczny probkujacy z czestotliwoscia 24MHz tak ze pomiary sa b. dokladne.
Tak wyglada wynik pomiaru


Zaczelem pisac symulacje 6502 i juz na wstepie widze ze powinienem uzyskac co najmniej 2-3 razy szybszy kod.
W koncu emulacja 6502 jest znacznie mniej skomplikowana niz 65816

Na kolejnym zdjeciu jest wynik prostego kodu

Kod: Zaznacz cały

LOOP:
	LDA #$55
	STA PORT
	LDA #$AA
	STA PORT
	JMP LOOP

Logic 2 [Logic - Connected] [Session 0] 24_01_2025 15_25_49.png (59.33 KiB) Przejrzano 8387 razy