Some 32k / SAMS memory questions

[+Lee Stewart]

So would this be the place (bold and italics)?

What's up with those addresses - aren't they out of range (831A and 8318)? (Sorry for my naiveté ).

 

Now, I would imagine variables names have to be kept somewhere, too, and would have to 'come along for the ride' when moving between pages of SAMS and stack(?). This also makes me wonder if I would need separately named arrays for each page of SAMS, or if one name may be used for all pages...

 

The >83xx addresses are pointers in scratchpad RAM (>8300 – >83FF). For example, >8370 contains the highest user-addressable VRAM address. You can see it change after each FILES command.

 

...lee

[+Lee Stewart]

I don't mean to give the impression that scratchpad RAM is only used for pointers. It is, of course, used for a fast scratchpad because it is on a 16-bit bus. It also contains workspaces for the console ISR and GPL. XB makes extensive use of scratchpad RAM. Thierry's site has that info as does the E/A Manual (Appendix 24.3.1).

 

Appendix 24.4 of the E/A Manual has useful additional memory allocation information.

 

...lee

[+Ksarul]

Why don't you take a look at the code Rich posted for the RXB game he wrote (In the Dark)? That may give you lots of clues for how to interface with the AMS memory. . .

[RobertLM78]

Why don't you take a look at the code Rich posted for the RXB game he wrote (In the Dark)? That may give you lots of clues for how to interface with the AMS memory. . .

Funny, that was actually going to be my next step, but even that seems to load assembly 'program' files (EA5), like the other examples.

[RobertLM78]

I'm willing to bet this has been done before, perhaps not using RXB, but nonetheless, it probably has been done. Well, just in case, I'm going to post it. What I did was wrote a little program to peek into VDP RAM after a cold boot. Now granted there are some strings in the little program that are probably getting stored in VDP memory, but other than that, the memory should be clean.

 

 

100 F=0 :: ADB=0
110 OPEN #2:"WDS1.PRINTOUT"&STR$(F),SEQUENTIAL,OUTPUT,DISPLAY,VARIABLE 80
120 CALL CLEAR :: DISPLAY AT(3,1):"WRITING ADDRESS:"
130 FOR D=ADB TO 16383
140 CALL PEEKV(D,X)
150 CALL HEX(D,H$,X,B$)
160 PRINT #2:"ADDRESS:";H$,D:"VALUE:";B$,X
170 DISPLAY AT(4,1)
180 IF D=0 THEN 200
190 IF D/1024=INT(D/1024) THEN F=F+1 :: ADB=D+1 :: CLOSE #2 :: GOTO 110
200 NEXT D
210 CLOSE #2 :: END

 

 

 

Next I intend to do the same thing, right after loading the arrays into memory (well, probably half of what fits: ~75 records), then I can compare - of course, >0800 to >37D7 seems the likely place to look for those differences.

 

I dunno, maybe I'm over-thinking....? (I should probably get Rich's eyes over here at this point).

VDPram.zip

Edited June 28, 2014 by RobertLM78

[RobertLM78]

Okay, following along with what I was planning, I went ahead and loaded the arrays and then used PEEKV to look into VDP RAM again. Now I haven't checked the comparisons yet - I wrote a program to do that for me, so now its just a matter of going through those files and looking at the differences. I've attached everything I've got so far in a nice package of TIFILES, for those that are curious .

VDPram-package.zip

[RXB]

I think the point that Rich was making is that RXB uses SAMS memory without using assembly. He is correct considering that RXB commands resemble an Extended Basic program by the use of line numbers with its command statements. However, I wonder if we are getting into a question of semantics with the extensive use of CALL LOAD and CALL PEEK statements in the Query Program example.

 

It has been a few years since I last used either SAMS or RXB. These are now on my 'To Do' list as I slowly work my way back into using my real iron TI-99/4A and its MESS emulator.

 

In considering Robert's FILES question, you must remember that the SAMS memory card loses its contents when the computer is turned off. Perhaps this is why I have never seen a SAMS program that retains contents when turned off. Art Green's Menu Loader program allowed you to place a number of .assembly programs in SAMS memory and they could be instantly accessed as long as the TI was still on. There is also a SAMS program that played XB music programs temporarily loaded on a SAMS card.

 

Robert, you should be able to place your arrays on the SAMS card while you update them but you will have to save their content to external storage before shutting down your TI or emulator. Of course, your arrays could be put on HRD or even on hard disks. Mess can handle pretty large ram or hard disks and these do not lose contents when MESS is turned off.

 

Just some thoughts to consider,

 

Jacques

 

.

RXB has a way to quickly SAVE the entire SAMS.

100 ! SAVE 119 LOWER 8K PAGES (2 4K pages equals 1 8K page)
110 CALL CLEAR
120 FOR P=1 TO 238 STEP 2
130 CALL AMSBANK(P,P+1)
130 CALL BSAVE("WDS2.RXBSAMS.AMS"&STR$(INT(P/2)))
140 NEXT P

This would create files 1 to 119 of 8K SAMS pages on WDS2 in directory RXBSAMS.

[RobertLM78]

Investigation is on-going, but it appears that BASIC starts storing string arrays starting from a high address in VDP and works its way down. For example, A$(1,0) is found from >310F to >3113 while A$(2,0) is found from >30D7 to >30DB. Interestingly T$(1),S$(1), and N$(1) are between A$(1,0) and A$(2,0).

 

Also, I'm running the test again for reproducibility, so far, everything I've found in the first run is in the exact same location for the second run. My concern is when I move away from a proof-of-concept to an actual program, how much of an offset is it going to have if I change the size of the DIMensions(?). (My test tries to cram about half of what fits in VDP, I would imagine for the real program I will probably use smaller array sizes).

 

 

Comparison.txt

Edited July 4, 2014 by RobertLM78

[RobertLM78]

BTW, is there a collection of Barry Traver's stuff to be found around anywhere? Rich was telling me about some libraries/utilities of his that will be helpful for this project.

[Gazoo]

Barry's XXB is included in XB v2.7. Just do a CALL XXB either from the command line or within a program and XXB is available for your use.

 

Gazoo

[RXB]

Barry's XXB is included in XB v2.7. Just do a CALL XXB either from the command line or within a program and XXB is available for your use.

 

Gazoo

We need the entire package as it included all the XB routines and assembly routines.

It is very cool the XXB is in XB v2.7 but for the project that Robert has in mind he needs the XB programs.

Are these also included?

Edited July 4, 2014 by RXB

[RXB]

So here is a Original Demo of AMS I did at a TI Faire back in 1995 or 1997 I think.

I will post a better one of this as part two as I did not have the paperwork to pull off a good demo in this video:

 

[Tursi]

Investigation is on-going, but it appears that BASIC starts storing string arrays starting from a high address in VDP and works its way down. For example, A$(1,0) is found from >310F to >3113 while A$(2,0) is found from >30D7 to >30DB. Interestingly T$(1),S$(1), and N$(1) are between A$(1,0) and A$(2,0).

 

Also, I'm running the test again for reproducibility, so far, everything I've found in the first run is in the exact same location for the second run. My concern is when I move away from a proof-of-concept to an actual program, how much of an offset is it going to have if I change the size of the DIMensions(?). (My test tries to cram about half of what fits in VDP, I would imagine for the real program I will probably use smaller array sizes).

 

 

 

 

Strings are basically allocated in a stack-like fashion, growing downwards as you noted. Every time you assign a string, new space is allocated, so you can test that too! Eventually, when there's no room for new strings (the actual determination is a bit more aggressive than that, I believe), a "garbage collection" is performed which frees up the memory from old strings that are no longer needed.

[RXB]

 

 

Strings are basically allocated in a stack-like fashion, growing downwards as you noted. Every time you assign a string, new space is allocated, so you can test that too! Eventually, when there's no room for new strings (the actual determination is a bit more aggressive than that, I believe), a "garbage collection" is performed which frees up the memory from old strings that are no longer needed

 

In XB you have to do a:

100 A=10
110 CALL TEST(A)! Global variable so does not invoke Garbage collection each time.
120 GOTO 120

200 SUB TEST(B)! Anytime a temporary variable is used a Garbage collection is needed.
210 SUBEND

Here is how it works in XB:

<0411>               ***********************************************************
<0412>               * Search and clean up stack and symbol table to not allow
<0413>               * garbage to accumulate
<0414>               ***********************************************************
<0415> 767F BD,52,6E CLEAN  DST  @VSPTR,@FAC8      Get a temporary stack pointer
<0416> 7682 C5,52,24 CLEAN1 DCH  @STVSPT,@FAC8     While not end of stack
<0417> 7685 56,BE           BR   G76BE
<0418> 7687 BC,58,E0        ST   V@2(@FAC8),@FAC14 Get stack ID byte
       768A 02,52
<0419> 768C A6,58,66        SUB  >66,@FAC14        Check the range
<0420> 768F C6,58,04        CH   >04,@FAC14        If string, numeric, >70, >72
<0421> 7692 56,98           BR   G7698
<0422> 7694 0F,78           XML  VPOP              Throw it away (Must be on top
<0423> 7696 56,7F           BR   CLEAN
<0424> 7698 8A,58    G7698  CASE @FAC14
<0425> 769A 56,A7           BR   CLEANG            GOSUB entry                >6
<0426> 769C 56,AD           BR   CLEANF            FOR   entry                >6
<0427> 769E 56,B7           BR   CLEANU            UDF   entry                >6
<0428> 76A0 56,A4           BR   CLEANE            ERROR entry                >6
<0429> 76A2 56,B1           BR   CLEANS            SUB   entry                >6
<0430> 76A4 06,A0,14 CLEANE CALL SQUISH            ERROR Entry - squish it out
<0431> 76A7 A7,52,00 CLEANG DSUB 8,@FAC8           Go down 1 entry
       76AA 08
<0432> 76AB 56,82           BR   CLEAN1            Go on to next entry
<0433>               * Jump always
<0434> 76AD A7,52,00 CLEANF DSUB 16,@FAC8          Keep it around but get below
       76B0 10
<0435> 76B1 A7,52,00 CLEANS DSUB 16,@FAC8          16 bytes further down
       76B4 10
<0436> 76B5 56,82           BR   CLEAN1            FOR or SUB entry
<0437>               * Jump always
<0438> 76B7 87,4E    CLEANU DCLR @FAC4             Cause delink to work right
<0439> 76B9 06,A0,10        CALL DELINK            Delink the symbol table entry

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0056 
EDIT-359
<0440> 76BC 56,A7           BR   CLEANG
<0441> 76BE 00       G76BE  RTN

[RobertLM78]

So here is a Original Demo of AMS I did at a TI Faire back in 1995 or 1997 I think.

I will post a better one of this as part two as I did not have the paperwork to pull off a good demo in this video:

:thumbsup: Using AMS for a RAMdisk is pretty cool idea. It's hard to see the code for that, and as far as I can tell it's not in the RXBDemo (2012), could you post it?

Edited July 4, 2014 by RobertLM78

[RXB]

Here you go the second demo and a better video. Also the zip files.

 

RXB AMS DEMO DISK.zip

[RobertLM78]

Investigation is on-going, but it appears that BASIC starts storing string arrays starting from a high address in VDP and works its way down. For example, A$(1,0) is found from >310F to >3113 while A$(2,0) is found from >30D7 to >30DB. Interestingly T$(1),S$(1), and N$(1) are between A$(1,0) and A$(2,0).

....

In addition to filling VDP downwards, I initially missed the fact that it looks like each string element is 'wrapped' by it's length (so A$(1,0) is 'ADAMS', so memory values for it are 5,65,68,65,77,83,5). I still haven't found the array name or element numbers, but those I'm not sure will be so obvious.

Edited July 5, 2014 by RobertLM78

[RXB]

Maybe it was Tigercub that had those routines?

 

Will have to go find them now.