game development in the 80s

Started by
13 comments, last by JiiPee 11 years, 4 months ago

what did huge game companies like Nintendo or Sega or Atari or even those awful companies like ljn (shivers) or great companies like konami use to program there games in the 80s?

Advertisement
From what I understand it was mostly assembly. I have a book at home by an old NES programmer. I'll post the title when I get back home.
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

http://skilldrick.github.com/easy6502/

knock yourself out kid.

thank you so much!

what about for the original gameboy or the turbo grafx 16? it doesn't say you can use 6502 it just says BBC Micro, Atari 2600, Commodore 64, Apple II, and the Nintendo Entertainment System.

All in asm. Even in C was very rare.

You may find this interesting.

what about for the original gameboy or the turbo grafx 16? it doesn't say you can use 6502 it just says BBC Micro, Atari 2600, Commodore 64, Apple II, and the Nintendo Entertainment System.

The gameboy used the z80, another very popular 8 bit processor.

I don't know what the TurboGraphics used.

One should not forget that these game devices also came with a custom GPU that let you do things like sprites efficiently without much CPU load.

It was nothing like a modern GPU though.

And also, that assembler for an 8 bit processor is very much easier to handle then modern asm. You can fit the entire instruction set on a single page, and it was not uncommon to know the hex opcodes for all of them by heart.

And also, that assembler for an 8 bit processor is very much easier to handle then modern asm. You can fit the entire instruction set on a single page, and it was not uncommon to know the hex opcodes for all of them by heart.

True. I used to program the 6502 by hex code. Still remember a few instructions. That was fun, but a waste of memory today.

Only way to update the code was to replace buggy code with a jump to the first free memory, add corrected instructions, and then a jump back again. That was true spaghetti programming. My first game was a Asteroid look-a-like, but using character graphics.

I remember the day I could afford an upgrade of the RAM from 4K to 8K.

800px-Ohio_Scientific_Superboard.jpg

Wow, old memories coming back. I implemented my first programming language at that time, being a Lisp-look-a-like (implemented using the string functions in the built-in Basic). Didn't work very well, due to a memory management in the Basic interpreter that would eventually hang. I complained to the retailer, and they said it was "normal behavior".

It was possible to save the binary code to a tape recorder, but I don't remember the details.

[size=2]Current project: Ephenation.
[size=2]Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

Even C was almost unheard of until the Playstation/Saturn/N64 -- There was some on the Genesis*, but it was the only early machine that wasn't too register-starved, or otherwise limited, for contemporary compilers to be useful. Even with the option to use C, many devs clung to ASM for long after.

*The Genesis had a luxurious 16 registers in its 68000 CPU, the z80 systems like the Gameboy or master system had a workable 8, but word size, memory segmentation, and lack of memory was still a serious hurdle.

throw table_exception("(? ???)? ? ???");

They book I was thinking of is Core Techniques and Algorithms in Game Programming by Daniel Sanchez-Crespo Dalmau.

Looking back over it he just spends some time in the early chapters chatting about the chronology of game development. Most of the book after that ends up begin about 3D graphics stuff, though he does talk about a lot of different things on the way.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

This topic is closed to new replies.

Advertisement