apple2ix/PROBLEMS
asc 3abd2e87aa Refactor to use GNU build tools
* Added configure.ac and non-recursive Makefile.am
    * Modularized source into subdirectories
    * Simplified header inclusion
2014-01-22 20:51:50 -08:00

59 lines
2.5 KiB
Plaintext

Known issues with the emulator:
Emulation Fidelity:
- Disk emulation. The emulator is not very realistic. It handles almost
all non-copyprotected disk access okay, but copyprotected or diagnostic
programs may be confused by our drive, which magically spins at precisely
the optimal speed. (see Specific Programs, below).
- Medium Resolution graphics. This is a rarely used //e mode that is to
Low-Res what 80 Column text is to 40 column text. We don't support it as
yet, although it should be relatively simple.
- We don't emulate the //e's vertical blanking interval detection feature.
This is on the TODO list.
Graphics:
- Composite graphics artifacts are not emulated. This is on the TODO list.
- B/W color setting does not apply to lores or double hires. This
generally is not an issue in practice though, as it's really only needed
to avoid color fringing in b/w hires images.
- Double Hires mode is always 140x192 color. Some applications use it as
a 560x192 b/w display however. Note that most applications indicate
which mode they want using the high bit of the dhires data bytes, so it
wouldn't need to be a preferences setting.
- If an 80-column mode is selected in the low-res emulator, nothing will
be written to the display -- the image from the last video mode will
remain on the screen. If a menu is brought up it will `stick'. This may
make people think the emulator crashed, although it will recover if the
application returns to 40-column mode.
Keyboard:
- Presently, the Backspace key is interpreted as Left-Arrow (Code 0x88).
It could be argued that it should be interpreted as Delete (Code 0xff)
instead. Real Apples had no seperate Backspace key, but the //e's Delete
key was in an analogous position to the PC's Backspace). The PC
keyboard's Delete is assigned to 0xff (in //e mode).
Specific Programs:
- Some programs (Computist's Nibbler, Sword of Kadash Master copy for
example) lock up. It appears (in debugger) that they are reading the disk
with the motor off. Perhaps they pulsed the real Apple's drive motor to make
it turn slower?
- ProDOS will refuse to format disks, claiming that the disk is too slow.
- ``Alternate Reality: The City'' seems to get jammed, rapidly changing
the video mode. I'm not sure if this is a real failure, or just a special
effect that takes longer than I'm willing to wait to finish (mode switches
would be much faster on a real Apple.) I can get into the program
with some nontrivial debugger manipulation to `short out' the offending loops.