Jump to content
Sign in to follow this  
majestyx

Need help understanding how to utilize SAMS memory in RXB

Recommended Posts

40 minutes ago, RXB said:
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.

Incorrect. As far as I know, XB256 is fully compatible with RXB. But it uses all of low memory, so SAMS access or anything that messes with low memory will not work.

 

(Edit) I should add that here I am referring to XB256 and not the compiler.

Edited by senior_falcon

Share this post


Link to post
Share on other sites
4 hours ago, majestyx said:

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 took a stab at it... I've never used SAMS before. I tried using info from Nouspikel's SAMS page, with Classic99 but I get only 1,s at CRU >1E00,>1E02. I tried to get >A000 - AFFF to page but stored values remained the same!(using EASYBUG)

 

I also tried a test program from here: #12

 

Are you using real hardware?

  • Thanks 1

Share this post


Link to post
Share on other sites

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.

Edited by majestyx
  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, RXB said:

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. 

 

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.

Share this post


Link to post
Share on other sites
4 hours ago, senior_falcon said:

Incorrect. As far as I know, XB256 is fully compatible with RXB. But it uses all of low memory, so SAMS access or anything that messes with low memory will not work.

 

(Edit) I should add that here I am referring to XB256 and not the compiler.

Hmm I am almost certain he meant the features in RXB like CALL MOVES (memory RAM/GRAM/GROM/VDP) or CALL HPUT or CALL VPUT or CALL HGET OR CALL VGET.

Or many other commands built into RXB making it so much better then XB.

Not to mention SAMS built in support. 

Share this post


Link to post
Share on other sites
2 hours ago, majestyx said:

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 if you watch the video it shows the XB routine and I explain in the video how it works. RXB 2015:

 

CALL MOVES("VR",2079,0,8192) ! this command moves VDP from address 0 (hex >0000)(2078 bytes) to Lower 8K at 8192 (hex >2000)

Screen starts at address 0 in case you did not know VDP memory locations.

CALL BSAVE("DSK3.FILENAME") ! this makes a Program Image file on disk from hex >2000 to >3FFF in lower 8K

 

We should move this conversation to a RXB thread instead of here.

Share this post


Link to post
Share on other sites
12 minutes ago, RXB said:

Hmm I am almost certain he meant the features in RXB like CALL MOVES (memory RAM/GRAM/GROM/VDP) or CALL HPUT or CALL VPUT or CALL HGET OR CALL VGET.

Or many other commands built into RXB making it so much better then XB.

Not to mention SAMS built in support. 

When XB256 is loaded, how does it interfere with CALL MOVES, CALL HPUT, CALL VPUT, CALL HGET, CALL VGET?

The answer is simple: It doesn't!

The only thing you mentioned that cannot be used is SAMS.

  • Thanks 1

Share this post


Link to post
Share on other sites
2 hours ago, RXB said:

No if you watch the video it shows the XB routine and I explain in the video how it works. RXB 2015:

 

CALL MOVES("VR",2079,0,8192) ! this command moves VDP from address 0 (hex >0000)(2078 bytes) to Lower 8K at 8192 (hex >2000)

Screen starts at address 0 in case you did not know VDP memory locations.

CALL BSAVE("DSK3.FILENAME") ! this makes a Program Image file on disk from hex >2000 to >3FFF in lower 8K

 

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!

Share this post


Link to post
Share on other sites

Alright ...dunno where I went wrong earlier..
I got some sense out of this now.

 

This will SAVE a screen(960 bytes(40x24)) to SAMS page 17(base 0)(>10), mapped to address range >3000 thru >3FFF and allow you to restore it(LOAD).

 

SAMSTESTS.DSK USE AS DSK2 or edit line 10.

 

I suppose with the addition of a couple variables, you could save 4 screens per page...

say A=x(1 thru 4) and B=x(17 thru 255) yielding 960 possible screens.

;-)

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

image.thumb.png.869c1b5158fb4b8c9d6a191039f810fc.png

image.thumb.png.1bfefd0eba39c32a7ebfc0d2f6af3e8b.png

Share this post


Link to post
Share on other sites
9 hours ago, HOME AUTOMATION said:

Alright ...dunno where I went wrong earlier..
I got some sense out of this now.

 

This will SAVE a screen(960 bytes(40x24)) to SAMS page 17(base 0)(>10), mapped to address range >3000 thru >3FFF and allow you to restore it(LOAD).

 

SAMSTESTS.DSK USE AS DSK2 or edit line 10.

 

I suppose with the addition of a couple variables, you could save 4 screens per page...

say A=x(1 thru 4) and B=x(17 thru 255) yielding 960 possible screens.

;-)

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?

Share this post


Link to post
Share on other sites

In GRAPHICS MODE, yes. I thought you might use TEXT MODE. I guess TEXT MODE is difficult to use from XB. Using 768 would buy 1 more screen save(4x960=3840),(5x768=3840).

  • Like 1

Share this post


Link to post
Share on other sites
19 hours ago, senior_falcon said:

When XB256 is loaded, how does it interfere with CALL MOVES, CALL HPUT, CALL VPUT, CALL HGET, CALL VGET?

The answer is simple: It doesn't!

The only thing you mentioned that cannot be used is SAMS.

Obviously he is talking about using them and having XB256 routines to speed them.

Why would he bring it up if not that reason as he is using RXB already?????

Share this post


Link to post
Share on other sites
23 hours ago, HOME AUTOMATION said:


I took a stab at it... I've never used SAMS before. I tried using info from Nouspikel's SAMS page, with Classic99 but I get only 1,s at CRU >1E00,>1E02. I tried to get >A000 - AFFF to page but stored values remained the same!(using EASYBUG)

 

I also tried a test program from here: #12

 

Are you using real hardware?

The BIGGEST PROBLEM WITH SAMS is where to put the memory manager and still use all 32K at same time.

Obviously the only safe RAM for Assembly is >6000 (cart RAM/ROM).

Now RXB uses GPL instead and stores the map in VDP or XB Program RAM but you really do not need a memory manager really.

RXB call CALL USER("DSK#.BATCH") that uses a file to load multiple XB programs or Assembly or Screen Images all run from a single DV80 Text file.

And you can edit this Text File easy.

 

 

The are a ton of Videos on Youtube on my channel of RXB features and changes from RXB 2000 to RXB 2018

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Majestyx originally asked: "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 responded: "Sorry no a XB256 version would have to be created called RXB256 I suppose."

This is not true and I responded: "Incorrect. As far as I know, XB256 is fully compatible with RXB. But it uses all of low memory, so SAMS access or anything that messes with low memory will not work."

RXB responded: "I am almost certain he meant the features in RXB like CALL MOVES (memory RAM/GRAM/GROM/VDP) or CALL HPUT or CALL VPUT or CALL HGET OR CALL VGET. etc..."

My response: "When XB256 is loaded, how does it interfere with CALL MOVES, CALL HPUT, CALL VPUT, CALL HGET, CALL VGET? The answer is simple: It doesn't! The only thing you mentioned that cannot be used is SAMS."

 

To remind you (Rich) yet again: XB256 is a collection of assembly language subprograms that expand the graphics capabilities of XB. That's all. Programs are written in XB and run in XB. (And are just as slow.) Hence my statement that it should be compatible with RXB. (or any other flavor of XB.) 

 

RXB response: "Obviously he is talking about using them and having XB256 routines to speed them. Why would he bring it up if not that reason as he is using RXB already?????"

This is not obvious to me since XB256 cannot speed anything up. You go on to say, in essence "He's using RXB already, so why use XB256?" RXB cannot do everything, and here are a couple possibilities: Maybe to use a proper graphics screen that can define more than twice as many graphics characters. (256 vs. 112). Maybe to use the advanced sound list player to play "Take me out to the ball game" and then superimpose the crack of a bat when a hit is made. 

 

When you respond to this, as you inevitably will, start a new thread. Call it "Why RXB and the Falcon think each other is wrong." Or something similar. This will avoid hijacking other threads. 

Share this post


Link to post
Share on other sites
On 9/5/2019 at 4:41 PM, senior_falcon said:

When XB256 is loaded, how does it interfere with CALL MOVES, CALL HPUT, CALL VPUT, CALL HGET, CALL VGET?

The answer is simple: It doesn't!

The only thing you mentioned that cannot be used is SAMS.

Again never once said INTERFERE with RXB said the routines have not support in Assembly for them like you do for things like DISPLAY AT or HCHAR  or SPRITES.

Do you have a RXB version of RMOTION (Reverse motion of a sprite or all sprites?

Do you have a RXB version of HPUT that works with entire screen unlike DISPLAY AT ignores borders on both sides, and GCHAR does not get a string like HGET in RXB.

 

But please this is the issue he talked about getting SUPPORT ROUTINES IN ASSEMBLY, not INTERFERENCE.

Look this issue is not interference it is support Assembly for same routines that you did in XB, I understand you do not want that project.

Share this post


Link to post
Share on other sites
21 hours ago, majestyx said:

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 am still working on the demo programs and other life issues presently, but hope to release this entire package as RXB 2020 due to so many routines being modified and not backwards compatible.

So hope this is done before December and uploaded.

  • Like 2

Share this post


Link to post
Share on other sites
On 9/7/2019 at 1:45 PM, RXB said:

I am still working on the demo programs and other life issues presently, but hope to release this entire package as RXB 2020 due to so many routines being modified and not backwards compatible.

So hope this is done before December and uploaded.

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.

  • Like 1

Share this post


Link to post
Share on other sites
On 9/5/2019 at 3:05 PM, senior_falcon said:

Incorrect. As far as I know, XB256 is fully compatible with RXB. But it uses all of low memory, so SAMS access or anything that messes with low memory will not work.

 

(Edit) I should add that here I am referring to XB256 and not the compiler.

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.

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...