Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Programowanie - 8 bit » Bieżący adres PC z poziomu Atari
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
Nie pytam się o emulator, tylko o real Atari.
Zastanawia mnie, gdzie można odczytać aktualnie używany adres PC wykonywanego rozkazu przez procek.
Zapewne wywołanie przerwania, zdjęcia danych ze stosu załatwia sprawę, acz....
może istnieje gdzieś magiczny rejestr z którego można pobrać te dane....coś mi kiedyś świtało, że $FFxx xx=??
Czy któryś ze znanych Wam freezer'ów miał śledzenie bieżącego adresu PC ?
?
Dziwne pytanie. Kto ma przeczytać ten adres? Sprzętowo jest on tylko na szynie adresowej, a nie pod żadnym magicznym adresem. Programowo to zwykle wiadomo, pod który adres kompilujemy:
ten_rozkaz
ldx #<ten_rozkaz
ldy #>ten_rozkazA w rzadkich przypadkach, gdy przenieśliśmy kod w inne miejsce, odzyskamy go skacząc do procedury (której adres jest dobrze ustalony):
jsr get_pc
...
get_pc
pla
tax
pla
tay
pha
txa
pha
inx
sne:iny
rtsW x i y mamy adres instrukcji po jsr.
Co do freezerów nie mam pojęcia, bo nigdy się z nimi nie zetknąłem.
W runtime adres dostępny jest tylko przez stos. Można go odczytać wywołując np BRK, ale polecałbym jednak zwykły JSR, ponieważ obsługa przerwania BRK może się nie udać z tego powodu http://atariki.krap.pl/index.php/6502 (sekcja "Błędy związane z przerwaniami").W tym wątku http://www.atari.org.pl/forum/viewtopic.php?id=7800 odbyła się dyskusja, ale ja nie sprawdziłem koniec końców czy da się poprawnie obsługiwać BRK - temat jest otwarty :).
@0xF: Niestety program nie zawsze jest kompilowany pod znany adres - vide SDX format relokowalny.
Pytanie dotyczy czasu po kompilacji, na zrelokowanym kodzie np. Sparty.
Wydaje się, że jedynie wykonanie jsr i obliczenie założonej różnicy w adresach może dać odpowiedź nt. obecnego fizycznego położenia.
A czy freezer na czas zatrzymania wywołuje przerwanie?
jsr do podprogramu jak pisal Fox.
get_pc tsx
ldy $102,x
lda $101,x
tax
inx
bne @+
iny
@ rts
Fox wskazał też inny sposób. Właściwie jeśli robisz JSR, to wiesz w którym punkcie programu go wywołujesz - w kodzie relokowalnym zamiast:
ldx #<point
ldy #>pointjak radzi Fox można zrobić:
pointadr .word pointi potem
ldx pointadr
ldy pointadr+1przynajmniej relokator SDX potrafi takie konstrukcje obsługiwać (właściwie to relokator do spółki z madsem).
Ale to jeśli interesuje cię adres punktu w pamięci po relokacji, bo jeśli jednak chcesz w różnych punktach programu wołać procedurę, która zbada skąd została wywołana i coś z tym zrobi, to zostaje JSR.
Czyli Fox dobrze radzi (i xxl) :)
To z innej beczki....
Niedopalone atari przyjmuje program z przerwaniami (też DLI) i chodzi. ZRapidusowane - gdzieś się wykrzacza, i można go selektywnie jak i fragmentami debugować. No ale błąd nie jest na każdej ramce, pewnie zależy od x-czynników.
Gdyby tak Freezer przejmował miejsce zwisu, to już by było coś. One to potrafią ?
Freezer nie ma miejsca "zwisu". Jak Atari się zawiesi to i freezer nie zadziała. Działanie Freezera polega na wygenerowaniu przerwania NMI i w tym czasie podmiana pamięci w obszarze wektora NMI tak aby wskazywała na procedurę startu kodu freezera. Po wciśnięciu przycisku freezera zmienia się totalnie mapa pamięci Atari. Ponieważ wywołanie freezera jest de-facto przerwaniem, adres powrotu leży sobie grzecznie na stosie. Jak wcześniej stos np. "przekręcił się", powaliło się coś innego... to często gęsto freezer nie da rady się poprawnie uruchomić... a jeżeli mu się to uda... to nie ma szans na poprawny powrót... bo niby do czego?. Jeżeli 6502 napotka któryś z rozkazów KIL... i 6502 wisi... Freezer również martwym jest.
pajero: Hardware'owy monitor szyny by się przydał. Nie wiem czy takie coś istnieje ...
W najprostszym wypadku będzie to garść diod led + rezystory. Ale O ile CPU nie wejdzie w stan ubicia/zwisu to ciężko będzie cokolwiek z tego odczytać.
Zdaję się, że Rapidus śledzi szynę.... ale oficjalnego manuala dopałki jeszcze nie widziałem.
Całość sprowadza się do kontynuacji prac nad QMEGiem 5x, właściwie wyprostowaniem tego co napsułem.
Głównie brak monitora pamięci. Też niedopracowana obsługa 65816 (tak by nie padał OS przez przypadek).
Serio? Qmeg? w 2017 roku?
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Programowanie - 8 bit » Bieżący adres PC z poziomu Atari
Wygenerowano w 0.022 sekund, wykonano 65 zapytań