Full NTSC Emulation w/ NES pixel decoding (Integer-only)

[EMMIR]

Hi, I'm EMMIR (aka LMP88959).
I've written an NTSC emulator that supports NES pixel decoding and I would like to share it here since it might be useful for those of you who are writing NES emulators.
It is a software implementation written in C using integers only and has a fairly simple interface.



The implementation produces accurate voltage levels (measured by lidnariq and on the NESDev wiki) and creates a buffer of voltage levels (in IRE units). The IRE buffer represents the entire analog signal for a field so it includes the necessary VSYNC and HSYNC pulses along with color burst.
This implementation can also optionally render the (normally invisible) NES border.
Since it is a full NTSC emulation, noise and 'blacker than black' signals can interfere with the sync pulse detection and cause some interesting problems.


GitHub Link:
https://github.com/LMP88959/NTSC-CRT

Acknowledgements:
Thank you to the NESDev Discord server for help with the NES pixel decoder.
The voltages generated by the decoder match the voltages lidnariq measured and has on the NESDev wiki.
Thank you to Persune for helping with understanding NES pixel decoding and the effort they put in to add it to Mesen.

[L. Spiro]

L. Spiro

[psycopathicteen]

What types of LPF are you guys using?

[Dwedit]

Let's see some Blacker than Black with all emphasis bits set! (Which happens to work fine on my old CRT)

I think I once made a couple of Game Genie codes for SMB1 to do that.

[segaloco]

Wait so in the process are you actually producing a digitally sampled CVBS signal and then on the other end interpreting that into pixels at runtime? I've thought often about the idea of digital CVBS, like the video equivalent of some sort of PCM mechanism to store raw analog video data with high fidelity. Can't say I've looked into it recently, but I've thought about it more in the context of "raw" VHS rips that are then interpreted into the proper display based on interpretation of the resulting RGBHV through real decoding operations, not just population of a bitmap form information that would be living in the PPU memory or something like that.

Either way, awesome stuff, I love the idea of actually modelling analog video signals in a digitally sampled format. My research has suggested this would require bitrates far in excess of those we currently use for audio.

[Dwedit]

There's a device called the Domesday Duplicator that's designed to sample raw analog data directly from a laserdisc before it goes to any other chips, and it can create a higher quality capture than anything else.

Just wanted to bring it up because it seemed similar to the topic of directly generating an NTSC signal in digital form.

[EMMIR]

Wait so in the process are you actually producing a digitally sampled CVBS signal and then on the other end interpreting that into pixels at runtime? I've thought often about the idea of digital CVBS, like the video equivalent of some sort of PCM mechanism to store raw analog video data with high fidelity. Can't say I've looked into it recently, but I've thought about it more in the context of "raw" VHS rips that are then interpreted into the proper display based on interpretation of the resulting RGBHV through real decoding operations, not just population of a bitmap form information that would be living in the PPU memory or something like that.

Either way, awesome stuff, I love the idea of actually modelling analog video signals in a digitally sampled format. My research has suggested this would require bitrates far in excess of those we currently use for audio.

Hi, yes that's how I'm doing it, but the signal is approximated otherwise it would pose the issue that you mention in the last line of your comment.

The git repo has some .h/.c files for each video system, for example crt_nes.h/crt_nes.c generates an analog signal for an NES frame, and crt_ntsc.h/crt_ntsc.c generate television format NTSC video.

Then, in crt_core.c, this 'analog' signal generated from any of those system modules is demodulated independently, similarly to how a television would do so.

[EMMIR]

What types of LPF are you guys using?

https://github.com/LMP88959/NTSC-CRT/bl ... core.c#L84

It's toggleable in the code but either a simple/cheap FIR or a first order 3-band EQ filter.