[kfox]

GEOS 64 and GEOS 128 run with the TR+'s REU as their RAM expansion, found and set up by GEOS's own CONFIGURE, with the TR still drive A and no IEC drive.

What the user does. On a TR+, set Special IO to REU+USB Mouse/Disk in Settings, then pick GEOS 64 or GEOS 128 as before. With any other Special IO setting GEOS runs with GeoRAM, as it does now.

How it works

• A new TR+ Special IO handler, REU+USB Mouse/Disk, keeps the REU at $DF00 and moves the USB mouse and block device registers to $DE00. Its unused REU registers read $FF, as a 1764's do, so TRB at $DF10 tells the two layouts apart.
• The TR disk driver, the mouse driver and the GEOS 128 boot ROM find their page: the drivers check TRB at $DF10, then $DE10. The boot ROM's page is written in by the firmware at launch.
• The -TR copy runs the stock CONFIGURE again. Its drive probe is patched to report the TR as a 1581 at device 8, and its 1581 driver record gets the TR transport. Copies made before this change, where CONFIGURE was put aside, are set up the same way. Any other CONFIG auto-exec, or a CONFIGURE not laid out like the stock one, is still kept from running.
• A copy's TR USB MOUSE driver is brought up to date in place at each launch, since an older one looks for the mouse where the REU now sits. One that takes a different number of blocks is refused with "its TR USB MOUSE is an old one; delete this copy".
• Docs:
  • docs/TR_Block_Device.md describes the second page.
  • A new docs/GEOS128_Usage.md covers GEOS 128.
  • docs/GEOS64_Usage.md and the GEOS 128 page share a "RAM expansion: GeoRAM or REU" section, which says which Special IO gives which RAM expansion on which board and recommends the REU on a TR+.
  • docs/General_Usage.md lists GeoRAM, 512KB REU and REU+USB Mouse/Disk under Special IO.
  • README.md links the GEOS 128 page.

Verified on hardware on a TR+ in an NTSC C128, with no IEC drive:

• GEOS 64 in C64 mode on the REU: CONFIGURE reports 512K (ramExpSize = 8), drive A is the TR, DeskTop up.
• GEOS 128 on the REU in 40 and in 80 columns, with the USB mouse; a file duplicated on the DeskTop.
• GEOS 64 and GEOS 128 on GeoRAM still reach the DeskTop, and the duplicated file is there after relaunching.
• NTSC read margin, per Constraints.md: a Dbg_SerTimChg build with a C64-mode loop reading the REU's address and length registers back, $DF10-$DF1F, and the TR page's TRM/TRB, 8 s at each step (1,400 to 5,100 rounds a second, by layout), while nS_PLAprop is raised. From the default of 150, the stock 512KB REU handler first fails at 260, this handler at 250 (one error at 240), and GeoRAM's TR page, as shipped, at 240.

Host tests. The disk and mouse drivers run on the 6502 emulator against a modeled REU and GeoRAM page, and the boot ROM with either page. The disk patcher tests cover the probe and driver records, the retyping, a copy set up by an earlier release, and the mouse refresh and its refusals. New harnesses cover the handler's IO2 page (the REU's registers, $FF across the rest of each 32 bytes, nothing without an REU) and which handler a GEOS launch runs under; each fails with the code it covers removed. npm test passes 337 of 337 on macOS, and under GCC in a linux/amd64 node:24 container 295 pass with 8 skipped for tools and disks it lacks. The firmware builds for TR and TR+ in the same container.

Reviewed at medium per change, with each review's fix commit at low, then a final medium pass over the branch, then a pass by Auditor, Adversary, Steward and Pragmatist lanes per the guidance in #79, whose fix commits got a low review. The docs commit was reviewed at low against the code; it changes no code (git diff c9fceda3 5c8de5b7 -- ':!*.md' is empty).

Memory, from CI's build of this head against main's: RAM1 code grows 832 B on the TR+, for the new handler's IO2 path, which the bus-cycle interrupt calls; it shrinks 64 B on the TR. RAM1 variables, free-for-locals and RAM2 are unchanged.