
-Assembler para Motorola y MK14
-Assembler para opcodes del Next
-Assembler instrucciones DD/FD+CB no documentadas. ej: LD B,RLC (IX+dd)
-Detectar errores sintaxis en assembler

-Quizá agregar stack Trace en kernel panic. Que pasa con stack de mk14 y Motorola?
Implica leer memoria para sacar el stack. Conviene hacerlo después de un panic?

Menu debugger:
-Doble ptr, uno para codigo y otro para memoria

-posicion electron no va bien en: zx81, tsconf. Revisar otras maquinas. En 48k funciona bien

--En debug cpu que diga tiempos de opcodes y/o en que t estado se ejecutan

-poder indicar mas de una accion en misma breakpoint condition, ejemplo
condition: pc=4000h

action: prints hello ; menu

-cuando hay breakpoint pc en otras vistas, tambien mostrarlo

-Menú debug cpu extra debug con extended debug, code coverage etc

-al cambiar de core reduced o no, si habia breakpoints, aparecen como activos aunque realmente el core no esta usando el debug core (se ha perdido el nested)

-con multitarea on, en debug cpu, en step mode, por lo tanto, no ejecuta cpu opcodes de fondo, si se activa OSD, se ejecutaran opcodes mientras dure el OSD
En ese mismo OSD, si pulsamos una tecla en el OSD, se quedara colgado, pues no vuelve -> parece que incluso sin modo step, el osd se colgara al enviar una tecla : en el caso de que no es modo step, realmente no se ha colgado, solo que se ha quedado la tecla indicada pulsada-> pulsar misma tecla para liberarlo

-con menu abierto no se disparan acciones, excepto si se va a menu debug cpu: logicamente pues eso solo se gestiona al iniciar el menu

-Si un breakpoint de menu y otro de accion (prints por ejemplo) coinciden al mismo tiempo, solo salta el breakpoint de menu
->problema que el breakpoint que ha saltado, indicado por la variable catch_breakpoint_index, solo puede ser uno cada vez...

-breakpoints que se disparen cuando se cumpla una condición N veces:
*shortcut desde ventana menu debug cpu para cambiarlo?
*para el futuro, para poder soportar:
a)     "== 5" — Break exactly on the 5th hit.
b)     ">= 10" — Break on the 10th hit and beyond.
c)     "% 3 == 0" — Break on every 3rd hit.
De momento solo soporto a). Se podría crear una pseudovariable (CURRENTHIT) que tome el valor de cada contador del breakpoint evaluado.
O sea si se está evaluando el primero, darle el valor del contador del primer breakpoint; si el segundo, con el segundo, etc.
Luego en el parámetro de pass count, en vez de indicarle un numero, indicarle una expresión:
CURRENTHIT=3
o
CURRENTHIT >= 3
etc.


-Desensamblador, que permita copiar código assembler a texto
->desensamblador, pero de momento no puede copiar a texto

-condiciones outfired e infired no se disparan cuando son operaciones i/o de dma. es debido
a que las variables debug_fire_in y out se resetean antes del core y se comprueban despues,
pero la dma va aparte

-debugger z80: que sea capaz de mostrar direcciones NNNN correctas (para JR CC DIS) aunque se este debugando con memory zone y direccion alta.
Por ejemplo:
estamos en full ram en zxuno, vamos a la direccion donde empieza propiamente la rom 0, a la 131072:

 20000 F3       DI
 20001 01036C   LD BC,6C03
 20004 0B       DEC BC
 20005 78       LD A,B
 20006 B1       OR C
 20007 20FB     JR NZ,0004

Este JR NZ deberia aparecer como 20004

-poder cargar tabla de simbolos de un codigo fuente

-visor sprites: quizá mejorarlo para que se pueda elegir el incremento de salto para cada scanline... Por ejemplo, sprites de tsconf saltan de 256 en 256

-Paso a paso cuando hay condición de debug activa no deja salir (en menú) : ocurre porque sale y al momento salta
breakpoint y vuelve a entrar. Es normal->opcion para poder salir de ahi aun con breakpoint activo? tiene sentido?

-menu debug keys. que muestre en pantalla las teclas que se pulsan

-Set breakpoint en dirección vista en ZRCP

->Esto siguiente de debug_dump_nested_functions ya está corregido en principio
void debug_dump_nested_functions(char *result)
  Ver en cada caso que haya algo en la lista y que ademas,
  el handler (por ejemplo, cpu_core_loop) apunte a handler nested
  Sucede que si por ejemplo activamos kartusho, y luego hacemos un smartload,
  el kartusho se desactiva, pero la lista contiene funciones nested, aunque los handler de peek y poke
  apuntan a los normales y no a kartusho (como debe ser)
->Se deberia tener algo que , cuando se cambian los handler (peek, poke, cpu etc) se borrase la lista nested,
aunque no es necesario, pues cuando se crea un elemento y el handler no apunta a nested, se crea lista nueva,
y ademas, la funcion de debug_dump_nested_functions ya controla esos casos y no retorna nada de la lista

-mostrar fecha y hora en los debug printf logs?


-Text Adventure Map
*botones rapidos para navegar norte/sur/etc?

-paws Dump toda tabla procesos
-confirmar parametros de Freehand en quill. crear grafico en illustrator y hacer las 8 posibles combinaciones
-Número gráficos limitar a maximo 256 (en quill, paws, daad, gac)
-text adventure map: opcion mostrar descripciones. localidad 14 por ejemplo se mezcla. en que juego??
la aventura original quiza. pero esto es porque la 14 parece que muestra varias habitaciones a la vez
(una con dibujo y otra sin dibujo y solo texto). quiza seria mejor opcion en que, cuando encuentre mas de una
habitacion en misma posicion, la mueva a otra posicion para que esté aislada



-registro debug ficticio EPC soporte para tbblue, zxuno, ....


-Debug printf solo hacer bloqueo cuando mensajes van a consola de ZX Desktop
Prueba con redimensionar ventana con driver audio sdl con callback y printf donde avisa de underrun de buffer y en Windows