Conversions - which of the 8-bit platforms is closest to the Atari?

[rdefabri]

I have always been fascinated by games that are converted to other platforms, particularly when they reuse or leverage similar code.  I know a few members here have ported / converted games from other platforms to the Atari 8-bits, leading to my question - which of the other platforms (e.g., ZX Spectrum, C64, Apple, etc) are the "closest" or most similar to the Atari 400/800/XL/XE?

[Mclaneinc]

It's a sort of tie between the Apple and the C64, but in the apples case it's because the games were originally Apple games and ported to the Atari. As for the C64, I'm not a big fan of the ports to the C64, in general I've found almost every port to be sub standard on the C64. About the only one I thought was ok was Henry's House.

 

Well that's what I think..

Edited September 9, 2022 by Mclaneinc

[rdefabri]

22 minutes ago, Mclaneinc said:

It's a sort of tie between the Apple and the C64, but in the apples case it's because the games were originally Apple games and ported to the Atari. As for the C64, I'm not a big fan of the ports to the C64, in general I've found almost every port to be sub standard on the C64. About the only one I thought was ok was Henry's House.

 

Well that's what I think..

I think in terms of capability - they are close(ish).  I'm thinking in terms of code reuse...the C64 sprite engine is way different than Atari's PMG (and I imagine all of the platforms are very different), so that presents some challenges.

 

I'm thinking of (say) Chimera.  If I understand the story correctly, the programmer more or less made the different platform versions in a few days, no doubt reusing much of the code that could be considered "standard" (for lack of a better word).

 

So the question might be better asked as such - if handed code from platform XXX, which would be the "easiest" to convert to the Atari?

[pseudografx]

I'd say the Plus/4 is not too far, with regard to CPU speed and palette. But all things considered, no platform is really close to the Atari 8-bit. The 6502-based systems are a lot more diverse than the Z80 ones, which often benefited from quick (and lazy) ports.

Edited September 9, 2022 by pseudografx

[Mclaneinc]

Obviously, any 6502 based platform has an easier chance, and yes apparently Shahid Ahmad did a quick turn around. I think he was asked that question when he visited us a while back. Again, the while different in its sprite mechanics the c64 would be the most obvious choice.

 

 

Edited September 9, 2022 by Mclaneinc

[matosimi]

Acorn BBC Micro is the closest in my opinion.

It has the same CPU on slightly higher clock, so technically speaking, the game core logic does not need to be touched/changed or even understood when working on the conversion.

It has no HW sprites, so everything is done with the software. Atari PMGs can be used to enhance the look.

It has video ram that can be quite easily emulated by Atari charset modes, however the pixels in color modes are represented by different bits within byte, so all drawing routines need to be adjusted.

Major drawback is that the screen has 256 lines, which is not achievable on our Atari XL/XE, so if the game uses whole screen area it is needed to adjust the design (that was the case during my Castle Defender conversion).

 

Edited September 9, 2022 by matosimi

[zzip]

I would think in terms of porting,  Apple II would be easiest.    No Sprites, primitive sound.   When porting from Commodore you would have to do more trade offs.

[Mclaneinc]

Mind you, a machine with custom chips will always be hard to copy..

[Mclaneinc]

1 minute ago, zzip said:

I would think in terms of porting,  Apple II would be easiest.    No Sprites, primitive sound.   When porting from Commodore you would have to do more trade offs.

That's one reason I mentioned the Apple but now the question is, which would be the easiest, which is why I go back towards the C64, I'd imagine creating a software sprite engine would be a bit of a chore, certainly not making it an easy port.

 

Mind you, I'm not a coder so I'll leave it to them to answer..

[zzip]

9 minutes ago, Mclaneinc said:

That's one reason I mentioned the Apple but now the question is, which would be the easiest, which is why I go back towards the C64, I'd imagine creating a software sprite engine would be a bit of a chore, certainly not making it an easy port.

Well since OP asked about reusing code, and all Apple sprites are software sprites, so it seems that you could port the software sprite engine as is (or use PMG to enhance it)

 

For C64 you have to translate the way the C64 custom chips do sprites and extra color placement to the way the Atari chips do things, and they are both restrictive in different ways and don't map 1:1..   

 

That said,  I have been noticed that many C64->Atari ports end up being closer to the original than I'd expect given the differences,  so who knows?

[rdefabri]

6 minutes ago, zzip said:

Well since OP asked about reusing code, and all Apple sprites are software sprites, so it seems that you could port the software sprite engine as is (or use PMG to enhance it)

 

For C64 you have to translate the way the C64 custom chips do sprites and extra color placement to the way the Atari chips do things, and they are both restrictive in different ways and don't map 1:1..   

 

That said,  I have been noticed that many C64->Atari ports end up being closer to the original than I'd expect given the differences,  so who knows?

Those early Apple game ports even had similar sounds to the Apple (Bandits, Castle Wolfenstein), and in some cases monochrome graphics, which lead me to believe they were fairly "easy" to port over.

 

I find that the Glurkvision ports are cool, although I imagine the architecture of the 2600 - while crude - has a lot of similarities to the 8-bit platform.  My original post was less about the 2600, more about the 8-bit / 6502 based PCs.

Edited September 9, 2022 by rdefabri

[rensoup]

I wrote a tool to semi manually colorize pictures for the A8 (piccolo) I used it for the title picture in PoP and I also released a slideshow before that:

 

 

 

I tested it with many C64 pictures ranging from simple (few colors in the original) to complex (changing palette for just about every 4x8 char). I don't think any of the original C64 pictures were enhanced with sprites.

 

In my experience it is simply impossible to convert complex C64 picture with a reasonable degree of accuracy because there are just too many colors per line.

On the A8, you can potentially reach 8/9 colors per line when using mode4 + PMGs while the C64 can have all 16 I believe. So whenever I tried to convert anything by Facet for instance (prolific C64 artist https://csdb.dk/scener/?id=21388) it would usually end up looking disastrous.

 

This is a major advantage for the C64 and it makes porting newer C64 games which boast lots of colors potentially difficult to port faithfully.

 

I was only able to convert semi complex pictures and usually with some reduction in quality but the palette selection being better on the A8, I was able to improve a few of them.

 

That said, the PoP title picture turned out really good and doesn't really look like anything on the C64 so yeah it's important to use the target machine's strengths

 

[drpeter]

20 hours ago, zzip said:

all Apple sprites are software sprites, so it seems that you could port the software sprite engine as is

Sadly not, as the way that Atari screen memory bits are mapped to the display is different (as is the case also with many other 8-bit platforms)

[Robert Cook]

On 9/9/2022 at 10:52 AM, rdefabri said:

I have always been fascinated by games that are converted to other platforms, particularly when they reuse or leverage similar code.  I know a few members here have ported / converted games from other platforms to the Atari 8-bits, leading to my question - which of the other platforms (e.g., ZX Spectrum, C64, Apple, etc) are the "closest" or most similar to the Atari 400/800/XL/XE?

That depends on several factors: 1) how the hardware features of the two platforms match up, 2) what features/capabilities of the original platform the game uses, and 3) how the programmer decides to do the conversion.

 

In the most general sense, I think the C64 matches up the best with the A8, but that's far from the whole story.  First of all, they are generally the closest in overall graphics capability.  However, where they differ they differ quite strongly, so it is often very difficult to convert games from one to the other anyway.  The greatest similarity they share is their multicolor character (text) graphics modes.  Both have fully redefinable character sets (quite powerful and not a common feature among 8-bit computers), and the multicolor variant of this mode is used in many games on both platforms.

 

This mode on the A8 has 5 color registers for 4 bit patterns.  Each character cell has 4 colors available (selected from a palette of 128, which is 8 shades of 16 hues), and the most significant bit of the character code selects between the 4th and 5th color register for the 4th bit pattern to represent.  The remaining 7 bits of the character code select from a set of 128 redefinable characters.  And using DLIs, the CPU can change the color registers per character row.  It is possible to change them at specific scanlines, too, but that would waste quite a few CPU cycles per frame (unless you stuff the DLI routines with some code you need to run at that point).

 

The C64's multicolor character mode also has 4 bit patterns for 4 colors per character cell.  The colors are selected from a palette of 16 (obviously far more limited than the A8 in this respect), and stored in 3 color registers plus a color/attribute map that has an entry for each and every character cell (like having 1000 color registers).  This is more flexible than the A8 in terms of being able to place more colors on each horizontal scanline, and also allows for 8-bit character codes to be used to select from a set of 256 redefinable characters.  That's twice as many as the A8 has, which sometimes makes no difference, but can also sometimes make a very big difference, obviously depending on how many different characters a game needs.  However, one of the bits in the color map is an attribute bit, and the result is that only the first 8 of the 16 colors in the palette can be used for the 4th color of each cell (note that this limitation does not apply to the C64's multicolor bitmap mode, which has 3 color maps with no such limitation).  In compensation, the attribute bit selects between multicolor and hi-res character mode (2 colors with half the pixel width and twice the effective horizontal resolution) for each character cell.  This interesting and unique feature, which kind of makes the character map like an A8 display list because it changes modes automatically, is used carefully by some C64 games, such as Impossible Mission, to give their graphics both multicolor and hi-res qualities.  The A8 could do the same thing per row easily enough, but per cell is rather different.  Additionally, using raster interrupts on the C64 allows the CPU to change the 3 color registers on any specific scanlines you want, rather than by character row.

 

Despite the differences, these modes are quite similar in the grand scheme of things, and make the conversions of some games between these platforms relatively straightforward.  That said, there are the two other factors mentioned above to consider.  If different modes are used, then all bets are off, because the A8 and C64 become quite different outside of these modes and their multicolor bitmap modes.

 

The Apple II is perhaps the second best match because it has fewer graphics modes and features to start with, making its games easier to convert for any platform, and the A8 also has a hi-res mode with NTSC artifact colors.  A bunch of game conversions exploit this similarity (with the A8's hue set to white) to make conversions easier, quicker, and cheaper, although the issue is that the A8's artifact colors are inconsistent between models (and sometimes between individual units), and only offer 4 colors compared to the Apple II's 6 colors.  The effects of this can be seen in some of the Ultima RPG games from Origin Systems.  They're good and quite direct conversions, but the colors are inconsistent between A8 models, and they lack a couple of colors in comparison to the Apple II.  An example of a different conversion strategy of an Apple II original game is Conan, which on both the A8 and C64 conversions apparently uses the multicolor bitmap modes of these platforms.  This made the conversions very similar to each other, which was a win for efficiency, but the programmer didn't bother to use any of these more powerful platforms' features, not even to give them as many colors as the Apple II original had.  That should have been quite easy, especially in the case of the C64, but what was done gave these conversions both lower resolution and fewer colors than on the Apple II.  See what I mean about the other factors?

 

For further illustration, we can compare the C64 with the ZX Spectrum or "Speccy", which were fierce competitors in the Europe, especially in the UK.  The C64 has a hi-res bitmap mode that is pretty much a superset of the very similar graphics mode on the Speccy, so despite their rather different CPUs (6502 variant versus the Z80), one might have expected conversions to be relatively simple and decent, but often they were not.  Conversions from the C64 were most often rather problematic because most games used different modes that had no close match on the Speccy, but what about the other way?  Well, it varied, surprisingly to me.  Some were indeed direct conversions using the C64's similar hi-res bitmap mode, but many such games ran very slowly on the C64.  Not all did, which tells me that either some code was automatically converted from Z80 to 6502 (which just can't produce optimal results) and/or some Speccy programmers just weren't as good at 6502 assembly language.  This was/is often true of conversions based on graphics features alone, too, even when the same CPU is involved.

 

On 9/9/2022 at 11:26 AM, rdefabri said:

So the question might be better asked as such - if handed code from platform XXX, which would be the "easiest" to convert to the Atari?

It depends. 😁  As a programmer, I think it's "easiest" to convert between the C64 and A8 when they use similar modes, which they have.  Or it can be incredibly difficult and time-consuming if the game being converted involves different modes.  One could argue that the Apple II is more consistently easy, and maybe that's a valid point, but the direct conversions that I've seen have typically been somewhat lackluster on the A8, despite the latter being overall a much more powerful platform, graphically.  Few would spend the money (time and effort) it would take to redesign a game originally made for a different platform for the A8 and its many features.  Such decisions were/are made on a case-by-case basis.

[Rybags]

The inspiration from Apple II and PET is fairly obvious on the Atari.

Like the graphics + text windows and full screen editor and graphical characters.

But closeness, I'd put Plus/4 and C64.

On the Plus/4 you can practically directly convert sound and music as the formula is almost the same.

The character graphics at least are fairly close on all 3.

Bitmap of course we have the proper linear where theirs is that cell based compromise.

On the OS and Basic side, you could probably say later computers like C128, BBC Model B and Amstrad got some inspiration from Atari.

C128 got some proper multimedia and file related statements at last and the others had more modern and modular OSes.

[Robert Cook]

On 9/9/2022 at 11:31 AM, matosimi said:

Acorn BBC Micro is the closest in my opinion.

It has the same CPU on slightly higher clock, so technically speaking, the game core logic does not need to be touched/changed or even understood when working on the conversion.

It has no HW sprites, so everything is done with the software. Atari PMGs can be used to enhance the look.

It has video ram that can be quite easily emulated by Atari charset modes, however the pixels in color modes are represented by different bits within byte, so all drawing routines need to be adjusted.

Major drawback is that the screen has 256 lines, which is not achievable on our Atari XL/XE, so if the game uses whole screen area it is needed to adjust the design (that was the case during my Castle Defender conversion).

 

Admittedly I'm not that familiar with the BBC Micro or "Beeb", but doesn't its 6502 CPU run at a full 2 MHz, sharing the bus equally with the graphics hardware, which also has 2 MHz worth of cycles with which to access memory independently?  My understanding is that it does this with DRAM that runs twice as fast as the standard DRAM of the time, which allows for greater resolution and bit depth combinations without halting the CPU for DMA at all.  While it lacks the powerful graphics features the A8 has, the Beeb has considerably greater raw "grunt" in terms of CPU speed and graphics bandwidth.  You can't compare it with a shared 1.79 MHz (on NTSC) bus.  I think the A8's effective CPU speed, when running in typical modes and conditions for games, is closer to that of the Apple II, VIC-20, and C64 than it is to the Beeb.

 

Then again, I don't know anything of the Beeb from experience, or have any real depth of knowledge on it.  Of course, I'm not saying that it's "better" than the A8 (or the C64, for that matter), which has so many advantages in other areas, but I think it's an exceptionally fast 6502 machine for that era, concerning raw processing.

 

On 9/9/2022 at 11:54 AM, zzip said:

Well since OP asked about reusing code, and all Apple sprites are software sprites, so it seems that you could port the software sprite engine as is (or use PMG to enhance it)

 

For C64 you have to translate the way the C64 custom chips do sprites and extra color placement to the way the Atari chips do things, and they are both restrictive in different ways and don't map 1:1..   

 

That said,  I have been noticed that many C64->Atari ports end up being closer to the original than I'd expect given the differences,  so who knows?

Perhaps it would be possible to reuse much of a software sprite engine from the Apple II, but it would definitely have to be modified for the rather different memory layout of even the somewhat similar hi-res modes.  And at the bit/pixel level, there are significant differences, too.

 

On 9/9/2022 at 11:59 AM, rdefabri said:

I find that the Glurkvision ports are cool, although I imagine the architecture of the 2600 - while crude - has a lot of similarities to the 8-bit platform.  My original post was less about the 2600, more about the 8-bit / 6502 based PCs.

Sure, the CTIA/GTIA in the A8 is a direct analog of and successor to the TIA chip in the VCS/2600.  Even their names are similar.  But while the GTIA can be used like the TIA in some ways, namely the CPU feeding the PMGs data while "racing the beam", it lacks (or does not expose) some of the features that TIA has, such as a playfield data register and repeating sprites.  Unsurprisingly, the GTIA was really meant to be used with the ANTIC.  You could still "race the beam" with the CPU to do additional things, but not exactly like how it's done on the 2600, which was expressly designed to operate in this way (and only in this way).

[Robert Cook]

On 9/10/2022 at 8:39 AM, drpeter said:

Sadly not, as the way that Atari screen memory bits are mapped to the display is different (as is the case also with many other 8-bit platforms)

Yes, 8- and furthermore 16-bit platforms.  In those days, being so early, there were so many different architectures being tried out that it was mind-blowing in comparison to the relative homogeneity of the modern era.  Some computers and consoles had separate video memory that was accessed through a port (the C128 had both this and the VIC-II), and at least one (I'm thinking the TI-99/4 series) stored code (except for ROM) in the video memory, which presented a bottleneck for its 16-bit CPU (the Intellivision was also a 16-bit machine).  The A8 had the luxury of two video chips, hence its plethora of modes, features, large color palette, and such, while other computers had to squeeze what they could out of less.

The C64's VIC-II chip had to more or less try to match the A8 in different ways at a cheaper price (only one graphics chip), so it has its ANTIC counterpart built in, and it's incredibly simple, because half of the chip die is taken up by the fancy sprite system.  The part that accesses memory only does it in one way for all modes, instead of a bunch of different ways like the ANTIC does.  The extra data that is read in many cases was repurposed as additional color maps.  Hi-res bitmap mode has 2 of those from the main DRAM, and multicolor bitmap mode has the same 2 plus a 3rd read from a dedicated bus connected to a small SRAM chip.  Doing everything the same way all of the time at the front end saves a lot of silicon, and actually provides additional capabilities in this case.  Of course, there are a lot of compromises in this architecture, too, one of which is that bitmap graphics are mapped to memory like character sets: 8 bytes to each cell, instead of in a more ideal linear fashion like on the A8.  This still works, but makes some things a bit harder to do (conversely some things are harder to do on the A8, too, which does not have color maps).  The VIC-II just could not spare the silicon die area for anything more or better.

The Apple II, which originally used discrete TTL logic for its graphics driver, is also really short on silicon, even for what it does.  It reads and generates text-mode characters differently because it has a dedicated bus to the character ROMs, which unfortunately means they are not redefinable like on the A8 and C64, but on the bright side, its CPU is never interrupted for anything (no DMA and no interrupt sources whatsoever, unless you were to install a sound card or mouse card and use that, which most people did not), but like the C64, it always reads graphics data in the same manner regardless of the mode (very different between these two platforms, though), which cuts down on the silicon required and the cost of manufacture (not Apple's retail prices, though--they had some BIG profit margins, and still do).

Moving on to the 16/32-bit Amiga, whose chipset was designed by the guys who designed the A8's chipset, this computer likewise used linear addressing for bitmaps, but unusually it used non-linear storage for bits, storing each bit of each pixel in its own separate (i.e. different set of addresses) bit plane.  This was because they wanted to have 3- and 5-bit graphics modes to save every last scrap of DRAM they could (why go to 4 or 8 bits if you don't need that?), and obviously this doesn't fit evenly in byte-addressed memory.  So what they did was have programs/games use specially designed devices in the Agnus chip (e.g. the blitter) to manipulate bitmaps in memory instead of having the CPU modify the memory directly, which would have been painfully slow.  This is oddly similar to Atari's Missile Command arcade game, which has 2-bit graphics for 4 colors in most of the display, but the developers wanted 3 bits for 8 colors near the bottom, and didn't want to waste any expensive memory to get it.  So if I remember correctly, they used bit planes, too, and implemented a small circuit to translate and store the bytes that the 6502 CPU wrote to a certain range of addresses into 3 bit planes for the graphics hardware to read from.  Imagine memory being written differently than the CPU would have expected, just to save a little bit on memory requirements without slowing graphics manipulation down to a crawl.  I guess 4 bits per pixel would have been overkill in that case.

[KG7PFS]

How does the TRS-80 Color Computer fit into this puzzle? I know the 68' cpu was just different enough to be a pain, just close enough to the 65' that it wasn't _that_ hard to translate.

[FifthPlayer]

1 hour ago, KG7PFS said:

How does the TRS-80 Color Computer fit into this puzzle? I know the 68' cpu was just different enough to be a pain, just close enough to the 65' that it wasn't _that_ hard to translate.

 

Games written for the CoCo would probably port over pretty easily, as the A8 has a pretty good match for all of the CoCo's display modes.  The real issue is the CoCo didn't have a lot of notable original software to port over.

[jhd]

Most Coco games used "high resolution" 256x192 mode. This was Black and White with two additional artifact colors (Orange and Blue/Red and Green) available.

 

Some early games used lower resolution, four-colour palates (Green, Blue, Red, and Yellow or Orange, Purple, White, and Cyan). Even lower resolution semi-graphics and character modes existed, but they were almost never used.  

 

The Coco lacks any sprite hardware.

 

Sound capabilities are surprisingly decent, but they consume a lot of CPU time.    

[KG7PFS]

Many CoCo 1/2 games were clones or almost clones of other popular games, the rest did a supprisingly good job with the hardware they had to work with. I'm really not sure which was worse - Apple or CoCo. I think the sound hardware was the same - a lousy 6-bit DAC.

 

Neither the Apple or CoCo had any significant hardware upgrades unil 1986. The Apple IIgs and CoCo 3 contained all of their predecessor's hardware plus HUGE upgrades. Sadly, the new (fresh?) fruit computer tried to outperform PC's at wasting memory and CPU power, and it still cost too much.

 

Many avanced games of the late 80's, such as Koronis Rift, Rescue on Fractalus, the Sierra games, Predator, Robocop, and Rad Warrior, were available for "all three" - The CoCo 3, Atari 8-bit, and Commodore 64.

[Robert Cook]

2 hours ago, KG7PFS said:

Many CoCo 1/2 games were clones or almost clones of other popular games, the rest did a supprisingly good job with the hardware they had to work with. I'm really not sure which was worse - Apple or CoCo. I think the sound hardware was the same - a lousy 6-bit DAC.

Which was worse?!  Maybe I'm just overly nostalgic, but they're all great!  I'm not that familiar with the CoCo 1/2 (or 3), but unless it can do the 6-color hi-res artifact trick that the Apple II does (and I haven't seen that), then regardless of the bunch of graphics modes it offers, in my opinion it can't quite match the Apple II graphically.  That's not an absolute statement that covers everything, but on paper and based on the dozens of examples of games I just looked at, I think the pre-GS Apple II series edges out the Coco 1/2.  CPU-wise, the CoCo has the advantage, but not an overwhelming one.  In terms of text modes and usability beyond games, the Apple II is better, in my opinion, especially if we count the IIe (lowercase characters, 80 column text mode, double hi-res mode, et al.).  But I don't care, I barely know the CoCo, but I still love it. 😁  And the Apple II.

 

As for sound, the CoCo 1/2 should be better with its 6-bit DAC.  The Apple II just has a 1-bit clicker, similar to the one in the Atari 400/800 (and the click sound that is added to the audio signal in the XL/XE series).  And if I heard/read right, I believe the CoCo 1/2 also has a 1-bit clicker.  While it is possible to install a number of sound cards in the Apple II, those were never widespread back in the day, and were never well supported, so this only counts in a limited sense: some Ultima series games, most prominently, and a few other games (there are more now, new games, but my perspective is based more on the past).

[Rybags]

I can't ever recall hearing decent music or sound on an early CoCo.  Surprised to hear it has a 6-bit DAC.

The 6809 is a more powerful CPU than the 6502 but CoCo 1/2 at least were hampered by the inferior graphics hardware.

CoCo 3 specs are impressive in the graphics department.

Possibly a reason for lack of good sound/music could be that there's not adequate timer/interrupt support?  Of course you can do all that in software alone but then everything else suffers.

[ClausB]

I thought the Apple II was close enough to try a port of subLogic's FS1 to Atari. The Apple's discontiguous bitmap could easily be duplicated with a custom display list, and color artifacting would be similar. But the Apple uses only 7 bits per byte for graphics, and they are in opposite order from the Atari, and that turned out to be the biggest headache. The FS1 code was so finely tuned to that format and it was a lot of work to adapt it.

[Robert Cook]

6 hours ago, Rybags said:

I can't ever recall hearing decent music or sound on an early CoCo.  Surprised to hear it has a 6-bit DAC.

The 6809 is a more powerful CPU than the 6502 but CoCo 1/2 at least were hampered by the inferior graphics hardware.

CoCo 3 specs are impressive in the graphics department.

Possibly a reason for lack of good sound/music could be that there's not adequate timer/interrupt support?  Of course you can do all that in software alone but then everything else suffers.

The CoCo 1/2 can run OS-9, which features preemptive multitasking, so interrupt support should be OK for music.  I don't know much about this platform, but I know that there are timer and V-blank interrupts, among other sources.  Perhaps the problem, regarding background music, is that it would take too much CPU time to play more than momentary sound effects, assuming that the DAC doesn't have its own DMA or other dedicated hardware driver.  I figure that if music indeed had to be standalone rather than playing in the background, then there would have been insufficient motivation to put much effort into it.  Just a guess, I don't know.