The Pascal Firmware Protocol Bytes ID are not enough to differentiate an SSC card from a IIgs serial firmware:
http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.08.html
Loading a2(e).ssc.ser on a IIgs succeeds, then goes to limbo when one tries to use the serial port.
Check first byte on the slot's firmware in addition to the four existing ones, as it's supposed to be $2C (BIT instruction) on an SSC card, and $EF (65C816 SEP instruction) on the IIgs' serial firmware (ROM revisions 0, 1, 3).
There is no need to TryToSend before getting the character. We
send bytes during SER_PUT, and if interrupted during sending, we
still try to do it at the beginning of the next SER_PUT.
Apple2 and Atmos have Index in X, but can still use it for the
best-case path as long as we reload it in the worst-case part
(when we assert flow control).
Also, standardize the free space to trigger flow control to 32
characters left (compare with RecvFreeCnt before decrement)
There's no target with more than one serial driver (and I don't see that change anytime soon) so it's a no-brainer to apply the standard driver concept to serial drivers.
The Receive Data Register and the Transmit Data Register share share a single address. Accessing that address with STA abs,X in order to fill the Transmit Data Register causes a 6502 false read which causes the Receive Data Register to be emptied.
The simplest way to work around that issue - which I chose here - is to move the base address for all ACIA accesses from page $C0 to page $BF. However, that adds an additional cycle to all read accesses. An alternative approach would be to only modify the single line `sta ACIA_DATA,x`.
The target util convert.system is to be used in conjunction with GEOS on the Apple II but has to be built as an "ordinary" Apple II program. The way the cc65 library build system is designed there's no way to define dependencies between targets. The solution used so far was to explicitly trigger a build of the target 'apple2enh' from the target 'geos-apple'. However, that approach tends to break parallel builds which may be in the middle of building 'appple2enh' at the time it is triggered by 'geos-apple'.
There might be ways to get this fixed - but the the cc65 library build systrem is already (more than) complex enough, so I really don't want to add anything special to it.
On the other hand there are easier ways (outside the scope of cc65) to archive what convert.system does so I don't presume convert.system to be actually used - it's more a reference type of thing.
Putting all facts together the decision was easy: Just move convert.system from the target it is used with to the target(s) it is built with.
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).
Please refer to https://github.com/cc65/cc65/pull/532 for background info.
I wrote in https://sourceforge.net/p/cc65/mailman/message/35873183/
===
cputs() wraps to the next line if the strings is too long to fit in the current line. I don't know if it's worth the effort to allow cpeeks() to continue reading from the next line. I'd like to discuss this aspect with the actual implementers.
===
This is still as unclear today as it was when I wrote the above. Therefore this change just doesn't add cpeeks() at all.
Since f8c6c58373 the Apple II CONIO implementation doesn't "need" revers() anymore - meaning that (nearly) every possible value can be placed in VRAM with a straight cputc() (without the need for a previous revers(1)).
The implementation of cpeekc() leverages that cputc() ability by always returning the value that can be fed into cputc() without a previous revers(1). Accordingly, cpeekrevers() always returns 0.
So after the sequence revers(1); cputc(x); a cpeekc() will return a value different from x! However, I don't see this behavior braking the cpeekc() contract. I see the cpeekc() contract being defined by the sequence textcolor(cpeekcolor()); revers(cpeekrevers()); cputc(cpeekc()); placing the very same value in VRAM that there was before. And that contract is fulfilled.
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.
