i***@gmail.com
2018-01-27 06:06:59 UTC
As noted elsewhere, I'm taking on disassembly and documentation of the Apple II Desktop (a.k.a. A2D, a.k.a. MouseDesk) graphical shell for the Apple II.
Code and documentation are at: https://github.com/inexorabletash/a2d
Goals:
* Get the code fully documented
* Get the code buildable with changes (i.e. no hard-coded addresses except documented entry points)
* Document the API (the GUI library and the app entry points needed by DAs)
* Fix known bugs in DAs and the app
* Code modernization.
* Add additional Desk Accessories. One is done already (an image viewer)
* Add additional functionality to the DeskTop app itself.
* Performance improvements (it's sluggish at 1MHz)
I'm using the issue tracker for feature requests/bug reports. I'm building it with ca65, and ensuring that it builds byte-identical for the moment.
The overall structure of the system is now reasonably well understood; see https://github.com/inexorabletash/a2d/blob/master/desktop/README.md which includes a breakdown of the file segments/overlays and the memory map. All the weird naming is my fault.
There's a GUI library that handles mouse/keyboard input, managing cursors, windows and menus, and drawing text and graphics in DHR; this provides an API with a MLI-like calling convention and is mostly understood, except for a handful of calls. It's pretty slick - fill patterns, polylines, bitmaps, cursors, menus, hit testing, proportional text rendering, 16-bit coordinates... everything you'd expect from a decent GUI library. This spans AUX $4000-$8500ish.
The bank switched memory in AUX $D000-$FFFF holds a tiny bit of code, but mostly resources (strings, bitmaps, menu definitions, points/rects, tables) and buffers for the windows/icons.
Everything else not taken up by ProDOS or DHR in both AUX and MAIN is the actual application, comprising the desktop logic, the contents of windows, and actions performed on volumes/files - dialog input loops and the actual ProDOS MLI work. The segments which are initially loaded are in the process of being understood (e.g. working backwards from string and bitmap resources it's possible to identify the handlers for various menu items and dialogs). Overlays are pulled in for operations with additional UI (e.g. disk copy) and I haven't dug into those yet.
There are some interesting things lurking in the code. For example, in the initial launch sequence which overrides the ProDOS QUIT handler (twice), there's an unreferenced block of code which can dump the DHR screen to an ImageWriter printer attached to an SSC in slot 1. I suspect this was used to generating screenshots for the manual, and could be hooked up by altering a few bytes. The code is all 6502, not 65C02. There are inconsistencies in coding style, but it's overall pretty elegant... if a bit pokey. The DAs are particularly buggy and have a fair bit of dead code.
If anyone is interested in helping... well, PRs welcome. :) The code base is large enough that assistance in deciphering it would be handy, although coordination would be required. There's definitely enough documented to produce custom DAs - I started documenting the lifecycle at https://github.com/inexorabletash/a2d/blob/master/desk.acc/a2d.md but that could definitely be improved.
Code and documentation are at: https://github.com/inexorabletash/a2d
Goals:
* Get the code fully documented
* Get the code buildable with changes (i.e. no hard-coded addresses except documented entry points)
* Document the API (the GUI library and the app entry points needed by DAs)
* Fix known bugs in DAs and the app
* Code modernization.
* Add additional Desk Accessories. One is done already (an image viewer)
* Add additional functionality to the DeskTop app itself.
* Performance improvements (it's sluggish at 1MHz)
I'm using the issue tracker for feature requests/bug reports. I'm building it with ca65, and ensuring that it builds byte-identical for the moment.
The overall structure of the system is now reasonably well understood; see https://github.com/inexorabletash/a2d/blob/master/desktop/README.md which includes a breakdown of the file segments/overlays and the memory map. All the weird naming is my fault.
There's a GUI library that handles mouse/keyboard input, managing cursors, windows and menus, and drawing text and graphics in DHR; this provides an API with a MLI-like calling convention and is mostly understood, except for a handful of calls. It's pretty slick - fill patterns, polylines, bitmaps, cursors, menus, hit testing, proportional text rendering, 16-bit coordinates... everything you'd expect from a decent GUI library. This spans AUX $4000-$8500ish.
The bank switched memory in AUX $D000-$FFFF holds a tiny bit of code, but mostly resources (strings, bitmaps, menu definitions, points/rects, tables) and buffers for the windows/icons.
Everything else not taken up by ProDOS or DHR in both AUX and MAIN is the actual application, comprising the desktop logic, the contents of windows, and actions performed on volumes/files - dialog input loops and the actual ProDOS MLI work. The segments which are initially loaded are in the process of being understood (e.g. working backwards from string and bitmap resources it's possible to identify the handlers for various menu items and dialogs). Overlays are pulled in for operations with additional UI (e.g. disk copy) and I haven't dug into those yet.
There are some interesting things lurking in the code. For example, in the initial launch sequence which overrides the ProDOS QUIT handler (twice), there's an unreferenced block of code which can dump the DHR screen to an ImageWriter printer attached to an SSC in slot 1. I suspect this was used to generating screenshots for the manual, and could be hooked up by altering a few bytes. The code is all 6502, not 65C02. There are inconsistencies in coding style, but it's overall pretty elegant... if a bit pokey. The DAs are particularly buggy and have a fair bit of dead code.
If anyone is interested in helping... well, PRs welcome. :) The code base is large enough that assistance in deciphering it would be handy, although coordination would be required. There's definitely enough documented to produce custom DAs - I started documenting the lifecycle at https://github.com/inexorabletash/a2d/blob/master/desk.acc/a2d.md but that could definitely be improved.