Vigo

What they could have done is shrinking/reworking the TIA chip die and using the extra chip space to add more sound channels. TIA is 1977 technology using very few transistors.

Apparently, it is YOU who misunderstands me. But that seems to be my constant fate here... Decrunchers or simple memory copy loops.... Not the above code. The first example will always execute faster. In some cases, this is desireable, in other cases, using the 32bit instructions can be significantly faster. That's what I was referring to in my original posts. Unlike the 68000, the 6502 register size is equal to the bus size, so it is always desirable to optimize code for 8 bit in order to avoid multiple register<->memory transfers. In many cases, this also applies to the 68k, but not all. Being able to store/fetch 32bits with 1 instruction can in many cases be a benefit instead of using multiple 16 bit instructions. Another example: move.l (a0),d0 asl.l #$1,d0 move.l d0,(a0)+ Is much more faster than: move.w (a0),d0 asl.w #$1,d0 move.w d0,(a0)+ move.w(a0),d0 asl.w #$1,d0 move.w d0,(a0)+ I take you did not understand the code example, or what are you trying to prove to me now what I already know? This is, apparently, not true. Guess everyone is having a go at me today...

Ehh? Maybe on a 68020. It's preferable to use 16bit data/var on the 68000. That's a waste of cycles or am I taking that statement out of context? Totally. Doing a move.l (a0)+,(a1)+ is ALWAYS more efficient than doing move.w (a0)+,(a1)+ move.w (a0)+,(a1)+ because in the later example, the CPU wastes 1 cycle with another opcode fetch.

I apologize too, if I caused you any frustration. *shake hands* The fact we misunderstood each other, and just had an intensive debate makes it clear that it's not an easy topic to discuss. I basically agree with you that you can indeed produce cases on the 6502 which perform faster than the 68000. What we seem to disagree on is if the advantages of the 68000 over the 6502 matter much when executing "real world" code. You seem to have the view that raw instruction throughput, no matter how poorly the cpu architecture is (and the 6502 is quite poor) will always win on average against more complex, slower CPU architectures. I have the view that, despite having a slower bus and longer execution times, the 68000 with its lavishly architecture design, combined with its 16bit data bus, will, on average, always have the performance advantage over the 6502, since real world code can profit from its architecture, especially the amount of registers and adressing modes. You say: Genesis games, in general, do not need the complex architecture of the 68000. I say: if I have a 68000, what stops me from writing optimized 68000 asm code, and design my game around the advantages, even on the Genesis? We both however, seem to agree that the PC-Engine is a cool, nice, little machine!

I didn't say it was the ONLY limiting factor, but it is the most basic limiting factor of the 68000. In this case, yes, but do I want that many byte operations on the 68000? What if I want to do 16it or 32bit table accesses? Me neither, it's just an example how a single 68k instruction can manipulate more data than a hu6280 instruction. You know, you keep mentioning the 32bit capabilities of the 68k, but when it comes to z80 it's just an 8bit CPU? What? I NEVER claimed the 68000 to be a 32bit CPU. It is just an 16bit CPU, as much as the Z80 is just an 8bit CPU. However, your analogy of comparing 6502 and Z80 and 6502 to 68k is totally inappropriate here, since the 68k is a 16bit CPU. I'm disappointed you are starting putting words into my mouth. Yes, and what? That is totally irrelevant if we are talking about a 6502 <> 68k comparision. Are you misreading my statements on purpose now? The Z80 has a 8bit memory bus, the 68000 has a 16bit memory bus. So this doesn't really fit in a 68000 vs 6502 discussion. So what is your point then? Yes, the Z80 is slower despite having a more complex architecture. But this can hardly be brought up as a case against the 68000. If you did not intend to say this, then why did you bring it up in the first place? You are (purposely?) misreading what I mean with effort. With effort, I simply mean number of instructions. And you were quoting MIPS between 6502 and 68k. That you are now bringing in another architecture type is, again, totally irrelevant to this particular discussion. As much as you do not know where I'm coming from. Again, you take my words out of context. I was referring to "best case" by constructing code which is , on purpose, designed to perform faster on 6502 than 68000, exactly the opposite of typical "real world" code. I ALREADY SAID THE PC-ENGINE CAN EXECUTE CODE FASTER! I must admit, I am getting angry now. I know that you are pushing the MIPS issue as an argument against the 68k, and I wanted to stress that MIPS alone is not a sole indicator how fast a CPU can perform certain tasks. Did I ever dispute that? No. But what do you need in a game? Doesn't this depend on what type of game you make? And why not using certain aspects of a CPU architecture if they are already there? Umm, now again, you are putting words in my mouth. I never claimed it was easy, quite differently, you seem to dictate the whole time what kind of instructions or architecture a game needs. Don't ever again say what is "too large" for me, mr. arrogance. Of course I know that. I coded on lots of CPU's, including 6502 and 68k. However, as much as you can take advantage of the faster instruction execution time of the 6502, you can ALWAYS take advantage of the instructions, bus width and register set of the 68000. Yes, but you neglect the fact that most RISC CPU's have even more registers than the 68000, and the 6502 register architecture is quite pathetic compared to both RISC cpu's and the 68000. You constantly need to do memory<->register transfers on the 6502, even for quite simple routines, which is why I am strongly convinced that, even in most general cases, the 68000 always performs tasks faster and more efficiently than the 6502. And exactly for that case, I will stand by my point that an equally clocked 68000 will always outperform an equally clocked 6502. The RISC philisophy can't be really applied to the 6502, since it lacks what most RISC cpu's have. I more have the feeling YOU seem to assume I know nothing about this topic. I am also quite disappointed at the amount of sheer nonsense you put into my mouth and how much I said you totally put into the wrong context. And with that, I leave the discussion now, because it is one thing to talk about technical aspects, but it is another to start a pissing contest, and quite franky, I am not used to nor do I like the smell of urine. Despite the fact I pointed out we both have basically the same opinions and views on CPU architecturesd, you keep trying to cram it down my throat, thank you.

And this is the problem, how can you ever judge something said being unreasonable if you don't know what this person is talking about?

Then isn't that what should be said as dictating the cycle timing, not the bus speed itself?? I am not to judge what should and what is, I did not make the 68000. Fact is, the way the 68000 is made, it can only access memory every 2nd cycle, contrary to the 6502, which can access it on every cycle. The whole 68000 microcode engine is designed around this behaviour. Most hardware architectures exploit this feature to implement transparent DMA, meaning the video chip fetches data in the cycle where the 68000 doesn't do a memory access. Amiga & Atari ST are designed that way. The only instruction which breaks this behaviour is the TAS instruction. Ah, ok. a move.l (a1)+,(a0)+ isn't ALU heavy either, yet, it moves 32bit in memory with only 1 instruction. Hence the distortions caused by the term "million instructions per second". Plus, the above code will ALWAYS be faster than: move.w (a1)+,(a0)+ move.w (a1)+,(a0)+ it is always preferrable to use the 32bit code on the 16bit 68000. This is completely unrelated to 16bit ALU related problems. Yes, the instructions are faster, but they can manipulate only 8 bits at a time, while the 68k can manipulate or move up to 32bits in a single instruction. I know that the 6502 has a faster bus, but, as you seemed to have agreed with me, bus speed isn't everything. And, considering branch instructions, the 68k has far more complex and powerful branch instructions, like the dbcc instructions, which alone can save multiple instructions required to emulate on the 6502. And yet, how is this a contradiction to "the genesis has a much more powerful cpu" ? It already starts by positioning sprites on a larger than 8 bit wide pixel grid. Everything which the 68k has much more powerful instructions for. You don't have, but you can. For example, if you are dealing with valuable ROM space, you sure appreciate a fast and efficient decruncher. Why should I tell you how to write a game? Besides, despite mentioning that the PC-Engine is a perfectly balanced architecture, I have the feeling you want to read in my statements that it isn't. It is. However, fact remains, the 68k in the Genesis IS more powerful. What you are doing with this extra power it is up to you. So, what are we arguing now? Everything which we discuss up to this point is redundant, since we both basically agree on the same things. Which are BOTH 8 bit CPU's, so you simply CAN NOT compare this case with the 68k. I am well aware that the Z80 also has a slower bus speed. But the Z80 isn't nearly as powerful as the 68k. Which I never disputed.. It is, if you quote measurements like MIPS. If you need less instructions, you need less effort to achieve your goal. Which I never disputed. Overall, however, the 68k IS much more powerful, and no matter if a typical scroller "needs" it (which is purely a decision how to design your game - you can always take advantage of the architecture you are coding for), the Genesis has a 68k. So, what are we disputing now?

Yes, you are right, I forgot that the PC-Engine also has a 512x mode. Which I already said. There is no difference. The 68k bus is constructed around the fact that it is a microcoded CPU. This statistic neglects the fact that you can do more complex things with fewer instructions on the 68000, since the 68000 has much more register, and, contrary to the 6502, has a 16 bit bus. I'm curious how you did get that numbers. Now compare this with having an 8 bit ALU on the 6502... The 6502 doesn't even have 32bit arithmetical or logical instructions, not even the register architecture to support them. And you surely know that a 32bit memory operation, even with a 16bit bus, is ALWAYS faster than 2 x 16bit memory operations, let alone 4 x 8bit memory operations. Yeah, but only if you severely limit what your code can do. I would say that your average platformer strongly benefits from having at least 16bit logical/arithmetic instructions, lots of registers, and furthermore, an unrestricted 32bit address space. The 6502 is very simple, doesn't take much chip space, and it has a fast bus interface, so it was a perfect choice for the PC-Engine. But I would never ever claim that an equally clocked 6502 is equal or better to an equally clocked 68000. Only if you construct some special cases, which theoretically are possible, but practically, you again end up limiting yourself on what you can do on the 6502, while on the 68k, you can accomplish much more with much less effort. As a coder, you always want your code reflect the best case for your CPU architecture, and I stand by my claim that the 68k best case always accomplishes much more than the 6502 best case. Is that a contradiction to my statement that the PC-Engine is a great hardware design and hides very well the fact that it is only an 8 bit machine? No. Most people will rightfully think that PC-Engine games are 16bit games. It's perfectly balanced, the 6502 was the right choice for it. I only take stance against the argument that the 16 bit consoles can hardly level with it, which has been stated. I am however, totally aware that the PC-Engine smashes the SNES in CPU power.

I know what you are asking, you don't know what I am answering. More chunky (due to 160x200) and less colourful (no attributes tiles). Again, how many times do I have to tell you that? How many times do I have to tell you that the 7800 is a completely other architecture in nature than all other architectures you desperately want it to be compared with? The SMS could do a 1:1 conversion (even with better graphics), the PC-Engine could do a 1:1 conversion (also with MUCH better graphics), and on the C64, I play Giana Sisters... Of course, you can even have 12 colour objects (which takes even less bandwidth than having 2 Display List entries for 2x4 colour objects each), but Maria is severely limited in the number of objects it can display per line once a tiled background is eating most of the bandwidth. How is a Colecovision bizarre? It has the same sprites the C64 has (the C64 VIC-II chip designers looked at how the TMS9918 sprites are implemented), it has a normal tile display, only that every character line can have a seperate colour attribute, and yeah, VRAM can only be programmed through ports. Nothing as weird as how the 7800 does things, with its complicated display list architecture. I answer it the whole time, you just don't understand it. No. The 4 colour background takes most of the DMA time. The DMA time isnt enough for even a 160 pixel wide 12 colour background (it can only display a 128 12 colour pixel background, which was one aspect which seriously disappointed me about the 7800). The best the 7800 DMA can do is: Displaying a 256 pixel wide 4 colour object or a 128 pixel wide 12 colour object per line. Anything above that will not be displayed by MARIA. And note that this is the BEST CASE. Every instruction fetch from the display list also takes DMA time, which is the reason why it is good to have fewer larger objects than many small objects. Umm, the screenshots are pixel accurate, there is nothing "lousy" about them, only your interpretation of them. Sorry, but, are you mental? I EXPLAIN IT THE WHOLE TIME WHAT THE 7800 STRENGTHS ARE!!! What the heck do you mean with "combined abilities"? "Earth, Fire, Water, Wind!!!!" Good for you. Yeah, so what? Some games cope with it better, but that's not the point, we are talking about hardware limitations. Again, I didn't say that. I only say it is severely handicapped for scrolling games, and the CPU power needed to (partly) overcome this, can be spent on many other improvements on the NES. Besides, I'd really like to see a fully coloured "1 pixel per frame" horizontal scroll on the CV, because it is impossible, no matter how much brain power you invest. Good luck with shifting all tile graphics in software... NES Defender doesn't even scratch the surface on what is possible on the NES. Have a fully coloured and complex background, and no trick of the world will save the Colecovision. Compare MSX Gradius to NES Gradius, and you'll see what I mean. Huh? You are making no sense anymore. The Colecovision neither has great processing power, nor does there exist an Atari 6400. Probably, but it would also look more blocky. Maybe, but who claims that both games couldn't be done better on the NES? Xevious isn't exactly a very demanding game, and there are lots of games on the NES which, quite simply, bash it to the ground. That's why I am talking only about hardware capabilities, because neither 7800 games nor first generation NES titles reflect what the hardware can do. Writing test code on the 7800 to test how many objects the DMA can push however, DOES reflect what the hardware can do. Lol, look at later generation NES games, and how much more graphical demanding they are. Apparently, besides from not reading my posts, you also didn't watch the videos. Should I wonder? Since you seem to be learning resistent, Tower Toppler looks like shit on the 7800, when watched on a PAL television (and it doesn't look hot either on the NTSC screenshots). And how exactly is the NES version of Tower Toppler being inferior to the 7800 version, considering that on the 7800, even the character sprite looks highly monochromatic compared to both the NES and C64 version? Excellent scrolling on Xevious? Have you seen Guardian Legend? LOL. And I constantly gave you that information. If you are, sorry, too uneducated in this matter to understand it, then it is clearly not my fault. I am NOT here to teach you the fundamentals of how the NES, 7800 and Colecovision work. Frankly, after having posted lots of examples and explanations, i am sick of spoon feeding you: it's finally up to you to catch up, because it's getting quite tiresome. Start some NES and 7800 coding, ALL TOOLS AND DOCUMENTATION ARE FREE ON THE WEB, so there is no excuse not to do it, and stop wasting other people's time. You are constantly comparing apples with oranges, so why should I answer a CV question to explain a genuine 7800 problem? Code it. I'm done now with this nonsense. This simply has been a waste of time with you. And quite franky, I know why, because you did not get the answers you wanted, and being pissed off with that, you start now going into circles, like an endless loop. Sorry, not with me, I'm done with this thread now. I'll let other people answer now your lamentations.

Actually, in terms of Millions of Instructions per Second, the TG16 is actually faster than the Genesis. clock speeds are deceiving. You seem to have snapped something up about the bus protocols of both CPU's, but do you know that things like: - number of registers (16) - width of registers (32bit) - addressing modes (a shitload) - bus width (16bit) strongly favours the 68000 over the 6502, do you? You ever coded on both architectures? This is an instruction on the 6502: lda #$ff and this is one on the 68000: move.l #$ffffffff,d0 Now speaking of "million instructions per seconds", tell me, which instruction moves more data? And furthermore, tell me, which of both architectures constantly needs storing/loading registers into/from main memory, because there aren't many of it. A 7,8 Mhz 68000 is, in every way, superior to a 7,16Mhz 6502. Bus speeds are deceiving.

For everything 6502, I always use DASM, being it C64, Atari 2600, Atari 7800 and even the PC-Engine/Turbografx 16 (using macros for the handful of extra opcodes). For the 2600, it's quite nice that the newest versions of DASM support the illegal opcodes.

The AMIGA architecture is a direct sucessor to the Atari 400/800 and even the VCS architecture. But then, the term reverse engineering is not quite appropriate, since I don't think Jay & Joe reverse engineered their own previous designs.

GCC also did the Food Fight arcade game for Atari which was based on the 68000 processor. I wonder if they intended to use the 1722 version in arcade games? Dan I doubt it, since at that time, Atari already had their own powerful 68000 arcade hardware (Marble Madness, Peter Pack Rat), and GCC alone probably could never have financed the development for further arcade games. But you are right, Food Fight is THE very first arcade game which uses an 68000 (1983), maybe that's why they perhaps thought it could be used in home video games so early? On the other hand, 680x0 is probably also a hint for the 68010. We'll probably never know fully what their plans were. But interesting nonetheless.

"Just to keep up" is not quite correct. There are lots of things on Mega Drive/SNES which the sweet little PC-Engine can not do. Both consoles for example have superior sound. The Mega Drive has a much more poweful CPU, and can display 2 parallax layers instead of just 1 layer. The SNES can display up to 4 parallax layers, has much more colours and lots more special effects. However, the PC-Engine can also do things which outdo aspects of the Mega Drive / SNES: 1. The PC-Engine can display way more colours than the Mega Drive / Genesis. 2. The PC-Engine has more processing power than the SNES (the 65816 is a very weak 16bit CPU). 3. The PC-Engine can display either 256x224 or 320x224 pixel screens without restrictions, the SNES is fixed to 256x224 (the 512x224 mode is heavily restricted). Compare SNES Parodius with PC-Engine Parodius. Graphically, the PC-Engine holds up really well, very impressive for an 8bit machine: http://www.youtube.com/watch?v=lV9FzQ_d_Wc http://www.youtube.com/watch?v=6x0brXUS4jw So in the end, if you show someone a PC-Engine game, probably all people will think it's a 16bit game, and considering the tiny little size of the console, I really love it! The PC-Engine has some of the best arcade ports. And from a programmer's POV, the PC-Engine is a joy to handle (you can write to VRAM every time, not just in VBLANK like SNES / Mega Drive ). And yes, I also coded on the PC-Engine, strongly recommended!

I thought it was 4? Well, then you thought wrong. The Colecovision can only display 4 sprites per line. Depends how you look at it. 8 hardware sprites, but the hardware sprites are only 8 pixels wide. Most moving characters in NES games use up 2 sprites each. Yeah, and? Everything I said is correct, the NES can display 8 sprites per line, not 8 Super Marios. The Colecovision can display 4 sprites per line. There are lots of games which succesfully avoid flicker. And there are others, which don't. http://www.youtube.com/watch?v=PuBquNRQ-H8 Monster in my Pocket is fun anyway.

The Jaguar is indeed the most powerful architecture of 1993. And I personally like it, since Atari really really tried to get their feet back into mainstream videogame business and the hardware reflects that "we put all our remaining resources into this machine" last effort feeling. And one can not blame them for trying every marketing trick to push this system into the conscience of the consumers. However, developers and people with hardware experience should know better. The system gets neither better nor worse by religiously sticking to marketing bull.

I thought it was 4? Well, then you thought wrong. The Colecovision can only display 4 sprites per line. IMHO, the SMS has A better game than the NES in every category except adventure games. (and vertical shmups, if we subdivide categories.) The problem being that it was generally the only one in that category on the SMS. You find a jump'n run game on the SMS better than SMB3, which is generally regarded as one of the best games ever made in that genre (yes, I know, everyone bribed by Nintendo)? THE TURBOGRAFX 16 IS 16 BIT. Nope, the hu62c80 processor is a normal 6502 core, with a handful of extra instructions for bankswitching (lda #$01, tam1). Of course, now you will say: but the graphics are 16 bit! Well, again, that's clearly NOT how the bitness of a system is defined. With that argument, both C64 and VIC-20 are 12bit machines. With that argument, I am now typing this text here on an 256bit PC!

Very interesting, on page 1, in the table, there is the following entry: "GCC1722 - Bus System: 680x0" Meaning that apparently, a successor to the 7800 with an 16bit 68k CPU was planned. Probably more to do with what it was developed on. Since Atari (not GCC) designed the 7800 development system around the Atari ST computers which used the 68000, it's probably what that refers to. Although I could be completly wrong about that (which I think I am). Yes, because it refers to a Maria chip revision (GCC1722) especially made for the 68k bus system, as the table indicated. This revision is also housed in a larger chip package (PLCC64 instead of DIP48), which could indicate a 16 bit data bus.

The bottom line is, it is very unusual to define the bitness of a system by its overall system or graphics bus. If you claim the Jaguar to be a 64bit machine, I can also claim that most Pentium 1 systems are 64bit or that the Commodore 64 and VIC-20 are 12bit systems. The funny thing here is, on the one hand, Gorf admits that bitness is no indicator of a system's performance, yet, on the other hand, he is defending Atari's marketing bull, because he, like Atari, knows that "64bit" sounds more impressive. In the end, if everyone just defines bitness of a system by what factor seems to be most convenient, this term becomes even more useless than it is already.

To be fair, the SMS doesn't flicker much on games designed for it - the only games I can think of with flicker are the arcade ports. The same applies to the NES. If you avoid displaying more than 8 sprites per scanline, everything is okeydokey. SMS has the same sprite limit per scanline. And yes, the SMS is indeed graphically superior to the NES, since it can display full 16 colour tiles/objects, has much more video memory, plus, I really like the fact that the SMS 1 has RGB output. The only aspect where the SMS is inferior is the sound and the games. There are not many games I think on the SMS which match the gameplay quality of NES games. But that's not the fault of the hardware... However, the best 8bit hardware out there is clearly the PC-Engine, since it smashes both NES and SMS against the wall, and can in some cases even give the MegaDrive/Genesis a hard time. And, contrary to the SMS, it has some really great games!

Very interesting, on page 1, in the table, there is the following entry: "GCC1722 - Bus System: 680x0" Meaning that apparently, a successor to the 7800 with an 16bit 68k CPU was planned.

@Exophase: if I were you, I would stop immediately bothering to discuss this here, because the signal-to-noise ratio on this board is very low. Be prepared for your arguments being twisted around here until you are tired of bothering with this nonsense anymore. EDIT: Ah, Gorf has already jumped on you, and as expected, he is going to divert the pure technical discussion into a "you haven't seen what I have seen!" kind of debate.

Get a Playstation 3 or XBOX 360. What games do you like to play? Arcade style games? Available. Adventures? Available (even a very good port of Maniac Mansion, if you like those kind of adventures more). Jump'n'Run games? Tons of. Shooters? Of course! Even simulators, like ELITE for example. You have practically every genre available on the NES, and yet, you dismiss it in a wink of an eye. What ignorance. That can indeed be argued. But we are talking about the games, right? Besides, if you dislike flicker, you wont like the SMS either.

Not only the NES has lots of bad games, but also the Atari VCS and the SNES, both consoles which every serious collector needs in his posession, only because of the great games.

I would argue that this is to the NES' detriment. Too much shovelware. Lots of bad but also lots of good to great games. You don't have to play the bad games.