nesdev.com

i agree .


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

What is the ROM speed of SA-1 games?

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

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.

You forgot math operations that need decimal mode ,very useful for games .

@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.

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 .


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


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 .


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 .


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 .

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

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:

Vs hu6280


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 .

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


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

To be honest Touko i really don't understand your interventions, your replies are always out of focus :



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.




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




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



The only valuable information in this thread is here :



Exactly what we said earlier...

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.


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 .


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 .

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



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

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


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

Thanks but i know...



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



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 )

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 .


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 .


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