Stella!
September 19, 2010 10:27 PM   Subscribe

Similar in concept to the ICU64 (Previously), Visual 6502 is a transistor-level simulation of the MOS 6502 chip (Wikipedia). Here's a Javascript implementation. Very processor intensive, doesn't work in IE. posted by griphus (17 comments total) 19 users marked this as a favorite
 
That's amazing.
posted by empath at 10:59 PM on September 19, 2010


Eventually Peddle was sent an official memo from management telling him to stop working on the low-cost design. In response, much of the original 6800 design team resigned en masse and went looking for a company that would be interested in building their new design.

Sounds like the kernel of a very geeky movie plot.
posted by pracowity at 11:08 PM on September 19, 2010


I remember writing a little assembly to calculate the digits of a new mersenne prime on my 6502 - it was something like 65050 digits, quite a lot for an Apple II+ to work on. It ran for something like 40 hours. I wonder if I have the code around somewhere to try on this... it will probably take years and years to run..
posted by DreamerFi at 11:46 PM on September 19, 2010


I did some 6502 (well, 6510) assembly hacking on the Commodore 64 to get better-than-BASIC speed in important loops. I'd rather be hacking in assembly than any of this new-fangled SDK stuff, harumph harumph.

This also brings back memories of the Computer Architecture class I took back in college. I designed a 4-bit multiplier almost entirely in my head for the class project, a feat I'm still rather proud of today.
posted by JHarris at 2:07 AM on September 20, 2010


BTW, from the FAQ:
Descendants of the 6502 and the chips it influenced are sold today in quantities of hundreds of millions annually. It was a strong influence in the development of the ARM architecture.

The NES, Nintendo's first console, ran on a variant of the 6502. The SNES ran on a 16-bit update of the chip. (The chip was only about three-and-a-half times faster, which is one of the reasons slowdown was a problem on it; the Genesis had a CPU that was twice as fast but had worse sound and graphics.) The GBA has one of those ARM chips mentioned above plus a Z80 (the processor in the Gameboy and Gameboy Color). The DS has a Z80 (for compatibility with the GBA), an ARM7, and an ARM9.

In other words: A substantial portion of Nintendo's consoles and portables depend on the 6502 architecture, including systems they have in production today.
posted by JHarris at 2:13 AM on September 20, 2010 [2 favorites]


Yeah, this is great.
From the faq:
While a multitude of people understand the instruction set for the 6502, almost no one, apart from the original designers, understands how the physical chip achieves this instruction set. The design is as elegant and sophisticated as any program written for the 6502. As digital archaeologists, we invite the current generation of hardware and software engineers to appreciate the work of the small number of designers who created the basis of everything we do today.
posted by memebake at 4:23 AM on September 20, 2010


JHarris: "The DS has a Z80"

That's mind-boggling - the same chips that were in the Radio Shack TRS-80s in 1979 are in the DSes of 2010. Almost as mind-boggling as the fact that the transistor-level emulation of a one Megahertz chip slows down today's multi-Gigahertz machines.

I get that doing things in a browser's javascript sandbox can involve a lot of abstraction and interface with a lot of code layers, but perhaps someone can explain in more detail why transistor-level emulation is so much more work-intensive than emulating a CPU, memory system etc.?
posted by Hardcore Poser at 6:33 AM on September 20, 2010


but perhaps someone can explain in more detail why transistor-level emulation is so much more work-intensive than emulating a CPU, memory system etc.?

Many chips have a core set of essentially identical instructions. For example, just about every chip has an ADD instruction. So in an emulator, when you come across an ADD instruction, all the emulator has to do is execute a similar ADD instruction directly on the host machine and plug in the result. That takes about a single clock cycle on the host machine. In fact, with pipelining and other techniques, the emulator may be able to cram more than one such instruction into a single host clock cycle.

But with transistor level simulation, the simulator has no sense of 'instructions.' Instead, it's propagating voltages across (virtual) circuits. So an ADD instruction actually becomes a simulation of the multiple circuits involved in the Fetch-Decode-Execute cycle. This takes many, many clock cycles on the host machine to simulate. With JavaScript and graphical output involved, it likely takes a few orders of magnitude more clock cycles, in fact, because the simulator is also drawing the active circuits using JavaScript's slow graphics routines.
posted by jedicus at 7:16 AM on September 20, 2010 [4 favorites]


Nit-pick - I think this is actually a gate-level simulation, not transistor level, but still very impressive nonetheless
posted by kcds at 7:51 AM on September 20, 2010


This is definitely a very, very simplified gate-level simulation. There's no way the average desktop or laptop could process the saturation models of all the on transistors, subthreshold models of the off transistors, manage all the secondary effects like channel-length modulation and the terminal capacitances of every device and show the results in real-time.

Digital guys have it easy.
posted by tylermoody at 8:25 AM on September 20, 2010 [1 favorite]


It's pretty incredible, particularly the Javascript version. The Python version is running at 27Hz, or just about 1/40 the speed of an Apple ][. That's pretty good.

Part of what makes it nutty is they started with photographs of the masks. And scanned it, and fixed the mistakes. Presumably the source files for the masks are available for a lot of processors, locked away somewhere inside a company vault.
posted by Nelson at 8:27 AM on September 20, 2010


The DS has a Z80 (for compatibility with the GBA), an ARM7, and an ARM9.

Do you have a cite for that? I don't think the DS has a Z80. It's not capable of playing GB or GBC games. GBA games play off the ARM7.
posted by East Manitoba Regional Junior Kabaddi Champion '94 at 8:32 AM on September 20, 2010 [1 favorite]


Presumably the source files for the masks are available for a lot of processors, locked away somewhere inside a company vault.

If you read their SIGGRAPH presentation [5 mb pdf], part of the point is that a lot of these very early chips were designed by hand on grid paper. There often is no digital source at all. The entire production process was analog. In other cases, the sources have been lost. This is, as they say, digital archaeology.
posted by jedicus at 8:43 AM on September 20, 2010


I think this is actually a gate-level simulation, not transistor level,
...
This is definitely a very, very simplified gate-level simulation.

Fair enough. My point about the massive difference in efficiency between simulation and emulation stands, even if what they're simulating are logic gates instead of bare circuits. For example, an 8-bit add involves dozens of gates, each of which takes an instruction to simulate if you do it directly. Compare that to executing an equivalent ADD instruction on the host machine.
posted by jedicus at 8:47 AM on September 20, 2010


Hmm.... On second thought, I think I'm wrong about the DS having a Z80. I think they removed it since GBA games don't get access to it so it doesn't matter to running those games.

My error, sorry about that.
posted by JHarris at 11:19 AM on September 20, 2010


The Python version is running at 27Hz, or just about 1/40 the speed of an Apple ][.

You are off by a factor of 1000. 27Hz is 1/40000 the speed of the Apple II.


While this is very impressive, it's kinda "easy" to do because the gates are digital, which means stuff like varying voltage and timing can be pretty much ignored. If you want to take it to another level, there's emulating chips with analog components.
posted by ymgve at 11:24 AM on September 20, 2010 [2 favorites]


Ah, East Manitoba Regional Junior Kabaddi Champion '94 caught it.

Here is my understanding of the chips, on further reflection and memory. None of this is newly researched so could be incorrect, but my memory is usually pretty good about these things:
The GBA doesn't have access to the Z80, it's kept powered off when the GBA is in GB mode. If I remember right now (this is why I use those words a lot), there is an actual hardware switch on the GBA that is depressed by GB and GBC cartridges when they're in the slot which switches the system into GB mode. (Or,

The base DS has GBA compatibility, which it can achieve somewhat easily because it has all the GBA hardware in it. The DSi and later revisions do not, but because the DS uses the GBA hardware as part of its functioning (unlike the Z80 in a GBA) it has to include an ARM7 and the GBA graphics hardware. That's no big deal. But if later games include DSi compatibility they'll end up including all the stuff in a GBA as well, since the hardware isn't locked off.

However, this isn't true, again if I remember correctly, if the GB sound hardware. The GBA uses the GB sound hardware, so the DS has to include it, or a chip that provides its functions. I'm not sure if the DS has access to it in DS mode; if it does, then the DSi and all later revisions that can play DS games must also include it, or some software recreation of it that might not be 100% compatible.

All these things are a result of how serious Nintendo is about backwards compatibility. Unlike the Xbox 360 or later revisions of the PS3, Nintendo's systems achieve it purely through hardware means. (Virtual Console on the Wii is an exception, although not really since it doesn't use the physical hardware of the old systems.) It also reveals the reason behind design decisions that seemed a bit strange at the time, like preventing GBA games from accessing the GB's Z80. If they hadn't, then they would have had to include a Z80 in the DS, and then the DSi, and the 3DS....
posted by JHarris at 11:37 AM on September 20, 2010 [1 favorite]


« Older The Black Ivy   |   Art Without Asking Newer »


This thread has been archived and is closed to new comments