Multifile games

[SteveB]

In order to save memory I was thinking about a game where the character definitions are done in one program and the actual game is loaded from a second file.

 

In order to chain the two programs ... how do I know which drive the two files are on? So I can load the second file from the same drive where the first was from. Or need I force the user to use DSK1 ?

 

[RXB]

40 minutes ago, SteveB said:

In order to save memory I was thinking about a game where the character definitions are done in one program and the actual game is loaded from a second file.

 

In order to chain the two programs ... how do I know which drive the two files are on? So I can load the second file from the same drive where the first was from. Or need I force the user to use DSK1 ?

 

You mean like RXB does this?

It loads the entire VDP screen and graphics definitions from one file.

Or like this:

Sorry wrong Youtube clicked!

[+TheBF]

1 hour ago, SteveB said:

In order to save memory I was thinking about a game where the character definitions are done in one program and the actual game is loaded from a second file.

 

In order to chain the two programs ... how do I know which drive the two files are on? So I can load the second file from the same drive where the first was from. Or need I force the user to use DSK1 ?

 

Maybe this is too simple for your needs but the 99 disk system let's you access disks by name not just number.

 

So you can name a disk  MYDISK and then access it with DSK.MYDISK.VDPSETUP  and DSK1.MYDISK.THEGAME 

 

If MYDISK is loaded in a drive then TI-99 will find it. 

 

 

[senior_falcon]

4 hours ago, SteveB said:

In order to save memory I was thinking about a game where the character definitions are done in one program and the actual game is loaded from a second file.

 

In order to chain the two programs ... how do I know which drive the two files are on? So I can load the second file from the same drive where the first was from. Or need I force the user to use DSK1 ?

 

Is this in XB, compiled XB, assembly, or something else?

[+Schmitzi]

4 hours ago, TheBF said:

Maybe this is too simple for your needs but the 99 disk system let's you access disks by name not just number.

 

So you can name a disk  MYDISK and then access it with DSK.MYDISK.VDPSETUP  and DSK1.MYDISK.THEGAME 

 

If MYDISK is loaded in a drive then TI-99 will find it. 

 

 

 

Hi, is this due to the controller ?

If so, is this every controllers behaviour ?

 

 

[pixelpedant]

Presuming this is in an XB context (since this doesn't really work in a TI BASIC context), you could have an ON ERROR handler which tries DSK1.MYFILE, DSK2.MYFILE, and DSK3.MYFILE in turn until one of them works.  Then, if *none* of them work, angrily prompts the user for the disk name.

[apersson850]

Whatever the language is, start a loader program which asks for the drive name. Then that loader reads the graphics and then the game itself.

[+Vorticon]

8 hours ago, pixelpedant said:

Presuming this is in an XB context (since this doesn't really work in a TI BASIC context), you could have an ON ERROR handler which tries DSK1.MYFILE, DSK2.MYFILE, and DSK3.MYFILE in turn until one of them works.  Then, if *none* of them work, angrily prompts the user for the disk name.

Never thought of that before. Great way to do load tracking! Definitely something I'm going to use in the future.

[+TheBF]

9 hours ago, Schmitzi said:

 

Hi, is this due to the controller ?

If so, is this every controllers behaviour ?

 

 

I believe it's part of the disk DSR so that would be in the controller card.

I used to do it with BASIC programs that I wrote.

Now I need to test it with something else to answer your question.  

 

[pixelpedant]

5 hours ago, Vorticon said:

Never thought of that before. Great way to do load tracking! Definitely something I'm going to use in the future.

 

Further to this, here is an ON ERROR approach which 

1) Tries to find a DV80 called MYFILE on DSK0 through DSK5

2) If that fails, prompts the user for the disk name and tries that

3) If that fails, prints "DISK NOT FOUND" and terminates.

 

10 ON ERROR 40
20 OPEN #1:"DSK"&STR$(W)&".MYFILE",INPUT
30 GOTO 120
40 W=W+1
50 IF W<6 THEN 10
60 INPUT "DISK NAME? (E.G. DSK9):":DSK$
70 ON ERROR 90
80 GOTO 110
90 PRINT "DISK NOT FOUND"
100 STOP
110 OPEN #1:DSK$&".MYFILE",INPUT
120 ON ERROR STOP
130 PRINT "LOADING..."
REM WHATEVER WE DO WITH THE FILE GOES HERE

 

Of course, file type can be whatever, but it is imperative that the file be explicitly opened as INPUT, since if the open mode is not specified, an absent file will simply be created, and no error will be generated.

 

[SteveB]

This is great! 

 

I have no additional hardware and SCSI and IDE are getting out of fashion, but how are TIPI drives named? 

 

I like the approach of guessing-before-asking. I also did some (V)RAM dumps to check and if you started the program with <RUN "DSK4.BISBEE-C"> you have a chance to find remainders in the XB crunch-buffer:

 

But I would not rely on this .. and did not find any more traces of something we later came to know as a "working directory".

 

 

 

[pixelpedant]

An alternative approach in any (TI) BASIC incidentally would be to read the disk's file index and check whether the file's there, before proceeding to try to open it.  However, this would be slightly more involved than the ON ERROR method. 

 

The original scenario mentioned here (where all patterns are loaded by one program file and the rest of the program is in another file) is not as usefully achievable in TI BASIC, incidentally, since RUN can't pass control to a new program, and only the patterns from 128 to 159 are preserved on return to the immediate mode.  Now, that is a chunk of custom patterns you have available to redefine permanently (until reboot).  But it's not as many as one might like, in this scenario.

 

The situation is better on the TI-99/4.  Since patterns from 96 to 159 are preserved in immediate mode.  So that's a pretty large supply of "persistent" patterns. 

 

The upshot of all this being of course that it makes a lot more sense to load patterns from a dedicated pattern file, in TI BASIC, if you're using a disk. 

 

 

[+TheBF]

5 hours ago, TheBF said:

I believe it's part of the disk DSR so that would be in the controller card.

I used to do it with BASIC programs that I wrote.

Now I need to test it with something else to answer your question.  

 

For closure on this I confirmed that this works with the E/A cartridge. 

I loaded  DSK.CAMEL99.CAMEL99 and it tried DSK1 for a few seconds and jumped to DSK2.