1 Meg Super AMS Discussion Thread

[RXB]

47 minutes ago, JasonACT said:

Yes, along with Myarc XBII constantly swapping pages, which you can see in the debugger.  It runs a fair bit slower than the real thing.

Again the main slow down is the way you change pages.

If the main routine is in ROM and moved to Scratch Pad Fast RAM to switch pages it would be even faster then what I do presently from GPL

It is only a 18 byte program so fits perfectly in XB FAST RAM at >8300

***********************************************************
* CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE AMSCRU      *
***********************************************************
*                 *        AORG >8300
AMSCRU DATA >8302 * AMSCRU DATA >8302     * First address.
       DATA >C04C *        MOV  R12,R1    * Save R12 
       DATA >020C *        LI   R12,>1E00 * Load CRU bits
       DATA >1E00 *
       DATA >1D00 *        SBO  0         * Set bits ones
       DATA >C301 *        MOV  R1,R12    * Restore R12
       DATA >04E0 *        CLR  @>837C    * Clear for GPL
       DATA >837C *
       DATA >045B *        RT             * Return to GPL.
                  *        END

If you add a line to move the page numbers you want in the program to switch pages it would be faster then my GPL version.

[+Lee Stewart]

4 hours ago, hhos said:

The Super AMS does not have a ROM.

 

In fact, it does...well...RAM, actually. The registers are in the >4000+ memory space and the card must be turned on (bit 0) to set them.

 

...lee

[JasonACT]

7 hours ago, Asmusr said:

It's still quite fast. And quite an accomplishment that you managed to get this to work.

There are two versions of my SAMS paging routine in the assembly patch file (in the archive, which you probably saw).

 

The first is optimised for size, and not speed, because I was hunting around for a place to stash it, which I was never able to find.  The whole 8KB Cart RAM is used, even to the extent that two stacks are set up at >607E and >603E and go in reverse.  One of them eats into the "PRESS... 2 FOR" menu text and standard header, which is the reason I clear out the >AA byte when I start.  Then I had the idea, knowing the very end of Cart RAM had loader functions (VDP RAM access and DSRLNK) that I might discard, once I load the SAMS up with the file data...  So I needed 2 copies of the paging code, one to use while loading, and one to use when running - and that one is copied to the very end of the Cart RAM after loading.  This worked, at least running the demo doesn't touch that RAM, I'm not entirely sure if some XBII function does though, but it was visibly slower than what I had running on my real TI.  Maybe not quite as bad as half speed, but getting close.

 

The second version is optimised for speed, and not so much size, which improved things quite a bit.  So, yes, I agree - while not meeting expectations of the real-deal, it's still pretty good.  I'd be unhappy to use this SAMS version for bench-marking though, unless the real thing was also included in the results.

 

7 hours ago, RXB said:

Which is the reason in RXB I put the program in FAST RAM SCRATCH PAD to change or set up SAMS pages.

It's a good idea, but I can't know for sure what scratch memory Myarc XBII uses, so I have to have it in slow Cart RAM unfortunately.

[JasonACT]

When I got home from work this afternoon, I tried a few more things out.  This isn't a bad XB, really.  Everything seems quite snappy.  My basic disk catalog program spits out the directory faster than other basics do.  That's not a bad test for data processing and printing.  I also timed the Myarc demo on my real TI and the SAMS conversion and got these numbers:

 

REAL: 120 seconds

SAMS: 173 seconds

 

I do note, the demo has a random element (the 2 drawn bar graphs are always different).  Still, a 45% difference here though.

[hhos]

5 hours ago, Lee Stewart said:

 

In fact, it does...well...RAM, actually. The registers are in the >4000+ memory space and the card must be turned on (bit 0) to set them.

 

...lee

I'm just grousing about the fact that none of the expansion memory boards uses a proper DSR ROM, Lee.  The 32K board is understandable.  They just wanted to put 32K of RAM into 32K addresses.  No ROM needed.  There needs to be a system for allocating RAM to applications.  Otherwise, it's just a game console, not a computer.  A well written DSR ROM on the memory board would go a long way towards establishing a standard.

[Asmusr]

58 minutes ago, hhos said:

I'm just grousing about the fact that none of the expansion memory boards uses a proper DSR ROM, Lee.  The 32K board is understandable.  They just wanted to put 32K of RAM into 32K addresses.  No ROM needed.  There needs to be a system for allocating RAM to applications.  Otherwise, it's just a game console, not a computer.  A well written DSR ROM on the memory board would go a long way towards establishing a standard.

The Myarc memory card does have a ROM in DSR space, but AFAIK it doesn't have subprograms for paging or memory allocation, like you would expect if a memory card was to set a standard. More information here:

 

[JasonACT]

16 minutes ago, Asmusr said:

The Myarc memory card does have a ROM in DSR space, but AFAIK it doesn't have subprograms for paging or memory allocation, like you would expect if a memory card was to set a standard.

I didn't see any either, but it (the XBII version) does have a reset to page 0 function at >4010 that I needed to work around in the conversion to SAMS / no DSR.

[RXB]

10 hours ago, hhos said:

I'm just grousing about the fact that none of the expansion memory boards uses a proper DSR ROM, Lee.  The 32K board is understandable.  They just wanted to put 32K of RAM into 32K addresses.  No ROM needed.  There needs to be a system for allocating RAM to applications.  Otherwise, it's just a game console, not a computer.  A well written DSR ROM on the memory board would go a long way towards establishing a standard.

As I was pretty much the one of only 2 people that supported the AMS the week it came out and got mine free from Asgard to support it from

RXB as requested.

This was back well over 20 years ago.

So if you make a DSR for SAMS that swaps with same DSR space of >4000 to >5FFF and use a different CRU address say like >1B00 what kind of 

memory set up would work with C, Forth, Pascal, GPL, Assembly and anything else?

After all each of these have different ways of doing the same thing.

 

I would say this is a good idea but you better have a insanely good memory manager so it can be used in all of these without huge problems down the line.

Edited February 15 by RXB
missing text

[JasonACT]

Link to the awesome manual, that I just finished reading...

On 7/4/2020 at 5:16 AM, hloberg said:

u da man @blackbox ?????

here is the .pdf booklet of those files .

80k. MyarcXBII.pdf

will be creating a package for ti99resources.wordpress.com tomorrow.

So good.

[hhos]

14 hours ago, RXB said:

This was back well over 20 years ago.

That's a long period of stagnation.  I suppose the problems presented by the 4 wait states per memory access, and the price of SRAM are the chief causes for that?

 

14 hours ago, RXB said:

So if you make a DSR for SAMS that swaps with same DSR space of >4000 to >5FFF and use a different CRU address say like >1B00 what kind of 

memory set up would work with C, Forth, Pascal, GPL, Assembly and anything else?

A DSR cannot reside outside the space of >4000 - >5FFF without breaking the rules set out by TI 40+ years ago AFAIK.  There is no reason I can think of to change the CRU address.  C, Forth, Pascal, Assembly, and "anything else" exist in the ia32 world of computers, and in far greater numbers.  Each of them do things in different ways and co-exist on the same platforms, but they all have a way to request memory allocations from the system, be it Windows, Unix, Linux, BSD, etc.    A C compiler is even available for many of the game consoles, but C sources, even on those platforms, have to be able to co-exist with assembly language.  Those are single application machines.  They're game consoles.

 

Adding a DSR to the SAMS does not mean a huge change in how these applications would be written.  A port from one to the other system might be as simple as changing "MAPPER EQU >4000"  to "MAPPER EQU >5FC0", or the equivalent in a higher level language, in some cases.  Everyone could then continue to just grab up all the memory available and use it in just one program.  But for the few who might want to run something a little bit more sophisticated some sort of memory sharing needs to be implemented.  MS-DOS/PC-DOS did this in software on the IBM PC and its compatibles, as well as providing many other services.  Tandy's early systems had software systems that did it on the Model II, Model III, Model 4, and even the Color Computer.  The Color Computer had at least 3 UNIXy systems written for it (although I have to admit it is hard, or maybe even impossible, to distinguish between OS9 and NitrOS9).  The C64 had an operating system called GEOS I believe, though I don't know when that was created (I think I have it in my C64 collection). 

 

The SAMS DSR I'm proposing would pretty much be memory allocation only, though I've thought about attempting, in hardware, to prevent a process from stepping on memory that belongs to another process.  If I go that way, that hardware would have to be switched on by an operating system, or user process, and have no off switch accessible to a user process.  That may be a bit too far for me to venture, but we'll see.

 

15 hours ago, RXB said:

I would say this is a good idea but you better have a insanely good memory manager so it can be used in all of these without huge problems down the line.

I don't have an inkling what you mean by "insanely good memory manager", but the "huge problems" already exist.  I am only suggesting a path toward resolving them.  If an operating system were already in place, like Linux, or even MS-DOS, I probably wouldn't have seen a need for this.  AFAIK there isn't, though I saw that there was someone making an attempt at Linux on the TI99.  Was it 3 years ago? 

 

What does "down the line" mean?  RXB, you say you received a SAMS 20 years ago?  When does "down the line" start?  Many, if not all, of those other operating systems I've mentioned were in place back in the '80s.  You decide how far "down the line" you are.  It looks a lot like 40 years to me, though it certainly is at least 20. 

 

I'm not going to start cluttering up this thread with all this, so I think I'll start a thread on this subject soon, with a couple of my ideas.  To anybody who is interested in a better memory expansion board, watch for it.  If I go for it I am certain of only one thing.  I will need some help.

 

HH

[+Lee Stewart]

1 hour ago, hhos said:

A DSR cannot reside outside the space of >4000 - >5FFF without breaking the rules set out by TI 40+ years ago AFAIK.

 

This is true for DSRs in ROM space, but TI-99/4A DSRs are not limited to ROM. They can also be in GROM space. The console DSRLNK routine searches GROM space as well as CRU-based ROM space for DSRs.

 

...lee

[RXB]

4 hours ago, hhos said:

That's a long period of stagnation.  I suppose the problems presented by the 4 wait states per memory access, and the price of SRAM are the chief causes for that?

 

A DSR cannot reside outside the space of >4000 - >5FFF without breaking the rules set out by TI 40+ years ago AFAIK.  There is no reason I can think of to change the CRU address.  C, Forth, Pascal, Assembly, and "anything else" exist in the ia32 world of computers, and in far greater numbers.  Each of them do things in different ways and co-exist on the same platforms, but they all have a way to request memory allocations from the system, be it Windows, Unix, Linux, BSD, etc.    A C compiler is even available for many of the game consoles, but C sources, even on those platforms, have to be able to co-exist with assembly language.  Those are single application machines.  They're game consoles.

 

Adding a DSR to the SAMS does not mean a huge change in how these applications would be written.  A port from one to the other system might be as simple as changing "MAPPER EQU >4000"  to "MAPPER EQU >5FC0", or the equivalent in a higher level language, in some cases.  Everyone could then continue to just grab up all the memory available and use it in just one program.  But for the few who might want to run something a little bit more sophisticated some sort of memory sharing needs to be implemented.  MS-DOS/PC-DOS did this in software on the IBM PC and its compatibles, as well as providing many other services.  Tandy's early systems had software systems that did it on the Model II, Model III, Model 4, and even the Color Computer.  The Color Computer had at least 3 UNIXy systems written for it (although I have to admit it is hard, or maybe even impossible, to distinguish between OS9 and NitrOS9).  The C64 had an operating system called GEOS I believe, though I don't know when that was created (I think I have it in my C64 collection). 

 

The SAMS DSR I'm proposing would pretty much be memory allocation only, though I've thought about attempting, in hardware, to prevent a process from stepping on memory that belongs to another process.  If I go that way, that hardware would have to be switched on by an operating system, or user process, and have no off switch accessible to a user process.  That may be a bit too far for me to venture, but we'll see.

 

I don't have an inkling what you mean by "insanely good memory manager", but the "huge problems" already exist.  I am only suggesting a path toward resolving them.  If an operating system were already in place, like Linux, or even MS-DOS, I probably wouldn't have seen a need for this.  AFAIK there isn't, though I saw that there was someone making an attempt at Linux on the TI99.  Was it 3 years ago? 

 

What does "down the line" mean?  RXB, you say you received a SAMS 20 years ago?  When does "down the line" start?  Many, if not all, of those other operating systems I've mentioned were in place back in the '80s.  You decide how far "down the line" you are.  It looks a lot like 40 years to me, though it certainly is at least 20. 

 

I'm not going to start cluttering up this thread with all this, so I think I'll start a thread on this subject soon, with a couple of my ideas.  To anybody who is interested in a better memory expansion board, watch for it.  If I go for it I am certain of only one thing.  I will need some help. 

HH

Stagnant for 20 years?

LOL I have put out very many updates to RXB since first created in 1993 and 2001 was the one that took off world wide in TI99/4A community.

RXB 2000, 2001, 2002, 2005, 2008, 2010, 2011, 2012, 2014, 2015, 2018, 2019, 2020, 2021, 2022, 2023 and now 2024

How the fk is that STAGNANT?

As for what you want to do, you can do that and I am cool with it and will support it.

I was only saying THINK AHEAD as that is my main goal with what I do.

I think the reason for the slow progress with SAMS is a lack on imagination on how to use it.

 

Look when the AMS from Asgard came out there were two people that had written for it... Joe Delekto and ME!

A year later the number was 5 people. 

So go with your idea, I just want to see it successful.

 

[RickyDean]

@Tursi

I've downloaded the DSK1.zip that was provided for the XBII and am getting to the blank screen in classic99. What is the correct way to setup those files in Classic99 to run them, I've not worked with your ini file much and the Manual is not getting me there. Thanks for any help.

As a side question I have the SAMS enabled in the ini, but when I use a EA cart and run AMSTEST4, it locks up and squeals on me, how do I properly setup SAMS too. Thanks again.

Edited February 21 by RickyDean
added content

[RickyDean]

On 2/14/2024 at 3:42 PM, JasonACT said:

Have you configured the Classic99 ini file (using details in the ini.txt) so the cartridge is in RAM instead of ROM?

Do I just change the rom word to ram instead to get this to run in classic99?

[+Ksarul]

I've been doing a bit of random digging on 2M SRAM chips. Interestingly enough, there is actually "one" chip of that size that is 5V tolerant and outputs at TTL levels. It isn't through-hole though, as it is a 44-pin TSOP-II. It only uses 37 of those 44 pins, and one of those can be tied to 5V at all times, leaving me with the same 36 pins I had on the 36-pin Zeropower SRAMS (but in a much different pin order). I ordered a few of the chips to play with and I'm working on a pair of little plug-in adapter boards for the chips that move the pins around to where I need them to be for the sockets. This idea may or may not pan out, but thanks to @hhos for inspiring me to take another look at the problem. The chips themselves are not at all common, but I've found at least three vendors that apparently stock them (although the numbers available at all of them are suspiciously close to each other, so they may all be relying on just one vendor's stock). One does have two more shipments identified as inbound as well, so they are apparently still being produced. Note that it may be months before I can have these in-hand and tested, due to a serious lack of hobby time lately. With luck, I may have something to say about progress by the Chicago Faire. . .

[JasonACT]

On 2/21/2024 at 3:34 PM, RickyDean said:

Do I just change the rom word to ram instead to get this to run in classic99?

Not sure Ricky, I configured the cartridge as described in my ini.txt, but I guess there's a way to make Classic99 always make the ROM space RAM?  I just don't know it.  Sorry for the delayed reply, I somehow missed the quote notification you usually get on this forum.

[+jedimatt42]

@JasonACT

 

This is super cool... I've thought about it in the past, but have been too lazy to dig in.

Congrats!

[+jedimatt42]

If you have a supercart, you can use the attached EA5 to load it on hardware. 

 

SuperCartSAMS-MXBII-loader.zip

 

A super cart has 8 K RAM in the cartridge ROM slot, and an Editor Assembler GROM so you can load the EA5 and get stuff into that RAM. 

 

(I used classic99's debugger make - save as EA5 menu to capture this...)

 

Oh: Also, when taking the xbii1-xbii5 files from Jason's zip, they need to be renamed to all-caps on real hardware ( cause real hardware has a case-sensitive filesystem )

[RXB]

2 hours ago, jedimatt42 said:

If you have a supercart, you can use the attached EA5 to load it on hardware. 

 

SuperCartSAMS-MXBII-loader.zip 5.88 kB · 5 downloads

 

A super cart has 8 K RAM in the cartridge ROM slot, and an Editor Assembler GROM so you can load the EA5 and get stuff into that RAM. 

 

(I used classic99's debugger make - save as EA5 menu to capture this...)

 

Oh: Also, when taking the xbii1-xbii5 files from Jason's zip, they need to be renamed to all-caps on real hardware ( cause real hardware has a case-sensitive filesystem )

Ok in Classic99 put EA supercart in slot to load it and it crashes as there are only 2 files SUPMXBII and SUPMXBU 

Renaming them to XBII0 and XBII1 crashes looking for XBII2 so pretty sure I am missing XBII3, XBii4 andXBII5 in this ZIP file you uploaded.

[+jedimatt42]

15 minutes ago, RXB said:

Ok in Classic99 put EA supercart in slot to load it and it crashes as there are only 2 files SUPMXBII and SUPMXBU 

Renaming them to XBII0 and XBII1 crashes looking for XBII2 so pretty sure I am missing XBII3, XBii4 andXBII5 in this ZIP file you uploaded.

If you are classic99, you don't need my zip at all... just run Jason's cart as described in his zip from the 'SAMS is slow' post.

[RXB]

1 hour ago, jedimatt42 said:

If you are classic99, you don't need my zip at all... just run Jason's cart as described in his zip from the 'SAMS is slow' post.

Thanks finally found the ZIP file!

[RXB]

Ok got Myarc XB2 to work and ran this program:

 

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL HCHAR(1,1,65,768)
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

RXB 2024B ran for 8 minutes 28 seconds

Myarc XB2 ran for 20 minutes and I was puzzled about this and so stopped it and typed:

PRINT C

0

Yea it said it ran for 20 minutes and the FOR NEXT loop for C stayed at 0 (ZERO) NADA NOTHING

 

I thought you could run Myarc XB2 to run TI Basic programs? Apparently not!

Edited February 25 by RXB

[JasonACT]

Hmmm, not sure Rich...  I changed the loop to be smaller and I got 10 seconds for 100 loops.  So 0.1 seconds then, making 10,000 loops 1,000 seconds or 16.6 minutes.

 

 

About right, in fact...

 

Maybe your run hit one of the bugs previously discussed?

[JasonACT]

Quote

   XB       XB3     XBGEM     RXB   command
-------------------------------------------------------------------------
4:37:35  4:39:17     9:31     7:33  CALL HCHAR(1,1,65,768)

2 hours ago, RXB said:

RXB 2024B ran for 8 minutes 28 seconds

What happened to 7 minutes and 33 seconds?  Nevermind...

Here's Myarc XBII on real hardware (sorry for the OZ date format):

Back in the day, 14 minutes would have been a game changer, no?

[RXB]

3 hours ago, JasonACT said:

Hmmm, not sure Rich...  I changed the loop to be smaller and I got 10 seconds for 100 loops.  So 0.1 seconds then, making 10,000 loops 1,000 seconds or 16.6 minutes.

 

 

About right, in fact...

 

Maybe your run hit one of the bugs previously discussed?

So Myarc XB2 can not do a FOR NEXT LOOP of 10,000?

Oh wait you did it? What is not right with my version I got from your post?

Edited February 25 by RXB
comment added