Dzięki! Myślałem, że do local nie da się patrzeć z zewnątrz, ale się da :)

;-------------------
.local  ,$A000
        org $A000
BANK1   rts
        org $BFFF
        dta $FF
.endl
;-------------------
.local  ,$A000
        org $A000
BANK2   rts
        org $BFFF
        dta $FF
.endl
;-------------------

i ładnie się banki 8kB robią.

XEX2WAV https://github.com/GienekP/xex2wav
Loader do mona, jednorekordowy, zatrzymuje silnik po INIT a sam xex2wav wydłuża przerwę.

za jednym poleceniem zrobisz wava na całą stronę kasety

xex2wav gra1.xex gra2.xex gra3.xex gra4.xex zestaw.wav

Po wygenerowaniu wava warto sprawdzić w Altirra czy xexy w ogóle chcą z taśmą gadać.

Ok, tak żeby zostało. Pozbierałem moje XEX2CAS w jedno miejsce:
https://github.com/GienekP/xex2cas
v1.0 - to ten pierwszy zrobiony "sto lat" temu
v1.1 - v1.0 przepisany do C
v1.2 - tutaj zamiast wykrzynika jest loader od mona, jednoblokowy, no ja dodałem od siebie trik z bardzo krótkimi przerwami
v1.3 - to jest wersja 1.1 ale ma poprawiony "Wykrzyknik". Ten loader jak wszyscy wiedzą działa przypadkowo na XL/XE. Zdebugowałem, go, koledzy pomogli i wyszła wersja taka jaką autor miał na myśli. Dla eksperymentu można włączyć wczytywanie z BASICem. Wyskoczy ładny komunikat, że mamy carta w slocie, czego nie zobaczymy na oryginalnym wykrzykniku.

800 bodów ($0320). Mój magnetofon wyrabia na 900. No więc wziąłem 1 blokowy loader xexów od mona. Dokleiłem drugi blok gdzie jest procedura przenosząca ROM do RAM i która zmienia timingi. No i na koniec doklejony jest sam XEX.

Jeszcze nie miałem czasu sprawdzić na realnej taśmie, ale jak zadziała to puszczę małego toolsa dla tych co chcą maksa wyciągnąć z normala.

Dzięki @mono
w sumie to trochę upraszcza sprawę zakresu $D5XX. Bo w tym zakresie cartridge ma totalny priorytet i w zasadzie nie ma się co przejmować tym co jest pod spodem.

Może chodzi o to, że co prawda strona D5 zakrywa RAM, ale dla emulatora to to kopiowanie to nie jest "kopia do RAM". Tylko kopia dla kodu emulacji procka, który idzie z MEMORY_mem. No nie czaję tego...

Nie to jest coś pokręcone. To raczej wygląda jakby obsługa D5 w ogóle nie była zrobiona. Bo to, że akurat D5 się wykorzystuje do pstrykania bankami to nie jest ważne. Równie dobrze można by cały zakres A000-BFFF zrobić rejestrami a banki mieć na D5xx. CCTL to jest taki sam pin na złączu carta jak S4 czy S5.

Jak było samo "GetByte" to D(isassembly) pokazywało kod poprawnie ale procek leciał na manowce.
Jak dodałem MEMORY_CopyFromCart to ruszył mi zarówno tester jak i inny programik co robię, który to na rzeczywistym sprzęcie też działa.
Nie mam za bardzo porównania, bo w sumie to nie spotkałem się z kombinacją, że procek wykonuje kod na stronie D5xx. A przecież nie ma ku temu żadnych przeszkód.

Ale z breakpointami to dziwna sprawa bo "b" nie działa natomiast jak dam:

bpc $D500

to wyświetla:

Breakpoint is at PC=D000

Jakie D0? Coś tu jest więcej zakręcone...

@xxl

Jak już jesteś na linii to mam kilka pytań związanych z xBIOSem. Nie znam go a interesuje mnie sprawa obsługi cartridgeów.
1. Czy xBIOS umiałby potraktować pamięć carta jak sektory dyskietek ale z dziurami? Czyli np. z banku 8kB tylko połowa jest na te sektory a druga połowa to coś tam.

2. Czy biblioteki xBIOS umiałby się przecisnąć przez okno $D500-$D5FF. Chodzi mi, że jakbym zrobił takiego carta co przy zapisie bankuje jak zwykły Maxflash ale przy odczycie to tam w tym zakresie pojawi się normalny kod dla CPU to czy xBIOS dało by się ogarnąć w tych 256bajtach (ten zakres też mogłyby być bankowany)? Zmierzam do tego, żeby mając cart w ogóle nie używać pamięci RAM (no może stos).

Kumam. Ale taki trik. Mam FPGA z wewnętrznym PLL. Niech będzie MAX10-tka. Obok niego mam oscylator 14.XXX (osobny, nie ten ATARowski). Sygnał wpuszczam na FPGA gdzie w środku mnożę PLLką niech będzie x16. Powstaje mi wewnętrzny zegar 224,XXMHz. Następnie najprościej jak się da maszyna stanu, liczona do 16.
Dla 0 wyjścia takie i takie.
Dla 1 ... itd.
Dla 15 ..
Wtedy nie potrzeba mi CLK_IN CLK_OUT PHI2. A OSC i wszystko co FREDDIE kontroluje ma zbocza żylety. Przesunięcia fazowe załatwia mi właśnie to zliczanie do 16 (ale może być większe przecież).

Czy wtedy PHI2 będzie stały w fazie (bo rozumiem, że zbocze SALLY jakoś tam zepsuje)?

Matko. Czytam z zainteresowaniem, bo zastanawiałem się jak sobie poprawić PHI2 na złączu carta, bo tak na oko oscyloskopu to on jest w fazie nijakiej z wypełnieniem dziwacznym. Kiedyś PLLem poprawiłem fazę (na minus) CLK dla HDMI (pixelclock74MHz) lecącego drutem przez slipringa. PLLka robi to w trybie basic przy minimalnej wiedzy operatora.

No ale tutaj jakaś masakra jest, przecież te zegary latają po wszystkich układach i każdy coś w nich grzebie. To jak na końcu cart ma się dobrze wystawić na magistrali i dla CPU i ANITCa i GTIA to bez szans jest gmeranie przy tym. To cud, że to w ogóle działa :/