Vigo

I also think that was the original plan behind this modular architecture. I guess they didn't see it coming that soon, with the 6800 and 6502, microprocessors will become affordable for gaming applications. Tank 8, Sprint 1, Sprint 2, Indy 4, Indy 8 and Super Breakout are all CPU versions of previous discrete logic games. Each car has a multitude of rotating shapes which are stored in a graphics rom, so no blocks moving around. Besides, cars can overlap each other, so you can have a multitude of colors within a small area. The car shapes are even displayed at the same resolution as a Playstation 2 game! Hey, you talked about the first color game, not the first "pretty color game". It's more like comparing 20.000 year old cave paintings with a photographed image...

Discrete Sim was written by Atari Age member Dan Boris, and can be found on his webpage: http://atarihq.com/danb/Pong.shtml On his blog, he also does an excellent job at explaining how Pong works. http://www.atariage.com/forums/index.php?a...;blogid=52&

If we are talking about simulation as in simulating the real hardware, since this is a no-cpu game, we are talking about the simulation of hundreds of individual logic chips with thousands of signal paths connected between them. In other words, a software simulation will never be playable on any current and next generation hardware for quite some time. The only part which could work is to understand the workings of the game by studying the schematics, and write a functionally equivalent software implementation. This however bears the possibility that in the process of re-interpreting the game mechanics, your implementation behaves to a certain degree differently than the original. Most probably, since it is a very large and expensive game, probably manufactured in small quantities. What you can easily find emulated in MAME are 2 other very early color games from 1976 and 1977 which use a CPU: Tank 8 and Sprint 8 Tank 8 (1976) Sprint 8(1977) While Tank 8 may not be the first color game, it may very well be the first CPU driven color game. Sprint 8 seems to be a CPU version of Indy 800.

Even without a microprocessor, I would think one could reap benefits from sharing a significant amount of circuitry between the cars. Though perhaps the game did and STILL needed a big board for each one. Though it wouldn't seem like it would need that much stuff... I would never have written such things in my post without having checked the schematics first: http://www.cityofberwyn.com/manuals/Indy800.pdf But seriously, check it out, it explains quite a lot. They exactly did design 1 circuit card for one car, containing the graphics rom and motion circuits, and used 8 of them in the game. The game even runs interlaced at higher resolution (640x480), so it's a quite fancy non-cpu game. Not as complex as Monaco GP though...

Indy 800, a true behemoth of a game: Each of the 8 cars has its own seperate circuit board. Must have been a very expensive game to manufacture.

Hello everybody, in the phase of repairing what seems to be an original PONG PCB, I discovered a significant difference in the vertical ball motion circuit between the Atari schematics and the circuit on the PCB, while everything else is exactly connected as described. What I am asking is if someone knows a source of hires scans of an original Pong PCB, where I can clearly make out the traces between the IC's. I am also noticing some subtle differences between the 2 existing hardware emulators (Dice & Discrete Sim) and the real PCB: - Once the ball collides with the horizontal and vertical screen boundaries, it is stretched into the HBLANK and VBLANK area for 1 frame. Actually, that's exactly how I would expect it to behave when looking at the schematics. The simulations don't reflect that. - There is a space of 1 pixel between the right score display and the right paddle, when the paddle is on the same level as the score display. On both simulators, there is no space between the right paddle and score display, which looks kind of odd. Perhaps there is someone having a real Pong machine verifying my findings?

Excellent Blog, Dan! I am currently restoring a real Pong PCB, and your descriptions here really help me in finding faulty parts. So far, I have replaced 2 TTL's (7400, 74161 (as a 9316 replacement)) and the game runs perfect now. Great work with the simulator! However, I noticed some differences between the real Pong and all simulations: - The graphics are mixed through resistors, which means that all elements are bright grey, and everything which overlaps with the ball is white. - I have to investigate it further, but it seems that on the original, the second paddle is displayed 4 more pixels to the right Again, great work! Shame that on some entries, the pictures are slowly vanishing...

Comparision with 9938/9958: They are not compatible. The 9938 implements 16 & 256 colour bitmapped display whild the SMS/Mega Drive VDP always operate on tiles. Also, the sprites are different, the 9938 can only display 1 colour sprites (which can change colour every line) while the SMS/Mega Drive VDP display 16 colour sprites. The 9938 has only vertical scrolling (horizontal only with a trick) while SMS/MD have full X/Y scrolling. The 9938 can display 512x448 pixel interlaced maximum, while the SMS can only display 224x192 & the MD can display 320x448 interlaced maximum. Plus, since the 9938 operates on bitmaps on the enhanced modes, it has a blitter. Comparision MD/SMS: The MD can display all SMS graphic modes except the old 9918 video modes. The MD has more sprites, more colours (64 vs 32), tiles/sprites with colour attributes, has 2 parallax layers, can switch between 256x224 & 320x224 (the SMS only has 256x192), line scrolling, shadow/highlight modes, DMA transfers to VRAM... Well, much more advanced of course. But SMS backwards compatible. Dunno. If they had to do, then it would be logical that Sega would have, too, since the SMS VDP can display all 9918 modes. It would be closer to the SMS, since the SMS has the same sound chip as the Colecovision. Both have the SN76489, while the MSX Systems are AY-3-8910/YM2149 based. For a game console, the SMS VDP makes more sense, the 9938 is not as well suited for games, but more for computer applications.

The Jaguar blitter and OPL are not turing complete. They are specialised for moving and manipulating graphics, but they can not execute full programs, with loops, branches, etc. One hybrid architecture which would fit this scheme would be the TMS34010 microprocessor. It's a CPU, which has built-in commands for graphic manipulations. But show me one assembler or C-Code listing which executes ON (NOT the JRISC or 68K) the Blitter or OPL... Show me a simple PONG game which executes just on the OPL & Blitter, without using the JRISC or 68k.... Or even something simpler, like a time counter.

No computer with finite memory is Turing complete. And thus, no existing computer would be fitting the original definition. I however, supposed that people would understand I was using the informal definition of turing completeness, like almost everyone else. The instruction set of all CPU's would fit the original definition if they supported unlimited memory in theory.

Yeah,exactly as I have proven multiple times in this thread... Obviously. Oh no, he is trying to judge me! :lol: You sort of remember me more of a schoolkid than a grown up. ("Now I get my friend, and HE WILL BEAT YOU, HUH HUH HUH! *snort*") Weren't we talking about the CV? Try to hold a magnet in front of your picture tube, and it will suddenly show 16777216 colours... IN ALL MODES! And the best thing is, it works even with the Aquarius!

There is something fishy with those DRAM's... The "AD" pins on the VDP are connected to the address pins of the DRAM, but also to a mysterious 4 bit port (marked I/O), right next to the data port. I have a feeling that this address bus is multiplexed several times... I'll continue my research. Ah, now I understand, it's a dual port VRAM not a standard single port DRAM. That's why they only used an 8 bit data port, because this ram can be read-out very fast (30ns)

My fault, I looked at the wrong schematics. Here are the right ones: http://www.emu-docs.org/Genesis/mega2.png The Genesis does indeed only have an 8bit graphics bus. Thank you for pointing me to that information!

That may work for console magazine readers, but it doesn't work for me, and it is not really correct to misuse this term that way. Gamers should always look at the games, and not argue or measure with something they do not understand. Note: I wasn't implying you belong to this group, quite contrary. And where does the Dreamcast & PS2 belong to? Good thought, but I have an explanation for that. An increment operation doesn't need an ALU, because you can achieve it by simply toggling the flipflops based on the state of the previous bits. Let's take the program counter (PC). It doesn't need the ALU to increment itself because of the reason I posted above (otherwise, the 6502 would not be as cycle efficient as it is). It has 2 functions: increment & load. On the 6502, page boundaries take 1 additional cycle, on the 65c02 this does not apply. They probably did this in the 6502 to make the incrementing logic smaller. But anyway, as the PC is implemented this way, the A, X, Y registers are probably implemented the same way. They can load a value and increment/decrement themselves. From a design point of view, 6 simple increment/decrement commands (INC A, DEC A, INX, DEX, INY, DEY) do not warrant a fully fledged 16bit ALU with all kinds of operations (ADC, SBC, AND, OR, EOR...). 1 of the main goals of designing chip designs is: make them small and efficient. That's why for example, the Atari engineers implemented almost every counter in the 2600 using LSFR's. What I proposed is not 2 chained 8 bit ALUs, but just one single 8 bit ALU with 2 multiplexers connecting all 8bit portions to the ALU. You only need to save the carry for a full 16bit add/sub operation on 2 cycles. If it has a 16bit ALU, it would certainly be divided into 2x8 bit parts. But I really doubt it because it doesn\\\'t make sense to me to waste that amount of logic. As far as I know, it also has 1 single 4bit ALU, which makes sense considering the Z80 takes 2 cycles between memory fetches. Both VDP's connect to the memory via a 16bit DRAM data bus, 7 bit multiplexed DRAM address bus (315-5309) and a 24bit unmultiplexed address bus (315-5364). It is a full 16bit system. Check it out yourself: http://www.emu-docs.org/Genesis/mega1.png Referred in the schematics as "V ADDRESS" and "V DATA"

Like malducci said, you can switch the accumulator or the index registers of the 65816 to 8bit or 16bit using the rep & sep commands. The 65816 also adds 24bit addressing space, which is kind of segmented, but can also be accessed in a linear fashion using 24bit addressing modes (lda $123456, jmp $123456). It has some benefits. During active display, the graphics chip can access ALL memory cycles for gfx fetches without stopping the CPU, which runs in parallel on its own bus. The disadvantage is, VRAM access only in the VBLANKS (except the Pc-Engine). I don't know much about the aquarius, I also come from machines which have unified memory architecture (C64, Amiga). I can however, understand why many console designers preferred the external VRAM bus design of the 9918. They just have to cope with the question: how much time should the CPU spend on game logic and graphics manipulation? How should it be divided? Yeah you can definitely see an improvement between the two...man that was many moons ago since I got my ass handed to me in those games. I think R-Type 3 holds up quite well, one last breath of excellence from IREM. (I am right they went bankrup after R-Type 3?) My guilty pleasure on the SNES is also Parodius... Intel at first never gave the CPU business much attention, that's why Frederico Faggin, the main designer of the 4004,8008 & 8080 started his own company Zilog and worked the 8080 design into the Z80, and designed one of the most succesful CPU architectures in history. The 8086 is a very unimpressive design compared to other 16bit architectures like the 68000. Intel never saw the 8086 as their main market (that changed only later with the success of the IBM PC), their main target at the time was the unsuccesful i432 architecture, a heavily microcoded cisc cpu design: http://en.wikipedia.org/wiki/Intel_iAPX_432 MS-DOS, the CP/M rip-off. I know that there was a version for the 68k, but I am unsure when it was released. It would have been an interesting question what OS IBM would have used if they took the 68000. On the Amiga, it depends on the Operating System version. Everything below 2.0 is VERY buggy & unstable, but from 2.0 on, it is a truly great OS for its time. But on the other hand, for a long time, the Amiga was much more expensive than the ST. The 060 has a slight advantage over the Pentium 1 in integer performance. I really wished Motorola would have continued the design. Yeah, okay, there is the Coldfire, but it isn't fully binary compatible to the 68k architecture. And the death knell for ever writing a fast library which emulates the missing 68k instructions,providing 100% compatibility, is the fact that 1 quite important instruction uses the same opcode, but behaves differently, so you can not trap it with an exception handler. I have to look up again what instruction that was... The more interesting question is: where do you get Tom & Jerry chips? Too bad, because it sounds quite interesting. I think Atari used a MIPS R3000 CPU in the Cojag arcade system based on the Tom & Jerry chipset.

That's the first I've ever seen anyone have that opinion about the SNES. Regardless of its bus, it definitely has a 16bit ALU. Yes, you read everywhere that the 65816 has a 16bit ALU, but from an engineer's point of view, it doesn't make any sense, and I'll explain why: Let's take any ALU opcode (EOR, AND, ORA...), i'll pick ADC #imm. ADC #$1234 Decodes in 16bit mode as: 69 34 12 So due to its 8 bit bus, the 65816 needs 3 bus cycles to execute the opcode. With an 16bit ALU, you fetch the opcode, the 2 bytes of the argument and then perform the addition. Note that the 16bit ALU can only perform the operation after the high byte of the argument has been fetched. With an 8 bit ALU however, you can first add the low byte of the argument in cycle 2 and then the high byte of the argument in cycle 3. Exactly as fast as a 16bit ALU. There is NO case in the 65816 where a 16bit ALU is needed! Another example: lda $1000,y :y is 16bit 1st cycle: fetch opcode 2nd cycle: fetch low byte of address, add low byte of y register using 8 bit ALU, save carry 3rd cycle: fetch high byte of address, add high byte of y register with carry using 8 bit ALU Can all be accomplished using an 8bit ALU. So, why should I assume that the designers of the 65816 effectively wasted precious logic gates on the chip by implementing an 16bit ALU, which is always idle in 1 cycle? Even the direct page registers indexed addressing modes add 1 cycle when the index register is 16bit. Can you follow me? Yeah, I basically agree with you. Most problems of the SNES could have been fixed if the CPU would have been twice as fast. But I always thought that WRAM accesses take 6 master cycles, and that the 65816 is just halted the first few cycles per rasterline to refresh it. 21bit ADDRESS BUS. Normally, the generic term "bus size" refers to the data bus size. Otherwise, the 6502 would have a 16bit bus. I would disagree that the PC-Engine is a 16bit machine for the same reasons I personally disagree the Jaguar is a 64bit machine. But let's not start the discussion again about that. I just brought it up to make the point here that I am consistent in my views (and have absolutely no grudges against the Jaguar), and if the 65816 would have an 8bit ALU, it would be a 8bit CPU, which would, from my view, again make the SNES an 8bit machine, no matter if the PPU's fetch 16bit of graphics. Note again: bitness != power of machine! No, it has a 16bit data bus, sorry. A CPU is also a state machine. For something to be worthy of being rated as a CPU, it must: 1. Being able to execute programs. 2. Be Turing complete. Yes, plus they take much more logic than the 65816. Remember that the 65816 is integrated into the SNES chipset. The chip which contains the SNES CPU also contains other elements like the DMA engine. Another point. Gotta love wiki The 8bit bus *really* hurts cycle times of the 68k instruction set, as if they weren't slow already. Maybe faster than the z80 or 8080 <_<; And here, I agree with you, too. The fact that all 68k instructions are encoded in 16bits is another negative factor. It would perform better than a Z80, but the 6502 could be faster in many cases than the 68008.

The 65816 is probably a relic from the time when the SNES was supposed to be NES compatible. If you compare the register spaces between the SNES & NES, while not compatible, they are identical ($2xxx & $4xxx), another hint at the intended backward compatibility. Plus, the 65816 is a much smaller design than the 68000, they tried to save cost by integrating all components into as few chips as possible. If the 65816 has a 16bit ALU, it is by definition a 16bit CPU, although I kind of doubt it is actually the case. The CPU bus of the SNES is 8 bits, but the graphics bus of the SNES is actually 16bits (the 64K VRAM is connected to both PPU's via a 16bit bus). They did it because they wanted the SNES architecture to closely resemble the NES architecture. Otherwise, SNES & Genesis have more similarities than you might think. Both have a dedicated sound CPU and both have seperate CPU & video buses, unlike unified memory architectures. They both access VRAM by writing/reading an access port. The only saving grace of the SNES are the sound & graphics and if you know where the weak spots of the design are, and design your game around it, you can achieve actuelly achieve great looking and sounding results. Just compare the horrendous slow "Super R-Type" with the magnificient "R-Type 3". The 8088 was meant to be a low-cost version of the 8086, which has a full 16bit data bus. The key word is compatibility, not speed or elegance. The problem was that at the time of the PC's introduction (1981), the 68000 wasn't readily available from Motorola and it was expensive. But otherwise, I couldn't agree with you more... When I was 15, I coded a Commodore 16 emulator for MS-DOS in x86 assembly language together with my friend, using the good old TASM. And it was always like: I want my Amiga back! So few registers, and the Real Mode addressing model... Eugh! There was a 68060 card available for the Falcon. I personally own an Amiga 1200 with 68060/PPC accelerator. I wish I would stumble upon a Falcon one day, it's the only Atari from the ST series which interests me.

You mean "quality" as in "graphics capability" or the artefacts of the composite video output? The SNES is another quirky architecture. Great effects (I just LOVE the color add/subtract modes), really advanced sound, but a pain-in-the-ass CPU, which is simply too slow to handle all the advanced stuff the graphics are capable of. The 65816 is not really a full 16bit CPU. I've been told it has in fact a 16bit ALU, but I simply don't understand for what, since it has an 8 bit data bus (an opcode like adc #$1234 takes 3 bus fetches, so the first result of the addition can be computed while the high byte of the argument is fetched), and the CPU can not perform an ALU operation on 2 registers (a case where a 16bit ALU could be of use on an 8 bit bus). Plus, all those rep #$30, sep #$30 (to set/reset 16bit registers) are really annoying, which makes it almost impossible to write a decent disassembler. The only way to achieve smooth games is to use the DMA controller whenever possible, to transfer graphics.

You can do games on the SMS which will look much better than NES games, since you have the whole 15 colour attribute palette for each sprite and another 15 colour attribute palette for the background, without those 8x8 pixel 3 colour attribute restrictions like the NES. Both have almost the same resolution (the SMS lacks a few lines which is not really a problem) and can actually display the same amount of sprite pixels per line. The only thing which the NES can do better is sound (well, compared to the European/American SMS, some japanese Sega Mark III consoles have a Yahama YM2413 FM chip, which is quite nice). The SN76489 (which is also in the Colecovision) can only have 4 square waves plus noise, while the NES has 2 square waves with variable pulse width, triangle waveform, 2 types of noise (short and long period - short period can be used to make a "dink" sounding noise), plus a DPCM channel.

Though, if you really want to be picky, the GBC has not a Z80, but an enhanced 8080 architecture. For example, the GBC lacks the second register pair of the Z80. Compare to the NES and SMS, the Game Boy can display 10 sprites per line, which is also nicer than the NES, and is certainly very well suited for the 160x144 display. The 2nd windowed character screen is also a nice feature.

You can't let it go, can you? Every time you mess with me is going to be a heavy footbullet for you, which shows your inability. I already wrote about the 2 colour limit of the Colecovision in this post in exactly THIS THREAD! http://www.atariage.com/forums/index.php?s...t&p=1572750 And since you are not going to read it anyway, as always, I quote and highlight it for you: Now go ahead and look up what C64 FLI mode it, because it is similar to the Colecovision mode... Oh wait, you won't be able to do that, as proven in the past, too, so I will do it for you: http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm And since you won't be able to read that, too, I am goint to quote the relevant passage: And here, a nice picture to go with, since all technical discussions are wasted on you anyway: The only thing YOU have established is your continued incompetence and ability to comprehend and read my posts. Hello??? I quoted SEVERAL TIMES that the Colecovision can do smooth scrolling, but NOT IN HARDWARE!

Exactly my point. What point?? The jag has to have several chips and it only adds up to 64. There is not a 64-bit chip in that system. That is not correct. The Jaguar has a 64bit system bus, which the system uses to display and manipulate graphics using the Object Processor and the Blitter. This is much more useful than having a 64bit CPU, because in a game console, you want to channel the power of the console to its graphics. However, both RISC CPU's are 32bit and the 68K is 16bit, which effectively makes it a 32bit multiprocessor system. That is the key point of the bitness discussion. Jaguar fans will use the bus argument to define it as a 64bit system, while most of the rest is in best case sceptical about that, and those who know more will clearly say it's effectively a 32bit system, because bitness is in almost all cases defined by the bitness of the CPU. Most popular example: PC's haven't been 64bit until AMD & Intel introduced true 64bit CPU's, while long ago, with the introduction of the Pentium 1, PC's already used a 64bit memory system to make up for the slow (60ns) DRAM (that's why you had to pop in 2xPS/2 SIMM modules in most Pentium boards). CPU 64bitness is again, not very useful for a gaming console. It only becomes useful when using huge amounts of memory (>4GB Ram = 64bit addressing) and higher precision mathematics, which is, considering most 3D consoles of the time use a 320x240 pixel display, again, not useful. Not liking Jaguar games has nothing to do with its architecture. The architecture is indeed much more capable of what the games actually showed. There are many other quirky architectures (PS2 comes to my mind) which have great games, and the Jaguar was the most capable system by a long shot when it came out in 1993. Atari was never able to gather the software support needed to survive, otherwise, with the Jaguar hardware, they did it correct. And I know I am getting insulted now from the: - Jaguar opposers - Jaguar fans And you know what: I don't care, because I can honestly say that I have a differentiated opinion, based on my own research and evaluation, no matter what insults you are going to come up with.

I skip the rest (although I already wrote an answer for that) and come directly to the main point: And yet, in another thread, you started to defame me as a NES lover, who spreads untruth of the 7800. Now how does that fit in now? Have you been lying in the past, or are you lying right now? Sorry, but I don't believe you. You pretty much see me as an idiot, because you behave and talk to me like an idiot. If you would start to talk to me in a more civilized manner, maybe we would have a base to discuss things seriously. But not like this. There are way more things YOU should try for a change. I don't need you to tell me how brilliant or unbrilliant I am. I know who I am and I know what I can and what I can not do. You know what? Stick to what you can do best, and where you seem to be most inventive: throwing insults. You are starting to sweet talk me anyway only because you fear banning, after your complete blackout in your previous posts. I am not stupid. Neither if we hate or love us doesn't change a single bit of truth. And I will leave it at that. If you are really serious about what you wrote in the following paragraphs, then reread your posts, and start to behave like a civilized human being for a change, which really seems to be quite a challenge for you. I know that I came off as arrogant. But that was just after I have been VERY patient with CV Gus. But this is nothing compared to what you just came up with. Is this is the way how you think to win an argument? Insult people until they stop bothering with you in disgust? As you being an idiot, I can only laugh at your insults. But as you in taking you seriously, I can only say: screw off.

Speculation on your part and only speculation and as hard a piece of evidence that you mouth is your ass. STRIKE ONE! I knew you would only pick the parts which would serve as the most convenient device to throw with verbal fecals. You are so predictable. If you think you can pull me down with that to your level, and distract from the points I make: no, you won't succeed. But go ahead. I refuted every single point in my previous post, so the only thing, which apparently is left for you to do, is to make an even bigger idiot out of yourself. Again you speaketh from your ass. http://www.atariage.com/forums/index.php?showtopic=121203 Not bad for a first attempt dont you think? In a high level language no less. Which is even more embarassing for you. No wonder you have no concept of player-missile graphics on the VCS. I don't know, it seems to be your field of expertise. It is you, who envied the most primitive Player Missile graphics of the VCS over a fully bitmapped display, which needs no constant update from the CPU. Sure Gorf... *calling the nurse* Wonderful, now let's rephrase what Gorf was able to come up with when his position is challenged: - insults - neglection of the original point - severe signs of other psychological defects Anyone who is calling ME arrogant has now the proof: people can be worse. MUCH worse. Anything you would like to add to your humorous & colourful collage of inane rantings?

You are, right now, providing plenty of material, more than I have expected. Yet you now do this: Your experience in programming the Jaguar makes this discussion even worse for you. Clearly no deity. Only a idiot would make such a statement like this if they know me at all. I guess we all know you a little bit better now... Yet, you repeat and viciously defend the biggest marketing blunder this company made. Besides from being not correct, it really HURT the Jaguar badly, because people were expecting much more than Jaguar games delivered. They pretty much lost their whole credibility. You declare components in the Jaguar as "processors" which are NO general purpose CPU's. You define the system bus as a measurement of the bitness of a system. You declare pretty much anything else not conforming to Atari's & your self-made definition of "bitness" as "outdated" (which is funny, considering that architectures coming long after the Jaguar, NEVER picked up on this kind of definition). That's clearly "twisting" in my eyes. And a pretty arrogant attempt at that, too. The most funny thing about the discussion, which is so irritating about you as a developer, is: no matter if I am right, it doesn't change one bit what the Jaguar is capable of. You are doing all this shit simply for your audience, my politician. I am only unnerved by people like CV Gus (who clearly has hardly any knowledge on both the Colecovision and 7800, yet, tries to lecture other people) and clearly you. Especially YOU need a big spanking. Even though I laugh at your childish insults, I recognise with how much arrogance you call people "idiots", "morons", "horse ass" and "liars", only a real true deity in all things would do that (and apparently get away with it). And I knew exactly this would happen after my post. Shall I really post now the links of the official developer docs? Anyone is free to examine them: http://www.starcat-dev.de/download.php?id=...8ffdef237bafd2b Don't take my or Gorf's words for it, read it for yourself. Gorf WILL probably now start the usual babble that they are inaccurate and that he found the trick to start code from blablablabla... Wonderful. You do realise you are quite funny trying to be insulting? Give me animal names, Tiger! I know that the Jaguar has a 64bit system main bus, and that the Blitter and Object processor can move and operate on 64bit of data at once. It is only you who doesn't know: it doesn't matter in this discussion. This discussion is purely about bitness rating. This discussion is NOT about how much performance the Jaguar has. Only someone with no experience would rate bitness = performance in all cases. I'm now eating my lunch, that's what I do. And maybe check-in later and see the next level of your inane rantings. I know it only can get worse.