Wyłączenie BASIC ROM

[BagoZonde]

Witam, potrzebuję trochę wolnego miejsca w pamięci C64 i mam wielką chrapkę na BASIC ROM, który znajduje się w $A000 - $BFFF. To całe 8kb!

Wpisałem więc sobie testowy program:

BASIC ROM wyłączam po prostu dzięki załadowaniu #$36 pod $01.
Następnie w pętli wykonuję INY i wrzucam do $A000+Y modyfikując tym samym pierwsze 255 wartości.

Działa to świetnie, ale jednej rzeczy nie rozumiem: naciskając RUN/STOP + RESTORE wracam do BASICa. Czyżby ta kombinacja klawiszy przywracała BASIC a może tak naprawdę wcale go nie wyłączyłem a zamroziłem ? No ewidentnie wartość pod $01 wynosi #$34 dla włączonego. Jeżeli tak to działa - po takim powrocie do BASICa dane pod $A000+ cały czas są zachowane. Rewelacja. Sprawdzając pod $B000+ już niestety wartości te są różne zaraz po powrocie do BASICa ale to nie szkodzi. Czyżby dla adresów od $A000 do ... (no właśnie muszę to sprawdzić) - nie trzeba było ich nawet na przykład - gdybym pokusił się o utworzenie jakiejś tablicy w tym obszarze - wczytywać ponownie przy kolejnym uruchomieniu programu? W każdym bądź razie nawet jeżeli przy każdym uruchomieniu programu musiałbym te dane wczytywać z dyskietki i ładować pod $A000 - $BFFF to i tak baaajka. Zbyt piękne, żeby to było prawdziwe stąd pytam. Dodatkowe 8kb śni mi się po nocach i uratowałoby technicznie mój projekt .

No i jeszcze jedno: czy wyłączanie BASIC ROM jest w sumie bezpieczne? Nie ma możliwości, że coś jakimś cudem korzysta lub jest zależne od tego?

Dzięki za odpowiedź .

[Kisiel]

jak sam zauważyłeś jest możliwe wyłączenie/włączenie rom basica, zyskuje się tym samym trochę więcej pamięci ram widocznej dla CPU. Żeby zapisać do ramu pod basicem nie musisz wyłączać rom. Wyłączanie basica jest bezpieczne jak go nie używasz, tak jak nie można zjeść cukierek i mieć cukierek.
Dla zakumania jak działa run stop + restore http://unusedino.de/ec64/technical/aay/c64/rome37b.htm

szczególnie part jmp ($0300)

[V-12/Tropyx]

W C64 manipulacja pamięcią odbywa się na zasadzie przełączania banków lub bloków (zależy jak kto woli na to mówić). Jak chcesz mieć jeszcze więcej pamięci na kod, to wyłącz Kernala. Wyłączenie BASIC ROM jest jak najbardziej bezpieczne pod warunkiem, że nie czynisz tego z poziomu Basic'a.

Run/Stop+Restore to ciepły start, ustawia na początek najważniejsze rejestry, w tym i $01 i wektory przerwań no i wskakuje do Basic'a, bo przecież z jego poziomu uruchamiasz cokolwiek na C64.

Jeżeli załadujesz dane pod $A000-$C000 to one powinny siedzieć w pamięci nieuszkodzone, jak będziesz wykonywał swój program w Assemblerze. Sam to czynię często .

[Skull]

Tak jak opisali przedmówcy - komórka $01 służy do konfiguracji pamięci, albo inaczej sposobu "widzenia" jej przez procesor. Teoretycznie w c64 jest aż 64k(ram)+16k(basic, a nie 8+16k(kernal)+8k(genrator znaków)+8k(rejestery i pamięć kolorów) - razem daje to aż 112kB(!) różnych komórek pamięci, z tym że spora część nadaje się tylko do odczytu (rom). Ponieważ magistrala adresowa ma długość słowa 16 bitów (od $0000-$ffff), wiadomo że nie miałaby szans dostępu do całego 112k (16bit to max 65536 kombinacji, czyli 64kB) dlatetgo też istnieje taki dodatkowy przyłącznik w komórce $01.

[V-12/Tropyx]

Gwoli sprostowania: generator znaków ROM ma 4KB, interpreter Basic'a 8 KB, Kernal również 8KB i żeby to wszystko zaadresować, potrzeba by było 88KB pamięci, stąd bankowanie.

[BagoZonde]

@Kisiel + everyone ;P
No dzięki za odpowiedź, poczytam więcej o tym warm resecie . W projekcie, który realizuję, przesuwam ekran do $C000, i gdy zdefiniowałem wszystkie tablice, etc. okazało się, że zrobiło się naprawdę ciasno. No i mam właśnie muzykę pod $8000 i myślałem, żeby ją wrzucić do tego $A000 zyskując więcej miejsca na dane pod $8000. I tak zrobię! Dzięki! Co do rozpiski działania Warma: bezcenne

@V-12/Tropyx
Co do Kernal ROMu ($E000 - $FFFF czyli kolejny łakomy kąsek 8kb) to jest to już grubsza brocha, z tego co czytałem, jak na mój skill odpuszczę sobie bo do projektu mi już wystarczyć powinno tej pamięci, ale na pewno warto byłoby się pokusić .

@Skull
BASIC ROM i KERNAL ROM mają po 8kb każdy z tego co wyliczyłem na rasowym kalkulatorze . No i jeszcze jak się nie korzysta ze sprite'ów, to też można w sumie wykorzystać te miejsce na jakieś tablice czy podprogram.

[Kisiel]

$a000 - $bfff i E000-ffff , czyli łącznie mieści się to w 16KB pamięci i tyleż samo mam na DOS i obsługę Fat16 jako nakładkę(podkładkę?) pod (nad?) kernal i basic.
Skleroza Skull ;P

[Skull]

macie rację podwoiłem romy - ech człowiek sobie zrobi urlop i już wypada z obiegu

[Raf]

a i tak nikt jeszcze nie wspomnial o pamici kolorow ;P

[Skull]

ja wspominałem

[Raf]

a sorry faktycznie.

[V-12/Tropyx]

@BagoZonde: wstaw sobie #$34 do $01 i masz niemalże całą pamięć na kod maszynowy jakby co mogę pomóc w kodzie jak masz problemy

[BagoZonde]

Dzięki! Te 8kb w BASIC ROM ratuje projekt, rozpisałem wszystkie rzeczy na dostępną pamięć i właśnie te 8kb to nawet za dużo .

V-12/Tropyx
Teraz będę zgłębiał tajniki rasterlinii, bo chciałbym wyświetlać sobie na ekranie po trzy "sety" sprite'ów w trzech rzędach na zmianę - do walk turowych . Każdy ze sprite'ów składa się z multicolor+hires więc w jednym rzędzie chcę 3*2 sprite'ów (3-ech ziomali w rzędzie) a potem chcę je switchować, żeby razem na ekranie wszyscy "siedzieli". Już sobie zbudowałem rastra ale jedna rzecz mnie trapi: nie zawsze jestem w stanie złapać odpowiednią linię - czasem ją przeskoczy w rysowaniu strony co jest oczywiste, bo zanim pobierze i porówna rastra - może już być o jedną linijkę (lub więcej) dalej i mam mignięcie (nie sprawdzałem na sprite'ach a na kolorze tła). Pasowałoby mi coś na wzór: jeżeli np: większa rasterlinia od 20, jeżeli większa od 50 i jeżeli większa od 80 to żeby raz mi przełączyło te sprite'y. Próbowałem z porównaniem BCS ale coś nie wychodzi, mimo tego, że wrzucałem do $D011 "górę". Już coś próbowałem i średnio to wyszło, znalazłem też kod ze stabilną rasterlinią, ale muszę go rozpracować. Temat jest ciekawy . Obczaję to zapewne w wolnym czasie, którego nie miałem w ogóle i bawiłem się rastrami po łebkach bez wnikania dogłębnego w zasadę działania :/.

Mi to by się przydały jakieś tutoriale do zapisu danych po trackach, i wynajęcie kogoś, kto umiałby zabezpieczyć grę przed lamerskimi crackerami . Choć z drugiej strony nie wiem czy jest sens zabezpieczać - jak ktoś złamie to nie napiszę już więcej nic .

[V-12/Tropyx]

Multplexer sprajtów najlepiej kodzić na zasadzie przerwania w przerwaniu, kolejne przerwanie zaczynasz bodajże 2 linie rastra przed tą linią, w której wyświetlasz następną warstwę sprajtów.

Nie musisz się męczyć z zapisywaniem danych po trakach, zapisz normalnie pliki, a potem usuń tytuły z dir'a (np. dir masterem) - pliki fizycznie dalej będą na dysku, ale dostęp do nich będziesz miał tylko poprzez wczytywanie po trakach. W dir masterze podejrzysz sobie także tracka i sektora poszczególnych plików.

Co do zabezpieczeń, to jeżeli zamierzasz grę wydać komercyjnie, to zawsze można coś pomyśleć. Ale w dzisiejszych czasach to raczej zbędne, chociaż dla klimatu czemu by nie. Z chęcią bym nabył jakąś nową grę na C64 w ładnym opakowaniu i jeszcze zrobioną w Polsce Współcześnie cracking mija się z celem, nie raz rozbawiali mnie pseudocrackerzy, którzy wydawali niezabezpieczone gry jako cracki, nawet 11 lat temu taki sam los spotkał moją grę imho prawdziwy cracking na C64 skończył się wraz załamaniem rynku gier na Komodę w latach 90.

[Skull]

@Bago masz problem z badlines (co ósma linia w obszarze grafiki). Na temat przerwań napisałem obszerny artykuł w ostatnim c&a fan - poczytaj.

ps. Twój język opisowy mnie rozbraja.