After some time away I've been able to spend some more hours on the reverse engineering project.
The Apple II is severly constrained in terms of memory. Consequently, Robotron uses for the "cut scenes" the actual game code to display elements like the player character or enemies. From a reverse engineering point of view this is fortunate, because I can use the uncluttered (and even scripted) movements of elements on the start screens to understand how the game moves "sprites" around the screen. For an
example see the movements of the player character on the screen explaining the controls.
I've extended the read/write tracking of the workbench from my last post to project what's happening in memory onto the simulated screen. In the following pic you can see the "echo" of the beginning of the movement of the player character on the controls screen (i.e. what you see in the Youtube video, the character going from left to right first.)
Attachment:
control_move.jpg [ 19.69 KiB | Viewed 1542 times ]
Following the strategy suggested in my last post....
Quote:
The workbench is reasonably fast enough to allow "slicing" the total dataset into smaller pictures = containing less cycles. I should thus be able to drill down to seeing a particular sprite drawn on the screen (write) and relate the bitmap to it's origin (read).
... I can visually do a trial-and-error to constrain the shown range of cycle counts (which I use as global clock) until I only see one particular "frame" of the movement:
Attachment:
control_single.jpg [ 3.78 KiB | Viewed 1542 times ]
The workbench can now show me the corresponding reads from memory:
Attachment:
control_reads.jpg [ 5.17 KiB | Viewed 1542 times ]
The area between the horizontal lines is the video memory. The colors on the zero page (first line) show that there is some heavy indirect reading involved.
Looking at which code was executed between the shown cycle counts is of course necessary to understand what e.g. the memory related to the two green lines on the lower left contain: It's the actual sprite data, both for removing the first shown player character ("facing the camera")...
Attachment:
man1.jpg [ 9.57 KiB | Viewed 1542 times ]
... as well as one frame of the player character in movement to the right:
Attachment:
man2.jpg [ 9.39 KiB | Viewed 1542 times ]
From inspecting the code and what's in memory I've gleaned some first information about how the sprites are stored in memory (resulting in the crude X. displays above), in particular how multiple sprites are stored in order to make it easy to horizontally move the sprite pixel-wise through the bits in screen memory.
This part of Robotron is quite central to the overall gameplay. The code takes generalised sprites (i.e. different heights, widths and "facings") and projects them onto the screen, inside bytes and scattered across the video memory (due to Apple II ideosyncrasies). In addition, the code needs to track the state of the sprite, to cycle through e.g. the left+right movements of the legs (or pulsing shapes etc.), which also needs to take into account the direction of movement. The algorithm is much more involved than I had originally thought it would be. A nice challenge!