It is currently Mon Apr 23, 2018 4:54 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 177 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12  Next
Author Message
PostPosted: Sat Dec 30, 2017 6:33 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 241
Quote:
Without seeing the dies though its all speculation

i agree .

Quote:
So I guess it could be seen as a 1phase 21Mhz or a 2Phase 10Mhz

Ah, not false, I did not see the SA-1 like that but it does not sound illogical.


Top
 Profile  
 
PostPosted: Sat Dec 30, 2017 10:10 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2605
What is the ROM speed of SA-1 games?


Top
 Profile  
 
PostPosted: Sun Dec 31, 2017 1:47 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 359
Hard to know, the Chips on the photos I could find of SA-1 Board don't seem to have datasheets available, surprise surprise, one however was -11 which might mean 110ns which is too slow for 10.5Mhz. The "Book II" says that when you run from ROM the CPU runs at 10.5Mhz but then also later says in the list of things to will incur a wait-sate - ruining from ROM is listed. However it also lists if the resulting address of a branch is ODD. This makes me think that they have modded the 65816 to have a full 16bit data bus, and done away with the pin plexing for the address while they were at it, then they make it pull 16bits data per access, to which the internal systems then read the 8bits each "tock" like normal. This is could be because if its odd aligned it only grabbed half and you wait while it re-grabs the other half, and it can't hit the ROM at full speed again so fast, you need to wait for the next 5.25mhz window. If it does pull 16bits every 2nd access then that drops the bus to 5.25mhz and 110ns is overkill.

Looking at a pinout it does indeed have 16 data lines...


Top
 Profile  
 
PostPosted: Sun Dec 31, 2017 1:13 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2605
Stef wrote:
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


We can say that, but again you will tend to use more one or the other depending the CPU you are working on...
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)


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.


Top
 Profile  
 
PostPosted: Sun Dec 31, 2017 3:19 pm 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 241
You forgot math operations that need decimal mode ,very useful for games .


Top
 Profile  
 
PostPosted: Mon Jan 08, 2018 8:10 am 
Offline

Joined: Mon Jul 01, 2013 11:25 am
Posts: 242
@touko>Definitely no :p I guess you speak about BCD instructions, imo BCD instructions are totally useless here... you only need it to compute score mainly and some rare others stuff. You need to process score very rarely (less than once per frame) so even if you do it using the slow way (software conversion or LUT) it's never a problem... And i would say that even a 8 bits system (like a NES or SMS) computing visual number which change less than once per frame (score, life) in software isn't a big deal.

@psycopathicteen> If you compare a 4 Mhz vs a 8 Mhz 68000 (i didn't saw it first) i would say there is no context, the 68000 would be faster in a lot of case. I think to make them almost on part you need at least a 5 Mhz 65816 vs a 8 Mhz 68000.


Top
 Profile  
 
PostPosted: Mon Jan 08, 2018 8:20 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 241
Quote:
you only need it to compute score mainly and some rare others stuff.

You compute score each times you need to do .
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 .
For the score and hi-score computation on Z80 / 68k you spend a lot of cycles(even with LUTs),and delaying it too mush is also not good visualy speaking .

Quote:
it's never a problem

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 :lol:

Quote:
If you compare a 4 Mhz vs a 8 Mhz 68000 (i didn't saw it first)

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 .

Quote:
I think to make them almost on part you need at least a 5 Mhz 65816 vs a 8 Mhz 68000.

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 .
They could have even removed the 8 bit bus for a 16 one like mitsubishi did .

Quote:
the 68000 would be faster in a lot of case

And what's your definition of "lot of case" ??
It'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 .

Ps: stef and speaking of misinformations on gamopat is really welcome from a guy like you .
You wrote a lot of false things(and you continue) and don't correct yourself even when some people said you that you're false .


Top
 Profile  
 
PostPosted: Mon Jan 08, 2018 10:21 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19938
Location: NE Indiana, USA (NTSC)
TOUKO wrote:
Quote:
you only need it to compute score mainly and some rare others stuff.

You compute score each times you need to do .
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 .

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.

A compromise is seen in Thwaite, which uses a ones place and a hundreds place. Whenever the ones exceed 100, addScore in bg.s adds 1 to hundreds, and then it marks the status bar as needing to be redrawn (by setting a bit in bgDirty). Later on, buildBGUpdate sees that the status bar contents have changed and reconverts the score and play time, using a fast binary-to-decimal routine optimized for numbers no larger than one byte (bcd8bit in bcd.s).


Top
 Profile  
 
PostPosted: Mon Jan 08, 2018 10:33 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 241
Quote:
No matter how many additions you do in a single frame, you only have to run the binary to decimal conversion once per frame.

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:
Code:
;****************************************************************************
; 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

Vs hu6280
Code:

;----------------------------------------------------------------------------
; 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      
      


it's not free on the 68k and consume "lot of cycles"(lot compared to 65xxx BCD of course) to do without a good BCD mode,and it also help to update the score/hi-score in VRAM .
You spend more cycles for the score/hi-score computation than the overhead for using 32 bits datas for physic on the 65xxx,and with headaches :P .

There is a good thread here (in 68K assembly) :
http://eab.abime.net/showthread.php?t=5 ... hlight=bcd

Quote:
imo BCD instructions are totally useless here..

Hopefully it's only your opinion,unless if you're speaking of the 68k BCD mode !!.


Top
 Profile  
 
PostPosted: Tue Jan 09, 2018 6:27 am 
Offline

Joined: Mon Jul 01, 2013 11:25 am
Posts: 242
To be honest Touko i really don't understand your interventions, your replies are always out of focus :

Quote:
Quote:
If you compare a 4 Mhz vs a 8 Mhz 68000 (i didn't saw it first)

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.

Quote:
I think to make them almost on part you need at least a 5 Mhz 65816 vs a 8 Mhz 68000.

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 .
They could have even removed the 8 bit bus for a 16 one like mitsubishi did .


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.


Quote:
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 :lol:


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...
Do you see how this is ridiculous ? You're trying to prove the 68000 is slow because 68k BCD instructions are slow ? really ? Even tepples try to explain you why computing score isn't an issue, even without BCD instructions. You are programming games but honestly your experience seems quite weak in some area. I don't understand why you are posting methods to compare BCD addition, as tepples said, normally a "smart" developer would keep the score in a normal integer (i assume a 8bit integer won't be enough here :p), then you compute the BCD version only after updating the score and to display it. You will *never* do it more than once per frame so you will *never* care about the performance here (unless you're doing something really insane which eat about 50% of the frame time just to compute a single int BCD conversion :D).


Quote:
It'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 .


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 progress ;)

Quote:
There is a good thread here (in 68K assembly) :
http://eab.abime.net/showthread.php?t=5 ... hlight=bcd


The only valuable information in this thread is here :

Quote:
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.


Exactly what we said earlier...


Top
 Profile  
 
PostPosted: Tue Jan 09, 2018 8:18 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 241
Quote:
Do you see how this is ridiculous ? You're trying to prove the 68000 is slow because 68k BCD instructions are slow ?

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.

Quote:
the problem is memory/ROM speed, not CPU speed

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 .

Quote:
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.

Oooh 42 cycles VS 130, yes, you're right !!
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 .


Last edited by TOUKO on Tue Jan 09, 2018 9:36 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Tue Jan 09, 2018 9:10 am 
Offline

Joined: Mon Jul 01, 2013 11:25 am
Posts: 242
Quote:
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 .


Not without a massive redesign of the chip and raising up the costs a lot (and you don't really double the speed).
I don't see the point speculating about that honestly, you don't really know if it was feasible or not, at which cost --> no point
We're comparing the SNES's CPU versus MD's CPU, not comparing a hypothetical customized 65C816 ...

Quote:
... 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 .


Yeah, because honestly it's just wrong :p
BCD isn't useful to make a game. If you need to display tons of base 10 numbers on display refreshing very quickly i would say "why not..." but in a game we just don't care. I won't debate for days about it...


Top
 Profile  
 
PostPosted: Tue Jan 09, 2018 9:31 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 241
Quote:
Not without a massive redesign of the chip and raising up the costs a lot (and you don't really double the speed).

Like i said stef, you are boring as hell .
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, if you redesign your CPU to be " a 1 phase" like the hu6280 you need RAM to be at the same frequency than the CPU,no cost added or something,all is the same, it's so hard to understand ???
I don't see why you add cost when you don't need to change anything !!

Quote:
Yeah, because honestly it's just wrong :p

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.

Ps: Et pour ta gouverne, je suis parti de gamopat à cause de toi, j'en avais marre de te voir traiter ceux qui pensent pas comme toi, de fanboys, ou de personnes ayant des avis biaisés, ou ce genre de conneries ,surtout venant d'un boulet incapable de voir plus loin que son nombril,et le plus beau c'est que tu continus .
Donc la prochaine foi que tu craches sur moi, évites de raconter n'importe quoi comme à ton habitude STP ..


Top
 Profile  
 
PostPosted: Tue Jan 09, 2018 10:08 am 
Offline

Joined: Mon Jul 01, 2013 11:25 am
Posts: 242
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.


Thanks but i know...

Quote:
if you redesign your CPU to be " a 1 phase"


redesign... do you understand that redesigning the CPU is all except trivial ??
There is a good reason why the 65xx CPU works in 2 phases, it's needed by its internal implementation. 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. You can read this page to learn more about it : http://archaicpixels.com/HuC6280
Also the 65C816 is a different beast and probably not as easy to redesign than a 6502...

Quote:
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.


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 :lol: )


Top
 Profile  
 
PostPosted: Tue Jan 09, 2018 10:18 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 241
Quote:
There is a good reason why the 65xx CPU works in 2 phases, it's needed by its internal implementation

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 .

Quote:
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.

And you know that because you were in the team who's designed the CPU ???
MMU was part of improvements hudson did over the 65C02,like sound and new opcodes,not a consequence .
Hudson did it with his limited team and budget,don't forget hudson was a very little structure and has done all the PCE's chipset alone, i don't think really that nintendo cannot do it easily .
Nintendo went with the standard design for the nes compatibility, nothing else and it was too late to redoing it when compatibility was drop out .

Quote:
it's not as common as the ADD instruction for instance (oh my bad, the 65C816 doesn't have ADD instruction :lol: )

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 :lol: ) . ..


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 177 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group