That's another thing that bothers me. I hate coming across as a know-it-all if experts in a field want me to believe something that doesn't add up, or sounds politically biased. If I find just one flaw in somebody's logic, people might think I'm a jerk who thinks he's smarter than everyone else, and I just want things to make sense.

I can sympathize with this. I've found that an effective remedy is to approach an argument objectively, and not in a way that is hostile or certain. If you believe you see a flaw in someone's argument, all you have to do is calmly walk through the points of that argument and attempt to follow it through to conclusion. You will almost certainly find a point in the argument you cannot move past, either because you do not understand that point, or that point in the argument is invalid/unsound. Alternatively, you follow it through to conclusion and find it makes sense after all.

Sometimes you need to walk someone else through their own argument and highlight the point in question, prefacing it all with "Perhaps I'm misunderstanding, but..." or "I could be wrong, but...". If you're prefacing your arguments with things like that, people won't think you're a jerk; you're just trying to understand. It's all about diffusing the sense of confrontation, shifting the purpose away from "winning the argument", and more towards "coming to an understanding".

I absolutely hate those one lined so-called "rules". They make absolutely no sense, as if you could summary good and bad programming practice in 5 (or so) lines.

It wasn't a "one line rule" when he said it. I linked the original article it appeared in above.

It is not at all intended as a "rule" against ever optimizing early. It's only the idea that the mistakes of the worst magnitude come from doing so. It's a thing to remember when you're making a difficult decision about optimization, not when the decision to optimize is easy.

In fact, directly preceding the quote in that article, he talks about some cases where you should routinely try to optimize immediately. In context he's not saying anything of the sort you are attributing to it. It's a small part of a much larger, and very practical discussion about optimization (and the point of the article: the place of GOTO in optimization circa 1974).

Maybe the quote is commonly being misused, misapplied, or misinterpreted, I don't know (psychopathicteen's diagram is absurd)... but the point of a quote is supposed to stand in for the larger idea, not encapsulate it entirely. (This is precisely why twitter is so good at fostering arguments; everything is reduced to a "quote" size that can't possibly mean all that it needs to.)

What page of the article is the quote on?

If he is talking about structural optimizations, what does he mean by "small inefficiencies"?

Just to reply on that point : we were speaking about "external" frequency, so basically by saying "the GBC Z80@2Mhz" we meant 8Mhz as internal frequency (GBC CPU is 4 or 8 Mhz)... you should read more carefully the post.After that, maybe you're really thinking that a 6502@1.79 Mhz beat the GBC CPU @8 Mhz (as tomaitheous seems to think)

Still i'm surprised to see that kind of discussion still living here If it can push you to make some awesome demos for the SNES then that is all good

If you really want to compare what you can each CPU, i think the 3D level in Toy Story is a good comparison.Definitely both versions are awesome and has been programmed by very talented developers and i bet than we can hardly do better that what you can see here...

They used mode 7 on SNES so they can use chunky pixel as well. In fact the SNES version is really impressive still the resolution is lower than the Genesis version, the window view is smaller and the H resolution is doubled (better to use emulator to compare). You can make your own conclusions...I know it won't change the point of view of some of you and i don't really care anyway

Last edited by Stef on Thu Dec 21, 2017 12:41 pm, edited 1 time in total.

I've concluded over recent discussions that between the two, the NES's 6502 might win at random access, such as properties of an enemy in physics or AI code or nested metatile decoding. But the GBC's LR35902 wins at sequential access because of things like (HL+) and INC DE, not to mention HDMA to VRAM in the support circuitry.

I don't know much about the plain old 6502 and I know even less about the Z80, but a 6502@1.79MHz beating a Z80@8MHz sounds even more ludicrous than a Z80@2MHz beating a 6502@1.79MHz. Sorry I misinterpreted your post Stef; yeah, that's ridiculous. I agree with what you said about the 3D section in Toy Story; they both probably just about showcase the best each processor can do, or at least close to it. Don't expect this kind of fanboy war to ever go away; I can't say it never gets on my nerves though. However, most of the time I'll actually just bring up relevant technical information and everyone just shuts up.

I've concluded over recent discussions that between the two, the NES's 6502 might win at random access, such as properties of an enemy in physics or AI code or nested metatile decoding. But the GBC's LR35902 wins at sequential access because of things like (HL+) and INC DE, not to mention HDMA to VRAM in the support circuitry.

Are you still comparing the 1.79Mhz vs the 8 Mhz GBC CPU ? There is absolutely no chance the 6502 can win against it, but if you compare to the 4 Mhz one, well... the 6502 may provide faster random access but in the end the bottlenecks always remains in sequential processing code (where you have loop) so you tend to arrange your data structure depending CPU strengths and in the end the winner is the CPU which can process more data (for a same amount of time). Difficult to say which one here...

The thread you started is not if a 1.79mhz 6502 vs a 8mhz Z80 would compete (because it's obvious it cannot) but "Let's compare 65x CPU architecture vs 68000 (or others)"

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

Your comparison with code was also hilarious,you code some bad exemple with bad 6502 code, and you summarise the results with all the processors serie,which is utterly false,but easy with no one who contradicts you, eh, be sure to lunch a comparison thread on a sega forum, the best place for this, without any doubt .When you want a 68K or Z80 vs 65xx comparison, what's the best place than a 65x forum ??

Why not here,were some people can contradict your arguments ??

Ah yes ,you said me that there are only fanboys here.

Quote:

They used mode 7 on SNES so they can use chunky pixel as well. In fact the SNES version is really impressive still the resolution is lower than the Genesis version, the window view is smaller and the H resolution is doubled (better to use emulator to compare). You can make your own conclusions...

Of course, and it's not in your favour,it show that a 2.58mhz 65816 can do raycaster close to a 7.67 68K, and with a one phase custom 65816 @5mhz which don't need to change anything on the system as you like to said on a french forum would crush the 68K in this exercice .

Last edited by TOUKO on Thu Dec 21, 2017 2:40 pm, edited 1 time in total.

What are you speaking about ? I didn't wanted to compare the 6502@1.79 Mhz vs GBC CPU @8Mhz in first place, I was just replying as i was quoted on something which could be wrongly interpreted...

Quote:

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

Again.. what are you speaking about ? Of course the hu6280 would destroy a 8 Mhz Z80, i have no doubt about it too... where did i said the opposite ?

Quote:

Your comparison with code was also hilarious,you code some bad exemple with bad 6502 code, and you summarise the results with all the processors serie,which is utterly false,but easy with no one who contradicts you, eh, be sure to lunch a comparison thread on a sega forum, the best place for this, without any doubt .

Why not here,were some people can contradict your arguments ??

And you are the one bringing the subject back... i don't want to open the war again about it but honestly I've absolutely no problem to discuss and debate about it wherever you want :pAgain i really don't care about convincing you, you're free to believe whatever you want. Myself I don't need to believe anything as i just know it :p

Last edited by Stef on Thu Dec 21, 2017 2:47 pm, edited 1 time in total.

And you are the one bringing the subject back... i don't want to open the war again about it but honestly I've absolutely no problem to discuss and debate about it wherever you want :p

But you have lunched it on sega-16, why not here ??And it's not a war,i thing we are grown enough to be gentle even in a CPU comparison(i know it's a little bit hard with you) .You can post your code exemple here, and we can discuss, it's not a fight, it will be just less easy than on sega-16 to post bullshit .

Quote:

Again i really don't care about convincing you, you're free to believe whatever you want.... I don't need to believe, i just know

And i don't care too, because i know you are only a fanboy persuaded to be right in any case,and that's really boring to discuss with you,because you're not able to admit when you're wrong even when most people said you .

Isn't that because the MD can write two 4-bit pixels in one shot, rather than one 8-bit pixel? IIRC it's only doing raycasting for every pair of columns.

You can do the same thing in Mode 7, by using tiles for pixel pairs and drawing the graphics to the tilemap. But it looks like they didn't do that.

The trouble with comparing multiplats is that it's almost impossible to get a real apples-to-apples comparison. Even if the same developer did both, and put the same level of effort into both, it's likely that their level of familiarity with each system and CPU was different, and the SNES was inarguably harder to develop for and had a less popular CPU. (And indeed, it looks like TT had way more experience with the MD at the time.) You'd have to put together a systematic bipartisan effort to come up with an optimal implementation on both consoles, and even then it would be difficult to eliminate all such lingering questions...

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

Who is online

Users browsing this forum: No registered users and 8 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