c64scene.pl

Właśnie dotarło do mnie, że decrunch w stacji jest niemożliwy - o ile idea crunchingu jest prosta a idea decrunchingu wręcz prostacka - o tyle jeżeli pojawi się rozkaz np. skopiuj 1500 bajtów - niet problema - te dane są z PRZODU - pojawi się rozkaz zdecrunchuj 3 bajty o ofsecie (WSTECZNYM) 20000 ups... dupa - jak tu odszukać sekwencję 20kb wstecz...

wegi pisze:Zielok zna wszystkie języki programowania by Ci zrobił...

Packer mogę przerobić jeśli jest zainteresowanie. A w zasadzie już go przerobiłem. Wacek wysłać Ci?

Droga przez mękę z hexedytami i cudami na kiju... Mogłeś makro w excelu walnąć do obcinania czy podmiany pierwszych 2ch bajtów też.

Uaaa - zielok sie pakerami zainteresował - przyznasz, że LZWVL ma wyjechaną dynamikę

AAA zielok - jak widzisz temat overlapu poza $ffff i ładowania pod IO?

@wacek - pytasz w czym rzesz z tym ładowaniem pod IO otóż to dec$01 i INC$01 (dodaje każdorazowo 10 cykli na zapis każdego odczytanego bajtu z driva) jest w krytycznym czasowo punkcie mającym dyży wpływ na czas ładowania - dlatego pod względem czasowości warto mieć 2 procedury w zanadrzu co z kolei wydłuży kod loadera - więc trzeba mieć na względzie, że są kompromisy - albo długość kodu albo czas itp...

Łaaaaa Zielok rządzisz

Spróbuj przesłać przez forum a jak nie pójdzie to wal na maila (gdzieś powinieneś mieć w inboxie

).

@Wacek

Poszło na email

@Wegi
Nie przygladałem sie temu packerowi więc ciężko mi cokolwiek stwierdzić.
Overlap dla mnie zbyteczny (nie widzę zastosowania ale takze nie analizowałem tego jakos specjalnie), a IO bardzo wskazane. Ja często potrzebowałem ładować pod rom bo tylko tam wolne miejsce było i godziłem się na to, ze bedzie to troche wolniejsze.

@zielok - pytanie brzmi:

Czy loader ma mieć 1prockę zawsze wolniejszą

...
dec $01
sta ($xx),y
inc $01
...

Czy okupione długością kodu loadera drugą bez inc i dec dla plików nienachodzących pod I/O - chodzi mi o coś co po prostu jest wypracowane przez praktyków i wiadome są wynikające z użytych rozwiązań kompromisy - jak byś wolał?

Ja uważam że load powinien być zrobiony tak, żeby przy skoku do load można to było włączać/wyłączać. Zrobiłbym tam jakiś warunkowy skok przed

wackee pisze:Najpierw przeczytałem to co Ty napisałeś, a po stwierdzeniu że jednak nie wyjaśniłeś Wegiemu o co chodzi, sam napisałem wyjaśnienie.

Dobra, ale Ty nie piszesz pod wplywem alkoholu.

wegi pisze:@zielok - pytanie brzmi:

Czy loader ma mieć 1prockę zawsze wolniejszą

To zalezy o ile większy kod loadera będzie. Jesli to będzie duża ilość bajtów to wolę jedna a wolniejszą.

wackee pisze:Ja uważam że load powinien być zrobiony tak, żeby przy skoku do load można to było włączać/wyłączać. Zrobiłbym tam jakiś warunkowy skok przed

Dobra skończę crunchera - trza pokumać nad konstrukcją loadera. Sprawdzenie zajmie niewiele mniej, osobna pętla raczej konieczna.

Cały ten ringbuffering ja bym przyrównał do tego co wydumałem ringbufora przesuwanego i zmiennej długości danych ze ścieżki gdzie symbolicznym ringiem jest ścieżka dysku akurat hihi

To byłby cruncher - oceńcie czy za dużo tam udziwnień, czy za mało.

Mile widziane pomysły na skrócenie kodu decrunchera i jego przyspieszenie

chyba 350 KB nie przyjmie forum to macie linka do bongo crunchera

nasmarkałem tam hintów, automatyzację dla linii komend mam nadzieję, że się połapiecie

Sie nakombinowałem - trzeba zmienić rozszerzenie na 7z ten plik jest spakowany 7zipem - akurat ma mniej jak 256KB

wackee pisze:Łaaaaa Zielok rządzisz
Spróbuj przesłać przez forum a jak nie pójdzie to wal na maila (gdzieś powinieneś mieć w inboxie ).

Kod: Zaznacz cały

		;-----------------
		ldy #0
		ldx #$30
		lda (lzwvl_get),y
		pha
		iny
		lda (lzwvl_get),y
		sta lzwvl_put
		iny
		lda (lzwvl_get),y
		sta lzwvl_put+1
		lda lzwvl_get
		clc
		adc #2
		sta lzwvl_get
		bcc *+4
		inc lzwvl_get+1		
		;negative : long mode (bmi, $30)
		;positive : short mode (bcc, $90)
		pla
		bmi *+4
		ldx #$90
		stx delzwvl_short_or_long
		and #$7f
		tax
		dex
		dex
		txa
		bpl delzwvl_start2
		;----------------

Możesz pakować z load adresem... takim jaki ma być depack adres to jest zmieniony entrypoint do decrunchera LZWVL na taką okoliczność. Rozumiem, że do opcji w bongo cruncherze uwag nie ma

zobaczylem jakas chwile temu na csdb. pyszne!

Poprzedni przykład ze zmienionym entrypointem dla LZWVL jest do dupy - nie używać

Zobaczcie sobie część sampli do bongo linking engine. Loader jest zgodny z wish listą Wacka:

$D011 - nieistotne co jest
PAL/NTSC - działa
$DD00 - możliwa zmiana banków podczas pracy loadera pod warunkiem zapisu do $DD00 gdzie 6 najstarszych bitów jest wyzerowane
sprajty - nieistotne ile ich jest i gdzie
IRQ/NMI - w dowolnym momencie może przerywać pracę loadera
badlinesy - nieistotne

(przy otwieraniu borderów również loader nie wniesie opóźnień czy jakichś "szumów")

Wsparcie dla:

- bongo cruncher (with/without golden seq)
- Doynax
- LZWVL
- Boozer
- EXO
- Level Crusher

Są to 4 rdzenie loaderów
- 1 krótki streamowy optymalnie czytający z przeplotem 8 (z fly decrunch $0a i większe w zależności od danych i rastra wyznaczonego dla niego)
- 2 szybszy ciut streamowy czytający optymalnie z przeplotem 6 + 2 dla decrunchera uwagi j.w.
- 3 nointerleave loader - ten nie jest uzależniony od przeplotu - sam się "wpasowuje" do tego co "przylatuje"
- 4 deterministyczny - działa na D64 robionych przez trackmolinkera - dzięki niemu z góry zna kolejność zapisywanych sektorów co daje mu fast file system bez zmiany kompatybilności plików z filesystem 1541

Te 4 rdzenie w sumie ze wsparciem dla cruncherów to osobne 28 loaderów zintegrowanych z decruncherem plus 4 "gołe" loadery bez decrunchera

Podczas pracy istnieje możliwość wymiany każdego z loaderów na dowolny inny w zależności od potrzeb można nawet wymieniać na inne decrunchery np jeden plik mieć spakowany exo inny level crusherem (raczej mało praktyczne ale możliwe)

Dodatkowe funkcje dla loaderów:

- exchange loader - to co powyżej
- 2 warianty change disk engine jeden bazujący na write protect drugi obywający się bez wrp. (moje drivy mają zjaraną fotodiodę

)
- find_by_filename (mało przydatne może dla "konserwatystów")
- get_start_tracks_and_sectors - jeżeli dyskietka nie jest składana jako trackmo tworzy tabelę start track i sectorów zapisanych plików (prg domyślnie - można zmienić w kodzie) - nie dla deterministycznego loadera
- get_silent_dir - pobranie danych o plikach zapisanych na 18,2 (działa z każdym loaderem - d64 musi być kreowane przez trackmolinkera bez opcji -dirent czyli trackmo disk) ograniczenie do 50 plików

Należy zmienić rozszerzenie na 7z - pozdro

Fajne demka, obejrzalem wszystkie.

Dzianx za fidbaka mam nadzieję, że wszystko w nich zrozumiałe i w tym co pisałem

edit:

Ale zauważyłeś jaką dynamikę ma Doynax jaka perełka

Ciekawe statystyki.

@zielok - jest prośba - zrobiłem wersję bongo crunchera jako APPCONSOLE bez GUI - To jest praktycznie czysty pascal - 44 procedury (w tym ze 2 funkcje) i żadne jakieś wymyślne czy skomplikowane - dałbyś radę skonwertować to do C?

@Wegi

Daj kod (zielok na gmail.com), spróbuje. Ostatnio kod w Pascalu widziałem jeszcze w 20 wieku.

Dzięki zielok - mam nadzieję, że nie będzie problemów

http://csdb.dk/release/index.php?id=117165

pół roku roboty

zapomniałem dodać, loader ładuje pod I/O

pozdr

c64scene.pl

Linking machine