|Re: [hatari-devel] New WinUAE CPU core and NatFeats|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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 :
PEA.L (A6, -$0048) == $000115ec
JSR $0000f912 ; natfeats call
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
chars = nf_call(id, buffer, (long)sizeof(buffer)-2);