Project NYDES - announcing a new FPGA emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

notyourdad
Posts: 16
Joined: Sun Mar 12, 2023 5:49 am

Project NYDES - announcing a new FPGA emulator

Post by notyourdad »

I'm excited to share a project I've been working on for nearly two years, an entirely new implementation of the NES built on a Xilinx Artix-7 FPGA. It's called Not Your Dad's Entertainment System (NYDES). It aims to be a cycle-accurate emulator. It reads directly from original NES controllers, so it has zero input lag. It generates video without a framebuffer, so it also has minimal video delay (maybe a few milliseconds). Finally, it is not constrained by an operating system, so it can never skip frames. This results in a system that feels like playing the real thing, but in 720p and without the random crashes from dusty, old carts. You can view the demo on YouTube.

By using all the awesome documentation produced by this community and by finding clarity in the forum discussions, I've been able to get the majority of NTSC games running on my prototype system. I've also been able to get it passing most tests.

At this point, the project is a prototype without a public code repository. I'd like to share what I've built for others to try, but I want to make it more accessible, i.e. to require minimal hardware and tools to set up. I am interested in producing a series of video lectures / coding sessions on building this system from scratch, including design alternatives for things like video, audio, and controller I/O, but I know such an endeavor will take months or years to produce. Please comment if you feel like you'd have some interest in this sort of content.

The NYDES is ripe for new feature development. It has a ton of potential to support NES game development, TAS tooling and content creation. It also has a lot of room for improvement with more diverse game support, better video and audio generation, etc. Even without any new features, it's already super fun to play.

The prototype system uses these specific components:
* Digilent Nexys A7-100T
* 1BitSquared PMOD DVI Interface, the 24bpp-DDR version - for HDMI video output
* 1BitSquared PMOD Gamepad and Audio Kit - for connecting original NES controllers

The video footage linked above was captured with a Datapath VisionRGB-E1S card, and the audio was captured with an M-Audio Duo interface. The NYDES was running in a special 60Hz mode to avoid temporal resampling of NTSC flicker artifacts, and the video is best viewed on a screen with a 60Hz refresh rate to avoid recreating such artifacts. The NYDES normally operates in a mode that precisely matches the NES refresh timing, including the odd frame pixel skip.

A huge thanks goes to this community for making my fantasy project possible. As a little kid, I used to stare at the edge connectors on the bottom of NES carts and wonder how they got all the little pictures inside. This project has thoroughly closed the loop on that childhood wonder. Thank you!
User avatar
Individualised
Posts: 310
Joined: Mon Sep 05, 2022 6:46 am

Re: Project NYDES - announcing a new FPGA emulator

Post by Individualised »

Awesome to see more FPGA implementations of the NES! Certainly an outstanding effort. It seems the sound is slightly inaccurate - Super Mario Bros. sounds a bit off to me, and Double Dragon 2 is missing one of its pulse channels. Which flashcart (if any) did you use for the video, and which flashcarts are compatible? Are there any known incompatible mappers or features?
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Project NYDES - announcing a new FPGA emulator

Post by Memblers »

Nice work. I did notice audio issues too, seems like the Technos, Sunsoft, and Tecmo games are usually missing a sound channel. And in the Castlevania intro, the triangle channel notes play too long (it's using the linear counter there, I think?).
notyourdad
Posts: 16
Joined: Sun Mar 12, 2023 5:49 am

Re: Project NYDES - announcing a new FPGA emulator

Post by notyourdad »

Individualised wrote: Sun Mar 12, 2023 11:50 am It seems the sound is slightly inaccurate - Super Mario Bros. sounds a bit off to me, and Double Dragon 2 is missing one of its pulse channels.
The sound leaves a lot to be desired. I'd like to implement it with a proper external circuit employing several DACs and filters. Currently, it's just generating audio with a poor man's 1-bit pulse density modulation setup through a simple low pass filter. The 60Hz implementation (used for video capture) also introduced some high frequency artifacts (rhythmic pops and clicks) in some games. It works by brute-force pausing the CPU, APU, and PPU while the HDMI video circuit "catches up."

As for the missing sound channels you and Memblers mentioned, I'll need to investigate what the cause may be. Generally, the APU passes all the tests I could find for it, but it may have some edge cases that end up muting the output or otherwise counting something wrong.
Individualised wrote: Sun Mar 12, 2023 11:50 am Which flashcart (if any) did you use for the video, and which flashcarts are compatible? Are there any known incompatible mappers or features?
Game ROMs are directly embedded into the bitstream file that's used to initialize the FPGA on boot. I want to build a circuit for loading ROMs from an SD Card, but that's a significant sub-project (especially reading a file system with no operating system). Generating a new bitstream for each test or game is a little slow and painful, but it's been sufficient for development and debugging purposes. In other words, it doesn't support using any kind of flashcart.
Individualised wrote: Sun Mar 12, 2023 11:50 am Are there any known incompatible mappers or features?
The project supports what I think are the most important features - all CPU instructions (both official and unofficial), all APU and PPU features, including a few bugs like sprite overflow. It only supports two controllers, and the external controller interface circuit I'm using probably precludes supporting any of the "exotic" controllers. The design currently does not account for mappers that mix in additional audio. It also does not currently support bus conflicts in mappers.

Right now, eight mappers are supported: NROM, UxROM, MMC1, MMC2, MMC3, CNROM, AXROM and BF909x. A lot of additional mappers are fairly simple to implement, but they haven't been my focus.

Thanks for your feedback!
notyourdad
Posts: 16
Joined: Sun Mar 12, 2023 5:49 am

Re: Project NYDES - announcing a new FPGA emulator

Post by notyourdad »

Memblers wrote: Sun Mar 12, 2023 1:05 pm Nice work. I did notice audio issues too, seems like the Technos, Sunsoft, and Tecmo games are usually missing a sound channel. And in the Castlevania intro, the triangle channel notes play too long (it's using the linear counter there, I think?).
I found one likely culprit. The APU frame counter was failing to generate one of the quarter frame ticks in both mode 0 and mode 1. I expect that fixing this will correct the legato bass notes in the Castlevania intro. I doubt I'll be lucky enough for that bug to resolve the missing channel issue, as the quarter frame tick only affects the triangle channel linear counter and the envelope counters. I believe that the triangle linear counter and envelope counter states are unobservable by software, which would explain why this issue didn't show up with any test ROMs.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Project NYDES - announcing a new FPGA emulator

Post by Pokun »

Nice to see more of these emulators.

How does its goals compare to other existing emulators such as Analogue and Mister? Will it support real cartridges? Mister does not.
notyourdad
Posts: 16
Joined: Sun Mar 12, 2023 5:49 am

Re: Project NYDES - announcing a new FPGA emulator

Post by notyourdad »

Pokun wrote: Mon Mar 13, 2023 3:59 pm How does its goals compare to other existing emulators such as Analogue and Mister? Will it support real cartridges? Mister does not.
Thanks for taking a look! I am only slightly familiar with MiSTer and the Analogue projects. To my understanding, they both use an Intel/Altera Cyclone V SoC at their core, which lets them run a lightweight operating system on a hard ARM CPU alongside the FPGA fabric. MiSTer uses modular hardware, and Analogue now provides a second FPGA for third-party emulator core development that can integrate with their provided systems (presumably for stuff like audio, video and controller I/O). Both aim to support multiple platforms.

My approach for NYDES was to emulate only the NES in FPGA fabric, not in a SoC with a hard CPU. I never had the goal of creating a commercial product. Rather, I just wanted to scratch the same itch that I think drives so many into new emulator development - that deep curiosity to understand it all and conquer it. When I began the project, I didn't know how much FPGA "power" would be enough, soafter weighing options with my limited understanding, I chose the Digilent Nexys A7-100T, because my calculations told me it should be able to fit at least some early NES titles in its block RAM. It also had the bonus of having 128 MiB of DDR2 SDRAM on the development board and a whole bunch of other handy I/O peripherals, including 5 "PMOD" ports for easily connecting expansion circuits. I had no idea how or whether I'd be able to use those features, but they've proven quite useful. When I bought my board, it wasn't quite as expensive as they've become now ($270 vs. $350). Finally, I had also dabbled with a Xilinx FPGA in my undergraduate studies, so my vague recollection of familiarity was helpful in choosing it over other platforms like Altera.

I really wanted to support HDMI video output with NTSC emulation, per the wiki documentation, so I bought two PMODs from 1BitSquared, one 12bpp (4096 color) DVI board, and one 24bpp DDR (1.67 million color) DVI board. I then developed basic video output circuits. I was able to get 1080p video working with the 12bpp board, but I could only get the 24bpp board to max out at 720p. I proceeded with the 24bpp board, because improved color accuracy felt like the better choice, and 720 vertical pixels is a nice multiple of the NES' 240 line output. I continued by implementing the basic NTSC algorithm. It was a big challenge, and I learned a lot about FPGA DSPs along the way.

I also wanted to support original NES controllers, rather than some kind of wonky feeling USB controller. So again I found a PMOD made by 1BitSquared that provided the 3.3V to 5V conversion circuitry along with a breakout board for soldering on aftermarket NES controller ports. Once I finally got deep into building the NES component circuits, I was able to use that PMOD board to strobe and read bits serially from the controllers on demand when the joypad registers are accessed by software.

At this point, my goals for the project are pretty wide open. It needs some more basic features like loading games from external storage (probably SD Card), supporting battery-backed ROMs and providing save states. It could also easily support more mappers, and with moderate effort, it should be able to run PAL games. Audio and video can also be improved a lot. Beyond those, I think the sky is the limit. I think it could be the core of an awesome NES development environment, a TAS tool and a great alternative for content creators who want to capture NES gameplay.

I've investigated interfacing with real carts, and in theory, I think it's doable. A big issue is the relatively high pinout. This development board has 40 general purpose I/O pins available (through PMOD ports), and I'm already using 24 pins. Perhaps an external circuit with high-speed serial-to-parallel shift registers could be read or written in order to interface with carts, along with some controller circuitry. Aside from general signal control, the main trick would be to minimize the time used up by the FPGA in order to get ROM in the carts to respond in time to keep up with CPU and PPU requests. In the reverse configuration, this FPGA board might also be used like a flashcart or a devcart with a huge potential for unique features.

As for now, the system is just really fun to play. My childhood muscle memory never feels cheated by timing that's just a little bit off. I would love to figure out how to share this with more enthusiasts!
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Project NYDES - announcing a new FPGA emulator

Post by lidnariq »

notyourdad wrote: Mon Mar 13, 2023 7:02 pm and 720 vertical pixels is a nice multiple of the NES' 240 line output.
It's worth pointing out that real NTSC SDTV CRTs don't display all 240 scanlines - some gets lost off the top and bottom - and many games rely on being able to conceal glitches there.

Of course, that doesn't help in the face of pixel clock problems...
notyourdad
Posts: 16
Joined: Sun Mar 12, 2023 5:49 am

Re: Project NYDES - announcing a new FPGA emulator

Post by notyourdad »

I've managed to solve the audio issues. I had expected the long triangle channel notes would be fixed by adding in the missing quarter frame clock tick. Indeed, that fixed it!

The missing audio channel in games from Sunsoft, Tecmo, Technos, and at least the Double Dragon games was square channel 1. I got caught out by a subtlety in the sweep target period that might warrant a clarifying edit to the APU Sweep document. The issue I ran into is that square channel 1 uses one's complement for negation, while square channel 2 uses two's complement. In my interpretation, setting the negate flag with a shift count of 0 will end up generating a target period of -1 (in 12-bit two's complement) for any timer value. My circuit treats bit 11 as overflow, so the sweep unit mutes the pulse channel in this case.

Square channel 2 doesn't have this problem, because two's complement negation will always calculate a target period of 0. For example, if the current timer is 200, and the shift count is 0, we'll get a target period of

Code: Select all

0xfff & (200 + (~200 + 1)) // result is 0 
However, for the same values with channel 1, we'll get:

Code: Select all

0xfff & (200 + (~200)) // result is 0xfff, i.e. 12-bit -1
I had to modify my circuit to force the target period to 0 when negate is set and the shift count is 0. Other values for the shift don't cause a problem, because they always result in positive target periods.

Perhaps the documentation for calculating the target period could explain this like:

1. A barrel shifter shifts the pulse channel's 11-bit raw timer period right by the shift count, producing the change amount.
2. If the negate flag is true the change amount is made negative
3. If the negate flag is true and the shift count is 0: The target period is 0. Otherwise, the target period is the sum of the current period and the change amount.

Tomorrow, I'll see about posting an errata video to demo the fix for some of the affected games.

[Edit: changed "APU Pulse" to "APU Sweep" and updated the link to reference the correct section of the documentation]
Last edited by notyourdad on Tue Mar 14, 2023 6:19 pm, edited 1 time in total.
notyourdad
Posts: 16
Joined: Sun Mar 12, 2023 5:49 am

Re: Project NYDES - announcing a new FPGA emulator

Post by notyourdad »

lidnariq wrote: Mon Mar 13, 2023 8:11 pm It's worth pointing out that real NTSC SDTV CRTs don't display all 240 scanlines - some gets lost off the top and bottom - and many games rely on being able to conceal glitches there.
Indeed, I have the board set up with a toggle switch to turn off output for the top and bottom 8 NES scanlines (24 top and bottom in the 720p signal). Ideally, this would be tunable with some kind of UI like many other emulators provide.

You can see the toggle switches on the bottom edge of the board in this messy setup photo.
nydes-setup.jpg
All of the game footage from the YouTube demo video has this option toggled on.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Project NYDES - announcing a new FPGA emulator

Post by tepples »

lidnariq wrote: Mon Mar 13, 2023 8:11 pm
notyourdad wrote: Mon Mar 13, 2023 7:02 pm and 720 vertical pixels is a nice multiple of the NES' 240 line output.
It's worth pointing out that real NTSC SDTV CRTs don't display all 240 scanlines - some gets lost off the top and bottom - and many games rely on being able to conceal glitches there.
Likewise, a lot of HDTVs don't display all 720 or 1080 lines of the signal either because they are configured out of the box to display broadcast and cable TV video, which by convention is formatted for early-adopter 1080i CRT HDTVs. See "HDTV Overscan" on How-To Geek.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Project NYDES - announcing a new FPGA emulator

Post by Pokun »

Yeah my LCD does exactly that, with no option to adjust how much you want to cut out either. My friend with a more modern TV can choose how much is to be cropped.

My CRT is set in a way that it shows some slight overscan in NTSC mode, but NES games are highly inconsistent in where they keep their garbage and where they show important information, so some games has a lot of artifacts while other games have a barely visible status bar.
Mega Drive games shows some CRAM dots sometimes (like the Langrisser title screen).


Thanks for explaining. It's indeed a very interesting project.
I suppose systems like the Mister needs some sort of interface to set various options and for choosing which core to start and the ROM/software to run on the core. But I assume this could cause similar hot boot problems that flashcarts tends to have when chain-loading the ROM from the flashcart's firmware menu. Although it's not exactly the same, as the core is probably booted in a way that simulates a cold boot.
So for such reasons it's interesting if you can boot a ROM in an authentic way more like a real NES.

Also I heard the Analogue has problems with many peripherals like the Turbo File II.
notyourdad
Posts: 16
Joined: Sun Mar 12, 2023 5:49 am

Re: Project NYDES - announcing a new FPGA emulator

Post by notyourdad »

Fortunately, my main testing TV has been forgiving for all of my development work. It's a Sony Bravia from about 10 years ago. It was tolerant of some wildly out-of-spec signals during the early stages of video circuit development. It lets you select from "full", "wide" and "wide zoom" modes. It also has a "game mode" to turn off all image processing like motion smoothing, noise reduction, etc., which presumably lets it operate without buffering any frames. I wish I could find good information about processing delay in modern TV models, but none of the manufacturers seem to be forthcoming about those specs. I'd be interested to hear if anyone knows about a project testing such delays.

I've also tested the NYDES on an LG monitor that I use for my PC dev box. It's a fairly new 2K (1440p) monitor. The TV and monitor were both happy to display the NYDES video signal, which skips several pixels (from 0 to 40) when entering the first line of the vertical front porch. The skip is used to "catch up" to the PPU when the alternating frame pixel is skipped. The clock ratios between the PPU and video circuit cause the skip pixel count to drift slowly over time, as the video clock has to run just a tiny bit slower than what's required for the ~60.09848Hz framerate when the NES is not skipping any alternate frame pixels. Otherwise, it would race ahead of the PPU's output!

The VisionRGB capture card was much more fussy about the video signal, and I had to rework the timing of the clock signal with respect to the enable, sync and data signals to get it to work. The video signal is generated using a clone of the TI TFP410 chip, if you're curious to see what's involved. I'm using the DDR mode to get 24-bit pixel depth with minimal output pins. The video clock normally runs at 74.37107MHz, which means data is sent to the DVI chip in DDR mode at 148.74214MHz. It's definitely pushing the PMOD output pins past their documented limits for reliable signals (about 40MHz).

As noted briefly before, I also implemented a special mode for temporarily pausing the NES clock ticks to allow the video output to run in a precise 60Hz mode, while still preserving the behavior of dot skipping on alternating frames. This is the mode I use for capturing web-ready videos that show the NTSC artifacts correctly (at least when viewed on a 60Hz refresh monitor). It requires reducing the NES master clock by a tiny fraction and skipping up to ~60 master clock cycles. For reference, the CPU gets a tick every 66 master clock cycles, i.e. the master clock is normally 118.125MHz.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Project NYDES - announcing a new FPGA emulator

Post by creaothceann »

notyourdad wrote: Tue Mar 14, 2023 6:12 pm I wish I could find good information about processing delay in modern TV models, but none of the manufacturers seem to be forthcoming about those specs. I'd be interested to hear if anyone knows about a project testing such delays.
https://www.rtings.com/tv/tests/inputs/input-lag
https://www.hdtvtest.co.uk/news/input-lag
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
notyourdad
Posts: 16
Joined: Sun Mar 12, 2023 5:49 am

Re: Project NYDES - announcing a new FPGA emulator

Post by notyourdad »

These are really helpful. Unfortunately, my TV (Sony KDL55HX750) is too old to appear in these tests. But this totally gave me an idea on how to measure the input lag with an FPGA! I'll post about that project idea if I manage to bring it to fruition in the coming weeks.
Post Reply