Porting acrosss different consoles, how the do that?

[magallanes]

Hi everybody:

 

Programming for the 8bits computers was a challenge and most games was programmed in Assembler.

 

However, i am amazed to find that most games was ported for several computers. How they do that?. Programming every single port or what?.

 

 

[+slx]

I suppose that in the 80s many ports were done from scratch. Even Atari employed programmers who ported Atari arcade games to Atari consoles weren't routinely given as much as graphics 'assets' let alone details on game logic and mechanics and often had to play the arcade game to find out what to program.

 

I doubt that there were many programmers around in the 80s who knew their way around two or more types of computer or console well enough to do ports themselves.

 

When you consider that even machines using the same 6502 had wildly differing feature sets and complex, fast games required a game kernel tailored to that feature set, it was probably easier to start from scratch and try to translate the spirit of the game to the target platform using it's features in the best way possible rather than attempting a subroutine by subroutine conversion. I am in no way an expert on ports but those games I remember comparing between my Atari and a friend's C64 usually differed a lot in both graphics and gameplay.

 

Direct ports using the experience of 30 years seem to be a recent phenomenon

 

A notable exception are Atari ports from the Apple that don't use PM graphics. I suspect the original Brøderbund Choplifter, AE and Threshold to fall into that category.

 

Scott Adams and Infocom used generic game files run on system specific interpreters.

 

 

 

 

Gesendet von meinem iPhone mit Tapatalk

[ggn]

And then there's some heroes like Pete Harrap who did all the porting by hand themselves across platforms.

 

 

Games like Thunderbirds and Manchester United were done on five different formats. Did you work on them one by one or all at the same time?
One by one. Basically, we'd get one version running and then port over to the others. That way we were not faced with writing multiple version of the same "logic". The "C" language is now touted as being very portable, but in those days all was in assembler and we went through line by line converting one asm format into another. However, we did get to be VERY good at it, to the point where I could do say 1300 lines a day at 90% bug free level.

 

(source)

[+Stephen]

Don't forget guys like Jeff Minter. I recall an interview with him where the 1st half of day was spent doing Intel assembly, the latter half on Motorolla. He had to keep not just the mnemonics in his head, but the endianess too.

[pirx]

it was both more difficult and less difficult - more, because you had to practically rewrite the code, less, because generally there was much less code to port.

[ggn]

While we're at it, Archer Maclean did all the ports to his games himself.

[Rybags]

On same CPU type systems you can keep the game logic much the same. Even much of the graphical assets.

Stuff like object positioning and rendering will often be different.

If a game is started with port-ability in mind, then it'll usually end up a more "structured" piece of programming and porting even to entirely different CPU types should be easier, but of course it's helpful if it's your own code that's being ported and not years later.

[JamesD]

Don't forget guys like Jeff Minter. I recall an interview with him where the 1st half of day was spent doing Intel assembly, the latter half on Motorolla. He had to keep not just the mnemonics in his head, but the endianess too.

Anyone that has gone between different processors has had to do that.

It goes with the territory.

[sack-c0s]

I'd assume keeping a clean seperation between logic and machine-dependent presentation/input code was the way to do it back then if you were planning a port from the beginning