Loading a second BASIC program from tape

[AndyH]

I've made a game in BASIC, first one I've written for I don't know how long. The game itself just fits into (unexpanded) memory but no space for any instructions. So I figure I can do the old trick of splitting my program into two; 1- the first program with the instructions, then 2- the second program which is the game.

These two programs are stored on tape. I'm hitting a problem where I get an error after loading the second program.

1) if I place a LOAD"":RUN command in the first program, it will load the second program but fails with an OUT OF DATA error on a line that has a READ command. Listing the program at this stage and the program is corrupt - it changes colours half way through, the line numbers go extremely high and I see garbage characters throughout. The last line number is suspiciously 65535 followed by a load of pi characters.

2) If I load and tun the first program, but stop it before it loads the second program and type LOAD"" myself and then run it, it works fine. Listing the program there is no corruption at all.

So I know both tape programs will load and run, just not the second one when I try to load it from the first. I expect I am doing something stupid here. What is the proper way for one BASIC program to load and run a second program?


Some additional information about my two BASIC programs

- I have tried CLR, RESTORE in the first program before loading the second program.
- I am poking 28 to 52 and 56, following the example in the Vic 20 Programmers Reference Guide, so I can poke 255 to 36869 so I can redrefine a small number of characters at 7168. I have tried pokine 30 back into locations 52 and 56, CLR, and poking 240 into 36869 to return to the original values but this has no effect.

Here is a copy of the code I have in the first program to load the second (line 50 I've added during testing to attempt to return to the defaults):

Code: Select all

50 poke36869,240:poke52,30:poke56,30:clr:restore:clr
51 load"":run:rem load the game

[chysn]

Have you tried adding RUN+RETURN to the keyboard buffer, then just LOAD at the end of the first program?

...Or adding LOAD and RUN to the keyboard buffer, and just let the first program end?

The keyboard buffer seems promising for some reason...

[AndyH]

Ah - in my futile search I did see a post from Mike suggesting the first approach but I've written this BASIC program with CBM PRG Studio on Windows and compiling the tape with tools, so I could not see how to insert that character in.

So with the keyboard buffer, you're meaning poke the appropriate codes and then end the program so it types that out and either presses return or triggers the RUN(/STOP)? Hmmmm -ingenious!

[chysn]

Try ending the first program with

SYS 58889

This is where the SHIFT+RUN/STOP key is checked, and the LOAD+$0d+RUN+$0d is put into the keyboard buffer from a table in ROM.

https://www.mdawson.net/vic20chrome/vic ... sembly.txt, see a couple lines after LAB_E602

[chysn]

There's more to it than this, though, because the LOAD doesn't seem to be happening.

I'll play around with it a bit.

Meanwhile, this works, but isn't quite as elegant. Still looking for solutions in BASIC ROM...

Code: Select all

FOR I = 0 TO 8
POKE 631 + I, PEEK(60916 + I)
NEXT I
POKE 198, 9

[AndyH]

Well the pokes work nicely, the second part loads up and runs!

[chysn]

Try this at the end:

Code: Select all

SYS 58889:LOAD

After the ROM routine loads the buffer, it goes back for more characters, which is kind of messing the idea up. So in the above case, you're discarding the LOAD in the buffer, but making use of the RUN. It seems to work nicely in my simple proof-of-concept.

Edit: This is no good. See the POKE method a couple posts down, which really loads via direct mode.

[srowe]

You can't chain load a long program from a shorter one, the end of BASIC/start of variables pointer doesn't get updated

https://www.atarimagazines.com/compute/ ... aining.php

[chysn]

And this just puts the SHIFT+RUN code right into the buffer. This works, too

Code: Select all

POKE 631,131
POKE 198,1

This was sort of a shot in the dark, and I didn't expect it to work any better than the lone SYS 58889. It may work because there's only one thing to do once we get back to direct mode.

[chysn]

You can't chain load a long program from a shorter one, the end of BASIC/start of variables pointer doesn't get updated

https://www.atarimagazines.com/compute/ ... aining.php

I've been playing with chain loading for over an hour this morning (real VIC/real C2N), and yes, I've observed some problems that probably are related to pointers.

I think the last solution I presented (POKE631,131:POKE198,1:END) is the best, because it tricks the VIC into "chaining" from direct mode, under which circumstance the pointers are correctly set. I've been able to run and edit the second program without any trouble using this method. The big difference is that it shows the commands and prompts, which doesn't happen with BASIC program LOAD. You can, of course, hide these with color.

Apparently variables persist with real chaining, which won't happen with a keyboard buffer method, of course.

[tokra]

Using the keyboard-buffer has been the standard-method used to load one program after the other has finished. Most type-ins back in the day worked like this. To make this work independently of the device loaded from, I amend all of the the type-ins I do.

Instead of just POKE631,131:POKE198,1 - which will just LOAD and RUN from tape, I do it like this:

Code: Select all

990?"{CLR}LOAD"CHR$(34)"PRGNAME"CHR(34)","PEEK(186)
991POKE631,19:POKE632,131:POKE198,2

This puts the full LOAD-command at the top of the screen and will add the last-used device from address 186 to the output. The keyboard-buffer then does a HOME+LOAD/RUN - so the program is loaded and run.

[AndyH]

Thanks both, this has got my little game moving again. Two really good solutions for what I need.

[srowe]

I've been playing with chain loading for over an hour this morning (real VIC/real C2N), and yes, I've observed some problems that probably are related to pointers.

The update of VARTAB is conditional on being called interactively rather than from a program

https://eden.mose.org.uk/gitweb/?p=rom- ... HEAD#l8660

This is why stuffing the keyboard buffer works.

[AndyH]

Will be releasing the game later, testing everything and working great. Thanks again!

( click to play GIF )