Jump to content
Omega-TI

1 Meg Super AMS Discussion Thread

Recommended Posts

RXB has the easiest way to use SAMS so far.

 

Since RXB 2001, has built in page switching since 2001, and built in LOADER/SAVER :Program Image utility for lower 8K.

 

RXB 2019 will have not only lower 4K LOADER/SAVER Program Image for lower 8K but ANY SAMS RAM MEMORY ADDRESS.

 

Using RXB 2019 as long as you do not turn off P-BOX you could same all of SAMS to disk or hard drive or RAMDISK and make a loader for it.

 

This would mean you could save FW to disk as Program Image with settings loaded and return to where you left off.

 

Or other programs as long as you know pointer to restart. This would even work for FORTH or Assembly or Games.

  • Like 1

Share this post


Link to post
Share on other sites

RXB has the easiest way to use SAMS so far.

 

Since RXB 2001, has built in page switching since 2001, and built in LOADER/SAVER :Program Image utility for lower 8K.

 

RXB 2019 will have not only lower 4K LOADER/SAVER Program Image for lower 8K but ANY SAMS RAM MEMORY ADDRESS.

 

Using RXB 2019 as long as you do not turn off P-BOX you could same all of SAMS to disk or hard drive or RAMDISK and make a loader for it.

 

This would mean you could save FW to disk as Program Image with settings loaded and return to where you left off.

 

Or other programs as long as you know pointer to restart. This would even work for FORTH or Assembly or Games.

 

That's sounds great. How do you see it working for low level languages?

What do I need to have loaded and what do I call to make it go?

Share this post


Link to post
Share on other sites

 

That's sounds great. How do you see it working for low level languages?

What do I need to have loaded and what do I call to make it go?

Well if it works for Assembly as I have demos of doing just that, it will work for Forth or Assembly.

 

My demos of RXB 2001 did this, so RXB 2019 will be a much better upgraded version of this demo.

 

Share this post


Link to post
Share on other sites

I just installed my SAMS board! It is awesome and working perfectly! I am enjoying playing Rich's In The Dark game. Can this be converted to load from the FG99?

  • Like 2

Share this post


Link to post
Share on other sites

I just installed my SAMS board! It is awesome and working perfectly! I am enjoying playing Rich's In The Dark game. Can this be converted to load from the FG99?

 

aren't you already running rxb from the fg99 to run it?

 

Greg

  • Like 3

Share this post


Link to post
Share on other sites

aren't you already running rxb from the fg99 to run it?

 

Greg

I'm guessing he means is there a way to combine RXB and the game into a single cartridge file to run? Dunno if that would be possible

  • Like 1

Share this post


Link to post
Share on other sites

I'm guessing he means is there a way to combine RXB and the game into a single cartridge file to run? Dunno if that would be possible

Maybe in rxb 2020

 

Sent from my LG-H872 using Tapatalk

  • Like 2

Share this post


Link to post
Share on other sites

I'm guessing he means is there a way to combine RXB and the game into a single cartridge file to run? Dunno if that would be possible

Naw, he is running RXB 2015 and my IN THE DARK game using a SAMS.

  • Like 2

Share this post


Link to post
Share on other sites

Sorry for the confusion, I currently load RXB 2015 from the FG99 and then load the game within RXB from the TIPI. I was wondering if the game could be compiled into a .bin file that could be loaded from the FG99 as Iwantgames mentioned.

Share this post


Link to post
Share on other sites

Sorry for the confusion, I currently load RXB 2015 from the FG99 and then load the game within RXB from the TIPI. I was wondering if the game could be compiled into a .bin file that could be loaded from the FG99 as Iwantgames mentioned.

Sorry there is no SAMS loader in TIPI and RXB has its own built in SAMS memory loader and switching mechanism.

  • Like 1

Share this post


Link to post
Share on other sites

SAMS has no real "platform" on the TI, any application written for it has to roll their own loaders and manage paging itself.

 

For example, my CRPG is a 144k program binary, 72K of which is program "modules" of 12K each. One module always resides in memory in the lower 24K block, the upper 24K is switched to whatever module is needed. The lower 8K block is used for data access and is switched frequently as needed.

 

Loading all this required writing a custom loader which opens to the binary and reads it in 8K chunks which are then copied to the CPU RAM page needed. It takes about a minute or so to load the game from TIPI, faster in Classic99.

 

Art Green's old AEMS assembler offered a linking loader design that could load object code into pages, but I'm not sure the design was ever fully worked out. Consider that if you wrote all your code into 4K module chunks loaded generically into a SAMS card (you don't have fixed pages for anything), that would mean maintaining a list somewhere of modules and their page assignments, which could get messy very quickly. Especially if one module is dependent upon another one being in memory at the time. I'd much rather write my games than focus on designing a framework to drive them on.

  • Like 2

Share this post


Link to post
Share on other sites

SAMS has no real "platform" on the TI, any application written for it has to roll their own loaders and manage paging itself.

 

For example, my CRPG is a 144k program binary, 72K of which is program "modules" of 12K each. One module always resides in memory in the lower 24K block, the upper 24K is switched to whatever module is needed. The lower 8K block is used for data access and is switched frequently as needed.

 

Loading all this required writing a custom loader which opens to the binary and reads it in 8K chunks which are then copied to the CPU RAM page needed. It takes about a minute or so to load the game from TIPI, faster in Classic99.

 

Art Green's old AEMS assembler offered a linking loader design that could load object code into pages, but I'm not sure the design was ever fully worked out. Consider that if you wrote all your code into 4K module chunks loaded generically into a SAMS card (you don't have fixed pages for anything), that would mean maintaining a list somewhere of modules and their page assignments, which could get messy very quickly. Especially if one module is dependent upon another one being in memory at the time. I'd much rather write my games than focus on designing a framework to drive them on.

LOL honestly you are talking a map like I did in RXB 670K of SAMS was just pages from 16 to 184 that was the entire map of my game IN THE DARK

It just rolled forward or backwards from pages 16 up to page 184.

Most of the SAMS was just for XB to scroll the map and the assembly was in >B000 to >C000 using VMBR and VMBW

 

I plan to make a new version game using RXB 2019

  • Like 1

Share this post


Link to post
Share on other sites

Consider that if you wrote all your code into 4K module chunks loaded generically into a SAMS card (you don't have fixed pages for anything), that would mean maintaining a list somewhere of modules and their page assignments, which could get messy very quickly. Especially if one module is dependent upon another one being in memory at the time. I'd much rather write my games than focus on designing a framework to drive them on.

One of the main reasons why I did all my software development on the TI 99/4A, when I could choose my platform myself, in Pascal. It does provide exactly that, but only inside the 32 K RAM expansion, of course. Nothing bigger existed when it was designed.

Edited by apersson850
  • Like 1

Share this post


Link to post
Share on other sites

One of the main reasons why I did all my software development on the TI 99/4A, when I could choose my platform myself, in Pascal. It does provide exactly that, but only inside the 32 K RAM expansion, of course. Nothing bigger existed when it was designed.

My map of SAMS is in XB variables mostly in VDP so unaffected by switching pages.

 

So putting the map in VDP does not take much space just using numbers in VDP I mean look

>00 to >FF at most would take 256 bytes for a memory map in VDP.

Are you telling me 256 bytes it to much space?

Share this post


Link to post
Share on other sites

I meant that the p-system will only use the 32 K RAM expansion (well, and the available part of VDP RAM) for paging in and out different program segments. Since no more memory was available at the time when said system was adapted to run on the TI 99/4A.

Share this post


Link to post
Share on other sites

Has anyone thought about how a memory manager for SAMS would be designed? By memory manager I mean a some code that keeps track of allocated memory, makes sure you don't allocate the same memory twice, and makes no longer used memory available again.

 

I'm thinking this would be used by a single program only, or as an extension to XB, although it might also be useful if someone invents a multi-programming kernel for the TI.

 

I have no knowledge of how memory managers like EMM386 worked, but at the basic level I guess it would need two functions:

 

Allocate memory:

handle = allocate(number_of_bytes);

 

Deallocate memory:

deallocate(handle)

 

A handle would just be a number, perhaps a 16-bit word.

 

The memory manager would also need functions to read and write data, like read(handle, offset, number_of_bytes, destination) and likewise for writes.

 

I'm thinking the memory should be divided into sectors like a disk, because individual bytes would be too time consuming to keep track of, and using a 4K bank as the allocation unit would be too wasteful. Something like 128 - 512 bytes per sector would be appropriate.

 

I don't have any immediate plans to start on a project like this, but I would be interested in hearing what people think and need for their projects.

  • Like 1

Share this post


Link to post
Share on other sites

I know precisely where there is some code that can do that very thing. The XOP written for MDOS that uses the Memory Management XOP.

 

Would just need whatever "tweak" for the page banking, etc. for a different device.

 

The Geneve MDOS Memory XOP has a lot more features than probably is what is needed as it also has to deal with fast vs slow memory decision making and some other items. I'm sure it could fit inside an 8K bank and maybe even inside a 4K bank depending upon how many bells and whistles you wanted.

 

I guess the code could even be mapped in where it was not always in the active memory range, a simple BLWP call would page it in, then it would page itself out and restore itself when it exited.

 

Beery

Edited by BeeryMiller

Share this post


Link to post
Share on other sites

I guess the code could even be mapped in where it was not always in the active memory range, a simple BLWP call would page it in, then it would page itself out and restore itself when it exited.

 

There has to be some small stub of the memory management software always available, or it would not work. You can't page out yourself, as that's equivalent to software suicide.

 

In general, you can make such memory managers in many different ways. One way is to create a RAMdisk. The disadvantage is that you have to go via the file access protocol for the machine to access data. The advantage is that you can run the same thing on a machine witout this memory, if you instead use a normal disk. It will just be slower.

 

If you want the language you are using to be able to access a variable in additional memory, just as it does in built-in memory, then you have the problem that you either need the memory always active, or you have to modify how that language accesses memory when using variables. It's simpler in languages with built in support for dynamic memory allocation. I did it for Pascal, to use RAM in module space. That gives you 8 K more variable RAM, but looks exactly the same when using the variable inside the program. A separate call procedure was used to create the variable.

 

For Extended BASIC, I wrote a memory expander that used the 8 K RAM as a sequential allocation area, with random access. It worked as described above. You called a store procedure, which gave you a handle back. Via this handle you could read back your variable with a call procedure. When you had filled the memory, you couldn't release anything but all of it in a fell swoop. You could store and recall the whole memory area in a file, though. But this means you have to CALL LINK each time you want to do anything with this memory.

 

More complex algorithms can of course be deployed. If you want to be able to not only allocate memory, but also release it, a simple way is of course the mark/release concept found in early UCSD Pascal implementations. You allocate sequentially, access randomly and release sequentially. Thus if you have allocated space for 100 items, and then roll back to item #50, then you can't any longer use any item in the range #51 to #100. The advantage is that tracking used memory is a simple pointer. Anything above is free.

 

If you want a fully flexible system, where you can allocate and release an arbitrary memory area, in any order, then you have to start keeping track of what's free, even when it's not a contiguous area. This can, for example, be done with a linked list, containing pointers to the free space, size information and a pointer to the next link. Simple and fully variable, but takes time if you have to traverse many links to find an area big enough.

You can have a bit map of available areas. That's like how a disk system may work. It does require you make a decision about the size of the allocation units, or the bit map will be overwhelming.

 

No matter what strategy you come up with, you have to handle the fact that you'll get scattered free spaces, if it's possible to release random memory areas. Eventually, you'll run into the situation that there's enough memory to allocate the size you need, but not in a contiguous area. Then you have to either give an error (out of memory), or you have to do a garbage collection, to consolidate the free spaces to bigger ones. You can do a full garbage collection, where all free memory is brought into one single area, or a partial one, where you only move around stuff until you have combined smaller free areas to one, that's big enough to cater for the immediate demand.

 

There's a lot written about virtual and expanded memory handling, so I'll stop here, in this post.

Edited by apersson850
  • Like 1

Share this post


Link to post
Share on other sites

Note: this revision of the board won't work above 1MB. I have to add some components and change some traces on the input side of the 612 to get that to work (major surgery that may show up on a future revision of the board).

 

For all those expressing interest in boards, I'll be building and testing the next 15-20 boards over the next two weekends. I plan to ensure these remain available indefinitely. Note for anyone building the boards on their own: you need to use AMS Test 1.4 to verify the board works. Earlier versions won't detect it properly. . .

 

The schematic in the AMS archive on WHT is pretty much identical to this board, with the exception of the added circuit for the LED and a few changes (a couple of relocated/added traces) on the output side of the 612 to prepare the board for larger memory chips (that side of the board is ready for the larger chips, but I had to do some further delving into what they were doing with the inputs to figure out that they weren't using them the way things initially appeared to be, so I'm rethinking my solution there).

Hi Jim, do you still have a 1 MB SAMS to sell or do I have to wait for the 4 MB unit?

 

Bill

  • Like 1

Share this post


Link to post
Share on other sites

I have plenty of the 1MB boards assembled and on hand, Bill. The current batch of boards are $85 each, shipped to a US address. Let me know in a PM if you want one and we can work out the details.

  • Like 1

Share this post


Link to post
Share on other sites

Hey there, All! :-)

 

Where , in this thread , is the tools for testing the SAMS 1 Meg card? Also...are there "new" utilities for the SAMS-1M? All I found (on Whtech.com) is the version for the AEMS/AMS card (Version 2.0 - "Boot"; Version 1.1 - Assmb/Loader; Version 1.0 - Linker)...I tried the "AMSTEST" - Version ? and it said that I didn't even have a card installed!?!

 

jt

Share this post


Link to post
Share on other sites

Ok RXB next version 2019 or 2020 not decided yet.

You can switch 4K pages in any memory area of 4K boundaries i.e. >2000 or >3000 or >A000 or >B000 or >C000 or >D000 or >E000 or >F000

 

Now of course if a XB program is there you have to be careful but I have a way around that problem.

Using same line numbers and variables switching routines should work.

 

Even if that does not work swapping out Assembly in any area not used should make XB kick ass for SAMS use.

Also a loader for any area of memory in 32K in 4K chunks.

Loading would be slower but with faster devices should not take long to load up to 4meg.

 

After all you only have to do it once.

Edited by RXB

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...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...