vic20/cputc: Fix incorrect CRAM_PTR at startup when using conio

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

libsrc/vic20/cputc.s

@@ -10,8 +10,29 @@
         .import         gotoxy
         .import         PLOT
 
+.scope  KERNAL
+        .include        "cbm_kernal.inc"
+.endscope
+
         .include        "vic20.inc"
 
+; VIC-20 KERNAL routines (such as PLOT) do not always leave the color RAM
+; pointer CRAM_PTR pointing at the color RAM location matching the screen
+; RAM pointer SCREEN_PTR. Instead they update it when they need it to be
+; correct by calling UPDCRAMPTR.
+;
+; We make things more efficient by having conio always update CRAM_PTR when
+; we move the screen pointer to avoid extra calls to ensure it's updated
+; before doing screen output. (Among other things, We replace the ROM
+; version of PLOT with our own in libsrc/vic20/kplot.s to ensure this
+; precondition.)
+;
+; However, this means that CRAM_PTR may be (and is, after a cold boot)
+; incorrect for us at program startup, causing cputc() not to work. We fix
+; this with a constructor that ensures CRAM_PTR matches SCREEN_PTR.
+;
+        UPDCRAMPTR := KERNAL::UPDCRAMPTR    ; .constructor doesn't understand namespaces
+        .constructor    UPDCRAMPTR
 
 _cputcxy:
         pha                     ; Save C