I got a suggestion: Try running the console verified runs on BizHawk and see if they sync. Most of them were done on FCEUX, but if for whatever reason it does not sync maybe something is wrong?
Didn't those verified game required some adjustment while playing back on a actual NES?
Wow, it's crazy how fast you get these improvements out. Great work. I've a question though, is an emulator passing all those above tests perfect in the sense that it behaves like real hardware? Or is it just that he passes all pubished test roms but there might still be differences to real hardware because maybe those roms didn't cover every hardware aspect?
Wow, it's crazy how fast you get these improvements out. Great work. I've a question though, is an emulator passing all those above tests perfect in the sense that it behaves like real hardware? Or is it just that he passes all pubished test roms but there might still be differences to real hardware because maybe those roms didn't cover every hardware aspect?
Yo, I just wanted to drop in and say I'm amazed by all the work you've been doing for NEShawk, Alyosha. Keep it up!
I noticed that the DMA work you've been doing relies on the RDY pin. I've put off working much on the 6502 CPU core until after I could get some automated testing going. However, the IncPc micro-op in the MOS6502X core was missing the dummy read (which would be stalled by RDY.) I've committed that fix today to master. AHX/SHX/SHY illegal opcodes affected by the high byte of the effective address also behave differently based on the RDY pin. More info here: http://csdb.dk/forums/index.php?roomid=11&topicid=94460 If you read that, keep in mind that in the C64 context, RDY is controlled by the video chip and is made inactive when it needs the bus fully.
Oh good catch! After looking at that I noticed that the dummy read for various instructions also is not affected by the RDY pin as it should be, and I think that is part of what is keeping from passing some more of these test, so fortuitous timing.
I finally got Time Lord working, Hurray! This is the only total incompatibility that I know of that remained so I'm quite happy to get it working. It was actually a simple fix, lucky the NesDev wiki already said what needed to be done, it was just a matter of implementing it.
Unfortunately things have gone awry elsewhere. NesHawk had a timing bug and apparently passed some rather important tests through shear luck and cancelation of errors. Removing this bug has led these tests to no longer pass , despite my repeated efforts to resolve them. So looks like a long road ahead.Which tests are now failed?
cpu_exec_space/test_cpu_exec_space_apu now passes with a few simple fixes. That makes 10 new tests passed, up to 90%! I did not include DMA timing fixes, as I still don't know the problem is, so that 90% can be taken with a grain of salt, but still this is progress. Pretty much every remaining test involves the APU. This is good, since it means the rest of the core is really solid, but that is also the least developed part, so will take some effort to get in order.
With a little added logic the other DMA test variant, sprdma_and_dmc_dma_512, now passes as well. That's 2 of the most grueling tests passing, so if I can just work out frmae IRQ stuff there will be no more hurdles and only tuning the APU left to worry about.
I'm a little worried about the accruing performance hits though. I'm currently at about a 20% penalty over 1.11.6. On my laptop that equates to being able to run at about 140 fps. Well hopefully it will still be at over 2x speed once I'm done, I think it will need some serious optimization work though.neshawk apparently passed some rather important tests through shear luck and cancelation of errors.
tvpassfail which seems like a great deal of work.
Just posting here to say I'm impressed with your work, Alyosha. A 100% NEShawk would be really, really awesome. Good luck with the remaining tests!
