[hatari-devel] Tracing AES calls with the existing VDI code?

[Eero Tamminen]

Hi,

On Tuesday 12 October 2010, Nicolas Pomarède wrote:
> Le 12/10/2010 20:13, Eero Tamminen a écrit :
> > I was thinking of adding AES call tracing functionality to vdi.c
> > and modify newcpu.c from this:
...
> > Or do the D0 checking in the renamed VDI_AES_Entry() function as I
> > anyway need to do it there.   Exceptions (for trap#2) should be so rare
> > that few possible extra calls to that function should be a problem
> > (which are done only when extended VDI resultion is used) and the AES 
> > stuff will be used only if tracing is enabled (at build&  run-time).

A problem with the AES tracing is that unlike for VDI & GEMDOS, tracing
doesn't seem to catch the AES calls that the ROM TOS does, only AES calls
done by the applications.  This reduces its usefulness for debugging EmuTOS
itself. App calls debugging can still be useful though.

-> Don't TOSes do AES calls through a Trap handler like they seems to
    be doing VDI and GEMDOS operations?

Also, what is Trap #2 called with D0 = 0xfffe used for?
(It's used e.g. by Opus spreadsheet on its startup)


> > Aditionally I thought to do these renamings:
> > * VDI() ->  VDI_AES_Entry()
> > * VDI_Complete() ->  VDI_AES_Complete()
> > * VDI_OldPC ->  VID_AES_OldPC
> > * CART_VDI_OPCODE_ADDR ->  CART_VDI_AES_OPCODE_ADDR

Renaming touches quite a few files:
M src/cart.c
M src/cart_asm.s
M src/cpu/hatari-glue.c
M src/cpu/hatari-glue.h
M src/includes/cart.h
M src/includes/m68000.h
M src/includes/vdi.h
M src/uae-cpu/hatari-glue.c
M src/uae-cpu/hatari-glue.h
M src/uae-cpu/newcpu.c
M src/vdi.c

Changes for those are trivial though (and as the VDI opcode doesn't
change cart_asm.s doesn't need to be recompiled).


On Tuesday 12 October 2010, Eero Tamminen wrote:
> I forgot to mention that adding AES tracing would need (like DSP tracing)
> changing the trace variable from 32- to 64-bit one as all bits are
> currently needed.  I thought Laurent was doing that, but it seems I'll do
> it. :-)

This was few line change.


> > And of course add the stuff needed for tracing the AES calls with
> > the right names.
...
> Anyway, I was also thinking that now that:
> -  the debugger can break into OS calls
> - OS call opcode/name tables are already listed in the code for tracing
>
> the debugger "info" command could also be used to list tables of the OS
> (GEMDOS, BIOS, XBIOS, VDI, AES) call number/name pairs.  I don't want to
> add the names for TAB-completion because they could conflict with the
> actual function names.

I have now a patch for all of this and for showing AES & VDI information
from debugger (if extended VDI resolution is used so that these are traced).
It's rather large. :-)


> This would mean that disabling tracing wouldn't get rid of these
> opcode/name tables and code for listing them (currently it's built in
> only when tracing is enabled when configuring Hatari).

It can if I add dummy replacement functions.


> For GEMDOS I was thinking that "info gemdos" could also show some Hatari
> internal GEMDOS HDD emulation information like DTA contents etc.  (I
> could also trivially make it so that giving non-zero argument to "info
> gemdos" would select either opcode table or HDD emu state output)

I'll do that for all of the "OS info functions".


> > Any objections for this?
>
> regarding the modification in newcpu.c, I don't have any objection as it
> won't really slow the emulation since, as you said, it will only happen
> in the trap #2 case that is already present.

Great, the stuff is almost ready for commiting.

I'll add separate bVdiIntercept flag similar to bBiosIntercept that will be
used in newcpu.c so that AES & VDI tracing can be done regardless of whether
extended VDI resolutions are used (enabling extended VDI resolution will
then just imply also bVdiIntercept=true).


> > Also, what this commented out code in VDI() is/was for:
> > ----------
> >          /*
> >          OpCode = STMemory_ReadWord(Control);
> >          // Check OpCode
> >          // 8 - Text Font
> >          if (OpCode==9)
> >          {
> >                  return true;
> >          }
> >          */
> > ----------

Opcode 9 is v_fillarea().

> > Can it be removed?
>
> Can't say, I don't know this part.

We don't have VDI (nor Bios / XBios) acceleration / Hatari host side
replacement implementations for the Atari native VDI function like
Aranym has, so this is quite useless.

Unless somebody's planning to implement such acceleration (which works
with all the screen formats Hatari emulates and with all possible VDI
implementations out there), I'll remove it.


	- Eero