i agree .Without seeing the dies though its all speculation
Ah, not false, I did not see the SA-1 like that but it does not sound illogical.So I guess it could be seen as a 1phase 21Mhz or a 2Phase 10Mhz
Moderator: Moderators
i agree .Without seeing the dies though its all speculation
Ah, not false, I did not see the SA-1 like that but it does not sound illogical.So I guess it could be seen as a 1phase 21Mhz or a 2Phase 10Mhz
Now that I look at it from the chart I made, it looks like a 8Mhz 68000's biggest strength over a 4Mhz 65816 is register to register math (especially when clc and sec are needed). If you divide 4 cycles by 2, you get only 2 cycles, and the only math instructions on the 65816 that take 2 cycles, are 8-bit immediate instructions without a clc or sec.Stef wrote:We can say that, but again you will tend to use more one or the other depending the CPU you are working on...psycopathicteen wrote:Opcodes that a 4 Mhz 65816 would be faster than a 8 Mhz 68000 would be:
-branching
-shifting by less than 3
-shifting by 8
-ALU and load/store instructions that use immediate, absolute or indexed addressing (except when "clc" and "sec" are needed)
-non-word aligned memory accesses
Opcodes 8 Mhz 68000 is faster at:
-shifting by more than 3 but less than 8
-ALU and load/store instructions that use registers or register indirect addressing
-ALU instructions that require "clc" or "sec"
-32-bit ALU instructions
On a 68000 you tend to cache everything in register and do all operations from them, also you try to optimize to code to take benefit of the 32/16 bits as much as possible. What is important is to see how much you can process bottlenecks on these CPUs, and for me bottlenecks always tend to be a data processing stream less or more. If it has a lot of branching the 65816 can have the edge, but in general the 68000 will be faster to process data (higher bandwidth / higher ALU rate with 32/16 bits)
You compute score each times you need to do .you only need it to compute score mainly and some rare others stuff.
It's not a problem, it's only slow as hell on the 68k,you can add this with all things that are slower like branching,jumping, interrupts,8 bits processing (which represent a lot in 16 bits games ),communicate with 8 bits devices, etc ..it's never a problem
You should do better search then, SA-1(10mhz) and superCPU(20mhz) for exemple, not a 65816 but the apple 2C+ use a 4mhz 65c02,atari lynx (6502 at 4mhz) and of course the hu6280 .If you compare a 4 Mhz vs a 8 Mhz 68000 (i didn't saw it first)
And for the 1000 times, Nintendo could have done it at 5MHz if they had taken the way that Hudson did, easily,and without changing anythings .I think to make them almost on part you need at least a 5 Mhz 65816 vs a 8 Mhz 68000.
And what's your definition of "lot of case" ??the 68000 would be faster in a lot of case
No matter how many additions you do in a single frame, you only have to run the binary to decimal conversion once per frame. Keep updating the score in binary and then set a flag "score has changed". Then after all game logic has run, if there's free CPU time and video memory bandwidth, it performs the conversion and queues up new score data to send to video memory.TOUKO wrote:You compute score each times you need to do .you only need it to compute score mainly and some rare others stuff.
Of course you can do it in some frame, but it's the same, you need to keep each value to add in RAm and add all in a frame or more, it's definitely not good because you cannot know how many times you must update the score because it can vary a lot between each frame,it works in a plateformer but not in a shmup for exemple,and why doing this when you can add it in real time for 40 cycles .
i'am not sure you can easily do that using the 68k 32 bits registers,i saw the score management of a recent sik's game and it's not a simple number addition:No matter how many additions you do in a single frame, you only have to run the binary to decimal conversion once per frame.
Code: Select all
;****************************************************************************
; AddScore
; Adds score to a player.
;----------------------------------------------------------------------------
; input d7.l ... How much to add (in BCD)
; input d6.b ... Which player (0 or 1)
;****************************************************************************
AddScore:
and.w #$FF, d6 ; Whose score to affect?
lsl.w #2, d6
lea (Score1P), a6
lea (a6,d6.w), a6
move.l (a6), d6 ; Add both scores
and.b #$00, ccr
abcd.b d7, d6
ror.l #8, d7
ror.l #8, d6
abcd.b d7, d6
ror.l #8, d7
ror.l #8, d6
abcd.b d7, d6
bcc.s @NoOverflow ; Overflowed?
move.l #$99990099, d6
@NoOverflow:
swap d6 ; Store new score
move.l d6, (a6)
rts ; End of subroutine
Code: Select all
;----------------------------------------------------------------------------
; input REG A ... low value to add
; input REG Y ... high value to add
; 8 digits score
;----------------------------------------------------------------------------
Add_Score:
ldx #LOW( score + 2 )
sed ; // Active le mode décimal
clc
adc <score ; // Unites & dixaines
sta <score
tya
adc <score + 1 ; // Centaine & milliers
sta <score + 1
set
adc #00 ; // 10 aine de millier & 100 aine de millier
inx
set
adc #00 ; // million & 10 aine de millions
cld ; // Désactive le mode décimal
rts
TOTAL 42 CYCLES
Hopefully it's only your opinion,unless if you're speaking of the 68k BCD mode !!.imo BCD instructions are totally useless here..
What is the point of your replies ?? Where did i said the 65816 could not be faster ? the problem is memory/ROM speed, not CPU speed.. Customizing the 65816 would have cost a lot of time and money in research and design, something Nintendo couldn't afford to as the Megadrive was already there at a good price. Sega could have used a 12 Mhz 68000, added 4 extra palettes, 128 KB of VRAM without cutting anything in the MD VDP with more money... There is no real point in saying that.You should do better search then, SA-1(10mhz) and superCPU(20mhz) for exemple, not a 65816 but the apple 2C+ use a 4mhz 65c02,atari lynx (6502 at 4mhz) and of course the hu6280.If you compare a 4 Mhz vs a 8 Mhz 68000 (i didn't saw it first)
And for the 1000 times, Nintendo could have done it at 5MHz if they had taken the way that Hudson did, easily,and without changing anythings .I think to make them almost on part you need at least a 5 Mhz 65816 vs a 8 Mhz 68000.
They could have even removed the 8 bit bus for a 16 one like mitsubishi did .
In the whole, what are you trying to prove ? Of course the 68000 is not perfect but in the whole it's a much better CPU than the 65816...It's not a problem, it's only slow as hell on the 68k,you can add this with all things that are slower like branching,jumping, interrupts,8 bits processing (which represent a lot in 16 bits games ),communicate with 8 bits devices, etc ..
Damn, it's all that a game needed
Of course Free to you to think whatever you want, at least this time you said "for me" in your second sentence, this is already a progressIt's already not faster by a huge margin with a 2.6 mhz !!
For me a 2.6mhz 65816 is not faster than the MD's CPU, but not so far .
The only valuable information in this thread is here :There is a good thread here (in 68K assembly) :
http://eab.abime.net/showthread.php?t=5 ... hlight=bcd
Exactly what we said earlier...So that's how much adding instructions on a whim saves, 11 cycles per digit. BCD was added as a lazy convenience, never to save cycles or code size. It's never used where performance is of importance, as this max-once-per-frame score example shows.
No, you 're proud to show how the 68k is wonderful for 32 bits operations even when they are useless in a 16bits game, i show you that it's easy to find something which is very slow on a 68k and useful for games,this is what i mean.Do you see how this is ridiculous ? You're trying to prove the 68000 is slow because 68k BCD instructions are slow ?
Frankly stop to be so stupid, we have explained so many times that you can double the CPU frequency with same ROM/RAM, you're boring to not understand that .the problem is memory/ROM speed, not CPU speed
Oooh 42 cycles VS 130, yes, you're right !!So that's how much adding instructions on a whim saves, 11 cycles per digit. BCD was added as a lazy convenience, never to save cycles or code size. It's never used where performance is of importance, as this max-once-per-frame score example shows.
Not without a massive redesign of the chip and raising up the costs a lot (and you don't really double the speed).Frankly stop to be so stupid, we are explained so many time that you can double the CPU frequency with same ROM/RAM, you're boring to not understand that .
Yeah, because honestly it's just wrong :p... And like usal you don't take care that somebodies in the thread said that BCD is useful even on the 68K, you keep always what you want . It's useless on the 68k because is so slow .
Like i said stef, you are boring as hell .Not without a massive redesign of the chip and raising up the costs a lot (and you don't really double the speed).
Yeah, this is why speaking of CPU with you is boring and pointless ..Yeah, because honestly it's just wrong :p
Thanks but i know...TOUKO wrote: The 65xxx classic design is a 2 phase CPU, each phase access to the ram at 1/2 cycle, this is why 2x the CPU frequency ram is needed.
redesign... do you understand that redesigning the CPU is all except trivial ??if you redesign your CPU to be " a 1 phase"
I said "you can use it as it makes the BCD conversion code simpler" but still we don't *need* it performance wise, it's an instruction you almost never use... it's not as common as the ADD instruction for instance (oh my bad, the 65C816 doesn't have ADD instruction )Yeah, this is why speaking of CPU with you is boring and pointless ..
I took the sik's code as exemple, and it use BCD,as a bunch of exemple on the EAB thread .
Score calculation is only one exemple,because i know you like to compare code, unless when it's not in favor of the 68k,and yes,sorry if it is a bit more than the 2 lda and 3 sta you did on sega-16,before declaring the 65xxx inefficient.
No, the 2 phase was here to permit an external chips accessing to the main RAM without stealing any CPU cycles like the Z80 did in the CPC or spectrum .There is a good reason why the 65xx CPU works in 2 phases, it's needed by its internal implementation
And you know that because you were in the team who's designed the CPU ???The HuC CPU required a major redesign with a MMU unit to make it acting 1 phase externally. It's required *a lot* of time / work and money to design this CPU.
i prefer the block transfert instructions what the hu6280 has, rather than a stupid add,more useful when you need to transfer through a 8/16 bit port(oh sorry i forgot, the 68k has nothing like this ) . ..it's not as common as the ADD instruction for instance (oh my bad, the 65C816 doesn't have ADD instruction )