1 Meg Super AMS Discussion Thread

[+TheBF]

2 hours ago, FarmerPotato said:

I figured you’d write ALLOCATE to guarantee  that one whole array stays in one 4K page. Then only one  BIG[ call to get at the struct. 
 

Starting to think about the efficiency/overhead after you asked. 

I like how 2 banks solves the problem of linked lists that need to grow past a 4K page boundary. 

I dumbed it down to match my brain. ?

By limiting to 16 x 64K segments the programmer decides which segment is used for what.

>> The code a threw together yesterday is flawed because the hi level data structures don't record the SAMS page# at compile time so I will fix that and re-post over on Camel99 topic.

 

It is possible to allocate everything as records across the entire 1Mbyte card with the BLOCK word like this:

(this is the same kind of code used for Forth virtual memory disk blocks)

VARIABLE BLK
: ]RECORD ( n -- addr)  RECSIZE UM* 4K UM/MOD 1STBLK + DUP BLK ! BLOCK + ;

RECSIZE in this example was set to 128 bytes. 

1STBLK is just a floor protecting SAMS pages you don't want used. It could be zero. 

 

So this would let you can address n=65536 by 128 byte records or 8Mbytes of data. 

It VERY convenient that 9900 does 16/32 mixed multiply and divide with mod.  

 

[+TheBF]

2 hours ago, FarmerPotato said:

I figured you’d write ALLOCATE to guarantee  that one whole array stays in one 4K page. Then only one  BIG[ call to get at the struct. 

No real need to get fancy. It's Forth after all.

If you just want to squeak a 4K character array into a SAMS page then you can use BLOCK bare-ass naked. ?

Read and write with C@ and C! because it's local memory after BLOCK runs.

 

23 CONSTANT DEDICATED 

: ]DATA   ( n -- addr)   DEDICATED  UM/MOD  ( offset blk#)  BLOCK + ;  

It's pretty fast once the page is brought into the RAM window. 

Lee wrote some code to replace UM/MOD with shift instructions and such and it is a bit faster. 

I should probably integrated that into BLOCK.

 

[Switch1995]

I noticed the (2) three pin jumpers (J1 & J2) are not on the material list for the bare board SAMS.  Do I just solder a permanent bridge to the 512 on both of these since 4M is not an option? Thanks!

[+Ksarul]

38 minutes ago, Switch1995 said:

I noticed the (2) three pin jumpers (J1 & J2) are not on the material list for the bare board SAMS.  Do I just solder a permanent bridge to the 512 on both of these since 4M is not an option? Thanks!

For most purposes, that solution will work perfectly.

 

If your board is the 2017 or 2020 edition, it is actually possible to build it as a 4M board--but the memory chips to do that are not reliable enough to actually make it a reasonable option. New 2M memory chips are actually available from at least one manufacturer, but the price is over $125 per chip and a board would need two of them, which is not economical. Used chips can be found for as little as $25 each, but generally, I've had to purchase four chips to find one good one, so not really economical. I install the 3-pin jumpers on boards that I build, just in case I find a good supply of the 2M chips though. I am still looking at other options to expand the board, but no solutions yet.

[Switch1995]

Hoping someone could point me in the right direction here.  Can XB programmers use SAMS to pass program control using line numbers?  Here is a example program to demonstrate what I'm asking:

 

*Program 1 of 3
10 CALL CLEAR
20 A=10
30 CALL CHAR(96,"FFFFFFFFFFFFFFFF")
40 CALL CHAR(97,"F0F0F0F0F0F0F0F0")
50 ***bank programs 2 and 3 into SAMS***
60 DISPLAY AT(10,1):"PRESS 1 OR 2"
70 CALL KEY(0,K,S)::IF S<>1 THEN 70
80 IF K=49 THEN 100
90 IF K=50 THEN 130
100 ***load program 2 from SAMS***
110 GOSUB 9000
120 GOTO 70
130 ***load program 3 from SAMS***
140 GOSUB 9000
150 GOTO 70

*Program 2 of 3
9000 CALL HCHAR(96,12,16)
9010 A=A+1
9020 DISPLAY AT(18,16):A
9030 RETURN

*Program 3 of 3
9000 CALL HCHAR(97,12,16)
9010 A=A+1
9020 DISPLAY AT(18,16):A
9030 RETURN

 

 

The follow-up question, if yes, is what is the special sauce to replace the *** lines in the code above to make it work?  Thanks!

Edited October 24, 2022 by Switch1995

[+Ksarul]

Regular TI Extended BASIC isn't really SAMS-aware. You would have to write (or repurpose routines used in other SAMS-aware programs) in order to do anything there. The real problem with the approach you are loking at here is Extended BASIC though. It is designed to store a single program in memory (although it can load and use multiple different assembly programs in the lower memory space). The moment you tried to switch things out to utilize the program in SAMS-space, you would destroy all of the pointers to your main program.

 

For some really good ways to use SAMS from an Extended BASIC style environment, look at some of Rich Gilbertson's how-to videos for RXB. He has taken a lot of time to integrate SAMS support into RXB and his videos do a great job of outlining the realm of the possible there. You can even get some additional tips on RXB/SAMS use by looking at his In The Dark game, an RXB game that uses most of the SAMS memory space.

[Switch1995]

Thanks, Ksarul.  Maybe I can beg @RXB Rich to show what my 3 little programs here would look like in RXB.  I did find his source code for "In The Dark", but it was prior to his rewrite of CALL AMSxxx to CALL SAMS.

Edited October 24, 2022 by Switch1995

[RXB]

1 hour ago, Switch1995 said:

Thanks, Ksarul.  Maybe I can beg @RXB Rich to show what my 3 little programs here would look like in RXB.  I did find his source code for "In The Dark", but it was prior to his rewrite of CALL AMSxxx to CALL SAMS.

Yea sorry I changed from RXB 2001 CALL AMSBANK to now (RXB 2022) it is CALL SAMS.  But now you can tell SAMS what bank and where in memory to use it.

Previously you only tell SAMS memory what bank but not the location.

 

The above program by SWITCH1995 is not really a SAMS doable project as it says 100 ***load program 2 from SAMS***

Is this a Assembly program as the TI99/4A OS does not allow multiple programs to run at same time as the next line is 110 GOSUB 9000

So, this shows a real misunderstanding of how the SAMS functions and how different RXB uses the SAMS.

 

RXB has always handled SAMS as a DATA storage in blocks of memory but unlike files you only load all blocks once much unlike FILES that require it each time used.

Or RXB handles SAMS as Assembly Support so you can load vast number of Assembly Language and switch them on demand.

 

This DEMO from 2018 pretty much explains all of it.

 

 

 

[Switch1995]

19 minutes ago, RXB said:

this shows a real misunderstanding of how the SAMS functions and how different RXB uses the SAMS

You can say that again!!  Haha, no worries.  I'll keep plugging away at the documentation and will figure it out.  

[RXB]

8 minutes ago, Switch1995 said:

You can say that again!!  Haha, no worries.  I'll keep plugging away at the documentation and will figure it out.  

Using RXB for your project is very possible depending on what you are loading is DATA or Assembly, you can load XB programs like I showed in DEMO.

But keep in mind you could never run both at same time.

My game IN THE DARK has pretty much everything do get as close to doing that in one package and does use most of SAMS memory to do it.

I did have a 943K SAMS version of my game IN THE DARK that is just monstrous to load.

 

IN THE DARK uses VDP screens loaded to SAMS then onto the screen and also reverse as it saves what you did on screen at end or game or when you pause game.

It also uses Assembly from 32K in the upper 24K at >D000 and I do not use CALL LINK to run that Assembly instead use RXB command CALL EXECUTE(address) instead.

You should look it over as it used almost every trick I could think of for a game in RXB.

[Switch1995]

From XB256:   CALL LINK(“RUNL1”,A$) RUNL1 is used to run an XB256 program from a running program. It is similar to CALL LINK(“RUN”) but there is a major difference. After it loads the program it runs line #1, but without doing a prescan or resetting any of the variables of the calling program. By chaining programs together with RUNL1 you can create a very long XB256 program, with instant start up of the chained programs. See page 26 for more information.

 

I am tempted to just pull the ejection handle on SAMS and go this route using XB256 programs loaded from TIPI....

[RXB]

33 minutes ago, Switch1995 said:

From XB256:   CALL LINK(“RUNL1”,A$) RUNL1 is used to run an XB256 program from a running program. It is similar to CALL LINK(“RUN”) but there is a major difference. After it loads the program it runs line #1, but without doing a prescan or resetting any of the variables of the calling program. By chaining programs together with RUNL1 you can create a very long XB256 program, with instant start up of the chained programs. See page 26 for more information.

 

I am tempted to just pull the ejection handle on SAMS and go this route using XB256 programs loaded from TIPI....

Yes as managing Memory is very complicated vs file access. (Though I have tried to explain something so complicated to people many times.)

RXB does have a command batch file system and a demo that is has almost unlimited size.

RXB 2022D CALL USER chains both Assembly and XB programs together that takes up 400K of disk space into a single batch file of 191sectors DV 80 file.

This was first demo in RXB 2001 this is from 2012 but mostly same demo:

 

 

[Tuxon86]

Silly question... I'm an expert in those 🙂

 

Would it be possible to have more than one Sams card in a Peb? One that does the 32k + expanded ram and the other that offer it's ram at a different CRU. Not that there's really any need for multiple Sams at the moment, but I'm just currious...

[+Ksarul]

31 minutes ago, Tuxon86 said:

Silly question... I'm an expert in those 🙂

 

Would it be possible to have more than one Sams card in a Peb? One that does the 32k + expanded ram and the other that offer it's ram at a different CRU. Not that there's really any need for multiple Sams at the moment, but I'm just currious...

Short answer: no.

 

Long answer: it is possible to build a larger SAMS card with more memory. The current iteration of the board actually supports up to 4M, but the memory chips it needs to do that are so unreliable that it makes no sense to try building one with them. I am looking at other options there, but I don't have any concrete answers yet. From a pure memory management standpoint, the memory mapper chip supports up to 16M, so there is actually a lot of headroom there.

[Tuxon86]

20 minutes ago, Ksarul said:

Short answer: no.

 

Long answer: it is possible to build a larger SAMS card with more memory. The current iteration of the board actually supports up to 4M, but the memory chips it needs to do that are so unreliable that it makes no sense to try building one with them. I am looking at other options there, but I don't have any concrete answers yet. From a pure memory management standpoint, the memory mapper chip supports up to 16M, so there is actually a lot of headroom there.

Thank you for your patience with my silly questions 🙂

 

[+arcadeshopper]

1 hour ago, Tuxon86 said:

Silly question... I'm an expert in those 🙂

 

Would it be possible to have more than one Sams card in a Peb? One that does the 32k + expanded ram and the other that offer it's ram at a different CRU. Not that there's really any need for multiple Sams at the moment, but I'm just currious...

sams provides 32k - only 1 32k source will work at a time 

1mb sams is larger than any software we currently have made that I know of, why would you need more?

4mb sams is available but expensive (ram costs) 

 

[Tuxon86]

6 minutes ago, arcadeshopper said:

sams provides 32k - only 1 32k source will work at a time 

1mb sams is larger than any software we currently have made that I know of, why would you need more?

4mb sams is available but expensive (ram costs) 

 

It's not about needs, but about if it's possible or not.

 

If the mapper can address 16mb as was said by @Ksarul, I was just trying to see if it was possible to max it out via multiple peb cards. I really don't see a need for it, but then again if we weren't fan of using things in a way they never were designed to be used originally, we wouldn't be in this hobby! 🙂

 

Your store, which I like a lot, is based on expanding the old tech via modern devices and pushing the limits. Most of my questions are also based on that spirit. I'm only curious about what could be done to upgrade those old computers. 

 

I also don't mind breaking compatibility with the old software library since I mostly play those games via emulation. My fun with those system is to thinker and code. This is also the reason  why the Commander X16 is interesting to me. It's something different.

[hhos]

On 11/14/2022 at 7:37 AM, Ksarul said:

Short answer: no.

 

Long answer: it is possible to build a larger SAMS card with more memory. The current iteration of the board actually supports up to 4M, but the memory chips it needs to do that are so unreliable that it makes no sense to try building one with them. I am looking at other options there, but I don't have any concrete answers yet. From a pure memory management standpoint, the memory mapper chip supports up to 16M, so there is actually a lot of headroom there.

Ksarul, have you found a solution to your troubles with the 2M SRAM?  I think it unlikely that the chips are the source of the problem.  You might try to find a better grade of socket, or even better, solder them into a board.  Solder would almost certainly cure the problem.

 

I haven't seen whether or not you put a 16MB version schematic out, so I made one up.  I haven't tried it because I don't have a SuperAMS board.  This should work, though.

[+Ksarul]

On sockets, I was using gold machine-pin sockets @hhos, so there really isn't something higher-grade to move on to. We did get a couple of boards working by the direct solder method--but there really are a lot of random issues with these chips, as we went through several chips before we had a set that worked right all the time. At the usual cost per chip, having 2-3 bad ones for each one that works is not even remotely economical. That was what put this on hold more than anything else. . .the design works, but the cost to make it work reliably is somewhat prohibitive, based on part reliability.

[+OLD CS1]

For moving above 1MB, is there any thought on using SIMMs?  While old as dirt, there is still a great supply of usable old stock.  I have 4MB, 8MB, 16MB, and 32MB 72-pin SIMMs around here I use on my Amiga stuff which all work just fine.

[GDMike]

1 hour ago, OLD CS1 said:

For moving above 1MB, is there any thought on using SIMMs?  While old as dirt, there is still a great supply of usable old stock.  I have 4MB, 8MB, 16MB, and 32MB 72-pin SIMMs around here I use on my Amiga stuff which all work just fine.

Good, I've got buches of 1 and 4 mb.. even some 32K and 256s. Up to 8mb. Just sitting in a coffee can lol

[JasonACT]

2 hours ago, OLD CS1 said:

is there any thought on using SIMMs?

They are DRAM, so would need a refresh circuit, and would add complexity and cost to the design.  I used a tiny 8 pin 8MB PSRAM for my Pico design, and can configure 32K standard, 1MB, 2MB or 4MB SAMs and that chip only costs AU$3.50 - but as @arcadeshopper has said, nothing uses more than 1MB, so I don't bother to configure mine any higher.

 

I'd love to see something cool that uses 4MB.  But we don't need the hardware to create that when the emulators already do it, once something is created that uses it, then we need the hardware.

[hhos]

4 hours ago, Ksarul said:

 At the usual cost per chip, having 2-3 bad ones for each one that works is not even remotely economical. That was what put this on hold more than anything else. . .the design works, but the cost to make it work reliably is somewhat prohibitive, based on part reliability.

That's strange.  Who would sell something that consistently lowered their customer's expectations?  It's not good marketing for the long run.  Perhaps a design assumption is wrong.  Power supply troubles is what leaps immediately to mind for me.  Is it possible that those were designed to be used at a lower voltage, maybe +3VDC-+3.3VDC?

 

4 hours ago, OLD CS1 said:

For moving above 1MB, is there any thought on using SIMMs?  While old as dirt, there is still a great supply of usable old stock.  I have 4MB, 8MB, 16MB, and 32MB 72-pin SIMMs around here I use on my Amiga stuff which all work just fine.

SIMMs sound like a great idea to me.  I don't know what capacity the SIMMs I have lying around are, but I've sure got a lot of them.  I think the simplicity of the SRAM design won out in the Super AMS.  A SIMM memory would require RAS/CAS logic and refresh.  Also, there might be wait states, perhaps not as many as the TI 32K has, if you apply some/most/all of Thierry's mods to the "wait state generator" in the console.  But that applies to the SAMS as well.

 

If we're talking about designing another memory board, how about moving the mapping registers to >5F00+?  Then we could put in a proper DSR ROM header in the memory space that the SAMS mapping registers use. 

Edited February 10 by hhos

[+arcadeshopper]

5 hours ago, hhos said:

That's strange.  Who would sell something that consistently lowered their customer's expectations?  It's not good marketing for the long run.  Perhaps a design assumption is wrong.  Power supply troubles is what leaps immediately to mind for me.  Is it possible that those were designed to be used at a lower voltage, maybe +3VDC-+3.3VDC?

 

SIMMs sound like a great idea to me.  I don't know what capacity the SIMMs I have lying around are, but I've sure got a lot of them.  I think the simplicity of the SRAM design won out in the Super AMS.  A SIMM memory would require RAS/CAS logic and refresh.  Also, there might be wait states, perhaps not as many as the TI 32K has, if you apply some/most/all of Thierry's mods to the "wait state generator" in the console.  But that applies to the SAMS as well.

 

If we're talking about designing another memory board, how about moving the mapping registers to >5F00+?  Then we could put in a proper DSR ROM header in the memory space that the SAMS mapping registers use. 

Marketing... Ha This is hobby stuff at this point if people really want something.  Make it you may sell 10-100 

 

A ram board that can be compatible with all the different memory standards for the 4a would be the game changer. Add a DSR and make it switchable for sams and myarc at least to make it xbii capable and maybe partitions as a RAM disk with backup battery or nvram ..  but you better do it for the fun as the market is small and unless you make both peb and sidecar models it's even smaller

 

 

[+retroclouds]

On 11/14/2022 at 4:41 PM, arcadeshopper said:

sams provides 32k - only 1 32k source will work at a time 

1mb sams is larger than any software we currently have made that I know of, why would you need more?

4mb sams is available but expensive (ram costs) 

 

 

I for one would be very interested in bigger SAMS. Could for example imagine having Final command in 1MB and stevie in the higher 1MB.

And to be honest I have run into the 1MB limit a couple of times while testing Stevie