Transistor level VCS emulation

[theor]

Hi everyone! After reading Racing the Beam a few months ago, the VCS started to captivate me and I got more and more interested in its hardware and its emulation, which eventually led me here.

 

The fact that the VCS games run so close to the metal essentially means that the emulator has to be cycle accurate, what some would call low level emulation. Yet despite its cycle accuracy, even the most accurate emulators such as Stella simulate the expected results and not the actual physical/electrical behavior of the circuits, like a SPICE engine or the DICE emulator do for old TTL arcade games.

This means the emulator has to be programmed to mimic all corner cases and catch up as they are found. It couldn’t expose a hardware bug by itself, or help discover a hardware trick like the HMOVE strobe (I suppose). It can only be programmed to mimic these artifacts once discovered on the real thing.

 

While emulating at transistor level is completely out of question for more complex hardware such as the NES - yet it has been attempted and there are working prototypes - I suspect this could be done in real time for the VCS.

The 6502/7 is only made of 3500 transistors, the TIA has 6193, the RIOT probably in between. That’s a likely total somewhere south of 15000 transistors, intimidating but for comparison, the NES PPU alone has more than 16K transistors, disregarding all its other chips. Plus the schematics are available and documented for each of the VCS chips so there's little to no reverse engineering required.

 

If horsepower would really happen to be an issue, then maybe :

- we could discard the real time approach and only emulate at the hardware level as a slow-motion debugging mode

- a hybrid approach with a traditional high level 6507 emulation and low level TIA emulation could be used (maybe as an optional engine in Stella)

- the emulation could happen a bit higher, at the logic gates level, so there's less circuit to model

 

Granted, a circuit level emulation wouldn’t be useful for perfect accuracy for a 3rd gen console like the NES since the hardware is much more abstracted and you get a framebuffer, so even the cycle accuracy isn’t vital.

But for a VCS, I suspect it could help finding, debugging and testing new hardware tricks right on his laptop without the need for a Harmony cart on the real thing, something even a real VCS couldn’t do unless there were logic probes on the chips and the ability to set breakpoints.

 

What do the pros here think? Could this be a worthy? I’m not a developer and wouldn’t be able to help much on the code if it happened, but I wanted to discuss this in case it could be an idea.

 

Further reading, including some transistor level 6502 and NES PPU emulation:

http://www.visual6502.org/JSSim/

https://github.com/trebonian/visual6502

https://github.com/SourMesen/VisualNes

http://www.qmtpro.com/~nes/chipimages/visual2c02/

https://hackaday.com/2014/12/18/counting-transistors-in-the-playstation/

 

[+stephena]

This has been discussed in the past, both for the 2600 in particular and for consoles/computers in general. There are several schools of thought on this, with some saying that cycle-exact emulation is enough.

 

Personally I agree with the 'cycle-exact is enough' camp. There are always lower levels of emulation one can go to, but at some point it reaches a point of diminishing returns (ie, we could simulate electricity running along a simulated bus, simulating the inner workings of a transistor, etc). There is a concept of going too far.

 

Stella is currently almost 100% cycle-exact for the TIA video hardware. And it does it not (solely) by considering expected results, but by looking at the hardware circuit and determining when and how various counters interact with each other. In fact, in developing this new code for Stella 5.0, many ROMs that never worked before suddenly started to work perfectly, as a result of emulating the behaviour of the circuits at a lower level. There is no longer anything in the code that tests for specific ROMs and does something based on how the ROM is behaving (so called ROM hacks). It is all being done by a cycle-exact low-level emulation of the original circuit.

 

Now, the current sound code isn't cycle-exact at all, and in some cases produces completely wrong output. This will be fixed in Stella 5.2 (or whatever we call it). In that case, the audio part of the TIA chip is being emulated at the cycle level, by considering the counters and pulses of the original circuit. And it produces sound that fixes ROMs that have never sounded correct in any other emulator.

 

Long story short, I think that while a transistor-level emulation of the 2600 could probably be done, I don't think it's really necessary at this point. I have my doubts that current hardware is fast enough for it (remember, it's not just number of transistors that matter, but also timing/synchronization between them). And I think that current emulators are getting to the point where cycle-accuracy is enough.

 

Of course I wouldn't try to discourage anyone from trying it; I just question its usefulness at this point.

 

EDIT: Also, DirtyHairy should weigh in on this WRT the current code in Stella/Stellerator. He has much more experience in this area.

[+stephena]

Also forgot to mention that emulating the 2600 at the transisitor level is no guarantee of perfect emulation either, since the original hardware had specific tolerances, etc, that are not readily apparent just by looking at the circuit. IOW, it's not just a matter of putting all the transistors together like they look in the circuit and automatically getting a 2600. Heck, over the years even many different TIA versions have differences, and they were all supposed to be created to be the same!

[DirtyHairy]

I think you underestimate the current level of precision of Stella's emulation engine As Stephen explained, it is a cycle-exact emulation of the various interacting counters that the TIA is built from, built on Andrew Tower's analysis of the TIA schematics, experiments and more inspiration from the schematics . On top, there is a certain amount of heuristics that come from experimentation (in particular regarding the detailed structure of the start field and the effects of RESx while a sprite is drawing), but those are also implemented in ways that are guided by the actual hardware, using the same counters. While no emulation is perfect (and there are and will always a few known issues), the current core emulates almost every ROM I know of perfectly, and none of the peculiar behaviors are put into the code ad hoc, but they arise naturally from the simulation model.

 

There are always ways to improve, and emulating the hardware at an even lower level might simulate some edge cases more naturally, but the bar is pretty high at this point. As an example, check out https://github.com/stella-emu/stella/issues/246--- a minor change in the current code to emulate the theorized differences between different TIA generations (the phase of the extra clock pulses that drive HMOVE) is abled to effortlessly emulate the resulting differences in certain edge cases almost perfectly.

 

In addition, I am not convinced that an idealized transistor level emulation of the TIA will emulate all edge cases correctly --- I think that analog effects (capacities, impedances, impurities in the clock) in the circuit are important in many cases (i.e. the starfield). In this thread there already was an attempt to reproduce the details of NUSIZ changes during player draw with a gate level emulation of corresponding part of the TIA by Joe Musashi. If I remember correctly, that gate level emulation wasn't able to capture all effects, either. All of those testcases now emulate correctly in Stella after we added a heuristic description of NUSIZ during draw based on experiments (https://github.com/stella-emu/stella/issues/63). There also were efforts of the visual6502 project to scan a decapped TIA and recreate it in a simulation. Initial results have been floating on the web for a couple of years now but, unfortunately, there is no analysis of the accuracy or public code available.

 

Don't get me wrong, I don't think there isn't potential for improvement (and there are some obscure things that I would love to be clarified by a more detailed simulation), but I am not convinced that a transistor level simulation is the appropriate tool for this (I don't even think it will be more accurate than the current core). I would be thrilled to see it and analyze the results, though I should also add that I don't think there are many *reliable* (i.e. stable between TIA generation) tricks left to be discovered, other than cleverly timed applications of known mechanisms.

Edited June 11, 2018 by DirtyHairy

[DirtyHairy]

I found the visual6502 TIA stuff: http://blog.visual6502.org/2014/10/atari-2600-simulation.html

 

Evidently, I was wrong, the source is available, but unfortunately, the last version is four years old. The pitfall screenshot exhibits some HMOVE issues --- it would be interesting to find out whether they ever found the issue.

[theor]

Thank you both for chiming in.

 

Actually I wasn’t aware that Stella v5 used physical modeling and thought it still used rom hacks. This is exactly what I wanted to address, and given this false assumption this makes most of my post somewhat irrelevant.

 

I wasn’t expecting to simulate the flow of electrons in semi conductors. My idea for an emulator was to have something akin to Verilog as an engine, I’m not sure if that has ever been attempted for low to average complexity circuits like found on the VCS.

 

DirtyHairy has a point, at such a deep level of emulation, other effects such as impedance mismatches, propagation delays, components aging should also be modeled, which would consume a large amount of power for little benefits.

However I thought this may also be the point because low-level emulation brings the most return for analog circuits simulation.

 

Besides game consoles, I’ve seen LLE successfully used on analog modeling software synthesizers, which are able to replicate the sound of electronic analog instruments much more accurately by modeling their circuits, especially oscillators, transistors and capacitors, instead of using pre-made wave tables from their sound waves (which sounds a little sterile) - at the cost of a lot of CPU usage, obviously.

 

The VCS is a special beast because despite being digital, there’s so little abstraction that I feel safe saying the analog non-linearities of its circuits matters more than on later hardware, so I thought there might be some accuracy to gain here. I think you proved me wrong with Stella v5, the links you posted were very insightful in that matter.

 

By the way, I admire your coding skills, the both of you.

[theor]

I found the visual6502 TIA stuff: http://blog.visual6502.org/2014/10/atari-2600-simulation.html

 

Evidently, I was wrong, the source is available, but unfortunately, the last version is four years old. The pitfall screenshot exhibits some HMOVE issues --- it would be interesting to find out whether they ever found the issue.

 

Great find! A comment suggests a phase offset between the 6507 and the TIA as the cause of an artifact in Pitfall.

 

I see there's a plan to port their Python code to C++, which would help the framerate quite a bit. Too bad they didn't go past v0.1. I feel like dropping them an email.

[+stephena]

I should also add that the upcoming TIA sound core is based on a Verilog implementation done by Chris Brenner. He basically took the circuit for the audio portion of the TIA and implemented it in Verilog. Then he converted it to C code, which I converted to C++, and after much refactoring by DirtyHairy, added it to Stella. It properly emulates the circuit, down to the counters/pulses and even the resistor ladders.

 

This properly emulates the analog 'interference' between the sound channels, which are most apparent in Ms. Pacman. And it allows to properly generate sound in E.T. for the first time. So from that POV, we already have a cycle-exact sound emulation too, that takes analog factors into account.

[DirtyHairy]

I should also add that the upcoming TIA sound core is based on a Verilog implementation done by Chris Brenner. He basically took the circuit for the audio portion of the TIA and implemented it in Verilog. Then he converted it to C code, which I converted to C++, and after much refactoring by DirtyHairy, added it to Stella. It properly emulates the circuit, down to the counters/pulses and even the resistor ladders.

 

There's even more analog simulation in Stella: the paddle readout circuit

 

 

Great find! A comment suggests a phase offset between the 6507 and the TIA as the cause of an artifact in Pitfall.

 

I've read that one, too, but I don't think that this matches the artifacts seen in Pitfall: There are different shifts in different directions.

 

I see there's a plan to port their Python code to C++, which would help the framerate quite a bit. Too bad they didn't go past v0.1. I feel like dropping them an email.

 

If you ever get an answer, please post it --- I am curious about whether they got any further, too.

 

 

By the way, I admire your coding skills, the both of you.

 

 

Nah, don't, now I am blushing

[theor]

I haven't got any reply and don't think I'll ever receive one unfortunately, it looks like the devs moved along. I'll post their reply here should I receive something, or PM you if this thread has gotten too old to dig up.

 

BTW, there's actually a lot of people here whom I admire their skills. Yours and stephana's for the x86, asm and verilog related low-level emulation, but also Darrel Spice Jr, Thomas Jentzsch, John W. Champeau and all the 2600 homebrew programers. I'm still in awe when I see Star Castle Arcade, Super Cobra Arcade, Boulder Dash, and most impressively, Draconian. The latest 2600 homebrews feel like NES games, it's almost hard to believe.

[+stephena]

Just a followup to this. Stella 6.0 is now released, and includes the cycle-exact TIA audio implementation discussed above: http://atariage.com/forums/topic/286333-stella-60-released

[+Gemintronic]

What about putting this research towards more accurate 2600 FPGA cores? It seems like this is the future of classic hardware.

[Osgeld]

its the same thing written in a different way

[Keatah]

What about putting this research towards more accurate 2600 FPGA cores? It seems like this is the future of classic hardware.

 

I would guess since Stella is open-source there are no show stopping secrets. The research should be available to any 2600 core developer..?

[DirtyHairy]

What about putting this research towards more accurate 2600 FPGA cores? It seems like this is the future of classic hardware.

 

 

Everybody works on what they like to work on It's a hobby, after all. I don't really care about what people perceive as "the future", but I do in my spare time what I like to do, and what time permits. Besides, without intention to conjure up the unnecessary discussion software vs. hardware, I think there is a place for both. A FPGA can provide gate-level emulation in realtime + plug-and-play, while a software emulator can provide accurate emulation without requiring dedicated hardware, plus additional tooling (save states, debugging, time travel, etc.).

 

That said, I think it is safe to say that there was not much research involved for the major features of Stella 6.0 in the emulation domain. The biggest new addition is the cycle-exact audio code, which is entirely derived from Crispy's FPGA implementation, and all credit for the associated research goes to crispy. The challenge here was not related to hardware research, but to refactoring the code in a way that would permit the emulation core to run uninterrupted on a thread (in order to provide a steady stream of audio data).

Edited December 26, 2018 by DirtyHairy