|
Post by parzival on Mar 16, 2021 20:53:21 GMT
I’ve created two programs that are meant to chain together. One DIMs arrays and loads data into the variables, the other is supposed to manipulate the data. According to the original Commodore 64 manual, Commodore 64 Exposed, and the Commodore BASIC Wiki this should work with a simple 1000 LOAD “PROGRAMNAME”,8 line statement in the loader program should load the new program and pass the variables along, though C64 E suggests the second program must be shorter than the loading program.
In any case, this doesn’t seem to work at all. I’ve removed any CHR$(147) statements just to be sure. Either the whole thing turns into gobbledygook that resets the colors(!), or I get BAD SUBSCRIPT errors from the array, and no data in the variables at all.
Any help?
EDIT Found a link to an old article from the days of the 128, which suggests that strings have to be manipulated in some way (be made “dynamic”) before being passed to another program with the LOAD statement. It suggests a simple X$=X$+”” to trigger the dynamic function of the interpreter. I’m going to try it, but I already have some dynamic strings in the mix— my loader program already combines several strings into a single long string that exceeds the length of a BASIC statement line. So, we’ll see...
ANOTHER EDIT Okay, yes, it worked. Of course, now I’ve run into an OUT OF MEMORY ERROR thanks to this. Not sure I can crunch enough to overcome it...
|
|
|
Post by parzival on Mar 17, 2021 18:44:30 GMT
CRUNCH, CRUNCH, CRUNCH...
Halfway through the manipulator program and it’s “smaller” than the loader, at least. I think I can split the loader into a small intro program (with no variables) which can call the loader program. The loader will wipe it out along with any variables it uses, but it won’t use any that need to be retained, so that falls under “who cares?” I think if I do that split the loader program can be made to work within the memory limits, but I dunno— there are a lot of large string variables to pass on (it’s a text adventure game)— 25 room descriptions of roughly 180-200 characters each, and 209 command and object words, with 73 of those having additional description strings (30 characters each, as an average) and alternate “things have changed” strings in the mix. Yikes. And until I get all this resolved, I won’t even know if the manipulation program works or not!
The funny thing is, this was meant to be just a simple test version prior to a truly big, Zork-level game. But I’m already seeing that’s going to have to be a different animal, probably calling data on-the-fly from the disk drive for use “as needed.” Which at this stage is a bit above my rusty BASIC skills... but I’m getting better at it as the work goes along.
On a side note, I find it a bit amusing that the various programming manuals and books seem to focus in graphics and sound rather than the processing of text data. Understandable, but it seems the concept of recording and processing written data (essentially database manipulation) would get more than just the short shrift I’ve seen so far!
|
|
|
Post by vic2020ian on Mar 17, 2021 22:15:49 GMT
Try the Denial Vic20 forum.
sleepingelephant.com/denial
The Vic20 forum is very active and squeezes a lot out of the machine and drives. There are some big adventures written so you could probably borrow learning from there.
Ian
|
|
|
Post by parzival on Mar 26, 2021 13:58:34 GMT
Okay, quick update after lots of debugging. Data loader and chaining works really well, with one odd exception (more on that in a separate thread). One of my biggest issues was squeezing the size of the secondary program down to below the size of the data loader. I could still probably crunch the data loader down, but as it stands now it and the primary game process program are within 86 bytes of each other, so that’s not gonna happen. Mainly I’m now in the process of catching all the little typing errors and logical-thinking missteps on my part. But there’s one big, weird thing that keeps happening, which I can’t resolve a source for— whenever a certain specific string is printed, the computer produces a series of garbage symbols, or a partial string with numbers, and/or changes the color of the text. The game doesn’t crash, and you can continue to play with no problems, but it’s confusing the heck out of me as to what’s causing it. But that’s a different thread... thec64community.online/thread/857/basic-error-printing-garbled-string
|
|