Need help understanding how to utilize SAMS memory in RXB

[majestyx]

So I'm trying to create a realistic statistics based baseball game and, due to the TI's limitations and my not wanting to learn assembly, I am trying to figure a way to utilize SAMS memory to store, for example, tables of data that I can look up and retrieve into variables, mostly strings. I'd also like to be able to use the extra memory to store in-game statistics like at-bats, RBIs, strikeouts, walks, etc. for each player in the game, as well as team statistics. I'm thinking I'm likely setting my sights too high for this machine, but would love to know if and how this might be possible, especially with 1 MB of memory just sitting there waiting to be used.

 

For example, I'd like to have many detailed plays such as "fly out to center," "6-4-3 double play," "out at first, other runners safe," and plenty others which I can look up in some sort of matrix in memory. I'm finding I'm really having to leave out more than I'd like to include using what's available on a 32K system. Having a way and understanding how to access SAMS memory, maybe even if used as a RAM disk, would be cool. Otherwise, I'll make do with what is possible to utilize, and try my best with what there is to work with.

 

I guess I'm just not understanding what use the extra memory is if it's not possible to utilize it easily. I've seen Rich's In the Dark but I don't think that's anywhere near what I'm trying to do. That game appears to be using the memory to store map sections and then move the data into program (or is it VDP?) memory. Also, I see subprograms in RXB that start with AMS, but I can't seem to make sense of them, likely because I'm clueless when it comes to TI machine language. If someone can point me to a tutorial or even just documentation on ways of using the SAMS memory in programs, especially along the lines of what I'm attempting to use it for (store and retrieve data) it would be appreciated.

[+TheBF]

You could consider making version 1 use a file based data base.  You would use a relative file that allows random access to any record. In Basic you would then need a way to calculate the correct record from the input data, or have an lookup table in a big array to find the record number or worst case, you search through each file record to find the correct data.

 

By using disk you have a clean interface to BASIC to get your ideas firmed up.  Then move them to SAMS.

 

I made and used a database of church hymns for my choir director job that used floppy disk and a binary search method. It found the correct file record to use in a second or two.?

 

Another method called a hash table lookup is even faster. 

 

my 2 cents

 

0xBF

 

 

Edited August 6, 2019 by TheBF

[RXB]

Working on a better version of RXB that has even better SAMS memory manager built into RXB.

Hope to release it before end of year. Have the Documentation done so currently working on DEMO's.

Tested all the routines and looked for any bugs so just the Demo's and videos need to be done.

After that I will release RXB 2019 or call it RXB 2020.

 

As for current RXB 2015 I am happy people are writing games and software using it.

Conversions of RXB 2015 XB programs to RXB 2020 XB programs will be provided and should be easy to convert.

[majestyx]

That may be the approach I'll need to use (files) unless someone can provide more insight on how to use the SAMS without having to program in assembly. I looked over what little documentation there is for it on the diskettes that are available on the WHTech FTP site, but it really doesn't go into much detail, especially on how to use it outside of the Editor/Assembler. I see that there is a way to load multiple PROGRAMS into the SAMS memory, acting like a RAM disk, but I'll need to delve a little deeper to see if this can be accomplished for data files. I'm thinking that IN THE DARK's program listing should provide more clues, but so far I'm just not "getting it" as far as what's happening with all the CALL AMSBANK, MOVES, and LOADs I am seeing.

 

For now, I'll likely make general plays such as FLY OUT, GROUNDER, DOUBLE PLAY, REACHED BASE ON ERROR, and so on, then add more detailed plays, if not in SAMS memory (my preferred method), then by using disk files.

 

Just saw Rich's post and am happy to hear that a new version of RXB is coming. I'm trying to utilize RXB as well as SAMS in order to take advantage of all the improvements and better tools that are now available for the TI that weren't previously. It seems to me the AMS/SAMS had a lot of potential, but in the more than 25 years it's been available, very little has been done to make use of it. I believe a big reason is because there doesn't seem to be much in the way of documenting how to use it, at least for the average non-assembly/non-Forth programmer.

Edited August 7, 2019 by majestyx

[Asmusr]

I believe you would have to use CALL LOAD and CALL PEEK to store and fetch variables in SAMS from RXB.  Quite cumbersome and slow - especially for floating point numbers.

 

I once thought about how to improve this, and suggested an XB extension to provide rudimentary array support:

https://atariage.com/forums/topic/261030-dungeons-of-asgard-game-under-development/?do=findComment&comment=4218621

[majestyx]

Yes indeed, those calls to arrays stored in the SAMS is EXACTLY what I could use, and I'm sure many others could as well. Since the results I'd like to store and use would be looked up in tables, this would be a fantastic solution.

[HOME AUTOMATION]

I think CALL LINK supports arrays...
I have used STRASG with XB in my LPC extractor program, but not with arrays.
The E\A manual sec. 17.2.2(p.286) documents how to use.
A subprogram to pass variables would probably be short and simple, but there is a bit of a learnig curve at first.

I don't see any support for STRASG mentioned in the XB manual.
I'm not certain how I found out that it equates to >2010 in XB.

Untill RXB 2019/2020, CALL LINK is probably the way to go!

[+Lee Stewart]

3 minutes ago, HOME AUTOMATION said:

I'm not certain how I found out that it equates to >2010 in XB.

 

Page 415 in E/A manual.

 

...lee

[+Lee Stewart]

6 hours ago, HOME AUTOMATION said:

I think CALL LINK supports arrays...
I have used STRASG with XB in my LPC extractor program, but not with arrays.
The E\A manual sec. 17.2.2(p.286) documents how to use.
A subprogram to pass variables would probably be short and simple, but there is a bit of a learnig curve at first.

I don't see any support for STRASG mentioned in the XB manual.
I'm not certain how I found out that it equates to >2010 in XB.

Untill RXB 2019/2020, CALL LINK is probably the way to go!

 

This post and the one following it deal with such arrays. The first limited to 100 array elements and the second unlimited.

 

...lee

[HOME AUTOMATION]

January 30, 2016: A day that will live in infamy!

 

You have a strong mind!

[+Lee Stewart]

2 hours ago, HOME AUTOMATION said:

January 30, 2016: A day that will live in infamy!

 

You have a strong mind!

 

Though, perhaps, you can get some ideas from the code, I just realized that it does not directly address how you might manage string arrays.

 

...lee

[majestyx]

As TheBF suggested and as an experiment to see how it would work, I implemented an "out chart" using the file system and, while it does work, it's pretty slow even in emulation in Normal mode (i.e. not accelerated), so I'm guessing that real hardware it would be even slower with all the disk accessing it needs to perform. It would definitely perform faster if the charts could reside in the SAMS memory in an array as Asmusr suggested and as I was hoping might be possible. I will make do with this solution for now, but am not sure how deeply I want to delve if there may be an easier way to do it with SAMS using a future release of RXB. Thanks to all for the suggestions!

[majestyx]

I have been making progress on the baseball simulation I mentioned in the original post but am running out of memory due to all of the arrays and variables I'm needing to use, even with keeping some things on diskette like out determination. While I have about 9K of program memory left BEFORE running it, after a game has completed, I'm down to only 1.5K and 7.5K of "Stack" free, according to the SIZE command. I think the problem is I'm likely being too detailed with the stats (or would like to be) and other quirks of the game and still haven't implemented even what I consider the "must haves" such as stealing a base. Seems simple, until you realize all the different situations and probabilities it entails. The simplest is stealing 2nd, but it only gets more complicated from there. Still, I'm of the mind that if you're going to do something, do it right!

 

I've got it to the point where it plays a pretty good game while recording the stats I've been able to set up so far for it - 10 of 11 for batters, with 2 more I'd like to implement that aren't yet a feature in the game, and 10 of 17 for pitchers. The toughest part is keeping track of who is in the game, and at or up to what point each is in it. That's what makes figuring who to charge earned runs to, or who has scored a run, a bit challenging. That being said, I'm not enforcing certain rules such as who can play what fielding position, or even if you want to play the same player in more than one place in your lineup. If you want to have your batting lineup all the single best batter on the team, go for it! I figure it's cool to deal in hypotheticals.

 

So here is hoping that Rich (since I'm using RXB for it) or someone else will come up with a way of accessing SAMS memory in such a way to store variable/array data and leave more memory from program space.

 

In the meantime, here are some screens from the sim as it stands now. Still need to write a program that compiles/displays the stats in a meaningful way and of course, add a lot more teams. So far I only have four of 30 completed.

 

 

[Omega-TI]

Would be real cool if RXB, using some sort of GROM based code would just automatically reserve 500K for program space and 500K of stack and auto-magically do it's thing in the background without the user ever having to fuss with anything.  If it could do that, I'd switch to RXB in a flash and never look back.

[HOME AUTOMATION]

I know this is a little far out but... sort of fits the bill in some ways...

 

MiniMemory Cart. provides DSRs to utilize 24K HIGHMEM, 8K LOWMEM, and 4K MEDIUMMEM... Namely: "EXPMEM2", "EXPMEM1", and "MINIMEM" respectivly. Each of these DEVICE NAMES acts as a single file that can have multiple REC #s., allowing a quasi ram-disk usage. Combined with bank switching I imagine this could be multiplied... All could run from TI basic. Perhaps the DSRs could be lifted from MINIMEM and added to an XB image for use on FG99. Similarly I believe FG99 MEDIUMMEM could be paged and accessed as DEVICE NAME "MINIMEM".

[RXB]

22 hours ago, --- Ω --- said:

Would be real cool if RXB, using some sort of GROM based code would just automatically reserve 500K for program space and 500K of stack and auto-magically do it's thing in the background without the user ever having to fuss with anything.  If it could do that, I'd switch to RXB in a flash and never look back.

Backward compatibility would be impossible.

RXB 2020 will allow you to change stack location just like TML (The Missing Link) does at start up.

You can do a NEW or RUN "DSK#.FILENAME" or CALL XB("DSK#.FILENAME") and it will not lose the new stack location, not possible with TML.

Also you can change the size of RAM used in upper 24K by XB and it remembers if you use RUN or NEW.

 

 

[RXB]

2 hours ago, HOME AUTOMATION said:

I know this is a little far out but... sort of fits the bill in some ways...

 

MiniMemory Cart. provides DSRs to utilize 24K HIGHMEM, 8K LOWMEM, and 4K MEDIUMMEM... Namely: "EXPMEM2", "EXPMEM1", and "MINIMEM" respectivly. Each of these DEVICE NAMES acts as a single file that can have multiple REC #s., allowing a quasi ram-disk usage. Combined with bank switching I imagine this could be multiplied... All could run from TI basic. Perhaps the DSRs could be lifted from MINIMEM and added to an XB image for use on FG99. Similarly I believe FG99 MEDIUMMEM could be paged and accessed as DEVICE NAME "MINIMEM".

An older version of RXB 5.54 (I think) had this feature and NO ONE EVER USED IT! Not one mentioned using it or anyone ever said a word about it.

I removed it for simple reason no one seemed  to care.

 

And proof is no one noticed either.

Edited August 31, 2019 by RXB

[+TheBF]

So this is a dumb question Rich but could a "DSR" type interface be created that treats the extended memory like a big device that can hold multiple files?

Or maybe simpler just a 1MEG file? Use it as you see fit.

That would seem to be the easiest way for a TI-BASIC programmer to use the resource without learning a whole new API.

 

Just me thinking out loud. ?

[RXB]

9 hours ago, TheBF said:

So this is a dumb question Rich but could a "DSR" type interface be created that treats the extended memory like a big device that can hold multiple files?

Or maybe simpler just a 1MEG file? Use it as you see fit.

That would seem to be the easiest way for a TI-BASIC programmer to use the resource without learning a whole new API.

 

Just me thinking out loud. ?

My view is that there is way to many DSR devices and 90% of them are ROM only, meaning limited access to all DSR in TI99/4A.

RAM only DSR is now 90% of the products created today, just to few GPL DSR being used now.

This is why I keep harping on using GPL DSR routines and to quit using ROM only DSR routines.

Yes ROM DSR are smaller and slightly faster but also ROM DSR is hobbled into ROM ONLY DSR access.

A GPL DSR finds all DSR Devices, and a ROM DSR will only find Cards and that is it.

EXAMPLE: in RXB EA cart type: BASIC and it finds and goes to TI BASIC, in TI BASIC type OLD XB and it finds and goes to RXB and in RXB type OLD EA and it goes to EA Cart.

 

Example as discussed I had a GPL DSR device called PDISK that was a fake Disk Drive in upper 24K of memory in RXB version 5.54

I also made a GDISK that used GRAM space in a 40K GRAM device like PGRAM or GRAMKRACKER or GRAMULATOR in RXB version 5.80

 

Say you are running FW or DISKU or some other routine, it would never find my PDISK or GDISK as they are GPL DSR Devices that are never searched.

 

So making a PDISK for the SAMS was abandoned as most programs people use would never see a GPL DSR Device like PDISK ever.

I can not get everyone to use TI standards (GPL DSR access) so I just had to give up the use of them.

Sorry but I was even at a STANDARDS MEETING in Chicago Fair with Bud Mills way back in 1993 and was flat out ignored when I brought this subject up.

[Asmusr]

3 hours ago, RXB said:

So making a PDISK for the SAMS was abandoned as most programs people use would never see a GPL DSR Device like PDISK ever.

I agree that it's a shame that the common DSRLNK doesn't support GPL headers, but from RXB programs it would work, right? It sounds like an excellent way of using SAMS in a way that's already known to programmers, but it's still a lot of work if you need to implement a complete memory mapper. One simplification would be to limit file size to 4K (one page) and to reserve a full page for each file even if it's smaller.

[RXB]

8 hours ago, Asmusr said:

I agree that it's a shame that the common DSRLNK doesn't support GPL headers, but from RXB programs it would work, right? It sounds like an excellent way of using SAMS in a way that's already known to programmers, but it's still a lot of work if you need to implement a complete memory mapper. One simplification would be to limit file size to 4K (one page) and to reserve a full page for each file even if it's smaller.

RXB 2020 reduced the pages from 8K to 4K.

Loading and saving pages was also reduced from 8K on disk to 4K, with the added feature of loading the page where ever you wanted it to go.

Only catch is you need to name the FILE the page number they are located at...

EXAMPLE: PAGE234 would be SAMS memory page 234, now you could load it at PAGE79 if you wanted but the idea is to keep record of where it is supposed to go.

 

Memory mapper is your XB program. Making an array of pages:

 

100 DIM PAGE(255) ! page numbers 0 to 255 for a 1 Meg SAMS.

[majestyx]

So I'm still hacking away at this and am wondering if I need to change my thinking in order to conserve program space. But first I need to know if something is possible.

 

Is there a way to save/store an entire screen to either SAMS (preferred) or to disk? The reason I ask this is because I have a separate page for a main menu that can be called during the game. If there is a simple way of storing/saving the entire screen layout and then reloading it when returning from the main menu, I believe this would be more efficient and quicker than having to execute all the code to completely repopulate the screen. The way I'm doing it now is eating up a decent amount of string and program space so I'm trying to optimize what I currently have in order to add more features.

 

If this is possible, could someone please explain how this is done? I have no assembly knowledge, but if there is an assembly routine that can be called from RXB, I'd be happy to try using it.

 

Also, if someone could point me to a good article or book on TI memory management, particularly in regard to using SAMS and paging, I'd greatly appreciate it. Right now there's so much I'd like to do, but can't seem to figure out how to execute it on the TI. I've looked over Rich's IN THE DARK program listing but get lost when I see all the CALL LOAD, CALL AMSBANK, and CALL EXECUTE commands, among others.

[senior_falcon]

2 hours ago, majestyx said:

Is there a way to save/store an entire screen to either SAMS (preferred) or to disk? The reason I ask this is because I have a separate page for a main menu that can be called during the game. If there is a simple way of storing/saving the entire screen layout and then reloading it when returning from the main menu, I believe this would be more efficient and quicker than having to execute all the code to completely repopulate the screen.

This is extremely easy to do using XB256. Use screen1 when creating the menu and use screen2 for the game. To display the menu CALL LINK("SCRN1"). To go back to the game CALL LINK("SCRN2")

[majestyx]

Does XB256 work with RXB? I'm using numerous RXB subprograms so I am hoping it does. My worry would be with conflicts between the two. I only see the official TI XB mentioned in the documentation.

[RXB]

1 hour ago, majestyx said:

Does XB256 work with RXB? I'm using numerous RXB subprograms so I am hoping it does. My worry would be with conflicts between the two. I only see the official TI XB mentioned in the documentation.

Sorry no a XB256 version would have to be created called RXB256 I suppose.

 

1 hour ago, senior_falcon said:

This is extremely easy to do using XB256. Use screen1 when creating the menu and use screen2 for the game. To display the menu CALL LINK("SCRN1"). To go back to the game CALL LINK("SCRN2")

RXB has one too,  that moves entire VDP to RAM in lower 8K then makes a Screen Image file to disk or hard drive or RAMDISK. 

RXB 2020 does so in 4K chunks but RXB 2015 and previous versions did this in 8K chunks.

A slight differences is RXB saves all VDP including Sprite positions and values. (works with SAMS or no SAMS)