Disassembling 2600 Games?

[tschak909]

DEBRO: Maybe Basketball.. I was always impressed how the AI worked in that game, to provide something that was consistently fast paced and playable.

 

-Thom

[DanOliver]

Here's a mind tweak...I don't think the 2600 is difficult. Takes what, a hour or two to read the entire spec. In a day or two you can have most 6502 op codes and 2600 registers fairly well memorized. The difficult part, what makes the 2600 so intriguing, is using that simple hardware to create something as complex as a game. Modern systems flip that. Takes months to begin to learn things like Unity, OpenGL or whatever, plus the hardware. Once learned getting a game on screen is easy although time consuming.

 

That's what makes the 2600 so fun to me. Easy to learn, impossible to master.

[tschak909]

Can not agree more! I love the fact that I can keep the entire instruction set in my head, and that the registers basically can fit on one page as well, the whole mental map of the machine and its states are literally right there, and that's what makes it so much fun to code in...While I code a lot in modern systems, with huge libraries and operating systems, and I enjoy doing so, there is something _very_ special about going right down to the metal...it was my second step after Atari Basic (the Atari Assembler/Editor cartridge)...mostly because that was what was easily available and people weren't doing C on 6502s really...nor that much Pascal (unless you count Apple's port of UCSD p-system)...and as I figured out, it was simultaneously so much faster than BASIC, and at the same time, the only way you could have the time to do certain things...

 

I love that the entire instruction set can fit on a reference card:

 

 

and that the TIA registers can fit on a single page:

 

 

There is almost no other game system like this, to program for, as they add increasing amounts of abstraction.

 

-Thom

[DanOliver]

And entire RAM variable map on one sheet of graph paper.

 

I started in AppleSoft Basic, a game, and quickly hit the performance wall and switched to Assembly but didn't get far before hiring out. Back in those days high level languages had a bigger performance hit than today so switching to Assembly didn't have a negative stigma it would later. And today Assembly is so out of the question for almost everything. Not sure that's such a good thing. Some programmers I work with today seem to be rather unaware there's any hardware at all, that memory is infinite and see no problem with a 300 MB app when 1 MB would have been enough. State of software today depresses the hell out of me...hate to use anything new it's so bad. Programming for the mob and the mob don't care. I watched a panel of current day programmers/game designers saying this same problem is infiltrating current games. Holding users hands through the entire game, making games super easy, in order to appeal to the mob. Games for gamers might be going away.

[tschak909]

And entire RAM variable map on one sheet of graph paper.

 

I started in AppleSoft Basic, a game, and quickly hit the performance wall and switched to Assembly but didn't get far before hiring out. Back in those days high level languages had a bigger performance hit than today so switching to Assembly didn't have a negative stigma it would later. And today Assembly is so out of the question for almost everything. Not sure that's such a good thing. Some programmers I work with today seem to be rather unaware there's any hardware at all, that memory is infinite and see no problem with a 300 MB app when 1 MB would have been enough. State of software today depresses the hell out of me...hate to use anything new it's so bad. Programming for the mob and the mob don't care. I watched a panel of current day programmers/game designers saying this same problem is infiltrating current games. Holding users hands through the entire game, making games super easy, in order to appeal to the mob. Games for gamers might be going away.

 

Yup...agree with all these points, as well.. It _scares_ me how few programmers today actually understand the very hardware they target, beyond a very abstract "this platform has X, Y, and Z". Although there is hope, I had a 20-something programmer ask me the other day, "how do I use bitwise operators?"

 

-Thom

 

(and yeah, Assembly today is nigh impossible on modern CPUs... VLIW and extreme pipeline designs killed the possibility of hand-written assembly being better than the RTL output of a compiler...)

Edited August 27, 2016 by tschak909

[Thomas Jentzsch]

(and yeah, Assembly today is nigh impossible on modern CPUs... VLIW and extreme pipeline designs killed the possibility of hand-written assembly being better than the RTL output of a compiler...)

That's exactly why I stopped coding for x86 with Pentium II (I did some optimized code for Fractint) back then.

[enthusi]

There are still some exceptions,like NEON extensions in ARM assembly.

[DanOliver]

 

Although there is hope, I had a 20-something programmer ask me the other day, "how do I use bitwise operators?"

I guess the hope part is they had heard of bit operators? Head in hands.

[tschak909]

...........................yeah.........................pretty much..........but I obliged him, and gave him a 30 minute chalk talk on how to use them from C and why. He did understand, and some lightbulbs turned on in his head...so...I guess that's good. :/

 

(the irony? he was the college educated one of us both. I am entirely self taught.)

Edited August 27, 2016 by tschak909

[+splendidnut]

I remember, in one of my senior year computer science classes, being the ONLY person in my class to successfully complete the homework because I was able to use the standard C library to read an input file for the homework program. Who makes it that far without ever having to use file I/IO? :/

Edited August 28, 2016 by splendidnut

[+splendidnut]

Granted... I entered college already knowing how to program in C, Pascal, and x86 Assembler.

[Mr SQL]

 

Wow! I missed that thread. Some people really have no shame...

Even a simple binary comparison between "The Shaman" and "Fire Birds (PAL)" only shows about 250 different bytes. A quick look at the disassembly in the Stella debugger and you can see that apart for a timer value (for scanline count) the remaining differences are only colors and graphics tables!

 

I don't use the debugger.

 

I did think it was cool that Spice wrote a public domain game back in '89 - does anyone have more info on it?

 

Tom and Rev already posted they are new to the retro programming scene, how about you - did you release any games in the 80's?

 

Just an idea, but instead of putting on aires and pointing fingers at programmer adepts from the past why not do something challenging and more fun like learning how to program without the debugger, and specifically how to program without looking at other peoples code if you take such exception to it?

 

Dan couldn't have said it any better than Nolan's Mantra - for an engineer programming the VCS is the ultimate Atari game - easy to learn, difficult to master.

[Trebor]

I did think it was cool that Spice wrote a public domain game back in '89 - does anyone have more info on it?

 

Besides the information posted by Darrell in this post, which states in the article column posted the game is called 128 Invaders, there is also this post from the Commodore 128 forum.

 

Really some high praises over the game. Detailed description and download available here.

 

Nearly 30 years later and he's still knocking it out of the park with his excellent programming skills.

 

BTW, the year was 1988, not 1989.

[Mr SQL]

 

Besides the information posted by Darrell in this post, which states in the article column posted the game is called 128 Invaders, there is also this post from the Commodore 128 forum.

 

Really some high praises over the game. Detailed description and download available here.

 

Nearly 30 years later and he's still knocking it out of the park with his excellent programming skills.

 

BTW, the year was 1988, not 1989.

Awesome! I like the screenshots and the description, I'll have to try this one in the emu (I only have a C64). imo this is the kind of stuff we should share

 

You're right it was '88 - Greg had posted earlier on that thread (before it got creepy) about one of my text adventures and a book being rereleased in a new edition by Falsoft back in '89 after I had left the scene.

[tschak909]

A question for the Stella/Distella masters: How can I mark a section in my source code explicitly as playfield or player graphics? Stella isn't quite figuring it out, and the OCD part of me is making the ganglia behind my left eye twitch.

 

-Thom

[alex_79]

I'm surely not a "master", but maybe I can help
You can use distella directives GFX (for players graphics) and PGFX (for playfield).
for example

PGFX $F800 $F81F

defines the area $F800-$F81F as playfield graphics.

You can type them directly in the debugger prompt or put them in a configuration file.
See the debugger doc (the part about distella configuration files is towards the end of the page.
http://stella.sourceforge.net/docs/debugger.html

Edited August 28, 2016 by alex_79

[MacrosCode]

That's exactly why I stopped coding for x86 with Pentium II (I did some optimized code for Fractint) back then.

 

I agree! With todays CPUs this is no more real fun!

 

Also it is impossible to control the hardware directly. You only have the API of the driver.

And not to forget: Hardware changes so fast you don't have the time to invent special tricks.

When you are familiar with some hardware, then it is obsolete because of a newer one!

 

Cycle exact coding... Racing the beam by counting the cycles... Rasters by switching backgound color...

On todays hardware? - Forget it!

Edited August 28, 2016 by MacrosCode

[MacrosCode]

I reverse engineer 2600 games as a past time hobby.

 

Also, is there anything anyone wants to see?

 

Is there a disassembly of H.E.R.O.?

 

Would be glad to take a look behind the curtain.

Edited August 28, 2016 by MacrosCode

[Thomas Jentzsch]

Is there a disassembly of H.E.R.O.?

AFAIK not.

 

And I would like to see that one, too.

[DanOliver]

I

 

 

I agree! With todays CPUs this is no more real fun!

 

Also it is impossible to control the hardware directly. You only have the API of the driver.

And not to forget: Hardware changes so fast you don't have the time to invent special tricks.

When you are familiar with some hardware, then it is obsolete because of a newer one!

 

Cycle exact coding... Racing the beam by counting the cycles... Rasters by switching backgound color...

On todays hardware? - Forget it!

I take a different view only because I like to. Modern CPUs are more complex than a 6502, but they're still CPUs. I'd say there are even more tricks, a lot more, that can be done in Assembly.

 

And we can certainly write drivers. Yes, hardware changes...true of the 2600 too. It's heyday was what, 4,5,6 years?

 

Racing the beam is fun. But so is dealing with pipelines, caches, multi-cores, etc... Basics are easy to learn by debugging in Assembly and seeing what tricks the compiler is doing.

 

But yes, to what end. Most programs are so large these days and CPUs so fast it would be hard to even measure a speed improvement. I do still like writing apps that are small in size for what they do. Pretty easy too. And I think there's some value there. Less code = easier to maintain and tweak, faster downloads, faster builds.

[Thomas Jentzsch]

Modern CPUs are more complex than a 6502, but they're still CPUs. I'd say there are even more tricks, a lot more, that can be done in Assembly.

True, but IMO the effort is absolutely not worth it. Multiple cores, each with multiple execution units which all have their limitations, multi level caches etc. pp . And from generation to generation the parameters change.

 

Yes, it is possible to write code for those, but without excessive time investment, it won't be any better than modern, optimizing compilers (e.g. from Intel).

 

When I did my Pentium II code for Fractint, this complexity just started. I extensively studied Agner Fog's documentation, but it turned out almost impossible to get the expected throughput. The effective cycle count hardly matched the optimum I wanted to achieve. There were always some extra cycles. The reason was some CPU internal unit, which was overloaded. I had to rearrange to code quite weird to get the best possible results. IIRC with Pentium III Intel fixed that. But one bottleneck removed, meant the next bottleneck showing up.

 

Overall, the code turned out very fast, shaving off a cycle or two from the previous best optimized code. But getting there was a nightmare. Only the competition with some other guys made me do it.

Edited August 28, 2016 by Thomas Jentzsch

[Nukey Shay]

 

Is there a disassembly of H.E.R.O.?

 

Would be glad to take a look behind the curtain.

One I did some years ago to add invincibility and God cheats to. Not much commented because those were the only requests.

Hero.asm

[DEBRO]

Hi there,

 

I didn't think this thread would get this much traffic.

 

DEBRO: Maybe Basketball.. I was always impressed how the AI worked in that game, to provide something that was consistently fast paced and playable.

 

-Thom

 

I'll get back to that one. This is one I started and hadn't touched in 12 years.

[tschak909]

Hi there,

 

I didn't think this thread would get this much traffic.

 

For me, disassemblies are how I am learning, and annotated disassemblies are gold. You are helping me be able to accomplish something that I've wanted to do for almost two decades (which suddenly got charged into action when a game idea burst into my head, fully formed.),

 

and for that, Thank you.

 

-Thom

[DEBRO]

Hi there,

 

I'm cleaning up some of my other disassmblies.

 

Looking at Superman (which I never truly completed), I'm having difficulty describing or labeling the rooms. The Daily Planet is easy but how would name the other rooms or scenes? Any ideas what to call them?