jbanes
-
Content Count
3,083 -
Joined
-
Last visited
Posts posted by jbanes
-
-
Antic is able to read the gfx data from different memory locations so you can write into a memory area while displaying a different one.I if you are finished writing to memory you just switch the pointer to this location.
The next operations can work on the memory displayed before and so on.
This technique was called "page flipping" and I would say it's a kind of framebuffer.
Indeed. Page flipping is also often used as a feature in framebuffer hardware that's got way more onboard memory than it needs for a single frame. Obviously it's a lot faster than double buffering, which requires that the full screen be dumped to vidmem after being constructed in main memory.
The cool part about the ANTIC's approach, however, is that it can not only perform a page flip, but a complex display list list (I love that name
) could actually interlace various line buffers to produce different neat effects on a shoestring memory AND CPU budget. That's a rare thing in my experience. Usually you trade one for the other. Of course, after all the *#[email protected] "fun" I had with SuperVGA bank switching, I never thought I'd actually be praising the ability to have a disjointed video memory map.
-
I don't know what screwball definition of "framebuffer" you've internalized, but on the Atari 8-bit computers and 5200, you can set up a contiguous block of RAM which will automatically display anything you stick into it without further CPU intervention. If that's not a frame buffer, I don't know what is.Ok, fine. How? I'm looking at the ANTIC docs right now. Taking Mode 8 (mentioned by Jaybird previously) as an example, "This mode, as other non-character graphics modes do, uses data in the display buffer as a bit map to be displayed. A command to display in mode 8 will cause the ANTIC chip to read the next 10 bytes in the display buffer." Each mode after that specifies the same thing, only with different pixel sizes and color counts.
Now I have no doubt that you can configure a display list list to emulate the framebuffer. That's still not a true framebuffer, though it's pretty darn close. The biggest problem with this scheme is that you're locking out your CPU every time the graphics hardware needs to be fed data. (Most true framebuffers have their own memory to generate the signal off of. This frees the processor to do other things. The IBM PCjr differed in that it used a Shared Memory Architecture, but as far as I know this didn't impact the main processor.) As Bryan stated, this scheme results in a significant drop in processing power. I originally thought that the GITA must be fed on a different bus, but I was corrected on that one. Which means that there are distinct disadvantages to the ANTIC emulation of a framebuffer.
-
I try to get out, and they pull me back in!jbanes, seriously, YOU HAVE NO CLUE WHAT YOU'RE TALKING ABOUT. You think you do, but you don't. You really, really don't.
Dude, chill out. Again, we have a failure to communicate here.
Not the Apple routines. These are too primitive for Bresenham's algo. They draw only horizontal or vertical lines. Which I'm not saying that Choplifter is using, but probably something similar, perhaps custom.Do you realize that the "Apple routines" are just software? There's nothing magical about them. They're just 6502 code.
Yes, I do realize this. I was stating that the standard Apple line drawing routines (at least the ones I mentioned, see the paragraph below) are too primitive to implement Bresenhams. They draw a line either vertically or horizontally. As I said, Chopper Command probably uses custom drawing routines for speed. It one of the first things that game programmers did back in the day.
Do you realize that in HIRES mode, there's a command that can draw lines between any two arbitrary points? Not just horizontal and vertical?I was digging a bit more through the reference material, and it looks like you're right. There's an HPLOT command in the AppleSoft commands for Hi-Res mode. I was looking at the Integer BASIC command set as an example. Thanks for pointing that out.
Do you realize that a 1-MHz system simply IS NOT FAST ENOUGH to draw and fill a complex vector object in realtime? For a real example of a game that uses vector objects, look at Out of This World/Another World. That ran sluggishly on systems vastly more powerful than the Apple II.Two points:
1. Define "real-time". Like I said, with a framebuffer you can drop your framerate and still produce a highly playable game. 1MHz is definitely not a lot, but to rotate a single sprite that isn't that bad. If you're running at 10FPS, you have about 100,000 cycles per frame. Since you're not forced to spend the majority of that updating the screen, you're left with a LOT of time to do your work in comparison to a 2600/5200/7800. So rotating a single line-art sprite *is* possible.
2. Out of this World was an all-polygon game. Without some sincerely bizarre magic, you can't render that many polys on a 1MHz system. Hell, most Apogee and ID games could barely run on a 10MHz PC with full 2D graphics. And those guys were wizards at this stuff. That doesn't mean that you can't compromise. Might I remind you of... (wait for it) Ballblazer?
Do you realize that I pointed to a hypothetical version of Gravitar? Of course I know that Chopper Command used a set of bitmaps! I chose a different situation because I was trying not to give the impression that I was saying that Chopper Command used line art for the chopper.
I've already named the primary fill areas on the Choplifter screen: The scoreboard, the ground, the stars, etc. I have questions about the base itself, and about the rotor on the chopper. I have no doubt that the Chopper, the People, the Tanks, and the Planes are buffered sprites.
The general topic here is advantages of 5200 vs. the 7800. The 5200 gained a lot of Apple ports because it was able to emulate a framebuffer. The 5200 does NOT have a true framebuffer, as the main processor has to setup a blit of each partial line of data via a display list at the time of the screen rendering. (Thank you to those who pointed me toward the ANTIC docs. They were very informative.) A true framebuffer generates a signal off of video memory, and will do so independent of instructions from the processor. This is probably why the 5200 Choplifter flickers while the Apple II version doesn't. (At least in the emulators. I have no reason to believe that the real hardware is any different, though.)
Now, will you please calm down?
-
Umm... let me guess that you're not a 6502 coder and have never done anything with any kind of assembly.I used to do quite a bit of assembly on the IBM PC, and I have tried my hand at the 6502. (It's kind of fun to do, BTW. The instruction set is so simple in comparison to most other processors.)
Any 2-D graphics library is designed to provide maximum flexibility, not speed.Not the Apple routines. These are too primitive for Bresenham's algo. They draw only horizontal or vertical lines. Which I'm not saying that Choplifter is using, but probably something similar, perhaps custom. He needs a fill routine for several areas on his screen, plus point routines to create the stars. If this was an Intel, I'd use a REP STOSW loop to blit the fill as fast as possible. Sadly, you can't do that sort of thing on a 6502, and have to resort to a standard loop or some sort of hardware acceleration. On most Ataris I've seen, this isn't such a big problem as each byte of data is used to produce 8 or 4 pixels of 1-bit or 2-bit color.
I confess to not knowing all the details about how the Apple II framebuffer worked (other than it's worse than programming bank switched SuperVGA), so I wouldn't quite know how the developer would go about writing the high-performance line, point, and fill routines, but the concepts are the same. You have a starting point, and ending point, and the routine performs a fill between. Taking the Atari 2600 and 7800 as examples, you can't really perform that same sort of fill without some trickery. A vertical line is not a vertical line, but rather a blip on each line that needs to be rendered. This makes programming these systems rather interesting since you don't have the memory to simply pre-compute the values, then pump them to the screen when the time comes.
(Side Question: Does anyone know if the SuperCharger games used framebuffer emulation? With an extra 6K of RAM to work with, it strikes me that they could have done much of the playfield rendering in memory during the Vertical Sync. The graphics could have been pumped directly from memory before and during each scanline. But I'm getting off topic.)
So it will spend huge amounts of time drawing a line point by point using Bresenham's algorithm, each point requiring multiple shifts to set the right bit in the byte.If you want high performance, you don't use Bresenham's. At least not back then. One can get away with a lot on modern computers, but back then you tried to use something faster. Even Breshenham's, however, can be much faster in specific circumstances. For example, if you wanted to port Gravitar to a system, it's going to be a LOT faster to rotate only the end points and draw the sprite line by line rather than rotating each individual pixel. This is effectively the method used in most early 3D engines. Rather than rotate and scale each pixel in the texture, it was far faster to rotate the ends and use a line drawing algo. Of course, Affine Texture Mapping wasn't exactly the best looking, but it was screaming fast.
Contrast that with a simple load/store loop of a pre-rendered sprite from ROM to screen RAM. Or, even better, updating a GPU register or two if the console supports sprites.Certainly. Sprite hardware will always be faster than a frame buffer. The primary advantage to a frame buffer is that you are not limited (graphics-wise) by the hardware. So if you need to draw a highly detailed background with a large number of foreground objects (such as Microgammon SB), you're not limited by a specific number of sprites or the auto-expanding of the playfield registers/display commands.
There's a reason that games of that generation were custom written in assembly and typically didn't use BIOS routines for anything they could do themselves - flat out speed. Even a JSR/RTS (GOSUB/RETURN equivalent) on the 6502 requires 12 cycles. On the 2600 that's 16% of the time it takes for the TV to draw a single line, and the Apple ][ wasn't clocked that much faster.The Apple II, as I understand it, was actually clocked slower than even the Atari 2600. As you said, it's amazing that it was ever able to do an action game like Choplifter. Of course, with a framebuffer you do have one major advantge: Framerate. The Ataris forced programs to keep up the 60Hz signal no matter what. With a framebuffer, you can drop to 10FPS and the hardware will make sure that the screen doesn't flicker.
-
You're probably right, but it's fun to kick around ideas like this. See if you can get people thinking outside the box, as it were.
Looks like at the moment we've got a three way tie between "Yay", "Nay", and "Huh?" We'll have to see if a concensus emerges or if the idea is just too weird.
-
Nah, just trying to communicate. I'm not always successful, I'm afraid. Like I said, I called it "vector-like" for want of a better term.
Believe it or not, I am listening to what people are saying, and I am learning new things. Sadly, I'm not always good at making that clear. My apologies if my failure to communicate is causing you any grief.
-
A big part of the appeal of the old 2600 games is their "pick up and play" nature. Intellivision games, on the other hand, were developed under the guiding principle of being complex. Nobody is going to want to dig out an instruction manual to figure out how to play Utopia or whatever these days.That's not true of all the games, however. Take Shark! Shark! as an example. Simple, straightforward, and easy to play. Similarly, Astrosmash, Atlantis, Beauty and the Beast, and many others are easy to pick up and play. These could easily encourage users to read the manual for more complex games like Star Strike.
Also, you may be underestimating the difficulty in getting started with a VCS clone. It might have been obvious in the late 1970's to use the reset button to start a game, but in 2006 it often confuses players. Similarly, games like Radar Lock, Quadrun, and Fatal Run require manuals to understand their complex controls or gameplay.
And remember the overlays? The ones that were absolutely necessary until you'd memorized the functions of all TWELVE keypad buttons in every game? How the heck would a hypothetical Intellivision Flashback handle those?Indeed. I was thinking about throwing one of those promo images for the overlays onto the box mockup I did. I don't see any reason why the overlays for the bundled games can't be included. They're not that expensive to manufacture.
Hrumph. You guys are no fun.
-
Sweet zombie Jesus. Talk about a little knowledge being a dangerous thing.It sounds like you think that Choplifter used the Apple's shape table functionality to draw the chopper. Well... no. First, shape table rendering is way too slow for a game like Choplifter (the Apple II was only a 1-MHz system, remember). Second, shape tables only support vector outlines, not solid-filled bjects.
Who the heck is talking about shape tables? I'm talking about basic drawing commands. You know,
PLOT x,y Draws a dot at location x,y
HLIN x1,x2 at y Draws a horizontal line from x1,y to x2,y
VLIN y1,y2 at x Draws a vertical line from x,y1 to x,y2
Various points are filled in using routines like these, such as the stars, ground, and score table. Modern libraries (and even several on other systems at the time) have much more complex routines that allow for diagonal lines, filled primitives, and other fun features. (Which again, are vector in nature, but are rasterized to the screen.)
So the chopper in Apple II Choplifter is exactly what any reasonable person might think it is-- several dozen predrawn bitmaps, blitted to the screen as necessary. The Atari computer/5200 versions are pretty much straight ports, complete with the crappy artifact colors endemic of straight Apple ports.So the stars are bitmaps? The scoreboard? The ground? I find that highly unlikely.
Like I said, it's not true vector graphics. But I don't know what else to call it in comparison to the full sprite versions of the Sega and 7800 versions.
-
I want the FB3 to be...
...An Intellivision!
...
Um, actually the FB4 since the FB3 is probably finalized at this point...
You can pick your jaws up off the floor now. I haven't quite lost it. (Yet.) Just hang with me for a moment while I explain.
You see, while Atari has a large number of classical holdings, they are really only well known for one of them. That one is the Atari 2600. The problem is that they've already used up their 2600 card with the Flashback 2.0. From here on out, Atari is going to be fighting an uphill battle in getting their new, non-2600 Flashback units accepted. Hopefully they'll be very cool and will go over well, but each generation is going to have to be more technologically sophisticated. Even doing an 8-bit computer as has been suggested would be much more difficult than the original 2600-on-a-chip. (Not to say that they can't do it. I have faith in Curt and his team.)
To make matters worse, any attempts to create a Flashback 5200 or 7800 will be hampered by the fact that these consoles' libraries are mostly composed of Arcade ports for which Atari may or may not have the rights. What's needed is a simple hardware platform with an abundance of games that are not tied up in complex licenses.
Now consider something for a moment. IntellivisionLives.com has rights to hundreds of games that are not encumbered by third-party licenses. They've got the software, they've got the original team of Intellivision developers, and they've got everything except the resources to build Intellivision hardware. Their attempts at a PNP system to date have been poor, and have completely missed any sort of attraction the system might have to consumers. As far as most people are concerned, it's just another gamepad with lousy games.
Atari, OTOH, has the resources to build the hardware. They also have the "Flashback" name, which is well on its way to becoming its own brand. What they need are unencumbered games. So if Atari enters into a deal with Intellivision, both companies win!
My friends, I give you: The Intellivision Flashback!
Just imagine the library this thing could have:
Shark! Shark!
Star Strike
Minotaur
Astrosmash
Atlantis
Beauty and the Beast
Bowling
Chip Shot Super Pro Golf
Diner
Space Spartans
White Water!
Dragonfire
Demon Attack
Stampede
World Series Baseball
And many, many other cool games! All packed in the stylish and sleek form factor of the original Intellivision. Personally, I think it would sell like hotcakes.
Minor Edit: Fixed some typos
Edit: Looks like Curt has turned his attention to making an actual Intellivision Flashback! So if we can convince Keith, the FB4 may very well be an Intellivision console!
-
Seriously, though, I agree with mos6507. The original, pre-Warner Atari was a very unique mix of personalities and technologies that came along at just the right time, and created a lot of the momentum that the company later lived on.I've heard some of the Atari alumni talk about how they tried to get back together again and recreate the magic among themselves, at Sente and at other places. Even they didn't succeed, so I don't know if it's even possible to reassemble ALL of the ingredients that made the early Atari successful in today's world. Even if Infogrames wanted to, how would they do it?
That's why Infotari *cannot* be that old Atari. Anyone carrying the Atari name must be a new company, with new ideas, but leveraging the old name to market those ideas. So far the Flashback 2.0 is the smartest move that Infotari has made yet. It has done well for the company, and has paved a road forward that I feel they would be wise to follow.
The problem is that they're going to have to get creative with this road. There are only so many old systems to revive. I think that Infotari would do well to investigate some of the holdings they inherited with the Atari brand, and perhaps use 20/20 hindsight to bring previously unreleased concepts to market.
Take the holographic handheld as an example. The implementation from back in the day just wouldn't work now. But nothing stops Infotari from developing a new device that builds on that technology. Imagine, for example, a handheld gaming system that replaced its screen with every cartridge. The cartridge itself would consist of the transparent Hologram, LCD pictures, and coloring over the LCD pictures. The coloring would be lit up by the unit's backlight, giving the illusion of a very colorful handheld game. Priced right, such a device could do well in today's market.
Another idea is a laser-projector, vector-graphics console. Can you imagine reliving Asteriod, Tempest, Gravitar, and other vector favorites, but projected directly onto a large wall instead of a tiny Vectrex screen? The technology exists, and is currently in use by hobbyists.
Basically, Infotari can have a very interesting future ahead of them. But they're going to have to play this different than everyone else, and follow the niche they've created.
-
WTF are you talking about? Vector mode? The Apple II version of Choplifter uses bitmaps, just like every other version.*sigh* I stated "vector-like" and "vector-style" several times before I dropped the moniker. It should be obvious what I'm talking about.
Basically, the 5200 version appears to emulate the Apple II's use of line, box, and other primitives that can be achieved on most systems via their basic graphics routines. The routines are actually vector in nature, but are normalized to a framebuffer. The graphics work on the 5200 because the 5200 has enough memory to emulate a framebuffer, whereas the 7800 doesn't. I *believe* that the 7800 could perform the same graphical feats, save for the fact that it lacks the memory. That's part of what makes it so much easier to draw bitmap mountains in the background rather than twinkling stars. (Like in the original.)
People who make stupid statements like this are ALWAYS doing themselves a disservice. This is the exact same thinking that produces the "5200 is waste of plastic and solder" line. Neither one is true, and you ought to be ashamed of yourself.
The truth of the matter is quite simple. The NES beat the 7800 technologically in the same way that the 7800 "beat" the 5200. Like we've been discussing, the 5200 had more memory, more powerful controllers (even if the non-centering point sucked), and a few other points in its favor. It's generally beat out by the 7800, however, by the fact that the 7800 can produce more sprites that look better, and more complex playfields.
In the same way, the Nintendo beats out the 7800 not on the number of sprites, but on its "cheap trick" of providing a tiling background and more earthy color tones. In addition, the Nintendo also had far superior sound and music ability, in a time when gamers were not used to background music in their home consoles. These factors combined, and made for a "superior" console to the 7800. Sure, the 7800 could push more sprites, but that doesn't help anyone when you have no need to render so many. The Nintendo's sprite capability was sufficient for most games, leaving the rest of its features to carry the day. Combine this with the superior artistry demonstrated in the games from Japan, and you will find that the 7800 never stood a chance.
-
Not a chance. That show (Enterprise) was a hideous abomination that never should have been. Bad acting, bad plots, bad continuity, and the producers absolutely despised the fans. I can't beliece that there were those trying to keep it on the air. They should have spent their energies on FireFly, a show people actually wanted to see. Oh well, no accounting for bad taste.
No, I just happen to know a few things about business, that's all. I'm not necessarily saying that fans should buy out Infotari, I'm just pointing out how it could work.
-
I've thought this myself ... but what exactly would we the fans done with it?Released all the ROMs into the wild? Atari gave us Atari Anthology, which essentially did that already.
Even the most loyal fanbase in the world doesn't have the manufacturing capability to make something like the Atari Flashback 2.
First and foremost, you need to realize that a holding company would be setup to actually "own" the mark. The fans who ponied up the cash would merely be investors. Since a company is directly responsible to its investors, the holding company would need to do whatever the fans say. (Might make sense to run it as a Co-op.)
Secondly, I think that such a company would do well to expand on its hardware console business. The flashbacks are a great start, and the old ST-style lines can be continued with new computers for kids. A new game console should be released, targetting the "casual gamer" and "young children" markets. That would keep it from going head to head with the Big 3 consoles. Yet through a fairly traditional licensing scheme, the fantari company could make much of its money off of third party title royalties, many of which would be created by fans.
Basically, fantari could cream LeapFrog and VTech in one fell swoop, and use the name recognition to convince parents to purchase their hardware and software for both their kids and themselves.
Thirdly, since fantari would be a "real" company, it could make the necessary deals with manufacturers to get its hardware produced at industrial rates. The only barrier would be the capital, which would be provided by investors and early sales. If necessary, fantari could run very small batches at higher prices to begin with, then use that capital to produce larger batches at lower costs.
Sound like a plan? Cool. Now who's going to be in charge of raising the capital?
-
Definitely the NES. Despite Nintendo's attempts to keep the number of games down, the library ballooned out of control by the time the SNES came around. You may remember the Toys'R'Us promotion where they had an entire WALL of games for $20 or less.
The 2600 had a respectable list, but the newness of the console made it slow to take off in title count (remember, it was only designed for about 10 games!), then the crash of '83 brought cartrige production to a screeching halt. All in all, it got about 7 years of development. In comparison, the NES was going strong in both the Japanese and American markets for about 8 or 9 years. Note that while the NES wasn't released in the US until 1986, the massive software base for the Fanicom provided the NES with a large launch library of titles.
The last official title to be released for the NES was Wario's Woods in 1994. (Three years after the release of the SNES in the US!)
-
You know, that game was amazingly addictive. I almost never pumped quarters into a machine when I was a kid (I'd wait until I get to Showbiz, where my parents gave me tokens), but something about Stun Runner made me sink tons of money into it. I think it was a combination of innovative gameplay and the controller. Since you can't reproduce the controller at home, it's just not as much fun to emulate.
It's too bad S.T.U.N. Runner fell into the dustbin of history. I always got the impression that the game didn't do all that spectacular when it was released.
-
Centipede. I can just boot the sucker up, sit back, and mindlessly blow things away. Millipede smokes my rear way too fast. Besides, all those mode switches interrupt my mindless shooting trance.
-
Very nice. When can I get a cart?
However, could you explain the graphics modes a bit? The Frogger is certainly interesting, but how does it actually compare to the 5200 hi-res mode? Choplifter, Microgammon SB, and Mini-Golf were all very detailed vector art. (They were also ported from the Apple II, so it's no wonder they all used this mode.) Can the 7800 do the same thing?
A 160x200x4-color bitmap screen requires 8K of RAM. This is not a problem on a machine with 16K, but doesn't work on a machine with 4K. There would be ways of doing a game like Missile Command on the 7800 even without memory for a full-screen bitmap, but it would be--to put it mildly--"interesting".Score one for the 5200! I knew that 16K was useful for something.
To be sure, many games can be implemented in a variety of ways besides a full-screen bitmap, but if a game was originally written for the Apple II, it's much easier to port it by using a full-screen bitmap on the target system than by using sprites, display lists, etc.Indeed. Choplifter for the 7800, for example, eschewed the vector mode in favor of traditional bitmaps. That made it not quite like the Apple II version, and not quite like the Sega version. Sadly, it seems to be generally hated for that.
Personally, I find it to be a lot of fun, but the gameplay is a bit different.
-
Where are you getting 256 bytes from? A SuperCharger game has 6K of RAM/ROM (plus the 128 bytes of system RAM). Or are you thinking of the Atari Super Chip which had 128 bytes of RAM mapped to the ROM space.Yes, thank you. Superchip, not Supercharger. My bad.
True, although the 7800 can change resolutions (via a DLI) on different parts of the screen. It is also possible to change between color modes on a per-sprite basis.Here's an interesting question. I got the impression that games like Chopper Command (original Apple II port, not the Sega one), MiniGolf, and Backgammon were only available on the 5200 because the 5200 was better able to produce hi-res vector-like graphics. Is that a correct supposition, or is it that no one ever bothered writing a hi-res game for the 7800?
-
Antic is an intelligent DMA device and it follows a simple program called a Display List to generate the screen but when it needs a byte from RAM it asserts the HALT line to the 6502, does a read (or many), then releases the 6502. A text mode screen can cause a 30% speed penalty on the CPU.*jaw drops*
But that defeats the entire point of a DMA transfer! It might as well use the 6502 to do the dirty work if it's going to halt it!
Was this some sort of misplaced attempt at multi-processor synchronization, or was there some sort of technical reason introduced that they didn't take the time to iron out?
-
This was more or less my point. Technologically, the two systems were fairly well matched, with each one having particular advantages over the other.
The most extreme discussion was this one, though I got started on trying to find the answer based on several offhand comments. (Like the one you just made.) Some of those comments suggest that the 5200 is superior, and some of them (again, like the one you just made) suggest that the 7800 is superior. My final take is that they're simply the flip-side of the same coin.
Now that's an interesting comparison, isn't it? The 7800 had better sprite capabilities and pastel colors, but the Nintendo creamed it on better sound support, tiling support, and more "earthy" colors. The earthy colors were often "ugly", but were put to good use by Japanese artists. Correct me if I'm wrong, but games usually didn't allocate artists to work on games prior to the Nintendo. Pretty much all the artwork was worked out by the programmer of the game, sometimes with a bit of consulting with an artist.
I've spent some time considering this, and I've come to the conclusion that had the 7800 been released in 1984, it still would have needed a follow-up console to properly compete with the Nintendo in later years. Of course, by then the system would have been 2-3 years old, and would still have a couple of years of breathing space before Nintendo really grabbed hold of the market.
Really? My understanding was somewhat different. As I understood it, the ANTIC ran separately from the 6502, and processed the display lists as a full microprocessor instruction set using DMA transfers from RAM. The ANTIC microprocessor then drove the GTIA. The only use of the 6502 for graphics should have been the creation of display lists.
Correct. Cartridge ROM limits don't really mean anything as you can always build a more sophisticated cartridge with a larger bankswitching scheme. (Just don't expect programmers to like the pain you're putting them through.
) The 5200 had 16K of internal RAM while the 7800 had only 4K. While 4K wasn't quite as limiting as the 128 bytes of the 2600 (256 if you used a Supercharger), it still wasn't exactly a "lot" of RAM to do very complex games in.
-
Poking around through the forums, it's easy to see that the 7800 and 5200 camps are divided on which system is technically superior. I've taken a bit of time to investigate each one, and I've come to the conclusion that they're effectively equals.
Both systems use the DLL scheme for graphics. Both systems run on the same processor at the same clock rate. Both systems can use POKEY for sound (though the 7800 was severely limited in this area). Both systems have a variety of arcade ports.
If anything, I'd give a slight nod to the 5200. It has more memory, a separate bus and processor for handling the graphics, and has many more control options. (Idiot analog joystick aside.) The 7800, OTOH, seems to be able to display more colors per scan-line, and can theoretically handle more sprites. (Though the lack of a separate bus really hurts here.)
When it comes down to it, I'd have to say that the systems end up being defined by their games. The 5200 had a very nice selection of arcade quality games. Its Centipede, for example, is unmatched by any contemporary system, and it had a few exclusive titles like Rescue on Fractalus. The 7800, OTOH, had fewer arcade ports, with many of them failing to take advantage of the system's capabilities. However, the 7800 did have many non-arcade games that (would have) allowed it to better challenge the contemporary game systems. Its ability to play 2600 games was also a plus.
So when it comes down to it, it strikes me that the 5200 was the "Neo Geo" of the 80's, while the 7800 was a "5200 'lite'" that was much better suited as the successor to the 2600. Considering that the 7800 was developed several years after the 5200, it should be no surprise that the components were finally inexpensive enough to make a console with the 5200's power at the 2600's price.
What are your thoughts?
-
Your point about Tekken was worded a bit clumsily. It would have been better to say that SNK had previously made the arcade hardware available to home players (Neo Geo), but that Tekken was the first arcade game to use existing home console hardware.
Also, I agree with a previous poster about Pole Position (there would have been no Virta' Racer, Cruisin' USA, or Ridge Racer without Pole Position!). and you forgot to mention TMNT. TMNT started the 4-6 player craze where each joystick represented a different player. This concept launched the X-Men, Simpsons, and many other arcade games for four or more players.
-
When I first played Centipede on my Flashback 2, I thought it was cute and ignored it. But it has some sort of strange appeal that has me coming back and back. Millipede doesn't grab my attention the same way. Maybe it's the ability to play for 15 minutes or more at a time. Maybe its the super-simple, yet challenging gameplay. Whatever it is, this classic (which I used to be only so-so on) has now permanently captured my attention. Maybe I should get a 5200 just to play it.
-
I already have a design.If you have a design, then you can use Pad2Pad to do runs for you. Their prices are often quite affordable, and they can scale to just about any size order you might need. Pad2Pad accepts standard Gerber 274X files in addition to their own proprietary format.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
5200 vs. 7800
in Atari 7800
Posted
To be clear, "framebuffer" can be correctly used to mean a RAM location holding screen data. More correctly, however, it refers to a hardware device that drives a monitor using pixel data from RAM. Such devices were once valued for their simplicity over their expense. As in:
"This Sun workstation is equipped with a simple framebuffer capable of driving the monitor at 800x600x256."
A RAM location that stores a screenful of data is properly referred to as a "backbuffer" or "frontbuffer'. As in:
"I wrote the screen to the backbuffer, then flipped it to be the frontbuffer during the Vertical Sync."
This is how I'm referring to it. The ANTIC is not a true framebuffer device. It actually has more in common with modern 3D Vector hardware in that it is a separate processor that queues up commands for just in time processing. Probably the biggest difference I see is that the ANTIC doesn't have its own bus. Performance-wise, you just can't do much worse than that.
Agreed.
The PC had an accelerated framebuffer because it was designed for "serious" home and business applications. The use of a framebuffer and character ROM greatly simplified the programming, making it much more useful as in business and BASIC programming. IBM made a half-hearted attempt to customize the PC for "family use" (i.e. games) with the PCjr, but the implementation sucked so bad that it was never taken seriously. (Ah, I still remember that stupid "grab the key" game that could be found by hitting the right function key when the built-in BASIC ROM started. And let's not forget how it would freeze if you hit a key sometime within the minute and a half while the memory was being checked! Stupid PCjr.)
It's worth noting, however, that the PC didn't have a true framebuffer device either. The framebuffer had a character blitter added to it that allowed the hardware to produce text. This stands in direct comparison to the Unix-machine framebuffers which drove everything through software blitting. The PC had different graphics modes similar to the ANTIC to help programs produce text screens. Many Unix machines, OTOH, had to draw everything in software.
The advantage to the full framebuffer was that there was no such thing as graphics modes. "Text Mode" was just an operating system driver that converted ASCII codes to bitmaps on the screen. You could call a graphics library at any time to produce pretty pictures right on top of the console. If X-Windows took over, all it did was disable to console driver and begin writing to the frontbuffer. (I'm somewhat simplifying this. X-Windows often switches a few registers to change the parameters of the video signal so that a higher resolution can be used.) That's why if you've ever seen a Sun machine, the console looks so damn beautiful. Pure white background with black anti-aliased text. *hugs Ultra 10 box*
So beautiful. 
*sniff*
Of course, for video games the differences don't really matter. Save for the fact that the PC is pain in the ass to code for.
Oh, I love it. "You're wrong because you're right! See?"
Let me ask you this: If you have a port that allows you to use the CPU to write a value to the monitor cable, is it a framebuffer device? No? What if you implement a program that produces a video signal with the correct timing. Is it a framebuffer then?
Sort of. Your program is emulating (or simulating if you prefer) the actions of a common piece of hardware. But it wasn't designed to perform this role, nor is it the default state of the hardware. That's why I refer to it as an "emulated framebuffer". And just like with the ANTIC, such a device would tie up the system's resources as the picture is being drawn.
No, the Atari can be programmed to do the same thing. That's software my friend, like it or not.
Ultimately you're wrong. There are frame buffers, then there are graphics accelerators, and then there are video overlay generators. A modern graphics card tends to incorporate all three. The frame buffer is the destination for the commands given to the graphics accelerator, which is overridden by the video overlay device to produce effects like a mouse cursor. In engineering these terms have very specific meanings. They used to have different meanings to consumers as well. Today they tend to be used interchangably outside of engineering, but we're all engineers here, right? Right?
*crickets chirp*
Hmm. From the Sun framebuffer FAQ:
<southern-lawyer>Your Honor, Ah rest mah case.</southern-lawyer>
(For what its worth, I also used to think that "framebuffer" was a loose term for "the thing that displays the graphics." It was a real eye opener to learn that specifying "framebuffer" meant I might be getting very different hardware than what I wanted.)