68k and HuC6280 comparison

[touko]

I didn't use self modifying code, but you could (if you have enough ram; 8k isn't enough). My demo is hardcoded/embedded. I wrote a util that took data files and created embedded ASM files for use with PCEAS. But I've done a lot more than just transparency with that method.

Ok, i'll try to understand how it works, thanks ..
 

Ehh? I don't remember. Charles and I talked about many awesome things, but I tend to forget things if I don't save them :/

It was in this tread :
http://forums.magicengine.com/en/viewtopic.php?t=1615

;-) ..

[Bonknuts]

Link didn't work. It just brought me to the main forum page.

[touko]

Oups, updated ;-)

[Bonknuts]

Pardon if this has been asked before, but how hard would it be to port a 68k game to HUC6280 and vice versa?

 Just the code itself? Not really hard at all, as long as you know both processors fairly well. Or at least knowing the target processor of the port pretty well (I'm thinking 68k->65x/6280). 68k is fairly straight forward. 65x/6280 can get convoluted when the code gets really optimized for speed. With out good notes/comments, I can see convoluted 65x/6280 code to 68k being a pain in the ass. Regular 65x/6280 code though, shouldn't be a problem. I have early source code for Art of Fighting on the PCE ACD. It shows some 68k code in the comments that they were directly porting. Me personally, I like to write comment code in C - for a quick explanation of what the code is doing. You have a project in mind?


 

[Bonknuts]

touko: Continuing the discussion...

 I was looking into doing fast multiplication on the PCE. Stef mentioned the 68k can get 70 cycles for 16bit * 16bit -> 32bit.

 I looked up some routines and came across the old c-64 code for fast mul. I've seen this before, a number of years back. But I never had a need for it. Almost all my multiplication in code were of usually one element being a constant and optimized as such. But for something else that I started, I needed variable values for both A and B.

 The fast mul routine is based on f(a+b)-f(a-b). Where f(x)=x^2/4. If you break the multiplication down into 8bit steps, a+b=9bit result. So f(a+b) is a 9bit (512) WORD wide LUT. This breaks it down into simple additions and subtractions (albeit 16bit add/sub operations). I have a few ideas how to speed this up further, but I have to write the code out and compare cycles.

[touko]

Ah yes i read that on sega-16 ;-) ..
But comparing 68k cycles with 6280 directly is not fair ..
70 cycles for mul opcode on 68k, stef don't count the registers init, he counted only the mul instruction ...
i think all the process (load each value + mul ) is close to 80/90 cycles ..