Jaki loader jest najbardziej kompatybilny (z SD2IEC)?

[4fun]

na krzyż z nim na krzyż....

Bez przesady, jednak od ludzi wypowiadających się na tego typu forach należałoby oczekiwać merytoryki i uprzejmości.

[Zbych]

Dobrze że jestem wyrozumiały i się szybko nie obrażam.
Co do tematu to jednak wracam do koncepcji wywołania load z romu, gdzieś znalazłem jak wyłączyć wysyłanie komunikatów na ekran. Zastanawiam się tylko jak wywołać load - czy zapamiętać co było pod $0330 i potem tam wykonać skok  czy olać to i wywołać bezpośrednio $F4A5, oczywiście wcześniej zapamiętam gdzieś moje zmienne z ZP. Myślę tylko kiedy ten wektor pod 0330 może się z zmienić na coś innego (jak ktoś ma custom Rom)?
No i mam nadzieję  że nie ma tam więcej odwołań do pamięci $0200+, bo nie zauważyłem w tej procedurze, nie miałem czasu to przetestować.

[Skull]

skoro chcesz się bawić to popatrz tutaj:


Najpierw prześledzić od początku do końca w monitorze vice-a
http://codebase64.org/doku.php?id=base:loading_a_file

http://unusedino.de/ec64/technical/aay/c64/krnromma.htm
Jeśli chodzi o transmisję to wystarczy dobre przestudiowanie dwóch bloków od ed00 ef00 w kernalu.
 

[Raf]

Ja bym zmienil bank vica na e000-ffff i bankowal rom tylko na czas ladowania danych. Aczkolwiek uprzednio warto zobaczyc jak sie dane beda pakowaly/depakowaly np exomizerem. Natomiast fast-loader zgodny z sd2iec  to dreamload (ktorego sam uzywam).

[Zbych]

Ja bym zmienil bank vica na e000-ffff (cut..)

Nie bardzo widzę co by mi dała zmiana banku VICa na obszar $E000-$FFFF, a hasło "DreamLoader" już mi gdzieś mignęło na Wiki, ale linki nie działały, próbowałem znaleźć źródła w inny miejscu, ale jakoś mi nie wyszło, a potem zmieniłem koncepcję żeby skorzystać z kernala, może poszukam jeszcze raz.

Właśnie pierwsze co zrobiłem to sprawdziłem ile zajmuje level po spakowaniu Exomizerem. Przykładowy etap zajmuje 1800 bajtów po spakowaniu 274 więc jeśli będę miał wolny obszar od F000 to wystarczy na około 14 etapów... hmmm nie wiem jak to się stało ale chyba coś źle wcześniej wyliczyłem 14 to nie jet tak źle. Chyba wiem... podzieliłem hex 1000 na dec 274, chyba już byłem wtedy po piwie albo zmęczony. No i już mi pomogłeś
Ale awaryjnie muszę być przygotowany na użycie dyskietki może będzie jakiś hi score load/save.

(...)
Jeśli chodzi o transmisję to wystarczy dobre przestudiowanie dwóch bloków od ed00 ef00 w kernalu.

Już studiowałem. Kombinowałem różne opcje i coś niebardzo mi to działało (zazwyczaj wywołanie load kończyło się tym że przerwania z kernala się uruchamiały), chyba jednak umieszczenie danych w obszarze $200+ nie jest najlepszym pomysłem, ale tam to to się fajnie wpasowało bo procedura mnożąca z tablicami zajęła dokładnie obszar od $200 do $7F3.

Na razie jedyny pomysł jaki mi zadziałał to:
- przed głównym uruchomienim wykonuję kopię obszaru $01-$ff i $200-$400
- wyłączam kernal rozpakowuje dane gra startuje itd.
- przed załadowaniem z pliku przywracam wcześniej zapamiętane dane do w/w obszarów
- wyłączam IRQ
- włączam kernal
- wywołuję LOAD
- wyłączam kernal
- przywracam moje dane

Może jest jakiś łatwiejszy sposób bez konieczności marnowania pamięci na przechowywanie danych z tych obszarów?
Pomyślałem że można by było ewentualnie skompresować obszar $200-$400 i po prostu przed włączeniem kernala rozpakować, oczywiście dla ZP zostało by zwykłe kopiowanie.

Czy takie kopiowanie tych obszarów będzie kompatybilne z większością maszyn (czy to zadziała jak ktośbędzie miał np. Jiffy lub inny rom)?
Czy może jest łatwiejszy sposób, może wystarczy przywrócić wartości tylko dla kilku komórek (ale jakich)?

[Kisiel]

http://csdb.dk/release/?id=100645
na codebase64 też masz przykłady. Można robić w normalu tylko mało kto ma jiffy dos.

[Raf]

zrodla znalazlem tu https://sourceforge.net/p/rrtools/code/HEAD/tree/dload/
zmiana banku daje wiecej pamieci dla vica, bo w pierwszym banku masz obszar systemowy (zeropage, stos) i nie mozesz wysiwetlic grafiki z 1000-1fff bo tam jest mapowany systemowy rom, stad zmiana banku umozliwi lepsza organizacje pamieci dla vica, do tego jak wbankujesz rom to vic dalej czyta z ramu a ty mozesz ladowac dane procedurami systemowymi z romu.

kompatybilnoscia z innymi romami bym sie nie przejmowal, przynajmniej nie na tym etapie. I tak kazdy rozsadny uzytkownik alternatywnych kernali ma takze mozliwosc wlaczenia stockowego dla kompatybilnosci.

[Zbych]

zrodla znalazlem tu https://sourceforge.net/p/rrtools/code/HEAD/tree/dload/
zmiana banku daje wiecej pamieci dla vica, bo w pierwszym banku masz obszar systemowy (zeropage, stos) i nie mozesz wysiwetlic grafiki z 1000-1fff bo tam jest mapowany systemowy rom, stad zmiana banku umozliwi lepsza organizacje pamieci dla vica, do tego jak wbankujesz rom to vic dalej czyta z ramu a ty mozesz ladowac dane procedurami systemowymi z romu.
kompatybilnoscia z innymi romami bym sie nie przejmowal, przynajmniej nie na tym etapie. I tak kazdy rozsadny uzytkownik alternatywnych kernali ma takze mozliwosc wlaczenia stockowego dla kompatybilnosci.

Masz rację. Właśnie niedawno się przekonałem jak próbowałem wrzucić czcionkę w $1800, może udało by mi się tak ułożyć wszystko żeby nie brakło miejsca na obrazy sprajtów dla cienia, bo na razie mi się nie zmieściły. Ale zanim zrobię przemeblowanie muszę to sobie na spokojnie przkalkulować.
Nie chce mi się teraz przepisywać całej organizacji pamięci ale dla jako ciekawostkę podam że:
- tekstura tunelu zajmuje $9000-$CFFF
- kod renderujący $4000~$7600 z logiką  $4000~$8300
więc jest już trochę ciasno