Find the rom. Open the file in a hex editor. There's the source code. Now all you have to do is get ahold of that cpu's code book to translate all that machine code. Sounds like fun.

Unfortunantly it is in hex. Not the natural language it was in. SO if u like hex u'll like a hex editor. However u can get some programs to convert over the code however these raerly ever work.

Well, depending on the CPU(s) that a game was developed for, you MIGHT be able to find a disasmbler that can take those hex values and rebuild the ASM code from that. However, you won’t have any intuitively named variables or comments in the output.

The closest thing I have done like this is examine a NES opcode output, so YMMV.

Arcade machines use the same cpus as most other machines, so you can use the same disassemblers. In fact it is usually even easier than disassembling a regular home computer game since the memory maps tend to be much more strictly defined making it easy to determine what is code and what is graphics.

E.g. Space Invaders uses an 8080 (like a z80 with only the first instruction page, and not even a fully populated one at that), all of the Atari/Williams machines use a 6809, although the vector ones have a custom maths processor which you'll want to be aware of, later 16bit machines are almost universally Motorola 68000 devices, its only in the 32bit era when things become a little more complicated and you start encountering sh2s and so on. Which I think are in the Sega Saturn, but not much else.

Keep in mind most of these will only disassemble to Assembly! There still will be no if statements or whatever, and you'll have to know the opcodes and architecture of the chip to understand it all...

If you want the source code, contact the developers...

Marcello

You can also go to www.motorola.com to get information on their chips.

68000 family programming reference manual

You'd expect those pioneers to work quite closely to the hardware, which distinguishes them from the great majority of Allegro users.

So BladeNick == Vegeta and Kablammyman == Goku ? Or is it the other way around? Or are they both Goku? Or are they both Vegeta? Its so hard to tell the difference between the two in super sayan...

The real crazy stuff was the Atari 2600 were the programmers had to interrupt the raster scan line to get pixels in about 1k. How the heck do you make a game like that? Even space invaders, sheesh. Defender was the first game to use bit blits.

dbz is soo lame.

Marcello

Well, the Atari 2600 has only a single scanline 'framebuffer', and at that only stores half the scanline with options to repeat it or mirror it. Therefore you have to use interrupts if you want an even slightly complicated display, but this is all only intended to be the background. On top of that are at least a couple of hardware sprites and a couple of hardware 'bullets' (read: small sprites with hardware collision detection on all other sprites). So, for example, combat is only having to negotiate with the freaky framebuffer to draw the map on which your tanks are sitting, the tanks themselves & their shots are handled by the custom sprite hardware. Naturally you can also change sprite details as the display draws to achieve two sprites per scanline rather than per frame.

Of course, Space Invaders would still be a problem with this setup.

It was the first game to use hardware for bit blitting, putting it years ahead of all the people who come on here and go on about mode 13h and optimising their sprite drawing via inline asm. But many earlier games used a frame buffer and deposited their sprites in that rather than some sort of restricted tilemap/sprite system. Certainly Space Invaders uses one...

I think it was a 6507 just over 1Mhz!

As far as I can remember it was a 6502 at 1mhz. The 2600 was a worse version than the atari 800 series of computers and the the 7600 was a better version.

But the Atari 800 had CTIA and GTIA modes. The CTIA modes provided two 320 x 240 1 bit screenmodes (one character based and one pixel based). It also had four colour modes (of which there were four different combinations). In the character mode you could also draw the character with one bit set which resulted in one of the colours being substituted with a 5th colour.

The GTIA mode introduced two 16 colour modes (one luminance based and the other hue based) which had a resolution of 80 x 240.

The display hardware could hardware scroll as well as do palette changes for every scanline (though this was probably done in software).

It has 4 sprites, each 8 bits wide (with a choice of three horizontal sizes, x1, x2 and x4) However the height can be any size that fits on the display.

These 4 sprites could also be drawn in a special mode which averaged colours with any overlapping sprites.

Finally it could draw 4 Missile sprites which used the same colours as the 4 Sprites but were only two bits wide.

I programmed a fair bit on the Atari.. It was a different kind of programming when you had to work with character sets rather than bitmaps. The good thing was you could switch character sets and have any gfx automatically animate (even if the entire screen was filled with them).

Remember the diagonally scrolling background pattern in the title screen of Boulderdash?