Vigo

Again, your typical "I have seen what no one else has seen" argument, claiming the official docs to be incorrect. Yes, we know you managed to get code started out of main ram, whoopie-doo. Irrelevant to the whole bitness discussion. Yes, but the bus size DOES NOT define the bitness of a system. If that would be, practically all PC's from the first Pentium were 64 bit systems (since they have a 64bit memory bus). It's just too bad that AMD/Intel, with their Introduction of their 64bit architectures, never asked you about your twisted definition of bitness. You, because you RIGHT NOW showed that you ignore the standard definition. The Falcon is also a 32bit system, despite having a 16bit memory bus, because it has a 32bit CPU. Same with the N64. Besides, these CPU's, in addition to their ALU, also have built-in cache memory of their native bus size. So Gorf, before you throw the stone and call me a moron, better consider the glass falling down on you. If you call it graphics bus or system bus is pretty irrelevant. No CPU in the Jaguar is 64 bit. Of course, you could twist now the definition even further by adding all bits of all components together (which would even make it an 80bit system), or declare the Blitter as a processor. Well, then I am apparently writing this document on a 256 bit PC,since that's the size how the blitter on my graphics card can move around data in video ram. So do old and crummy PCI graphics cards with a 64bit memory bus. But they are NO general purpose CPU's, and thus fail the definition. With a definition like that, the PS2 console is a 2048bit machine, and the Dreamcast is a 128bit one. You sound rather funny than insulting, because right now, with your behaviour, you exactly reveal yourself to me (and many other people) as what you are: a dimwit. I pretty much have reduced you to a 15 year old fanboy brat. And it wasn't even hard. I know that the Blitter and Object processor can process 64bit. But what apparently YOU don't know is: despite what the designers like to call them, they ARE NO general purpose CPU's. If that definition would apply, call everything a CPU and apply the bitness definition, then many other systems suddenly would have really huge bitness ratings. Does it change the power of those systems? No. Bitness does not reveal the power of a system. The designers of the Jaguar were right to give it a 64bit bus to move and manipulate graphics, because that's (for a console) where it counts. But no, no, and again: no, the Jaguar does NOT fit the definition of a 64bit system. As much as the Saturn doesn't fit this definition. No, it exactly shows that the Jaguar seems really to be your only field of expertise. Even Sega did not dare to call the Saturn a 64bit system, despite also having 2x32bit RISC CPU's and 1x16bit 68k. And again: appeal to authority. So the Jaguar designers apparently know much more about bitness than the rest of the industry? Besides: I am not smarter than most people here. But then again, most people posting here are gamers, and gamers PLAY games, they don't necessarily know how the hardware works, which is completely okay, since everyone was once a novice. Other people, like malducci, supercat, exophase, pacmanplus, danboris etc. do also know a lot, and I always corrected myself if they pointed out a mistake I made. Not like a true deity, which is always right and makes no mistakes.

The only one wrong here is your arrogance telling even the designers of the Jaguar they are wrong. They say it was and it is a 64 bit system. method: appeal to authority. OF COURSE will the engineers repeat the marketing campaign of Atari. method: appeal to authority My non-involvement in the design of the Jaguar is totally irrelevant. Or maybe it IS relevant to some degree, since engineers always tend to praise their children. I know what a bitmapped display is, but obviously, you don't know what a pain in the ass the player/missile objects of the VCS are, which have to be reloaded ON THE FLY using the 6507. You know the term "racing the beam"? Look it up before start whining about manipulating bitmapped displays with a lavish 4K of own video ram (and even the video hardware helps you in masking the data, a luxury many other bitmapped-only architectures dont have). I suppose you never coded on the VCS either. Shows much about "yoor" lack of understanding. I already quoted the basic system design of the Jaguar, and you continue to repeat it here. I guess that would make you a liar, too.

A bit of hypocrisy? You come shoot your mouth off about the Jaguar, and I bet dollars to donuts you NEVER coded a single line of code, yet you dispute my 13 years of experience? 13 years of Jaguar programming experience. Changes nothing about your utterly wrong conceptions about bitness & hardware architectures. I don't need to code the Jaguar to see from the technical documents that it is NOT a 64bit system, and IF you were declaring it 64bit because of its system & graphics bus, or perhaps the 2x32 bit RISC processors, then this would have immediate effect on the bitness rating of lots of other systems. What the Jaguar is actually capable of, which, and I repeatedly stressed this, has NOTHING to do with bitness, seems to be your field of expertise. And this is my one & only point, which you always LOVE to misrepresent. Every argument I heard from you, to twist, bend or simply change common conceptions to keep this stupid "64 bit" term, either makes you seem quite unknowledgeable in pretty much anything BESIDES the Jaguar, or (what I personally think is more the truth) you just LOVE to be the "deity" of a Jaguar worshipping audience, and thus, you love to do ANYTHING to keep that up, even if it includes passionately repeating & acting the moronic official marketing politics of Atari in the face of heretic "unbelievers". This, and the way you usually behave when you are cornered in a technical discussion (change the topic, twist words, appeal to authority), puts A LOT of doubts in me about you, and especially this post, in this totally unrelated thread, pretty much acknowledges most of my suspicions. You are a truly born politician. Yet, and that's the beauty of it, it changes NOTHING about cold technical facts written on paper, and etched into silicon, no matter how many people you are able to bring up against me. The only thing I get again is a repeated taste of your ignorance & inability to read my posts properly. Besides, this is hardly the place to talk about Jaguar matters, isn't it?

Yeah, it could have played video tracks from a *very* expensive and bulky laserdisc accessory. Laserdisc games just worked 1, maybe 2 times (Dragon's Lair & Space Ace), and then the whole technology lost its appeal to the player, since Laserdisc games practically hardly have any gameplay. Besides, add-ons NEVER worked for the console market, the most prominent examples being the Sega CD and 32X. And Laserdiscs are much more bulky and limited (in terms of data storage, since it's an analogue medium) than CD-ROM's. And don't get me wrong, a Laserdisc add-on would have been a financial desaster for ANY game console manufacturer.

The Astrocade has 4K of ram, you spoiled brat! The most prominent system where your ability and ingeniuity as a coder directly translates into gameplay is clearly the good old 2600. From that perspective, you are right. Nevertheless, if you talking about minimalist CPU driven hardware, hardly anything beats the 2600. 4k of video ram...

How can one argue against that? I guess patriotism and objectivity doesn't mix. This discussion here is not about what the 7800 can not do, it's about what the 7800 can do better or worse than the NES. Your kind of argumentation is simply not right, every hardware architecture has its limits. You can simply not do anything you want, especially on those old machines. You have to be creative and inventive to make something cool out of their limitations.

You could change the color intensity bits mid scanline since it's a separate reg ($2001) Yeah, I forgot that. I think Noah's Ark uses this effect. The NES has several limitations, which, and I give you that, limits it in doing raster driven effects. They probably invented this idiotic "Sprite 0 detection" method to dodge Commodore's patent on the programmable raster IRQ counter... (Yes, that patent really exists).

The Colecovision can do as well "smooth scrolling" as an 1977 Apple II. Nothing in the Colecovision hardware is build to make games scroll. The CPU has to do all the work. Therefore, you are the person being unreasonable and strongly misguided about the concept on "smooth scrolling" on the Colecovision. And quite frankly, I don't give a hoot about the opinion of someone, who has never programmed the 7800 at all (and I pretty much doubt you know anything about programming and hardware architectures at all), and doesn't even know what a PAL television is. Facts remains facts, no matter how many ad hominem attacks you are throwing at me: YOU are the one who clearly lacks even the most simple understanding in these matters. And you, the one without the slightest bit of knowledge, are to be the judge about my abilities. :lol: Who are you to judge what is "nearly enough" ? You don't understand even the most primitive basics of what WE (yes, not only me) are talking about. Proof again you did not understand anything we were talking about. I, and other people, explained it almost a dozen times to you. But it's more like teaching tap dance to a monkey than making you understand what the difference is between hardware and software scrolling, and what the consequences are. Simple, the Colecovision needs to spend a huge amount of CPU power and memory to shift and copy graphics around to achieve smooth scrolling. This has been mentioned several times before, also by other people than me, my dear friend. In comparision to the Colecovision, the 7800 is only limited in resolution and sound. In Colours, number of objects and scrolling, it is vastly superior to the Colecovision, simply because Maria CAN do it. The Colecovision, as I said again, will have great trouble in smooth scrolling full-screen, fully coloured tile displays, because you would have to shift ALL character graphics in VRAM using the CPU, and furthermore, the fixed 8x8 colour attribute boundaries, which can NOT be made to scroll, pretty much prevent it from using colour attributes freely. The 5200 has no problems with it, since it can move and shift all tiles per hardware. The same with the 7800 and NES. Thats exactly the purpose of hardware scrolling. No, 4. You even fail to research the most simple facts about this chip. And the Colecovision doesn't "flicker" sprites, it simply drops them. Flickering is achieved through software by cycling the Sprite priorities. It surely means nothing looking at the huge software library of the 7800... The NES still has the superior sound compared to the SMS. In case of the NES, it is clearly the software which drove the hardware. But that is irrelevant in regards to the lack of scrolling capabilities of the Colecovision. The Colecovision was produced before the videogame crash, the NES revived the market through 1 single game: Super Mario Bros, which is still the most sold game in history (40.000.000). Yeah, blablabla, it's completely irrelevant to your original question, which ironically is purely technical in nature, but you refuse to accept any technical explanation, to compensate for your lack of knowledge. So, as a discussion partner, all you have to offer in this discussion is whining and bickering. Well, then this whole discussion is pointless, because the tech-specs clearly determine what a hardware can and can not do. Besides, if you consider the \"end results\" (the whole software library of the Colecovision), the Colecovision would be a far worse machine than the MSX1, although both architectures are almost similar. That\'s why the best way to discuss these matters is on a technical level. It is not my or other people's fault if you fail to comprehend or participate in these discussions. Only if they are imcomplete, like the illegal opcodes or other hardware tricks on the C64 and other 8bit architectures. They do not tell YOU anything. I have always said that the Colecovision can not do hardware scrolling and this remains true, no matter how much you ignore and twist my words. In the previous post>>s<<, I already explained to you that pretty much any hardware with redefinable characters or a bitmap display can do some sort of scrolling, since *drum roll* CPU's are made to move data! Now, get through your head again why, other architectures are even considering implementing hardware scrolling. We already told you several times. And I won't go into further detail until you, at least, try to read the other posts in this and those other idiotic "7800 vs..." threads. No, I already did it several times in several threads. Besides, >>I<< have to do nothing. It is >>you<< who is whining and constantly requesting people to spoon-feed >>you<<. What you basically asking for is someone coding games for you to prove this point. May I be so frank and tell you that your lack of education in those fields simply isn't worth it? How much arrogant can one get? Stop asking technical questions. You are a non-technical minded person. You are a gamer. And a gamer should play games instead of wasting other people's time. And, if I may be so frank, you are as much, if not more, arrogant than me, with the big distinction that, contrary to myself, you have NOTHING (and I mean REALLY NOTHING) in your hands to participate in this discussion, yet, you are constantly trying to question people's knowledge, instead of listening and comprehending. Trying to educate you on these matters is like feeding a black hole. You are consuming energy, yet, you give nothing back to this universe.

Which, as I said again, is nothing special. All hardware architectures which support at least redefinale characters or bitmapped screens scan do some sort of smooth scrolling using the CPU. This, as I said again and again and again and again, is much more limited and CPU intensive than hardware scrolling. Those games aren\'t exactly very demanding. They pretty much use every trick available on the CV to achieve something which is pretty much unimpressive on architectures which support hardware scrolling.

Raster interrupts with certain mapper chips (excluding sprite 0 flag limited method). I was referring to the sprite 0 flag method, which is a method to generate a raster interrupt, no matter how limited it may be. Granted, the DLI's are more flexible, but it's not that the NES couldn't do certain raster effects. If vdub wants to pimp the 7800 with more ram, then I just want an MMC3 mapper then. But the situation then would be that the 7800 still has no colour attributes, but the NES can now do much more flexible raster effects. You could do a forced vblank. Some games use it for the status bar having different colours than the screen.

But in order that the wrap qround takes places, you need to DMA a bigger character map than pixels available per line, right? The Maria documents says, wrap arounds occur when an object crosses the 255 x position, so you have to display 160 pixels, plus the invisible 96 pixels. If that is the case, you are basically using the whole DMA time available per line. Are you coding a Battlezone port? I was just thinking, with enough extra card ram, one could do a faithful Missile Command port using 320B mode.

You know pretty well that this technique is severly limited, and does hardly compensate the lack of attributes. I can also code wonderful gradients on the Atari 2600. Besides, the NES also has raster interrups, and many games do also change the palette during screen rendering. And yeah, my point is , with the right hardware add-on, you could even make a Doom clone on the 7800. Slow??? It's super fast! You just write to 1 port, the NES increments the VRAM address for you. That you can only do it in VBLANK is indeed negative point, but on the other hand, you have no other DMA busmaster stealing cycles form the 6502 on the NES. They become indeed difficulties one you try and recreate what the NES can do with its fixed rendering pipeline. I know how this works, yet, you are silently dropping the point that DLI's are hardly a compensation for the lack of colour attributes... And again, the NES can also scroll different screen areas using raster interrupts. On the NES, you need not copy whole lines to have continuous scrolling. You just update the tile at the border of the screen, and use the full range of 0-255 for the scrolling registers. Again, I never said that scrolling games are impossible, but you guys are now trying to make the 7800, one of the most complex 8 bit graphics architectures, look as if it was easier to code for as the NES, which is clearly WRONG! You started with a quote from me, so I naturally suppose the whole post is directed at me. I am not taking offense at you, I am just having a heated debate.

Maria can not do tile displays with colour attributes. Maria has no wrap-around when scrolling tile displays. Maria has to sacrifice resolution in order to display more colours. Maria has to sacrifice colours in order to display more objects. Yeah, because it needs to do this because it stores its graphics in a line buffer. Otherwise, you would have a non-functional garbage display. Other architectures neither have nor need a line buffer. No one disputed that the 7800 can do NES style games. I am only disputing that the 7800 can do them equally well. What wrap-around are you talking about? Maria has no wrap around when displaying a tile display using indirect mode. And what exactly is so hard about writing the 2 scrolling registers of the NES???The NES even increments the VRAM address for you, either in 1 (for horizontal stripes - vertical scrolling) or 32 steps (for vertical stripes - horizontal scrolling). So, have a fully coloured background, where each 8x8 or 16x16 block has its own colour attributes, and then tell me again what is done easier on which platform.... LOL, that is exactly the advantage the 7800 has over the NES. And you apparently never heard of 160B mode, where you can use 12 colours per object. I have a strange feeling... I completely disagree. If you run out of cycles or DMA time, NONE of your abilities as a coder will help you. Perhaps you can push the barrier a little further than others, but every architecture has its limits. Your ability and imagination lies in making the best out of its limitations.

Let's see what happens if I drop a Vectrex on a 7800...

You can do smooth scrolling on pretty much any architecture which has a bitmap display, or redefinable characters. The fact remains that the Colecovision does not support it in hardware, and the ways how to achieve this are very limited. While Matt Patrol is indeed an impressive effort on the Colecovision, on the 5200, 7800, NES, C64 etc. it would be less than average. The Colecovision can not do hardware scrolling, the 7800 can. And we already explained the limitations, but you again, due to your lack of understanding what we are talking about, you ask the same questions over and over again. Though you can apply all techniques learned from the C64 hires bitmap mode to the Colecovision (the colecovision can even do more out of the box, since you can change the fore/background colour pair every 8 pixels, similar to the C64 FLI mode), the biggest limitation, worse than the lack of scrolling IMHO, with this machine is that it can only display 4 sprites per line. On the contrary whith the NES, I think the 7800 can, with no problem, do every game the Colecovision can do. The problem again with the 7800 is: more colours, more objects, but resolution is usually lower (160 pixels v.s. 256). The 320 modes have very little useage for games except perhaps score/status displays. Those achievements are impressive for the Colecovision, but are, again, no challenge for those architectures which support smooth scrolling in hardware. I am not so sure about this, because, although these are great games, the scrolling is jerky, and the graphics can not match the NES versions of those games. Take that, and the excellent software support of the NES. You forget that the 7800 is downward compatible to the bigger success of both consoles, the 2600. Untapped potential does not mean being able to port games from each platform to another, but to use the strengths of the hardware. And, besides, even if you are a master coder, you still need a great game. I'll take any good 2600 game over a badly or even mediocre designed 7800/CV/NES/SNES game. That is a concept which defies the whole purpose of these nonsensical "7800 vs...." threads. Nonsensical from a gamer's perspective...

The only official successors of the 9918 are the 9938 and 9958. All other designs were redone from scratch on a gate level, but implement specific key features introduced by the 9918 exactly the same way. Yes, but the TMS9918 introduced it. Atari / Commodore designs are mostly based on 14,318Mhz master clock for 160/320 pixel modes. The Genesis / PC-Engine support both 320 and 256 resolution modes. Yes, but this valid conclusion is no contradiction to the fact that all designs I mentioned are based on the 9918. The pixel clock was not the only aspect I was referring to. All designs I mentioned share the same way sprites and VRAM accesses are handled, and although they are more capable than the 9918, the basic architecture is the same. It's a completely different way how Commodore or Atari implemented tile based graphics or sprites. Charles is a very capable person with huge knowledge, so I believe him. Nevertheless, the Genesis VDP is a heir of the 9918.

This is almost correct. MSX1 and Colecovision use the same videochip. The Sega Master System however, uses its own videochip developed by Sega, which on the other hand, IS backward compatible to the MSX/Colecovision videochip. And this backward compatibility is also present in the Genesis and Game Gear VDP. Yes, the 16bit Genesis CAN display the original MSX1/Colecovision graphics modes! I suppose all of you know that the Genesis can also play SMS games. You sure about that? I thought it was just the SMS modes the Genesis VDP could display and lacked the SG1000 modes. Wikipedia says it can not display the 9918 modes, other technical documents indicate it can. I already quoted the connections. That they are tilemap based is the most obvious fact, but not unique to the 9918. However, the strong connections, which have been introduced firstly by the 9918, and which ALL of its heirs have, are: - Timing is based on the same pixel clock (5,37 Mhz / 10,73 Mhz), 340 clocks per line (the NES/SNES adds a single 341 clock scanline so that the colourburst rolls) (that's why all those designs can display 256 pixels horizontally, occupying the whole scanline) - Strictly seperate cpu/video buses - Access through address/data ports, with the address port self-incrementing - Sprites are multiplexed by the hardware, so that the hardware can manage more sprites than it has DMA time to display them per line - Sprite overflow flag to indicate too much sprites per line These are the basic elements which have been introduced with the 9918, which have been used as a blueprint for most 80's japanese consoles. Basically, you have 4 main branches coming from the 9918: TMS9918 (1979) * *********************************************************************** * * * * NES PPU (1983) V9938(1985) SMS VDP(1986)************ PC-ENGINE VDP (1987) * * * * * * * GG VDP (1991) SNES PPU(1990) V9958(1988) GENESIS VDP(1988) Read through some hardware documents at www.romhacking.net and you will clearly see the connections.

Right, you can develop some very pretty games on the Game Gear (but also on the SMS). That's why it is a shame that 1st grade companies like Konami never developed any games on it, because they probably would have pushed the envelope quite far, especially looking at their MSX games.

This is almost correct. MSX1 and Colecovision use the same videochip. The Sega Master System however, uses its own videochip developed by Sega, which on the other hand, IS backward compatible to the MSX/Colecovision videochip. And this backward compatibility is also present in the Genesis and Game Gear VDP. Yes, the 16bit Genesis CAN display the original MSX1/Colecovision graphics modes! I suppose all of you know that the Genesis can also play SMS games.

Seems to be a Z80/8080 based microcontroller architecture, although the mnenomics differ a bit from the Z80. The register architecture, and how they are used for addressing, seems to be the same.

I am talking only about the NES PPU, which is indeed an evolution of the 9918. They are both programmed the same way, they both share the exact same video timing, they both share the same way in handling sprites, and they both have similar kinds of limitations. Get your facts straight before lecturing me what I don't know... The TMS9918 is, like the NES PPU, a custom chip, with the only difference that the 9918 was used in several systems. You could easily hook up a 6502 CPU to a TMS9918.... The MSX1 uses the same video chip as the Colecovision (9918) and has the same CPU with the same clock (Z80 @3,58 Mhz). Porting games over to each architecture isn't hard at all, only the sound and the memory map differ. Wrong, the Sega VDP is a completely different offspring, which is also compatible to the 9918. Plus, contrary to the MSX, which uses a AY-3-8910 soundchip, the SMS uses the SAME soundchip as the Colecovision (SN76489), so the SMS is CLEARLY NOT adapted from the MSX. Sega went their own way in expanding the TMS9918 architecture, which you can easily see when comparing the SMS VDP to the official successors of the 9918 used in MSX2/MSX2+ machines, the 9938 and 9958. Again, get your facts straight. The Colecovision TMS9918 VDP (which was previously used in the TI99/4A) is the ancestor of many different graphic chips developed in the 80's, including the NES/SNES PPU, SMS/Genesis/GG VDP, MSX2 9938/9958 VDP & PC-Engine VDP. The SMS/Genesis/GG VDP's are even downward comaptible to the 9918. They still can display its native video modes! And before you tell me that MSX1 has the TMS9929 VDP: it's the PAL version, which has also been used in the PAL version of the Colecovision.

"Stronger or weaker" and "Less powerful or More Powerful" are simplistic conclusions to a complicated question. I'm a bit confused about the specs, because there is practically nothing really documented (even the CPU, though normally, a NEC uPD780 is a Z80 clone), and some specs seem a bit unorthodox (128 Sprites??? As much as the SNES? I doubt it.), especially when looking at the screenshots. Plus, I never used or saw one in real life. Very interesting though.

Yup. If you want a 160-line view, just design a cart with its own CPU that can do all the drawing it has to do in 102 line times, and can then feed the data in response to MARIA DMA requests. One could do some pretty amazing games using that technique; the cart could probably cost less than $50 to produce. That was exactly what I had in mind. With the amount of storage you get now for very little money, many old systems suddenly become attractive for displaying full motion video.

I have never heard about that system. But the specs surely are less than impressive...

I recently took a look at Matt Patrol, the Moon Patrol port for the Colecovision and the parallax scrolling it does is very impressive. I really didn't think that was possible on the Colecovision's hardware. Any idea how it was done? There are some possibilities. The Colecovision has a whopping amount of 16kb VRAM, so there is lots of place to store preshifted tiles, where the graphics data is formatted like this: tileset 0: ----*--- ---***-- --*****- -******* ******** tileset 1: ---*---- --***--- -*****-- *******- ******** tileset 3: --*----- -***---- *****--- ******-- *******- etc.. So fine scrolling would be achieved by a combination of updating the tiles and the character graphics pointer. The scrolling hills are very repetetive, which is an indicator that this technique might have been used. This technique however is severely limited. Another Possibility would be combining Sprites with character graphics. s = sprite c = character ss ssss ssssss ssssssss sccccccccs ssccccccccss sssccccccccsss ssssccccccccssss sssssccccccccsssss ssssssccccccccssssss sssssssccccccccsssssss ssssssssccccccccssssssss The only problem is now that the Coleco can only display 4 16x16 Pixel Sprites per line, which means only 2 mountains per line, so make em big!