6 ms·

That was absolutely crazy. He decoded a 48K assembly program on paper, while working as a security guard? Just amazing.

kryten 13y ago
My father in law is a security guard for a private company. He watches DVDs for 7 hours a day on a laptop and goes for an amble the other hour. That is the entire job. If only he put some of that time to better use like that kid did. It's not amazing, but a good use of the time.
joezydeco 13y ago
In the early days of game piracy on computers like the Apple ][, people hand-disassembled the copy protection schemes to understand how they worked and develop workaround patches. Granted, it's a lot easier to get to the object code on an Apple ][ than it was on a Williams Robotron. Harder still when you don't have documentation about the specific I/O ports on the hardware and other things like the blitter chip.
vidarh 13y ago
I don't want to diminish what he did, but consider that this was one of the most common methods of learning assembler programming in depth in that era. Most books on the subject were relatively primitive in the context of games and demo programming, and so if you didn't want to lag behind, you needed to figure out techniques by studying disassembled programs. (EDIT: Just to add that this is in reference to the disassembling bit. Pulling eproms to dump them and studying them so intently you start to fix bugs the game designers hadn't managed to solve is certainly dedication well above the typical level) Many large demos at least for 8-bit computers, and quite likely some games too, were written even without a symbolic assembler, but instead entered using a simple machine code monitor (think just one step above debug.com on MS DOS, and decidedly more primitive than programming directly in gdb...) using hardcoded address references instead of labels. I'd actually been programming on the C64 for a couple of years before I got an assembler that supported labels that was good enough to use (I had some before that, but they wasted too much memory and/or were too slow to seem worth it) and from people I met I gather that's a fairly common experience.
- joezydeco 13y ago
  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.
  - vidarh 13y ago
    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)
    - 300bps 13y ago
      >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
Jare 13y ago
That's how me and my brother learned to program graphics and games as 14-year olds. We disassembled over 50% of Manic Miner on the Sinclair Spectrum using an hex-to-opcode sheet, lots of pen and paper, and oh yes tracing lines along the jumps. Fun times! (I continued ripping apart many other Spectrum games, but with actual disassemblers) All it required was: free time, motivation and, above all, a mind free of assumptions and structure, ready to learn and be filled no matter the effort.
sehugg 13y ago
Compare that to Tom Skelly, lead programmer at Cinematronics (80s vector games) who had to reverse engineer an abandoned custom CPU design while writing games for said CPU in machine code on legal pads. http://www.dadgum.com/halcyon/BOOK/SKELLY.HTM http://www.dadgum.com/halcyon/BOOK/SKELLY.HTM It's amazing what you can do when you're focused.
- joezydeco 13y ago
  The most amazing part about the Cinematronics/Vectorbeam games is that they had no CPU in the form of a microprocessor. It was all common TTL gates wired up into a simple processor architecture.
VladRussian2 13y ago
(25 years ago) the first and hardest step was to get the hex memory dump printed (the amount of pages to be printed required escalating of one's permissions to "operator" level) and physically get the said printout into your possession - depending on the situation one could try to charm the girl "operator on duty" in the university department datacenter or one could divert her attention in some other way while one's partner will try get to the printer ...
mtm 13y ago
I can remember using 'ddt' to rummage through the code for WordStar (I think) on my old Kaypro back in the early '80s. It really caught me of guard when somewhere deep in the middle of the disassembly I ran into some chunk of data that said "Nosey, aren't you?"

My father in law is a security guard for a private company. He watches DVDs for 7 hours a day on a laptop and goes for an amble the other hour. That is the entire job. If only he put some of that time to better use like that kid did. It's not amazing, but a good use of the time.

joezydeco 13y ago

In the early days of game piracy on computers like the Apple ][, people hand-disassembled the copy protection schemes to understand how they worked and develop workaround patches. Granted, it's a lot easier to get to the object code on an Apple ][ than it was on a Williams Robotron. Harder still when you don't have documentation about the specific I/O ports on the hardware and other things like the blitter chip.

vidarh 13y ago

I don't want to diminish what he did, but consider that this was one of the most common methods of learning assembler programming in depth in that era. Most books on the subject were relatively primitive in the context of games and demo programming, and so if you didn't want to lag behind, you needed to figure out techniques by studying disassembled programs. (EDIT: Just to add that this is in reference to the disassembling bit. Pulling eproms to dump them and studying them so intently you start to fix bugs the game designers hadn't managed to solve is certainly dedication well above the typical level) Many large demos at least for 8-bit computers, and quite likely some games too, were written even without a symbolic assembler, but instead entered using a simple machine code monitor (think just one step above debug.com on MS DOS, and decidedly more primitive than programming directly in gdb...) using hardcoded address references instead of labels. I'd actually been programming on the C64 for a couple of years before I got an assembler that supported labels that was good enough to use (I had some before that, but they wasted too much memory and/or were too slow to seem worth it) and from people I met I gather that's a fairly common experience.

joezydeco 13y ago
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.
- vidarh 13y ago
  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)
  - 300bps 13y ago
    >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

Jare 13y ago

That's how me and my brother learned to program graphics and games as 14-year olds. We disassembled over 50% of Manic Miner on the Sinclair Spectrum using an hex-to-opcode sheet, lots of pen and paper, and oh yes tracing lines along the jumps. Fun times! (I continued ripping apart many other Spectrum games, but with actual disassemblers) All it required was: free time, motivation and, above all, a mind free of assumptions and structure, ready to learn and be filled no matter the effort.

sehugg 13y ago

Compare that to Tom Skelly, lead programmer at Cinematronics (80s vector games) who had to reverse engineer an abandoned custom CPU design while writing games for said CPU in machine code on legal pads. http://www.dadgum.com/halcyon/BOOK/SKELLY.HTM http://www.dadgum.com/halcyon/BOOK/SKELLY.HTM It's amazing what you can do when you're focused.

joezydeco 13y ago
The most amazing part about the Cinematronics/Vectorbeam games is that they had no CPU in the form of a microprocessor. It was all common TTL gates wired up into a simple processor architecture.

VladRussian2 13y ago

(25 years ago) the first and hardest step was to get the hex memory dump printed (the amount of pages to be printed required escalating of one's permissions to "operator" level) and physically get the said printout into your possession - depending on the situation one could try to charm the girl "operator on duty" in the university department datacenter or one could divert her attention in some other way while one's partner will try get to the printer ...

mtm 13y ago

I can remember using 'ddt' to rummage through the code for WordStar (I think) on my old Kaypro back in the early '80s. It really caught me of guard when somewhere deep in the middle of the disassembly I ran into some chunk of data that said "Nosey, aren't you?"