I think comparing CPU:s only matters when designing *new* hardware, and then, availability and price is going to outweigh performance as long as you can do what you set out to do with it. When it comes to desigining software (homebrew/game), the most important factor to me would be who's going to be able to use/play it.

PC Engine and MSX are special cases then because they're interesting enough in their feature sets that i'd be interested in making something despite that only a subset of game collectors have them.

I'm even surprised that you choose a 1.79 mhz vs a 8mhz Z80 to be sure to be right .The hu6280 destroy litteraly your 8mhz Z80 even with your crappy code examples, and it's a fact, why you don't take this in account ??,not easy here right ??

It's "not easy here" to obtain a HuC6280-based console in the first place. Plenty of stores that offer used NES, GBC, and TI-83 units for sale have no used TG16.

Sorry, maybe i did not use the right expression, i mean by "not easy here" was rather "it's more easy to say that a Z80 is more powerful than a 6502 than with a hu6280".

Quote:

And even if you don't have one, that doesn't change the fact that the CPU exists, which was the only preface to TOUKO's comment.

Yes that was my point,but maybe not well translated in english,i apologise .Here many people know the 6502, some the 65816, ccovell ,tomaitheous and i(and maybe others),we know the hu6280.

It would've made more sense if he said "unnecessary optimization" instead of "premature optimization". "Premature" sounds like you shouldn't make any optimizations early on.

No, thats not his point at all. Everything he talks about in the context that quote applies only to early optimization, and the accumulated effect they then have over the course of the project.

"Avoid unnecessary optimization" would be an unhelpful platitude. Knuth's advice is offering his intuition based on his experience: that mistakes made due to optimizing early are overall more harmful than the mistakes made by not optimizing early enough. It's advice to try to recognize when you're making an early decision like this, consider its long term implications, and if unsure he would probably want to err on the side of optimizing too late.

The reason people optimize early is to avoid optimizing too late: the case where you have to rewrite/refactor a bunch of stuff because the structure of things made it impossible to fix locally. That case is something real to worry about, but Knuth was warning against the long term impact of doing it too early, which in his experience was often overlooked. Over the long term code has to be revised many times, and requirements frequently change, and optimization has a tendency to make code both more difficult to maintain and more specialized in its requirements. On the other hand, most late optimization opportunities are easy local fixes, so the rewrite case is rarer, and even then the time spent in a rewrite might be comparable to the time spent in added maintenance if it had been done earlier. That's the perspective he's trying to share, and it would not at all be intimated by warning merely about "unnecessary" optimization.

It's not at all a statement that you should never optimize early. It is an opinion about which category of mistake is most important to avoid, advice from a seasoned professional about how to weigh hard decisions in code design, not some sort of dogmatic rule.

...and just in case it's not clear, it is talking about a specific kind of optimization: something that makes code faster but more complex. Not all optimization falls into this category, but almost all optimization that a programmer needs to make difficult/critical decisions about does.

A spectrum guy compared some years ago the C64's 6502 @1mhz and the 3.5 mhz in the spectrum .The two CPU was close,and overal the Z80 was ahead(not by far) by his frequency .

But if his tests were done with the nes or A8's CPU (which run @1.79 mhz) no way for a 3.5mhz Z80 to win .It's often common for the Z80 side to take the slowest 6502 computer for comparing,like stef did when comparing the 65xx with other architectures,and pushing his biased mind to do this comparison on a sega forum .

@stef: if you want to discuss how the 6502 architecture is efficient(or not), you must speak with GARTH WILSON .

I think speaking about efficiently of a CPU mean less or more "what can it does with a given memory".The internal speed of the CPU is just matter of implementation, what is important is external / memory frequency... and if we compare on that, a 6502 is definitely not a "efficient" CPU. A 6502@1Mhz is equivalent to a ~3.5Mhz Z80 in term of external frequency, and i think the 3.5 Mhz Z80 can do more than a 1Mhz 6502.A 1.79 Mhz 6502 may be more powerful than a 3.58 Mhz Z80, but it requires faster memory so that is easy.

Same can be said for a 65816 vs a 68000 but the 65816 use a 8 bit bus, making it incomparable to the 68000 CPU from the start.If we want to be more fair for the 65816 we would probably allow it to use memory at twice the speed of the 68000 memory (so compare a 65816@ 3.8Mhz versus a 68000@7.67 Mhz), but then that becomes unfair for the 68000 which always do 16 bit memory accesses... Still, i believe than a 68000@7.67Mhz is already faster than a 65816@3.8Mhz, that shows how much the 68000 is more "efficient".

Wouldn't a lower internal frequency give you more room for overclocking? How fast can you make a 6502 vs Z80 before it overheats? This isn't relevant to any system during the time though.

Stef wrote:

Same can be said for a 65816 vs a 68000 but the 65816 use a 8 bit bus, making it incomparable to the 68000 CPU from the start.If we want to be more fair for the 65816 we would probably allow it to use memory at twice the speed of the 68000 memory (so compare a 65816@ 3.8Mhz versus a 68000@7.67 Mhz), but then that becomes unfair for the 68000 which always do 16 bit memory accesses...

It depends; how much would 8 bit memory cost compared to 16 bit memory at half the frequency?

Stef wrote:

Still, i believe than a 68000@7.67Mhz is already faster than a 65816@3.8Mhz, that shows how much the 68000 is more "efficient".

Although I don't have the best knowlege of the processor, even factoring in the increased utility of each instruction, with the number of cycles per instruction don't see a 7.67MHz 68000 being better than an always 3.8MHz 65816 for a 2D game console. Of course, there's no way to prove this, but it's fun to speculate.

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

question: how long have you been beating this drum and had nobody care and blamed everybody else for not caring, from what i hear you have an old account here from like 2010 or something

also legit why do you think that sprite priority is causing any slowdown, im just, i dont get where the hell you drew that link from

you said, after eliding most of the content of my last post, that this is to

"get rid of the slowdown caused by the non-contiguous OAM."but vanilla SMW doesn't do any sprite priority stuff of note, it just pre-assigns oam slots to sprite slots (btw you should definitely learn how people around here use words or youre going to be talking nonsense to us); the reason we use NSTL is because it runs out of oam slots, not time. the only sprites im aware of with any priority needs are the net koopas and they arent exactly notorious slowdown beasts

im assuming you got the thing about non-contiguous OAM from my post on the NSTL patch, but thats because the NSTL has to allocate tiles, not order them; if youre just ordering them you can treat them as contiguous since having an extra off-screen tile in the middle of your list isn't going to affect the priority literally at all

moreover, you absolute chumpo idiot, i personally have already written a patch that makes the NSTL allocation linear-time, and i didn't need to make 8 oam mirrors to do it, and didnt inexplicably tie oam allocation to creating an oam priority thing.

So in other words, I'm an idiot for thinking SMW allocates sprites in OAM based on sprite priorities? I mean, what the fuck does she think determines what sprite goes on top of what inside the sPPU?

Seems like they passive aggressively sort of ganged up on you, if that's even a thing.

Quote:

(btw you should definitely learn how people around here use words or youre going to be talking nonsense to us)

This was pretty funny. In other words, talk technologically illiterate so they can understand you.

I don't think the majority of them are actually interested in coding, but rather, messing around with a level editor. If they were more interested in the SNES hardware, they'd immediately abandon that pos game engine immediately.

And yes, that girl probably doesn't know anything about the HiOAM table, or cares to learn about it. You're probably wasting you time there, but you already knew that.

Wouldn't a lower internal frequency give you more room for overclocking? How fast can you make a 6502 vs Z80 before it overheats? This isn't relevant to any system during the time though.

Well, overclocking a CPU isn't interesting if externals parts don't follow... In fact you can overclock the Genesis 68000 close to 12 Mhz without too much troubles while i think you can't overclock the 65816 at all as the memory is already close to its limit.Probably you could get a 65816 @5 Mhz back in time (as the PCE was able a 6502 @7Mhz with some modification) but there is no point in doing that if you can't get the ROM working at that speed. In fact ROM cost was the big deal here (not only the RAM).

Quote:

It depends; how much would 8 bit memory cost compared to 16 bit memory at half the frequency?

It's doesn't really cost more to use 8 / 16 memory, you can use 2x8bit memory chip to do a 16bit one... the cost is on the CPU / BUS side here.

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)

Last edited by Stef on Tue Dec 26, 2017 3:33 am, edited 1 time in total.

Probably you could get a 65816 @5 Mhz back in time (as the PCE was able a 6502 @7Mhz with some modification) but there is no point in doing that if you can't get the ROM working at that speed. In fact ROM cost was the big deal here (not only the RAM).

Doing a 1 phase 65816 is not like an overclocking,a classic 6502 design which works in 2 phases accesse to his ram at the speed of CPU x2,and for a 1mhz CPU you need 2mhz RAM .With a one phase you need ram at the same speed than CPU so 1mhz for a 1mhz CPU .So with the same RAM/ROM and a 1 phase 65816 you can go up to 5mhz in the snes without any design change like hudson did .The 1 phase design was useful for other access like video or something else, useful for un Pc which share his main memory, but useless for a gaming system with dedicated VRAM/AUDIO RAM .

PS:To be precise,in 2 phases the accesses were a little bit under 0.5 cycles, and less than 1 cycle in 1 phase.

Quote:

In fact you can overclock the Genesis 68000 close to 12 Mhz without too much troubles while i think you can't overclock the 65816 at all as the memory is already close to its limit.

You're right but there is not much MD that accept this frequency,but you can find all superCPU for C64 which are all 65816 @14mhz overclocked to 20mhz, close to 50% more .The 65816 was by himself very oveclocable, but not in the snes.

Quote:

It's doesn't really cost more to use 8 / 16 memory, you can use 2x8bit memory chip to do a 16bit one... the cost is on the CPU / BUS side here.

it depend of modules available,this is why sega put 8ko of 100ns SRAM for his Z80, completely useless but i'am sure at a very good price because the needs was for the 16/32/64 ko modules and there was so much stocks of 8K modules.i dont' see how it was expensive for nec and faster SRAM was affordable for SEGA, it's a nonsense,and here i'am not even speaking of the snes's audio RAM .

Seems like they passive aggressively sort of ganged up on you, if that's even a thing.

Quote:

(btw you should definitely learn how people around here use words or youre going to be talking nonsense to us)

This was pretty funny. In other words, talk technologically illiterate so they can understand you.

They mean purposely flip flopping the definition of "sprites" back and forth for the sake of disagreeing.

Quote:

I don't think the majority of them are actually interested in coding, but rather, messing around with a level editor. If they were more interested in the SNES hardware, they'd immediately abandon that pos game engine immediately.

And yes, that girl probably doesn't know anything about the HiOAM table, or cares to learn about it. You're probably wasting you time there, but you already knew that.

The people at smwcentral aren't even interested in actual game design. Lets say you have a pyramid level, and you have the idea of having some blocks coming in and out of the walls that you have to make timed jumps to. The very first response you get is "that will cause slowdown!"

Who is online

Users browsing this forum: No registered users and 0 guests

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