Jump to content

Photo

1 Meg Super AMS Discussion Thread

TI-99/4A 1MEG SAMS AMS

296 replies to this topic

#276 RXB OFFLINE  

RXB

    River Patroller

  • 3,603 posts
  • Location:Vancouver, Washington, USA

Posted Thu Feb 21, 2019 4:18 PM

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.



#277 TheBF ONLINE  

TheBF

    Stargunner

  • 1,047 posts
  • Location:The Great White North

Posted Thu Feb 21, 2019 6:03 PM

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?



#278 RXB OFFLINE  

RXB

    River Patroller

  • 3,603 posts
  • Location:Vancouver, Washington, USA

Posted Thu Feb 21, 2019 6:14 PM

 

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.

 



#279 GDMike OFFLINE  

GDMike

    Chopper Commander

  • 138 posts

Posted Sun Feb 24, 2019 12:05 PM

Great board! Works flawlessly!! Very happy!

#280 twoodland OFFLINE  

twoodland

    Moonsweeper

  • 277 posts
  • Location:Delaware, OH

Posted Mon Feb 25, 2019 7:08 PM

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?



#281 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 4,410 posts
  • Location:Portland, Oregon USA

Posted Mon Feb 25, 2019 9:03 PM

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



#282 Iwantgames:) OFFLINE  

Iwantgames:)

    River Patroller

  • 2,490 posts

Posted Mon Feb 25, 2019 9:12 PM

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

#283 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 4,410 posts
  • Location:Portland, Oregon USA

Posted Mon Feb 25, 2019 9:31 PM

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

#284 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,529 posts

Posted Mon Feb 25, 2019 10:48 PM

Before this year is over you'll be able to play my CRPG too!

#285 RXB OFFLINE  

RXB

    River Patroller

  • 3,603 posts
  • Location:Vancouver, Washington, USA

Posted Mon Feb 25, 2019 11:12 PM

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.



#286 twoodland OFFLINE  

twoodland

    Moonsweeper

  • 277 posts
  • Location:Delaware, OH

Posted Tue Feb 26, 2019 6:10 PM

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.    



#287 RXB OFFLINE  

RXB

    River Patroller

  • 3,603 posts
  • Location:Vancouver, Washington, USA

Posted Wed Feb 27, 2019 2:20 AM

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.



#288 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,529 posts

Posted Wed Feb 27, 2019 10:37 AM

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.



#289 RXB OFFLINE  

RXB

    River Patroller

  • 3,603 posts
  • Location:Vancouver, Washington, USA

Posted Wed Feb 27, 2019 3:08 PM

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



#290 apersson850 OFFLINE  

apersson850

    Dragonstomper

  • 607 posts

Posted Thu Feb 28, 2019 6:52 AM

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, Thu Feb 28, 2019 6:52 AM.


#291 RXB OFFLINE  

RXB

    River Patroller

  • 3,603 posts
  • Location:Vancouver, Washington, USA

Posted Fri Mar 1, 2019 3:59 AM

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?



#292 apersson850 OFFLINE  

apersson850

    Dragonstomper

  • 607 posts

Posted Fri Mar 1, 2019 10:45 AM

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.



#293 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 3,149 posts
  • Location:Denmark

Posted Fri Mar 1, 2019 12:30 PM

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.



#294 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • 958 posts
  • Location:Campbellsburg, KY

Posted Fri Mar 1, 2019 12:39 PM

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, Fri Mar 1, 2019 12:48 PM.


#295 apersson850 OFFLINE  

apersson850

    Dragonstomper

  • 607 posts

Posted Sun Mar 3, 2019 3:50 AM

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, Sun Mar 3, 2019 3:55 AM.


#296 FDOS OFFLINE  

FDOS

    Moonsweeper

  • 287 posts

Posted Sun May 19, 2019 12:48 PM

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



#297 Ksarul OFFLINE  

Ksarul

    Quadrunner

  • 5,322 posts

Posted Sun May 19, 2019 2:14 PM

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.


  • RXB likes this





Also tagged with one or more of these keywords: TI-99/4A, 1MEG, SAMS, AMS

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users