Printable View
Ok i decided to open a new thread to speak about the 68000 vs 65x series CPU debate :)
By 65x i assume whatever is derived from the 6502 architecture.
My point of view is that the 65x is a really weak CPU architecture, for me it's only strength is its price but except that it is really an inefficient CPU and i will try to explain why.
So first i reintegrate last posts between Tom (tomaitheous) and me which started on Let's Compare (Road Rash) topic and derived on CPU debate :)
I agree the GBC custom Z80 is not as powerful than the classic Z80 but the GBC Z80@2 mhz slower than the 6502 @1.79 Mhz ?!? No way...Quote:
Originally Posted by tomaitheous
I would say that even at 1Mhz (or 4 Mhz depending how you see it) the GBC cpu is already on part if not faster than the NES 6502.. The fastest 6502 instruction still requires at minimum of 2 cycles where it requires 1 cycle (or 4 depending your view) on the GBC cpu.
And the GB, unlike the NES, requires graphics data to be transfered to the VRAM (ok it has a DMA for that but still).
Given the GB games library (i'm thinking about last generation games as Donkey Kong country, Zelda or Wario land games) you can easily see the GB/GBC cpu is not that weak...
Again i don't really agree on this one :p Well, i can eventually accept "equals" but i believe that in hand of good programmer the Z80 can do a bit more than the 6502.Quote:
A stock 6502 at 1.79mhz easily competes with and can exceed a z80 at 3.58mhz.
But the point for me here is that the 6502 @1.79 Mhz requires a much faster RAM than a 3.58 Mhz Z80.
Of course the 6502 is cheaper, so maybe you can spent more and get faster RAM but then you have to consider others aspect as the ease of development, high level language support (as C).
Yeah, indeed the 65816 is a 16 bits extended 65C02 ;)Quote:
The 65816 is more than just the original 6502 with 16bit extensions. The 65C02 is a nice step up from the original 6502 (on paper it doesn't look so much, but in practice it is), and the 65816 has additional opcodes on top of the 65C02. So yeah, the '816 is a little more than just a '6502' with 16bit extensions.
Of course, i never meant it couldn't do better than the SMS version, i just wanted to point that it had to use pre scaled sprites at least, a better port comparison would have been the Amiga version so. At 3.1 Mhz, the 65816 is indeed much more powerful than the Z80 @3.58 (i would say it's probably twice as fast, maybe a bit more).Quote:
The SNES could have easily done something better than the SMS port. Even at low clock speed of fast-mode 3.1mhz (not 3.58 because work ram has wait states), it's got more than enough processing room to do what the SMS port is doing - and more.
Probably you can mix a bit of vertical stretching which is a lot faster to do than horizontal scaling indeed, i don't know how much you can do with sprite tuck however, given the number of sprite, it can quickly become something really heavy to compute actually (the position but also rebuild all the sprites from 8x8 tiles as the SNES only handle square sprites).Quote:
Definitely prescaled sprites, but with 128k work ram and more rom space - you'd get better frame intervals than the SMS version. The SNES could easily mix realtime vertical scaling on existing prescaled frames, to add more fluid scaling in between said prescaled frames (something easily done for planar). There's also the sprite 'tuck' method that can create in between 'scaled' frames, horizontally, for prescaled objects.
I've to admit it is not a game that i played too much but at least i always had a pleasant feeling playing it because of the smooth scaling (you can easily see it when you fall from your bike and have to run to get back on it) and the advanced road rendering (which is more than simple raster rendering) even if the animation is a bit choppy.Quote:
Never liked this series, regardless of the platform. But it is a cool technical feat, I guess. I would have never guessed that RR1 on the Genesis was doing real time scaling, because of the serious choppy frame rate. It almost negates doing real time scaling. Almost.
reply from tomaitheous:
You should take a second look at the GB-CPU instruction set. Whew.. it's minimal. Even with low cycle counts, the instructions for that kind of architecture is pretty limiting. I mean, this isn't even a z80 (GB-cpu is much closer to a 8080). And at 1mhz, there's no way it's on the same level at the 6502 @1.79mhz. Yeah, maybe for the GBC I kind of understated the benefit of the 2mhz clock, but it is the exact same minimal instruction set.
Here's a basic example:
vsCode:ld a,(addr1) ;3
ld hl,#addr2 ;3
add a,(hl) ;1
ld (addr1),a ;3. So 10cycles for 1mhz and ~18 cycles in equivalent 6502@1.79mhz cycle times
Yeah, not a whole lot faster on the 6502 side. But you wasted an address vector (reg pair), which has more of an impact on the 8080/z80 arch for obvious reasons. The 65x arch has up to 128 16bit address vectors, if you so desired it. You rarely push/pop stuff on the stack on the 65x, and this is one reason. On the 8080/z80, you start juggling stuff and pushing/popping the stack. The 8080/z80's weakness, is for its architecture type (reg based operations) - is that it doesn't have enough registers. It's the bottle neck of the design IMO.Code:lda abs ;4
clc ;2
adc abs ;4
sta abs ;4 = 14
The 6502 can easily extend it to something like this (which is very common).
or this..Code:lda addr1,x ;4
clc ;2
adc addr2,y ;4
sta addr1,x ;4 = 14
or even this..Code:ldx addr,y ;4
lda table,x ;4
As well as indirect indexed ( LDA [Vector],y ). When you scale for more complex code, the 6502 pulls ahead.Code:ldx addr,y ;4
lda table1,x ;4
tax ;2
lda table2,x ;4
The indexing might be small (they don't have to be 256byte aligned either), but it's extremely fast (indexing itself is free). LUTs are the magic elixir of the 65x. Hell, I've used small LUTs to handle the MSB vector and bank for address calculation for larger LUT access - it's super fast. The 65x might be labeled as an Accumulator based processor, but really it's just means it's a memory-memory operation processor (with the accumulator being the intermediate); sooo many operations can be done against the Acc reg directly from memory (or indexed, or indirect indexed, etc). Not mention other exploits (automatic Flag updates from simple loading a register; N,V,Z flags), etc.
Don't get me wrong; the 65x is limited compared to the 65c02 and higher (those additional instructions/address modes really help out a lot given the style of coding on the processor). And I have to remind myself of this from time to time (usually working with 65x processors that are 'C02 or higher), but the original 6502 has all of the core strengths of the design. Both the 6502 and GB-CPU have a small instruction set, but the advantage is on the 6502 side is with the addressing modes for the instructions and less bottle necks for the processor architecture/design.
The NES has the option for vram and vrom; many games use vram (Battletoads, 5 of the megaman games, all the final fantasy games, etc). So in those cases, graphics do have to be transferred to vram. The GB has a big advantage here though, because vram on the GB is actually local mapped in the 16bit cpu address range (kinda rare for console style devices of the time). And the GB-CPU has DMA unit that has access to the whole 16bit cpu address range as well (so vram as well). Coupled with the fact that the GB has less resolution to deal with (smaller display area), can translate into less cpu resource or easier/faster optimizations. The GB strengths lay with its interfacing hardware and overall design; not really the processor. I like the GB/C system; I coded quite a bit for it back in 1999-2001 (before any other console type systems). I think it's a great design (clean and straight forward). And the processor is adequate for what it is. But the processor is what it is; a hacked 8080 processor with a limited ISA for its arch-type. If you're specifically doing bitmap drawing effects (software blitting) at the given GB screen resolution, then relatively speaking the GB 1mhz CPU is might be faster for the task than NES at its native resolution. But in absolute terms, and a normal game engine, I would say that it's behind.Quote:
And the GB, unlike the NES, requires graphics data to be transfered to the VRAM (ok it has a DMA for that but still).
Given the GB games library (i'm thinking about last generation games as Donkey Kong country, Zelda or Wario land games) you can easily see the GB/GBC cpu is not that weak...
Both true statements, but also irrelevant for this discussion. What is required by the core hardware design is irrelevant, because what is relevant is the hardware set in place and the design of code around it. Yes, the z80 has it's strengths for designing a system with a processor that doesn't hog the bus, but we're not discussing make a system. We're discussing the capability of code in relation to a fixed hardware platform and by extension - all available exploits. I think C is relevant to the GBC (given the year) in general game application, but again this not relevant when it comes to writing something specific like this; assembly is where it's at when you need every ounce of speed.Quote:
Again i don't really agree on this one Well, i can eventually accept "equals" but i believe that in hand of good programmer the Z80 can do a bit more than the 6502.
But the point for me here is that the 6502 @1.79 Mhz requires a much faster RAM than a 3.58 Mhz Z80.
Of course the 6502 is cheaper, so maybe you can spent more and get faster RAM but then you have to consider others aspect as the ease of development, high level language support (as C).
Well, it has some more instructions as well as a new addressing mode (stack+index). And it now has a few new long addressing modes (including indirection), so you can directly access data outside a banking system. Though these things are more high level friendly stuff IMO, or for convenience rather than speed. I'm not a big fan of the 65816 (I don't think they went far enough, and I think the multiplex data bus is retarded), but I recognize that it still has the same core strengths of the 65x series. And that makes it fairly powerful in the right hands. But yeah, a 16bit data bus would've made that processor stupidly fast. Completely missed opportunity. On a side note: It'd be funny to see what existing Genesis games would do at SNES clock speeds for the 68k (2.68mhz and 3.1mhz).Quote:
Yeah, indeed the 65816 is a 16 bits extended 65C02
If I were to approach this on the SNES, I'd have separate routines that are specific to the metasprite size needed to display that specific object. It's more about memory locations and the flow of writing to it. Snes sprites are stored as 8x8 columns, so that might help some. The '816's fast access to LUTs should help speed things up for anything that can be precalculated. The devil is always in the details, but sometimes the devil looks the other way :DQuote:
Probably you can mix a bit of vertical stretching which is a lot faster to do than horizontal scaling indeed, i don't know how much you can do with sprite tuck however, given the number of sprite, it can quickly become something really heavy to compute actually (the position but also rebuild all the sprites from 8x8 tiles as the SNES only handle square sprites).
Anyway, putting aside all these muddling of processors for a minute; what really makes or breaks a system, and the effect your going for, is going to be highly dependent on the supporting hardware. The Genesis gets a very nice boost to certain type of effect simply because the tile format is packed pixel (and lesser extend 8x8 cell layout for sprite sizes). I would saw more than the processor itself. Planar pixel format, (composite format, sequential planar, or consecutive planar format) doesn't lend itself to much in the way of effects.
This is what I was thinking. But I was thinking more in terms of, you spend more time at fast speed than at slower speed. So you really don't get the full benefit of real scaling. I personally would rather have a faster framerate with prescaled sprites, and than real scaling at a choppy or low frame rate.Quote:
I've to admit it is not a game that i played too much but at least i always had a pleasant feeling playing it because of the smooth scaling (you can easily see it when you fall from your bike and have to run to get back on it) and the advanced road rendering (which is more than simple raster rendering) even if the animation is a bit choppy.
I looked at the GB CPU instruction set, it seems they removed the extra set of register, the useless (imo) IX, IY index registers and the block processing instructions, except that you almost have everything else... and some nice bonus: they added LDH xx and LD (C) instructions which are quite interesting. They somehow correspond to the zero page addressing mode of the 6502 except here it's the "last page addressing" and only for loading/storing operation.Quote:
Originally Posted by tomaitheous
Honestly for me they removed almost all the useless stuff of the Z80 (except the extra set of register). IX and IY are useless because too slow and the same for block processing instruction (faster to use the stack pointer for fast copy for instance).
I do agree the Z80 design is bad, i really don't like this CPU and always have some hard time developing my sound drivers... but the problem is not really the number of register itself but more the instruction set ! All operations has to pass by the A register, mean you often have to transfer stuff in A before being able to operate on it. For me this CPU has a very unbalanced instruction set making the register usage not as powerful as it could be ! Also IX and IY are totally useless, of course they are practical for writing code but you *never* use them if you want to have fast code ! Definitely having removed them from the GB CPU is not a big deal :pQuote:
Here's a basic example:
vsCode:ld a,(addr1) ;3
ld hl,#addr2 ;3
add a,(hl) ;1
ld (addr1),a ;3. So 10cycles for 1mhz and ~18 cycles in equivalent 6502@1.79mhz cycle times
Yeah, not a whole lot faster on the 6502 side. But you wasted an address vector (reg pair), which has more of an impact on the 8080/z80 arch for obvious reasons. The 65x arch has up to 128 16bit address vectors, if you so desired it. You rarely push/pop stuff on the stack on the 65x, and this is one reason. On the 8080/z80, you start juggling stuff and pushing/popping the stack. The 8080/z80's weakness, is for its architecture type (reg based operations) - is that it doesn't have enough registers. It's the bottle neck of the design IMO.Code:lda abs ;4
clc ;2
adc abs ;4
sta abs ;4 = 14
Ok now, take a look on your code... Taking a simple isolated operation as this "adding 2 variables in memory" is never a good candidate to compare CPU and you know it. Of course the 6502 often has the edge here as this CPU need to work with memory which is not the case of almost every others CPU (where you use register when possible).
Also you miscounted cycles on the GB :
So it is even worst for the GB cpu with 11 cycles... but again that is not a fair comparison.Code:ld a,(addr1) ;3
ld hl,#addr2 ;3
add a,(hl) ;2
ld (addr1),a ;3
Did you saw the LD A, (C) instruction on the GB cpu ? at least they added something interesting in this CPU :pQuote:
The 6502 can easily extend it to something like this (which is very common).
or this..Code:lda addr1,x ;4
clc ;2
adc addr2,y ;4
sta addr1,x ;4 = 14
or even this..Code:ldx addr,y ;4
lda table,x ;4
As well as indirect indexed ( LDA [Vector],y ). When you scale for more complex code, the 6502 pulls ahead.Code:ldx addr,y ;4
lda table1,x ;4
tax ;2
lda table2,x ;4
Also they modified the LDD and LDI instructions which are now finally useful (because they only use the HL register) :p
LDD / LDI, LD (C) instructions takes only 2 cycles where LDH instructions requires 3 cycles.
Honestly i believe that even for indexed accesses the GB CPU has the edge.
I can't see how you can speak about 6502 strengths as this CPU is just very basic with a very limited instruction set, for instance being limited to 8 bits indexing is just painful ! You speak about fast lookup table accesses because of free indexing but that is a biased point of view. It is not that indexing is free, it is that no indexing is generally slow (1 cycle lost for internal technical matter). In term of efficiency this CPU is a disaster and we tend to abuse of indexing to maximize its efficiency... You require and waste so many memory accesses to work with. For instance any minimum instruction eat 2 cycles where it should be 1 cycle (as the CPU accesses BUS memory on each cycle).Quote:
Don't get me wrong; the 65x is limited compared to the 65c02 and higher (those additional instructions/address modes really help out a lot given the style of coding on the processor). And I have to remind myself of this from time to time (usually working with 65x processors that are 'C02 or higher), but the original 6502 has all of the core strengths of the design. Both the 6502 and GB-CPU have a small instruction set, but the advantage is on the 6502 side is with the addressing modes for the instructions and less bottle necks for the processor architecture/design.
I don't totally agree with that... if you truly want to compare a 1.79 Mhz 6502 to the 1 Mhz GB cpu ok but if you are comparing the 6502 CPU against a Z80 derived CPU (and i believe that is also what you are doing when you speak about the advantage of the 6502 in addressing modes) then i think we always should consider why we had this hardware in place. I often heard "Nintendo is stupid, they should have clocked the 65816 at faster clock in the SNES !" but how the hell can they did it ?? The ROM was just not fast enough to feed the 65816...Quote:
Both true statements, but also irrelevant for this discussion. What is required by the core hardware design is irrelevant, because what is relevant is the hardware set in place and the design of code around it. Yes, the z80 has it's strengths for designing a system with a processor that doesn't hog the bus, but we're not discussing make a system. We're discussing the capability of code in relation to a fixed hardware platform and by extension - all available exploits. I think C is relevant to the GBC (given the year) in general game application, but again this not relevant when it comes to writing something specific like this; assembly is where it's at when you need every ounce of speed.
And so a 1.79 Mhz 6502 is already very asking on the memory BUS, a lot more that the 1 Mhz GB CPU and i believe that is why the GameBoy VRAM could be directly mapped on the main BUS for instance. But ok, let say that is not the important point here...
I'm not sure that giving a 16 bits BUS to this CPU would have made it *stupidly* fast :p Of course it would have helped but still at 2.78 Mhz it would be slower than the MD 68000 for instance, even at ~3.1 Mhz (fast ROM speed) it would remain slower.Quote:
Well, it has some more instructions as well as a new addressing mode (stack+index). And it now has a few new long addressing modes (including indirection), so you can directly access data outside a banking system. Though these things are more high level friendly stuff IMO, or for convenience rather than speed. I'm not a big fan of the 65816 (I don't think they went far enough, and I think the multiplex data bus is retarded), but I recognize that it still has the same core strengths of the 65x series. And that makes it fairly powerful in the right hands. But yeah, a 16bit data bus would've made that processor stupidly fast. Completely missed opportunity. On a side note: It'd be funny to see what existing Genesis games would do at SNES clock speeds for the 68k (2.68mhz and 3.1mhz).
Also i wonder what you mean by "what existing Genesis games would do at SNES clock speeds for the 68k (2.68mhz and 3.1mhz)" ?
Are you really asking what the 68000 could do at 2.68 or 3.1 Mhz ?? Many people tend to compare CPU based on their clock speed... but that is totally absurd and wrong ! That's exactly the problem of the 65x02 series for me, you have to consider what a CPU can do in a given architecture / hardware and actually in every case a 65x02 CPU will do less (and actually *far* less) than a 68000 because of its cheap but also inefficient design. You can't clock the 65x02 at the same speed as the 68000 or the Z80, even if the CPU supports it the rest of the hardware don't ! If we consider in term of memory speed, the Genesis 68000 run at 1.92 Mhz. Then compare what the genny 68000 can do at "1.92 Mhz" to the 2.78 Mhz 65816... Considering again the memory speed the SNES could have get a ~12Mhz clocked 68000 (as do the MD actually) and so it would blast away the 65816.
Of course a 7 Mhz 6502 is fast, it can be faster than a 7 Mhz 68000 in many case (and overall almost on part) but look at the memory requirement for this CPU, look at the small amount of fast memory NEC had to put in the PCE to cut costs (8 KB which is as much as the old Master System and 8 times less than the MD).
Of course the linear/packed pixel format helps a lot on Megadrive ;) I mentioned it when i said the SNES could not replicated the scaling, both because of the CPU and the planar format. But honestly, why the SNES is using planar format when the Megadrive was already able to use packed pixel format ? that is another weak point of the SNES graphic hardware for me... back in time we used planar as it was more common for memory chips but then we moved to linear as it was just more practical. The SNES being released 2 years after the genny they could have used linear graphics memory organization (the mode 7 uses packed format if i remember correctly, for obvious reasons about the rasterizer implementation).Quote:
Anyway, putting aside all these muddling of processors for a minute; what really makes or breaks a system, and the effect your going for, is going to be highly dependent on the supporting hardware. The Genesis gets a very nice boost to certain type of effect simply because the tile format is packed pixel (and lesser extend 8x8 cell layout for sprite sizes). I would saw more than the processor itself. Planar pixel format, (composite format, sequential planar, or consecutive planar format) doesn't lend itself to much in the way of effects.
True, i agree on this one, RR frame rate is choppy... But for me prescaled sprites with smooth frame rate looks ugly and choppy too because of the wrong speed feeling.Quote:
This is what I was thinking. But I was thinking more in terms of, you spend more time at fast speed than at slower speed. So you really don't get the full benefit of real scaling. I personally would rather have a faster framerate with prescaled sprites, and than real scaling at a choppy or low frame rate.
reply from tomaitheous:
Stef: I would have posted much more, but this isn't a CPU VS thread. I tried to keep it minimal. Sorry for the late reply (school and such).
Actually, I did miss count the cycles for GBCPU (got the cycle and byte listing backwards). It's actually:
It's 13 cycles (instead of the 10 I posted), or 23 cycles in 6502@1.79mhz cycle times. And I didn't think that worked against it originally; I thought it showed that they were more comparable (though it looks a little worse now)Code:ld a,(addr1) ;4
ld hl,#addr2 ;3
add a,(hl) ;2
ld (addr1),a ;4
Actually, it's a common operation. It was a simple and common example, that allowed me to extend into something more complex, but still common (I mean, array access is a common thing). It was to show a glaring weakness of the processor; It's not that everything needs to pass through the A register for operations, but that those logical operations supporting the A register - don't have direct memory addressing modes (and to a more important extent, direct memory+indexing). Just look at add, compare, sub; only three addressing modes on the GB-CPU for A. Even loading/storing A register (which gets the most use, since everything passes through it), only has three addressing modes. The original 6502 has 8 addressing modes for instructions that effect the Acc reg. Those additional addressing modes can translate into not having to load another register just to complete an operation. That's an immediate savings, but it also plays back into the larger design (and overhead). The GBz80 is weak in addressing modes overall (other instructions) by comparison.Quote:
Ok now, take a look on your code... Taking a simple isolated operation as this "adding 2 variables in memory" is never a good candidate to compare CPU and you know it.
Yeah, I saw those. At first glance they look useful, but then you see that addressing mode (GB zero page) isn't used for logical operations. They only save one byte or cycle, here or there. LDH would have been useful if it could load to other registers (again, effective address mode problem). LD (C) is interesting, but it's really just indexing into GB zero page: ld ($ff00+c) = lda zp,x. Not indirection as it might appear and would be more useful; lda [zp,x].Quote:
I looked at the GB CPU instruction set, and except the extra set of register and the useless (imo) IX, IY index registers, you almost have everything else...
Also you have the LDH or LD (C) instructions which is quite interesting and somehow correspond to the zero page addressing mode of the 6502 (but only for loading/storing)
Indexed? Really? Sure, it's been years since I've coded on the processor - but just looking over it now, I see absolutely nothing that gives it the advantage of indexing. Matter of fact, it has no indexing what-so-ever in this context (SP+8bit offset is technically indexing, but that's hardly a qualifier).Quote:
Did you saw the LD A, (C) instruction on the GB cpu ? at least they added something interesting in this CPU
Also the modified they LDD and LDI instructions which are now finally useful (because they only use the HL register)
LDD / LDI, LD (C) instructions takes only 2 cycles where LDH instructions requires 3 cycles.
Honestly i believe that even for indexed accesses the GB CPU has the edge.
That's because you don't know the processor. I never said it wasn't convoluted or complex (how ever that translates to you), but it most definitely has its strengths (that are really underestimated). You're a 68k guy, so you see everything thought that lens. Until you've cut your teeth on the 65x, you can't accurately speak on its strengths and weaknesses. I'm proficient at 65x, not because I love the processor or ISA, but because I understand where the strengths lay. I coded for many other processors, including the 68k. The 68k is probably one of my favorite ISAs, simply because it's dead easy to code for (and get good results). Matter of fact, almost all my macros for 65x assembly - resemble 68k instructions (including labeling ZP areas with 68k register names: A0-A7, D0-D7, etc). But the original 68k isn't the end all, be all. It has its deficiencies, where the 8bit processors can creep up on it (clock for clock). And by 8bit processors, I mean specifically mean 65x, 6809, and 6309.Quote:
I can't see how you can speak about 6502 strengths as this CPU is just very basic with a very limited instruction set, for instance being limited to 8 bits indexing is just painful! You speak about fast lookup table accesses because of free indexing but that is a biased point of view. It is not that indexing is free, it is that no indexing is generally slow (1 cycle lost for obscure reason). In term of efficiency this CPU is a disaster... You require and waste so many memory accesses to work with. For instance any minimum instruction eat 2 cycles where it should be 1 cycle (as the CPU accesses BUS memory on each cycle).
I think the code below speaks for itself:
That's a simple array of 256 objects, all 24bit in length: 16bit whole part (signed) and 8bit fractional part. Hell, that's not even really optimized (only optimized for split tables). I added "ldx #$xx" for simplicity overhead, but it would be much more flexible than that (an index into an array that could skip non entries, which translates into not having to move any data around or resorting an array). This was taken from the 68k vs 65x discussion with Steve Snake. Cycle for cycle, this is even faster than his fully optimized 68k example (32bit adds with auto incrementing). Does my simple 'add' and add with indexing seem more clear now?Code:;24bit add for X and Y. 16:8 = 16bit for whole, 8bit for fractional
ldx #$xx ;2
jsr AddVelocity ;6
AddVelocity:
lda x_float,x ;4
clc ;2
adc x_float_inc,x ;4
sta x_float,x ;4
lda x_whole.l,x ;4
adc x_whole_inc,x ;4
sta x_whole.l,x ;4
lda x_whole.h,x ;4
adc x_whole_inc.h,x ;4
sta x_whole.h,x ;4 = 38
lda y_float,x ;4
clc ;2
adc y_float_inc,x ;4
sta y_float,x ;4
lda y_whole.l,x ;4
adc y_whole_inc,x ;4
sta y_whole.l,x ;4
lda y_whole.h,x ;4
adc y_whole_inc.h,x ;4
sta y_whole.h,x ;4 = 38
rts ;6
;38+38+6+6+2 = 90 cycles
Because they went with a stock 65816. The stock chip was supposed to be drop in replacement/upgrade to the original 6502. That means in order to access a larger address bus, they had to multiplex the upper 8bits on the data bus (intel had been doing this before). That's one (main) reason for faster rom requirements. They could have cut that nearly in half, had they went with a custom 65816 package that eliminated that part (there's no need for it on the SNES). Later snes carts has custom 65816's on them (SA-1) at speeds of ~10mhz.Quote:
I often heard "Nintendo is stupid, they should have clocked the 65816 at faster clock in the SNES !" but how the hell can they did it ?? The ROM was just not fast enough to feed the 65816...
The C64 has local mapped video memory. The 6809 is just like the 65x, memory bus hog, and the CoCo systems had local mapped video memory too. I believe it's the same for Apple II computers as well (65x based).Quote:
And so a 1.79 Mhz 6502 is already very asking on the memory BUS, a lot more that the 1 Mhz GB CPU and i believe that is why the GameBoy VRAM could be directly mapped on the main BUS for instance. But ok, let say that is not the important point here...
Do you know how much usage zeropage gets? So not just every access to rom would be basically cut in half, but access to ZP as well (and indirection).Quote:
I'm not sure that giving a 16 bits BUS to this CPU would have made it *stupidly* fast
I was able to write equivalent code on the 65816 (fast rom: 3.1mhz) that directly compared to the 68k, and even at the slower clock speed the difference wasn't half - it was much closer to 70% mark. If you took the time to look at what cycles per byte on the bus, then you'd see that you would get a near 50% increase in speed (both ZP and rom access). The '816/65x does have overlap; it can fetch a byte from the bus while processing an operation. The current snes cpu at the current fast rom speed with a 16bit data bus, even with wait states on wram, would easily be on par with the 7.67mhz 68k. Even Steve Snake agreed with me that even with the 8bit data bus, simply running the 65816 at the speed of 7.67mhz would smoke the 68k at the same speed (in the context of these consoles).Quote:
Of course it would have helped but still at 2.78 Mhz it would be slower than the MD 68000 for instance, even at ~3.1 Mhz (fast ROM speed) it would remain slower.
Yup.Quote:
I wonder what you mean by "what existing Genesis games would do at SNES clock speeds for the 68k (2.68mhz and 3.1mhz)" ?
Are you really asking what the 68000 could do at 2.68 or 3.1 Mhz ??
Yeah? So do RISC processors. The original 68k has both powerful instructions and addressing modes, but it also has long execution times on average; it's got some fat with that muscle. The 65x series is lean and fast.Quote:
Thats is exactly the problem of the 65x02 series for me, many people tend to compare them based on their clock speed... but that is totally absurd ! You have to consider what a CPU can do in a given architecture / hardware and actually in every case a 65x02 CPU will do less (actually far less) than a 68000 because of its cheap but inefficient design.
The PC-Engine would like to say hello.[/QUOTE]Quote:
You can't clock the 65x02 at the same speed as a 68000, even if the CPU supports it, the rest of the hardware don't !
Good idea! It was derailing the other thread anyway.
So, to kinda set the rules for this comparative discussion - what is the context of this processor comparison? Is this primarily 16bit platforms, or rather consoles? Because the 68k clearly has a LOT of advantages in a computer/OS environment that 65x do not (for obvious reasons). Is it only 65x based and 68k, or is z80 included (though that would entail talking about traditional 8bit consoles)?
As far as context, while it would be about CPUs - we could still talk about the surrounding hardware that might aid or give a disadvantage (usually video, and all exploits that go along with it. I.e. is the video making up for a processor deficiency or adding to it?).
Not that I have much to add to this thread, but this is pure Z80 CPU grunt (besides the scrolling):
https://www.youtube.com/watch?v=CvF8lNdkgJ0
Just to reply you Tom about the purpose of this topic: my point of view it's just to expose why the 6502 (and derived) is a *bad* CPU :p It may sound a bit aggressive and sorry for that but I often read 6502 is a good and powerful CPU as instructions execute in few cycles compared to the 68000 for instance. For me that is a total non sense and i want to clarify why :)
And so here it is my long reply to your last big post :
Ok now we have a dedicated topic, you can take your time :)Quote:
Stef: I would have posted much more, but this isn't a CPU VS thread. I tried to keep it minimal. Sorry for the late reply (school and such).
Indeed it's even worst, as the original was 13, rounded to 4 cycles give 16 cycles as so ld a,(addr) is 4 cycles...Quote:
Actually, I did miss count the cycles for GBCPU (got the cycle and byte listing backwards).
...
It's 13 cycles (instead of the 10 I posted), or 23 cycles in 6502@1.79mhz cycle times. And I didn't think that worked against it originally; I thought it showed that they were more comparable (though it looks a little worse now)
Quote:
Actually, it's a common operation. It was a simple and common example, that allowed me to extend into something more complex, but still common (I mean, array access is a common thing). It was to show a glaring weakness of the processor; It's not that everything needs to pass through the A register for operations, but that those logical operations supporting the A register - don't have direct memory addressing modes (and to a more important extent, direct memory+indexing). Just look at add, compare, sub; only three addressing modes on the GB-CPU for A. Even loading/storing A register (which gets the most use, since everything passes through it), only has three addressing modes. The original 6502 has 8 addressing modes for instructions that effect the Acc reg. Those additional addressing modes can translate into not having to load another register just to complete an operation. That's an immediate savings, but it also plays back into the larger design (and overhead). The GBz80 is weak in addressing modes overall (other instructions) by comparison.
Again that is a biased comparison for me, you definitely can't compare CPU on that type of operation or more precisely of an isolated operation of that type. With a 6502 you tend to do it *a lot* as you don't have the choice: you work with memory and only memory. With others CPU you do it less, far less actually... in my 68k code i very rarely use that piece of code as for these CPU it's indeed quite inefficient to do that (as with the GB cpu). Honestly I think you are terribly biased to the 65x habits :p And you just prove it with the A register thing, you said the problem is the lack of addressing modes with the A operation, that is your point of view because you are used to have more addressing modes on 65x CPU and actually on the classic Z80 you have access to more indexed mode (with IX and IY registers) but it does not help at all, i never use them.
It's just a part of the problem and giving the processor the real biggest issue is that you can't do inter registers operations so the advantage of having many registers (compared to other 8 bit CPU) is somehow wasted. And i don't think the GB cpu is that weak in addressing mode, the simple but efficient (HL) indexing is almost enough for everything. It would be better to have 2 full 16 bits indexing registers but so you can use (C) indexing with last page for that then in this case i honestly think the indexing can be better than in 65x CPU... you also have LD HL, SP+x which is very useful for local variable accesses or LD A, (d8) for fast last page access (equal 6502 ZP access).
Quote:
Yeah, I saw those. At first glance they look useful, but then you see that addressing mode (GB zero page) isn't used for logical operations. They only save one byte or cycle, here or there. LDH would have been useful if it could load to other registers (again, effective address mode problem). LD (C) is interesting, but it's really just indexing into GB zero page: ld ($ff00+c) = lda zp,x. Not indirection as it might appear and would be more useful; lda [zp,x].
Indirection ?? Indirection is a weird feature of the 6502 CPU as it does not have plain 16 bits index registers, it's totally useless on a Z80 based CPU as it is on moderns CPU and i believe that even on 6502 you try to avoid to use it as it's very slow. On a classic CPU you just load the address register then uses it to access value in memory...
But LD A,(HL) *is* indexing ! Of course it is just direct indexing without any offset (absolute or relative) but still it is indexing. The idea of indexing is "iterating on table" and with the new HL post increment / pre decrement the GB CPU is even faster than classic Z80.Quote:
Indexed? Really? Sure, it's been years since I've coded on the processor - but just looking over it now, I see absolutely nothing that gives it the advantage of indexing. Matter of fact, it has no indexing what-so-ever in this context (SP+8bit offset is technically indexing, but that's hardly a qualifier).
You can now do fast memory clear operation with LD (HL+), A
2 (or 8) cycles per byte cleared... you won't be able to do as fast with the 6502.
Honestly maybe i don't know enough this CPU but for sure you really don't know enough others CPU or you are just too biased by your love for this CPU :p I started assembly programming 20 years ago with a... 6502 (on a VIC20) :p Ok i did not made much with this CPU but still i think i have a good experience with CPU assembly in general, i made some 6809, 6800, Z80, Saturn CPU (not speaking of sega saturn CPU but of a very weird and neat 4 bits CPU), ARM, SHx, 680x0, x86, microchips and others i can't remember. I believe i have a good overview of CPU design in general. Also i never said the 68000 is perfect, it could be improved in some ways (with some extra instructions for instance) but still i think it has a very elegant and efficient design with a very powerful and balanced ISA which is definitely not the case of the 6502. Again you can't compare CPU clock to clock (and honestly i'm very surprised you make that mistake), that is definitely not interesting... In this case a Pentium 4 is simply weaker than a pentium 3 ?? Of course not, you have to take others aspects in account, as the memory usage efficiency.Quote:
That's because you don't know the processor. I never said it wasn't convoluted or complex (how ever that translates to you), but it most definitely has its strengths (that are really underestimated). You're a 68k guy, so you see everything thought that lens. Until you've cut your teeth on the 65x, you can't accurately speak on its strengths and weaknesses. I'm proficient at 65x, not because I love the processor or ISA, but because I understand where the strengths lay. I coded for many other processors, including the 68k. The 68k is probably one of my favorite ISAs, simply because it's dead easy to code for (and get good results). Matter of fact, almost all my macros for 65x assembly - resemble 68k instructions (including labeling ZP areas with 68k register names: A0-A7, D0-D7, etc). But the original 68k isn't the end all, be all. It has its deficiencies, where the 8bit processors can creep up on it (clock for clock). And by 8bit processors, I mean specifically mean 65x, 6809, and 6309.
Quote:
I think the code below speaks for itself:
That's a simple array of 256 objects, all 24bit in length: 16bit whole part (signed) and 8bit fractional part. Hell, that's not even really optimized (only optimized for split tables). I added "ldx #$xx" for simplicity overhead, but it would be much more flexible than that (an index into an array that could skip non entries, which translates into not having to move any data around or resorting an array). This was taken from the 68k vs 65x discussion with Steve Snake. Cycle for cycle, this is even faster than his fully optimized 68k example (32bit adds with auto incrementing). Does my simple 'add' and add with indexing seem more clear now?Code:;24bit add for X and Y. 16:8 = 16bit for whole, 8bit for fractional
ldx #$xx ;2
jsr AddVelocity ;6
AddVelocity:
lda x_float,x ;4
clc ;2
adc x_float_inc,x ;4
sta x_float,x ;4
lda x_whole.l,x ;4
adc x_whole_inc,x ;4
sta x_whole.l,x ;4
lda x_whole.h,x ;4
adc x_whole_inc.h,x ;4
sta x_whole.h,x ;4 = 38
lda y_float,x ;4
clc ;2
adc y_float_inc,x ;4
sta y_float,x ;4
lda y_whole.l,x ;4
adc y_whole_inc,x ;4
sta y_whole.l,x ;4
lda y_whole.h,x ;4
adc y_whole_inc.h,x ;4
sta y_whole.h,x ;4 = 38
rts ;6
;38+38+6+6+2 = 90 cycles
Ok, array of 256 to start with, if you want more, you have to add code... anyway, it's just normal that "cycle for cycle" it is faster on the 6502, it *should be faster* on 6502 as this CPU generally work at 1/4 of the clock speed of a 68000 ! It's what i'm trying to explain you :) this CPU cannot work at fast speed just because it accesses BUS at each cycle internal cycle where the 68000 accesses BUS each 4 cycles. That is a *huge* difference, if we count in BUS cycle the genesis 68000 actually runs at.. 1.92 Mhz ! And that would be a more fair "clock to clock" comparison and in this case the 65x CPU are just so bad that it is ridiculous. But still, even trying to compare with the code you posted, i accept the challenge :) Here it is :
88 cycles for the AddVelocity method.Code:
lea AddVelocity, a6 ; 8 (using xxxx(pc))
lea Ret, a5 ; 8 (using xxxx(pc))
...
lea xxxx(a3), a0 ; 8
jmp (a6) ; 8
Ret:
...
AddVelocity:
move.l a0, a1 ; 4
move.l (a0)+, d0 ; 12
move.l (a0)+, d1 ; 12
add.l (a0)+, d0 ; 14
add.l (a0)+, d1 ; 14
move.l d0, (a1)+ ; 12
move.l d1, (a1)+ ; 12
jmp (a5) ; 8
16 cycles for to pointer set and call, you also have 16 cycles for base initialization but in multiple calls you will have it only once. Ok if we compare cycle by cycle i have 104 cycles where you have 90 cycles. I used register for fast calling / return as the 68k is slow for call / return sequence but in real situation you will use that type of optimization when you call billion of time a small routine as this one. So of course in term of number of cycle you have the edge but again a 65x CPU is not meant to run at same speed than a 68000, and even in this particular case you can see you don't have a big advantage in number of cycles compared to the 68000.
Now let's see how you would normally do it on a 68000, just assuming you need to update the position on many objects :
So now we have 90 cycles by object proceed and i could probably optimize it by using movem sequence but i don't care too much here. With the 65x you will experience problem if the array cross 256 bytes bounds so you have to prepare / split arrays (and so spent some extra cycles here and there).Code:lea xxxx(a3), a0 ; 8
move.w #xx, d7 ; 8
.loop:
move.l a0, a1 ; 4
move.l (a0)+, d0 ; 12
move.l (a0)+, d1 ; 12
add.l (a0)+, d0 ; 14
add.l (a0)+, d1 ; 14
move.l d0, (a1)+ ; 12
move.l d1, (a1)+ ; 12
dbeq d7, .loop ; 10
The fast rom is needed because of fast bus cycle on 65x CPU and just for this reason... I don't even speak about having a real 16 bits bus on the SNES, it would have raised costs and required modifications of the standard 65816 package.Quote:
Because they went with a stock 65816. The stock chip was supposed to be drop in replacement/upgrade to the original 6502. That means in order to access a larger address bus, they had to multiplex the upper 8bits on the data bus (intel had been doing this before). That's one (main) reason for faster rom requirements. They could have cut that nearly in half, had they went with a custom 65816 package that eliminated that part (there's no need for it on the SNES). Later snes carts has custom 65816's on them (SA-1) at speeds of ~10mhz.
SA-1 came *very late* (1995) and was very expensive ! I remember all games including SA-1 chip were quite expensive on SNES. And yet, the SA-1 include a tiny 2 KB of fast ram (to feed the fast 65816) which was directly integrated into the die... nothing comparable to what the SNES could have when it was released.
Yeah and because of that the CPU was running at only 1Mhz or even less !Quote:
The C64 has local mapped video memory. The 6809 is just like the 65x, memory bus hog, and the CoCo systems had local mapped video memory too. I believe it's the same for Apple II computers as well (65x based).
Again you are trying to compare these CPU at same speed which is definitely not fair...Quote:
I was able to write equivalent code on the 65816 (fast rom: 3.1mhz) that directly compared to the 68k, and even at the slower clock speed the difference wasn't half - it was much closer to 70% mark. If you took the time to look at what cycles per byte on the bus, then you'd see that you would get a near 50% increase in speed (both ZP and rom access). The '816/65x does have overlap; it can fetch a byte from the bus while processing an operation. The current snes cpu at the current fast rom speed with a 16bit data bus, even with wait states on wram, would easily be on par with the 7.67mhz 68k. Even Steve Snake agreed with me that even with the 8bit data bus, simply running the 65816 at the speed of 7.67mhz would smoke the 68k at the same speed (in the context of these consoles).
Even at 3.58 Mhz the 65816 already ask faster memory than the Genesis 68000, it's why the fast rom were not available immediately (too expensive).
But ok, for me at ~3.1Mhz the 65816 is only about 50% of the performance of the 7.7 Mhz 68000, maybe a bit more but definitely not 70%. And with a 16 bits you only make it a bit faster, not that much ! Or you need to heavily modify the CPU architecture so it accesses BUS only half time (each other cycle) and have 2 bytes queue so you can increase its speed greatly by just clocking it at double clock rate :) But unfortunately the CPU is based on 65x architecture so that was not a possible solution.
Of course you can always find piece of code that fits better to 65816 but generally the 68000 will be faster and in worst case the 68000 can be *a lot* faster (multiplication / division, 32 bits operations, memory set/copy...) ! I'm ready to compare whatever piece of code you want to throw :p And i don't compare in cycle but just in CPU efficiency, already accepting fast rom speed is "kind" as the 68000 use slower speed memory to work at 7.67 Mhz :p
The 68000 was designed to work that way and it was efficient, again everything lead to the whole architecture. When you have a 2 Mhz memory you have choice between a 8 Mhz 68000 or a 2 Mhz 65816, i think the choice is quite easy here ! The 68000 will give *a lot* more.Quote:
Yeah? So do RISC processors. The original 68k has both powerful instructions and addressing modes, but it also has long execution times on average; it's got some fat with that muscle. The 65x series is lean and fast.
Then you have costs, that is the only big advantage of the 65x CPU, it was very cheap... so you could eventually use faster memory (as does the PCE) but that does not mean the 6502 is better for that reason. The CPU itself is crap but its low price allow to somehow compensate it.
Haha, yeah... can you recall me the ridiculous amount of main memory we have in PCE ? ;) As much than in the Sega Master System which is out 2 years ago and half of its price. The Hu-Card capacity were also pretty limited for that simple reason too, very expensive fast rom required by the fast Hu6280. Hopefully NEC was producing the memory itself so they could afford a such fast memory at reasonable cost but still it was (imo) something really hurting in the general design of the system ! The PC-Engine was almost the same price as the Sega Legadrive even if the later was much more advanced so definitely for me the 6502 is a bad CPU in almost every aspect... Very painful to code with, inefficient in term of memory usage, not usable with high level compiler. Its only advantage : price. But of course if it's cheap you have to pay it somehow ;)Quote:
The PC-Engine would like to say hello.
Awesome scrolling gam :) When you think the CPC does not have any assistance for scrolling it's really impressive :)Quote:
Originally Posted by Kamahl
It does actually, sort of, it would be impossible for the game to be that fast otherwise (moving 16k of memory around is too much).Quote:
Originally Posted by Stef
The CPC can scroll per tile. What it lacks is an "adjust" register to do pixel smooth movement. You can get 4 pixel scrolling (or 2 wide pixels) with screen adjustment tricks (MSX2 style). And you can get the final 2 pixel (or 1 wide pixel) scrolling by keeping a shifted copy of the framebuffer and sprites.
This is doing everything (including the scrolling and the sound effects) with the Z80:
https://www.youtube.com/watch?v=zoDPU8fXKZY
For comparison with the 6502, the C64 can't update its entire character screen (including the colours) in 1 frame while having game logic. That's around 2k of memory.
That game above is updating around 7k of memory, plus the sprites, without double buffering, in 2 frames.
Yeah i do remember about the 4 pixels scrolling stuff in CPC, i had a talk with some CPC gurus doing a R-Type remake with smooth scrolling. They had to have 4 copies of the background graphics to make smooth scrolling but it was really impressive.
So Zynaps is 100% pure soft handled ? It looks so smooth :) the 1bpp graphics mode help here :D
Yup, 100% software. Cobra, Crosswize, Cobra Force and Dark Fusion are other ZX spectrum games with really smooth scrolling.Quote:
Originally Posted by Stef
I also exaggerated the amount of memory they're moving around a bit since they have those status bars. It's more like 5k of data, plus the sprites.
I have programmed with 6502, especially for Atari2600, Atari5200 and some Nes. Programming for Atari2600 you learn to count cycles, because you NEED to count cycles and that's why I know the instructions and cycles of the 6502, and perhaps that's why I'm all the time looking to optimize any code that I do, regardless of the type of CPU.
This is actually 96 cycles because "Sta abs, x" is 5 cycles (with HU6280 would be even more cycles, because the "lda abs, x", "adc abs, x" and "sta abs, x" are 5 cycles , plus the jsr and rts are 7 cycles).Code:;24bit add for X and Y. 16:8 = 16bit for whole, 8bit for fractional
ldx #$xx ;2
jsr AddVelocity ;6
AddVelocity:
lda x_float,x ;4
clc ;2
adc x_float_inc,x ;4
sta x_float,x ;4
lda x_whole.l,x ;4
adc x_whole_inc,x ;4
sta x_whole.l,x ;4
lda x_whole.h,x ;4
adc x_whole_inc.h,x ;4
sta x_whole.h,x ;4 = 38
lda y_float,x ;4
clc ;2
adc y_float_inc,x ;4
sta y_float,x ;4
lda y_whole.l,x ;4
adc y_whole_inc,x ;4
sta y_whole.l,x ;4
lda y_whole.h,x ;4
adc y_whole_inc.h,x ;4
sta y_whole.h,x ;4 = 38
rts ;6
;38+38+6+6+2 = 90 cycles
The loop of this routine can be faster:
Code:lea xxxx(a3), a0 ; 8
move.w #xx, d7 ; 8
.loop:
move.l a0, a1 ; 4
move.l (a0)+, d0 ; 12
move.l (a0)+, d1 ; 12
add.l (a0)+, d0 ; 14
add.l (a0)+, d1 ; 14
move.l d0, (a1)+ ; 12
move.l d1, (a1)+ ; 12
dbeq d7, .loop ; 10
In this example the loop is 74 cycles. :)
Code:.loop:
move.l (a0)+,d0 ; 12 X_inc
move.l (a0)+,d1 ; 12 Y_inc
add.l d0,(a0)+ ; 20 X += X_inc
add.l d1,(a0)+ ; 20 Y += Y_inc
dbra d7, .loop ; 10
I generally agree on IX and IY. 9 extra cycles for most extra instructions compared to the equivalents using HL isn't worth it in most cases. Maybe it's different when you're coding for size and you actually need the offset for some reason. I think it would have been better if they just dropped the replacement. A 4 cycle penalty for an HL-like register is much easier to swallow IMHO.Quote:
Originally Posted by Stef
Not sure why you're so down on the block processing instructions though. I can see why you didn't use them in your 4-PCM driver: you didn't need the counter so wasting BC for that purpose is undesirable, but it's not really faster. The fastest copy using pop looks something like:
That's 32 cycles to copy two bytes which is 16 cycles per byte assuming you don't need to check for some kind of end condition and you don't need to be able to cross a 256 byte boundary. ldi also takes 16 cycles to copy a byte, but also decrements a counter for you and doesn't have the 256 byte boundary limitation. ldir adds another 5 cycles, but given that you're getting looping, 5 cycles seems pretty cheap. It's also nice for code density since 2 bytes gives you what is basically a memcpy instruction.Code:pop de ;10
ld (hl), e ;7, 17
inc l ;4, 21
ld (hl), d ;7, 28
inc l ;4, 32
As for the actual topic, I find the comparison between the 65XX and the 68000 pretty amusing. As has been stated, at typical clock speeds for each it's not much of a contest. The PC-Engine with it's ~7MHz 65C02 makes things a little interesting, but it's hard to really make a fair comparison between a 16/32-bit CPU and an 8-bit one. The Z80/6502 comparison is more interesting, but at least in the home computer arena the Z80 was clocked typically 3-4X as fast as the 6502 in contemporary systems (presumably due to the RAM constraints Stef mentioned). My fastest Z80 implementation of the little 6502 code sample is 225 cycles and a perhaps more realistic one is 264. On a clock for clock basis, that's terrible, but if we're comparing a 3.5Mhz Z80 system to a 1MHz 6502 it's more like 64-75 cycles (assuming we're normalizaing to the 6502 clock).
Of course, if we're limiting ourselves to consoles the clock ratios are not so bad (only 2X comparing the NES and the Master System) and the 6502 pulls ahead again.
Anyone have any actual price data from the relevant time periods?
Haha well done gasega68k :pQuote:
Originally Posted by gasega68k
I did not even though about putting steps before values... there is always way to optimize more your code ;)