reverse engineering Robotron 2084 for the Apple II

[Chromatix]

Are your reverse-engineering tools available anywhere? I might try them out on the ROMs from a classic chess computer.

[fschuhi]

I'm sorry for having been away from the forum for so long, please excuse the late answer.

Chromatix wrote:

Are your reverse-engineering tools available anywhere? I might try them out on the ROMs from a classic chess computer.

Thanks for asking, no, I've not yet been able to upload anything to GitHub or the like, the workbench and it's various tools is much too disjointed to be of any use to anyone. I'll have to do a refactoring anyways as soon as I come back to the project (hopefully in September), so I might package it a bit better and upload it then.

[Chromatix]

Sure, there's no hurry.

I actually found some documentation about the chess engine design used by that particular author, and the small amount of manual analysis I managed to do seems to match certain details of that. It also looks like he's stuck to NMOS coding style, even though the machine uses a CMOS 6502.

[cjs]

I don't know if you're still working on this, many months later, but this thread certainly was an interesting read! I've got a couple of minor comments:

fschuhi wrote:

I've managed to understand some important subroutines completely, on my own, for the first time ever....

Code: Select all

$51e8  readNextChar  INC $22           ; next char in stash (after JSR)
$51ea                BNE L51ee         
$51ec                INC $23           ; stash can be > 255 bytes
                               
$51ee  L51ee         LDY #$00          
$51f0                LDA ($22),Y       ; load char from stash
$51f2                RTS               

That increment of the high byte is vital, and nothing to do with the length of the stash. If the stash crosses a page boundry, even if it's only two bytes long, the low byte will wrap around to 0 and, if the high byte is not incremented when that happens, you'll end up reading from an address 256 bytes less than the one you should be reading from. (And what you see above is of course the common idiom for 16-bit increments.)

Quote:

I've not yet been able to upload anything to GitHub or the like, the workbench and it's various tools is much too disjointed to be of any use to anyone. I'll have to do a refactoring anyways as soon as I come back to the project (hopefully in September), so I might package it a bit better and upload it then.

I wouldn't worry too much about the disjointedness or quality of the code; just get it in the repo, make sure there's a couple of lines of README that say what the repo is and link back to this thread, and worry about cleaning it up later. Having anything at all available for others to see is still much better than having nothing. And of course it serves as a backup as well in case your disk gets trashed or whatever.

Also, what can help with this is always to start out with an empty repo when you start on a project like this and commit at regular checkpoints when you've got something working. This not only lets you easily go back if you mess something up, and review your changes, both of which are useful even if nobody else ever sees the repo, but tends to make one (or me, at least) slightly more organized about what I'm doing. (In particular, this can make a project a lot easier to come back to after a couple of weeks or more off.)

[BigEd]

(Welcome, cjs, good to see your first post!)

[fadden]

There are a number of Apple II game disassemblies collected at https://6502disassembly.com/ (Space Eggs, Stellar 7, Elite, Caverns of Freitag, others). If you're not familiar with common ways to handle the hi-res screen, reading other people's code can be useful.

All of the disassemblies were done with SourceGen (https://6502bench.com/), a fully interactive 6502 disassembler that runs in Windows. I can highly recommend it, both as a heavy user and as the program's author. Being able to decode graphics and embed them in the listings was hugely beneficial when digging through Space Eggs (video: https://youtu.be/lSvEr5nCHbY). SourceGen is free and open-source.

[fschuhi]

cjs + fadden, thanks for adding posts to this dormant thread!

I intend to come back to the project, not soon but eventually, hopefully in the fall. I have a long reading list and also lined up a number of 6502 tutorials, so I should be able to make a bit progress when coming back to Robotron.

[fschuhi]

I've managed to upload the Python stuff covered in this thread to GitHub: https://github.com/fschuhi/Robotron_2084

It has been a while (actually more than 1 year) since I've suspended working on the project. It was never discontinued, though, just waited to be rekindled

I did some checks on the Python code today, but I've actually just added it for reference purposes. The main work currently goes into working with C#, namely Sean Fausett's https://github.com/digital-jellyfish/Virtu, more precisely the hex-ray branch of his collaborator Nick Westgate (https://github.com/sicklittlemonkey/Virtu/tree/hex-ray). The hex-ray feature is explained by Nick on https://www.youtube.com/watch?v=Ux4n5Z5E-Lo. This is pretty much what I did on Excel, but in real-time. I'll hope to make use of this feature in my Robotron project.

Nick is a frequent contributor to comp.sys.apple2 and the author of a mod of Robotron 2084 on the Apple (for 2 joysticks). He actually provided me with a partial disassembly of Robotron which I was able to compare with what I had - - a nice booster for the project!

Even before getting more those additional pointers into the code I had been making much progress using Andy McFadden's SourceGen (see the lasts posts here). With the Python workbench I did only disassembling along the execution path. As some of you pointed out it can be difficult to understand the workings of the code. Working towards a complete disassembly with SourceGen has brought me up to speed again.

Looking back at this thread, I have to say "thank you" once again to all of you folks here. Your comments, code snippets, and views on reengineering and 6502 programming helped to build momentum which was so great that it actually carried the project across a chasm of 2 years. I'm really grateful for your help.

Over the coming weeks (probably well into the fall) I will have to spend time on a day job which consumes much of my bandwith. Robotron will have to be sidelined, but I'll keep working on it from time to time as a nice distraction