1 Meg Super AMS Discussion Thread

[+FarmerPotato]

2 hours ago, FDOS said:

Ideal for my purpose!  I might even be able to use it with a NanoPEB by disabling it's 32K!

 

RETRO Bill

I hope it meets your needs! But I am designing it to do one thing well. It will not connect with a NanoPEB.. well... hmm...

[FDOS]

On 11/30/2019 at 11:15 AM, FarmerPotato said:

I hope it meets your needs! But I am designing it to do one thing well. It will not connect with a NanoPEB.. well... hmm...

Not extending the TI-99/4A side port, is never a good idea, as it limits the original purpose, and I do realize that the NanoPEB did just that, as do other mini-PEB systems, but I believe that TIPI should include the 32K on-board, as long as 32K is it's standard memory size, and not a separate sidecar.  However, that's just my opinion; everyone is entitled to their own opinion.

 

RETRO Bill

[wierd_w]

I like the modularity there.  It gives options.  The RAM in the 99 is not terribly fast anyway due to the multiplexer, and the added waitstates. The extra waiting that happens from having RAM that far away from the CPU is a drop in the bucket.

 

Specifically, SAMS banks out the 32k ram area.  If you build-in the 32k on the TIPI car, then a sidecar SAMS is not useful, and in fact, becomes incompatible.  Being able to decide "Hmm.. 1MB+ with bank switching, or just straight 32k? Hmmm.." is useful.  Especially if you want to incrementally upgrade your kit.

 

Keeping them separate has tractable benefits.

[+FarmerPotato]

5 hours ago, FDOS said:

Not extending the TI-99/4A side port, is never a good idea, as it limits the original purpose, and I do realize that the NanoPEB did just that, as do other mini-PEB systems, but I believe that TIPI should include the 32K on-board, as long as 32K is it's standard memory size, and not a separate sidecar.  However, that's just my opinion; everyone is entitled to their own opinion.

 

RETRO Bill

Yeah, integrating 32K to the TiPi would appeal to some folks, but I'm glad it came first as a separate choice.

 

My SamsCar PCB does have the same 44-pin connector as JediMatt42's 32K, so that his TiPi will fit right on it.

For a challenge, how to put a NanoPEB on it instead? Well, some ideas:

 

NanoPEB options

1. NanoPEB have a 44 pin vertical card edge connector. You could make a small PCB with a right-angle 2x22 header and 2x22 card edge.

Or you could de-solder the NanoPEB vertical card edge connector and attach a tall 2x22 board-to-board header. (likely a mix of 1x16 and 1x6.)

 

In the 2x22, there is a 2x20 that is essential, plus one +5V pin, the one specced for 50mA that the Speech Synthesizer eats. (My SamsCar passes through its regulated 5V on that pin.)

 

Old CF7s used a 44 pin IDC cable to 40 pin female. There was a 2x20 box header (IDE, keyed) on the board. It would be a cinch to connect that one. Mine is fried, however. Jaime already repaired it once, but I gave up on it the second time. Charles Good donated his, but it has the 44-pin vertical card edge connector already. 

 

Need for mass storage

 

Since the main goal of my SamsCar is to make it possible to play Adamantyr's game, it is essential to have mass storage; TiPi is the first option, but NanoPEB would get a lot of users. Still, that assumes you can disable the NanoPEB from trying to drive accesses to 32K.

 

1. I think the RAM is soldered on? because removing that might do the trick.

 

2. A more elegant option would be if SamsCar did not pass through /MEMEN for addresses in the 32K (but not 8K of DSR). Maybe I can design that in.. Yeah!

 

There are two unused I/Os in the PLD. 1 I/O block = 1 output + 1 flip flop. Can be either 1 bit register, or just logic output.

 

So I can use an I/O to output a gated /MEMEN and route it onto the pass-thru connector. This /MEMEN will be passed through as false (logic 1) when SamsCar 32K space is being accessed. (Risk: nanoPEB could interpret this as a CRU cycle and drive CRUIN... nah, not a risk.) So NanoPEB would never see the 32K memory access. There could be a jumper to choose one or the other. or maybe a jumper is unnecessary... I don't know any reason why TiPi would be affected if 32K access were masked off.

 

DSR mapping

 

I did not include an option yet  to map the DSR. But the last unused I/O can be the CRU bit to enable DSR mapping. This presents no compatibility problem. AND now I've used up all the PLD. I was reluctant to add any more stuff until after the essentials were in there, but, this is a good use of the last two I/Os.

 

Status Update

 

SamsCar PCB is almost ready to go to OSH Park. I "finished" last night. Still got to simulate the PLD though, then put it on the test rig and verify it. (Exciting, going to use LabVIEW to automate the validation at real speeds.)

 

To reduce cost and complexity, I removed the jumpers (or 5 pullup resistors) for choosing a CRU base address. It is fixed at >1E00, which is standard.

 

Address pins are in correct order, in case you want to drop an EPROM into one of the RAM slots, that will work.

 

Building SamsCar as a kit is still all through-hole components (except for a micro USB power input, which is non-essential unless you want battery power, and anyhow micro USB has widely spaced SMD legs.)

 

One thing, however, you'll need to buy the PLD chip pre-programmed from me (or the whole kit) or use a TL866 like I do.

 

All files will be open sourced.

 

[+FarmerPotato]

51 minutes ago, wierd_w said:

I like the modularity there.  It gives options.  The RAM in the 99 is not terribly fast anyway due to the multiplexer, and the added waitstates. The extra waiting that happens from having RAM that far away from the CPU is a drop in the bucket.

 

Specifically, SAMS banks out the 32k ram area.  If you build-in the 32k on the TIPI car, then a sidecar SAMS is not useful, and in fact, becomes incompatible.  Being able to decide "Hmm.. 1MB+ with bank switching, or just straight 32k? Hmmm.." is useful.  Especially if you want to incrementally upgrade your kit.

 

Keeping them separate has tractable benefits.

 

Modularity and pass-through connector was imagined by JediMatt42 before he told us his plan to use it for TiPi.

 

The extra wait states on RAM are not changing. The wait states are built into the side port's 16-to-8 bit bus logic. 

 

See my last post for how easy it would be to neutralize a 32K RAM that comes after the SAMS.

 

 

[FDOS]

2 hours ago, FarmerPotato said:

 

Modularity and pass-through connector was imagined by JediMatt42 before he told us his plan to use it for TiPi.

 

The extra wait states on RAM are not changing. The wait states are built into the side port's 16-to-8 bit bus logic. 

 

See my last post for how easy it would be to neutralize a 32K RAM that comes after the SAMS.

 

 

This is a lot to think about!  In my case, I have to keep things simple, unless someone else does it, and sells it as a finished product.  My projects never considered making the TI-99/4A or /P faster than greased lightning (old home computers are for amateurs ?).  I was all about making it easy to use expanded memory (either program or video or both) for old salts, like myself, or newbies.  I know the TI Avaunt Guard here on AtariAge have a different goal, and I would say ALL are welcome, as it obviously keeps the TI group active and very interesting.

 

RETRO Bill

[mr_gw454]

On 5/29/2019 at 5:55 PM, Ksarul said:

Here is AMSTEST V4, which is what you need for the SW99ers version of the card and for the current 1M version.

AMSTEST4.DSK 254.14 kB · 15 downloads

Hi Ksarul,

 

Is there any version of this program that will run from a cartridge (FinalGROM99, perhaps)?

 

I only have access to real floppies in my PEB at the moment and I'm using a standard TI FDC, so your test DSK image is too large for me to use.

 

Thanks!

[+Ksarul]

Unfortunately, there is not, but the program does not fill the disk either. I will try and make a 90K disk image of the program this weekend.

[+arcadeshopper]

Hi Ksarul,
 
Is there any version of this program that will run from a cartridge (FinalGROM99, perhaps)?
 
I only have access to real floppies in my PEB at the moment and I'm using a standard TI FDC, so your test DSK image is too large for me to use.
 
Thanks!

I made a cart image at one point did you check the fgfr99 topic?

Sent from my LM-G820 using Tapatalk

[+arcadeshopper]

Also the latest jedimatt ram test does sams it's in that topic

Sent from my LM-G820 using Tapatalk

[atrax27407]

Here is a SSSD .dsk file.

AMSTEST4.dsk

[+TheBF]

20 hours ago, Ksarul said:

Unfortunately, there is not, but the program does not fill the disk either. I will try and make a 90K disk image of the program this weekend.

Why is it so big?

[+Ksarul]

That was the size of the disk the image was made from, nothing more, nothing less. As seen from the above post, it does fit on a 90K disk though.

[+arcadeshopper]

I made a cart image at one point did you check the fgfr99 topic? 

Sent from my LM-G820 using Tapatalk

 

 

 

 

https://atariage.com/forums/index.php?/topic/253095-[emoji985]-FlashROM-99-&-FinalGROM-99---Repository----(11/26/2019)#entry3592592

 

Sent from my LM-G820 using Tapatalk

 

 

 

 

 

[Omega-TI]

30 minutes ago, arcadeshopper said:

https://atariage.com/forums/index.php?/topic/253095--FlashROM-99-&-FinalGROM-99---Repository----(11/26/2019)#entry3592592

 

 

 

<< TRY THIS >>

[MikeV]

 

I realize this is an old post from circa Feb. 2019. The original thread had a link to this place to continue the discussion (of course, cannot locate that thread now). Was the idea above ever continued and/ or implemented? Is this possible/ doable with the SAMS card? Any examples of implementation? Thank you.

[Asmusr]

Link to the original post. I haven't worked on it. 

[Elia Spallanzani fdt]

With 1 mega and a little video player you can make Ti-fender of the crown.

[MikeV]

13 hours ago, Asmusr said:

Link to the original post. I haven't worked on it. 

OK and thanks. Hopefully someday - a great idea for SAMS card. Do you know offhand if your sample code is similar in any way to what was used by XB-II/ Myarc Ram disk for string handling (in a separate segment of memory)?

[Asmusr]

50 minutes ago, MikeV said:

OK and thanks. Hopefully someday - a great idea for SAMS card. Do you know offhand if your sample code is similar in any way to what was used by XB-II/ Myarc Ram disk for string handling (in a separate segment of memory)?

It's not really sample code - only a proposal for an interface. I don't know what XB-II/ Myarc Ram disk was using for string handling, but I would be interested to know if it's something similar. I imagine my suggestion would be implemented as two components: a memory manager that takes care of page allocation that could also be used by other applications, and a number of assembly functions that take care of the interface between the memory manager and XB.

Edited April 11, 2020 by Asmusr

[MikeV]

On 4/11/2020 at 2:57 PM, Asmusr said:

It's not really sample code - only a proposal for an interface. I don't know what XB-II/ Myarc Ram disk was using for string handling, but I would be interested to know if it's something similar. I imagine my suggestion would be implemented as two components: a memory manager that takes care of page allocation that could also be used by other applications, and a number of assembly functions that take care of the interface between the memory manager and XB.

Unfortunately,  I have no idea how Myarc XB-II implemented its routines for string manipulation. I do know that it dedicated one 32K bank of memory for numeric variable storage and another for string variables, which left a good deal more memory available for XB program space. Back in the later 80's Curtis gave several demos to the UG - some provided by Myarc, some he wrote - all very impressive (and quite large programs). Harrison, who also saw the need for additional variable space wrote a program called "Stor Mor" to allow allocation of additional string storage space in the 32K proper. Again, I have no idea if his approach resembled either Myarc's or you own. Thank you though.

[RXB]

On 12/2/2019 at 8:54 AM, wierd_w said:

I like the modularity there.  It gives options.  The RAM in the 99 is not terribly fast anyway due to the multiplexer, and the added waitstates. The extra waiting that happens from having RAM that far away from the CPU is a drop in the bucket.

 

Specifically, SAMS banks out the 32k ram area.  If you build-in the 32k on the TIPI car, then a sidecar SAMS is not useful, and in fact, becomes incompatible.  Being able to decide "Hmm.. 1MB+ with bank switching, or just straight 32k? Hmmm.." is useful.  Especially if you want to incrementally upgrade your kit.

 

Keeping them separate has tractable benefits.

Hmm the SAMS banks out 4K each bank up to 32K, now you could bank entire 32K but how would you load it or change pages. 

WELL RXB does that: 

 

[RXB]

1 hour ago, MikeV said:

Unfortunately,  I have no idea how Myarc XB-II implemented its routines for string manipulation. I do know that it dedicated one 32K bank of memory for numeric variable storage and another for string variables, which left a good deal more memory available for XB program space. Back in the later 80's Curtis gave several demos to the UG - some provided by Myarc, some he wrote - all very impressive (and quite large programs). Harrison, who also saw the need for additional variable space wrote a program called "Stor Mor" to allow allocation of additional string storage space in the 32K proper. Again, I have no idea if his approach resembled either Myarc's or you own. Thank you though.

Bruce Harrison called me a few times to discuss the AMS (SAMS) and before he wrote any programs for it, due to RXB was the first known use of AMS/SAMS.

The biggest problem with SAMS is where do you store which pages you want to use next, not the pages in use.

RXB solved this by using VDP to store the pages in XB Variables, but in Assembly the program is in 32K SAMS memory......problem.

Bruce was first to use CART RAM to deal with this page swapping and we had a few discussions on it.

Edited April 16, 2020 by RXB

[MikeV]

On 4/16/2020 at 11:21 AM, RXB said:

Bruce Harrison called me a few times to discuss the AMS (SAMS) and before he wrote any programs for it, due to RXB was the first known use of AMS/SAMS.

The biggest problem with SAMS is where do you store which pages you want to use next, not the pages in use.

RXB solved this by using VDP to store the pages in XB Variables, but in Assembly the program is in 32K SAMS memory......problem.

Bruce was first to use CART RAM to deal with this page swapping and we had a few discussions on it.

Thank you for the explanation. I did not realize there was a difference in implementations.

 

I recently (last week) added optional SAMS support (via RXB of course!) to a simple program I have been working on. A very modest 5 - 4K pages, but they integrate and perform extremely well. Once I stopped whining about a SAMS ramdisk, though I made progress with that, I simply followed your demo example and it worked beyond initial expectations. (Thank you.) The number of pages could easily be increased by 10 or 15, but since an array is utilized, other memory issues would ensue. Hence the interest in using SAMS for arrays. Apparently, not yet anyways.

 

As RXB works very well with SAMS (and I also have an appreciation for simple), so it is rather surprising that it has not seen more utilization.

[RXB]

1 hour ago, MikeV said:

Thank you for the explanation. I did not realize there was a difference in implementations.

 

I recently (last week) added optional SAMS support (via RXB of course!) to a simple program I have been working on. A very modest 5 - 4K pages, but they integrate and perform extremely well. Once I stopped whining about a SAMS ramdisk, though I made progress with that, I simply followed your demo example and it worked beyond initial expectations. (Thank you.) The number of pages could easily be increased by 10 or 15, but since an array is utilized, other memory issues would ensue. Hence the interest in using SAMS for arrays. Apparently, not yet anyways.

 

As RXB works very well with SAMS (and I also have an appreciation for simple), so it is rather surprising that it has not seen more utilization.

Almost done with RXB 2020 and some big changes with SAMS is on way, you get 4K pages now instead of 8K pages, this works much better with SAMS as it is designed for 4K pages.

Also as RXB 2001 to RXB 2015 used 8K pages only in lower 8K I needed to do this many years ago, as loading any place in 32K along with swapping any 4K page in SAMS.

RXB 2020 to load a SAMS page from disk.

CALL SAMS(3,21) ! put SAMS page 21 at >3000 RAM

CALL PLOAD(3,"DSK2.TEST") ! Load a file named TEST from disk 2 into >3000 RAM

 

As you can see RAM locations are designated with a HEX letter. i.e. 2= >2000, 3= >3000, A= >A000, B= >B000, C= >C000, D= >D000, E= >E000, F= >F000

Like previous RXB versions these are Program Image files, but instead of 32 sectors (8K size) now are 16 sectors (4K size). (But can be loaded anywhere!)

To deal with this is a new routine CALL PRAM that lets you change END RAM LOCATION IN 24K RAM for XB, thus RAM from >A000 to >E000 is now available.

(This could be for DATA or Assembly use.)

I should explain XB starts using RAM in 24K from >FFFF down to >A000 so >A000 to >E000 is normally empty for most XB programs less then 4K in size.