Making a cartridge from a TI BASIC program

[senior_falcon]

For a long time I have thought that it would be possible to make a cartridge from a BASIC program. Because the basic interpreter is built into the console, it should be possible to store the entire 16K vdp ram plus the scratchpad, into a cart. Ideally the cart would have 2-8K banks, and you can see the problem right away. 16K + 256 bytes + headers and loaders (about 200 bytes) will not fit!. But with a simple RLE compression scheme it is possible gain enough space. Here is the result of my experiments. Note that this is not compiled. It is totally TI BASIC, just starting up faster. This method eliminates the slow startup speed of large basic programs.

The zip file has the docs showing how to use this. There is a cartridge for Hell's Halls at the bottom of the post.

 

.

BasicCart.zip

 

HALLS1-8.BIN

[ti99iuc]

Ohhh nice gift!

I know there were the possibility to do this thing also using classic99 but maybe with your utility could be still easier? I Will try it for sure.

 

Could be also a nice thing to have the same for the XB programs, please please please 🤗☺️

 

Thanks again Senior Falcon! We Always appreciate your stuff 👍

Edited August 18, 2023 by ti99iuc

[senior_falcon]

5 hours ago, ti99iuc said:

Could be also a nice thing to have the same for the XB programs, please please please 🤗☺️

 

There is an unused 8K bank in the Cortex BASIC cartidge, so it was pretty easy to fit an 8K program into that space. Squeezing in more could be done with some compression, but that is a lot of effort for something with no demand.

BASIC is built into the console, so all the BASIC cartridge above has to contain is the program. (Well, actually the entire 16K and scratchpad)

 

This same technique could be done with XB, but there you would need to start with the entire XB cartridge (5 groms and 2 roms - more for XB 2.9 and the latest RXB) In addition to that you would need 2 more rom banks if running without 32K expansion, or 6 more banks to make an image of both the VDP ram and 32K ram. This seems like a lot of bloat.

In contrast to that, a compiled XB program only requires 4 rom banks.

[jrhodes]

I'm sorry but haven't we done this song and dance before? Like the 600+ games by tmop69 in the "basic/extended basic games worth to be compiled" thread? Confusing.

[senior_falcon]

52 minutes ago, jrhodes said:

I'm sorry but haven't we done this song and dance before? Like the 600+ games by tmop69 in the "basic/extended basic games worth to be compiled" thread? Confusing.

Well, actually no. The tmolp69's title says it all - "games worth to be compiled". The cartridges made using the loader above are not compiled. They are TI BASIC programs, stored in the cartridge and loaded instantly and already running. The only thing fast is the loader. Otherwise, it is standard TI BASIC.

[WhataKowinkydink]

As I seem to recall when I ran into a problem loading PRK from ForceCommand it was revealed that Personal Record Keeping itself is in TI-BASIC.

[Retrospect]

1 hour ago, jrhodes said:

I'm sorry but haven't we done this song and dance before? Like the 600+ games by tmop69 in the "basic/extended basic games worth to be compiled" thread? Confusing.

It's a BASIC program stored on a cartridge image, which starts up quicker.  (runs normal speed though)

This is the same principle as a .Z80 image on the ZX Spectrum emulators.  It's a memory image.  Kind of.  Harry, am I wrong?

[pixelpedant]

49 minutes ago, WhataKowinkydink said:

As I seem to recall when I ran into a problem loading PRK from ForceCommand it was revealed that Personal Record Keeping itself is in TI-BASIC.

TI's early home productivity carts are TI BASIC, yeah, but at least some include supplementary subroutines not otherwise available to TI BASIC (like PRK has a DISPLAY AT equivalent - CALL D - for example), and so cannot be regarded as pure TI Console BASIC.  Notably, regular TI BASIC programs can access these subroutines when the cartridge is inserted, making PRK a de facto Very Slightly Extended BASIC.

Edited August 18, 2023 by pixelpedant

[WhataKowinkydink]

54 minutes ago, pixelpedant said:

TI's early home productivity carts are TI BASIC, yeah, but at least some include supplementary subroutines not otherwise available to TI BASIC

Indeed- I'd forgotten that PRK adds some new routines.  Still though it demonstrates that it can be done :)

[Tursi]

13 hours ago, senior_falcon said:

For a long time I have thought that it would be possible to make a cartridge from a BASIC program. Because the basic interpreter is built into the console, it should be possible to store the entire 16K vdp ram plus the scratchpad, into a cart. Ideally the cart would have 2-8K banks, and you can see the problem right away. 16K + 256 bytes + headers and loaders (about 200 bytes) will not fit!. But with a simple RLE compression scheme it is possible gain enough space. Here is the result of my experiments. Note that this is not compiled. It is totally TI BASIC, just starting up faster. This method eliminates the slow startup speed of large basic programs.

Yep, Classic99 can do this too. It doesn't save the disk buffers to make room and (if necessary) also doesn't save the current screen. You can run your BASIC program to the location of your choice, then breakpoint and hit save. Classic99 will ensure a clean startup by letting the GPL interpreter finish the current instruction before it saves. Classic99 will optionally prevent users from stopping with FCTN-4 (by installing a hook that resets the console if the program stops running for any reason).

I used it for Hyper Racer and Owen used it for something, I can't remember what. It was his project I did it for.  Of course, it's inverted order cause that's how we did things back then. I believe I fixed Classic99 to be able to export non-inverted since then.

 

HyperRacer Crap Entry.zip

Edited August 19, 2023 by Tursi

[ti99iuc]

I haven't tested the seniorfalcon utility still but with @tmop69 we had written a tutorial about the cart conversion using classic99.

 

I don't know which will be the easier way of them or maybe the two methods will be complementary.

[tmop69]

8 hours ago, jrhodes said:

I'm sorry but haven't we done this song and dance before? Like the 600+ games by tmop69 in the "basic/extended basic games worth to be compiled" thread? Confusing.

In addition to the compiled games, I've also converted to SSS some TI BASIC games using Classic 99:

 

 

This is an "addendum" pack, so somewhere here there is also the initial pack of more than 100 TI Basic classic games in SSS. Some of these where also be compiled.

 

[Tursi]

Choice is always good to have!

 

Nice writeup -- though it's worth noting that if a BASIC program has a title page or otherwise waits for a keypress, it may be easier to let it run to that point, then simply press F1 to trigger a manual breakpoint (rather than toggling on the screen color change... though I do remember giving that as advice in the past).

 

It's kind of neat that Senior Falcon's version triggers on BASIC line number.

 

[+Ksarul]

22 hours ago, WhataKowinkydink said:

Indeed- I'd forgotten that PRK adds some new routines.  Still though it demonstrates that it can be done

Statistics also includes those PRK routines. . .

 

Also, if you look at a significant number of the Scott Foresman cartridges for the TI, they are also programmed in TI BASIC saved to GROM. Many of the other early TI cartridge releases use the same trick. The nice thing about the process @senior_falcon developed here is that it replicates that process to some extent. I say to some extent, mainly because the TI trick allowed BASIC programs to exist that were larger than console memory. The original process required that the program be developed on a 990, so this new process is a definite improvement on the original process.

[WhataKowinkydink]

29 minutes ago, Ksarul said:

Statistics also includes those PRK routines. . .

 

Also, if you look at a significant number of the Scott Foresman cartridges for the TI, they are also programmed in TI BASIC saved to GROM. Many of the other early TI cartridge releases use the same trick. The nice thing about the process @senior_falcon developed here is that it replicates that process to some extent. I say to some extent, mainly because the TI trick allowed BASIC programs to exist that were larger than console memory. The original process required that the program be developed on a 990, so this new process is a definite improvement on the original process.

Nice vignette - really clarifies what the benefit is - thanks!  And nice work @senior_falcon 😎

[senior_falcon]

21 hours ago, Tursi said:

Yep, Classic99 can do this too. It doesn't save the disk buffers to make room and (if necessary) also doesn't save the current screen. You can run your BASIC program to the location of your choice, then breakpoint and hit save. Classic99 will ensure a clean startup by letting the GPL interpreter finish the current instruction before it saves. Classic99 will optionally prevent users from stopping with FCTN-4 (by installing a hook that resets the console if the program stops running for any reason).

Just tried it out with Hell's Halls. CALL FILES(0) to use the entire vdp memory. Works fine. As mentioned, doesn't save the screen, but as long as you save at the beginning before anything is printed then all works as it should.

This is yet another reason to RTFM!!!!

[Tursi]

1 hour ago, senior_falcon said:

Just tried it out with Hell's Halls. CALL FILES(0) to use the entire vdp memory. Works fine. As mentioned, doesn't save the screen, but as long as you save at the beginning before anything is printed then all works as it should.

This is yet another reason to RTFM!!!!

Haha, nah, it's fine. Your stuff is always so impressive to see.

 

It's been 13 years since I did it, but yeah, if I remember right, if it can't make space by skipping the disk buffers, then it leaves out the display and stores the loader and scratchpad there.  

 

I took a look cause I was curious what the CHARA1 option did, forgetting that it only needs to overwrite the VDP memory. But it looks like I forgot to do anything at all with that option.  Other than that, the copy code assumes it can resume at >0070 (cause the save program cycled to there), restores the GROM address, VDP registers, and scratchpad, as well as VDP as described. No compression though!

My original pass did not restore the GROM address, and I even commented that it shouldn't be necessary. But for some reason I decided it was.