majestyx

Looking at that seller's 25000+ additional items for sale, this is indeed a true statement. Pre-recorded VHS tapes for $30-60, never-heard-of movies on DVD for $50, pre-recorded cassette tapes of unknown artists for $15... yep, they are definitely smoking the hope-ium.

Thanks for your input on this as well. You were very helpful in helping to get my GRAIL OF THE GODS working properly by sending me bug fixed code to get it to compile properly. I'll take my time with my new project, as I'd really like for this to be what I've always envisioned a baseball sim to be on the TI. I'll see what will work best and implement each part as I get all the pieces figured out.

Okay, I thought it may actually already be available. Take care of what you need to. This is certainly not a pressing issue. I just didn't want to implement something that would either be easier to implement in the new version, or that would need modification once the new version of RXB comes out.

Where is RXB 2018 available? I'm using 2015 since it comes with Classic99 and it's also in the development resources here. I'm thinking that since pages can now be saved as 4K instead of 8K, that may clear up my Stack Overflow issue. I'm subscribed to your channel and have watched a number of your videos which are quite helpful.

I will test this out. I need something like this to temporarily store the current game state that is displayed on the screen. Quick question: Isn't a screen 768 bytes - 32x24?

Okay, I'm now running into a Stack overflow problem, which is likely due to the string variables I'm using that are eating up stack space. I'm guessing that I need at least 8K available in the Stack in order to be able to save a screen as explained above. The loading of screens works great, I'm happy to report.

I watched it again and am still not seeing where it explains how to SAVE the screen, but the above explanation is quite helpful. I wasn't understanding how that BSAVE command worked. When I saw that it makes a "program image file," I thought that meant that it can only be used for saving PROGRAMS. The video is explaining differences in loading between RXB 2015 and 2018(?) and how some commands have been rolled into one command which utilizes parameters. I've already got ideas on how to save memory by having ready made screens which will save valuable program space by eliminating the need to redraw the screens over and over again - or at all for that matter!

I must be missing it because I only see loading of screens. How is a screen saved from within a program? As an example, let's say it's the 6th inning and I need to switch my team's pitcher because he's lost his effectiveness. I want to capture the current state of the screen, then switch to the main menu which is where I have choices to switch pitchers and rearrange the batting lineup. Once I'm done with the menu, I want to go back to the state of the screen before I switched to the main menu by reloading it. I'm missing what command is used to save the state of the screen.

No, I'm using Classic99. I don't have a physical disk drive or PEB for my real hardware. I do have a nanoPEB and a FinalGROM. My first two projects were done as proof of what COULD have been done back in the day if I only had the money to buy products that were available back then. Now I'm trying to use everything at my disposal to create a respectable stat-based baseball simulation for this platform, something that was available for most every other platform in its era such as the Apple ][ line, C64, Atari 8-bit, and even the mid-80s PC. All of those platforms had much more memory and storage at their disposal for keeping track of heavy stat games like baseball and football. With extra memory and storage, not to mention the ability to accelerate it via emulation, I think it can finally be done and I'm trying my best to make it a reality. I guess I'm just getting frustrated at the fact that the TI can technically be expanded to 1 MB (and 4 MB once it's implemented in the next iteration of the SAMS card), yet it's so difficult to actually utilize it with some modicum of ease. I appreciate the input and patience from everyone who has commented so far.

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.

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.

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.

Not sure if Video Output is the same as bad video RAM so I chose both Video Output and Other, since it may not have only been the video RAM.

By stack, I meant the amount of memory that the SIZE command returns. I wasn't sure if this was separate, but based on Tursi's explanation, it's not. According to the XB Manual So I guess I'm back to what I was discussing in a separate thread, which is a way of accessing AMS memory in order to store table/variable data, which there doesn't seem to be except for loading an entire page of memory at a time, i.e. not even a POKE command to place data into a memory location in an AMS memory bank, what's more a feature like Rasmus mentioned such as special arrays that exclusively use AMS memory. The reason I'm so wanting something like this is because I'm having a difficult time tracking all the stats I'd like to in my statistical baseball simulation I'm developing - the woes of attempting this with a 32K computer. Having access to all that extra memory would make it so much easier.

Looks like I overlooked the link to Thierry's article. Thanks for the nudge in the right direction, Greg! Also, Ksarul, what you're saying made me realize that on a physical system there wouldn't really be many people who have GRAM - certainly less than those who have a SAMS card - so this is a no-go. I did know about the difference between GROM and GRAM, along with the 6K/8K oddity, but was completely forgetting the fact that there isn't any GRAM in a TI itself, thus the need for a GRAM Kracker/Karte.

I understand there was a product called the GRAM Kracker which was used to copy cartridges to diskettes, in addition to some other features. However, I'm not understanding its usage, or at least the GRAM piece of it, particularly in RXB and Classic99. I see an RXB subprogram called POKEG with the following description: What I'm not getting is that the CALL LOAD subprogram states ...while the POKEG appears to simply place a value in a memory location, such as a POKE command does on a C64 or Apple ][ and is not loading any assembly object. I guess that "direct data" covers individual values, but it's not really explained much further than the above in the XB manual, with not even one example given. To further muddy the waters, the GRAM... option in Classic99 states So let's start at the beginning - what is GRAM? Second - "it only makes writes work" in Classic99. Does this mean it's not actually storing what being written to GRAM? Third - what addresses are "safe" to write to of those that are listed in 4 KB chunks? >0000 >2000 >4000 etc. I'm still attempting to figure a way of using additional memory as storage for table data and am having a hard time understanding all the different types of memory the TI uses - program, stack, VDP, SAMS, GRAM, GROM and any others I may have missed. What locations store program data, variable data, and the like? Is there a good book/article/publication that explains this in layman's terms? There is also a POKEV subprogram that discusses placing values in VDP memory. Since I'm still unclear as to what memory is what, and what is "safe" to use - such as with CALL POKEG/V - without messing up other data that may be stored in those memory locations, I'm really struggling to understand memory management on the TI.

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!

Sounds like a great time was had by all. Would be cool to sit down and talk a bit with Jason Scott. His contributions to the software library at the Internet Archive is simply stupendous, not to mention his Get Lamp documentary. This would really be right up my alley, as my first computer was the TI and my second was an Apple //c. I've gotten back into the Apple ][ line recently, having picked up a IIGS in nice shape. I added a Floppy Emu, jacked it up to 8 MB, replaced the on-board battery, located a decently working joystick, and am now a very happy camper! Both of these computers hold special places in my heart, along with the Amiga, as they were all at one time my main computer up until 1998 when I finally gave in and bought a PC. Now I use the PC to go back and use these machines. Oh, the irony... Thanks for sharing the pics and your experience~!

Sure, no problem, Bill! It's not seen often in the wild, although a member here (Ksarul - discussion thread here) I do believe has some new ones - as in he actually had a run of them made not long ago - available for sale. I know a good deal of the users here on AA do have one in their real hardware. The SAMS (and previously AMS) was a memory expansion board that could be plugged into the Peripheral Expansion Box (PEB). It was initially available as a 128K or 256K RAM board and was made by Asgard (Asgard Memory System, or AMS for short). It was then picked up by the SouthWest TI99ers (the S in the SAMS) and expanded to have up to 1 MB available. It has been further updated to, theoretically, expand up to 4 MB. Ksarul's version is a 4 MB board, but there is some issue that 4 MBs is not available for use, so he only has it available as a 1 MB card. Sorry, I don't own a PEB so I don't have the full details on the real hardware. I am programming in the Classic99 emulator which, among other emulators, can also emulate a SAMS expansion, so I'm trying to take advantage of it. And yes, I believe there are more people who own the expansion than there are actual programs that make use of it. Thus it has a lot of potential which never was tapped into. The biggest issue is that only 32K is actually easily usable in any Extended BASIC available, and even Assembly appears to have some limitations with it - again, not a machine language programmer so I am not that familiar with what it can do. Since I've no way of implementing the SAMS yet, as I'm using RXB 2015 (an enhanced and updated Extended BASIC by Rich Gilbertson who has made a huge game called IN THE DARK which takes full advantage of the 1 MB SAMS), the baseball game I'm making in its current form only requires 32K expansion and a disk drive/disk drive equivalent (I use a nanoPEB on my physical machine) from which to load player stats. Of course these are the "real hardware" requirements, as emulation takes care of all of this quite easily. Hope that helps~!

Looks like Opry99er has been missing for the past month and a half. In the meantime, I figured I'll share a teaser of what I have so far. It's working and plays a full game, but there are still plenty of features I'd like to implement to make it more realistic, which is why I'm looking into how to incorporate use of the SAMS card to store table and stat data. I've been doing all my test runs using the 2008 World Series teams. Once I've added more features, I'll expand on the 2008 season stats, as it's time consuming to convert them from the Statis Pro cards to the format I'm using in the game.

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.

Wanted to report an issue which may be known, as I saw it in another, older thread which I can't seem to locate right now. Every so often, Classic99 locks up on me, with 2 of the 4 cores of my CPU registering at full usage. When I open the debugger, it is blank. I am using the latest version QI399.006 on a Windows 7 64-bit machine. I've included a screenshot below of what it looks like when this happens. When it finally unlocks, the debugger goes back to working and displaying all kinds of numbers updating on the right-hand side of the window. Don't know if this provides any useful information, but just wanted to report it, since I believe that Rich (author of RXB) was the person who had this issue in the thread I am referring to.

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.

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.

So my latest project is a statistical baseball game which I'm programming in RXB. I'm trying to figure out what to include/exclude, yet still make it a worthwhile venture. This is my labor of love project, as I've always wished the TI had a statistics based sports game, especially since TI loved to tout the accuracy of their calculators. Anyway, I'm glad I found this thread. I've downloaded what I believe is your final version (v6) of the non-BBS version of the game for some tips on how to include as many features as possible. I must admit that I am using Avalon Hill's Statis Pro Baseball 2nd edition rules (from 1982), since stat cards from many seasons are widely available for free, and also for nearly all seasons for a price. To get me started, I found a copy of the Apple ][ version of the game which was written in Applesoft BASIC, requiring a 48K machine. I found some real spaghetti code, stuff that wasn't implemented but apparently planned, and even some lines of code that were never used. I found it most useful for coming up with manageable stat "cards" for players on each team, keeping the roster for each one at 25 - that's 15 batters/fielders and 10 pitchers. I too came to find that enforcing baseball's rules is a bit more intricate when programming than actually playing the game. I also realize that I'm going to have to trust players to be honest in certain situations, as I can't seem to find a way to enforce certain rules without it eating up too much program space. It would be REALLY cool if there was a way to use SAMS memory for XB/RXB program storage, or a way to chain programs together so that they don't lose the values in the variables when doing so. I find the TI boast in the XB manual to have that exact major caveat: ...provided you have no need to keep values in variables, and my guess would be that's not very often. I'd have loved to have tried converting Strat-O-Matic Baseball since I own a late 80s boxed tabletop version of it, but it's next to impossible to find entire seasons of stats for the game without paying through the nose for them. I also own numerous versions of Out Of The Park Baseball for the PC which is probably the most awesome MLB sim there is. I won't kid myself that I'll be able to get anywhere near OOTP, but I would like a halfway decent program to run on the TI, thus my project. Sooo... I currently have a working program which hasn't implemented the numerous types of outs yet, and I've only made up two teams for it, but it's definitely a lot farther along than I thought I might get. That said, it doesn't have even all of the basic SPB rules implemented either. Once I've added more features, I'll share it here, although that may be awhile. So I was wondering, was any more development ever done on the XB game that this thread refers to? Would be cool to see how far along you got.