nesdev.org

Honestly if you don't use the externals multiply and division units then i think you have no chance of having comparable execution time :-/ May be,but in this case why do not use an external ship then,the big deal is mainly mul/div . 3D is not my cup of tea, i let more experienced coders here doing...

That depends on what you're actually comparing... if it's 68000 vs. 65816

Yes it's for 65816 vs 68000, and not entire system,this is why stef doesn't care of planar/packed display.

For a Md vs snes, it would be also unfair because Md use a sort of chunky mode vs the snes's planar .

you can use the multiply and division units from the PPU to perform the operation if you want (in which case you can't use the mode 7 anymore as i believe it uses these units). In this case is not really fair, because mul/div on snes is not a CPU part .. For a good comparison, you must fake these i...

I will try to find something better as i admit using code with multiply and division is not really fair for the 65816.

Why ??, these are 68k instructions, it's fair IMO.
Stef don't be overconfident

What second register? o.O for the second value if you scroll on Y .. A use of (An) is slower no ?? How many cycles this take ?? . move.l #$40000010, ($C00004) move.l (a6)+, ($C00000) I think with interruption is close to 100 cycles / line move.l a6, -(sp) move.l usp, a6 move.l #$40000010, ($C00004)...

If the adc is in RAM (zp), you can do this on hu6280 #$6 is directly added in zp_var location,without touching the A reg .

Every CPU have their own strength and of course you study a bit the instruction set before trying to code anything. of course stef, but we cannot said if a cpu is good or bad only with that , mainly if you're more experienced and used with an architecture .. you cannot look an ISA and say, "oh...

tepples wrote:I wonder if psycopathicteen would want to see your 65816 source code and point out obvious problems. Apparently there are a lot of people who try programming 65816 without knowing peephole optimization.

i agree with that ..

if you're coding 65xx like Z80 or 68K you'll go in the wall .

If you need to do two planes, it'd be two 32-bit writes (of which one is always the same value), which yeah is slower but still not as bad as it sounds. Of course this is not as dramatical like it seems, but not as fast than 65xx,and you must spend 2 registers only for that effect .. I actually use...

Maybe it's irrelevant since it's JMP instead of JSR, but still. no, but it's really cheap to be forced to use a JMP rather than the common jsr, for a "mush more evoluted" CPU than 65xx (dixit stef), i think it's not really serious :wink: and you can do the same with HU6280,where jmp is 4 ...

So from what I've seen so far, Espozo is right: the increased CPU frequency and increased cycle counts balance out. Ok, but i take in account the HU6280 too, for me the 68K jsr/rts are just too slow . I would mind if 8-bit was slower, however. it would have been a shame really, but the 65816 is clo...

On Hu6280 JSR/RTS takes 16 cycles,but @7,16 mhz .

32 cycles on a 68000 is like 4 fast and 8 slow cycles on a 65816.

how did you get these values ??
With the clock speed difference ??

hum, a single JSR/RTS take at least 32 cycles

When you are used to 68000 programming you really don't accept anymore to deal with that sort of problem ;) you can say that for any CPU, when you're used to 65xx you cannot accept that a 16 bit CPU cannot do 8 bit operations faster than 16, slow irqs, slow tests+branching, slow sub routine calls ,...

PCE was also the most forgiving of the three platforms when it came to video hardware accesses during active scan, Yes, but unfortunately, the CPU is not able to use all the available bandwidth .. :? However you can use the fast DMA for VRAM to VRAM transferts,you can fake some parallaxes or doing ...