1 Ostatnio edytowany przez Gienek (2024-01-01 19:19:07)

Ma ktoś doświadczenie z emulatorem ATARI800 i działaniem kodu ze strony $D500? Coś dziwnego się dzieje.

Zrobiłem sobie carta (DCart) co udostępnia cześć banku na stronę $D5XX, tak, że mogę wykonać kod nawet gdy sam cart ma wyłączony bank. Bardzo wygodna sprawa, bo można zaszyć procedury, które są "niezniszczalne". W sensie, przełączanie banków, RAM/ROM nie rusza ich.

Zrobiłem sobie tester i na real ATARI wszystko śmiga zgodnie z planem.

No to chciałem emulator ATARI800 uzupełnić o taki cart. Dodawałem sobie już carty, więc nie jest to jakieś trudne. I niby wszystko jest OK. Jednak coś ATARI800 ma poknocone z D5XX.

Puszczam kod w monitorze. Idę krok po kroku. Jestem na stronie $06 i skaczę pod $D500. Na polecenie "D" Debuger ładnie pokazuje kod ukryty na stronie $D5. Robię jedną instrukcję, sprawdzam, drugą, sprawdzam. Wszystko OK. Robię trzecią i kod idzie w adres z czapy $5462. Jakim cudem? Nic tam niema. A pod $D500 wszystko jest OK.

Próbowałem założyć BREAKPOINTy na stronie $D5 ale też coś to nie działa. Jakby ktoś w emulatorze zrobił bypass dla tego zakresu i jest on traktowany jakoś wyjątkowo. Ale znaleźć to to nie wiem jak.

Upgrade dla ATARI800 (z nowym cartem) oraz tester poniżej. Tester jest prosty. Miga ramka, po naciśnięciu START, skacze do RAM i tam kod miga tłem, potem START i skacze do $D500 i mają migać znaki. Na real działa, na emu nie.

Widok z monitora

> g
  0  21 A=A5 X=00 Y=94 S=FF P=N-*----C PC=064D: 4C 00 D5  JMP $D500
> 
  0  24 A=A5 X=00 Y=94 S=FF P=N-*----C PC=D500: A5 14     LDA $14     ;RTCLOK+2
> d d500
D500: A5 14     LDA $14     ;RTCLOK+2
D502: 8D C5 02  STA $02C5   ;COLOR1
D505: AD 1F D0  LDA $D01F   ;CONSOL
D508: 29 01     AND #$01
D50A: D0 F4     BNE $D500
D50C: 4C 77 E4  JMP $E477   ;COLDSV
D50F: A5 14     LDA $14     ;RTCLOK+2
D511: 8D C8 02  STA $02C8   ;COLOR4
D514: AD 1F D0  LDA $D01F   ;CONSOL
D517: 29 01     AND #$01
D519: D0 F4     BNE $D50F
D51B: A9 00     LDA #$00
D51D: 8D C8 02  STA $02C8   ;COLOR4
D520: AD 1F D0  LDA $D01F   ;CONSOL
D523: 29 01     AND #$01
D525: F0 F9     BEQ $D520
D527: A2 4F     LDX #$4F
D529: BD 35 B5  LDA $B535,X
D52C: 9D 00 06  STA $0600,X
D52F: CA        DEX
D530: 10 F7     BPL $D529
D532: 4C 00 06  JMP $0600
D535: AC C6 02  LDY $02C6   ;COLOR2
D538: A9 40     LDA #$40
> g
  0  26 A=A5 X=00 Y=94 S=FF P=N-*----C PC=D502: 8D C5 02  STA $02C5   ;COLOR1
> d d500
D500: A5 14     LDA $14     ;RTCLOK+2
D502: 8D C5 02  STA $02C5   ;COLOR1
D505: AD 1F D0  LDA $D01F   ;CONSOL
D508: 29 01     AND #$01
D50A: D0 F4     BNE $D500
D50C: 4C 77 E4  JMP $E477   ;COLDSV
D50F: A5 14     LDA $14     ;RTCLOK+2
D511: 8D C8 02  STA $02C8   ;COLOR4
D514: AD 1F D0  LDA $D01F   ;CONSOL
D517: 29 01     AND #$01
D519: D0 F4     BNE $D50F
D51B: A9 00     LDA #$00
D51D: 8D C8 02  STA $02C8   ;COLOR4
D520: AD 1F D0  LDA $D01F   ;CONSOL
D523: 29 01     AND #$01
D525: F0 F9     BEQ $D520
D527: A2 4F     LDX #$4F
D529: BD 35 B5  LDA $B535,X
D52C: 9D 00 06  STA $0600,X
D52F: CA        DEX
D530: 10 F7     BPL $D529
D532: 4C 00 06  JMP $0600
D535: AC C6 02  LDY $02C6   ;COLOR2
D538: A9 40     LDA #$40
> g
  0  29 A=A5 X=00 Y=94 S=FF P=N-*----C PC=5462: 00        BRK
> d
5462: 00        BRK
5463: 00        BRK
5464: 00        BRK
5465: 00        BRK
5466: 00        BRK
5467: 00        BRK
5468: 00        BRK
5469: 00        BRK
546A: 00        BRK
546B: 00        BRK
546C: 00        BRK
546D: 00        BRK
546E: 00        BRK
546F: 00        BRK
5470: 00        BRK
5471: 00        BRK
5472: 00        BRK
5473: 00        BRK
5474: 00        BRK
5475: 00        BRK
5476: 00        BRK
5477: 00        BRK
5478: 00        BRK
5479: 00        BRK
> d d500
D500: A5 14     LDA $14     ;RTCLOK+2
D502: 8D C5 02  STA $02C5   ;COLOR1
D505: AD 1F D0  LDA $D01F   ;CONSOL
D508: 29 01     AND #$01
D50A: D0 F4     BNE $D500
D50C: 4C 77 E4  JMP $E477   ;COLDSV
D50F: A5 14     LDA $14     ;RTCLOK+2
D511: 8D C8 02  STA $02C8   ;COLOR4
D514: AD 1F D0  LDA $D01F   ;CONSOL
D517: 29 01     AND #$01
D519: D0 F4     BNE $D50F
D51B: A9 00     LDA #$00
D51D: 8D C8 02  STA $02C8   ;COLOR4
D520: AD 1F D0  LDA $D01F   ;CONSOL
D523: 29 01     AND #$01
D525: F0 F9     BEQ $D520
D527: A2 4F     LDX #$4F
D529: BD 35 B5  LDA $B535,X
D52C: 9D 00 06  STA $0600,X
D52F: CA        DEX
D530: 10 F7     BPL $D529
D532: 4C 00 06  JMP $0600
D535: AC C6 02  LDY $02C6   ;COLOR2
D538: A9 40     LDA #$40
> 
Post's attachments

cartridge.c 59.81 kb, liczba pobrań: 1 (od 2024-01-01) 

cartridge_info.c 9.73 kb, liczba pobrań: 2 (od 2023-12-31) 

cartridge_info.h 5.11 kb, liczba pobrań: 2 (od 2023-12-31) 

D5testerDCart.car 512.02 kb, liczba pobrań: 2 (od 2023-12-31) 

Tylko zalogowani mogą pobierać załączniki.

2

Nie wiem czy to będzioe pomocne ale może chodzi o implementację dekodera adresów (74LS138) i dostęp do rejestru na stronie $D5 może powoduje wywołanie obsługi carta z poziomu OS-a...

https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email

3 Ostatnio edytowany przez Fox (2024-01-01 17:08:38)

Kod dla 6502 jest zawsze pobierany z tablicy MEMORY_mem. Nie wystarczy więc zwracać go w GetByte, lecz trzeba go kopiować do MEMORY_mem podczas przełączania banku, makrem MEMORY_dCopyToMem.

Edit: Zrób forka na GitHubie i podsyłaj linki do commitów na branchu. Przerzucanie się plikami źródłowymi na forum było dobre 30 lat temu. :)

https://www.youtube.com/watch?v=jofNR_WkoCE

4 Ostatnio edytowany przez Gienek (2024-01-01 19:17:55)

@Fox
Dzięki! Będę się z tym próbował. Dziwne, że dwie instrukcje poszły.

Fork jest (powstał na potrzeby zabaw z JACART), ale zbytnio się tym nie chwalę bo babol z D5XX siedzi:
https://github.com/GienekP/atari800

EDIT.
DZIAŁA :)
Nie wiem czy elegancko dodałem, bo jeszcze nie czuję kodu atari800, w każdym razie wybrnąłem tak:

MEMORY_CopyFromCart(0xd500, 0xd5ff, active_cart->image + (active_cart->state & 0x3f) * 0x2000 + 0x1500);

5 Ostatnio edytowany przez Fox (2024-01-01 19:41:04)

Ta linijka kodu wygląda dobrze. Sam nie zaglądałem do Atari800 od 14 lat.

https://www.youtube.com/watch?v=jofNR_WkoCE

6 Ostatnio edytowany przez mono (2024-01-01 20:37:38)

Mnie się wydaje, że to co Fox mówi to jest zło i niedobro. MEMORY_CopyFromCart i MEMORY_CopyToCart służą do przerzucania pamięci między komputerem a cartridgem, a bajty na $D5xx w komputerze nie są pamięcią - adresy $D0xx-$D7xx są przecież mapowane w obszar $5000-$57FF i teraz zależnie od tego czy mamy tam ROM to pokaże się tam SELF-TEST, a jeśli jest włączony MapRAM to może tam się pokazać też RAM który jest w tym obszarze (o ile konfiguracja PORTB mówi żeby tę pamięć podłączyć). Więc jedyne co tak możesz zrobić to ustawić zawartość pamięci, ale odczyt pamięci w MEMORY_HwGetByte (memory.c) i tak do tego nie sięgnie, bo ten obszar kierowany jest to CARTRIDGE_GetByte.
Wygląda mi ten kod Twój dobrze, ale zwróć uwagę że w CARTRIDGE_GetByte masz

return GetByte(&CARTRIDGE_main, addr, no_side_effects) & GetByte(&CARTRIDGE_piggyback, addr, no_side_effects);

więc może masz jakiś przelotowy drugi cart zamapowany który zwraca coś na $D5xx. Albo może masz jakieś urządzenie włączone?
Albo coś zapisuje Ci $D5xx i przemapowuje bank? Próbowałeś ustawiać breakpointa na zapis do $D5xx?

b WRITE>=D500
b WRITE<=D5FF

Edit: Ale fiksacja :) Cart Ci działa poprawnie, a tylko listowanie kodu za pomocą D(isassembly) przy domyślnym adresie listuje Ci kod spod złego adresu :) Pooglądaj co się dzieje w monitor.c.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

7 Ostatnio edytowany przez Gienek (2024-01-01 21:22:36)

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...

8 Ostatnio edytowany przez mono (2024-01-01 21:22:34)

Gienek napisał/a:

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

To oznacza, że breakpoint ustawiany przez BPC jest nieaktywny. Mnie chodziło o breakpointa ustawianego przez B.

Gienek napisał/a:

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.

Wygląda na to, że emulator robi jakieś przebitki z pamięci - przedziwne. Musi jakiś bug.

Gienek napisał/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.

Cartridge typ 47 "AST 32 KB cartridge" mapuje swoją pamięć na $D5xx i patrzyłem co on robi zanim się zabrałem za oglądanie Twojego.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

9

Na real sprzęcie zwykły ? PEEK(54528) pokazuje mi bajt z magistrali carta, więc jakbym podlutował zwykły ram to bym sobie mógł normalnie tam zapisywać. Jak jest rom to wiadomo, tylko odczyt. Więc bit PORTB (dla SelfTestu) chyba nie wpływa na D5 tylko na 50. I tu coś jest pokręcone w atari800. Bo on jakby na siłę chciał robić trik z SelfTestem.

10

Gienek napisał/a:

Więc bit PORTB (dla SelfTestu) chyba nie wpływa na D5 tylko na 50.

Oczywiście. Chodziło mi o to, że RAM jest podłożony pod całą pamięć Atari - pod $D000-$D7FF również. W standardowym komputerze ta pamięć nie jest dostępna, bo PORTB mapuje ROM z $D000-$D7FF w $5000-$57FF. Po instalacji xxl-owego MapRAM-u można za pomocą PORTB przemapowywać też RAM w $D000-$D7FF w $5000-$57FF.
Na stronie $D5 znajdują się rejestry sprzętowe, ale nie RAM/ROM dlatego procedury CopyFrom/CopyTo nie mają tu nic do roboty. Coś tam jest innego zepsute, ale gdzie?

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

11 Ostatnio edytowany przez Gienek (2024-01-01 21:41:17)

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.

12

I tak działają cartridge z Bounty Bob.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

13 Ostatnio edytowany przez Gienek (2024-01-02 15:31:47)

Poprawcie mnie jak piszę głupoty. Zakres $D5XX jest trzypoziomowy. Najniżej jest RAM. Nad nim jest ROM. I to wszystko przykrywa złącze cartridge. Jak carta nie ma to widzimy FF. Włączenie bitu SELFTEST powoduje migrację obszaru $D000 na $5000. Ale migracja dotyczy tylko(?) ROM. Więc w obszarze 55XX żadne FF się nie pojawią (?).

Czy w ATARI bez żadnych modyfikacji jest jakakolwiek szansa dostać się pod RAM $D5XX? Czy tutaj zawsze cart z butami siedzi.
Czy zapis na $D5XX zawsze idzie do carta, czy w zależności od PORTB jest w stanie trafić gdzieś indziej?
Jeżeli jest SELFTEST to zapis w $5000 idzie na manowce czy zapisze pod RAM "pod spodem"?

Dążę do wniosku, że jeżeli na D5XX zawsze jest widoczny cartridge to kopiowanie na żywca w emulatorze w zasadzie jest akceptowalne. Ale jeżeli magistrala przestawia się jak na semaforach to to co jest w atari800 to na pewno tego nie uwzględnia i zmiana musi być bardziej pokręcona.

14

Gienek napisał/a:

Jak carta nie ma to widzimy FF.

To tylko częściowo prawda. W komputerach gdzie magistrala jest pull-upami podciągnięta do 5V pojawią się $FF-y, ale tam gdzie ich nie ma dostaniesz losowe wartości wynikające ze stanów nieustalonych. Krótko mówiąc - tam nie muszą być $FF-y i nie wolno na tym polegać.

Gienek napisał/a:

Ale migracja dotyczy tylko(?) ROM. Więc w obszarze 55XX żadne FF się nie pojawią (?).

$D5XX - nie pojawią się.

Gienek napisał/a:

Czy w ATARI bez żadnych modyfikacji jest jakakolwiek szansa dostać się pod RAM $D5XX?

Nie ma szans.

Gienek napisał/a:

Czy zapis na $D5XX zawsze idzie do carta, czy w zależności od PORTB jest w stanie trafić gdzieś indziej?

Zawsze idzie do carta.

Gienek napisał/a:

Jeżeli jest SELFTEST to zapis w $5000 idzie na manowce czy zapisze pod RAM "pod spodem"?

Nie zapisze. Tu nie ma jak w C= że zapis do ROM trafia do RAM.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

15

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.

16

ciekawy pomysl...

da sie go rozwinac tak, zeby kart podkladal swoja pamiec sekwencyjnie? takie rozwiniecie karta tom ? moznaby zadac kartowi generowanie spritow programowych i ustawic odczyt antica na d5xx :)

http://atari.pl/hsc/ad.php?i=1.

17

automatem?
GALem cieżko, pewnie trzeba jakieś CPLD albo nawet FPGA.

Ale jakiś picocart to by dał radę. W sumie to by wyszło tak, że dla ANTICa to by istniał jakiś virtualny hardware co mu na gotowo sprajty robi :)