Sorry, I'm on a bit of a roll here. (Trying to as much as I can before going back to work after the Christmas break!).

So, my question is about the "RUN" command. Is this the only way that one STOS program can call another?

My dilemma is that I want one program to call another, but without the inevitable white screen that seems to pop up when you do. So, within program A, I have a line that reads:

RUN "B.PRG" (or whatever).

The problem is that there was an image on screen. It disappears when B.PRG starts loading and everything turns white, which looks sorta rubbish. Ideally, I'd like the image to stay on screen to a black background. Any ideas?

I don't think you can actually call PRG files that way within STOS. PRG's are normally compiled programs which run in GEM not STOS environment.

The only PRG you can call is within a memory bank, normally you can call assembly routines that way, such as some tracker code is called from a memory bank, and the STOS program sends data to the routine normally by address and data registers.

I should add that it's a compiled STOS program calling another compiled STOS program. My "menu" does seem to work without issue. Perhaps my gripe about it loading with a blank white screen is quite minor then...

I should add that it's a compiled STOS program calling another compiled STOS program. My "menu" does seem to work without issue. Perhaps my gripe about it loading with a blank white screen is quite minor then...

I had to try that myself as it shouldn't have worked at all. The manual says the RUN command is for running BAS files only. I'm also pretty shocked the compiler actually lets you compile a editor command (it shouldn't). Though the manual states programs should be protected with protect.bas which excludes the editor commands, so it seems you stumbled on a combo which shouldn't work at all, but actually does!

So pretty much your "white screen" is when the PRG file quits to TOS then loads/run your second program. TOS is by default a white screen. Your not actually running any STOS program while loading is happening, the OS/TOS is in control.

So, the big question is this - I've seen a lot of STOS MegaDemos and such like, ones that are loading multiple demos in parts, or allowing the user to select which screen they want to see from a menu. How are they doing it? (If they're not using RUN?)

exxos wrote:I've been using an "undocumented feature" to my advantage.

So, the big question is this - I've seen a lot of STOS MegaDemos and such like, ones that are loading multiple demos in parts, or allowing the user to select which screen they want to see from a menu. How are they doing it? (If they're not using RUN?)

M.

You tell me, your now the expert on this undocumented feature

I don't know about demos, its been like 15+ years since I did any real coding in STOS. The only ones I remember were ones which just ran BAS file in the editor.

The way I would have done it/ OR / *should be done* , would be to simply write all the demos, then just use RENUM and renumber them in multiple of 10,000 or something, then your menu can just jump to demo 1 aka line 10,000, demo 2 aka line 20,000 etc If you total code length is over 65530 lines then you might have issues

If your using memory banks, you just load them in as MBK's as you need them (or MBS but not sure if that works on compiled programs). This way, if one demo uses different sprites, you can load the MBK in as you need it. If you use multiple screen banks, then you have several screen banks to chose from, or I think something like the missing link may allow you to pack multiple screens in a bank. Though you could easily program that anyway. Though of course you will eat up more RAM the more you load in at once.

Overall, your loading times would be a lot less in compiling everything into a single PRG file. Each time you load a PRG your loading in all the STOS support code, so multiple PRG's means your eating up a lot of disk space for no reason at all.

I've just had a look at Flair's "Cunning Demo". I think they cheated a bit, because they created something called "LOADER.PRG" in the Auto folder. It's only 6K, so there's absolutely no way it's a STOS program (even if they used a packer on it). They must've created a loader in devpac.

The individual demos as just program files that they removed the .PRG extension from (you can rename it back and it loads fine), so I guess it's not the most efficient way of doing things. There's a few memory banks saved on the disk, but not many.

So, I think the answer to my original question is that I'll need to write an ASM loader to do what I originally wanted.

mrdalliard wrote:I've just had a look at Flair's "Cunning Demo". I think they cheated a bit, because they created something called "LOADER.PRG" in the Auto folder. It's only 6K, so there's absolutely no way it's a STOS program (even if they used a packer on it). They must've created a loader in devpac.

The individual demos as just program files that they removed the .PRG extension from (you can rename it back and it loads fine), so I guess it's not the most efficient way of doing things. There's a few memory banks saved on the disk, but not many.

So, I think the answer to my original question is that I'll need to write an ASM loader to do what I originally wanted.

M.

Why bother with a ASM loader when you can just program everything into 1 program anyway ? Like I said before, your going to be compiling STOS itself each time you compile a PRG. Thats probably 40K each PRG file which you don't need.

You can use an ASM loader and you can CALL programs from within STOS programs... sorted of nested programs but these tend to be small routines and such, tracker players or 512k spectrum viewers...My adivce is also to build multiple BAS files and merge them .. BE AWARE... you need to make sure all the listing numbers are different otherwise old code gets overwritten, for example

then the second would overrwrite the first...You can have 65k lines of code btw and renum them 1,1 so it goes 1.2.3. or renum 10,100 so it goes 110,210,310..the manuals a bit rubbish at stuff like this ..