Can someone explain memory to me?

[Sinphaltimus]

What I mean is, stack ram and system ram.

 

I have a 32k card in my peb.

 

While programming in extended basic, I run out of memory in program but have plenty more remaining in stack. Is there a way for me to utilize stack with extended basic so this does not occur?

 

It would I have to use assembly for this functionality?

[JamesD]

The first thing you need is a memory map of how Extended BASIC uses RAM.
I've never seen one so this info may not be of much use.
TI BASIC & Extended BASIC are very different anyway.

Under Microsoft BASIC, a block at the top of RAM is reserved for the stack.
Then a block is reserved for variables just below that.
Other than some space reserved for a few system variables needed by the interpreter, the rest of RAM is available for BASIC code.

A CLEAR statement resets all variables and sets the amount of space reserved for variables.
There is no command to change the area reserved for the stack.

As a general rule, the interpreter needs a certain amount of stack space even for a small program.
It's needed for keeping track of things like the start of for loops. When your program hits the next, it grabs the location of the last FOR off of the stack.
It could also be used by individual commands for temporary storage.
The stack is going to need a certain amount of stack space just for normal operation, so reducing that could have unintended consequences.

If the stack size is not hard coded, there should be a pointer in RAM that can be modified to change the start address for variable RAM.
Then you can move the lower variable / top of RAM to free up space for basic.
Just remember that if the test for stack overflow doesn't use the pointer in RAM, you won't get a stack overflow, you might overwrite your variables.
Worse yet, changing a variable could overwrite the stack and crash the interpreter.

[Sinphaltimus]

So program ram stores my program (and there's some system reserve there too) and stack ram is used for internal operations to execute the code(with system reservations there too)? These allocations are handled by the system and not really manipulated via extended basic user commands? Some of my assumptions are based on what you typed and some things I've read elsewhere.

[senior_falcon]

If you are not using the 32K expansion then the program and stack all reside in the 16K VDP memory pretty much as JamesD describes. The XB interpreter keeps track of how big the program is and how the stack space is used and automatically allocates memory as needed until there is no more room left. When you add the 32K expansion the XB program is kept in the 32K ram but the stack remains in the VDP ram. These are distinctly different memory areas with no real connection to each other - i.e. you are not just adding 32K on top of the VDP ram to make a 48K long block of RAM. As you are finding out, this is not necessarily the most efficient way to use memory - you can use up all the stack space with a 1K program or have virtually all the stack space remaining with a 23K long program. I believe this was done so that XB could work either with or without the memory expansion. I don't know of anyone who has come up with a workaround for this, and suspect that it cannot be done. It is possible to put additional XB program lines in the 8K low memory which would allow you to have a program close to 32K long, but this is not trivial, and there would be no easy way to edit them.

[Tursi]

The TI is a little different than other systems.

 

There are three types of memory in a TI-99/4A home computer: System, VDP, and GROM.

 

GROM is TI's proprietary memory that is usually used to store cartridges, or at least part of them. It also stores most of the operating system. It's a device-oriented memory that is accessed through a special memory port, as such it can not run assembly code. Usually it stores programs written in GPL, which is sort of an intermediate language that TI created for them. GROMs are the slowest memory on the console, around 30 times slower than normal memory. There are GRAM devices but these are mostly used to emulate GROMs, not to treat it as true RAM.

 

VDP is the Video Display Processor, and it has its own 16k of RAM attached to it. In a bare, unexpected console, this is 98% of the RAM in the machine - as such, it's used for storage by anything that runs on an unexpanded console, including BASIC. This is again a device-oriented memory and so it can not run assembly language code, although it can at least be accessed at (almost) full speed. The main slowdown dealing with video memory is that changing the address is a multi-step process.

 

System or CPU memory is directly attached to the CPU. In the bare console there's 8k of ROM (consisting mostly of the GPL interpreter) and 256 bytes of RAM (the other 2%). Cartridges can also attach up to 8k directly, and expansion devices have another reserved 8k slot. The rest of the space is reserved for the 32k card, when attached. The 32k card is divided into two separate spaces, one 8k and one 32k.

 

When first released, TI BASIC didn't know about the memory expansion, so a 32k card doesn't help there. In Extended BASIC, when the 32k card is detected it reconfigures itself to store the program in the 24k space (the 8k space is left reserved for loading assembly language programs). It stores some of your variables (strings, IIRC) in VDP memory and some of the other tables -- and the VDP memory is what it calls 'stack'. It's completely unrelated to the definition of stack on any other computer.

 

There's not much you can do -- if you run out of program memory you can't add any more code. But you can break your program up into pieces and use "RUN" commands to chain them. I'm not sure what other people did, but I use to pass data between chains programs by defining characters (as that's preserved) and reading the hex string back. (Also, when I had a lot of CALL CHAR commands I would have one program do all the CHARs, then chain to the next program to run the game ).

 

(Senior Falcon posted at the same time as me, and he knows a lot more than I do about it )

Edited August 29, 2016 by Tursi

[Sinphaltimus]

You folks are the best. This is all very enlightening. I greatly appreciate you all taking the time to answer the call.

[+adamantyr]

Basically, you burn up stack space by using strings, and program space and numeric variables take up the program space.

 

So ideally in Extended BASIC, if you have a lot of data to track like paths or units, your better bet is to use string arrays. They have the advantage of being dynamic and they also use memory you would otherwise be using for a large static numeric array. Downside is you're limited to integer values and nominally, values of 0-255.

[Omega-TI]

Bummer you cannot load XB into the upper paged memory for the SAMS and then have all the other normal space available for goodies.

[Asmusr]

Bummer you cannot load XB into the upper paged memory for the SAMS and then have all the other normal space available for goodies.

 

If we had someone on the forum who were both the developer of one of the BASIC variants and a great advocate for the use of SAMS, that person could probably make a new version of BASIC that allowed SAMS to be used for both programs and stack.

[+InsaneMultitasker]

In many of my larger programs, I offload the majority of the in-program text to a DV80 file. At program startup, I read the file into a string array. This has two advantages:

 

1. I can edit the text and make changes without modifying the program itself.

2. The strings will only consume stack space. When the string is part of the program, it consumes both program space and stack space.

 

The downside is you have to print the DV80 file with line numbers, or have some other mechanism to know what array element you want. The program space needed to represent the array should be considered when deciding to move a string into the file.

 

A simple example for loading a 100 line text file

DIM A$(100)

OPEN #1:"DSK1.STRINGS",DISPLAY,INPUT

FOR X=1 TO 100::LINPUT #1:A$(X)::NEXT X

CLOSE #1

 

PRINT A$(5) - print the fifth line of the file that was input above.

 

If stack space is limited, you can also clear some of the strings once used to make room for other data while the program is running.

[Sinphaltimus]

In many of my larger programs, I offload the majority of the in-program text to a DV80 file. At program startup, I read the file into a string array. This has two advantages:

 

1. I can edit the text and make changes without modifying the program itself.

2. The strings will only consume stack space. When the string is part of the program, it consumes both program space and stack space.

 

The downside is you have to print the DV80 file with line numbers, or have some other mechanism to know what array element you want. The program space needed to represent the array should be considered when deciding to move a string into the file.

 

A simple example for loading a 100 line text file

DIM A$(100)

OPEN #1:"DSK1.STRINGS",DISPLAY,INPUT

FOR X=1 TO 100::LINPUT #1:A$(X)::NEXT X

CLOSE #1

 

PRINT A$(5) - print the fifth line of the file that was input above.

 

If stack space is limited, you can also clear some of the strings once used to make room for other data while the program is running.

 

OK, this makes sense reading it but the entire concept is a bit more advanced for my comprehension at the moment. Now that I finally have a drive working with disks, I will be reading and learning all the disk commands etc.. and of coarse finding out more about loading and unloading things to disk as well as that array stuff. Thanks again for more tips and tricks.

[matthew180]

Something else to keep in mind is that all comments, REM and ! comments, consume program space in memory. That is unfortunate since it deters good commenting. Another reason I wrote TidBit, which strips all the comments out of the translated code so memory is not used up by the comments. This allows you to have heavily commented code without the downside of comments.

2. The strings will only consume stack space. When the string is part of the program, it consumes both program space and stack space.

What about DATA statement information? Where is it stored? I believe it only consumes memory in one place, yes?

[+InsaneMultitasker]

matthew180, on 29 Aug 2016 - 11:40 PM, said:

What about DATA statement information? Where is it stored? I believe it only consumes memory in one place, yes?

DATA statements are stored as part of the program. Their string and/or numeric information is not usable until assigned to a variable at run time.

 

When the data is read into one or more variables it will consume either stack space or program space. The numeric variables consume space within program memory, based on DIM statements and prescan findings. String variables 'consume' stack space dynamically as strings are assigned, during prescan and execution. This can be seen by checking SIZE after a breakpoint or FCTN-4 interruption.