Login
Back to forumReply to this topicGo to last reply

Posted By

Dunric
on 2004-04-23
22:12:29
 Got the font working now, but...

Hello,

I uploaded the latest version of Wizard Castle, for the C-64, 128 and
Plus/4, here:

http://www.geocities.com/dunric/pauladv.html

But I ran into a strange error...the C64 mode will load the second
program
but then the variables will disappear...everything dimensioned in the
first program is gone.

Any ideas? Is the load used in the first program to blame?

The first program is larger than the second one, as required, and the
line
numbers of the first program are lower (0 through 449) than the second
program (507 through 950).

The strange thing is that the game will work fine in both the C-128 and
Plus/4 modes without any of this nonsense going on. Am I just not doing
something right?

If someone could download the demo (at the very bottom of the page in
the
link provided above), and check it out in C64 mode, that would be
awesome
help.

Reposted from comp.sys.cbm.

Sincerely,

Paul Allen Panks
dunric@yahoo.com
Phoenix, AZ USA

Posted By

JamesC
on 2004-04-24
00:08:16
 Re: Got the font working now, but...

Paul,

I have downloaded your game, and listed it in a Plus/4 emulator three times, but I'm completely missing where the loader is loading the second part of the game.

I really hate to have to copy the disk to a 1541, hook up a C64 and a printer, find a working ribbon, and then print it all out just to find one line.

Can you point out the line in "Start.prg" that loads the remainder of the game?

Posted By

Dunric
on 2004-04-24
01:41:26
 Re: Got the font working now, but...

Lines 37 and 38 load the program, depending on the operating mode of the machine.

If it's a Commodore 128 or Plus/4, line 37 is run.
If it's a Commodore 64, line 38 is run.

The C-128 and Plus/4 mode version appears to function normally,
but in the C-64 mode most of the variables/strings are overwritten when
the first program "start.prg" loads the second program "wc.prg".

The commands used are:

37 IFPEEK(65534)<>72THENDLOAD"WC":RUN
38 LOAD"WC",8:NEW

Paul

Posted By

Ulysses777
on 2004-04-24
09:39:00
 Re: Got the font working now, but...

The C64 (and apparently any BASIC 2.0 machine) appears to have a lot of problems with string variables when chaining programs. Not sure if there's a workaround for this.

By the way, LOAD"WC",8 should work on any machine, you shouldn't need a line for DLOAD. (unless I'm missing something) happy Also, you shouldn't need the RUN and NEW commands on those lines, as 1) they don't get executed, because loading the new program deletes those lines, 2) they'd reset the variables anyway.

Posted By

SVS
on 2004-04-25
10:56:22
 Re: Got the font working now, but...

After a loading operation performed in rrun mode (that is inside a program), the BASIC automatically execs a RUN 0, then the first line of the just loaded program is executed (it could be different than line number 0).
Differently than GOTO, execution of RUN will CLeaR every variable in memory, looking at pointers at $2F... in zeropage.
The real problem (common to all the CBM BASIC versions) is that these pointers are set on the base of ending point of program in memory. Both starting and ending addresses of a program just loaded are set, ONLY if the program was loaded in direct mode. Thus if a loader program loads another program, the second is yes executed, but the pointers at $2B.... are not updated. The execution of the automatic RUN will clear the variables (and other functions) using the old addresses in zero page. This could result in a mess IF the second program is longer than the first one.
The solution is to manually calculate the addresses of second program and POKE their values onto $2B... by a Basic line before that one with the LOAD. In this way when the second program is loaded, it will find the rights pointers and its automatically clearing will not cause domage.
Hope this could help happy

Posted By

Dunric
on 2004-04-26
01:13:16
 Re: Got the font working now, but...

How should I load it from BASIC without losing the variables/strings? It works fine on the Plus/4 and Commodore 128 modes, but it appears as though the C64 doesn't quite have enough free space to store some of the variable/strings, as they just come out as
jibberish.

See below:

http://www.geocities.com/dunric/c64other.html

As is usual on the C64, it has free space enough for only some of the strings and variables defined by the first program, but the overall size (26KB) of the second program, combined with the strings being passed, messes up data. The Commodore 64's BASIC has severe limitations when compared to the C128 and Plus/4. 38,911 bytes is simply not enough memory to write a large text adventure, even when storing the data to disk. ML programs which use most of that 64KB memory are better suited. BASIC 2.0 is clearly not.

Sincerely,

Paul Panks
dunric@yahoo.com
Phoenix, AZ (USA)

Posted By

SVS
on 2004-04-26
03:05:12
 Re: Got the font working now, but...

Try these steps:
1) pre-Calculate yourself (not the program) the exact addresses of second program, then insert in the first program the proper POKEs to redefine the variable area as it have to be when second program runs (finish with a CRL);
2) the second program should make more FRE(x) executions. This function performs a "garbage collection" from the strings, then after it you'll have more space.
Bye

Posted By

seff
on 2021-05-01
08:54:06
 Re: Got the font working now, but...

Chaining, Load-Linking and Overlaying were great techniques available in 1982.

Loading and Linking Commodore Programs, Part 1-5:

https://www.atarimagazines.com/compute/issue70/088_1_Loading_And_Linking_Commodore_Programs.php
https://www.atarimagazines.com/compute/issue71/loading_linking.php
https://www.atarimagazines.com/compute/issue72/loading_and_linking.php
https://www.atarimagazines.com/compute/issue73/loading_and_linking.php
https://www.atarimagazines.com/compute/issue74/loading_linking_part5.php

Chaining Rules
Let's summarize the rules for well-chained programs:

• The first program in the chain must be as big or bigger than all subsequent programs.
• Any strings you need to pass from program to program must be dynamic, not static.
• If you use DEF FN definitions, redefine them in each program.
• Arrays should be DIMensioned only once, preferably in the first program.




Back to topReply to this topic


Copyright © Plus/4 World Team, 2001-2024