Zatimco ke mne zpoza oceanu putuje cosi jako hardwareova ladicka programu,
na netu se vylouplo tohle megadílo:

Megamon 64 by Mark Schultz is not only a great ML Monitor, it is also very well documented. Docs are on disk.
http://www.commodore.software/downloads ... megamon-64

Megamon has a single-step feature (unusual in memory-resident monitors)
https://www.lyonlabs.org/commodore/onrequest/index.html

Pravy debugger pro C64 se tezko hleda, vydavaji za nej kdejaky disasembler, vcetne starickeho Supermonu.

Reálnej debugger čistě softwarovej jako program co by se nahrál je trochu nereálný na C64

Preco by mal byt nerealny ? Kopec inych osembitov (aj horsich) ma softwerovy debugger.

To se jedná jen o ML monitor,který řada lidí považuje za debugger ač do reálnýho debuggeru tomu pár vlastností chybí.

Teraz nie som si isty ci obaja pod pojmami ML monitor a debugger myslime to iste. Aspon ja si pod pojmom softwerovy debugger predstavujem program ktory umozni vykonavat ladeny program, krokovat ho, sledovat jeho vykonavanie (vypis instrukcii, obsahy registrov a pameti) a nastavovat rozne podmienky vykonavania (ochranne okna v pameti, breakpointy...). A toto vsetko sa softwerovo da urobit.

Urobit se to dá,ale né na C64 ,kde limit je paměť a ASM je low level.

Podla mna by sa urcite dalo aj na C64. Ved napriklad taky ZX Spectrum, ten ma este mensiu pamet (48kB, z coho este natvrdo ukroji 7kB obrazovka takze realne iba cca 41kB), a existuje tu kopec plnohodnotnych cisto softwerovych debuggerov. Umoznuju krokovat strojakovy program vsetkymi beznymi sposobmi ako nativne debuggery: step, step-over (rychle vykonanie celeho podprogramu), beh programu v plnej rychlosti az po najblizsi breakpoint, sledovanie/modifikacia pameti a vsetkych registrov procesora, ochrana vybranych usekov pameti pred zapisom a vykonavanim kodu.
Samozrejme je tu to obmedzenie ze debugger musi byt nahrany niekde v pameti, a tento kus pameti krokovany program potom nemoze pouzivat. Ale s tym sa pri softwerovych debuggeroch pocita.

Já myslím že by stačilo číst co píše Cosmos, pokusit se porozumět tomu textu a až teprve potom psát co si myslíš.

Ja si zase myslim ze by stacilo si precitat aj posledne dve vety z mojho predchadzajuceho prispevku (nechal som ich tu v citate) a pokusit sa im porozumiet

tohle není ten problém

beh programu v plnej rychlosti az po najblizsi breakpoint - Normalny klasicky softwerovy breakpoint. Na 6502 je na toto vhodna instrukcia BRK a ked ladeny program vyuziva prerusenie tak sa s urcitymi obmedzeniami da pouzit aj JSR. Proste, ked program narazi na breakpoint, tak breakpoint sposobi ze program nepokracuje vo vykonavani, ale skoci do debuggera a debugger nasledne zobrazi kde program skoncil a uzivatel sa moze rozhodnut co dalej.

sledovanie/modifikacia pameti a vsetkych registrov procesora - tak toto je hadam jasne, uzivatel moze pocas krokovania sledovat a modifikovat pamet ci registre. Pocas ostreho behu na toto moze sluzit prave ten breakpoint - ked program narazi na breakpoint, riadenie sa odovzda debuggeru, ktory na zaklade definovanych podmienok (napr. na zaklade hodnot v registroch a v pameti) vie rozhodnut co dalej (napriklad na ZX Spektre toto umoznuje Laser Genius debugger).

Pokud vám běžící program přepíše vektor tabulku podle své potřeby nebo mění konfiguraci RAM $01 podle potřeby a v případě konfigurace $01 na bez Kernalu si nastavi hardwarouvou IRQ adresu ($FFFE-$FFFF) jak potřebuje,tak jsou nějaký breakpointy k ničemu.

Neznám ZX Spectrum organizaci paměti a jak s ní pracuje,ale na C64 v běžné praxi jak program přistupuje k hw je softwarový debugger,který se nahraje jako program,kde obsadí paměť např od $8000 nebo od $C000 nepoužitelný, jelikož může spuštěný program si na danou oblast zapsat data

Samozrejme je tu to obmedzenie ze debugger musi byt nahrany niekde v pameti, a tento kus pameti krokovany program potom nemoze pouzivat. Ale s tym sa pri softwerovych debuggeroch pocita.