[hatari-devel] Tracing AES calls with the existing VDI code?
Nicolas Pomarède
npomarede at corp.free.fr
Tue Oct 12 20:54:03 CEST 2010
Le 12/10/2010 20:13, Eero Tamminen a écrit :
> Hi,
>
> I was thinking of adding AES call tracing functionality to vdi.c
> and modify newcpu.c from this:
> ----------
> /* Intercept VDI exception (Trap #2 with D0 = 0x73) */
> if (ExceptionSource == M68000_EXC_SRC_CPU)
> {
> if(bUseVDIRes&& nr == 0x22&& regs.regs[0] == 0x73)
> {
> if(!VDI())
> ----------
>
> To either this:
> ----------
> /* Intercept VDI (D0 = 0x73)& AES (D0 = 0xC8) exceptions (Trap #2) */
> if (ExceptionSource == M68000_EXC_SRC_CPU)
> {
> if(bUseVDIRes&& nr == 0x22&&
> (regs.regs[0] == 0x73 || regs.regs[0] == 0xC8))
> {
> if(!VDI_AES_Entry())
> {
> ----------
>
> 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).
>
> 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
>
> And of course add the stuff needed for tracing the AES calls with
> the right names.
>
> Any objections for this?
Hello,
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.
>
> 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;
> }
> */
> ----------
>
> Can it be removed?
Can't say, I don't know this part.
Nicolas
More information about the hatari-devel
mailing list