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.
Although the primary target OS for the Apple II for sure isn't DOS 3.3 but ProDOS 8 the Apple II binary files contained a DOS 3.3 4-byte header. Recently I was made aware of the AppleSingle file format. That format is a much better way to transport Apple II meta data from the cc65 toolchain to the ProDOS 8 file system. Therefore I asked AppleCommander to support the AppleSingle file format. Now that there's an AppleCommander BETA with AppleSingle support it's the right time for this change.
I bumped version to 2.17 because of this from the perspective of Apple II users of course incompatible change.
I recently came across that the question if a driver is compatible with DOS 3.3 isn't about the fact if it actually uses IRQs but if it potentially could use IRQs as the driver kernel pulls in the IRQ handler anyway. This is especially suboptimal in the scenario of statically linked drivers where it is concpetually totally clear at link time they use IRQs or not. Apart from that it might make sense to be able to define on a per-target basis if _any_ of the drivers of a certain class uses IRQs. If that isn't the cases the driver kernel for that driver class for that target could omit IRQ handling too. I'm aware that Uz imagined drivers being loaded which weren't known when the program was linked - but I don't see this.
For quite some time I deliberately didn't add cursor support to the Apple II CONIO imöplementation. I consider it inappropriate to increase the size of cgetc() unduly for a rather seldom used feature.
There's no hardware cursor on the Apple II so displaying a cursor during keyboard input means reading the character stored at the cursor location, writing the cursor character, reading the keyboard and finally writing back the character read initially.
The naive approach is to reuse the part of cputc() that determines the memory location of the character at the cursor position in order to read the character stored there. However that means to add at least one additional JSR / RTS pair to cputc() adding 4 bytes and 12 cycles :-( Apart from that this approach means still a "too" large cgetc().
The approach implemented instead is to include all functionality required by cgetc() into cputc() - which is to read the current character before writing a new one. This may seem surprising at first glance but an LDA(),Y / TAX sequence adds only 3 bytes and 7 cycles so it cheaper than the JSR / RTS pair and allows to brings down the code increase in cgetc() down to a reasonable value.
However so far the internal cputc() code in question saved the X register. Now it uses the X register to return the old character present before writing the new character for cgetc(). This requires some rather small adjustments in other functions using that internal cputc() code.
Those tags have two attributes: "url=" and "name=". In the non-HTML output formats, <url> shows both fields, while <htmlurl> shows only the name field (as the HTML format always does.) Thus, the general rules are
1. If the two attributes are different, then use <url>.
2. If they are similar, then use <htmlurl>.
3. If they are the same, then consider using <url> without the "name=" attribute.
(The reason for rules 2 and 3 is that the same text shouldn't be shown twice.)
There can be exceptions. Example: "od65.sgml" has <htmlurl> because the URL
would disturb the flow of a sentence.
