Relocating basic?

[R'zo]

When relocating basic I know basic start pointers are at 43 & 44. 55 & 56 are end of memory.

Do I also need to set variable and array pointers or will the Vic automatically set them appropriately as the Vic loads and runs the program?

I've moved start of basic up before but not the end down. When moving the start I know this is not necessary but I'm not sure about moving the end down.

If it helps at all I'm looking to keep unexpanded memory starting at 4096 but drop the end down to 7167.

[vicist]

Poke44,28 should be all you need.

I assume you want to protect some user defined characters.
Do the poke and then peek the other pointers to make sure.

[tokra]

If it helps at all I'm looking to keep unexpanded memory starting at 4096 but drop the end down to 7167.

Then you should be able to just do POKE 56,28:CLR

What vicist wrote will START the BASIC at 7168, which is not what you wanted.

I saw the line above "POKE 56,28:CLR" in many type-ins back then. The CLR makes sure also address 52 is corrected.

[vicist]

OOOps!!.

Yes, my mistake.

[R'zo]

Then you should be able to just do POKE 56,28:CLR

What vicist wrote will START the BASIC at 7168, which is not what you wanted.

I saw the line above "POKE 56,28:CLR" in many type-ins back then. The CLR makes sure also address 52 is corrected.

Thank you.

Here's a short type in of the little experiment I needed to try out with that for the project i'm working on. Use awsd to move the character around the screen.

I poked 55,255 and 56,27, are my calculations off?

Code: Select all

100 poke 55,255:poke56,27:clr:poke648,28:poke36866,22
200 poke36866,(peek(36866)and128)+30:poke36867,(peek(36867)and129)+34*2
250 cc=37888:xx=15:yy=450:x1=0:y1=0:c=7168
262 fort=0to1024:pokec+t,32:nextt
275 pokecc,2
288 poke650,128
300x=0:y=0
350 getA$
400 ifa$="w"theny=-1
500 ifa$="s"theny=1
600 ifa$="a"thenx=-1
700 ifa$="d"thenx=1
725 x2=xx:y2=yy
750 xx=xx+x:yy=yy+(y*30):x1=x1-x:y1=y1-y
775 ifx1<0thenx1=0
788 ifx1>10thenx1=10
794 ify1<0theny1=0
797 ify1>20theny1=20
798 ifxx<0thenxx=0
799 ifxx>29thenxx=29
824 ifyy<0thenyy=0
837 ifyy>990thenyy=990

850 poke36864,x1:poke36865,y1:pokecc+xx+yy,2:pokec+xx+yy,1
860 ifxx=x2andyy=y2then900
870 pokec+x2+y2,32
900goto300

[Forbidden64]

Looks spot on. 27 = 1B, 255 = FF
1BFF = 7167

Neat experiment. At first I thought ... Oh no, another program that doesn't work on NTSC. Then I saw what you were doing, pretty cool experiment!

[Mike]

I poked 55,255 and 56,27, are my calculations off?

Looks "spot on", but isn't.

Actually, the pointer in 55/56 signifies the first byte above the string heap, that *isn't* used by BASIC. This can easily be checked by looking at the pointer value directly after power-on (or reset): in most cases, the standard memory configurations set 55 to zero. Notable exception being the Super Expander, which reserves some memory at the top of BASIC to store the definitions of the function keys (which don't take a whole 256 byte page and thus result in a non-0 value in 55).

Of course it's generally a Good Idea™ to fully init both 55 and 56 (exactly because of that SE scenario), but to reserve 7168..7679 for UDGs on an unexpanded or +3K expanded VIC-20, you'd do POKE55,0:POKE56,28:CLR where CLR also corrects some other pointers (notably, 51/52) alongside, and which thus don't need to be changed either.

Finally, when you're just lowering the roof, you are not relocating BASIC. The BASIC program stays at the same position as given by the memory configuration on power on (reset). You'd actually relocating BASIC when you're changing 43/44 from the default.

More details can be found in another thread: "How to reinit 16k expansion?".

Greetings,

Michael

[R'zo]

Thank you Mike. Does the Vic always set variable and array pointers automatically? Could you for example set the pointers for variables and arrays to the lower 3k exp. area, screen and caracters to the unexpanded area and then basic to the upper 24k? Would the vic atomatically set the pointers within the basic area?

[Mike]

The BASIC interpreter uses the pointers in 43/44, 45/46, 47/48, 49/50, 51/52 and 55/56 to keep track where various parts of program memory, variable memory, array memory and string memory begin and end.

The following addresses are *required* to be in ascending order, with no physical RAM gaps in the whole range, no compromises: 45/46 (start of variables) <= 47/48 (start of arrays) <= 49/50 (end of arrays + 1) < 51/52 (bottom of string space) <= 55/56 (top of memory + 1). Between 49/50 and 51/52 the memory is not (yet) used, but BASIC extends simple variables and arrays from the bottom into the free range, strings from the top. New strings are continuously allocated into the free space, until 49/50 and 51/52 are on the brink to collide, and then the Garbage Collection is invoked to provide a defragmented string heap and thus again more free space - if that fails, you get an ?OUT OF MEMORY error.

With an empty variable space (after RUN or CLR), 47/48 and 49/50 are automatically set to the value of 45/46, and 51/52 is automatically set to the value of 55/56. As variables are allocated, BASIC keeps 47/48, 49/50 and 51/52 up to date. So much for variable space.

Could you for example set the pointers for variables and arrays to the lower 3k exp. area, screen and caracters to the unexpanded area and then basic to the upper 24k?

In principle, one could place the text of the BASIC program at a completely different place than rightly before the variables, but (and this is a big BUT) this probably makes more problems than it solves.

- Relatively unproblematic is adding some extra space between BASIC program and variables. This keeps the natural 'order' of program/variables and even provides 'hidden' space behind the BASIC program to hold data or machine code. The BASIC stubs of near 100% machine programs are probably the most extreme examples for this.

- What can lead to bigger issues is moving the variable space *below* the BASIC program (what you asked for). One peculiarity of BASIC V2 is, that it keeps constant strings within the program text. When doing the Garbage Collection, BASIC compares pointers to check whether the string is stored in the program text (those don't need to be collected!) or in the string heap, and in this scenario here the GC then would confuse both types and copy the constant strings from the program text into the string heap, which would even consume even more memory or even overwrite valid string data, and this is what we surely wouldn't want!

Finally, your proposal would rely on this still that somewhat obscure requirement of having +3K alongside a bigger RAM expansion. It gives just a meager 3K for the variables, yet most non-trivial BASIC programs are supposed to use more memory for variable data than program text. Before I'd choose to use such a construction, I'd rather have a look at the BASIC program text, where it can be optimized and shortened to make room for more variables.