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

[ Thread Index | Date Index | More Archives ]

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.


I'm adding this to my todo list, will try to give it a look soon.


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);


Mail converted by MHonArc 2.6.19+