The BASIC sandbox is no more....

[senior_falcon]

I've been working some with the idea that James Abbatiello had in his program "Escape the BASIC sandbox". The attached program shows the results of my tests. I think you'll agree that the BASIC sandbox is a thing of the past! Remember, this must run in TI BASIC, not XB.

 

It has only been tested on Classic99. It should be possible to save this on cassette and run it on an unexpanded TI. If someone wanted to test this I'd be interested in the results.

DEMOTEST.zip

[+Vorticon]

Nice! This kind of feat was considered unthinkable previously. What are the essential constraints here from a programming standpoint?

Perhaps you could put together a tutorial document on how to do this as a reference for any future project along those lines.

It would be fun to come up with a little game here. Hmmm... Contest anyone?

[+InsaneMultitasker]

Very cool

[senior_falcon]

All the code has to run from the scratchpad. There is room for up to 112 (maybe 114) bytes of code at a time, starting at >8300. Your program can specify which block of code to load next and a page handler will copy it out out of VDP and into the scratchpad RAM. Because the code all runs from the same place, the BLWP instruction is not useful. BL works but only within the page that is loaded. I am still working out a method for branching to a subroutine and returning. You have the same 16K memory limitation that BASIC has or XB without the memory expansion. That 16K has to hold the screen, character definitions, sprite tables, etc. so you won't be able to write a huge program. There is some overhead in loading the various pages of code. The flip side of this is that code that spends a lot of time in loops, such as the scrolling routine in the demo, would run faster because everything is on the 16 bit bus. You can see from the demo that auto sprite motion works and the ability to play sound lists.

 

I forgot to thank Owen Brand for the music from "Honeycomb Rapture"

[+OLD CS1]

I see an awesome amount of potential here. The question I have is, where did you put all that data?

 

I was thinking at first that this technique could have been used a long time ago to provide a TI BASIC loader for games, but then remembering that most people with the 32k expansion and a disk drive would also have Extended BASIC or some other module kind-of negates that as a possibility for existing games. But getting new things done would be super-easy. In particular, since GPL will run out of VDP RAM, it should be pretty easy to do some GPL/XML hybrid using the TI BASIC sandbox as a launching pad.

 

Pretty damned cool.

 

If I can find an acceptable power cable for my program recorder, I am going to convert this over to tape and see how it runs on an un-expanded metal. DUH! I need to get Original Iron out of my head: I can convert this to wav and load it into a real TI from my phone (or PC.)

 

EDIT: Here, someone can give these a shot on real metal.

 

RE-EDIT: These are 41% louder, no clipping. May help with some audio source devices which attempt to attenuate audio for headphones.

demotest(adjusted).mp3

demotest(adjusted).wav

[Omega-TI]

I can convert this to wav and load it into a real TI from my phone.

 

I hope you are more successful at using a cellphone than I was. My phone "SEEMS" to put out plenty of audio for headphones but does not have enough output to be read by the TI. Impedance issues? I'm going to have obtain a TI Program Recorder as this thread is just too interesting to pass up.

 

So, after I get a program recorder, I'll probably start looking for someone to sell me a tape with this program on it.

[+OLD CS1]

I have to ask this question as I do not have the DSR documentation in front of me: I seem to recall that you can ask a DSR to load data into VDP memory. Is that correct? If so, then this method could be used to stub for much larger programs which swap in parts of themselves from disk. Is that 114 bytes of space taking into account RAM used by the GPL interpreter? If so, if we could cut the GPL interpreter out of the picture we could free up more space and just ignore the idea of running GPL from within VDP RAM

[Omega-TI]

 

 

EDIT: Here, someone can give these a shot on real metal.

 

Someone else might have better luck, I just used my DELL laptop, I got audio, but not sure it was enough. Just because it did not work for me does not mean it will not work for someone else. (I was at full volume on the laptop).

Edited November 12, 2013 by Kevan

[+OLD CS1]

 

Someone else might have better luck, I just used my DELL laptop, I got audio, but not sure it was enough. Just because it did not work for me does not mean it will not work for someone else. (I was at full volume on the laptop).

 

On my Dell laptops I found that the built-in audio CODEC actually cut the volume when you plug a device into the headphone jack. I got it to work from my Dell laptop by using a little $2 USB sound card.

[Tursi]

I have to ask this question as I do not have the DSR documentation in front of me: I seem to recall that you can ask a DSR to load data into VDP memory. Is that correct? If so, then this method could be used to stub for much larger programs which swap in parts of themselves from disk. Is that 114 bytes of space taking into account RAM used by the GPL interpreter? If so, if we could cut the GPL interpreter out of the picture we could free up more space and just ignore the idea of running GPL from within VDP RAM

For the DSR bit, in theory you could use the GPL DSR to load data to VDP, it would be tricky but should be feasible (of course, in this case you DO need to preserve the GPL parts of scratchpad. ) That said... if you run in graphics mode and assume all sprites and all characters defined in separate tables, you've still only used 5k or so, so you still have 7k or so available for assembly language code and data (assuming 12k max load size, which is rough, likely you have more).

 

For using all of scratchpad, yes, but you're also throwing away most of the console interrupt functionality, as it relies on various bytes in scratchpad. (This may be okay depending on your application, but for simple stuff it's a lot of code you don't have to provide.) Harry's program is already paging a lot of code in and out of scratchpad, it's a good demo! This is exciting stuff! It's always very cool to see "impossible" overcome.

[Omega-TI]

Okay, I'd like to clear up my understanding a little on this thread, but let me say outright I KNOW NOTHING ABOUT machine language programming, but have been thinking about learning.

 

1) I know a lot of people learned and started programming with the Mini Memory. Are we talking about a way here for a beginner to learn on a BASIC console without a Mini Memory?

 

2) If so, what books would you recommend for a totally ignorant noob? This might be the perfect thing to use my backup console for.

[+OLD CS1]

I uploaded adjusted audio files with the DemoTest program. These are adjusted to be 41% louder without clipping (42% tipped the scales.) This may help with some audio devices which attenuate output for headphones. I am missing a coupler otherwise I would be doing it tonight, myself.

[Tursi]

Okay, I'd like to clear up my understanding a little on this thread, but let me say outright I KNOW NOTHING ABOUT machine language programming, but have been thinking about learning.

 

1) I know a lot of people learned and started programming with the Mini Memory. Are we talking about a way here for a beginner to learn on a BASIC console without a Mini Memory?

 

2) If so, what books would you recommend for a totally ignorant noob? This might be the perfect thing to use my backup console for.

I would say no... on the surface, at least.

 

The biggest reason is that working with the kind of constraints this enforces (only 256 bytes of work RAM available) requires some expertise to learn to use -- it is much easier to start with lessor constraints. There's also some technique required to getting the BASIC program to contain the assembly code.

 

Now of course, nothing is impossible. You could in theory write an assembler that runs in this environment, and as long as the programmer realized that they are working under unusual constraints, you could probably put together a package that would work. But it does not exist today.

[+OLD CS1]

It awaits creation.

 

FTFY

 

(DISCLAIMER: Tursi never said that, only implied. Or at least I inferred as much.)

[senior_falcon]

Kevan, what Tursi says is correct. Assembly code with this package is a bit more complicated to write than with a full blown TI system, so that would be a better place to start programming assembly language. Opinions differ (what, computer programmers are opinionated?) but the book I started with is "Compute's Beginner's guide to assembly language on the TI-99/4a". This book is for the minimemory cartridge and the line by line assembler. This would be a wonderful tutorial if it were rewritten to show how to program with the Editor/Assembler package.

 

Programming with this package is pretty straightforward if you are used to writing assembly language. Write the program with your favorite text editor. Save, then assemble with the E/A cartridge in the slot. Let's assume the object code is called DEMO-O. Quit and select BASIC, then type:

CALL INIT

CALL LOAD("DSK2,DEMO-O")

CALL LOAD("DSK2.MAKEBX-O")

CALL LOAD(-31804,240)

The code is embedded in a BASIC program that you can save or run.

BTW, the loader for the E/A cartridge is way faster than the loader for XB. It is a real joy to use!

[+OLD CS1]

Best I can do. I cannot find any of my connectors so I had to rig something together. I am loading the DEMOTEST program using a WAV on my phone, created by CS1er. I have connected the phone to the TI using a cable which the phone recognizes as a line-out rather than as headphones, so it does not attenuate the output. I am using my volume-adjusted wav file from above but I also used the non-adjusted mp3 and wav files, both of which worked.

 

(Sorry about the video in a ZIP. It is an MP4 but AA does not allow that file type for upload. It plays just fine in VLC Player, and should play in Windows Media Player but no promises.)

 

 

MOV00001.zip

[Tursi]

Hah! That was awesome to watch. It's been a surprisingly long time since I've used the cassette interface, and that was totally nostalgic.

Edited November 13, 2013 by Tursi

[senior_falcon]

Freaking awsome! It's great to know that it actually works on an unexpanded system.

[+InsaneMultitasker]

Opinions differ (what, computer programmers are opinionated?) but the book I started with is "Compute's Beginner's guide to assembly language on the TI-99/4a". This book is for the minimemory cartridge and the line by line assembler. This would be a wonderful tutorial if it were rewritten to show how to program with the Editor/Assembler package.

 

Agree 100%. Taking it a small step further, I always thought a combination of Molesworth's assembly book (E/A) and the Compute! book would have been great together. I didn't have MiniMen but I had (and still have) the Compute! book and enjoyed reading through it to better understand certain concepts. There are a good number of 'starting assembly' resources out there and an active base right here.

[+retroclouds]

Impressive! Imagine the power if something like this would have been available say, 30 years ago.

[Tursi]

I know... I am so full of "what could have been" now. We even had TI Intern back then, in theory we had everything we needed to have worked it out.

[senior_falcon]

^{OK, here's a weird one for you. In testing the DEMO program I found that it behaves slightly differently in Win99/4a and Classic99. The difference is that the lower case characters and the UFO's are loaded one pixel higher in Win99/4A than they are in Classic99. There is one extra pixel under the UFO's and extra pixels here and there in the lower case characters. The video taken on the real TI looked right but it is fuzzy enought that I can't be sure. So could those of you who have tested this on a real TI verify whether or not the lower case characters are correctly aligned. Thanks.}

[+acadiel]

I am amazed... +1 for the cassette playback on the cell phone

[Tursi]

I wasn't able to run a test on this here... for some reason Win994A is not running on my PC anymore (I even reinstalled), and I could not make the code work from the CF7 drive (tried a regular and 2.2 console). I wonder has anyone tested from floppy? (Using the disk controller mode in Classic99 worked, as did adding the extra 6 bytes of reserved VDP RAM for the CF7).

 

I did like OLD CS1 and CS1er to convert to WAV (I always wanted to try that program anyway).. I was able to load it on my standard console and my V2.2, but neither worked properly. The 2.2 just crashed (even though I selected 2.2)... the standard console once got as far as displaying the saucers before it locked up. (They looked okay at least).

 

 

Conflict with the interrupt routine at a critical point, maybe? Does the exploit code disable interrupts as soon as possible?

[senior_falcon]

It sure seems odd that it would get that far and then crash. Maybe there is some conflict with the console interrupt that moves the sprites and plays the sound list. This does not use user interrupts so that shouldn't be the problem. Has anyone tried James Abbatiello's program on a V2.2 console?

 

We should be able to fix this problem. I will think about it today and find a way to test it. Meanwhile, I am still curious as to whether those who can run it on a real TI see any anomalies in the lower case characters.