Repository navigation
Conversation
… beside an REU Under an REU the registers move to $DE00, since the REU's own repeat across $DF00-$DFFF. A copy of the driver lives on the user's disk, in CONFIGURE's 1581 driver, and outlives a change of Special IO, so it looks for the TRB id at $DF10 and then $DE10 on every transfer instead of being told the page when it is installed. $DF10 comes first because $DE10 is GeoRAM's window, which can hold any bytes; an REU's unused registers read $FF there.
…r beside an REU Beside an REU, $DF03-$DF05 are its address registers, which hold whatever the last transfer left and so can read "TRM". The block device's TRB id at $DF10 picks the page instead: an REU's unused registers read $FF there, and GeoRAM's window at $DE10 is never asked.
… launch gives it The boot ROM is built at every launch, which knows which handler it starts, so the firmware writes the page into the ROM instead of the ROM searching for it: a glitch-safe search does not fit in the one page the cold start copies. geos128boot.mjs assembles the ROM at two pages and lists the bytes that move, as trdrive.py does for relocations. The launch still asks for the page beside GeoRAM.
…R as drive A CONFIGURE is what finds an REU and sets GEOS up to use it, so it has to run. Its drive-type probe now answers a 1581 at device 8 and nothing elsewhere, and the 1581 driver it installs for drive A, its record 4, gets the TR transport the boot image already has. The stock file is known by the target's name for it and by the probe in record 0, so a copy made before this, where CONFIGURE was retyped, is set up the same way. Anything else named CONFIG is still kept from running, including a CONFIGURE whose records are not laid out as the stock one. The synthetic test disk has one directory sector; the old CONFIGURE test put a ninth file past it, so its check that CONFIGURE.DOC stays as it was looked at a slot no directory held.
The copy outlives the firmware that made it, and a mouse driver from before the REU route reads $DF03 for its ID, which beside an REU is an address register. The driver is rewritten in place over its own blocks; one taking another number of blocks is refused with a message to delete the copy, since growing it means allocating on the user's disk.
The REU answers at $DF00 as before, and the USB mouse and block device move to IO1, the page an REU leaves free. A GEOS launch takes this handler when it is the Special IO setting, and GeoRAM otherwise, and builds the GEOS 128 boot ROM for the page that handler puts the registers on. Beside the REU, $DF0B-$DF1F read $FF, as a 1764's unused registers do, so the TRB id the GEOS drivers look for at $DF10 cannot appear there.
…d not at all without an REU The TR's GEOS drivers decide which page holds the block device by what $DF10 reads, and no test ran IO2Hndlr_REU_TRPage itself: dropping its $FF answer, its bank check or its 32-byte mirror left the suite green.
…osen for Both the C128 boot ROM's register page and the handler come from GeosIOHandler(), and no test held either: dropping IOHandlerSelectInit's GEOS branch puts GEOS under the item's GeoRAM while the boot ROM looks beside the REU, and the suite stayed green.
Giving GeosIsDriverAt and GeosReplaceTransport a second caller took them out of their inlined callers and into ITCM, 334 bytes on both TR and TR+, and the probe patterns and CONFIGURE names landed in DTCM. The build's memory report showed it; marking them FLASHMEM and PROGMEM, with GeosFindOnce and GeosBytesInBlock beside them, returns 320 bytes of RAM1 code on each target and leaves the TR's below where it was before the REU change.
Contributor
Author
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.
Documents GEOS 128, and how GEOS 64 and GEOS 128 choose between GeoRAM and the REU through Special IO.
Builds on #81, whose REU route it describes. Until #81 merges this PR also shows #81's commits. This PR's own change is the last commit, 5c8de5b.
What changes
docs/GEOS128_Usage.mdcovers:/GEOS128and what the boot disk must hold (128 DESKTOP,GEOBOOT128);-TRcopy;docs/GEOS64_Usage.md: the GeoRAM and REU sections become one "RAM expansion: GeoRAM or REU" section, the same as GEOS 128's.docs/General_Usage.md:README.mdlinks the GEOS 128 page.Reviewed at low, checking claims against the code: the menu row and board gating, folder and file names, every message string, which handler
GeosIOHandlerpicks, the GeoRAM and REU register addresses and sizes, and the preload and save files. No findings.git diff c9fceda3 5c8de5b7 -- ':!*.md'is empty.