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.)
