HuC6280 VS 5A22 - Legacy battle 6502!

[spenoza]

OK, this keeps coming up, but I want to pull it out in the open. CCOVELL and TOM are going to be the two best qualified to address this and I invite them to. as well as anyone else who knows anything. At least this inquiring mind wants to know.

The HuC6280 in the PCE and the Ricoh 5A22 in the SNES all have their origins in the MOS 6502, the SNES perhaps a little more distantly. What truly separates these designs from each other and from their shared 6502 ancestor? And what were some of the practical implications for game design and system performance?

[Tom]

 The lineage:

            6502
              |
           65C02
           /      \
     R65C02  65816 (SNES)
     /
 HuC6280(PCE)

 Both offer much improvements over the '02 in my opinion. All the descendants are still Accumulator based processors, so additional instructions to avoid using a register is always helpful.

 The HuC6280 has some additional (helpful) instructions that didn't make it into original 65816. The 65816 has faster 16bit operations, but they expanded the cycles count for them - operations that only require 8bit precision are now slower then on the '02. Personally, they didn't think the instruction set through for the 16bit upgrade. It should have been either the same cycles or have byte specific instructions - like the 68k did (byte operand loads/adds/etc instructions). To me this is an unwelcome, although not large, performance hit.

 The 65816 has a cleaner method for arrange data/code than the HuC6280 and requires less optimization for near and far data for speed of access. It provides for a less complex code/data layout. On the downside the 8bit data bus slows down some things and the system ram (WRAM) has 'wait states' keeping most/important instructions from even reaching the 3.57mhz speed (about 3mhz roughly). One thing though, the 65816 definitely plays nicer with higher level languages than the '6280. But where's the fun in that? 

 In the end what matters is how much a processor can churn out. Despite the '816 being '16bit', it can't over come the raw clock speed of the '6280 at even half its speed, let alone less than. Even though the slower '816 excels at 16bit math, the PCE's raw clock allows its weaker 16bit arithmetic to process faster. Performance is performance no matter how you got there.

 On the '6280, I only use a handful of its instructions and only a few addressing modes. I want the fastest instructions and the fastest execution times. I reshape how data and code is organized. I use redundant code if it means I can shaves cycles and try my damndest to find any/all exploits of common reoccurring variables and constants. I pack LUTs in any space I can fit 'em or waste space aligning to offsets. I'm of the school that, once you spent the time optimizing all code and data to its maximum - it's done. You do it once, but experience the result many times over. The PCE's '6280 provides simple but fast instructions and the raw clock speed to back it up.

 The '6280 wasn't designed for high level languages, inexperienced coders, or 16bit macro loving sissies. Ok, now I'm getting a bit carried away... 

 Wait. Is that what you were looking for?

[spenoza]

heh... Sounds good to me. Explains a few suspicions I've had about the state of the console universe.

Doesn't the SNES also have to pause when pulling data from the cartridge?

[Tom]

heh... Sounds good to me. Explains a few suspicions I've had about the state of the console universe.

Doesn't the SNES also have to pause when pulling data from the cartridge?

 That's only for slow ROMs.

  Load a 16bit value into a register from rom (given in master cycles - 21mhz):

  lda #$1234    ;load accumulator with 16bit value $1234. This is a 3 byte instruction.

  PC <opcode> fetch  6+2 cycles   ;byte 1
  PC+1 <operand> low fetch 6+2cycles   ;byte 2
  PC+2 <operand> high fetch 6+2 cycles  ;byte 3
  <internal operation> - happens on the same cycle as fetching the next opcode
  PC+3 grab next <opcode>...

  24 master clock cycles. The +2 are wait states and add 6 more cycles. This would be 3 CPU cycles at 2.68mhz

  For fast rom and in the processor set to fast mode, it would be 18 master cycles or 3 CPU cycles at 3.57mhz. A 25% increase in speed.

  It's easier to display this in master cycles otherwise you get fractional numbers for cpu cycles.

  If you have the processor in 3.57mhz mode and you access WRAM:

  lda <$00     ;load accumulator register with 16bit value from ZP register 00

  PC <opcode> 6 cycles
  PC+1 <operand> 6 cycles
  <internal> fetch low byte 6+2 cycles
  <internal> fetch high byte 6+2 cycles

  that's 28 master cycles or 4.667 cpu cycles @ 3.57mhz because the work ram. Normally the instruction would take only 4 cycles if there were no wait states on WRAM. The instruction is now 14% slower or 3.06mhz.

 The 65x based CPU requires a master clock higher than the clock rate of the chip. This is because the processor has a series of internal cycles that correspond to one clock cycle. Both the SNES and the PCE use a 21mhz master clock. The PCE divides this down by 3 to get 7.16mhz. The SNES divides this by 6 for 3.57mhz. It's always running at 3.57mhz but by default it boots with wait states on for ROM thus lowering cycle count down to 2.68mhz. On the PCE you rarely, if ever, see the instructions listed in master cycles. This is because there are no wait states like with the SNES.