HuC6280 vs 68000?

[djcouchycouch]

I hate asking a question like this, but it's been on my mind lately:

How would the HuC6280 and the 68000 compare in performance running code written C?

I hate the question because I realize the answer to that question is "it depends", because there are so many factors that can affect it (the compiler quality, the written code, architecture, etc.) but I keep wondering how the HuC6280 would perform if I ported Goplanes to it. Would I realistically expect to do a bit more optimization, a lot more, or none at all?

[Stef]

Due to the restricted number of registers, C compilers generally performs really bad on 6502 derived cpu (as 6280 or 65816 cpu).

[powerofrecall]

Would I realistically expect to do a bit more optimization, a lot more, or none at all?

I assume it'd be like anything else; optimizing where your code spends the most time executing & the operations it performs most often. It's a real shame there isn't any kind of real profiler for MD (or the PCE/TG16, as far as I know).

[Chilly Willy]

It depends.

Well, given that your code doesn't get too complex for HuC, I'd guess the 6280 will do rather well. It may be mostly a 65c02, but it's also 7MHz. The extra instructions to do things is offset by the higher clock rate and better IPS compared to the 68000.

I would guess you would spend more time making it compile with HuC than in optimizing. Of course, I'm not sure how much of the MD hardware you're using... if you use both planes, you'll need to find some other way on the PCE... maybe use sprites for another layer... unless you make it SGX.

[Charles MacDonald]

There's a number of homebrew TurboGrafx games that are written in 100% C using HuC, no assembly, and perform surprisingly well. One of the best ones is Jungle Bros:

https://www.youtube.com/watch?v=eKVd8lyrEdk

It's surprising since HuC, while not bad, isn't exactly the best compiler around and it's hard to get good quality compiled code for the 6502. So I think you wouldn't have too much trouble with Goplanes, even if you used C exclusively and no assembly.

That said, it is a real pleasure to program the HuC6280 in assembly. It's incredibly fast and unlike most other 8-bit CPUs you seldom find yourself running out of cycles during V-Blank time. I guess that makes it forgiving as any wild idea you have can usually be done without needing a lot of optimization. Maybe that's why HuC has good results even if the output isn't very efficient.

[mic_]

if you use both planes, you'll need to find some other way on the PCE

Looks like it to me.
If the furthest background layer is really simple (such that it repats often) you can fake two layers by creating duplicate tiles with all possible combinations of the two layers (see Sword Master on the NES for an example).
That might not be feasible if you want to scroll both planes horizontally and vertically though, as the number of possible combinations would get quite large.

[djcouchycouch]

If I brought Goplanes to PC Engine, it probably won't be a straight port due to hardware differences and gameplay differences like only having two buttons instead of three.

Of course I'm getting ahead of myself since I haven't actually finished one version to go about making a second But I like to think about it. My bus rides are loooooong.

Any idea about the quality of CC65 compared to HuC? I've read that CC65 has support, but generally lacking in libraries.

[Chilly Willy]

Any idea about the quality of CC65 compared to HuC? I've read that CC65 has support, but generally lacking in libraries.

The support is in the assembler. While you can tell the compiler the CPU is the 6280, it still only generates 6502 instructions.

http://www.cc65.org/mailarchive/2005-09/5201.html

So any PCE specific code would need to use the assembler... which is probably what you'd want anyway since the platform specific libs need to be as fast as possible.

I suppose the best way to handle PCE support in cc65 would be to make a cc65 version of the MagicKit library.

[tomaitheous]

Ouu.. this is a sore topic. I hope I don't catch any flack for this ;>_>

Currently, C (small C) completely SUCKS on the PC-Engine. Not only are a lot of functions ridiculously slow (both internal to the compiler and to the external library. And it's in ASM!) - comes with a lot of limitations. And the library suffers too much from - one size fits all type of mentality. It tries to give the programmer all these options, but it's optimized in no area. IMO - the PCE is less flexible than Genesis in this state, so it suffers more as result.

Array and pointer access is SLOOOW. I mean, retarded slow. Even pointer/array access to fixed local mapped memory - gets a huge weird code generation. Everything gets treated as of it's far banked memory. Using local variables it very slow (so is passing to them via a function call) - any kind of speed needs to be kept as global variables. So are any kinds of logical shits (the code generation is enough to make you laugh). I'd wager a bet that a real time BASIC interpreter is about as slow in that area (maybe even faster).

In order to optimize for HuC on the PCE, you need to be very familiar with assembly and the low level hardware of the system (on top of the higher level structure of HuC) - because you'll not only be writing assembly routines - but you'll be hacking the crap out of the external lib (which is all ASM) and monkeying around with the limited banking system that HuC forces on you. It's fine for messing around with, but I don't recommend doing anything serious with it. By the time you get efficient enough with it, you could be that much more efficient with assembly and have *real* power to play with. Anyway, that's just my opinion.

Two people that I know of, are pretty efficient at it. Old Rover and Arkhan. Old Rover managed to make some impressive stuff with it, but he's been working with it for like 10 years now. If you're really determined to do this, talk to those guys.