Writing an Extended BASIC game too big for memory

[Cheung]

I already posted this question on FB but didn't really get any response: I've been working on a new game that's getting to be pretty big - too big to fit it all in expanded memory. I've worked around this by having the program broken up into sections with each program calling the next one. For instance:

Start->intro->instructions->level1->level2->etc.

 

So this seems to work fine when the programs are all on a specific disk. But how would this work for a cartridge? What would need to be changed to get this working for cartridge if this is even possible? For disk, it's just a matter of calling:

RUN "DSK1.LEVEL1"

or whatever is the next program in the sequence.

Thanks

 

 

 

[GDMike]

3 hours ago, Cheung said:

I already posted this question on FB but didn't really get any response: I've been working on a new game that's getting to be pretty big - too big to fit it all in expanded memory. I've worked around this by having the program broken up into sections with each program calling the next one. For instance:

Start->intro->instructions->level1->level2->etc.

 

So this seems to work fine when the programs are all on a specific disk. But how would this work for a cartridge? What would need to be changed to get this working for cartridge if this is even possible? For disk, it's just a matter of calling:

RUN "DSK1.LEVEL1"

or whatever is the next program in the sequence.

Thanks

 

 

 

Edit. Didn't see that last little bit of your question till now..

Be more specific if you can regarding, "cartridge" which cart? Since each does something different. Or are you creating a cartridge?

 

Old info....

Basic program's can call another program by "stringing" as you suggest, you could also load data and reuse that data once it's been used up by reading more data in. 

You could purchase SAMs 1 Meg card and map banks of 4K and make 1 or more banks swappable for 1 of the 32K memory banks without interrupting that bank as a temp holding area 

Edited April 30, 2022 by GDMike

[+FarmerPotato]

@Cheung

When you say cartridge, do you mean you are trying the XB compiler? 
 

XB programs by themselves can’t be stored and run in a cartridge.  
 

Feel free to ask questions how to reduce memory footprint!

 

The easiest thing is to have short variable names.
 

I use an array $_ to store global strings, which  can be read from a file. Then DISPLAY AT(1,1):$_(1) for instance.  
 

another tip is to turn off prescan. This makes the “stringed” program (or any) start up faster. 
 

[HOME AUTOMATION]

Yes, did you have a type of cartridge hardware in mind? ...or perhaps you just want a .BIN file for emulation.

 

Are you using the lower 8K?

 

I know a few tricks to using the FinalGROM 99's advanced features...

I think I could get you to a SAVE/RESTORE state from where you could run your XB program as if it were the cartridge. You would have to contend with a few lines of assembly code to bounce the data around. You can get direct access to nearly 1Mb of ROM/RAM, if you don't mind juggling the data around some. You could also run multiple carts in progression.

[tmop69]

55 minutes ago, HOME AUTOMATION said:

Yes, did you have a type of cartridge hardware in mind? ...or perhaps you just want a .BIN file for emulation.

 

Are you using the lower 8K?

 

I know a few tricks to using the FinalGROM 99's advanced features...

I think I could get you to a SAVE/RESTORE state from where you could run your XB program as if it were the cartridge. You would have to contend with a few lines of assembly code to bounce the data around. You can get direct access to nearly 1Mb of ROM/RAM, if you don't mind juggling the data around some. You could also run multiple carts in progression.

 

I think the initial request is the same that all people developing with XB+Compiler have. I'll try to summarize with an example:

 

we have a XB program that will be compiled and the EA5 files converted to a SSS using Module Creator 2 (so a "8.bin" cart). It has a "Title/Intro" screen, a "Level 1" and a "Level 2", etc. These cannot stay all in the 24K space. The desiderata is to be able to "jump" after the "Title/Intro" screen to "Level 1", then to "jump" to "Level 2", etc. In case of death to "jump" back to "Title/Intro", etc. Some variables should be maintained eg. score, lives, high score, etc.

 

Basically, the request is to have a sort of "bank switching" for compiled XB code that have to be run in SSS. To run on FinalGROM, but also on emulators/MiSTer, etc. It should also be compatible with XB256.

 

Is it feasible? 

 

Edited April 30, 2022 by tmop69

[HOME AUTOMATION]

...Perhaps.

 

Old Chinese proverb... There's more than one way to skin a cat!?

 

Though, my way is somewhat proprietary now. I believe Emulators/Mister could support FG99's paging.

[Asmusr]

It sounds doable. The parts would be responsible for saving and restoring the shared variables, e.g. using VDP RAM as temporary storage, before and after a switch. Depending on how you created the combined bin there could already be code in cartridge space that you could call to do the switch, so all you would need to do would be to switch the bank and call the code. You would need a 'module creator' that supported placement in any ROM bank.

[tmop69]

15 minutes ago, Asmusr said:

It sounds doable. The parts would be responsible for saving and restoring the shared variables, e.g. using VDP RAM as temporary storage, before and after a switch. Depending on how you created the combined bin there could already be code in cartridge space that you could call to do the switch, so all you would need to do would be to switch the bank and call the code. You would need a 'module creator' that supported placement in any ROM bank.

Great. ? So, someone of the assembler gurus here on AA could provide these tools/routines? I can help for tests. This addition surely will help to improve the possibilities of XB compiled games.

 

 

[Cheung]

The intent is to compile the program. It will currently run on disk with no issues - it would be nice if a BIN file for ROM could be made. Not sure how to do that given the current configuration. I am not passing variable values between the programs/loaded sections.

   Information that the newly loaded sections need will be read from the screen of the previous section. So the screen itself will act as a storage medium for data that must be shared between the level: score, health, items collected, etc.

   

Edited April 30, 2022 by Cheung
Clarifying

[Asmusr]

6 hours ago, tmop69 said:

Great. ? So, someone of the assembler gurus here on AA could provide these tools/routines? I can help for tests. This addition surely will help to improve the possibilities of XB compiled games.

My module creator tool should be able to do this, but it has been a while since I tried this feature. You need java installed to use the tool, and you run it like this:

java -jar ea5tocart.jar [path to EA#5 file in TIFILES format] [name of cart] [destination ROM bank]

for instance:

java -jar ea5tocart.jar ea5files\PINBALL "MY PINBALL GAME" 0

This would produce a 32K pinball8.bin file in the ea5files directory intended to run from ROM bank 0.

So the idea would be to compile the parts separately (each producing a set of E/A#5 files), then use my tool to generate bin files for each part (each producing a 32K file), and then combine the files into one, e.g. using copy /b. The first part should have 0 as destination bank, the second 4, the third 8, and so on.

To switch to a new part from the XB code you would need to change the ROM back by writing to >6000 for the first part, >6008 for the second part, >6010 for the third part and so on, and then execute the machine code in the ROM that copies the part into 32K at >603C (this is specific to my tool). You can use CALL LOAD to switch the bank, but you would need assembly support to be able to execute arbitrary machine code. Maybe XB256 has something you can use? I think there is something called CALL LINK("X")? @senior_falcon

Calling >603C should not change VDP memory, so unless a compiled program initializes the VDP memory, it should be fine to use it to preserve data.

This is all speculation, I have not tried it and don't intend to. But if you use my module creator and find some issues I'm happy to look into that.

 

ea5tocart.jar

Edited April 30, 2022 by Asmusr

[RXB]

For SAMS support RXB is king after all the commands do not require a CALL LINK or CALL LOAD to switch banks.

 

You can load the SAMS using CALL PLOAD(memory-boundry,"DSK1.FILENAME")

 memory-boundry is TI99/4A memory in hexadecimal 2=>2000 hex or 3=>3000 or A->A000 or D=>D000

So RXB has a built in LOADER for SAMS up to 32Meg using Classic99. Oh also CALL PSAVE is how you save these.

 

For SAMS Bank and Page switching use CALL SAMS(memory-boundry,number)

 memory-boundry is explained above and number can be 0 to 32767 that is 64Meg of SAMS but Classic99 only supports up to 32Meg so 16383 is the limit

Now Bank and Page switching is AUTOMATICALLY done for you in a single NUMBER like 8734 Decimal represents that page and bank used.

This makes using the SAMS much more manageable and easy to keep track of what you are doing.

I am not a gamer but I did create a game called IN THE DARK that used 832K of SAMS to play game, though main distribution is only 342K version.

It uses Assembly loaded at >D000 just next to XB program that runs it, also rest of SAMS is used to load screens of the game.

Additionally it saves what you do playing the game and will take weeks to finish in the 832K version.

 

Give RXB a try it is for those that are not into Assembly yet as that is a real steep gradient to master.

 

 

 

[tmop69]

7 minutes ago, RXB said:

For SAMS support RXB is king after all the commands do not require a CALL LINK or CALL LOAD to switch banks.

 

You can load the SAMS using CALL PLOAD(memory-boundry,"DSK1.FILENAME")

 memory-boundry is TI99/4A memory in hexadecimal 2=>2000 hex or 3=>3000 or A->A000 or D=>D000

So RXB has a built in LOADER for SAMS up to 32Meg using Classic99. Oh also CALL PSAVE is how you save these.

 

For SAMS Bank and Page switching use CALL SAMS(memory-boundry,number)

 memory-boundry is explained above and number can be 0 to 32767 that is 64Meg of SAMS but Classic99 only supports up to 32Meg so 16383 is the limit

Now Bank and Page switching is AUTOMATICALLY done for you in a single NUMBER like 8734 Decimal represents that page and bank used.

This makes using the SAMS much more manageable and easy to keep track of what you are doing.

I am not a gamer but I did create a game called IN THE DARK that used 832K of SAMS to play game, though main distribution is only 342K version.

It uses Assembly loaded at >D000 just next to XB program that runs it, also rest of SAMS is used to load screens of the game.

Additionally it saves what you do playing the game and will take weeks to finish in the 832K version.

 

Give RXB a try it is for those that are not into Assembly yet as that is a real steep gradient to master.

 

 

 

 

Yes, it's cool, but unfortunately you cannot compile an RXB program. ?  The improved speed from compiled code is now a must. You should really think of creating an RXB compiler...

 

[RXB]

4 hours ago, tmop69 said:

 

Yes, it's cool, but unfortunately you cannot compile an RXB program. ?  The improved speed from compiled code is now a must. You should really think of creating an RXB compiler...

 

DUDE do you know why XB is not compiled by Texas Instruments in first place?

It is a BEGINNERS LANGAGE not ASSEMBLY and you just indicated XB should be a COMPILED LANGUAGE the opposite of the definition: 

 

BASIC (Beginners' All-purpose Symbolic Instruction Code) is a family of general-purpose, high-level programming languages designed for ease of use.

BASIC - Wikipedia

 

If I wanted XB to be a ADVANCED LANGUAGE I instead would work with C like everyone else on planet!

How come you are not USING C like rest or world?

 

See ease of use is not assigned to any low level language like Assembly or C or FORTH or Lisp or Python.

 

P.S You can not change things in these low level languages fast and easy like XB, and you need MULITIPLE COPIES to do so

i.e. Source, Object (Compiled output file), Listing and a folder to put it all into.

XB just needs the program itself and 2 seconds to make changes and save it again, HENCE EASE OF USE!

[Cheung]

  XB and Basic are too slow to make decent games with. Having the OPTION to compile XB ala XB256 changes that. Now, we are able to program decent (for the platform) games compiling XB256.

   TI games were always behind comparable platforms for the age (Commodore, Atari) and Basic and XB restricted the ability to take full advantage of what was possible for the system.

   There wasn't a way to program in assembly for the TI without expanding the system - which many could not afford to do back in the 80's ( I quit my paper route after buying my TI because I was from that point on a future millionaire game programmer).

   I've made games for other platforms using C, C++, Java, QBasic, Visual Basic and I've decided to return to TI XB game programming (my first computer) to see what is now possible on the platform using these updated tools.

   I want to see if TI homebrew games can approach the quality of games that were available on other systems like the C64.

[senior_falcon]

1 hour ago, RXB said:

DUDE do you know why XB is not compiled by Texas Instruments in first place?

It is a BEGINNERS LANGAGE not ASSEMBLY and you just indicated XB should be a COMPILED LANGUAGE the opposite of the definition: 

 

BASIC (Beginners' All-purpose Symbolic Instruction Code) is a family of general-purpose, high-level programming languages designed for ease of use.

BASIC - Wikipedia

 

If I wanted XB to be a ADVANCED LANGUAGE I instead would work with C like everyone else on planet!

How come you are not USING C like rest or world?

 

See ease of use is not assigned to any low level language like Assembly or C or FORTH or Lisp or Python.

 

P.S You can not change things in these low level languages fast and easy like XB, and you need MULITIPLE COPIES to do so

i.e. Source, Object (Compiled output file), Listing and a folder to put it all into.

XB just needs the program itself and 2 seconds to make changes and save it again, HENCE EASE OF USE!

I just had a great idea. I don't know why I never thought of this before. When you are developing a program, you could write it completely in XB. XB makes it easy to test it, see where it needs work, make changes, test again, add another screen, test again, and so on. All in XB which has the ability to quickly make changes and test them immediately.

Once it is finished, only then would you put in the compiler disk, and load the program you just wrote and tested in XB. Then press Enter about a dozen times and voila! you have the same program that runs 30x faster.

Just a thought...

 

 

[+OLD CS1]

1 hour ago, Cheung said:

XB and Basic are too slow to make decent games with.

Perspective.  A good number of useful and decent games have been writing in both.  Maybe lacking certain bells and whistles, but I would not call them not decent.

 

2 hours ago, RXB said:

DUDE do you know why XB is not compiled by Texas Instruments in first place?

It is a BEGINNERS LANGAGE not ASSEMBLY and you just indicated XB should be a COMPILED LANGUAGE the opposite of the definition: 

There is no reason that compiling BASIC would be any worse or better than compiling other languages.

[Cheung]

26 minutes ago, OLD CS1 said:

Perspective.  A good number of useful and decent games have been writing in both.  Maybe lacking certain bells and whistles, but I would not call them not decent.

 

Can you point to some? Most of what I've seen are really quite bad.

[Cheung]

1 hour ago, senior_falcon said:

I just had a great idea. I don't know why I never thought of this before. When you are developing a program, you could write it completely in XB. XB makes it easy to test it, see where it needs work, make changes, test again, add another screen, test again, and so on. All in XB which has the ability to quickly make changes and test them immediately.

Once it is finished, only then would you put in the compiler disk, and load the program you just wrote and tested in XB. Then press Enter about a dozen times and voila! you have the same program that runs 30x faster.

Just a thought...

 

 

Yes, this is how I do it.

[GDMike]

2 minutes ago, Cheung said:

Can you point to some? Most of what I've seen are really quite bad.

Bad? For what year? Most written 30 or More years ago I think. .. so maybe comparing incorrectly?

[Cheung]

Just now, GDMike said:

Bad? For what year? Most written 30 or More years ago I think. .. so maybe comparing incorrectly?

The ones written in the 80s. I haven't come across any written recently that are strictly in uncompiled XB/Basic that are particularly noteworthy.

[GDMike]

In the 80s people were fascinated by what just basic could do. Just being able to save a file to disk, being able to print to a printer..... and don't get me started on hearing speech.. awesome technology in 1983.

Edited May 1, 2022 by GDMike

[Cheung]

3 minutes ago, GDMike said:

In the 80s people were fascinated by what just basic could do. Just being able to save a file to disk, being able to print to a printer..... and don't get me started on hearing speech.. awesome technology in 1983.

When you compare it to what the C64 offered, it wasn't so amazing. The C64 could synthesize speech without an additional peripheral device not to mention the ability to program multi color sprites and perform multi directional high resolution scrolling.

[GDMike]

And...mainframes we're cool too and heathkits, and I can go on... but this is a TI forum, I don't think anyone is comparing technologies here.

[GDMike]

Oh..I think there was also a lot of assembly poking and prodding going on in a commodore basic code if I'm not mistaken.

Edited May 1, 2022 by GDMike

[Cheung]

2 minutes ago, GDMike said:

Oh..I think there was also a lot of assembly poking and prodding going on in a commodore basic code if I'm not mistaken.

It allowed access to memory locations using the standard PEEK and POKE statements, something TI denied to it's users.