Emulation Description Language + NTSC Composite

Emulation Description Language + NTSC Composite
by SavourySnaX on 2012-01-15 (#88874)

Hi all,

I've been reading this site with great interest over the last month or so.

In my spare time, I've been working on an emulation description language (although to be fair its more of a cpu description language).

I have written i8080,z80,6502,6510 and begun an rp2a03 && rp2c02 core (yes the last one is not a cpu - more on this later). The difference between my emulation and others is that I emulate the pins. Which means interaction with the cpu cores involves feeding data onto the chips pins themselves. this allows nice tricks like (from i8080 core):

Now as you can guess I've decided to play with NES emulation, but I`m trying to be different (aren't we all), and so I have been playing with CRTSIM (which is a program that reads NTSC composite(ish) signals and produces a display from them - not written by me, but google crtsim and you will find it).

At present I haven't got very far - the rp2a03 core is basically the 6502 core I wrote, with the bcd stripped out and a dma emulation put in. I had a crack at getting the rp2c02 to generate composite video signals this weekend - the below is where i've got to so far.

There is a lot of corruption (if i disable the colour parts its cleaner - so the corruption is probably my colour clocks being wrong), also the brightness is reduced from what it should be.

The emulator at present is dumping out an .ntsc file, which i then feed into crtsim and get a nice movie.

I hope to make some more progress next week and sort out the colour, but i thought (even broken) it might be of some interest.

My homepage has lots of details about EDL. Nothing NES or CRT related posted yet, I want to get things a bit more stable first.

Homepage : http://savourysnax.github.com/EDL

by clueless on 2012-01-15 (#88883)

This project kicks ass. +1

by tokumaru on 2012-01-15 (#88887)

Interesting idea. I always wanted to see the NES simulated like that... The approach of emulating the individual chips is perfect for the NES because of the insane amount of mappers it uses... If each mapper is emulated as its own chip(s), we could easily add new ones without messing with the CPU and PPU.

Sorry if I can't be of any help though... I'm not much of a hardware guy, and I certainly don't know anything about NTSC signals! =)

by RLError on 2012-01-15 (#88890)

SavourySnaX... are you the same person who worked on SNEeSe?

This is awesome, by the way.

by SavourySnaX on 2012-01-15 (#88892)

RLError - yes. That was a long time ago, Charles did exceptional work after I moved on. Those were the days

tokumaru - the intention is to provide the external cart connector signals and then have a file to describe the cartridge format. The details on this are sketchy at present, I almost want it to be a circuit diagram, but at present I still use C to link chips together.

Thankyou all for the encouragement.

by byuu on 2012-01-16 (#88925)

SavourySnaX wrote:
RLError - yes. That was a long time ago, Charles did exceptional work after I moved on. Those were the days :)

Woooow, had no idea you were still around. Back in '98 or so I offered to try and port some of SNEeSe' code over to C and failed miserably (to this day I can barely understand AT&T syntax, heh.) I was quite envious of your project back then.

And yeah, Charles ended up helping me out quite a few times. He was great at taking technical specifications and deducing how hardware must work within those constraints, especially for the PPU. It's a shame he's not still involved in the SNES scene. We're unlikely to ever fill his and anomie's shoes.

Quote:
Which means interaction with the cpu cores involves feeding data onto the chips pins themselves.

That's really cool, I love seeing new ideas like that. Will be very interesting to see how performant you can get this model.

Are you going to treat it as a perfect digital logic, or are you going to support the analog raises and drops that you often see on oscilloscopes of the real hardware?

Quote:
If each mapper is emulated as its own chip(s), we could easily add new ones without messing with the CPU and PPU.

I do that now. My NES CPU/PPU have no concept of mappers at all. It only gets a bit tricky because things like MMC5 interrupts aren't fully understood (I detect it by looking for the two dummy nametable reads.)

All you really need there would be: clock source (you can send one tick per NES CPU cycle if you want) that can set audio mixout value and signal an IRQ to the CPU, PRG read/write, CHR read/write.

by tepples on 2012-01-16 (#88927)

Because if you want to emulate the Zapper and the Vaus controller accurately, especially the "X AND Y COORDS" of Zap Ruder, you'll need at least something analog.

by SavourySnaX on 2012-01-16 (#88928)

Blimey - I didn't realise so many people would remember me. I've been out of the emulation scene for a long while now, but tinkered around with various things in my own way.

'98 - I do remember the C port being done (I`m afraid my memory is a bit poor), didn't realise it was you. I have to say the work you have done on bsnes is awesome.

As far as perfect digital - EDL is pure digital for now.

Anyway, I managed to put the correct timebases through and generate a new image - no more corruption in the colours, but I think i may still need to tweak something more

Strangely I seem to have to knock the colour phase out by 4 cycles to get close to the correct colours (based on the NTSC timings on the wiki).

so colour burst is 8. colour from palette needs + 4 to its phase index. I need to have a think....

by tokumaru on 2012-01-16 (#88936)

byuu wrote:
I do that now. My NES CPU/PPU have no concept of mappers at all.

Cool! I'd love to see it in action (even though I won't be able to spot anything different from a regular emulator! ).

by infiniteneslives on 2012-01-16 (#88937)

I really like the idea of emulating at the pin level. Technology like this could actually allow for bringing old hardware back to life. So is there any thought to being able to slap the 2a03/2a02 on a FPGA with some sort of breakout board that could allow you completely replace a burnt out CPU/PPU on the original motherboard?

I doubt it would really be worth the expense currently as the console it's self is fairly cheap to replace entirely, and not much cheaper than a FPGA. But this might not be the case once we all get old and grey, once they start to die off and sizable programmable logic costs pennies. Of course they won't be 5v at that time either, but that's what level shifters are for.

by tepples on 2012-01-16 (#88946)

At that point, kevtris's idea of making the whole d███ console on an FPGA starts making more sense.

by SavourySnaX on 2012-02-01 (#89465)

Been a while since I posted.

Since last time, I've enlisted the help of someone at work, who has kindly offered his services to write a tv emulator that sits within my nes framework (which saves having to switch to crtsim to check the video signal).

The original nes emulator was a pin accurate CPU core and some C code mashed into the shape of a PPU. Since that post, I've now re-written the PPU core into EDL, and moved the clock dividers into the respective chips. In the process upgrading the compiler and adding support for some of the features it still lacks.

The screenshot below is squashed, the link below it - will take you to a full res version. The NES window is a traditionally emulator view (without fancy post processing). The NTSC window is obviously the TV emulation (apologise for the darkness - its not the tv emulators fault - The signal I'm feeding is still not quite to spec).

The logic analyser is currently probing the composite video signal along with the DBE pin on the PPU and the M2 clock on the CPU.

For full resolution click below :

http://savourysnax.github.com/EDL/images/nes.png