Slashdot Mirror
Source Code of Several Atari 7800 Games Released
jadoon88 writes to share a series of old Atari 7800 games that have been unofficially open sourced. "Remember Dig Dug or Centipede or Robotron? They used to be favorites when Atari's 7800 series was still around. Since the era of those consoles is over, and a different world of interactive reality gaming has taken over, Atari has unofficially released source code of over 15 games for the coders and enthusiasts to admire the state-of-the-art (because this is what it was back then). During those times, nobody would have imagined in their wildest dreams the games that Atari's developers floated into the gaming thirsty market and instantly swept across continental boundaries. But things changed soon after that and a company once regarded as one of the most successful gaming console manufacturers and developers faded away in the pages of our technology's hall-of-fame."
Well this is really great and I thank them for finally releasing code from like 40 years ago but what does 'unofficially released source code' mean exactly???
Looks like 6502.
Anyway, source code is a bit of a misnomer here. All of these games were written in assembly, not any high level language. They are very well commented though, and it's more readable that most Python code I've seen...
I am TheRaven on Soylent News
... we see our first CERT advisory for a buffer overflow exploit in Dig Dug, leading to a remote execution vulnerability in your 'net-enabled MAME console.
This unofficial open source release signals that this will finally be the year of the cutting edge linux gaming platform.
A Magic the Gathering Article and Forum Aggregator
Should end in SPHINX.zip not Sphinx.zip. Beware the 404
Pain is merely failure leaving the body
You can be sure that the original arcade versions were written in assembly language not that different from what you see here. As a rule, nobody wrote video games in C until the mid 1980s. Assembly language was king.
I worked at a game software developer in the late 1980s, and all of the 2600 games, all of the 7800 games, all of the C-64 games, all of the Atari 800 games we developed or ported during the period were written in native assembly language. Only the Amiga, Atari ST, Macintosh, and the later PC games were written in C. NES and SuperNES games were written in assembly as well.
* From the devkit readmes:
;GO TO SELECT MODE ;LOOK AT FIRE BUTTON INPUT
;THESE FOUR LINES MUST BE INCLUDED IN ;REMEMBER ;REMEMBER,. . ., ROSEBUD
2600/7800 DEVELOPMENT KIT<br>
CARE AND FEEDING INSTRUCTIONS<br>
[...]
Feel free to telephone John Feagans at Atari (U.S.) at area code
(408) 745-xxxx any time you have a question about using the
software. He wrote the download program and the transfer rom
code. He's the one who did not write any support documentation
to go with his software.
* From the base sw:
CPX #1 ;HACK: WE STOP AT 1
BEQ SELRTS
INX ;BIGGER HACK: PUSH X INTO RANGE.
LDA ZHACKMOD+2,X ;BIGGEST HACK: TABLE LOOKUP NEXT MODE.
* Ofcourse, we have explicit words:
CMP #$FF ;SEE IF ANY INPUT
BEQ FUCKYOU
JMP GOTOSEL
FUCKYOU BIT INPT4
BMI ATIT4
LDA #0 ;ENOUGH TIME HAS ELAPSED TO ALLOW CAPS
STA $1 ;TO DISCHARGE SO CONTINUE FUCKING WITH
LDA #$14 ;IO HARDWARE
STA AUDC0,X ;GO POUND SAND IN YOUR ASS
* Citizen Kane anyone?
LDA INPT0,Y
;THE FINAL VERSION
AND INPT1,Y
BMI FUCKBAR
* In Galaga, at 'a boss hit':
JSR ABOSSHIT ; HOW YOU PRONOUNCE IT IS YOUR OWN
;BUSINESS
* Liek wtf?
* GROUND TARGET SECRET CODES (SSHHHH!)
* 0 regular dome logram
* 1 regular pyramid barra
* 2 detector dome zolbak (and your mama, too)
*And finally, an original comment which couldn't be more to the point in 2009:
*PROGRAMMERS BEWARE: THIS CODE IS OLD AND VERY UGLY! TAMPER AT YOUR OWN RISK
It looks like Hattrick is written mostly in Forth btw. I personally didn't know they wrote games in that language!
After 21 years, how many of them do you think are still alive...
No kidding. That would make them like 50 or 60! Quit being so ridiculous...
This guy's the limit!
Apparently Curt Vendel and Atarimuseum.com deserve the real credit for this release.
Seeing how it was done old-school is always refreshing. No C++, Java, C#, just hardcore assembly.
As an anecdote, I have a friend who used to work at MECC and worked on games for the Apple II like Oregon Trail and Odell Lake (find yourself a Way-Back Machine if you aren't familiar with those games). If memory serves me right, before leaving MECC, he wrote something akin to the following in one of those two programs:
[code]
; Important. Do NOT remove this. -- username
nop
nop
nop
; Proceed
[/code]
Years later it was apparently still in the code and he'd met up with an old colleague who asked, "What was up with the three nops? We didn't remove them because we didn't know what would happen". The response being, "Nothing, I just thought it would be funny to have this conversation a few years later".
Well, if my knowledge of history by way of Hollywood is any help, that's the portion of the game that if accidentally accessed by a kid renders him in control of our nuclear arsenal.
Looks like 6502.
Actually, it would have to be 65C02 or better. You couldn't do "ldx #$FF" on a 6502, you had to do "lda #$FF" and then "tax" (transfer A to X). The ability to load immediate into the X or Y registers was added on the 65C02. And, don't quote my on this, but I think the 7800 predated the 65816, so I suspect 65C02 is the right answer...
"Convictions are more dangerous enemies of truth than lies."
look, it's Ms Pacman
;MS RIGHT, HALF OPEN
DB $08,$00,$0A,$50,$A5,$54,$25,$D5,$17,$55,$15,$50
DB $15,$00,$15,$50,$15,$55,$05,$54,$01,$50,$00,$00
All the pixelfonts are in there too offcourse. If you're into remaking arcade classics, there's a lot of picture and sound data there just waiting to be recycled.
Okay, curse my failing memory, I believe I just "misremembered" that factoid. On the 6502, you couldn't push or pull X or Y from the stack, necessitating the cumbersome txa, push or pull, tax instead of simply pullings into the desired register. I don't recall now if loading immediate into X or Y worked on the 6502.
The scary thing is that I remember ANY of this shit over 25 years later...
"Convictions are more dangerous enemies of truth than lies."
Looks like 6502.
Actually, it would have to be 65C02 or better. You couldn't do "ldx #$FF" on a 6502, you had to do "lda #$FF" and then "tax" (transfer A to X). The ability to load immediate into the X or Y registers was added on the 65C02. And, don't quote my on this, but I think the 7800 predated the 65816, so I suspect 65C02 is the right answer...
I like compilers.
6502c, actually. It's a custom version of the 6502 that was integrated with various other system hardware and could dynamically adjust its clock depending on which memory address was being accessed. (That was how Atari gained 2600 compatibility, which was a custom 6507 chip.)
It sounded all well and good on paper, but the actual implementation of the processor was a serious PITA. If you weren't careful, you'd accidentally drop the speed to 1.19MHz and throw all your timings off. Even more annoying was that many functions required you to access hardware that dropped the clock speed. The worst offender was the TIA sound hardware because Atari was too cheap to install a POKEY chip.
Worse yet, the normal 1.79MHz was underpowered for the complex sprite hardware they'd paired it with. The sprite hardware basically processed lists of lists of sprites, requiring sophisiticated data structures to get good performance out of complex, fast moving scenes. And if that wasn't painful enough, you were wise to find a way to keep as much of the structure in ROM as possible so that you wouldn't blow through the mere 4K of RAM.
The 7800 was an interesting and potentially even useful design, but it simply wasn't practical for most developers. (Many of whom were not computer scientists.)
Javascript + Nintendo DSi = DSiCade
I quite like the way this blog by an old time Atari employee recalls the when and how of Atari developement. Something (Donkey Kong port on Atari consoles) that read
I should explain how Atari's Arcade conversions group worked. Basically, Atari's marketing folks would negotiate a license to ship GameCorp's "Foobar Blaster" on a cartridge for the Atari Home Computer System. That was it. That was the entirety of the deal.
made it clearer with :
We got ZERO help from the original developers of the games. No listings, no talking to the engineers, no design documents, nothing.
but, wait... there was even less:
In fact, we had to buy our own copy of the arcade machine and simply get good at the game (which was why I was playing it at the hotel our copy of the game hadn't even been delivered yet).
was for me a sure way to a plentiful of nostalgiaholic reading.
Al.
No, but whomever wrote that headline is making a common mistake. The use of the term "open source" tells us that "open source" is apparently no more clear to people than what that movement tried to supplant—free software. While "free software" has an ambiguity problem, that problem is easily resolved by saying the "free" refers to freedoms to run, share, and modify the software, not a reference to price. "Open source" is also widely misunderstood:
but not easily cleared up. As that essay points out, "the explanation for "free software" is simple--a person who has grasped the idea of "free speech, not free beer" will not get it wrong again. There is no such succinct way to explain the official meaning of "open source" and show clearly why the natural definition is the wrong one.".
From what I can tell, there's no permission given to share any of these programs, no permission to modify any of these programs, and no permission to distribute these programs commercially.
The blog poster claims "In an official release, Atari has quoted that the purpose of the release is to give potential developers insight into the Atari's gaming platform so they may possibly build upon the 7800 series." but there is no link to the official release from the copyright holder. Therefore the provenance of this source code is unclear. I would consider these programs to be neither open source nor free software. This looks like an offer to download source code for proprietary software then make the mistake of distributing unauthorized derivative works based on these programs. It might be fun to program new Atari 7800 games, but copyright lasts a very long time and there's too little information to verify what the blogger claims.
Digital Citizen
It indeed is packed BCD. Some processors of that time have special instructions for that kind of notation, which makes calculating with them not much more difficult than normal binary. (Dunno if the 6502c has these kinds of opcodes, though; the Z80 for example does.) The advantage is that it makes blitting to screen really easy: instead of constantly dividing by 10, which is a processor-intensive task, you could just bitshift the number, which is much easier.
Looks like 6502.
Actually, it would have to be 65C02 or better. You couldn't do "ldx #$FF" on a 6502, you had to do "lda #$FF" and then "tax" (transfer A to X). The ability to load immediate into the X or Y registers was added on the 65C02. And, don't quote my on this, but I think the 7800 predated the 65816, so I suspect 65C02 is the right answer...
BZZT! WRONG! Thanks for playing...
I have written hundreds of pages of 6502 code, on systems old enough (Apple 1) to have original MOS Technologies 6502s in them, and the "immediate" addressing mode (denoted by the # symbol in the argument) was DEFINITELY in the original 6502.
Don't believe me? Take a look at this listing of the (nearly completely unused) Floating Point routines that were included in the original Apple II monitor ROM. You will see an immediate load of the X register (LDX #$2) within the first couple of lines of code. This code was written by Steve Wozniak WAY before the Rockwell R65C02 was even on the drawing board!
What you MAY be thinking of is the fact that you couldn't load the STACK POINTER REGISTER (S) "immediate". You had to do a LDX #STACKTOP (usually set to $FF), and then use the TXS instruction to get the value into the Stack Pointer. This listing of Microchess (originally written in 1976 for the MOS Technologies KIM-1 computer, shows (at the label "CHESS" near the top of the listing) the LDX #$FF then TXS instruction pair mantra used to initialize the stack pointer on the 6502. The comment mentioning "Two Stacks" is referring to a software PSEUDO "stack pointer" (variable "SP2") that doesn't have anything to do with the 6502's hardware-implemented Stack Pointer (S register).
Now get off my lawn!!!