JamesD

Expensive to produce, tape drives, lack of 3rd party support, too much competition, daisy wheel printer, size, bugs and poor timing. The first ones supposedly erased a spot on the tape when you turned it on or off. Something like that anyway. A friend of mine had one and he had to have one of the tapes replaced and the unit serviced to fix it and he had barely gotten the thing.

I went to my storage unit a few weeks back and the owner was clearing out the unit next to mine for lack of payment. Most of the stuff was total crap that nobody would want but I noticed a couple things and commented they might be worth something on ebay. He said they were just going to the dump and I could have whatever I wanted. He let me have a dual drive Apple IIe system (I passed on the monitor... I have at least 6 now), a Nintendo with no PS or controllers and 1 game Mario/Duckhunt was in the system.

I thought it did but I didn't want to say unless I was sure. It, the SID and memory size are why I voted for the C64 over the Atari. A faster clock would have been nice though. I also think the Atari is closer to the first type. You even have to move the sprite data up and down in the Player Missile buffer to move it up and down on the screen instead of just changing the Y co-ordinate to place the sprited at. A lot of vertical sprite action or animation on screen at once can take thousands of clock cycles and the extra CPU speed is definately needed. I'd say if there was a limitation it was imagined or on the programmer's part. The only way sprites should be slow is if the game logic is making a huge number of calculations... and frankly... the ONLY thing I've seen needing that number of calculations is 3D and a lot of that is in drawing and has nothing to do with sprites.

Well, I'm not a C64 guru so I don't know exactly what was up... however, there are a couple ways animated sprites are implemented in hardware and how you would have to update them depends on the hardware. 1. The sprite hardware uses a fixed buffer and you copy each sprite's new frame into the buffer to display the new image. 2. The sprite's hardware uses a pointer to the buffer and you just change the pointer to the new buffer to display the new image. On the first type of sprite hardware a space game with only a small amount of sprite animation could be absurdly fast, but with heavily animated characters it could slow considerably. On the second type it doesn't matter, it's always fast. Just remember, this also depends on what color mode is used too. The more colors in the sprites, the more data you have to move if you change them on type 1. Now, whenever you aren't doing much sprite animation either one can be very fast but as soon as you have to move a block of data... CPU speed or a more efficient algorythm is king. If only part of the sprite changes you could update just that part of the sprite by using a software state machine. More tests but lots less load, save, increment and loop to do to update the sprite. But I think you'll find a lot of programmers would just update the entire sprite because it's easier to do.

To give you an idea of what is possible on a Plus/4: Xe03

If there was anything lacking on the C64 color wise I would say it was the programmer's fault. The problem with the C64 goes back to clock speed. Even if DRAM refresh, screen refresh, etc... take 30% of the Atari CPU clocks that still leaves more clock cycles for the Atari than the C64 has to begin with! The C64 sprites steal some clock cycles to generate but there is certainly nothing slow about them. You can move them faster than a person can see them if you want. I'd guess something else in the games were slowing them down.

I think building a character and spending attributes is pretty much standard these days. Just building a character could take a big chunk of code if you allowed the flexibility of modern games.

Any updates?

To some extent you are right. Comparing a 3D engine to a game is like comparing apples to oranges. The game they built using that 3D engine handled more objects on screen at a time and animated them faster. It may not have been doing as much as Elite... but on the other hand, Elite may not be doing anything to justify a slower speed other than have a slower built in 3D engine. The point was that people are trying to say a machine is faster because it's 3D is faster than another machine's. On a 6502 vs 6502 comparison with most of the same code that might work but Z80 vs 6502 is another matter. You don't know how optimal the routines are on both systems. Even different screen resolutions or number of colors impact the speed of calculations and one machine may be doing more than another. And as you said, you can precalculate data and that can make a 3D animation faster. Unless you know the two machines are doing exactly the same amount of work you can't say one is faster than the other. The Speccy could be slower at doing the calculations but faster at displaying because of the 1 bit per pixel display. It may give the machine an advantage but then the other machine could just as easily use different colors for different 3D objects on the screen at the same time and that would be much more work on the speccy not to mention the color clashes that would be inevitable. The best way to compare machines speed wise would be to create a standard set of tests for doing different things within certain parameters.

First of all that's opinion and video generated interrupts aren't unique to the Atari. The coprocessor was but the things it did could be duplicated just with the CPU on other machines. Interrupt driven programming is pretty common in game development on all machines. Even on the C64. Less overall effect on the game? You mean I wouldn't have to program around hardware limitations?

It's an 8/16 bit CPU. Same as the 6809, which could easily do the same thing. IMHO, the rule was always about the data bus and the operators. The 6502 has nothing really in the way of 16 bit operators. Indexing is a biggie for me. If the chip has 16 bit indexes, then it's a 16 bit chip on the inside. The Z80 was always called an 8 bit CPU in spite of having 16 bit index registers. The size of the index registers is strictly so you can index the entire 16 bit address space. The 8/16 bit designation of the 6809 is marketing on Motorola's part. It's register capabilities were similar to older 8 bits. It's extensive addressing modes, instruction set and fast execution speed are what set it apart.

An excellent point. IF you have a master than knows all the tricks for one CPU / machine do one port and someone that doesn't know them all for another CPU / machine for another port then using the game to compare the two machines is meaningless. It's a 16 bit machine too, although I suppose you could debate that when it runs 6502 compatible mode. It has an 8 bit data buss and to the best of my knowlege uses 8 bit opcodes. The Z80 can represent 16 bit numbers in the same way as the 65816 so then what is it?

It's totally vague to make statements like that. You can speed up almost everything by adding precomputed data. By that the 3D engine will consume more space. So while speeding the 3D up, you deduct memory for the rest of the game at the same time. If you make a 3D engine that is twice as fast while at the same time being twice as big, you just might not be able to fit the rest of the game into 64K. Also in a real game your "3D-Time" is shared with "AI-Time" and whatnot, which an engine demo won't deal with. So when someone writes a 3D-engine that can rotate the Cobra twice as fast or even with filled polygons or some other gimmick, that says nothing regarding wether "Elite could've been like that". Sure, 1000s of programming tricks have been discovered 1985, but until someone delivers a significantly improved Elite with the rest of the game completely intact, that discussion is pure academic. Making claims the 3D library is bogus without proof isn't any better. It's a generic 3D library and the source is on the web if you want to prove it's crap. For that matter the original Elite source for the Atom is on the web.

First of all, Isometric games just have blocks of graphics that are drawn back to front, bottom to top. All it does is sort the data and draw. What machine is faster is very dependant on how you implement this. If you use a slower sort, less intelligent screen update or blit routine then one machine will be faster than another just on that basis alone. The 6502 is tougher to sort on but it's faster at blitting hands down. However, if the blocks of graphics are designed to work within certain screen attributes of one machine it may not translate well to another machine. That can work in reverse. An isometric game designed from scratch for a machine that used 2 or 4 bits / pixel may not run as fast on the speccy because the graphics blocks aren't an even multiple of 8 pixels wide. Then it doesn't just copy to the screen it has to OR with what is already in a byte and that will vary as you go across the screen. This would bring the Speccy to a crawl while the other machine just blits. <edit> That should read "copies data" rather than "blits" because a blit can include masking and that wasn't what I was trying to say.

Is it really fairer? I thought the Speccys horizontal resolution is only 256 pixels vs. 320 on the C64. So while the Speccy can go with 8-Bit math, the C64 had to do a slightly more complex job, dealing with an additional 9th bit somehow. It's worse than that. The speccy uses 1 bit per pixel for the bitmap and then has a block of RAM for setting the color within a square on the screen. So, if you leave the color the same for an entire area and only update the pixel bits there's less to process than on a system with multiple bits / pixel. However, changing screen modes part way through the screen could counter that. On the other hand, computers that have user definable characters can show very complex images and move them by moving fewer bytes than on a machine with only bitmapped graphics. Each one of these machines has some feature that was used to it's advantage and it's why some games look better on one than another and it's not consistant which machine is best. No one machine was better for all games.

It's online but the benchmarks came from a different magazine that isn't available. The speed difference between the C64 and Atari based soley on clock speed is a little misleading due to differences in the two architectures. More clock cycles are stolen away from the Atari CPU by the rest of the hardware. But that doesn't mean the Atari isn't faster. Besides, it varies on both depending on mode, sprites, etc. Since I haven't benchmarked them myself I tend to take comparisons with a grain of salt. That was a magazine article and they tend to be as smart as their author. Like I said, if Basic was involved that would hurt the Atari. But then the Tandy CoCo didn't have integers either and still came close to the performance of machines with integers and that was at the default .69MHz stock clock speed. The double speed poke on it pretty much made it one of the faster machines from Basic. Speccy faster than the C64? Could be... I thought it takes closer to a 4MHz Z80 to match a 1MHz 6502 but to be honest it depends on what you are doing and the implementation. Optimal Z80 code is a little easier than 6502... I've programmed both and an optimal 6502 version sometimes takes a very strange approach that isn't obvious. Commodore hacking newsletter (#16?) had a 3D engine that was faster than the Elite engine. Every 6502 version might have been faster if parts of it had been used. But then, the Z80 version might benefit from some changes as well. Any time you compare machines with a game you are depending on the programmers to implement things in the best way and that varies from one game to the next. Of those machines, yes but the CoCo3 would have been faster once in high speed mode (1.7??? MHz). Older CoCos could double speed when using the ROM so Basic could run faster but it didn't work in RAM so the CoCo3 is faster than older models. Of all 6502 machines, OSI supposedly had a faster 6502 machine if you had the bucks (I *think* 4MHz). It had an ion implanted 6502 or something like that. I wouldn't call it a gamer and OSI disappeared into oblivion. The 2MHz 65816 in the IIgs was also faster. But again, it was a later design. I thought the one I looked at used assembly but I can't find any other article so it might be the one and I just messed up. I looked up benchmark articles in Kilobaud Microcomputing and only found info on assembly benchmarks but that doesn't mean they didn't have basic ones as well... obviously. Yeah, if it's a Basic benchmark then that will really hurt the Atari. I'd like to see what one of the faster replacement Basic's for the Atari that came out later would do on those. Even if that's the case, I still wouldn't change my vote because those benchmarks didn't enter into my decision. To be honest I didn't have either the Atari or C64 as a kid and now I have 2 Atari 130XEs and no C64... but I want one. That article certainly doesn't speak well of speccy Basic. The Z80 is slow but not that slow. Machines like the TRS-80 Model III would have done pretty well in a Basic benchmark. I wonder if the updated ROMs on the web improve Speccy Basic's speed.

But valid, none-the-less... Actually no. GEM Desktop originated on the PC and had color there. I believe it was sold by itself at first. I even used to sell Amstrad PCs that included GEM desktop in the states at the time the ST came out and I'm sure the machines were available in Europe months before we got them. Also, the Amiga was in develpment long before the ST and had a working color GUI... it just shipped after the ST.

Well, of the systems listed I'd have to say the C64 overall but to be honest, it really depended on the game. For some types of games sprites are almost required and the C64's are flat out better than the Atari Player Missile system because no memory moves are required to move an object up and down. Just left and right and it doesn't matter. MSX and other Z80 machines with sprites do ok as does a Ti99. The Ti99's CPU was slow though since the architecture wasn't really designed for it. The Amstrad 6128 Plus was probably the best Z80 machine hardware wise and even had DMA to drive the sound chip. The Atari has more colors so between that and the coprocessor it's possible to make some really great looking screens that make the machine appear to support more colors in a gfx mode than it does. But the more of this stuff you do the slower it becomes because clock cycles are taken away from the CPU to do it. Same goes for sprites on the C64. The absolute worst culprit at that is anything with a Z80. MSX and CPC machines suffer a bigger penalty for the stolen clock cycles than the 6502 with cpu clock cycles times a minimum of 4 cycle intervals on the 6128 Plus. As for sound, more channels vs analog filters vs more machines with the same chip. The Atari has more sound channes which is better for music but you can multiplex channels for more on the other chips so it's not such a big deal. The analog filters on the SID give it the most control of ANY of these old chips... but game developers turned out the same boinky warbling crap anyway. The General Instruments AY chip turns out as good of sound as the Atari but with 1 less channel. Speaker toggling on the Apple II and earlier Speccys sucks and who wants to spend as much on a sound board as one of the other machines? The Mockingboard wasn't cheap! Speccy? Uh, no... strictly low end and doesn't benchmark anywhere near the other machines. And the 6502 is way faster for moving bitmapped graphics around. I've programmed in assembly on the 6502 and Z80... no comparison speed wise for this sort of thing. However, I could probably finish a Z80 program quicker. I posted a sort routine on the Speccy forums last night and it didn't take long to modify the original routine it was based on. 15 minutes or less and I haven't touched Z80 assembler in years. In 6502 it would take much longer to get it right unless I spent a lot more time on the 6502. The Speccy does have some cool games you won't find anywhere else and a very large game catalog. The Oric wasn't the best gamer but it also had some unique titles that were pretty cool and available on no other platform. It's odd display layout made action games a bit of a challenge but more static graphics could be pretty good. The C116, C16 and Plus/4 were somewhere between the Speccy and the C64/Atari as far as capability and were 75% faster than the C64. Pretty good as a competitor to the Speccy but much more limited as far as custom audio/gfx hardware goes than Atari or C64. In recent years several C64 games have been hacked to run on the system and even SID music has been emulated on the built in TED sound. Not as good but pretty impressive anyway. I learned to program the 6502 on an Apple II. The screen memory map is evil and the color generation method (artifacting) sucks. You can do quite a bit with it anyway but it really limits what kind of games you can implement or how good they will be. A really large number of games helps it out though. It works pretty well for games that have static text or minimal motion like RPGs or simulations. One arcade game Space Eggs took advantage of it's color generation quirks to make the bad guys change colors as they moved. The Atari version just didn't have the same feel. There were several of the Sirius titles that were excellent. Other games took advantage of the Apple Pascal's ability to swap subroutines in and out of memory making it possible to have very large games in a small memory footprint. Something I didn't see on any other 8 bit system. The IIc+ was also the fastest 6502 system short of aftermarket 65816 upgrades. I have one and it's pretty fast for the time. The Atari fans love to bring up the clock speed difference between it and the C64 but in an old Compute Magazine they benchmarked the two in assembly and the C64 was the faster of the two there. Both beat the Speccy by a wide margin and the BBC micro was the fastest of the machines tested. However... I haven't been able to track down the magazine the original benchmarks came from so I don't know if they were flawed. If any Basic was involved the Atari's lack of integers in it's Basic really slow it down. Now, I personally had a TRS-80 Color Computer and thanks to color artifacting (similar to the Apple) it could do pretty well. I've heard 4 channel music generated through it's built in DAC that is pretty good. Way better than Apple/Speccy speaker clicks but not like a sound chip either. It's 6809 CPU stomps the 6502 and Z80... don't even argue that. It didn't receive as much game development as the Apple II or Speccy but I'd classify it's games as similar in quality and the same resolution as the Speccy. Games like Time Bandit originated on the CoCo and made it to the 16 bit systems later. The Color Computer 3 however was a totally different beast. 320x225 resolution with 16 colors from a pallette of 64 colors. 640x225x2 max resolution. You could change color pallette registers for color cycling, for placing more colors on screen at once, etc... It had built in hardware for horizontal scolling games so you just change the scoll register to move the screen. No sprites but with it's high CPU speed mode enabled the 6809 can drive over 8 sprites with masking just in software. Some people have managed 16 software sprites which is pretty impressive. The best version of Pac Man I've ever seen on an 8 bit computer is on the CoCo3 and Crash, Crumble, Stomp looks almost like the arcade. The Speech and Sound Pak added an AY sound chip, speech chip and a PIC microcontroller to drive them independantly of the main CPU so a music track doesn't have to steal as much CPU time as any other 8 bit. A common upgrade is the 6309 CPU which is even faster than the 6809. It's kinda like what the 65816 is to the 6502 or 64180 is to the Z80. Sadly Tandy's attitude of protecting their PC line pretty much sealed the fate of one of the best 8 bit game systems ever made. Better hardware, not many games. The Apple IIgs was also an excellent system but it was a later design than the others so that's no surprise. No sprites but a 2MHz 65816 gave it similar capabilities for software sprites as the CoCo3. It had the best built in music/sound of any 8 bit machine. The new graphics modes did away with the old evil graphics memory map and color by artifacting. It had 4096 colors, color cycling, etc... and ran most older Apple II stuff. But you could buy a C64, Atari 130XE and Color Computer 3 for less than what it cost by the time it was released. I picked a nice complete one up off of ebay for $12 + shipping last month. That's less than most C64's go for.

Not all changes on the 128 were for the better. The 128 has vertical lines running through the display on the TV output caused by some sort of noise in the signal where the C64 doesn't. I know my 128D has them. If you compare the 128 and 64 side by side you'll notice it. I think there was a couple cartriges that had a problem on the 128 too but then I have a 128 and not a 64.

The 1200XL is the scarcest of the 8 bit Atari's. It was more expensive to produce than the later models and the war with the C64 + compatibility issues with the new ROM lead to it's demise. I only see 1 or 2 of these on ebay at any given moment but I saw twice that once when one sold really high. That always leads to a lot of listings for the rare machines. This one with 256K and a bunch of extras is over $100: Auction Most of it's problems were related to the ROMs it has and using different ones usually makes most stuff work on it from what I read. I don't have one myself but I would like to get one. It has the best keyboard (at least most people say so) of any of the 8 bit machines so it's worth keeping if you get your hands on one.

The AtariProtos.com site says there is a little color glitch in the death screen but I seem to remember the real arcade machine flashing the screen like that. You would think that once a game is that far along that they would let them finish it in hopes of making back some of the development expense. A couple more weeks work and it probably would have been pretty good.

Adventure will probably win because it's a 2600 game and there are more 2600 fans here.

huh ?? As far as I know there is only one bus in any type of atari 8bit, so all memory has same bus. Normal memory, stack, zero page, extended (130XE) memory. The only difference in an 130XE is that you can allow Antic and CPU to access the extra RAM independently, but not really simultaneously. Ya know, that was obviously wrong after I did some looking but I was sure I read it in a review of the machine and that's where I got the idea. I probably just misunderstood.

DRAM refreshes, screen refreshes, sprites, you name it all take time away from the CPU on most old systems. However, the sprite hardware saves a lot more clock cycles than what it would take to duplicate in software. If you have a 130XE, you can run code out of the bank switched RAM to avoid the slowdown since it's on a separate buss. Sadly, I don't think Atari put page 0 and 1 (stack) on a different buss than the graphics hardware so you still suffer some slowdown.

It's a mylar circuit and I'm not sure I want to solder on it. If everyone's been doing this without problems I'll go ahead and fix it that way. There's a pen for drawing circuits that I'm sure would work great but I couldn't find one locally. Since I have a working 130XE it's not a major priority but I'll need to take care of it sooner or later.