|
|
Post by parzival on Mar 15, 2022 21:49:53 GMT
My BASIC text adventure game has maxed out the system; it largely works, but it does so at a crawl, with frequent “garbage dumping” pauses. I’ve done what I can to simplify the parser and strip excess IF THENS, FOR NEXT loops, etc.., but it’s all still too slow. Alas, machine code is not something I can do (yet), but I’m thinking maybe I can just cheat the C64 into acting like the modern-day hardware it actually is. Am I correct that the emulator slows down the clock to match the limitations of an actual Commodore 64 6502 hardware? And likewise that the RAM access is artificially restricted to 64K? And if that is the case, is there some way to tell the emulator to “goose” the speed and RAM availability up to what the hardware can handle (or at least something faster with more memory to hold the program)?
|
|
|
|
Post by c64stuff on Mar 15, 2022 23:03:36 GMT
I think you can launch vice and the SuperCPU on the mini and maxi? But even if I'm right about that I think someone said it will not run as fast as it should unless you're running vice on a PC or raspberry pi or something.
Far as memory expansion goes isn't basic on the C64 limited in it's ram access by the amount of memory and kernal/basic ROM the CPU can see at the same time without memory banking? Then again I think the C64 has a little more ram available than basic has access to but this ram sits at a higher address above the rom and that's I think why basic doesn't have full access to 64k of ram free. I think the ram for basic has to be continuous.
It's been years so I'm sure somebody will correct me if I'm wrong.
Short of anything else anybody might suggest that may be a better idea, maybe you could write one or a few of your most cpu intensive subroutines that keeps getting used over and over again in machine language and pass the few variables needed for it from basic to machine language and back again? This is how I speeded up the bulletin board I wrote back in the day. The majority of the BBS was in basic but I wrote a routine to read text files off disk and spit them out to both the bbs screen and modem in machine language because otherwise basic was too slow reading the text file and sending it out to modem and screen even to max out 300 baud modem speed.
Later on the amiga i wrote another BBS in basic but I used a compiler to compile it into a faster machine language version. Worked great.
I'm not sure but if you add ram expansion I think the C64 basic has to have a few of it's basic and screen editor memory pointers poked to change them to start at a different location higher up where you'd then have your longer continuous run of RAM, but again there's a limit on how much ram and rom the CPU can see at one time without using bank switching to see more.
Again, somebody will I'm sure correct me if I've got the details wrong.
Edit: One more idea. You could only load in smaller portions of the game as it progresses and erase prior old code or variables. I remember seeing basic programs that did this, including a commercial BBS program. If memory serves there would be a root basic program and it would somehow load in new basic below it when needed. I don't remember how this was done, but if you could keep loading in smaller groups of code or at least your variables used by existing code when needed then this should speed it up a bit if basic is getting sluggish when ram is being maxed out.
One more idea. Again, this is from memory so forgive me if I'm wrong, but wasn't there commands in basic to clear old variables being stored? I think there was something like that and it was to do this very thing, to free up memory and gain a little speed. I might be confusing this with what was available in Amiga basic though.
|
|
|
|
Post by parzival on Mar 22, 2022 2:33:48 GMT
Much of that is quite beyond my programming skills. Fortunately, I’ve gotten the code now to where the game can parse even a complicated sentence and carry out commands at decent speeds. The typical two word command will parse and execute within 3 seconds or less. More complex sentences will take longer, but anything over three words isn’t treated as a command (the actual structure of any command is Verb Noun Noun— articles, prepositions, adjectives, etc. are simply ignored). So about 9 seconds is the longest parse anyone is likely to force. My real problem is the so-called garbage collection routine of Commodore Basic V.2– the version in the C64 Maxi. Apparently, the Commodore 64 handles dynamic strings in an unusual way that fills up the memory with wasted unused string space as strings are manipulated and altered by a program. When it gets full, the system clears things up automatically, but it’s unpredictable, locks up the computer, and can take a great deal of time to perform— even hours! It can be triggered with the FRE function, but that just means you get to set a point where it WILL happen— but you can’t establish how long it will take, or if it will happen again. More here: retro64.altervista.org/blog/garbage-collection-commodore-64-basic-to-handle-it/ I’ve done what I can so far to limit it; I’ve buried a trigger into the game after the initial loading of all the string data to knock out at least one round of garbage collection while the reader is viewing the adventure set up text. It’s still too long (takes about 30 seconds), but it’s bearable. My problem is when the garbage collection kicks in mid-adventure. I’m pretty certain it’s largely triggered by the parsing routine, which uses temporary string variables to build up individual words from an INPUT string holding the player’s commands. So the command: TAKE FLASHLIGHT will involve two strings being manipulated and changed 14 times as the parser goes through the message character by character. One string pulls out each character, one at a time, and the other string is built by concatenation, with the space being the clue that the concatenation has ended. The word string is then compared to the game’s list of verbs and nouns, and so on. Once this is done, the variables are cleared, but obviously the whole garbage problem is present. I’ve read the above linked article, but honestly I’ve never used PEEK or POKE (didn’t really have to on the machines I learned on— TRS-80 and later the Mac), so the talk of High Byte and Low Byte and stack and memory locations means, well, not a lot to me. The examples in the article aren’t what I’m doing, so I have no idea how to translate that into the structure of my code, or even if that’s possible. Fortunately, most of the game code is using numbers, not strings, with the numbers tied to arrays where the string value has been set and the pointer is to the location in the program and not in the string space. Numbers and numerical variables at least don’t trigger garbage collection! Still working on it. And one of these days I’ll try to learn how to punch some of this into machine code… but that’s not something I know how to do right now. |
|
|
|
Post by c64stuff on May 24, 2022 14:21:16 GMT
See the thread about the new Vision BASIC for the C64. It looks to be the answer to all your problems. It not only is highly compatible with the commands of the old Commodore basic so you can easily run old programs on it, but once the program is compiled for amazing speed others can play your text adventure without the need of having vision basic since it's now converted to native machine language. This new basic also features powerful graphics and sound commands, memory banking, and a full 64k of basic memory available for use (and beyond that with memory banking). This even opens up the possibility for you to add graphics to your game to make it a graphics text adventure without much effort in writing it.
|
|
|
|
Post by virtualsky on May 24, 2022 19:56:24 GMT
Maybe take a look at this little BASIC utility, Quikrunch. It will analyze a BASIC program and try to condense it as much as possible. Just make sure you make a copy of your original program first. After Quikruch does its job, it's pretty difficult to read. A link to the disk image that has Quikrunch on it is at the top of the web page. Don't know if it will help you at all, but you never know. |
|
|
|
Post by parzival on Oct 3, 2022 15:17:54 GMT
After a looong time away from working on this, I’m giving it another look. At this stage, I’m thinking of experimenting with PEEKing and POKEing the memory locations as suggested in this article retro64.altervista.org/blog/garbage-collection-commodore-64-basic-to-handle-it/ (also linked above) for both the data loading program and the actual game program. First time attempting such coding, but there’s always a first time, etc., etc.. Will report in if it works. |
|
