Whatever became of Turbo-816?

[JamesD]

If I recall correctly, the Antic/GTIA have their own internal clock speed on the chip. However, the read/writes can probably only be done at 1.79 MHZ. I am not sure if it is possible to write to these chips at higher speeds.

Nope, that's why I said isolate the two. The buffer keeps the chips from stealing more than 1 clock cycle for reads or writes on the fast buss but makes the buss timing look like 1.7MHz to the custom chips... *if* that doesn't cause problems anyway.

 

Of course another option is make ICs that are backward compatible with Antic/GTIA. Maybe have optional enhancements like increasing the HOZ resolution by a multiple for the current Antic Mode. Double the Vertical resolution by writing to the interlace lines. Already we have someone making VideoBoard XE for a new sprite layer. Aren't there 2 open memory locations in the Antic area? You have 2 more registers, along with the other 240 bytes past the Antic area. GTIA has 224 more bytes beyond its memory area. Extra registers can be added without loosing backward compatibility. Maybe combine the two ICs into one chip like Atari was proposing with the CGIA.

The entire machine could fit on an FPGA now.

 

My Ideal about increasing the HOZ res, would take like Antic Mode 2,3 4,5, 13, 14, and 15 which are 40 bytes wide. I would add a register in the Antic area, if you leave it at 0, those modes will stay the same. Set it to 1 to go to 64 bytes wide, 2 would be 2x res giving us 80 columns, a 3 would be 3x+ res to an even 128 bytes. Maybe go beyond that to 256 bytes wide. Going 128 bytes wide or more probably not be practical for 2 text modes, would useful for 4 and 16 color GTIA modes. I probably would have one of the bits in this register to toggle to one byte (8bits) per pixel/color clock (256 color mode!). I think you get the picture of where I am going with this. The color clocks will increase proportional to the resolution and the chip probably need to run at 50mhz.

I think the best thing would be to have the chips start up in compatibility mode and then a write to an unused register location switches them to native mode to access whatever you want. Instead of extending a whole bunch of old modes you would be better off having more usable bit mapped ones with alterable width, height and color dept attributes. Let those attributes be based on existing timing circuits the chip already needs. That would mean same width as an existing mode and double width. More than that and the FPGA gets too complex and it's too slow to push the graphics around anyway. I'd leave height to NTSC and PAL. Color depth... 16 color or 256 color. They use the same bytes per page but 256 at half the resolution. It keeps the timing circuits simple.

Add 256 color player/missiles in any mode (making it easier to hack existing games for more colors) and a 4096 color palette to chose from.

Add a blitter to write from anywhere in memory to the screen, to/from player/missile buffers or to scroll the screen around.

But that's just off the top of my head.

 

Once you start running at a decent MHz and have a certain amount of RAM a lot of the modes that once made sense just aren't practical anymore and they are more difficult to program for than standard bitmapped graphics.

I would add another Pokey but I'd also add an 8 bit D/A converter or two to simplify output of real sounds. Possibly DMA driven or with a programmable timer so it's easy to output to them at regular intervals.

[mos6507]

The entire machine could fit on an FPGA now.

 

Easier said than done. Look at the C=1. Nobody's made an Atari core for it yet.

 

Once you start running at a decent MHz and have a certain amount of RAM a lot of the modes that once made sense just aren't practical anymore and they are more difficult to program for than standard bitmapped graphics.

I would add another Pokey but I'd also add an 8 bit D/A converter or two to simplify output of real sounds. Possibly DMA driven or with a programmable timer so it's easy to output to them at regular intervals.

 

The challenge in a project like this is deciding what not to do. Otherwise before you know it you've replaced everything from the A8 to the point where the A8 portion is nothing but a dongle sitting side by side with a whole new platform.

[potatohead]

Yep.

 

It's the being hard to program for part that gives the experience. If one is gonna just do bit mapped graphics, who really cares? That's the cell phone market.

 

Doing new "Atari" games, really means doing them on an "Atari". Look again at how well the original chips have been extended. A few simple changes that open up that functionality are the key, not just a toggle into some rather ordinary environment.

[peteym5]

The challenge in a project like this is deciding what not to do. Otherwise before you know it you've replaced everything from the A8 to the point where the A8 portion is nothing but a dongle sitting side by side with a whole new platform.

 

With the Graphics, I probably will just do a few extra things like options to double or tripple hoz resolution, but stay with the 256 Color Atari Palette. I would not suddenly give it VGA or XGA resolution or 3D acceleration. Maybe include the VideoBoard XE style sprites; Blitter Sprites. I

would also do the Duel Pokey with an additional sound chip emulation, but would not go overboard and give it a sound blaster like sounds. I would keep Output to a standard NTSC or Pal TV, but also include S-Video and RPG output, even output to an HDTV.

[JamesD]

I don't mean to be argumentative but do you guys really think that's what Atari would have done if *they* had updated the chipset?

Lets see... what was in development... an advanced sound chip that they even had singing (supposedly) and it had how many voices?

And what did the most famous Atari engineer go on do develop? The Amiga.

 

You don't hesitate to talk about adding on a graphics board that would cost more and be more complex than what I suggested.

You also praise the C64 Joystick and it adds a bitmapped 256 color mode with a blitter.

Yet someone suggests that be done on the Atari and it's blasphemy.

 

The reason for the character based Atari graphics modes and ability to change the color palette on the fly with a coprocessor in the first place was the price of RAM.

Anything that reduced RAM requirements but improved the graphics meant a lower price for the capability.

Raster based arcade machines with simple blitters already existed when the Atari 8 bit chipset was created so it was definitely possible at the time and some of the Atari engineers that designed the 8 bits probably designed some of those arcade machines.

 

Say whatever you want, what you propose is not what Atari would have done.

Would that have enhanced some existing modes? Probably. The already demonstrated that with the later models.

But double the resolution of a character based graphics mode?

You run out of characters the generator can use to put different things on the screen in a hurry. Twice the horizontal and twice the vertical takes 4 times the number of characters on the display. At some point the savings once created by the character modes actually works against you.

 

Is it good experience to have to work within such a restrictive environment?

Certainly. You learn a lot more when you are under tight restrictions because you can't get away with as much and you have to do whatever you can to get more out of the machine.

 

But does that mean it wouldn't be an Atari if it adds bitmapped graphics modes like I proposed?

The coprocessor could still change the palette on the fly, turning a 16 color mode into a hundreds of colors mode.

Player missiles would still exist but with more colors and some hardware to move the data around quicker without bogging down the CPU.

The sound chip would just be upgraded to two pokeys (already been done) but with stereo DAC so sound samples are easy to play. Common technology from the time and a D/A converter could even be implemented with a bunch of resistors.

A timer or DMA to drive them without eating cpu time?

DMA was the thing on the Amiga and boy have I heard a lot of people here say it was the real replacement for the Atari 8 bits rather than the ST.

 

I guess I just don't get it.

[DamageX]

I take issue with the statement that the 68k is faster than the '816 at a similar clock. For particular tasks that is true, but in general it is somewhat like the Z80 vs. 6502 comparison. Since the 65xx chips are running faster internally they end up requiring the same speed memory on the outside anyway and get roughly the same amount of work done as these other chips do when running at 2x the clock. If you're running an '816 at 14+MHz then SIMMs or DIMMs will slow you down (and complicate the board), you need SRAM for the low latency.

 

As for the graphics modes, limitted RAM size was definitely a consideration back in the day but IMO memory bandwidth was the larger issue. I feel that the Japanese home computers, game consoles, and arcade system boards were miles ahead due to their better handling of this. Whereas Atari and Commodore always had the CPU and graphics sharing the same memory bus, none of their Japanese competitors did. Plus they sometimes used SRAM instead of DRAM for more speed. So those systems had more memory bandwidth, and I would argue that they made better use of it with character-based graphics modes, multiple color palettes, and large numbers of sprites.

 

The TMS 9918A looks like it could be the beginning of this kind of design. Perhaps the VIC-II borrows some ideas from the TI chip, and the NES clearly does, but Atari apparently was not paying attention. The 7800 had multiple color palettes at least, but no more speed, and setting up the display lists taxed the CPU. Around this time in the arcades, were games like Star Force that already had graphics hardware with similar features to the Sega Genesis. Those game designers already knew what they wanted, it was only a matter of time before the features could be had at lower cost for a home system.

 

Then with the Amiga, we have bitplanes, which are again a means of reducing memory usage rather than getting the most out of limtted bandwidth. The blitter is not fast enough to keep up the full 50 or 60fps when doing screen updates the easy (double buffered) way, and there are only 8 sprites. Plus the blitter became obsolete when the A3000 came out since the CPU was faster and had a wider bus to chip RAM. I think the Amiga would have been better had it kept the Atari's display list with a choice of bitmap and character based modes, not only for games but also for computer apps. Look at the 80x25 color text mode on PCs, the Amiga could accomplish the same thing, but only by using a 640x200 4 bitplane screen that used more memory and slowed the system way down.

 

Since the Atari already has a choice of 14 ANTIC modes, the obvious way to upgrade it is to simply add some more modes, with 2,3,4x the number of bytes per line. With character based modes, the way to make use of the extra bits is by allowing for more characters and for multiple color palettes. And with bitmapped modes you can try some stuff like YUV 4:2:2. Or mix two resolutions by having 8 bpp, if the top bit is set then you get one low res pixel with 128 possible colors, if the top bit is clear you get two high res pixels with 8 possible colors.

 

I wouldn't bother adding a blitter, instead I might add more sprites, or keeping with the Atari spirit, add more flexibility to ANTIC kind of like the 7800's display lists or the Jaguar's object processor. I think that a graphics processor that simply deals with a list of bitmapped rectangles is one really good idea that nobody implemented in the 80's. Imagine if in your PC the video card rendered all the separate windows in your GUI from separate framebuffers in video RAM, instead of the OS itself having to do all the clipping and redrawing inside one framebuffer. Well, now it is a reality... using modern 3D accelerated video cards. But someone should have done it 20 years ago

Edited October 3, 2007 by DamageX

[Richard H.]

It's likely to be an AtariVOX thing

Please explain ?

[danwinslow]

I'd like a 816 board that plugged into the original 6502 pins, had a faster clock, and had it's own memory that could be bankswitched in to the regular memory ( for compatibility ), as well as an 816 extended mode for new code. A videoboard output ( say 320x200 256 colors ) that could be overlaid onto the Antic output would be cool as well I guess...and maybe a new sound chip that could be merged with the A8 sound. As would USB and IDE connectors...but at some point I guess it would really stop being an A8.

 

Even so, it would be kind of fun to throw compatibility to the wind and build a 'next-gen' machine using all the parts that would have been available during the late 80's. Upgrade and extend the OS but keep the basic look and feel, and the indirect organization.

[potatohead]

It's likely to be an AtariVOX thing

Please explain ?

 

I'm not talking down the excellent AtariVOX, nor Glenn's up and coming Chimera. It's just that only a few people have these devices. They are getting written to, as most of the right people have them, and that's cool. IMHO, both are excellent add-ons, but they still see limited distiribution. The community surrounding these things is fairly tight too boot. It's all working. They fit onto and work with nearly all the consoles they are targeted for.

 

There is more diversity in the 8 bit arena. No one size fits all. So the success of these two really will be much more difficult to achieve. I was really after highlighting that difference.

 

 

That came off weird, sorry!

[mos6507]

I don't mean to be argumentative but do you guys really think that's what Atari would have done if *they* had updated the chipset?

Lets see... what was in development... an advanced sound chip that they even had singing (supposedly) and it had how many voices?

And what did the most famous Atari engineer go on do develop? The Amiga.

 

The big difference: the Amiga is not backwards compatible with the A8.

 

Extending the A8 means just that, extending. Not making a whole new platform. That means you have to elegantly add in stuff without breaking the OS or old software. Atari themselves did this once with the move from CTIA to GTIA. You can stack POKEYs and PIA chips and other things along those lines. There are still holes in the memory map to do some things. That's where I would draw the line. Otherwise you have a 7800-like system that is largely two systems under one case with a few shared components.

[mos6507]

Then with the Amiga, we have bitplanes, which are again a means of reducing memory usage rather than getting the most out of limtted bandwidth. The blitter is not fast enough to keep up the full 50 or 60fps when doing screen updates the easy (double buffered) way, and there are only 8 sprites. Plus the blitter became obsolete when the A3000 came out since the CPU was faster and had a wider bus to chip RAM. I think the Amiga would have been better had it kept the Atari's display list with a choice of bitmap and character based modes, not only for games but also for computer apps. Look at the 80x25 color text mode on PCs, the Amiga could accomplish the same thing, but only by using a 640x200 4 bitplane screen that used more memory and slowed the system way down.

 

Not having a hw text mode was the biggest omission from the Amiga chipset for sure.

[peteym5]

I do agree that the reason of the Antic Text Mode design was due to memory restrictions on period specific DRAM chips. If you doubled the text width, you will be using 80 bytes per line x 25 lines and now need 2k of ram just for the text. If you quad tripled the 40 byte bitmapped modes, you will need 160 bytes/line and now need 32k for a full screen. Probably be wise at some point to have 'Extended Antic 'use extended memory area like the Freddie/130XE did. However we are proposing to do this on a 65816 system with 16megs of ram.

 

I just thought of this also, what could we do with those other Antic bitmap modes that only did 40 or 80 pixels across if we incorporate something that multiplies the byte per Antic Line. My thoughts would be to leave these modes as is, just affect modes that are 40 bytes wides. For the 20 column 4 color text mode, just have that multiply up to 4x, 80 columns 4 color text mode. This does bring up another point, would be be wise to add a character color map?

 

Having multicolor player/missile graphics would be a good ideal. I probably duplicate the GTIA area 4 or 8 times to have multiple sets of player/missile graphics.

 

My question is could you get a FPGA chip to just take over the Antic/GTIA/Pokey with a separate 65816 and memory all on one board? That is also including the Extended functions we have been proposing.

Edited October 3, 2007 by peteym5

[+warerat]

The entire machine could fit on an FPGA now.

 

Easier said than done. Look at the C=1. Nobody's made an Atari core for it yet.

 

@mos6507: Amen.

 

I'm no VHDL expert, but I did a one time try coding some of the guts of ANTIC a while back based on the internal architecture depicted in the patent, but gave up on it after a few registers. I had a decoder for a few memory locations and the 1K/4K address counters with address preloads counting up and working in a simulator, but far from anything workable, or more importantly, exactly matching the cycle timing of the real IC in a real system.

 

Someone here once stated they had a rudimentary ANTIC working (I think just mode 2) just from looking at the behavior on a logic analyzer. I'd love to see a picture of that setup and what timings he looked at.

 

Like you said, easier said than done--not impossible, but still a formidable task.

[peteym5]

@mos6507: Amen.

 

I'm no VHDL expert, but I did a one time try coding some of the guts of ANTIC a while back based on the internal architecture depicted in the patent, but gave up on it after a few registers. I had a decoder for a few memory locations and the 1K/4K address counters with address preloads counting up and working in a simulator, but far from anything workable, or more importantly, exactly matching the cycle timing of the real IC in a real system.

 

Someone here once stated they had a rudimentary ANTIC working (I think just mode 2) just from looking at the behavior on a logic analyzer. I'd love to see a picture of that setup and what timings he looked at.

 

Like you said, easier said than done--not impossible, but still a formidable task.

 

Duplicating the original Antic/GTIA would be the first step and the most crucial step before adding more registers and functions. I know it is not going to be easy. Now with the timing issue, could something be build that could go into system with a faster cpu and bus speed. Remember a few do say that is why the original Antic cannot be put into a faster system.

[DamageX]

If you doubled the text width, you will be using 80 bytes per line x 25 lines and now need 2k of ram just for the text.

But 2KB was not a huge deal. What you also need is faster RAM chips, or multiple banks with interleaved reads. And perhaps even more importantly, you need a better display than a TV.

[potatohead]

Is that really true today?

 

Most TV's do really well, compared to back then.

[peteym5]

If you doubled the text width, you will be using 80 bytes per line x 25 lines and now need 2k of ram just for the text.

But 2KB was not a huge deal. What you also need is faster RAM chips, or multiple banks with interleaved reads. And perhaps even more importantly, you need a better display than a TV.

Using 2K or 4K for text mapped screens is not a huge deal, even back in the 80s. The original Bitmap screens used just under 8k of ram. If you wanted to use 320x200x256color, you will need to use 64k for the display. I am not sure I would do these higher bitmap modes from an Antic style display list because of limitations on the original chip. I know some would like to combine a part hardware text map and bitmap display.

 

Is that really true today?

 

Most TV's do really well, compared to back then.

 

The Atari 800 and XE models can be modified to output to S-Video with a minor upgrade or just by splicing an s-video cable with 2 female end for chroma/luma. The XL can also with an internal modification. That makes 80 columns somwhat readable. Some have RGB ports also. I would consider outputting to s-video, RGB, or whatever else HDTVs takes. I would have it still use composite, but not recommend 80 column display. My wish is higher color bitmap modes, 16 and 256 colors in 320x200 which can be outputted to a tv without any problems.

 

If someone were to put our ideals forward and wanted to make a new FPGA graphics chip. They would have to look at the limitations of the ANTIC/GTIA chipset. The other thing that has to be considered is how many people will actually buy into this new technology.

Edited October 4, 2007 by peteym5

[JamesD]

I will agree that it is definitely important not to do something that is overkill but what that seems to be a matter of opinion which differs from one person to the next.

 

320x200x256 colors doesn't just take 64K, it also takes a lot more memory bandwidth and slows down the CPU more. That negates much of your performance increase. On the other hand, if you have a 24 bit address space, 64k is a drop in the bucket. It's even less important if you have a blitter that can write across different 64K memory blocks without code theatrics. The 65816 may be able to access 24 bits of address space but that doesn't mean that doing so would be as easy as on a 68000. A quick look at the 65816 should tell you that it's enhancements over the 6502 are very usefull but modest at best.

3D graphics would be fastest on a 256x256(and under)x256 color bitmapped screen. If you use a 256 pixel wide drawing area on a 320 pixel wide screen it's about the same. One of the reasons there were so many 3D games for the Sinclair Spectrum was the screen layout.

 

I don't think adding on to the existing chipset is going to be "elegant" no matter what you do. Trying to use words to make one approach sound better than another doesn't mean it is. We could elegantly add on bitmapped modes or elegantly extend existing modes or elegantly do both. However, if you want to use the word elegant... from a programming standpoint bitmapped graphics is certainly more elegant to code for. There is certainly less hardware needed to implement bitmapped graphics since you bypass the character generator. For 256 color modes you just load from memory and dump the output to the DAC. For 16 colors you need to do more work so it might be better to skip that unless you want to save memory.

 

A blitter... the Amiga blitter was slower than the later CPU upgrades because it was clocked at the original ~8MHz.

A blitter clocked at the same speed as the CPU would be faster than the CPU. It could also convert from bitmapped graphics to a character display eliminating the need for multiple routines needed just to write each game graphic to the screen.

From the Pro Eye Needed - Gremlins thread:

Of course, unrolling a sprite will take something like 4-5k per unique shape (I think I was calculating for 12 bytes tall, not 16) which may be too much memory. Also, filling in the playerdata from the background is expensive, and not accounted for here.

Even with a 24 bit address space 4-5k per shape for the unrolled loops is pretty costly. Now add the possibility of higher resolution plus greater color depth and that gets even worse because you are processing more data for the same sized object. With a faster clocked cpu you may not need to unroll the loops but the blitter would still be faster and the code smaller. Even a blitter that works on existing hardware would certainly let programmers squeeze more in the existing machine. It also doesn't require recreating the existing hardware. One of the easier hardware mods by far.

Programmers could still push the hardware to the limit in other ways. Just look at the Amiga, it has better hardware but that didn't stop programmers from pushing the hardware to the limit. All you are doing is changing what the limits are.

 

Extending the color palette to 4096 colors would have a significant impact on the hardware unless it was implemented just by letting you set the values for the existing 256 color palette. Squeezing it in is another matter. I think a DMA transfer from a block of memory would work best. It could use a palette color start number end number and 24 bit address.

 

If there are at least two locations remaining unused on the existing hardware, one could be the index to the register you want to read/write and the other could be where you read/write from/to it. This is how several of the sound chips from that time were implemented. If you had 4 open spaces you could do this twice adding 512 new registers.

[mos6507]

I don't think adding on to the existing chipset is going to be "elegant" no matter what you do.

 

I think the moral of the story here is that a computer architecture must be balanced. That's what I didn't particular like about the VideoBoard XE. It focused on enhancing the video portion of the architecture but not addressing the core CPU speed and memory issues of the A8. So you run into bottlenecks which would prevent you from really getting the most out of the new hardware. The new hardware should enhance the original rather than systematically replace it.

[JamesD]

A couple other possibilities the blitter may offer are running the buss at double speed and burst mode RAM.

The CPU is only available to 16MHz but the blitter is just simple DMA and bit masking which could easily run at double speed if not more.

Add to that the use of burst mode RAM which lets you load/save more bytes at a time and it's really fast. The CPU couldn't use burst mode but the blitter could and would be completely done faster than the equivalent CPU routine could write 4 bytes.

[peteym5]

I think the moral of the story here is that a computer architecture must be balanced. That's what I didn't particular like about the VideoBoard XE. It focused on enhancing the video portion of the architecture but not addressing the core CPU speed and memory issues of the A8. So you run into bottlenecks which would prevent you from really getting the most out of the new hardware. The new hardware should enhance the original rather than systematically replace it.

 

VideoBoard XE had its own memory and I think it runs internally at 7mhz, independent from the main CPU. The articles I read about it, it did not draw much main CPU usage. However I do agree you probably will need more than original 6502 CPU at 1.79MHZ. Also would still be overlaying the original Antic/GTIA screen and many did want to know if it could do 80 column or do more with the bitmapped background. One thing it is proposing to add is a color map for the background down to 4x4 pixels. Personally I would like to see more resolution/color depth with Antic Modes with VideoBoard XE. Your Sprites are going to be 256 colors at 320x200 res, and your background would be like 160x200 res x 4 colors, (more with VBXE color map or DLIs). I do believe you can set the VBXE sprites to 2x width to have the same res. Its overlaying Amiga/Sega Genesis/Super Nintendo style sprites over an Atari 8-bit background. I think to make anything really great on a system with VideoBoard XE would require a 65816.

 

I would like to add, you can use VideoBoard XE onto of a Antic/GTIA background and 6502cpu. Create some decent background scenery with the sprites. Just be aware the maximum Antic resolution is not going to change. You will have a color map and change colors in different regions.

Edited October 4, 2007 by peteym5

[+bob1200xl]

If you doubled the text width, you will be using 80 bytes per line x 25 lines and now need 2k of ram just for the text.

But 2KB was not a huge deal. What you also need is faster RAM chips, or multiple banks with interleaved reads. And perhaps even more importantly, you need a better display than a TV.

Using 2K or 4K for text mapped screens is not a huge deal, even back in the 80s. The original Bitmap screens used just under 8k of ram. If you wanted to use 320x200x256color, you will need to use 64k for the display. I am not sure I would do these higher bitmap modes from an Antic style display list because of limitations on the original chip. I know some would like to combine a part hardware text map and bitmap display.

 

Is that really true today?

 

Most TV's do really well, compared to back then.

 

The Atari 800 and XE models can be modified to output to S-Video with a minor upgrade or just by splicing an s-video cable with 2 female end for chroma/luma. The XL can also with an internal modification. That makes 80 columns somwhat readable. Some have RGB ports also. I would consider outputting to s-video, RGB, or whatever else HDTVs takes. I would have it still use composite, but not recommend 80 column display. My wish is higher color bitmap modes, 16 and 256 colors in 320x200 which can be outputted to a tv without any problems.

 

If someone were to put our ideals forward and wanted to make a new FPGA graphics chip. They would have to look at the limitations of the ANTIC/GTIA chipset. The other thing that has to be considered is how many people will actually buy into this new technology.

 

 

I was trying the Component inputs on my CRT televisions and will agree with you on the 80 columns - not really good enough. But, on my HD LCD set, even an un-optimized 8-bit looks really good. Too good, actually. You can see the color clocks, the refresh, and all the other garbage that the SD sets don't pass. The point is though, the characters are razor sharp. (they look like an emulator screen) These TVs will make great 80 column displays.

 

Bob

[DamageX]

I was trying the Component inputs on my CRT televisions and will agree with you on the 80 columns - not really good enough. But, on my HD LCD set, even an un-optimized 8-bit looks really good.

Yes, my comment about the unsuitability of TVs was meant to be in the context of what Atari did or might have done back in the day. I'm sure a lot of TVs are up to the task now. Plus if someone is going to implement A8 hardware in an FPGA then they can put a scan-doubler in there while they're at it...

Its overlaying Amiga/Sega Genesis/Super Nintendo style sprites over an Atari 8-bit background. I think to make anything really great on a system with VideoBoard XE would require a 65816.

Sprites on the Amiga are sort of like players on the Atari, except more numerous (eight), twice as wide, and with three colors each. Contrast this with those Japanese systems, where sprites have their screen position, size, and graphics address specified in an attributes table with 64 or 80 records.

 

One thing that has to be considered is the genre of game that you want to run on the hardware. While it's nice to have a balanced set of capabilities as mos6507 mentioned, a slow CPU with nice gfx hardware could do a nice puzzle game. Likewise a fast CPU with unimpressive gfx could do a fun action game.

 

I'm biased toward shoot'em ups due to the amount of time I have spent playing them and also programming. That's why I like character mapped backgrounds and hardware accelerated sprites. So when Amiga fans wax nostalgic about old games I always think "...but you guys don't have Chourensha 68K or even Zanac."

Edited October 5, 2007 by DamageX

[mos6507]

I'm biased toward shoot'em ups due to the amount of time I have spent playing them and also programming. That's why I like character mapped backgrounds and hardware accelerated sprites. So when Amiga fans wax nostalgic about old games I always think "...but you guys don't have Chourensha 68K or even Zanac."

 

The Amiga could do action gaming pretty well. You just needed an accelerated machine and a good coder. My favorite Amiga game was Deluxe Galaga, which got ported to the PC as Warblade. Deluxe Galaga was really frenetic on AGA Amigas, bitplanes be damned.

 

http://www.mobygames.com/game/amiga/deluxe...-2x/screenshots

[peteym5]

Yes, my comment about the unsuitability of TVs was meant to be in the context of what Atari did or might have done back in the day. I'm sure a lot of TVs are up to the task now. Plus if someone is going to implement A8 hardware in an FPGA then they can put a scan-doubler in there while they're at it...

That was one of my suggestions, have it hit the between interlace lines to double the vertical resolution. Only problem is how would it handle DLIs at that point.

One thing that has to be considered is the genre of game that you want to run on the hardware. While it's nice to have a balanced set of capabilities as mos6507 mentioned, a slow CPU with nice gfx hardware could do a nice puzzle game. Likewise a fast CPU with unimpressive gfx could do a fun action game.

 

I'm biased toward shoot'em ups due to the amount of time I have spent playing them and also programming. That's why I like character mapped backgrounds and hardware accelerated sprites. So when Amiga fans wax nostalgic about old games I always think "...but you guys don't have Chourensha 68K or even Zanac."

 

The Amiga could do action gaming pretty well. You just needed an accelerated machine and a good coder. My favorite Amiga game was Deluxe Galaga, which got ported to the PC as Warblade. Deluxe Galaga was really frenetic on AGA Amigas, bitplanes be damned.

 

Last month I posted a message asking people What would they do with a Videoboard XE or What they want to see done. Someone wanted to know if it can play AVI style Video. I recall one wanted creation of First Person Shooters (3D) like Wolfenstein 3D or Doom. I know you can probably do some primitive 3D first person views on the Atari 8-bit, but to make something look somewhat decent, you really need to use a 65816 at 16 mhz and more memory. I played around with doing a first person type game with a character mapped screen many years back in Turbo

Basic.

 

I personally like 2D side-scrollers like Super Mario Brothers, MegaMan, Sonic the Hedgehog, and even BoulderDash. These done take a whole lot of CPU power to scroll. With 16bit CPU and extended graphics, you can make an awesome side-scroller. Doing a multiplane Genesis/Amiga screen would be a challenge but not impossible.

 

I also like those Vertical scrolling shooters like Galaga, and can easily do some nice similar type games with just Videoboard XE or with some of the extensions we proposed.

Edited October 5, 2007 by peteym5