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.
By 'inverting' the loop, we can save 16 cycles by removing the `cpy #8`,
saving 16 cycles. But we need an extra `ldy #7` at the start of the
loop, so the total cycles saved is 14. Code size doesn't increase due to
the addition of the `ldy #7` negating the removal of the `cpy #xx`.
The driver requires a special linker configuration: "vic20-tgi.cfg".
The VIC-20 computer needs at least 8K of expansion RAM!
"tgidemo.c" needed to be adjusted because the VIC-20's vertical (y) range is greater than its horizontal (x) range -- the opposite of most other platforms. Also, the circle demo would jam on the VIC-20.
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.
For some reason or another both the author of the PR in question and its reviewers didn't notice that the two functions in question were totally overlooked.
Do not check $fbbe when detecting the Apple //e card. This byte is a version number for the Apple //e card according to misc technote #7 and it appears that the last version of the software that I am aware of has a 3 at this location.
Prior to this change, Apple //e cards which we not version 0 would be detected as an Apple //e enhanced.
tmp1 was used at two places resulting in the bug that VDC_CSET was set to garbage on 16k VDC.
pagecount and curpage were not reset on INSTALL resulting in non-reentrant code on static linkage of emd driver.
To do this we add a constructor call to UPDCRAMPTR, which is the ROM
routine that fixes up CRAM_PTR to match the screen location pointed to
by SCREEN_PTR.
This adds two additional bytes to programs using cputc() or other
routines that call it. These are in theory recoverable, but the VIC-20
does not yet free space used by constructors after the constructors
have been called.
Thanks to <greg.king5@verizon.net> (GitHub: greg-king5) for
investigating the difference in the VIC-20 KERNAL from the C64 and
proposing this solution to the problem.[1]
[1]: https://github.com/cc65/cc65/issues/946#issuecomment-538502820
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.
Restructured according to review in pull request #567.
The "inputc" function was moved in slightly modified form
to kbhit.s and replaces the old keyboard scanner.
cgetc() uses the new kbhit() to read a character.
* The sprite-types for black and transparent backgrounds were swapped.
* A filler-byte for text output isn't printed. (A hardware bug might not need that work-around in most cases.)
