Nestopia JG

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
carmiker
Posts: 12
Joined: Wed Sep 16, 2020 4:16 am
Contact:

Nestopia JG

Post by carmiker »

I am pleased to announce that since the placement of Nestopia UE into maintenance mode, a new fork has been created to continue work on the Nestopia codebase: Nestopia JG

This is part of my larger project, Jolly Good Emulation. Nestopia was in fact the first emulator I worked on, mainly due to the number of input devices it supports -- it allowed me to build a fairly robust input system from the start. I will also note that I designed this for developers and those wishing to learn more about emulation through a "do it yourself" type project, and it is not for casual everyday use, though it could potentially be packaged up in that manner later on.

Currently, there is only one real change since forking. I have fixed a small glitch in the APU that caused scratchy noises in some games, such as Super Mario Bros 3.

I have intentionally disabled the ability to post issues/bugs/pull requests on gitlab for now, as my project is very young and taking shape still. However, I decided to post here so that the nesdev community would be aware that the emulator is still being actively worked on.
User avatar
carmiker
Posts: 12
Joined: Wed Sep 16, 2020 4:16 am
Contact:

Re: Nestopia JG

Post by carmiker »

I've released Nestopia JG 1.52.0.

Within a few days, the changes were picked up by both Nestopia UE and libretro, I am certain that soon, OpenEmu will also pick up the latest code. All of these are great options if you don't feel like compiling my upstream code from source, and still want to use the Nestopia emulator.

The emulator is still very much active, and for the next release tag, I am hoping to get the small handful of remaining TASVideos tests to pass, and perhaps some other tests, as well as support for more pirate mappers.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Nestopia JG

Post by lidnariq »

If it's ok to tell you this - there's a major bug in Nestopia's handling of the DPCM-vs-joypad reads. Somehow it's gotten the DMA read-vs-write clock exactly backwards, so DMA-fortified routines that work on hardware exactly *don't* work in Nestopia, and vice versa.

It's bad enough that we have to tell people to not use Nestopia for development at all; it'd be more useful to completely disable Nestopia's emulation of this bug than the specific way it's backwards.
User avatar
carmiker
Posts: 12
Joined: Wed Sep 16, 2020 4:16 am
Contact:

Re: Nestopia JG

Post by carmiker »

Yes, I am aware of this. Unfortunately I end up doing a git reset --hard any time I try to fix it -- it is very frustrating. If anyone else can lend a hand, I would appreciate it... but if not, I will have to just bite the bullet and put in the time and effort to get it right on my own.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Nestopia JG

Post by Fiskbit »

I intend to update the wiki in the near future with new findings regarding DMA and 2A03 registers, which will hopefully make it easier to understand and implement. I agree with lidnariq, though, that it is far better to completely disable the extra reads caused by DMA than leave them in with bad timing. Nestopia is the biggest argument against using synchronized reads to work around the joypad bit deletion issue, a strategy that I think is otherwise ideal.

I'm glad you're working on keeping this emulator alive and improving it!
posit
Posts: 15
Joined: Tue Oct 11, 2022 11:40 pm

Re: Nestopia JG

Post by posit »

I intend to update the wiki in the near future with new findings regarding DMA and 2A03 registers, which will hopefully make it easier to understand and implement
<3
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Nestopia JG

Post by Fiskbit »

FYI, my DMA article is now up on the wiki. If something's confusing or poorly worded or if it doesn't answer your questions, please let me know.
User avatar
carmiker
Posts: 12
Joined: Wed Sep 16, 2020 4:16 am
Contact:

Re: Nestopia JG

Post by carmiker »

Thanks for taking the time to put that together, Fiskbit. I'll take a look and hopefully be able to resolve this bug in Nestopia.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Nestopia JG

Post by Dwedit »

Fiskbit wrote: Fri Jan 06, 2023 2:20 am FYI, my DMA article is now up on the wiki. If something's confusing or poorly worded or if it doesn't answer your questions, please let me know.
It says that "The power-on alignment with the CPU is random." Was this confirmed with hardware tests?
I think it could be tested with Frame IRQ, a sprite DMA operation, and a big idle loop that waits for the correct number of cycles. Looks like APU frame counter also operates every other cycle, so what's its power-on alignment?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Nestopia JG

Post by Fiskbit »

I do my testing on Everdrive and so I can't test that it's random at power-on, but I did confirm it's random across resets. lidnariq analyzed this in Visual2A03, and my understanding of what he found is that it starts running as soon as the CPU receives power and a clock, so while it may be fixed initially, the exact timing of when the CPU comes out of reset (depending on the CIC on the NES-001 and capacitor otherwise) is not consistent, leading to an unpredictable alignment.

I would expect this to affect anything using the APU clock, which I suspect includes the frame counter (the wiki says it's clocked every 2 cycles).
User avatar
carmiker
Posts: 12
Joined: Wed Sep 16, 2020 4:16 am
Contact:

Re: Nestopia JG

Post by carmiker »

I've finally gotten back to the Nestopia codebase after a longer than planned adventure in the world of Neo Geo. I can say now that a few more tests pass (sprdma_and_dmc_dma and sprdma_and_dmc_dma_512 thanks largely to Fiskbit's documentation), and the bug mentioned by lidnariq should now be resolved. I hope to tag a new release before this calendar year is through, however, I would like to know if there is any specific homebrew I could play around with to ensure the bug mentioned by lidnariq is indeed resolved. There are dma_sync_test_odd and dma_sync_test_even which I've been using, but it would be great if I knew of an actual game that relies on this being correct.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Nestopia JG

Post by Fiskbit »

Thanks for working on this!

This hack of Shanghai 2 to add mouse support relies on synced reads, though I believe it only works with the official SNES mouse, not the Hyperkin variety, which requires delays between reads. I also have two modified test ROMs here. One of them relies on sync working forever and should never see a collision, while the other is expected to produce a collision very quickly due to a write cycle causing a desync.

Is there a build available that I could play with?
User avatar
carmiker
Posts: 12
Joined: Wed Sep 16, 2020 4:16 am
Contact:

Re: Nestopia JG

Post by carmiker »

Thanks for the info on the Shanghai 2 hack, and the more exhaustive tests.

I don't release binaries at the moment, though there is work being done which allows static linking of cores with the frontend, which could be used to generate standalone Windows executables via CI in the future (not that this helps now). If you have a development environment, the latest commit in my gitlab repo has the tentative fix: https://gitlab.com/jgemu/nestopia

I seem to fail the exhaustive test, so there is still some tweaking to be done. I am probably missing one or two cases here still.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Nestopia JG

Post by Fiskbit »

I suggest going over the summary on the DMA page again, but for specific ideas, make sure that the DMC timer is continuing to run even on halted cycles, that DMC DMA takes the correct amount of time (4 cycles if it lands on a put as usual, and 3 cycles if it's delayed to a get), that the write cycle delays are working correctly (it can be delayed up to 3 cycles because that is the longest stretch of write cycles possible), and that reload DMC DMA still takes 4 cycles when delayed twice (because two delays makes it land on a put, so its timing is the same as usual, just later).
User avatar
carmiker
Posts: 12
Joined: Wed Sep 16, 2020 4:16 am
Contact:

Re: Nestopia JG

Post by carmiker »

I am still trying to get this working in Nestopia correctly. The problem I am having is that the codebase is extremely complex, so though I understand how DMA is supposed to work, implementing it properly in this codebase has proven impossible for me over the past few weekends. I am starting to think the problem is not in the base DMA code, but in how the $200x read conflicts are being handled. I have a new strategy, which is to continue work on my new cycle-stepped NES emulator and implement everything perfectly there first, then compare and port it over.
Post Reply