by not clearing the accrun flag, the dialog to insert a previously
ejected disc successfully causes the emulated mac to cycle to the
correct disc.
This worked in several cases I tested, though in the specific case
of an older OS (About Finder says 5.3) with a newer floppy
(HyperCardBootSystem7.img) the hypercard floppy keeps adding a new
desktop icon everytime it's ejected then re-loaded, and the request
to load it can never be satisfied.
you can specify a directory as the second -d argument and then cycle
among them by dragging to trash. Using eject doesn't work very well,
because it leaves a ghost on the desktop and accessing it has no way
of completing.
This change adds a boatload of ROM patches to alter screen base, resolution,
words-per-line, and related variables so that MacOS will function correctly
with a framebuffer other than 512x342 (which remains the default).
The majority of the patches are actually to make ROM-drawn low-level things
(such as disc icons, happy/sad Mac icons/crash hexadecimal info) render
right and be positioned correctly.
This works up to about 800x600; the limiting factor is patching int16
immediates for certain instructions, meaning a ~64KB framebuffer size
is the current limit without more work.
The Makefile can now take DISP_WIDTH/DISP_HEIGHT parameters to configure
a build. There is no support for dynamic switching, or runtime-selected
switching.
Additional ROM patches manually set the memTop variable to a given
memory size, and the memory test routine is skipped. This allows
the Plus ROM to cope with a Mac 256K configuration, but also non-
power-of-two sizes. That's useful for an MCU, making a Mac 208K,
Mac 192K, etc. possible.
Memory addresses are clamped such that wrapping within the RAM
region works, and any emulated address can be used without
overflowing the host RAM allocation. For a power-of-two memory
size this boils down (after compiler optimisation) to a plain
tmask; for non-Po2, this involves a divide/mod in the weird ROM
probing "off the end" cases, and a simple compare in all other
runtime cases (so shouldn't be too slow).
Instead of relying on the disc data being directly mapped, and
accessing blocks by memcpy'ing from it, provide op_read/op_write
callbacks so that the host can do disc ops itself (e.g. access SD).
The disc_descr_t describes the callbacks (and an opaque pointer
passed as an argument when they are invoked), per-disc.
...slightly. This shows the sync/hunt status, and TxUnderrun, which
are expected by system 7's startup. (It enables SDLC mode and probes
stuff.)
With this (and increasing memory, e.g. 4MB), umac boots 7.5.5 :)
The unix_main gets another option, -w, that enables the disc
mapping to reflect writes back to the backing file.
The disc emulation code now handles writes, which are copied
back to the disc data.
This still doesn't abstract read/write ops to disc, which will
be the next step (to support, for example, block-based storage).
