The README listed only the SDL2 and the console frontends, and the build
instructions for all of them lived in the README. Now there is a Frontends
section with the eight of them, each linking to a page with how to build it,
how to use it and what it can not do.
The libretro pages take the frontend_ prefix as well. The feature list moves
to doc/features.md, leaving a summary in the README.
The default configuration was wrong in the two places it was written: it
listed a parallel card in slot 1 and a mouse in slot 4, which are empty and a
Mockingboard, and flags -disk35 and -hd that no longer exist. Both lists now
come from -showConfig.
Runs izapple2 inside RetroArch and the other libretro frontends. It is built
as a C shared library with cgo, so it needs a C toolchain, and it is not part
of the releases.
The frontend owns the frame timing, calling retro_run once per frame, so the
core advances the machine with RunCycles and hands over one video frame and
the matching audio samples on the thread it was called on, with no
goroutines. A frame is 17030 cycles. While a drive asks for fast mode it runs
sixteen frames worth, or loading a disk takes half a minute.
Kept small on purpose: no super hi-res, no Videx video, no RGB card and no
savestates. What is left is generated as 560x192, so the framebuffer is a
fixed 564x192 and the geometry never changes. The cards that produce the
other modes are taken out of the slots.
Diskettes are swapped from the menu through the extended disk control
interface, with the list coming from an M3U playlist, and the saves go to the
save directory of the frontend as overlays.
Go cannot call the function pointers the frontend hands over, so shim.c keeps
them and reaches them through plain C functions, and the callbacks the core
provides go the other way through it. Four entry points take a const pointer,
which cgo cannot generate, so those are wrapped there as well.
The default machine is the new gaming model, an enhanced //e with a
Mockingboard, no mouse and no VidHD, which also serves the command line.
See doc/libretro.md to use it, frontend/a2libretro/README.md for how it works.
The emulation writes to a disk in the file it was loaded from, so saving a
game modifies the image the user has. With a save directory the changes go
to an overlay file there instead and the image is only ever read.
An overlay stores just the parts the software wrote, indexed by a bitmap in
its header: tracks of 4096 bytes for the diskettes, blocks of 512 for the
ProDOS devices. Nothing is written for the rest, so the file takes as much
space as what was saved and not the size of the disk, which matters for the
hard disks where an image can be 32Mb and a saved game a handful of blocks.
The header also holds a checksum of the image it was made from, so an
overlay is never applied to a different disk with the same name.
As the image is only read, this also makes writable the disks that could not
be written at all: the ones inside a zip or a gzip, the ones loaded from an
URL and the ones embedded in the executable.
The directory comes from the new -saveDir option. The cards that write to
their disks take a savedir parameter of their own that defaults to it, with
'none' to write back to the image.
Also fixes saveTrack leaking a file descriptor on every track written, and
going on to write through a nil file when it could not be opened.
Iván Izaguirre