Repository navigation
GEOS boot disk patcher: add the TR USB mouse driver to a copy of the user's boot disk - #67
Merged
Merged
Conversation
Moves the RAM1/RAM2 8K bank allocator, the image preload and the numbered button save out of IOH_REU.c into RAMBanks.c, so the GeoRAM handler can use the same code. The REU keeps its own bank array and count: SerUSBIO's busy check reads NumREU_Banks to mean the REU's DMA is live, which a GeoRAM must not trip. Behavior is unchanged except that the save writes whole banks instead of a byte at a time.
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
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.
kfox
marked this pull request as draft
October 23, 2026 00:06
…REU mode leaves IO1 alone again Serving them at $DE00 beside the REU made every read of $DE00/$DE01 consume mouse movement, and IO1 probes for SwiftLink, RR-Net or MIDI saw changing values. The GEOS 128 driver now probes only $DF03, so it stops reading $DE03-$DE05 every frame.
…y main loop pass Other handlers no longer pay for the poll. While GeoRAM is not running the library's report accumulates unread, so starting GeoRAM clears it rather than delivering it to the C64 as one jump.
…do the arithmetic after A read that reaches DataPortWriteWait late is latched wrong on some C64s, so the step and clamp now run after the byte is on the bus. The main loop's poll updates the ready byte with a compare-exchange that fails if a read landed meanwhile, so a step is never driven twice. The bytes a read sequence returns are unchanged.
GeoRAM_NoRAM was never read: the IO handlers return while there are no banks. Init now points the window at the first page before it publishes the bank count, so that stays true without it; the two are volatile so the stores keep that order.
The patcher's helpers had no FLASHMEM, so the ones GCC kept out of line (GeosReadDirectory, GeosReadTrackBam, GeosTake and five more, 1,770 B) were placed in RAM1 code. They run only from the GEOS menu item, never from an interrupt, so flash is fast enough. The host harness gets an empty FLASHMEM, as TRMouse128.h does for PROGMEM.
…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
…s single $DF00 probe
…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("").
kfox
changed the title
# Conflicts: # Source/Teensy/MinimalBoot/Common/IO_Handlers/IOH_REU.c # Source/Teensy/RemoteControl.ino
# Conflicts: # Source/Teensy/DriveDirLoad.ino
Contributor
Author
|
Thanks for the ITCM and DTCM catches here.
Main's new The "GEOS 128 Boot Disk Setup" item stays as the step #70 builds on, and #70 replaces it with "GEOS 64". I've reworded this PR's description to say so. |
kfox
marked this pull request as ready for review
October 26, 2026 03:11
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the GEOS 64 package; stacked on #66 (USB mouse), so until it merges the diff here includes #61 and #66. Adds the firmware side of
trmouse.py: the TR finds the user's GEOS boot disk on the SD card and puts the TR USB mouse driver on a copy, never writing the original. #70 builds the GEOS 64 launch on it.The menu item this PR adds, "GEOS 128 Boot Disk Setup" under TeensyROM Specific, is a stepping stone: it only patches a GEOS 128 disk, and #70 replaces it with "GEOS 64", which patches and boots.
/GEOS128here) for disk images whose directory holds the target's DeskTop.<name>-TR.<ext>and adds the driver ahead of every other input driver. If the copy already has the driver, it reports that copy and changes nothing. With no boot disk in the folder, it tells the user where to copy one.The patch (
GEOS/GeosDiskPatch.h) is plain C over 256-byte block callbacks, so it works on the image on SD in place. Every refusal except a failed block read or write happens before the first write. The DeskTop name and the driver come from a target record (GeosTargets.h).tests/geos-disk-patch.test.jscompiles the patch on the host and holds it byte for byte totrmouse.pyon D64, D71 and D81 disks, refusals included.Tested on a TR+ in an NTSC C128 with the stock GEOS 128 2.0 D81: the prompt with an empty folder, the
-TRcopy listing the driver first with the original unchanged, and no second patch on a second run. Through #70's GEOS 64 launch on a TR+ in a C64: a disk whose directory must grow for the driver launches with the original untouched, and a disk with no room is refused with the image unchanged.