nesdev.org

Has it ever been tested?

All accesses go through the internal state machine, it doesn't make much sense for it to work in some other way.
VRAM bus capture could easily tell how many accesses are possible. I imagine jwdonal can say a thing or two about it.

I hope replying is ok if I only read the first page and only scanned the rest. As Memblers said, there are several on the 6502. org fourm (http://forum.6502.org/) who are strong at programmable logic (FPGAs, which are field-programmable gate arrays, suitable for even making your own microprocessor, and CPLDs, complex programmable logic arrays which are a step down but can do a lot more than say a PAL). A few members are very strong at video, the first one coming to mind being Oneironaut (see this topic of his with lots of pictures and links to videos of his builds using off-the-shelf 74HCxx logic), and someone (I can't remember who at the moment) is reverse-engineering the SID. There is someone also selling the SwinSID (I hope I got the name right) which mimics the Commodore SID. Others have their especially strong points, like algorithms (member dclxvi and others), OSs (member kc5tja, TMorita, and others), Forth (Dr. Brad Rodriguez who's a big man in the Forth world), etc.. Unfortunately our resident arcade man, Nightmare Tony, died four years ago with cancer, in his 40's; and Lee Davison who wrote the excellent EhBASIC and was also on the forum died a few years ago, also not very old. I don't know much about video myself, but I have a 6502 primer about many other aspects of making your own 6502 computer, at http://wilsonminesco.com/6502primer/index.html .

Oneironaut (mentioned above) plans to use my large look-up tables for fast 16-bit scaled-integer math (including mult, div, trig, log, square root, and others) which, in the extreme cases, make looking up math functions nearly a thousand times as fast as having to actually calculate them, and you'll have all 16 bits correct, not needing any interpolation, because all the answers are there, pre-calculated. Do that with a maximum-speed 65816, and you'll have math performance that's thousands of times as fast as the Apple II.

The 65c02 and 65816 are very much in production today, actually being made in huge volumes (over a hundred million units per year today, yes, >100,000,000/year), although they're rather invisible, being at the heart of custom ICs made for automotive, industrial, appliance, toy, and even life-support applications, the fastest ones running over 200 MHz. Western Design Center (WDC) is the IP holder, and they make most of their money from licensing the IP to client companies. They do sell some hardware parts, including the 65c02 and 65816 which are all guaranteed to be able to do at least 14MHz. The '816 is a natural upgrade path to the 65c02, with registers that can operate in 16-bit mode, and has a 24-bit address bus, and has a lot more instructions and addressing modes, making it much more suitable for things that the '02 is either clumsy at or incapable of. The 65816 outperforms the 68000 and 8086 in the Sieve of Eratosthenes benchmark. Bill Mensch, WDC's owner, is still going strong, and intends to keep the technology available indefinitely.

@Garth

This is good to know. This is on topic and will keep that information in mind. Thanks.

Garth wrote:The 65816 outperforms the 68000 and 8086 in the Sieve of Eratosthenes benchmark.

Do you by any chance have sources for this? I've tried google but all I've found is you making that claim ( ) and this article, which (quoting an old BYTE article) gives the 68k quite the edge over the 65816 (although the 65816 indeed still crushes the 8086).

Edit: (that article seems to come straight from Programming the 65816 - so even the canonical source claims the 68k is faster)

Edit edit: Also - that probably came across as more argumentative than I intended! I'm not a 68k fanboy, I love both it and the 65816 equally, for different reasons. Just curious to See The Code, as it were.

Adam, I originally got that info from WDC, and I don't remember if it was in paper literature or on their website which keeps getting changed and not all of the info is there anymore. Samuel Falvo repeats it at http://forum.6502.org/viewtopic.php?p=190#p190 and says it was published in the January, 1983 issue of BYTE magazine. I don't know if the source code was there. It shows the 65816 taking .73 seconds (that was for ten iterations of the Sieve, IIRC) to do what the 68000 did in .49 seconds, both at 8MHz; but then the '816 went on to achieve higher clock speeds than the 68K. The '816 would only have to run at 11.9MHz to match the 68K; but the SuperCPU plug-in addition for the C64 ran the '816 at 20MHz.

Edit: I do have the Eyes & Liechty programming manual referred to in your link. I guess I glossed over that when I read the book many years ago, so I didn't remember it was there. (I do refer to the reference sections in the back of that book frequently though.)

If you're just looking to learn and tinker with making your own simple console it might be worth checking out the Uzebox if you haven't already. Off the shelf new parts, only two IC's (atmega and video encoder) plus bunch of discrete components. It's open source and you can make it yourself, and add your own improvements or whatever you'd like. It's doesn't fit the frankenstein bill of the thread topic, but I noticed your other topic expressing curiosity with arduino and wanted to point it out. It's kinda like an arduino minimalist video game console.

The only way a 68000 would be faster is if you're only using 32-bit instructions, only using 24-bit addressing, and emulating every 68000 instruction word for word.

I should have mentioned that the 65c02 has much better interrupt performance than the 68000. I've run up to about 140,000 interrupts per second on my 5MHz 65c02 workbench computer. (Obviously the ISR had to be pretty simple.) I have a 6502 interrupts primer at http://wilsonminesco.com/6502interrupts/ . That said, the 68000 does have an instruction set that's better suited for HLL compilers.

Ahh, I see! Sorry, I misunderstood - you didn't mean that clock-for-clock the 65816 runs the sieve faster, you meant that - at this point in time - you can clock it (more than) high enough to make up the difference. That plus the faster interrupt handling plus the current availability would indeed make them pretty compelling for this kind of project.

(*that said*, I'd be remiss if I didn't mention that apparently 28MHz (!!!) 68000s existed, once upon a time)

psycopathicteen wrote:The only way a 68000 would be faster is if you're only using 32-bit instructions, only using 24-bit addressing, and emulating every 68000 instruction word for word.

The sources we're looking at claim that, at the same clock speed, the 68k does in fact outperform the 65816 at this particular task. The 65816 code is given, and while I'm not going to claim it's beyond reproach, it's not doing anything like you're describing; it was written to be fast ("the Sieve program...provides an opportunity to examine performance-oriented programming; since the name of the game is performance, any and all techniques are valid in coding an assembly-language version of a benchmark") by authorities on the CPU.

If you can write a 65816 sieve that actually does outperform the 68k, write it up (in another thread?) and we'll have a shootout

In case of SNES there's the limit of 8bit bus which will reduce all the offchip traffic speed.

I should have mentioned that the 65c02 has much better interrupt performance than the 68000. I've run up to about 140,000 interrupts per second on my 5MHz 65c02 workbench computer. (Obviously the ISR had to be pretty simple.) I have a 6502 interrupts primer at http://wilsonminesco.com/6502interrupts/ . That said, the 68000 does have an instruction set that's better suited for HLL compilers.

From the info I have found it takes 44 cycles to enter an interrupt and 20 to exit on 68000, so 64 cycles just for that (more for Address Error and Bus Error exceptions as they put extra info on the stack), plus whatever time you spend on actually doing anything.
If one is gonna design some hardware with 68K you'll want to fire your line int earlier if possible so that you aren't gonna get too much into the blanking area and can maximize the space fully. Cycle hungry instructions like DIV and MUL will delay interrupt response fair bit too, you don't want to be doing those if you need timing critical code.

TmEE wrote:In case of SNES there's the limit of 8bit bus which will reduce all the offchip traffic speed.

Which is largely balanced out by the 68000 accessing memory only once every four cycles.

For the algo mentioned earlier I assume the comparison is between 65816 with 16bit bus and 68000. I would think 65802 mentioned in the WDC programming manual is closer to what's in SNES, except you do get 24bit addressing on SNES which you don't on 65208. Now 68008 (68000 with 8bit bus) vs whatever would be a win to whatever, 68008 is very very very slow when it comes to talking to the external world. Big instructions, big data, lots and lots of slow memory cycles.

Baseline 65816 has an 8-bit data bus. Opcodes are 8-bit, and operands and data are read or written at one cycle per byte. As I understand it, the only real difference with the 65802 was that it could only address 64 KB due to 6502 pin compatibility requirements, which is definitely not true of the 5A22.

Going to a 16-bit system bus in the Super Famicom would have required some reasonably sophisticated glue logic, plus either external wait states or greatly complicated on-die timing.

A 6502 successor with a 16-bit data bus, no half-cycle strobe, and no concern for backward compatibility could have been a monster, approaching double the performance of the 65816 at the same clock speed, or quadruple the performance at the same memory speed. (I'm assuming here that processing would remain more or less I/O-bound...)

I just looked at the Sieve benchmark, and it looks rigged to me. If they used word aligned addresses, they wouldn't have needed the sep and rep.

EDIT: Actually, even with the code posted, I don't understand how the 68000 could be any faster, unless they just used a completely different algorithm to begin with.