Why wasn't the start of BASIC moved to $0400

[x16tial]

Yeah, don't get me wrong, I wasn't advocating for moving BASIC down..  ?

[BruceMcF]

On 12/21/2022 at 6:38 PM, Ed Minchau said:

Yep, but we've been using the Commodore Kernal, and that's what Commodore allocated the space for. The kernal probably still has the code to operate a cassette drive using that 1kb.

I was saying, earlier in the X16 project, part of $0400-$7FF was being used, but that was moved in the same reorganization that freed up half the zero page for application use. At that time, we lobbied to keep it as Golden RAM 

[TomXP411]

On 12/21/2022 at 3:38 PM, Ed Minchau said:

Yep, but we've been using the Commodore Kernal, and that's what Commodore allocated the space for. The kernal probably still has the code to operate a cassette drive using that 1kb.

Actually, the datasette buffer was at $033C-$03FB. $400 (or 1024 decimal) is the starting address of the VIC-II text display, and the sprite registers are directly after that. 

So, basically, the entire 1024-2047 block is video memory and registers on the Commodore 64. 

As to the cassette routines: It's possible I'm wrong, but it looks Ilike they have been stripped out, with the open, chrin, and chrout routines basically just doing nothing on channel 1. This is actually the first thing that fast loaders like JiffyDOS do, in order to make room for the faster DOS routines, so it make sense that those were removed from the CX16 KERNAL In fact, since there is no cassette port and the VIA chip that would have handled cassette duties is doing something else, it would actually have been irresponsible and possibly cause hardware problems if the code was left in and able to communicate with the VIA. 

 

[x16tial]

What am I thinking, I even mentioned the TXTTAB pointer.

You can make BASIC start at $0400, if you want.

Here's how:

POKE 224,4:POKE 1024,0:NEW

It's that easy.

What that does is pokes a 4 (where normally there's an 8 ) into the high byte of the TXTTAB pointer.  Pokes a 0 at $0400 (1024) to make BASIC happy (the start byte HAS to be 0).  And a NEW to initialize the new BASIC location (updates pointers and puts null link at the start)

Picture below demonstrates the increase of 1024 bytes.

Note: FRE(0) returns 2 bytes less than what the startup header reports, because at the start, BASIC uses 2 bytes for a terminating null pointer.

And the 2^16 adjustment is needed because of how FRE works.

Incidentally, the reverse could be done as well:  You could make the free area bigger and BASIC smaller, by poking a number larger than 8 to 224, and poking a 0 to the new start (multiply the new (larger than 8 ) number by 256).

Example:

POKE 224,12:POKE 3072,0:NEW

Will go 1K in the other direction.

[x16tial]

Additional note: after the above procedure, SAVE does save a basic program with the header bytes (correctly) set as 01 04.  Later if the file is loaded with ,8,1 it would position it at $0401.  But as I mentioned before, if loaded with just ,8, it will load to wherever TXTTAB is currently set.