Skip to main content

Posts

Apple2TC: an Apple II Binary to C Decompiler - Part 5

 This is part 5 in a series of posts describing Apple2TC.  The start is in  Part 1 . Part 4 described the Apple II hacks we had to deal with, in order to get the decompiled version of Applesoft BASIC working. This part is a quick update on getting two Apple II games to work - Robotron 2084 and Snake Byte. Robotron 2048 After all the effort we went through for the BASIC ROM, Robotron 2048 was shockingly easy. First, we ran a2emu to collect runtime data: a2emu --collect --limit=30000000 robotron.b33 > robotron.json In the emulator, the game title screen appeared, we eagerly pressed spacebar, getting us to the control selection screen, selected keyboard, and we were off. The game is pretty challenging, but we managed to play a little before dying and closing the emulator. With the so collected runtime data, first we decompiled the binary to 6502 assembler: apple2tc --run-data=robotron.json robotron.b33 > robotron.lst Then to C (with the "simple" backend): apple2tc --simpl
Recent posts

Apple2TC: an Apple II Binary to C Decompiler - Part 4

This is part 4 in a series of posts describing Apple2TC.  The start is in Part 1 .  In this part we finally get to the interesting part and describe the Apple II hacks we found while trying to run the decompiled version of Apple II BASIC. Running the Decompiled Code In the previous part we described our technique for generating a "Simple C" representation of the disassembled 6502 code. Now it is time to actually build and run the generated code! Using our a2io and decapplib libraries, it is trivial to link the generated Simple C code into an executable.  We started by decompiling and running the Apple II ROM code, containing Applesoft BASIC and Monitor, because its disassembled source is already available and heavily commented  (thanks to Andy McFadden ). We can "cheat" and look at the listing to check whether we are doing something wrong. Problem 1: Indirect Branches In our first attempt, we decompiled the ROM statically and used the Simple C backend to convert

Apple2TC: an Apple II Binary to C Decompiler - Part 3

 This is part 3 in a series of posts describing Apple2TC.  The start is in  Part 1 . In this part we get to actually generating some working C code. "Simple C" Backend As was established in the end of Part 2 , our jump tracing disassembler is successfully able to statically disassemble large portions of binaries given to it, generating a reasonable looking assembler listing. The problem is that there is no way to truly evaluate the quality of said listing - it looks reasonable, but we can't tell whether it is actually correct or complete, and most importantly whether it contains enough data to start working on decompilation to C. We could try to assemble it back into a binary and compare to the original, but that would be pointless because even a listing containing a sequence of byte values can be assembled correctly. DFB $AD, $ 34 , $ 12 ; This correctly assembles to LDA $1234, but is not really useful.   We need some way to execute  the disassembled code and ensure tha

Apple2TC: an Apple II Binary to C Decompiler - Part 2

This is part 2 of a series of posts describing Apple2TC. Check out Part 1 for an introduction. In this part we describe the different parts of Apple2TC. Apple2TC Components Apple2TC encompasses several sub-projects: id - a simple interactive assembler/disassembler/binary editor for quick exploration/patching during development. a6502 - a two pass 6502 assembler capable of assembling the Apple II+ ROM . a2emu - our custom Apple II emulator, feature complete with the exception of floppy disk support. apple2tc - our tracing disassembler/decompiler. a2emu and apple2tc are the two main components - one producing runtime data, the other consuming it. We will go into more detail about them, while just briefly describing the rest. id is a convenience tool for exploration and patching of Apple II binaries. It can load and save binary images, evaluate simple expressions, disassemble ranges of bytes or print them as words and bytes, or assemble individual instructions and patch bytes.  a6

Apple2TC: an Apple II Binary to C Decompiler - Part 1

This is a series of blog posts to serve as a log documenting my work on Apple2TC - an open source hobby project developed on GitHub:  https://github.com/tmikov/apple2tc . There are various interesting things that come up all the time and I thought it might be useful to record them for posterity. Part 2  describes the different components of the project Part 3 shows how we validate our disassembly by generating a working C representation of it. Part 4 shows the Apple II tricks we had to deal with to get to correct running code. Part 5 describes decompiling and running Robotron 2084 and Snake Byte. What is Apple2TC? Apple2TC is an open source project to decompile original Apple II binaries, mostly games, into understandable and working modern C code,  completely automatically  by analyzing the runtime behavior of the code via custom software emulation.  When we say automatically , we really mean it - Apple2TC is not intended to be an interactive disassembler like IDA Pro or Ghidra. Ou

You Don't Like Google's Go Because You Are Small

When you look at Google's presentations about Go, they are not shy about it. Go is about very smart people at Google solving very BIG problems. They know best. If you don't like Go, then you are small and are solving small problems. If you were big (or smart), you would surely like it. For example, you might naively think that printing the greater of two numbers should be as simple as std::cout << max(b(),c()) That is because you think small. What you really should want is: t1 := b() if t2 := c(); t1 < t2 { t1 = t2 } fmt.Print( t1 ) Isn't it much better? We didn't have to type all those extra semicolons that were killing productivity before. If you don't like it, you are small. If you wanted to extract an attribute of an optional parameter, you may be used to typing something like: a = p ? p->a : 0; or even: a = p && p->a You just make me sad because obviously what you really want is: a = 0 if p != nil { a = p->

The fallacy that WP7 is immune from the race to the bottom

People left and right are claiming that if Nokia had chosen Android, they would be one vendor amongst many competing on thinner and thinner margins, while WP7 somehow isolates them for that. As far as I can tell, that is now commonly accepted as truth. It is amusing how a fallacy turns into "common sense" when repeated enough times. In reality, of course, people don't buy operating systems. They buy phones, and they would not buy a more expensive phone if a cheaper one offered the same capabilities given comparable manufacture quality and design. This is such a simple and fundamental truth that it is almost unbelievable that it is ignored. Apple is always used as a counter-example, but in reality an unlocked iPhone costs about the same as any other high-end smartphone with comparable parameters. Granted, people will pay more for good design or even just a fancy logo, but the name of the OS running in the phone hardly even enters the equation.  In particular the notion