decrazyo / lng-fds Goto Github PK

On real hardware the startup message states the machine is detected as PAL 50hz, when it is actually an NTSC 60hz NES.

Freaking cool project. I find your README.MD a bit challenging to read though.

Would you be interested in me reformatting it with markdown...?

I'm not asking for money or anything, just wanted to know if it was something you were interested in before starting on it.

Here's an example of my markdown-ing from a pull request.

Here's an example from one of my repos.

And here's an example from reddit.
Though reddit markdown is a bit different (note that it doesn't have linebreaks).

I can embed pictures into it as well (if you wanted to take a few of it running on a console), to give people a feel for what it looks/acts like.

It might help grow your userbase/audience a bit more.
I'd love to see a project like this freaking go for the moon.

I have an NES with a Famicom EXP port mod, plus a Famicom keyboard and flash carts.

Using the Everdrive N8 Pro I am able to type just fine, but when I try to load (l sh), it gives one of these various behaviors:

1. It just goes to the next line as if nothing happened.
2. It starts to read and locks up (I left it for a long while just to be sure).
3. I receive an I/O error.

I am unable to load the disk at all using the PowerPak, it locks up on the load screen.

I don't have a real floppy drive or RAM cart setup to test with, unfortunately.

(Very cool project, thanks for sharing!)

You are probably very aware of the screen flicker issue.
I had a look at this in Mesen2's event viewer and I can see why it has this problem. Your screen updates are frequently occurring outside of vertical blank. The PPU's VRAM can only be written to safely during blanking (vertical blank at the start of NMI, or forced blanking). During rendering, PPU accesses behave in an unpredictable manner as it is doing its own fetches to draw the screen.

Unfortunately, this seems to be a symptom of much bigger problem - Your program logic does not appear to be synchronised with PPU frames in any way. A more sensible approach on this system would be to implement a Main & NMI handler thread, as recommended by NESdev Wiki:

• https://www.nesdev.org/wiki/The_frame_and_NMIs
• https://www.nesdev.org/wiki/NMI_thread