Sandbox Loader / Assembly Programs & Instructions

[Asmusr]

1 hour ago, senior_falcon said:

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. 

I must admit it's been a while since I looked at your documentation, and it all seems reasonable enough, but if someone was trying to make a micro Forth machine all I'm saying is that those are not given restrictions. All you absolutely need is room for a workspace. 

[+Lee Stewart]

4 hours ago, senior_falcon said:

 

>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

 

 

  Perhaps not that important to establish here, but >8378 is not the random number seed. The byte at >8378 is the storage location for the normalized random number generated by the GPL RAND instruction. The random number seed is the word at >83C0 (R0 of Interrupt workspace), which is used and updated by RAND. ?

 

[EDIT: Though my comments above are true for GPL RAND and for TI Basic, which uses it, Playground re-purposes those locations as @senior_falcon noted—my bad.]

 

...lee

[senior_falcon]

12 minutes ago, Lee Stewart said:

 

  Perhaps not that important to establish here, but >8378 is not the random number seed. The byte at >8378 is the storage location for the normalized random number generated by the GPL RAND instruction. The random number seed is the word at >83C0 (R0 of Interrupt workspace), which is used and updated by RAND. ?

 

...lee

On the TI-99 the random number seed is normally located at >83C0. Playground overwrites that
address when it loads and also uses it as R15 of the workspace. The random number seed has been
moved to >8378. LIMI will increment >8379 60 times a second which does the same thing as
RANDOMIZE in BASIC.
Below is a subroutine used for generating a random number. This code can be used as a subroutine or
placed within a page if speed is important. This code has been adapted from the random number
routine in the console.
*********************************************************
*RANDOM is a subroutine to generate a random number. *
*If you want a RND from 0 to 5, R0 should be 6 *
*The random number is returned in R1 *
*********************************************************
RANDOM DATA RANDOE-RANDOS
RANDOS LI R11,>6FE5
MPY @>8378,R11
AI R12,>7AB9
MOV R12,@>8378
CLR R11
SWPB R12
RANDO2 DIV R0,R11
MOV R12,R1
BL @SUBPAG
DATA RETURN
RANDOE

[senior_falcon]

Historically it has not been possible to run assembly programs from TI BASIC. You need a cartridge to be able to do that, such as XB, E/A, MiniMemory, etc. Playground was developed so you could run assembly programs on a completely unexpanded TI99, although you really would need some way to get the program into the computer such as a cassette player. But there is no law that says you have to use this on an unexpanded console.  If you have memory expansion, this would be a way to get an assembly program into the 32K. You could start Funnelweb this way and have access to all the E/A and TI Writer capabilities, all without needing a cartridge. Realistically though, if you have 32K and the disk system, then you will have XB and/or E/A

[+Lee Stewart]

1 hour ago, senior_falcon said:

The random number seed has been moved to >8378. LIMI will increment >8379 60 times a second which does the same thing as RANDOMIZE in BASIC.
Below is a subroutine used for generating a random number. This code can be used as a subroutine or placed within a page if speed is important. This code has been adapted from the random number routine in the console.

 

This has probably been discussed  before somewhere, but I want to point it out here, as well: The use of the Playground’s RANDOM cannot provide a reproducible pseudo-random-number (PRN) sequence (useful for debugging), as most (all?) other PRN generators can, because it includes the Interrupt timer byte (>8379) as its LSB, which, as explained by @senior_falcon, effectively runs RANDOMIZE for every call to RANDOM.

 

...lee