

- Applewin unable to capture print screen cracked#
- Applewin unable to capture print screen manual#
- Applewin unable to capture print screen software#
- Applewin unable to capture print screen code#
Applewin unable to capture print screen code#
Currently I am far too weak in 6502 to try to understand the code itself, just by reading it. The next step will be to establish which stretch of the code reads and writes certain memory locations, together with the particular addressing modes. Call trees from those compact subroutines are directed acyclic graphs, which in turn will help me understand the execution flow. Still, it has been possible to identify a bunch of "compact" subroutines: a contiguous stretche of executable 6502 code, leaped into the top by 1 or more JSRs, exit via normal RTS, no jumps from anywhere else into the middle of the stretches - what I would call a "subroutine" in the normal sense. The whole idea of statically analysing the 6502 code seems a bit flawed, or it has to be at least complemented with runtime info. mixing JSR and JMP), also PHA'ing different addresses and doing RTS more as a jump than as a return from subroutine.

So far that has turned out considerably more difficult than expected, mainly because of "subroutines" PLA'ing the return addresses from the stack (i.e. The immediate goal is to map the execution flow for this very first part of the game. * save/load complete state of 6502, memory, as well as Apple II display and softswitchesįor now I focus exclusively on the splash screen part of the intro section of the game, that's difficult enough for its 600 lines of disassembled 6502 code. * disassemble code with automatic labels and other leap info (who calls what) * collect info on memory locations (leap from/to info, touch counts etc.) * understand 6502 opcodes and addressing modes
Applewin unable to capture print screen manual#
* read relevant sections of the Apple II Reference Manual (Woz, 1979) The last couple of days I did the following:

I had to port ApplyPy to Python 3, but else nothing else was needed to do a "first light" with running Robotron from the ram image. Note that I am not interested in a high fidelity recreation of Apple II artefacts, nor execution speed - to achieve both I use the excellent. Reverse engineering generates a lot of data which has to be collected and correlated as easily as possible, which maybe makes the choice of using Python a bit more sensible. I think it is easier to learn a language with a good project and right now I can't think of any project being a better one than reverse engineering a 6502 game! Python knowledge is needed for a different project, expected to start towards the end of 2019. The starting point for the project was James Tauber's Apple II emulator ( ), written in Python.
Applewin unable to capture print screen software#
I have to be prepared that the inner workings of the software are pretty arcane and convoluted. This rule certainly applies here, becauseĪ) I basically don't know anything about the 6502ī) I owned an Apple II in the 80s but never understood the hardware.Īpart from those pretty damning constraints, Robotron is a pretty big game, with a lot of stuff happening on screen. There is 6502 source code available for the Williams coin-op system (where the game was officially launched) as well as for the Atari7400 and other platforms - but not the Apple II.įrom reverse engineering projects in other domains I know that it is never recommended to try to understand a target system completely. An added advantage which might come in handy at a later point in the project is that Robotron is a well-researched game. I chose Robotron 2084 as a target for reverse engineering because I play it reasonably well and have very fond memories. I don't know why I have finally decided to try this myself, maybe it was just a critical mass thing. Awesome! Since then it has always bugged me that I shied away from learning 6502 and diving into 8bit game design.
Applewin unable to capture print screen cracked#
Then, in school, there were 6502 wizards who not only cracked the copy protection on those games but were actually able to understand and change them. With the proliferation of really good emulators for the Apple II, I have recently been re-introduced to the games I played decades ago.
