nesdev.org

ASL.W #4,d0 on the 68000 takes 14 cycles whereas ASL, ASL, ASL, ASL on the 65816 takes 8 cycles, despite being more instructions. Shifting takes 2 cycles per bit on both cpus, but the 68000 always has an overhead of 6 cycles when using shifting instructions.

DBRA.W d0,loop on the 68000 takes 10 cycles whereas DEY, BNE on the 65816 takes 5 cycles.

So is it another 6502 vs. Z80 story here, where the 6502-family CPU performs as if it has an internal clock doubler?

More or less. The 68k's cycle counts get pretty ridiculous when you start using all the features, though it does have the advantage of only needing one bus cycle to load a 16-bit value.

I don't really see the benefit of having a 16-bit data bus with a 4 cycle memory accesses, over having an 8-bit bus with 2 cycle memory accesses.

The 65816 has a 1-cycle memory bus though.

The benefit is the ability to use slower RAM. By having each memory cycle take multiple processor cycles, the processor can be doing other things while it's waiting for memory.

tepples wrote:Perhaps the effective MIPS of the 65C816 needs to be lowered, as I'm guessing the average instruction will have a cycle of SlowRAM access. Immediate and jump instructions have fewer, instructions in 16-bit have more, and RMW instructions have more.)

I agree. You can't really say the SNES CPU runs at 3.58mhz since in not practical game program will it ever run that speed. That's the peak, not the average. I really do think it should be obvious that the 68000 @ 7.6mhz is going to be able to get more done than the 65c816 @ 2.68mhz ~ 3.58mhz. Not basing that solely on clock speed but more on how the processors work and just observing some commercial software for both platforms.

The SNES obviously isn't pathetically slow to some point where it can't do anything. But I do think it's quite fair to say on the SNES you don't have as much cpu time to be wasteful with.

It's a benefit when you consider the predecessor chips were an 8-bit data bus with a 4 cycle access period. Pretty much the entirey of the 8080/8086 derivatives used that sort of bus, and the 6800 and it's children used a very similar one.

One thing I like to point out.

It's 2010, FastROMs are dirt cheap nowadays.

Anyway, I'd say in FastROM mode it is approximately 3.3 Mhz and it's about the same as a 5 Mhz 68000.

And how did you come up with these numbers?

The 68000 beats the 65816 mainly at 32-bit calculations. It still has more overhead compared to 16-bit calculations, but it's definitely much faster than faking it.

MottZilla wrote:And how did you come up with these numbers?

I estimated it being 1 out of 4 cycles is a work ram accessing cycle, which is about 3.3 Mhz.

I estimated the 65816 as about 1.5x as cycle efficient as the 68000.

Taking into account the costs/limits of when the system was commercially viable (like expensive FastROM) makes for a fairer comparison.

]The SNES obviously isn't pathetically slow to some point where it can't do anything. But I do think it's quite fair to say on the SNES you don't have as much cpu time to be wasteful with.

I agree with Mottzilla here. There's a decent speed advantage over the '816 but I'd say both systems are not really challenging in terms of homebrewing a random game.

The cycle counts for the 68k are reasonable given how much work it can do with the time especially on 32bit stuff with nice addressing ability and specialized instructions. A CPU that can access memory faster isn't a huge advantage if it needs a whole lot more accesses to do an equivalent job. 65816 is cool with 16bit shifts, but try 32bits and it's 9 cycles per bit for example. It's a clear disadvantage before the clk speed differences are brought in.

tepples wrote: What are you talking about? Bonk was also on the NES.

Huh? What does that have to do with my Bonk port project to the MD? And NES Bonk != PC-Engine Bonk.

You only used one single palette for the whole BG... on PCE there were more used....

Ehh? I used two subpalettes. I know, because beside doing the conversion myself, I had to use my PCE conversion util on the first level tileset to help in reducing the colors (then convert the output data to MD's tile format). I left the other two subpalettes for enemies and objects. PCE original used 3 or 4 subpalettes for the BG total, for each area. And 4-6 for sprites.


As far as the whole 68k VS '816 thing, really.. little examples mean nothing. You can provide examples on both sides to show strengths and weaknesses. Try writing code for both. Optimize it for both. 8 or 9 times out of 10 (for game consoles and 2D gaming), ignoring clock differences, the '816 will come out ahead with less overall clock cycles. I done just that. If you're not getting similar results, well.. then you're not really efficient with coding on the '816 or 65x arch in general (would be my guess). LUTs and indexing in general is a huge strength of the 65x. And you play to the strengths of the processor. The difference between normal code and optimized code on the 68k, is not nearly as drastic in difference as it is on the 65x arch (65x= anything 65xx or 65xxx). Not to mention the 68k is the perfect CPU for a computer or operating system, but game consoles are more slimmed down and specific tasks. The requirement for the type of code is fairly different, and it's that difference that brings the differences or strengths between the two archs closer together, or rather.. eliminates some of the normally big benefits of the 68k design.

The 68000 beats the 65816 mainly at 32-bit calculations. It still has more overhead compared to 16-bit calculations, but it's definitely much faster than faking it.

Addition/subtraction, IIRC, the '816 even beat it out cycle wise (not to fuel this debate any further, we had this out in the genesis dev forums already).

Anyway, I'd say in FastROM mode it is approximately 3.3 Mhz and it's about the same as a 5 Mhz 68000.

Any instruction that touch ram, which is almost all of them since the 65x has practically no on dye registers, is closer to 3.15mhz.

ASL.W #4,d0 on the 68000 takes 14 cycles whereas ASL, ASL, ASL, ASL on the 65816 takes 8 cycles, despite being more instructions.

And that is the worst possible comparison. The SNES is great at shifting, if you know what you're doing. You can shift six places faster than four:
XBA; LSR; LSR; and ten places at the same speed a six. Just have to be sure B (top 8-bits of A) is clear first.

Multiplication and division is a real treat, too. ASL; ASL; PHA; ASL; CLC; ADC $01,s == A*=12.

65816 is cool with 16bit shifts, but try 32bits and it's 9 cycles per bit for example.

Yeah, you can chain ROLs, but those require RMW operations, which suck. If you have a fixed number of bits you want to shift, it should be pretty easy to at least mitigate that damage.

I myself would have really liked MUL/DIV opcodes in place of the absolutely useless MVN/MVP opcodes (okay fine, they allowed barely faster WRAM->WRAM, but that was it.) Division by 56 for instance is a nightmare, and that SNES-specific ALU was such an ugly, slow, annoying, interrupt-unsafe kludge.

It's 2010, FastROMs are dirt cheap nowadays.

A lot of the time you are accessing WRAM, which is SlowROM. Nowadays you could throw some in-cart RAM at $f0-ff banks, but direct page is still going to be SlowROM.

So, in summary, it has been argued the MD's graphics are 100 times more limited than SNES', MD's FM sound sounds like a joke compared to SNES's Wavetable sounds (when the chip is used correctly, that is), and now we're debating whenever the MD's CPU is much faster, a little faster or not even any faster at all ?

Anyway, even if it were this much faster, the SNES would still end up pushing the MD to shame. A faster CPU is good for computers, but for consoles, it's really the graphics and sounds that matters. Even today's action games typically doesn't handle more than a dozen of bullets and enemies on screen at a time - not much more than what was made in the 80's. (okay I'm not very knowledgeable about today's games so I might be missing something).

And I didn't even talk about the controllers... The MD was originally made to compete with the NES (which it did quite well in fact !). But then the SNES came out and booom !
Sega's policy of releasing a new consolle every couple of years is weird, and what caused them to eventually go to their doom, instead of releasing better consoles less often. Yet I know the MD is Sega's best console and all, but hey... I just don't like Sega very much for some reason. I know I'm biased