Ecco. Visto? Secondo me e' stata la Befana ;-) Eppure sono convinto che il tempo necessario per capire che non ci sono piu' bit in arrivo da nastro non e' cosi' lungo da permettere a qualche routine di rovinare la schermata. Almeno a giudicare da quanto e' rapido il R Tape Loading Error... :-) Il 05/01/09, Alessandro<alessandro.poppi@xxxxxxxxx> ha scritto: > On Monday, January 05, 2009 1:15 PM [GMT+1], > Alessandro <alessandro.poppi@xxxxxxxxx> wrote: > >> Ho appena finito l'editor dell'indirizzo di breakpoint nel firmware >> del picoblaze, adesso finalmente provo a prendere qualche snapshot >> usando la fine della routine di caricamento come trigger. > > Col cazzo. (si puo dire, 'col'?) > > Al secondo gioco (Arcadia, Imagine software) sono incappato in una cosa > strana: lo snapshot preso mediante NMI su breakpoint a 05E2 non funziona. > Funziona invece se preso poco piu` avanti a mano, oppure anche settando il > breakpoint all'indirizzo $6001 (che e' quello del 'randomize usr' che si > vede nel loader in basic). > > Alla fine ho scoperto che il quarto blocco (1=basic, 2=codice macchina, > 3=protezione, 4=protezione) carica tre bytes nella variabile FRAMES, che e' > quella incrementata ad ogni interrupt. E' probabile che l'arrivo del mio NMI > impedisca un qualche incremento, essendo prioritario, per cui scatta la > protezione. Il ripristino dello snap utilizza una tecnica un po' complicata > per riattivare gli interrupt, perche' ad esempio se il gioco utilizza IM2 e > abilito EI (ovviamente stando ancora dentro alla mia bootrom) la routine di > servizio potrebbe non essere al suo posto. > > Quindi, puo' darsi che in fase di ripristino l'INT non venga servito > abbastanza in fretta (o forse fenga servito TROPPO) per cui il conto non > torna. > > Almeno, questa e' la mia ipotesi non confermata ma plausibile. > > Ciao! > (e adesso vediamo quanto ci metto con il terzo gioco) :-) > > >