A Berkeley Softworks geoRAM: the $DE00 page window onto RAM banks from
RAMBanks.c, with the page ($DFFE) and 16K block ($DFFF) registers
decoded across $DF80-$DFFF the way VICE does, leaving $DF00-$DF7F
free. No DMA, so it is in every full build, TR and TR+, and serves C64
and C128 mode alike. Up to 512K, as much as fits beside a loaded crt;
preloads SD:/georam.ram, and the special button saves the next free
georamNNN.ram. Freed with the REU wherever the menu reclaims RAM.

A short write (card full, drive pulled) printed "Saved" and flashed the
save LED. Load stops at a read error rather than adding -1 to its count.

…om one shared page

…eing them

Placed before Debug it moved Debug's number, and that number is what
eepAdNextIOHndlr stores, so a board saved with Debug as its default came
up on GeoRAM. After Debug, with LastSelectableIOH moved to it, every
selectable handler keeps the number it had.

The TR's USB host port takes a mouse; the main loop adds up its movement
and the IO handlers hand it to the C64 as signed steps, at $DF00 beside
GeoRAM and $DE00 beside the REU, in the halves of the IO area each one
leaves free. A 1351 can't be emulated: the SID's POT lines are not on the
cartridge port, so this is for software with a TR driver.

Each read of X or Y returns the movement since the last read of it, at
most 127 steps, and keeps the rest for the next one, so a fast mouse is
not lost between polls. Only the main loop writes the USB totals and only
the IO ISR writes what it has handed out, so neither needs a lock.

trmouse.py assembles trmouse128.asm and writes it to a GEOS 128 boot
D81 as TR USB MOUSE, in the directory entry ahead of the other input
drivers, because GEOS loads the first one it finds. The driver finds the
TR's registers by their ID at $DF03, else uses $DE00, doubles X in 80
columns as the stock 1351 driver does, and leaves clamping to the
kernal, which flags a push past an edge for apps that scroll on it.

…, and drops buttons on unplug

…and drains movement while the pointer is off

Without a TR handler serving either page, the driver read open bus at
$DE00 as motion and a held button, so the pointer jumped and clicked on
its own. Movement made while mouseOn was clear stayed in the TR's
counters and swept the pointer across the screen once it came back on.

…d directory chain

GEOS reads the permanent name's version from offset 12, where the class
string had a space. A directory sector that links back to an earlier one
made dir_slots loop forever when no slot was free.

…ort an unplug strands

On the Cortex-M7 an NVIC_ICER write is not guaranteed to block the IRQ until a DSB/ISB, and without a compiler barrier the inlined getMouseX/Y loads may be hoisted above the disable, so the window 78cbc05 closes could stay open. A report landing just before an unplug was left pending and delivered (buttons included) on the next plug. IRQ_USBHS is in scope through USBHost_t36.h, so use the library's name.

… that does not hold

…and holds the class name to its 12 bytes

…piler too

mouseDataClear() keeps its stores ahead of NVIC_ENABLE_IRQ only because it lives in another translation unit; with LTO (opt=o2lto) it inlines, and its plain stores may sink past the volatile NVIC write, reopening the race on the way out.

A 1581 directory lives only on track 40, sectors 3-39. A chain into a
free data sector on any other track let allocate() hand that sector to
the driver while the new directory entry was written over it.

D81_SIZE is derived from the geometry it stands for.

…r's directory link, and grows a full directory

… undercounts a track, and a header with no directory link

…ry sector the BAM frees, not only the first free one

The firmware will put the same file on a boot disk that trmouse.py does, so the bytes come from one place. A test regenerates the header and fails when the committed copy drifts from trmouse128.asm.

…its arrays in flash

Python's write_text writes CRLF on Windows, which the drift test compared against an LF checkout. A Teensy 4 places const data without PROGMEM in RAM1.

…r block by block

It reads and writes 256-byte blocks through callbacks, so it can patch an image on SD that is too large for RAM. A host test compiles it and holds it byte for byte to trmouse.py on D64, D71 and D81 boot disks, refusals included.

… not the hand-written patch header

… its first write, and links from more than one file

A refusal used to come after blocks were already written, which on an image patched in place on SD leaves it half patched. The harness now fails a refusal that changed the image, and refuses an image too big for any format rather than reading its first 800K.

…ory again, and a test holds the full-directory refusal to before the first write

…tor, so its own refusal leaves the image as it was

…get, and tells a boot disk from a data disk

GEOS 64 needs only its own driver and a second target to use the same patch.

A 6526 flips AM/PM when hour 12 is written to its TOD, so writing 12 PM
left the clock at midnight and 12 AM at noon; GEOS then ran 12 hours off
and turned the date over at noon. The hour byte is now the one that lands
on the right value after the flip.

The patch also keeps the stock clear of CRB's alarm-select bit, which it
had dropped to make room: with that bit set, the time would go to the
alarm. The time fits in the stock run by storing the seconds and tenths
from X, which the stock file's preceding loop leaves zero; the matched
bytes include that loop's end so another boot file is left alone.

…oram.bak

The button saved to the REU's numbered names (georam000.ram, ...), but
preload reads only georam.ram, so a saved GeoRAM never came back. The
new image is written to georam.tmp first and renamed into place only
after the write succeeds. The REU keeps its numbered saves.

On Teensy 4 string literals land in .rodata, which the linker places in
DTCM. PSTR() puts each one in flash instead, where snprintf and
SendMsgPrintfln read it directly. The host harness gets PSTR(s) as (s).

… not where they are

# Conflicts:
#	Source/Teensy/MinimalBoot/Common/IO_Handlers/IOH_GeoRAM.c

# Conflicts:
#	Source/Teensy/MinimalBoot/Common/IO_Handlers/IOH_GeoRAM.c
#	Source/Teensy/MinimalBoot/Common/IO_Handlers/IOH_REU.c
#	Source/Teensy/Teensy.ino

…s single $DF00 probe

SD.h's File::flush() is void and drops FsFile::sync()'s result, and getWriteError() reads a Print flag the SD library never sets, so the image is held as an FsFile opened on SD.sdfs and FLUSH returns sync()'s result. Closing at unmount reports a failed final write on the serial console instead of dropping it. The image opens O_RDWR: a missing path no longer creates an empty file.

…ens it

SD.begin rebuilds the SdFat volume in place: the image's dirty cached sector is dropped rather than written, and the open FsFile is left pointing into the rebuilt volume. Host file commands (GetStorageDevice), a GeoRAM save from the special button (SDFullInit and FSfromSourceID) and a remote launch can all begin the card while GEOS has the image mounted. Patching each caller would leave the next one to forget, so the main image's SD.begin calls all go through SDBegin(), which syncs and closes the image first and reopens it from its saved path after, keeping a running GEOS session's disk.

…en it ends

The block device only answers under GeoRAM, so its polling moves from every main loop pass to GeoRAM's polling handler, beside the USB mouse. Nothing would then flush or close the image after GeoRAM ends, so leaving it (SetUpMainMenuROM, RemoteLaunch) unmounts the image beside FreeGeoRAM: close() syncs it. RemoteLaunch's SDFullInit before that point is safe since SDBegin closes and reopens the image.

Only TRPageIO and the inline register helpers in TRBlock.h serve the IO ISR. PollTRBlock and the file and image backends run from the main loop at SD card speed, so they move to flash; TRBlockImage.h gets FLASHMEM's host fallback through GeosDiskPatch.h.

The REU no longer serves IO1, so the REU row, the $DE00 probe and the checklist's either-base item go.

# Conflicts:
#	Source/Teensy/GeosLauncher.ino

PSTR on the launcher's and boot builder's own messages, as the patcher's already are, so their literals go to .progmem instead of DTCM .data.

…nd puts it back if the save cannot take its place

If the last rename failed, georam.ram was gone: the next session preloaded
nothing, and saving that blank RAM removed georam.bak, the last good image.

… running handler's memory

A launch is accepted while a handler is busy. One naming a TR menu path that
does not exist returned after the CRT chips, REU, GeoRAM and SwiftLink
buffers were freed, without resetting to the menu, leaving the running
program on freed memory.

A C++ harness includes USBMouse.c with the USB controller, the NVIC and the data port stubbed, and runs it from a script of USB reports, polls, inits and IO reads. The tests hold the register map: a large movement arrives as 127s and then the remainder, X and Y apart, sub-step counts carry, init discards movement from before the handler, and the buttons follow the report and clear on unplug. An IO read can be landed at the poll's atomic write of the ready word, and a weak compare-exchange can be made to fail, to show neither repeats nor drops movement.

The source is C++ (static_cast on the controller), so the harness is built as gnu++17 rather than C99. The Cortex-M barrier in PollUSBMouse does not assemble on the host, so the harness turns asm volatile(...) into asm("").

The REU no longer serves IO1, so the block device lives only beside
GeoRAM. Probing $DE as a fallback read GeoRAM's page RAM under GeoRAM
and open bus under the REU. With the base fixed, the driver no longer
patches its own register addresses. The checklist now says what the
driver checks: TRB, not TRM.

The image is mounted only while GeoRAM is the handler, and under GeoRAM the
card is begun only through SDFullInit (the special button's save, a host or
NFC launch) and FSfromSourceID (the same save, an NFC tap). FSfromSourceID now
begins through SDFullInit, which only adds its retry for a card that is present
but fails to start. Every other SD.begin goes back to calling SD.begin.

Every D64 is the same size, so after a card swap the reopen took the new
card's file at the same path and GEOS's cached BAM and directory overwrote it.
The mount records the file's first sector and the card's serial number; a
reopen that finds either changed leaves the image unmounted and logs it.

GEOS never sends FLUSH, so the idle flush is its only way to the card, and it
cleared the dirty flag whether or not the sync succeeded. A failed sync now
leaves the image dirty, retries a quarter second later and logs once.

…he image is reopened

The flush-failure log flag was a function static that only a successful sync cleared, so after an image was closed with its sync still failing, a later mount's failures went unlogged. It is file scope now and TRBlockClose clears it with the dirty flag.

# Conflicts:
#	Source/Teensy/RemoteControl.ino