Md 68k and hu6280 comparison

[touko]

Wahou, very good analysis, i don't search a fight 68k vs 6280, i know that 68k is a great CPU, more flexible for multiples use than 6280, and for any one more easy to use ..
I have no problem with 6280 assembly now, and i like it ...
Of course i respect arkhan 's headaches with it ;-) ..

Tom i have already seen this interrupt code comparison on spritesmind, and I found it very interesting ..
IMO the huge interrupt cycles consumption justify the existence of the Md scroll table ..

your last sentence responds to my question, that 6280 can compète with Md 68K in game code ..
;-)

Thanks you all for trying to give me an answer.

[Arkhan]

I don't have an actual specifics, so I am speculating:

I would figure that if you're doing a lot of actual 16-bit operations, the 68k will out perform the 6280 because it's setup to do that better. 

but if you're doing a bunch of 8 bit crap, they will be roughly the same.   More so because the 6280 is superfast, compared to other 65xx variants.   Sort of like using a pickup truck to carry a carton of eggs home.  Works the same as a sedan.    Have fun getting a couch home in the sedan, though.



EDIT: Also, Tom posted while I had half this post typed and didn't finish.  He said something similar at the end.   68k doesn't benefit from processing 8 bit data.



However, depending what you are writing for a game, you will likely see >8 bit numbers in your game that you need to do things with. 

Also, doing a raw 68k vs 6280 comparison doesn't amount to much when you consider what really makes the system operate are the other chips/things that the system can use to facilitate things.

You also have to consider that the two CPUs have different instruction sets/styles, and should not be approached the same. 

If you make really contrived examples, you will probably find ways to say the 6280 is wildly faster.  But, it will be for some goofy example that isn't very practical in a game, anyway.

[touko]

Arkhan you'r right, i don't want a MD vs PCE, because like  you have already said, a game machine is not only a CPU, and i think also what MD is better in general ..

My goal would be to compare MD with SGX to be fair ..
I think Tom came to the same conclusion, that 6280 can compete with MD cpu even his higher frequency ..
obviously only in the case that concerns us: the game ..

And except sprite/line limit,i think, a game like gunstar hero is doable in term of sprites animation on PCE ..

[Arkhan]

even a straight 6280 vs 68k comparison isn't totally fair since the two aren't in the same league.  You'd be better off doing 65816 vs 68k, and watching the argument that ensues. 

[touko]

Of course arkhan, but do you know a console with a 65C816 @7 mhz ?? 

[Arkhan]

Nope.  The 65816 blew. 

lol

[touko]

LOL

[Bonknuts]

Surprisingly, the 6280 can keep up with the 68k on quite a few 16bit stuffs. Sometimes coming very closet to matching it, other times beating it. But like stated before, comparing snippets of code between these two processors isn't exactly representative; even simple addition comparisons.

 But here's one:

Code: [Select]

(68k)
move.w d0,abs.w ;12
add.w d0,abs.w ;16

28 cycles

(6280)
lda <$01 ;4
clc ;2
adc <$02 ;4
sta <$01 ;4
lda <$03 ;4
adc <$04 ;4
sta <$03 ;4.  24+2 = 26

 That's just a memory+memory->memory operation; 16bit+16bit->16bit. The 6280 beats it by 2 cycles. I used ZP on the 6280, but I also used the MD's fast access mode ram (top half of the 32k) for faster accessing too. Not exactly the same, but fairly close in principal (if you treat certain ZP variables as ram instead of data regs). If you have a matrix of variables that need to be added to a single value (say like moving a series of linked objects), the 6280 automatically gets free indexing and such. I had quite a few examples of 16bit operations, and even when the 6280 was slower cycle wise - it was still pretty close. And of course if the operation is 8bit+16bit->16bit instead of a full 16bit operation, the 6280 gets a nice little speed up there (a branch to skip on non overflow detection). This isn't to take away from the 68k's 16bit operationally ability (it can do quite a few fancy 16bit things), it's just to show that different between one being 8bit and the other being 16bit isn't as drastic as it seems.

 Of course if you design the game logic specifically around the 6280 strengths, it'll scream along no problem. The key is high level optimization in design along with low level optimizations. This might limit you in game design slightly, but the player/gamer will never know. The 68k is more flexible and robust overall, while the 6280 is extremely fast at more specific/narrow-focused designs.

[touko]

yeah i think so ..
I have a discussion about this with stef (the creator of gens), but he's too fanboy, nothing is better than MD and his CPU ..
Of course it's a great machine, and his VPC is very ,very, good ..

And I'm a little annoyed by this urban legend,where if a CPU is 16 bit, then it's alway better than a 8 bit .
I took as an example of a 256 bytes increment, a common use to increment a pattern on a 32*32 pixels sprite ,to show how fast the 6280 can be in 16 bit data processing using the 8 bit LSB/MSB feature ..
This kind of processing is very common in games of this era ..
i think also that 8 bit variables are the most common.

[Arkhan]

It's not that it's "better" speed wise. It's that it's more capable.   Like I said before, a truck and a car can both take some eggs home, but the car sure has problems getting a couch home...

It can do much more with itself than an 8-bit CPU.  Imagine if Amiga kept going with 6502 CPUs like what was in the C64.

The Amiga would've been a joke. 


For game consoles, the CPU almost barely matters in the end, because the other hardware decisions are what truly make or break the consoles.   

[HercTNT]

I'm just thrilled there is not a test on this later as my head exploded!! Frankly you guys could be BS'ing and i would have no idea LOL. For all i know you just described the processing power of a frosted flake when it interfaces with a bowl of milk

[spenoza]

For all i know you just described the processing power of a frosted flake when it interfaces with a bowl of milk

If someone designs a console I can eat for breakfast... I'll feel really bad for losing a console when I get hungry.

[touko]

It's not that it's "better" speed wise. It's that it's more capable.   Like I said before, a truck and a car can both take some eggs home, but the car sure has problems getting a couch home...

It can do much more with itself than an 8-bit CPU.  Imagine if Amiga kept going with 6502 CPUs like what was in the C64.

The Amiga would've been a joke.  

Yes of course, but you're taking extreme cases ..
68K is perfectly designed for a workstation, and of course is well suitable for a home computer, better than a 6280, in this case 6502 is out of competition .

For game consoles, the CPU almost barely matters in the end, because the other hardware decisions are what truly make or break the consoles.  

I agree with that, and how many people said "Snes has a crappy  CPU " ??, yes snes has also very slow main RAM, but very impressive hardware too ..
When you have good copros, you don't need (usualy) a fast CPU ..

[EvilEvoIX]

This argument has gone back and forth for years.  Look at the games and what the system is capable of.  Later MD games would be really hard to visualize on the PCE.  The PCE is really good at color and I think that is the systems strong suit.  The md has poor color but can be displayed cleverly.  Systems and chip sets have strengths and weaknesses.  In my experience the PCE does shooters really well.  The md certainly does animation better, and the snes did RPGs.  It was an amazing time as all systems were so different and had so much personality.  I don't think that the PCE suffered so much from it's "bit-ness" however it really does straddle the line between 8bit and 16bit.  When push comes to shove you won't see earthworm Jim on the PCE or Ranger x, at least not without noticeable sacrifices.

[Black Tiger]

Here we go again.