1 Meg Super AMS Discussion Thread

[+OLD CS1]

The board says it can do 4096K...

[+jedimatt42]

The board says it can do 4096K...

Jim said that the board as released cannot. Despite the jumpers and labelling.

 

-M@

[+OLD CS1]

Jim said that the board as released cannot. Despite the jumpers and labelling.

 

-M@

 

[+Ksarul]

True--but I am still digging into what I'll need to add to make it work to that capacity. The first run of boards won't be able to be modified sufficiently to make it work (or better said, not easily), and once I do figure it out, I'll probably have a direct path all the way to 16MB.

[Omega-TI]

16MB? I always come up with weird or far out ideas for stuff, but this one escapes me. What would a person use a 16MB card for on a TI?

As far as I know, nothing is currently being developed for the 1MB board to make it practical. So, with the exception of very few programs, and for all practical purposes, it's nothing but a new 32K card.

[+jedimatt42]

16MB? I always come up with weird or far out ideas for stuff, but this one escapes me. What would a person use a 16MB card for on a TI?

As far as I know, nothing is currently being developed for the 1MB board to make it practical. So, with the exception of very few programs, and for all practical purposes, it's nothing but a new 32K card.

 

That seems a little defeatist. It takes time. Tooling is an issue. It appears to me from watching what goes on and has gone on around here, that the toolset of choice are XB, ASM, and GCC. It is doable in each of those languages to utilize the extra memory for data, but not by any means, naturally.

 

RXB has some convenience factors over top of using it for data, including demos of using it to swap different sets of ASM routines in and out. And there is 'in the dark'.

 

fbForth makes it pretty easy to use for data.

 

TurboForth actually has a library that extends the language so you can use it for code and call the code naturally. If only our computers came with Forth instead of BASIC BITD...

 

There is C99 support, but I don't know what that looks like yet... It seems promising for a natural approach in that the linker is involved (code might stand a chance of calling code in other banks)... However, the C programmers seem to like gcc, and they can't be faulted for that.

 

It is July... didn't people just get these cards in May, or was it April?

 

You gotta remember this is only hobby time. Games like Legends and Legends II that did so much disk work, would be an awesome endeavor, and totally benefit from SAMS. But I'd have to emphasize the word 'awesome' and it's many meanings in this context. I wonder how much time those guys put into making those games...

 

-M@

[Tursi]

It seems like everyone just wants 80 column word processing, so I suppose 16MB would allow one to edit 16 copies of the King James Bible at the same time. Or one MS-Word-formatted thank you note.

 

And curse for a VERY long time when the power goes out before you save.

 

Assuming you can fill memory at a rate of 120k/s (rough numbers from old testing), it would take a flat out copy loop a little over 2 minutes to fill 16MB.

 

Uncompressed, it would take 182 SSSD floppies to fill it (91 DSSD, 46 DSDD).

 

Alternately, you could run a Star Trek simulation, and track every individual unit of a 3D space 256 units cubed, with instant lookup to each position.

 

You could store 1365 bitmap mode images uncompressed.

 

Using the animation tool I released last year, you could run about 4 minutes of continuous video with sound.

 

If you were running a data logger that recorded 30 (16-bit) samples per second about your project, house, etc, you could save data for over 77 hours.

 

Since the main challenge is getting data into the memory that you can afford to lose on a whim, it probably wouldn't ever be filled completely, except maybe by demos. But it's not too hard to go beyond 1MB, so you could consider this card as removing the memory barrier.

[Opry99er]

Interesting perspective, Tursi.

[+adamantyr]

Working on my CRPG, I realized that part of the issue is memory just isn't enough. Sure you can keep more data in memory rather than on disk. But your core engine code is largely the same. Its like putting a jet engine inside a regular car, unless you upgrade a whole lot of other things it won't be able to be utilized fully.

 

That said, I would like to get a SAM upgrade for my CF card widget, but since they're no longer being made I guess that won't be happening...

[RXB]

 

That seems a little defeatist. It takes time. Tooling is an issue. It appears to me from watching what goes on and has gone on around here, that the toolset of choice are XB, ASM, and GCC. It is doable in each of those languages to utilize the extra memory for data, but not by any means, naturally.

 

RXB has some convenience factors over top of using it for data, including demos of using it to swap different sets of ASM routines in and out. And there is 'in the dark'.

 

fbForth makes it pretty easy to use for data.

 

TurboForth actually has a library that extends the language so you can use it for code and call the code naturally. If only our computers came with Forth instead of BASIC BITD...

 

There is C99 support, but I don't know what that looks like yet... It seems promising for a natural approach in that the linker is involved (code might stand a chance of calling code in other banks)... However, the C programmers seem to like gcc, and they can't be faulted for that.

 

It is July... didn't people just get these cards in May, or was it April?

 

You gotta remember this is only hobby time. Games like Legends and Legends II that did so much disk work, would be an awesome endeavor, and totally benefit from SAMS. But I'd have to emphasize the word 'awesome' and it's many meanings in this context. I wonder how much time those guys put into making those games...

 

-M@

I am a little surprised at the lack of wanting more memory on a TI99/4A?

 

The one thing that everyone pointed out over he years is 48K SUCKS as it is just to small to do anything, and using swappable Cartridge space of the 8K is insanely problematic.

 

Example what can be done with the SAMS that makes Supercart look like JUNK:

 

Lower 8K

4K >2000 Paged space 960K

4K >3000 Paged space 960K

 

RXB program in memory running a XB program that is 11K in size controlling the rest of memory and swapping out pages.

4K >A000 (XB program)

4K >B000 (XB program)

4K >C000 (XB program)

 

Unused space in upper 24K were we imbed Assembly for XB program access using CALL EXECUTE(ADDRESS) -- (CALL LINK will not work as that only works from 4K >3000 space only).

4K >D000 (Assembly space use)

4K >E000 (Assembly space use)

 

Last section is used by XB for Numeric Variables and Constants.

4K >F000

 

This map above is how I created my IN THE DARK game, though not impressive you can see the potential of using 960K SAMS and Assembly within XB programs space at same time.

(Also it points out the huge problem with XB CALL LINK to access Assembly)

Edited July 23, 2016 by RXB

[vectrexroli]

As I got a desoldering gun from China I wanted to try to replace the 7805 voltage regulator with a TracoPower TSR 1-2450. This is a tiny 5V DC-DC converter version that is pin compatible to the 7805, but it only can handle 1A, which seems to be fine for the Super AMS board. Works fine for me so far and it does not get even warm, I have not experienced any negative side effects so far, but I tested it only for a few hours.

I am NOT encouraging anyone to replace the 7805 on his board, there is nothing wrong with that design decision, so there is nothing to "fix" here, I even felt bad touching that beautifully built board. I only wanted to check out if that solution would work.

Edited July 29, 2016 by vectrexroli

[RXB]

It seems like everyone just wants 80 column word processing, so I suppose 16MB would allow one to edit 16 copies of the King James Bible at the same time. Or one MS-Word-formatted thank you note.

 

And curse for a VERY long time when the power goes out before you save.

 

Assuming you can fill memory at a rate of 120k/s (rough numbers from old testing), it would take a flat out copy loop a little over 2 minutes to fill 16MB.

 

Uncompressed, it would take 182 SSSD floppies to fill it (91 DSSD, 46 DSDD).

 

Alternately, you could run a Star Trek simulation, and track every individual unit of a 3D space 256 units cubed, with instant lookup to each position.

 

You could store 1365 bitmap mode images uncompressed.

 

Using the animation tool I released last year, you could run about 4 minutes of continuous video with sound.

 

If you were running a data logger that recorded 30 (16-bit) samples per second about your project, house, etc, you could save data for over 77 hours.

 

Since the main challenge is getting data into the memory that you can afford to lose on a whim, it probably wouldn't ever be filled completely, except maybe by demos. But it's not too hard to go beyond 1MB, so you could consider this card as removing the memory barrier.

Using the Funnelweb 80 Column SCSI hard drive and my 80 Column SOB and TIM card with 9958 with 192K VDP memory and 19268 Colors and 8 Sprites per line was a kick ass card.

 

Using Floppies on the 80 Column card was like watching grass grow. (Floppies suck for size and for speed.)

[atrax27407]

On the other hand, an AVPC with 192K of memory and multiple RAMdisks completely eliminates the lethargy of physical disk drives. Of course, F'WEB in 80 columns is great!!

[+OLD CS1]

Like SSD before SSD was a thing.

[Omega-TI]

Any new software activity for this thing?

[Sinphaltimus]

It seems like everyone just wants 80 column word processing, so I suppose 16MB would allow one to edit 16 copies of the King James Bible at the same time. Or one MS-Word-formatted thank you note.

 

And curse for a VERY long time when the power goes out before you save.

 

Assuming you can fill memory at a rate of 120k/s (rough numbers from old testing), it would take a flat out copy loop a little over 2 minutes to fill 16MB.

 

Uncompressed, it would take 182 SSSD floppies to fill it (91 DSSD, 46 DSDD).

 

Alternately, you could run a Star Trek simulation, and track every individual unit of a 3D space 256 units cubed, with instant lookup to each position.

 

You could store 1365 bitmap mode images uncompressed.

 

Using the animation tool I released last year, you could run about 4 minutes of continuous video with sound.......<<WAIT WUT?>>>

 

Animation tool?

[Tursi]

Animation tool?

 

The thread: http://atariage.com/forums/topic/234632-animation-playback-on-the-ti-994a/

The tool: http://www.harmlesslion.com/software/vidconvert

The samples (Classic99 required to play them): http://www.harmlesslion.com/temp/vids/

[Asmusr]

 

Any new software activity for this thing?

 

I have actually made a SAMS loader for the megademo we're working on. It loads the whole demo into RAM instead of loading each file as needed, which is breaking up the demo. But, depending on your system, it can take a while to load 180K from disk, so you might prefer the cartridge version instead.

[Omega-TI]

 

I have actually made a SAMS loader for the megademo we're working on. It loads the whole demo into RAM instead of loading each file as needed, which is breaking up the demo. But, depending on your system, it can take a while to load 180K from disk, so you might prefer the cartridge version instead.

 

Woo Hoo! Looking forward to seeing it! Speeds not really an issue for me on a demo. I'll load the file from the HDX as it's two times faster than using the FDC.

[RXB]

 

I have actually made a SAMS loader for the megademo we're working on. It loads the whole demo into RAM instead of loading each file as needed, which is breaking up the demo. But, depending on your system, it can take a while to load 180K from disk, so you might prefer the cartridge version instead.

SCSI is pretty fast too, much faster than any other device except for RAM DISK or something like a huge CART.

SCSI does have a advantage above others as it can load a single file of any size.

[atrax27407]

I can load an 800K file from my RAMdisk - not too shabby!

[RickyDean]

Is the 555 timer chip used here a CMOS device, where do I find the BOM for the SuperAMS?

[+arcadeshopper]

Is the 555 timer chip used here a CMOS device, where do I find the BOM for the SuperAMS?

https://www.arcadeshopper.com/wp/?page_id=11#!/Fetzner-1mb-SAMS-board-bare-board-assembly-required/p/65657431/category=16275021 has the bom included

[RickyDean]

https://www.arcadeshopper.com/wp/?page_id=11#!/Fetzner-1mb-SAMS-board-bare-board-assembly-required/p/65657431/category=16275021 has the bom included

Thanks, Greg, that will help.

[Omega-TI]

Okay, I have one last (and probably stupid) question about the SAMS card, and then I'll no longer bring it up.

 

1) Would it be possible, to use the 8K space of a SuperCart to install a control program

that manages access to higher memory in the SAMS card?

 

2) Could a new class of programs (using a standard code) be written to access this control program?

 

Would these two things working together make it possible to effectively write bigger and use larger programs on the TI?