No, jest MAE, które ma edytor, kompilator i debugger w jednym. Debugger ma, jak każdy debugger, opcje śledzenia programu, aczkolwiek nie powiem, żebym kiedykolwiek z niej korzystał.

Ale emulator (Atari 800 Win) ma wbudowany monitor, którym można wszystko przejżec. Nie da się nim co prawda podglądać działania programu krok po kroku, ale na pewno łatwiej nim dociec co się zwaliło po zwisie, niż na prawdziwym Atari.

Ja deabuggera MAE uzywałem dość często i muszę przyznać, że jest to bardzo dobre narzędzie (czego nie mogę powiedzieć o Bug Huntrze): ˇ praca krokowa ;)
ˇ pułapki na adres, stan procesora
ˇ monitor pamięci i rejestrów
ˇ wbudowany prosty asembler
ˇ deasemblacja na dowolne urządzenie (E:, D:, itp.)
ˇ podgląd wartości etykiet (jeśli przejdziemy do debuggera po asemblacji programu)
ˇ wyszukiwanie referencji
ˇ funkcje uzytkownika
ˇ prawie cała pamięć dla programu (debugger zajmuje kilkaset bajtów poniżej $C000, reszta jego kodu siedzi w banku)
ˇ długo jeszcze by wymieniać ;)

A moze przydalby Ci sie mlody (hehe) programista jako betatester tych opcji debugujacych? :D

[ Dodano: Pią Lis 12, 2004 12:54 pm ]
Wlasnie, zapomnialem dodac, ze jak juz mam xasm pod winde + emulator to debuger/symulator bylby znacznie wygodniejszy w obsludze pod winde a nie pod atari. Ja zawsze mam problem jak na ekranie 1000x700 pomiescic wszystkie wymagane informacje (program, ze 2 podglady pamieci, rejestrow, timerow,...). Na Atari to musi byc masakra.

gdb-style zupełnie wystarczy na początek, ja stawiam wino jak ktoś zrobi gdb-like uruchamianie programu, z: s,n,up,do,b,c,l, etc...
Tylko musi być możliwość załadowania równolegle źródełek (albo outputu x-asma) :)

s-step (into), czyli jezeli nastepna instrukcja jest JSR to wywola to JSR i zacznie debugowac tam
n-next, jezeli to JSR, to poczeka az JSR wroci
up-pojdzie 'wyzej' w stosie wywolan (czyli pokaze kto nas wolal)
do-to samo nizej
b-ustawi breakpoint (bez parameteru - tu gdzie jestesmy, z paramterem - adres lub linia kodu)
c-continue, czyli niech sie program dalej wykonuje do momentu zatrzymania
l-listuj

co do ladowania zrodelek, to x-asm produkuje taki fajny pliczek jesli sie uzyje odpowiedniej opcji, w ktorym jest pomieszany wygenerowana binarka ze zrodlem. super by bylo jakby wciskajac 'l' (list), o ile dla danego fragmentu pamieci kod jest 'zywcem' z x-asma, widac byloby taki uklad kodu (i komentarzy!)  jak w xasmie. ma to oczywiscie pewne problemy, np co zrobic z makrami, wiec mozna by bylo zrobic dwa rodzaje pracy - czysty tryb 6502 i x-asm :)

jezeli uzywasz 'printf' do debugowania zamiast gdb... to znaczy ze nie jestes dobrym programista (cytat z mojego promotora, ktory programista jest niesamowitym) :)
oczywiscie printf tez sie przydaje, ale nie zastepuje gdb jednak.

:)

oOOOOoooooOoOOooOOooOooo!
to moja nie wiedziała.
To jakieś straszne draństwo, że zablokowali. Czekam na wersję odblokowaną :)
masz wino, tylko się przypomnij :)

Panowie, bez jaj. Po co to wszystko mieć na ekranie? To - wartości rejestrów, stany znaczników, operacje wykonywane przez rozkazy - widzi się po prostu na generowanym przez debugger listingu kodu. Debugger, który nie może pomieścić istotnych informacji na ekranie 1024x768 może potrzebny jest przy łamaniu cudzych programów, ale do śledzenia własnych wystarczy 40x24 (= debugger MAE).

Poza tym, ale to moja prywatna opinia, jeśli ktoś się uczy asemblera, to uzależnianie się od debuggera na tym etapie jest największą krzywdą, jaką sobie można zrobić na przyszłość. Albowiem do wykrywania błędów we własnych programach wcale nie jest potrzebny debugger, tylko umiejętność analizy kodu, a w wyrobieniu tej umiejętności debugger akurat przeszkadza, bo odmóżdża już na samym wstępie.