Sandbox Loader / Assembly Programs & Instructions

[Omega-TI]

I remember there was much talk a while back about something called, "The Sandbox Loader".  I never really followed those threads closely because I could not divide my time up any more than it already was.  But now, as time has gone on, I'm wondering has the tech/method been improved, matured and finalized?  I'd really be interested in some "distilled" information on this topic.

 

I'm wondering...

1) IS THERE A FINALIZED INSTRUCTION MANUAL AVAILABLE? (like how to use and load programs)

2) Is there a link to the program itself and all the programs available for it?

 

I'm assuming...

Any program for it and the loader itself can be downloaded and then saved to cassette, and then used on a totally unexpanded system.  

 

I'm hoping...

At least a couple of the Atarisoft games were converted?

 

[+OLD CS1]

That was this thread.  Includes a bunch of source and a PDF instruction manual.

[+Lee Stewart]

37 minutes ago, Omega-TI said:

I remember there was much talk a while back about something called, "The Sandbox Loader".  I never really followed those threads closely because I could not divide my time up any more than it already was.  But now, as time has gone on, I'm wondering has the tech/method been improved, matured and finalized?  I'd really be interested in some "distilled" information on this topic.

 

I'm wondering...

1) IS THERE A FINALIZED INSTRUCTION MANUAL AVAILABLE? (like how to use and load programs)

2) Is there a link to the program itself and all the programs available for it?

 

I'm assuming...

Any program for it and the loader itself can be downloaded and then saved to cassette, and then used on a totally unexpanded system.  

 

I'm hoping...

At least a couple of the Atarisoft games were converted?

 

The BASIC sandbox is no more....

Hacking your way out of the TI-Basic sandbox

 

...lee

[Omega-TI]

10 minutes ago, OLD CS1 said:

That was this thread.  Includes a bunch of source and a PDF instruction manual.

 

Thanks.  I just bookmarked that thread and will check it out after I get back today.  I'm sort of hoping it's easy to use like...

 

Step one, load loader.

Step two, use loader to load assembly program.

Step Three, run and play game. (like Pole Position)

 

... we'll see!  Thanks again.

[+OLD CS1]

I will save you the disappointment. The only CPU address space available is 256 bytes, but that has to share with GPL workspace and the Playground "kernel," if you will.

 

 

 

 

The program has to be written for or painstakingly converted to work in 114 byte pages.  But still pretty awesome to run real assembly on the unexpanded console!

[HOME AUTOMATION]

39 minutes ago, Omega-TI said:

Step two, use loader to load assembly program.

Step Three, run and play game.

Yes, I think you could copy code into 32K, such as a @LOADER, than you could load .obj files!

 

   P.S. ...The environment will probably need a setting up, depending on what you wish to run.

[+Lee Stewart]

17 minutes ago, HOME AUTOMATION said:

Yes, I think you could copy code into 32K, such as a @LOADER, than you could load .obj files!

   P.S. ...The environment will probably need a setting up, depending on what you wish to run.

 

But, then it is not an UNexpanded console.

 

...lee

[Omega-TI]

3 hours ago, OLD CS1 said:

 I will save you the disappointment. 

Bummer.  I was operating under a misconception, probably due to the fact that I did not follow those threads closely back then.  I was thinking that programs like Pole Position were 8K in size and that the TI could load them into it's internal memory to run them, and that the loader made it possible. ?

[+mizapf]

Yes, you can execute code in ROM. You should not see cartridges as a data storage but as a pluggable part of memory.

[+OLD CS1]

11 hours ago, mizapf said:

Yes, you can execute code in ROM. You should not see cartridges as a data storage but as a pluggable part of memory.

I think what he is hoping is to take a cartridge ROM and convert it to run from tape on a console with no expansions.

 

This was done a lot with Commodore 64 cartridges, where the cartridge was dumped and then attached to a BASIC "loader."  The difference being the Commodore 64 has RAM available in the address space of the missing cartridge, while the TI only has 256 bytes of scratch-pad RAM and none "under" the GROM port address space.

[HOME AUTOMATION]

6 hours ago, Lee Stewart said:

But, then it is not an UNexpanded console.

  B'oh! I missed that...

[+FarmerPotato]

The Sandbox is mind-blowing. Imagine if people had known how to exploit this back in the day - commerical "BASIC" cassette programs that get around the bottlenecks in TI BASIC!

99'er magazine  reviewers would be stumped at how a program got that performance!

 

 

Imagine a FORTH environment that targets the Sandbox loader. FORTH might be a good way to leverage the tiny page size! A word would have to be limited in its compiled size to very tiny. The stacks would be similarly limited. Perhaps static analysis could determine in advance what the required depths would be. (or at least run-time tests.) In the end, a FORTH program that executes from a bare console in BASIC, with mind boggling performance nearly as fast as assembly, certainly faster than GPL or BASIC!

 

 

[+mizapf]

1 hour ago, FarmerPotato said:

The Sandbox is mind-blowing. Imagine if people had known how to exploit this back in the day - commerical "BASIC" cassette programs that get around the bottlenecks in TI BASIC!

Still, you needed the 32K or some other kind of memory expansion.

[senior_falcon]

2 hours ago, mizapf said:

Still, you needed the 32K or some other kind of memory expansion.

?????????????

[wierd_w]

I doubt TI would have complained if it drove sales of official 32k upgrade cars.

 

 

[Tursi]

11 hours ago, mizapf said:

Still, you needed the 32K or some other kind of memory expansion.

No, you didn't... the Sandbox samples swap code from VDP RAM into scratchpad to run. Performance is good - sometimes better than the 32k RAM (depends on the software, of course).

 

[Tursi]

13 hours ago, FarmerPotato said:

The Sandbox is mind-blowing. Imagine if people had known how to exploit this back in the day - commerical "BASIC" cassette programs that get around the bottlenecks in TI BASIC!

99'er magazine  reviewers would be stumped at how a program got that performance!

I think about this often, in particular because I spent so long just programming TI BASIC with an unexpanded machine, and being jealous of my friends. This did drive me to learn several other computers of the day, though.

 

For some reason I'm most fixated on a port of Donkey Kong for the CoCo2... probably because it was one of the only arcade-style games I played off cassette tape. I still tell myself I'm going to do that in Playground, even though we already have a real Donkey Kong.

 

[+mizapf]

8 minutes ago, Tursi said:

No, you didn't... the Sandbox samples swap code from VDP RAM into scratchpad to run. Performance is good - sometimes better than the 32k RAM (depends on the software, of course).

Hmm ... I did not follow that topic closely enough. But faster than the 32K - I guess because of the 16 bit with 0 WS?

[+TheBF]

On 6/10/2020 at 4:58 PM, FarmerPotato said:

The Sandbox is mind-blowing. Imagine if people had known how to exploit this back in the day - commerical "BASIC" cassette programs that get around the bottlenecks in TI BASIC!

99'er magazine  reviewers would be stumped at how a program got that performance!

 

 

Imagine a FORTH environment that targets the Sandbox loader. FORTH might be a good way to leverage the tiny page size! A word would have to be limited in its compiled size to very tiny. The stacks would be similarly limited. Perhaps static analysis could determine in advance what the required depths would be. (or at least run-time tests.) In the end, a FORTH program that executes from a bare console in BASIC, with mind boggling performance nearly as fast as assembly, certainly faster than GPL or BASIC!

 

 

This would be pretty a good trick.

Typically you would need 16 levels for each stack so there goes 64 bytes!

You could limit that in the way you write programs. Might be able to use registers as a short data stack. (?)

 

It begs the question of what threading mechanism you would use. The smallest code to run is native code because the CPU does all the interpretation. So you could just pass addresses from VDP of code snippets that load to scratchpad, run and reload the VDP reader.

 

You might be able to use byte code that feeds native code snippets to the scratchpad for each byte code and then reloads the byte code interpreter... my head starts swimming.

[+mizapf]

On 6/11/2020 at 12:46 AM, mizapf said:

Still, you needed the 32K or some other kind of memory expansion.

 

Interestingly, I completely missed that topic when it came up, so I readily take back my comment. I found out that I joined AA in January 2013, so I missed the initial thread about "Hacking your way out ..." (started 2010). But I did not comment to the Sandbox thread which was hot in November 2013 where I should have had a chance; maybe I was distracted by too many other stuff. I do remember that there were BASIC programs with merged assembly code, but I had Extended Basic with 32K in mind with that.

 

After starting senior_falcon's DEMOTEST I have to say: Fascinating!

 

(hey, I'm just 7 years late )

[+FarmerPotato]

14 hours ago, TheBF said:

This would be pretty a good trick.

Typically you would need 16 levels for each stack so there goes 64 bytes!

You could limit that in the way you write programs. Might be able to use registers as a short data stack. (?)

 

It begs the question of what threading mechanism you would use. The smallest code to run is native code because the CPU does all the interpretation. So you could just pass addresses from VDP of code snippets that load to scratchpad, run and reload the VDP reader.

 

You might be able to use byte code that feeds native code snippets to the scratchpad for each byte code and then reloads the byte code interpreter... my head starts swimming.

It is fascinating. My only idea was that a list of tokens referred to dictionary addresses in VDP. Like your idea.

 

I look forward to your working out how to use the tiny memory  Surely there has been a teeny tiny FORTH in all its history?

 

Just kidding, you are under no obligation to solve such an interesting exercise!

 

[+TheBF]

6 hours ago, FarmerPotato said:

It is fascinating. My only idea was that a list of tokens referred to dictionary addresses in VDP. Like your idea.

 

I look forward to your working out how to use the tiny memory  Surely there has been a teeny tiny FORTH in all its history?

 

Just kidding, you are under no obligation to solve such an interesting exercise!

 

If it walks like a gauntlet and it talks like a gauntlet  

 

I must confess that I was thinking about it. My cross-assembler post might show how it could be created by a program running on TI-99.

 

Now look what you did. I am thinking about it again.  

[Asmusr]

On 6/10/2020 at 3:33 PM, OLD CS1 said:

I will save you the disappointment. The only CPU address space available is 256 bytes, but that has to share with GPL workspace and the Playground "kernel," if you will.

  Reveal hidden contents

 

 

 

The program has to be written for or painstakingly converted to work in 114 byte pages.  But still pretty awesome to run real assembly on the unexpanded console!

Why would you be limited to 114 bytes?  Once you're in, you should be able to disable interrupts and use the entire 256 bytes. You could save the original contents to VDP RAM if you want to restore it later.

[+OLD CS1]

24 minutes ago, Asmusr said:

Why would you be limited to 114 bytes?  Once you're in, you should be able to disable interrupts and use the entire 256 bytes. You could save the original contents to VDP RAM if you want to restore it later.

Just following orders.

 

I would assume you are correct: do not use GPL and interrupts and the world is your oyster, right?  The Playground kernel pages in executable data from VDP RAM, so you could make use of that and sacrifice some RAM out of the 256 bytes (not accounting for the work space.)  Or roll your own paging handler.

[senior_falcon]

7 hours ago, Asmusr said:

Why would you be limited to 114 bytes?  Once you're in, you should be able to disable interrupts and use the entire 256 bytes. You could save the original contents to VDP RAM if you want to restore it later.

If your entire program fits into 256 bytes then you could use the hack to seize control of the computer by loading code from >834A to >83C4 or a little beyond. Then that code could load almost the full 256 bytes - you have to save some room for the instructions that load the code. If your code is larger than 256 bytes then you have to load it in pages. Doing that means reading the code from VDP and writing it to scratchpad. Every instruction requires 6, 12, or 18 instructions in the loader (plus some additional overhead) just to get it from VDP to scratchpad. Something as simple as B *R11 cannot be done if it goes to another page. You have to load yet another page with the code needed to load the calling code and return to it. 

You can see there are numerous complications. I felt that being able to use console routines (auto sprite motion, kscan, etc.) would be useful and probably faster, and certainly more compact than paging in all the code needed to duplicate these routines. If you eliminated all console routines, you would need a workspace(32 bytes) and code to load the pages(36 bytes for the code I wrote) which leaves you with 188 bytes per page - a little more if your workspace was less than 16 registers.

 

There is no going back to BASIC. Once you are in, many of the pointers are overwritten so the only exit is via "Quit".

 

Here's a memory map of how the scratchpad is used. (There is much more information in the docs.)

>8300 - >8371 114 bytes available for a program page. (KSCAN and GPLLNK use memory from >836A to >8371)
>8372 - >837D System use for keyscan, sprite motion, etc. >8373 is GPL substack pointer; >8378 is the random number seed
>837E - >83A1 36 bytes - Page loader
>83A2 - >83C1 Workspace (R15 overlaps into R0 of interrupt workspace)
>83C0 - >83DF Interrupt workspace. (R0 not available) R8 and R9 (>83D0 and >83D2) are used to store return address for a subroutine.
>83E0 - >83FF GPL workspace

I only had provision for 1 level of subroutines. As I remember, Moije figured out a way to have a stack and documented how he did it. Of course, the entries on the stack cut into the 114 bytes, but that may be an avenue worth pursuing.

 

One of the things I would like to do is port "Megabug" or "Dung Beetles" to the unexpanded TI.