TI Basic session manager

[+retroclouds]

Here’s an idea that grabbed my mind and just doesn’t let go, so I need to write about it.

 

I’m playing with the idea of creating a session manager for TI Basic (and possible Extended Basic)

It’s a spin-off of the TI Basic integration work I’m doing with Stevie and thought it’s better to discuss in a separate thread.

 

So what is this about? In Stevie I’m now able to jump into TI Basic with a single keypress, do program stuff and return to Stevie with FCTN-9.

I can then repeat jumping back and forth, all while the TI Basic program, screen layout and colors is all still there.

That is nothing so special, but I’m happy to get it working nonetheless.

It’s inspired by the work done by @Tursi with his TI Basic cartridge creator and classic99 functionality.

With the difference being that this time it’s all handled on the TI-99/4a itself. 

 

The way it works is by setting up a ISR routine before jumping into TI Basic. The ISR then calls the necessary functions to copy VDP memory and scratchpad to SAMS ram. Now here is the nice thing, with SAMS you have lots of memory. This is where I got the idea of a session manager for basic.

 

Some of the functionality I can think of:

 

• Have multiple TI Basic/Extended Basic sessions
• Switch between sessions by using keyboard combination
• Dump and restore sessions on a fast storage device (e.g. TIPI, HDR), aka “snapshots”
• Periodically switch between sessions, even while the TI basic program is running (so you get a “faked” multitasking)
• Exchange data between sessions (not sure how that would work, need to give it some more thoughts)
• Give basic some kind of API to query and manipulate session state, e.g. set session title, periodically take snapshots by having a corresponding TI basic command => 100 CALL SNAPSHOT(“TIPI.SNAP….” )
• Possibility to use the load interrupt to restore a session if it got stuck (not sure about this one, need to give more thoughts).

 

Is anything of the above useful in any form? Probably not. But I think it’s a kinda cool idea I’m going to further explore.

Will see what comes out of it. Wish me luck ?

[+OLD CS1]

Thierry's site has some ideas on context switching.

[+Vorticon]

This could come in handy for testing graphics in one session while the main program resides in another as an example.

And if you can exchange code between sessions, then one could build a library of subroutines that can be dropped into a program in a different session.

[+RXB]

Now that RXB 2020 has a VDP STACK Manager and XB RAM Manager built in not a problem combined with SAMS.

Guess I should make a demo of it working with multiple programs again.

 

You can not do snap shots easy, but you can have multiple XB programs loaded and run and stop them of course break points can not be saved.

Example have first 4K programs saved at >FFE7 to >F000, second program saved at >F000 to >E000, third program at >E000 to >D000 and so on...

Down to last memory address for XB at >A040 which is normal XB RAM last address unless you want that last >40 bytes too.

Using SAMS makes it even better and they can be any size programs up to the entire 24K in upper XB RAM.

No other XB variant can do this that I know of.

 

CALL VDPSTACK(address) ! sets VDP Stack location in VDP

CALL PRAM(start-address,end-address) ! this is start and end address for XB Program RAM, the open area other programs can be installed, but no used.

CALL PLOAD(address-boundry,path-filename)  ! this loads a 4K page into SAMS or normal memory.

Of course you can load more then 4K using multiple files, yea I know it is a waste of DISK but now we have TIPI or SD cards. 

Edited September 27, 2021 by RXB
missing text

[kl99]

This is interesting, would this approach also allow a Basic or GPL debugger on the currently running Basic?
That might also be a nice function for this.