The first line invokes the Apple II "System Monitor", the second writes 3 bytes to memory at address $3F2 (the effect of which is to tell the computer to enter the Monitor whenever someone resets the computer from the keyboard), and the rest load binary files into different memory areas. I'm guessing it's all to build an image to be written to disk. (See [2] for more on the System Monitor.)
It looks like he used an Apple II as the development environment, which is straight forward since both machines use the same CPU. The .S files are assembled to 6502 object files. The "makefile" loads each object file to a specific area in RAM, then Download.o transfers the contents of RAM to a waiting Atari 800 via serial connection.
At Broderbund we used Apple II's to develop for both the Atari 800 and the C64. I worked on a cable and software for both ends so we wouldn't have to change systems. It is MUCH faster to develop on one machine, and test on another.
This is spectacular. I really wish more great old game developers would do stuff like this. Not having the source code to the greatest games of our time is like having only half of the bible, or War and Peace. Or only half of Snowcrash or Neuromancer. Imagine!
Bill's also not the only developer who has this stuff in the garage. I think the IP rights are just tricky to deal with, so few developers are comfortable dumping this stuff into github yet.
I totally agree! I'd love to see the source code for the original Rollercoaster Tycoon, for example. From what I understand, it's 99% assembly with a few parts in C to handle media. It would be awesome to try to grok that!
For assembly, comments are more like the audio track for a drama, rather than directors' commentary. Sure, without them, you can see when entities are happy/sad/angry, but you have no idea why those things happen.
Reading foreign assembly isn't that bad unless it is being intentionally obscured. It definitely takes time to decipher things but at the same time you really learn what's going on :)
There's some nifty tricks that Budge did in the code. Just looking at this, for example:
LDA (PARAM),Y ;JUMP TO SELECTION
STA DOMNU6+1
INY
LDA (PARAM),Y
STA DOMNU6+2
DOMNU6 JMP $FFFF
Instead of creating a 16-bit lookup table and doing an indirect indexed branch (which I can't even remember if you can do on a 6502), Budge just modifies the code inline and lets the jump happen naturally. Very nice.
This is probably the most common way to handle jump tables on the 6502. If you're writing ROMable code you'll have to use indirect jmp (vector) instead of selfmod. It's more efficient to split the jump table into two halves though, with the LSB in one table and the MSB in another, and access it like so:
lda param_lo,y
sta vector
lda param_hi,y
sta vector+1
vector = * + 1
jmp $5e1f ; dummy address, written with selfmod
Wow, I spent a lot of time with this game when I was eight or so. Brings back the memories. I'm pretty sure my Atari 800 is still in my parents basement. Just need to find a TV I can hook it up to...
Same, but on the Apple II version. I remember making Rube Goldberg like pinball layouts where the ball would be guided through all sorts of paths and down to where you'd only have to hit it with the flipper every once in awhile.
Pinball Construction Set, Spy's Adventure in North America, Robot Odyssey. So many classics on the Apple II that were fun and educational.
I basically learned college level circuit design by playing Robot Odyssey as a child. For those curious, here's a part of a Let's Play trying to solve one of the earliest puzzles in the game:
Looks like a MOS Tech 6502? Seems pretty similar to a Zilog Z80. 8 bit processor with a 16-bit PC, though seemingly without the 16-bit paired 8-bit registers.
Agreed, I had a Z80 card in my Apple II and they are very different. I found assembly on the 6502 a little easier but the Z80 allowed me to run CP/M and that opened the door to a tone of SW.
Also code space. The cartridges I wrote typically over-filled the code space by a factor of 25 percent, whereupon you crunched.
Usually you wound up with a handful of bytes free. One cartridge I did had 6 bytes left, and another one had less than 20 and I was trying to think of something cool I could do with 20 bytes.
This is cool. Not so sure about the practice of committing object files to source control, but I guess it makes sense in a "the more, the better" kind of way, at least.
As a side note, I must say that as a former (contracting) developer at an EA studio, it's a very interesting feeling to see the programmer (the programmer, as in "the one") of a recent release sit next to EA's boss and talk about the title.
Things have certainly moved on a bit, since then. :)
This is great! I really wish there were a developer commentary track that you could listen to as you read the source code. Would be really cool to hear what they thought about with specific routines, or neat hacks they used to make things work in small memory footprints like that.
Just for whatever it's worth (I assume you know this, but for the class): with no explicit statement, the default in US and EU is "all rights reserved".
True. And yet: the author has overtly placed it in a public place normally understood to be for sharing.
At the very least, people can reasonably assume an implicit permission to do the usual things that are done with Github public repositories: fork at Github, create local copies, create derivatives with the intent of sharing back to the original, etc.
And, if he's using Github's free plan, that's only available for projects that are "open source", a term with a fairly well-understood meaning in our profession. So he's likely also implicitly represented to Github that whatever the formal license, it qualifies as 'open source'.
The author could be confused. It could be a trap. He could probably withdraw any of these implicit permissions by taking the right explicit future steps.
But in the meantime, people don't have to fear normal copying and sharing based on a default 'all rights reserved' assumption. It's probably OK, and even if the author changes his assertions later, penalties for copying during this 'implied consent' period are unlikely.
Is there something in the Github TOS that suggests that? Because otherwise I think your beliefs about people's reasonable assumptions are the opposite of true.
Although I agree with you that his intentions are probably not at this point to take advantage of his copyright on the code. :)
If the author is using the free plan, Github's 'plans and pricing' indicates that's for 'open source' projects.
As far as I can tell, there's no way to turn off a 'public' Github project's download, fork, and pull request functionality. Indeed, those functions are emblematic of the service, and they're meaningless without grants to make copies and republish derivatives far beyond the legacy all-rights-reserved defaults of legislative copyright law.
IANAL, but placing code on Github, where those features are mandatory and expected, looks like an overt act authorizing related copying and modification — an 'implied license' — even without the explicit grants provided by a formally-expressed open source license.
You are definitely wrong in your 'definitely' assurance.
Someone absolutely can get implied permission, from either a physical property-holder or IP rightsholder, when the owner's actions (or even non-actions) are reasonably interpreted to have indicated mutual assent. or created a 'constructive agreement'. or simply waived some rights (modifying the 'all rights reserved'). Some examples of relevant legal principles:
It gets murkier in copyright law, because legislation has often been crafted to supercede common law and court precedents.
But these are still potent issues; for example, Google's lawyers sought a summary judgement against Oracle on many of these 'equitable' grounds, based on Oracle's public statements and actions.
Also, the idea of an 'implied license' was a central defense used by those sued by copyright troll Righthaven. (The Righthaven entity has now lost cases right and left, and is facing sanctions for its legal misconduct: http://righthavenlawsuits.com/.)
So it's not just that Bill Budge won't sue. It's that if he did, and asserted that his intent was always 'all rights reserved', he'd almost certainly lose. Defendants would have a strong, perhaps ironclad argument that upload to Github was implied permission for lots of copying/reuse/modification. (That is, you can't put something into a world-readable folder that by custom means "download, share and improve me" – and then assert that's not what you wanted people to do.) And that goes doubly if Budge is on the free plan, that's reserved for 'open source' projects.
When informing people about the letter of copyright law, and the maximal interpretation often asserted by rightsholders and literalists/authoritarians, it's important to also communicate how copyright law is really practiced and interpreted by the courts, and reasonable people. Many of our era's emblematic companies and services -- including Github, Google, YouTube, and blogging -- absolutely depend on the more liberal, fuzzy, implied-permissions and reasonable-balances practice of copyright law.
[1] https://github.com/billbudge/PCS_Atari800/blob/master/Disk1/...
[2] http://apple2.info/wiki/index.php?title=System_Monitor#Gener...
EDIT: added additional details