Certain scenarios (e.g. not running any Applesoft program at all since booting DOS 3.3) can make DOS 3.3 consider cc65 device input (e.g. getchar()) that reads a CR interpreting the command in the keyboard buffer. Setting the hibyte of the Applesoft currently executed line number to some value <> $FF (beside setting the input prompt to some value <> ']') makes DOS 3.3 understand that we're not in intermediate mode and that therefore I/O not preceded with ctrl-d mustn't be fiddled with (see DOS 3.3 routine at $A65E).
The implementation is a bit tricky as it requires to take different code paths for the //e, the //c and the IIgs. Additionally the //c only provides a VBL IRQ flag supposed to be used by an IRQ handler to determine what triggered the IRQ. However, masking IRQs on the CPU, activating the VBL IRQ, clearing any pending VBL IRQs and then polling for the IRQ flag does the trick.
As described e.g. in the Apple IIe Technote #6: 'The Apple II Paddle Circuits' it doesn't work to call PREAD several times in immediate succession. However, so far the Apple II joystick driver did just that in order to read the two joystick axis.
Therefore the driver now uses a custom routine that reads both paddles _at_the_same_time_. The code doing so requires nearly twice the cycles meaning that the overall time for a joy_read() stays roughly the same. However, twice the cycles in the read loop means half the resolution. But for the cc65 joystick driver use case that doesn't hurt at all as the driver is supposed to only detect neutral vs. left/right and up/down.
CPU accelerators are supposed to detect access to $C070 and slow down for some time automatically. However, the IIgs rather comes with a modified ROM routine. Therefore it is necessary to manually slow down the IIgs when replacing the ROM routine.
On C64, VIC-20 and Plus/4, the conio library PLOT routine uses direct
calls into the Kernal, including the Kernal PLOT routine that we're
replacing. These were previously hardcoded addresses; we change these
to use the symbols for those routines defined in cbm_kernal.inc. (This
changes no functionality.)
To do this, we need to import cbm_kernal.inc in a namespace so we
don't have a collision between the PLOT that we're defining and the
Kernal definition.
We also add a UPDCRAMPTR symbol (used by kplot for VIC-20 and C64) to
the direct entry kernal routines in in cbm_kernal.inc, and expand the
comments describing what the "direct entry" Kernal routines are.
<greg.king5@verizon.net> (GitHub: greg-king5) came up with this idea
and did initial testing of it.
This has been tested on VICE xvic, x64 and xplus4 emulators with a
program that does a cputs() call (github.com/0cjs/vic20cc65) to
confirm that it works the same way after as it did before.
