7800 programming vs. 8-bit/5200/2600 question...

[+Pac-Lander]

This question is coming from a non-programmer/graphic artist, so please forgive the lack of knowledge!

 

I'm wondering if it's a simpler process to translate a game to the 7800 from an Atari 8-bit, 5200, or 2600 game (for example) if the game/code already exists vs. starting from what I would imagine be from scratch if the idea was to create a 7800 game based on a different platform altogether (i.e. arcade port, Lynx, NES, etc). 

 

Or does it not matter at all, and each platform has its own completely unique language? Certain Atari 8-bit, 5200, and even 2600 games can look (and sometimes play) a bit more similar to 7800 games, so was just curious. 

 

[SlidellMan]

It isn't as easy as you think, despite all those systems having the same CPU. You have to edit RAM Addresses, color palettes, sprites, and controls just to name a few.

[+Pat Brady]

It's a good question.

 

I consider the 2600, 8-bit computers/5200, and 7800 to be 3 different platforms. They do share the same CPU (the 2600's runs slower), and the 2600 and 7800 use the same sound chip, but there's not much similarity otherwise (unless running the 7800 in 2600 mode, in which case it's a 2600). They have completely different graphics processors and memory layouts. The NES also uses the same CPU, so I don't see it as any further away.

 

Whether porting an existing game is easier than starting from scratch probably depends on the nature of the game and how it was coded. If the original was coded with the game logic cleanly separated from the display code, then porting the game logic might be fairly straightforward. If all the code is intertwined, it might be easier to start from scratch. Coding for reuse takes effort. My impression is that BITD it wasn't really a consideration: it was hard enough just to get a game working in the allotted time.

 

Since the graphics systems are all completely different, the display code — which might be a substantial part of the total code — cannot be reused in any case.

 

Even if the code is cleanly separated, the systems have big differences in RAM and practical CPU power. That's obviously a problem when going from a more powerful system to a less powerful system. But going in the other direction, it might make it hard to take advantage of that power, which we typically want to do. For example, the 2600 has only 128 bytes of RAM in the console, and games have to be coded around that limitation, and that might prevent desired improvements in a 7800 game, so you zmay end up rewriting it anyway.

 

I know some of the 8-bit computer homebrewers have done ports using code from C64 or BBC Micro versions (again, same CPU, different graphics chips). Maybe it makes more sense when the source and target platforms' capabilities are in the same ballpark.

[zzip]

On 3/3/2023 at 5:39 PM, Pac-Lander said:

This question is coming from a non-programmer/graphic artist, so please forgive the lack of knowledge!

 

I'm wondering if it's a simpler process to translate a game to the 7800 from an Atari 8-bit, 5200, or 2600 game (for example) if the game/code already exists vs. starting from what I would imagine be from scratch if the idea was to create a 7800 game based on a different platform altogether (i.e. arcade port, Lynx, NES, etc). 

 

Or does it not matter at all, and each platform has its own completely unique language? Certain Atari 8-bit, 5200, and even 2600 games can look (and sometimes play) a bit more similar to 7800 games, so was just curious. 

 

There might be some game logic written in assembly that can be reused, but the 7800 has a radically different sprite system than the 5200/8-bit line, so you'd have to rewrite the graphics code and probably sound code too at minimum

[Synthpopalooza]

On 3/6/2023 at 1:05 PM, zzip said:

There might be some game logic written in assembly that can be reused, but the 7800 has a radically different sprite system than the 5200/8-bit line, so you'd have to rewrite the graphics code and probably sound code too at minimum

If the 7800 game uses an onboard POKEY, the sound part should at least be similar.

[+Defender_2600]

Or better with 6 channels, TIA + POKEY as in Commando.

 

Today many new 7800 releases use POKEY.

 

 

 

Edited March 17, 2023 by Defender_2600

[Synthpopalooza]

Also the recent 7800 port of Popeye is POKEY plus TIA

[RevEng]

Generally this is about what is easier on balance for the developer, converting vs remaking.

 

In terms of non-arm-assist 2600 to 7800 conversions, 2600 games are typically so much smaller than 7800 games, that porting doesn't really save you a whole lot of time. 2600 games are also architected to save as many cycles as possible in the display kernel, and often that spills into other areas of the code, or even the whole architecture of the game. None of that is useful to convert over to the 7800, but you still need to understand it, and then remove it.

 

In terms of A8 to 7800 conversions, the conversion vs remake balance heavily depends on what unique hardware features the game uses. I think the only finished A8 to 7800 conversion at this point in time is Serpentine. Out of the dozens of A8 games I enjoyed greatly back in the day, I picked Serpentine to port because it didn't significantly use Player-Missile graphics, collision registers, or anything else deeply A8 flavoured. (Serpentine was itself a port from Apple II to A8, so that makes sense) Even then, i spent a few weeks disassembling the A8 release before even getting to the adaptation stage, so conversion isn't the easy slam dunk you might think it is.

 

The 7800 graphical strengths are somewhat opposed to the strengths of the 2600 and A8. Player-Missile graphics can easily be made tall, but being very wide is a decent challenge. 7800 display objects are easily made very wide, but creating very tall objects requires creating multiple stacked objects, which be hard on resources. Also, the cycle penalty for DMA tends to be heavier on the 7800 than on the A8, for comparable modes - I had to tune Serpentine timings to make it run faster on the 7800, just to keep pace with the A8 version.

 

When you're porting games from other platforms that don't have similar DMA penalties and improving graphics for the 7800 at the same time, you need to factor in that DMA cycle penalty even larger. Even though the C64 and PET run at a slower clock than the 7800, the fact that the 7800 port of Petscii Robots was pretty much all 160B (there are 314 160B sprites that make up the main display) meant it ran much slower than the other platforms at first. I had to dig really deep with algorithmic improvements to get things running at a correct speed.

 

While DMA, graphical strengths, lack of collision registers, etc. are a factor for any sort of port - conversion or remake - dealing with these issues in your own source from the outset is always going to be much easier than having to deal with them by refactoring someone else's source code.

 

Thanks for coming to my Ted Talk.

[KrunchyTC]

I have a few questions, since I don't know how things work, I'm curious about certain aspects of the 7800. Does having an external sound chip save on CPU cycles at all? Also, how much does the TIA cripple the performance of the SALLY chip? Do you have to access the TIA chip very frequently? Also, is it a significant issue to not have the ability to have both the CPU and graphics chip to access memory at the same time? Does that mean that there is a performance penalty by default? Is that what DMA is? Why would GCC go with such a design?

Edited May 24, 2023 by KrunchyTC

[RevEng]

13 hours ago, KrunchyTC said:

Does having an external sound chip save on CPU cycles at all?

Nope, being external doesn't have an effect on CPU cycles. Depending on how the chip paradigm and/or number of voices, it may take more cycles to drive than TIA. (or in the case of a chip with tracker built in, fewer cycles than TIA. AFAIK this only applies to the microcontroller sound-chip in the Rikki+Vikki homebrew)

 

13 hours ago, KrunchyTC said:

Also, how much does the TIA cripple the performance of the SALLY chip? Do you have to access the TIA chip very frequently?

The usual way of driving TIA audio is to update it's 6 registers once a frame. A simple tracker might use a few dozen cycles. A very complicated tracker might use a hundred or so. Even with DMA the average game will have ~10000 cycles, so this is a drop in the bucket.

 

Driving TIA more frequently to play PCM audio is different, since you're likely hitting TIA over hundreds of times per frame. But that's not a common requirement for games.

 

13 hours ago, KrunchyTC said:

Also, is it a significant issue to not have the ability to have both the CPU and graphics chip to access memory at the same time? Does that mean that there is a performance penalty by default? Is that what DMA is? Why would GCC go with such a design?

Yes there's a penalty, and that's what DMA amounts to. (Direct Memory Access -  when a non-cpu device takes over access to the memory bus) Having shared memory would complicate the design quite a bit ($$$) especially given that Maria runs considerably faster than Sally's top speed.

 

The reason for going with such a design, was to maximise what the 7800 is capable of at the intended production cost.

 

DMA as an approach in itself isn't unorthodox. The Atari 8-bit computers do the same - the Sally CPU with the necessary halt line was developed for those computers, and repurposed for the 7800. The DMA penalty is smaller in the computers because Antic is doing less Sally halting than Maria does.

 

CPU is the typically most constrained resource in this architecture, but it's less of a big deal than you may think. Not every game task needs to happen every frame, so you can claw back time by scheduling things only when needed, rather than when convenient, and then balancing that scheduling. Further, algorithmic improvements can get you far. (see my previous comments on Petscii Robots)

[KrunchyTC]

3 hours ago, RevEng said:

Nope, being external doesn't have an effect on CPU cycles. Depending on how the chip paradigm and/or number of voices, it may take more cycles to drive than TIA. (or in the case of a chip with tracker built in, fewer cycles than TIA. AFAIK this only applies to the microcontroller sound-chip in the Rikki+Vikki homebrew)

 

The usual way of driving TIA audio is to update it's 6 registers once a frame. A simple tracker might use a few dozen cycles. A very complicated tracker might use a hundred or so. Even with DMA the average game will have ~10000 cycles, so this is a drop in the bucket.

 

Driving TIA more frequently to play PCM audio is different, since you're likely hitting TIA over hundreds of times per frame. But that's not a common requirement for games.

 

Yes there's a penalty, and that's what DMA amounts to. (Direct Memory Access -  when a non-cpu device takes over access to the memory bus) Having shared memory would complicate the design quite a bit ($$$) especially given that Maria runs considerably faster than Sally's top speed.

 

The reason for going with such a design, was to maximise what the 7800 is capable of at the intended production cost.

 

DMA as an approach in itself isn't unorthodox. The Atari 8-bit computers do the same - the Sally CPU with the necessary halt line was developed for those computers, and repurposed for the 7800. The DMA penalty is smaller in the computers because Antic is doing less Sally halting than Maria does.

 

CPU is the typically most constrained resource in this architecture, but it's less of a big deal than you may think. Not every game task needs to happen every frame, so you can claw back time by scheduling things only when needed, rather than when convenient, and then balancing that scheduling. Further, algorithmic improvements can get you far. (see my previous comments on Petscii Robots)

Very interesting, It's reassuring that the memory bus isn't as big an issue as I thought, back in the day, people on forums would say that part of the 7800's hardware was a system killer. Thanks for the response!

Edited May 24, 2023 by KrunchyTC