Re: [hatari-devel] New WinUAE CPU core and NatFeats

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 09/01/2015 11:57, Nicolas Pomarède a écrit :
> Le 06/01/2015 23:28, Eero Tamminen a écrit :
> > --------------------------------
> >
> > Besides not advancing over the opcode, is there a problem in illegal
> >
> > opcode exception stack? ("invalid NF ID -1 requested" error comes
> >
> > from doing NF_CALL with invalid ID, not by requesting ID with NF_ID.)
> >
> > I'm running Hatari like this:
> >
> > $ hatari --natfeats yes --conout 2 --debug-except all,autostart --trace
> > gemdos,natfeats nf_ahcc.tos
> >
> > nf_ahcc.tos is attached, it's built from Hatari sources.
>
> Hi
>
> I'm adding this to my todo list, will try to give it a look soon.

Hi

this should now be fixed ; problem is that I copied/pasted the change in 
OpCode_VDI to OpCode_NatFeat_ID/OpCode_NatFeat_Call by calling 
fill_prefetch() but in fact I should have called "NOP" in this case.

Do you confirm it works for you ?

Note : debugging took more time than expected, because it seems the test 
program in tests/natfeats/natfeats.c is in fact bugged :(

Problem is in nf_showname, size of buffer is passed as a "word", but 
natfeats expects it to be a "long" ; so we get :

MOVE.W #$003e,-(A7)
PEA.L (A6, -$0048) == $000115ec
MOVE.L D4,-(A7)
JSR $0000f912		; natfeats call

....
NF_NAME[1](0x115ec, 4063232)
M68000 Bus Error writing at address $115ec.

-> len is 4063232 = 0x3E0000 because we read a long in nf_name. So 
STMemory_CheckAreaType will fail unless you have 4MB or more.

I think adding "(long)" should fix the nf_showname in 
tests/natfeats/natfeats.c :
                chars = nf_call(id, buffer, (long)sizeof(buffer)-2);

Nicolas