A file dropped on the window went to drive 1 or drive 2 depending on the
half it landed on. There was no way to know beforehand which drive was
which or what each one had inserted, and no sign afterwards of where the
file went. The machines with two Disk II cards have four drives and only
the first two could be reached.
F8 now shows a screen with one area per removable media drive, each with
the name of its drive and the image it has inserted, or EMPTY, and the
same screen appears for a moment after a drop with the drive that got the
file marked. It is a text screen of 80 columns rendered the same way the
help is, so SnapshotMessageGenerator takes the number of columns now.
The drives register with a label and tell the media they have, so the
frontends ask the machine with GetRemovableMediaDrives instead of assuming
two. The name of the media is written by the emulation goroutine and read
by the frontends, hence the atomic access.
The new frontend/shared package holds what the frontends have in common
and the emulator library has no place for: the composition of the screen
and the mapping from a position to a drive.
a2sdl reads the position of the pointer on the desktop when the file is
dropped. The mouse motion events do not arrive while another application
drags a file, so the last known position was stale and the file could land
on the wrong drive.
a2sdl3 shows the areas while the file is being dragged over the window,
which is something only SDL3 reports.
a2ebiten had no drag and drop at all, although the help it shows said
otherwise. Ebitengine hides the paths of the files dropped, but it opens
the real files and the handle tells the path back, so the images are
loaded like on every other frontend, compressed files included.
The screen modes mixed two independent things. Green, plain and NTSC read
as three points on one scale, but plain and NTSC are the same colour
rendering and differ in whether the gaps between the scan lines are drawn,
while green is a phosphor that happened to always get them.
They are now the four combinations of the two: ScreenModeGreen,
ScreenModeColor, ScreenModeGreenScanlines and ScreenModeColorScanlines,
built from a bit for each property. isColor and hasScanlines read them, so
each place says what it means, and NextScreenMode rotates through the four.
The old modes map onto the new ones exactly, green to green with scan lines,
plain to color, NTSC to color with scan lines, and the frontends are moved
over so nothing they show changes. The scenarios of the tests now cover all
four, and their images are renamed after the modes. The three that already
existed render byte for byte as they did.
Iván Izaguirre