The printout-and-highlighters method of reverse engineering was indeed common way back then. It became even more well known in 1982, when Don Lancaster wrote a book entitled Enhancing your Apple II. In it was a chapter on "Tearing into Machine-Language Code," in which he explained a method for using a disassembly printout and colored highlighters to quickly reverse-engineer machine code. This method soon spread beyond the Apple II community. For example, from a 1983 book review in Microcomputing Magazine:

    Software buffs are likely to vote for the 
    third chapter ("Tearing Into Machine- 
    Language Code") as the jewel of the 
    collection. It is a unique contribution that 
    applies to all machine languages, of 
    which Apple is only one. Possibly no 
    manual anywhere that describes the use 
    of disassemblers and techniques for ex- 
    tracting hidden code can equal this 
    60-page adventure in decryption. Pro- 
    grammers would do well to look into this 
    chapter to check on techniques they 
    might have missed; commercial software 
    vendors may want to know some things 
    that hackers do to defeat them. 

    Source: Microcomputing Magazine (October 1983) [1]

[1] http://archive.org/stream/kilobaudmagazine-1983-10/Microcomp...

Interesting... The Apple machines were pretty much unknown in large parts of the world outside the US, so I've actually to this date not even seen an Apple II in person as far as I'm aware, and didn't come across Don Lancaster's stuff until a year or two ago either.

Europe was dominated largely by Commodore, with Sinclair, and Atari and maybe Amstrad in "supporting roles" far ahead of the usual suspect of weirder machines for pretty much the entire 80's, until the PC finally got the upper hand.

The computer shops near me in the early 80's at one point or another probably stocked about 20-30 distinct home computer brands, but I can't remember seeing any Apple products at any of them until the Macintosh.

It's fascinating how the view of home computing is often so completely different from the US vs Europe as a result.

Australian, checking in. I first saw a Commodore Pet, then an Apple II shop, in Perth WA, around 1977 - 1982, competing with each other. Tandy had their TRS-80 shops too, but generally .. Apple II was the first "real PC" I remember seeing in the neighborhood of the late 70's. In the early to mid 80's, it was all C64 and Atari and Amstrad for games, pretty well mixed, but a lot of the richer-kids had big Apple II investments, even into the 80's .. and there were of course a lot of other clones in the arena, at that time, too.

Were there large import tariffs or something making it prohibitively expensive to get Apple computers from the US, or did Apple not market the machines internationally?

Countries such as the USSR and Brazil simply made their own Apple clones. I'd suspect Western Europe did not do so because of legal ramifications.

No it wasn't down to tariffs. Keep in mind Commodore did immensely well in Europe despite being a US company (though in name from some point in time it was a Bahamas corporation for tax reasons)

It was many factors I think.

Apple indeed was not set up to handle international sales well, while Commodore had a huge international channel owing to a much longer history (the progenitor of Commodore Business Machines was founded in 1954).

But all indications are that Commodore (and probably Tandy) outsold Apple substantially in the late 70's in the US too. At that point Apple got the "hacker" market, Commodore focused on the business market.

It wasn't until the VIC 20 that Commodore started aggressively going after the consumer market, but the VIC 20 was a low end product, and it was probably first with the C64 that Commodore had a product going after some of the same market as the Apple II.

At this point Apple increasingly was the expensive choice, and the European market was apparently a lot more price sensitive. On top of that Apple had much more aggressively pursued schools in the US, and so I guess US parents might have seen the Apple II as a more "serious" choice at a time when Commodore was increasingly getting associated with games.

Commodore thoroughly trounced Apple in worldwide sales of 8-bit machines and probably for quite some time in 16 bit models from soon after the introduction of the Amiga, but more and more of their output went to Europe for these reasons (eventually quite a lot of Commodores machines were also manufactured in Germany) but also because Tramiel quickly realized that the European markets were higher margins, and so any if supply couldn't be ramped up quick enough for certain models, Europe got priority.

Commodore also burned itself in the US, and its US dealer network, through extreme price war with Texas Instruments and Tandy (pushing things so far that TI pulled out of the market and posted massive losses, but also massively hurting Commodore's profitability - likely a major factor when Jack Tramiel was ousted) and the damage it did to its good will with its US dealer network probably shouldn't be under estimated.

(If you're interested in the Commodore/non-Apple view of the early home computer market, "Commodore: A company on the edge" by Brian Bagnall is a fascinating read)

You've triggered a flashback. I now sorta recall using different colored highlighter pens to denote different kinds of things: loops, jumps, data, etc.

Not to derail, but wow! Thanks for pointing out those old Kilobaud issues on TIA.

TIA is amazing. There's also these amazing sites worth knowing about for old computer magazines:

http://www.atarimagazines.com/ (Not just Atari stuff - also Compute! etc.)

http://www.bombjack.org/commodore/ (Mostly Commodore, but also some more generic 6502 oriented magazines)

http://www.atarimania.com/list-atari-magazines.html

Nasir Gebelli was a game programmer that created some of the classic early games for the Apple ][ (Space Eggs, Gorgon). He eventually went on to create Final Fantasy at Square.

When programming his games in 6502 assembly for the Apple, Gebelli used the built-in mini assembler from the command line. No text editor, and according to most accounts no printer either. All in his head, by hand.

I don't know the Apple mini assembler, but that sounds similar to what I meant.

Either we'd load a tiny "monitor" which is what they were typically called in the Commodore world at least, and you'd have a primitive REPL with commands like ".D C000 C100" to disassemble addresses 0xC000 to 0xC100 or ".A C000" to get a prompt with the address 0xC000 after which you could enter one instruction, press enter and have it instantly assembled and get the next address (with no support for labels). If you needed to correct something, you'd press enter to exit back to the prompt, type ".A [address to correct] [new instruction]" and hopefully you wouldn't need to alter the length of the instruction as then you'd have the fun task of remapping absolute addresses and copy the following code around.

Then when you wanted to test something, you'd do ".G C000" and hope your program didn't crash things so bad you had to load things back in...

Scarily enough it was common at least in demo circles to not even save before each test as it was too slow with a tape or floppy and so we just hoped we wouldn't lose changes too often from bugs overwriting our program etc.

Often not all variables might even be reinitialized on starting the program again either, and so the program might differ depending on test runs... When we saved the programs it was often just a raw memory dump of the locations we'd assembled stuff to... (e.g. .S "filename" C000 C3FF might save the 1K range from 0xC000 to 0xC3FF)

(I keep using C000 by habit, even after 25 years or so away from the C64 - 0xC000 to 0xCFFF was free space in between the BASIC ROM and memory mapped registers for the graphics and sound chips, and BASIC would not touch memory above 0x9fff, so putting stuff at 0xC000 was popular since you could e.g. load basic programs without wiping it)

The Apple II had a monitor you could reach via:

    ]CALL -151

and you could type a program such as:

    *300:AD 30 C0 88 D0 FD 4C 00 30

but while there was a disassembler (300 L) there was no assembler!

Fortunately, if you had Integer Basic, you could do:

    ]INT

to get to Integer basic, then go into that monitor:

    >CALL -151

then jump into the "mini assembler" inside Integer Basic:

    *F666 G

and now you're in something resembling an assembler:

    !300:LDY#$0
    !302:JMP$309
    !305:JSR$FDED
    !308:INY
    !309:LDA $320,Y
    !30C:BNE $305
    !30E:JMP$FF65
    !$320:48 45 4c 4c 4f 20 48 41 
    !$328:43 4b 45 52 20 4e 45 57 
    !$330:53 21 00
    !303G

  *300:AD 30 C0 88 D0 FD 4C 00 30

OWWW my ears! And I think you meant "4C 00 03" there. :)

Yup definitely. Good catch!

Nicely explained. And hello back at ya. (JSR $FF3A)

>I keep using C000 by habit

It's been over 25 years since I last programmed in Assembly on my Commodore 64 but I will never forget typing:

SYS 49152

Yes, the starting address of the 4KB of "protected" memory that we'd poke our assembler opcodes into. All us C64 programmers (loosely used term in my case, I was ten years old or so) have that address burned into our brains forever.

SYS 64738

Agreed. A symbolic assembler was just a convenient way of managing names and jump targets. To reverse engineer it wasn't too hard to write down the bytes and translate to symbols because the instruction sets were relatively simple and regular (unlike current x86).

It wasn't just the method he used, though. It was 512 pages of assembly, and he spent more than 6 months studying it. The amount of effort he put in is astounding.

It sounds a lot when put like that, but it's not 512 pages of dense text, but in terms of typical presentation, perhaps four hex character address, a three character instruction and an operand of <10 characters or so - he could've fit the entire thing on 64 double sided pages easily, maybe less.

Lots of people printed out games and other programs in the 32K-64K size range all the time and studied them for months. It's what we did to work with "large" code bases. I've written perhaps a dozen pretty printing programs for asm (including ones that would painstakingly download narrower fonts to our dot matrix printer to fit more columns....) exactly because I wore out large number of printer cartridges, printing out code and kept trying to get things printed faster and on less paper, and that was a pretty common pursuit.

Again, it's a lot of effort, and some of what he did shows a quite impressive level of dedication (such as dumping the eproms, building his own clone of the game, and fixing bugs the designers hadn't found), but actually printing out a code base that size and studying it to learn was quite normal.

I'm all for recognizing this guys effort, but not for the most mundane part of what he did.

In my days in the 80's, I had one of these:

http://www.old-computers.com/museum/hardware/Oric_Atmos_MCP4...

.. and used it as a general work-buffer for expressing routines and dumping assembly .. my parents called it my "bogroll homework" since I usually took rolls of plotted product to the head with me, light reading ..