Commander X16

Given that the screen RAM got moved into the VERA RAM, why was the start of basic kept at $0800 rather than moving it to $0400 and capturing an additional 1k for BASIC?  It's really more of a curiosity question than anything else.

I can make two guesses:

1. This gives us 1K for machine language co-routines. Since the only other way to get that is to lower the top of BASIC using POKEs, this is the most sensible and easy way to do so. 

2. To keep binary compatibility with Commodore 64 BASIC programs. A BASIC program written on a C64 will load right up on the Commander and on the C64 without changes, which you can't say for PET, VIC-20, and C128 BASIC programs. I even wrote a simple tool (in the download section) to convert the start address, due to that issue. 

 

This came up early on. Some of the space was originally used for something, and then when there was a rearrangement and one High RAM segment used which freed up the $0400-$07FF space, I was among those lobbying Michael Steil to leave the 1K in place as Golden RAM. The 4K Golden RAM at $C000-$CFFF in the C64 is very useful, and with an autoexec capability, a Golden RAM space will be even more useful in the X16.

On 12/21/2022 at 8:21 AM, BruceMcF said:

Some of the space was originally used for something,

Golden RAM was originally the cassette tape buffer. 

On 12/21/2022 at 11:24 AM, Ed Minchau said:

Golden RAM was originally the cassette tape buffer. 

I was talking about the X16.

On 12/21/2022 at 2:53 PM, BruceMcF said:

I was talking about the X16.

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.

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.

And when someone develops a cassette drive interface card the routines will be there for use. ?

 

On 12/21/2022 at 6:48 PM, Edmond D said:

And when someone develops a cassette drive interface card the routines will be there for use. ?



 

Wouldn't the C64 kernal expect the screen buffer to be at $0400 and put the cassette buffers elsewhere?  The cassette buffer has to be relocatable since the C64, VIC20 and PET all use basically the same kernal, but all put their screen buffers in different places.  I think even the TED based machines used a variant of the same kernal.

On 12/20/2022 at 3:28 PM, TomXP411 said:

2. To keep binary compatibility with Commodore 64 BASIC programs. A BASIC program written on a C64 will load right up on the Commander and on the C64 without changes, which you can't say for PET, VIC-20, and C128 BASIC programs. I even wrote a simple tool (in the download section) to convert the start address, due to that issue. 

Don't BASIC programs (or any file really) loaded with the ,8 (or ,9) without the 2nd ,1 parameter load into whatever area is set for BASIC in the TXTTAB pointer?  Pretty sure that's true.  If not loaded with the ,1, the first two bytes are ignored.

On 12/21/2022 at 7:45 PM, x16tial said:

Don't BASIC programs (or any file really) loaded with the ,8 (or ,9) without the 2nd ,1 parameter load into whatever area is set for BASIC in the TXTTAB pointer?  Pretty sure that's true.  If not loaded with the ,1, the first two bytes are ignored.

That's not necessarily true for every version of BASIC. On the PET, for example, you simply can't load a BASIC program that has the wrong start address. While it will load, it will end up in the wrong place, and the PET can't run it. Also, people have gotten used to using ,8,1 and will often forget that you probably should not do that with BASIC programs, so it makes things confusing. I figure that having a consistent start address makes at least one thing just a little bit simpler.