Re: VIC-20 basic memory start + basic stub + etc

From: Marko Mäkelä <>
Date: Tue, 7 Feb 2012 15:40:57 +0200
Message-ID: <20120207134057.GF9445@x60s>
On Tue, Feb 07, 2012 at 02:30:45PM +0100, Gábor Lénárt wrote:
>Now my question: can I write a program in assembly (with the basic 
>stub) which works on both of unexpanded and expanded VIC-20 without any

Sure. See the "cbmbasic" set of binaries for cbmlink. It can be loaded 
to the current BASIC start address (as long as it is $xx01). It will 
relocate the machine code to the specified address. I played a few 
tricks so that I could store the relocation information inline with the 
code. The BASIC part looks like this:

    20 sys29+256*peek(44):new
  6656 sys

The second line will not be reached. It is where the start address can 
be specified, in the line number. And it tells you that the code can be 
restarted with SYS 6656. :-)

>But this means another question: if I have an expanded VIC-20 to the 
>max (as far as I remember something like +28K RAM is reported by the 
>basic startup msg) then will it be continous, that I can load a single 
>prg file which is sized - let's say - 25K ?

Yes, you would have the screen memory at $1000 and BASIC from $1201 to 

>I'm thinking on writing some simple code (which contains only 
>PC-relative jumps, etc) as the relocation code, which copies the rest 
>of the code so I have a "fixed" address then for it, regardless of the 
>memory expansion (but I will lose some memory then maybe about $200=512 
>bytes) to compensate the difference, and also I need to handle screen 
>address not as a constant anymore ...

I used a trick in the cbmlink compilation. I searched for contiguous 
bytes that do not exist in the binaries. For example, let us assume that 
they are $b9, $ba, $bb, $bc.  Then I assembled the code to $b900 and 
wrote the relocator so that it would detect any bytes $b9..$bc and 
relocate them by simple subtraction or addition. This would work for 
relocating from $b900 to a user-specified $xx00 address.

Best regards,


       Message was sent through the cbm-hackers mailing list
Received on 2012-02-07 14:00:51

Archive generated by hypermail 2.2.0.