SAMS on the 16bit bus?

[+retroclouds]

Has it ever be attempted to build a SAMS board that sits on the 16 bit bus?

Yes, probably would require some console surgery to make it happen.

[apersson850]

It would, since the 16-bit bus isn't available in any existing connector. Like several other users, I have 16 bit RAM in the console, as an alternative to the memory expansion in the expansion box. It required some chips inside the console to accomplish that.

[GDMike]

Could a port be added, like how we add a VGA port for F18A? Then plug an add-on board?

I make everything sound simple..

[Reciprocating Bill]

I'd be happy with an 8-bit SAMS that would function in conjunction with 32K of 16-bit RAM in the console.

[Bill R Sullivan]

Actually, it should be switchable for 8 bit and 16 bit, so that software can be written and tested on the same TI-99/4A!

[apersson850]

4 hours ago, Reciprocating Bill said:

I'd be happy with an 8-bit SAMS that would function in conjunction with 32K of 16-bit RAM in the console.

The 64 K 16-bit RAM I have in my console has not interferred with anything else yet. But I don't have any SAMS, so I have not tested that. I can't see that it wouldn't work, though.

[Asmusr]

If you have SAMS you can't have another 32K. Talking about 16-bit access to RAM that's outside the addressable 64K makes no sense, because you can only access pages that are swapped into the addressable region. So it boils down to whether the SAMS is on the 16-bit bus or not, which is probably possible but still requires changes/soldering inside the console.

[apersson850]

You're right, the SAMS will replace the 32 K RAM expansion. My design is such that if I turn off my internal 32 K RAM expansion (16 bit wide), then whatever is available at the same address range on the 8-bit bus will show up.

Normally I use the 32 K RAM inside the console, and then the 32 K standard memory expansion in the box shows up if I turn off the internal one. So in a way I can already bank memory like that. But it "only" doubles it, of course.

 

I've never used any, but I've understood that it provides 32 K RAM and then enables different RAM banks to show up as the 32 K RAM. Do you bank in extra memory wherever you want, or just in one window? Like always in low memory expansion? How large are the windows? Do you switch 8 K at a time, or some other amount?

 

I'm asking since if it's a certain window you use, say low memory expansion, then it would be possible to turn that off in my internal RAM, but keep 16 bit wide RAM in the 24 K part. Or some other combination like that.

Edited February 13, 2022 by apersson850

[+Lee Stewart]

1 hour ago, apersson850 said:

I've never used any, but I've understood that it provides 32 K RAM and then enables different RAM banks to show up as the 32 K RAM. Do you bank in extra memory wherever you want, or just in one window? Like always in low memory expansion? How large are the windows? Do you switch 8 K at a time, or some other amount?

 

I'm asking since if it's a certain window you use, say low memory expansion, then it would be possible to turn that off in my internal RAM, but keep 16 bit wide RAM in the 24 K part. Or some other combination like that.

 

The windows are 4 KiB each. When SAMS is present, all eight windows are used: >2000, >3000, >A000, >B000, >C000, >D000, >E000, >F000. The question is which windows the programmer wants to use for swapping other SAMS banks in and out. One or two low memory windows are, perhaps, more often used for this purpose, but in fbForth, I do not have that luxury. I must use windows in upper memory: >D000, >E000, >F000, while (usually) moving the stack and Terminal Input Buffer.

 

...lee

[apersson850]

I see. I have eight CRU bits to control banking of 64 K RAM, so that's 8 K at a time. Could be SAMS compatible, if I want it to.

[Bill R Sullivan]

22 hours ago, Bill R Sullivan said:

Actually, it should be switchable for 8 bit and 16 bit, so that software can be written and tested on the same TI-99/4A!

My SNUG TI-99/4P has 1MB of 16 bit SAMS on the SGCPU card, that's why I would prefer 16 bit SAMS in my TI-99/4A.  i use >4000 for paging.

Edited February 14, 2022 by Bill R Sullivan
added important info.

[+FarmerPotato]

I imagine an internal memory card that requires de-soldering and replacing the two console ROMS and the ‘138 that first decodes A0-A2.

 

 That gets you most of the necessary signals for the 16-bit bus. 
 

Then, the board would sit over the ROM sockets for 16-bit data. (Original ROMs mounted on board.)

 

There’s a small CPLD or PAL for logic. It takes over the function of the ‘138 decoder  (cable to socket maybe.)

 

The card decides if it will service addresses at pretty much anywhere; in which case it doesn’t forward that 8K enable signal into the ‘138 socket it replaced. 
 

other signals left to solder are WE, CRUCLK, CRUIN. 
 

The card can provide SAMS compatibility, while forwarding to the PEB as long as SAMS is turned off. 
 

it can have a power-up DSR that copies console ROM into RAM pages 0-1, to prepare for when you turn on paging.
 

It could map another Ram resident DSR into 4000 at a software-configurable CRU base. 
 

maybe you would even want it to override the cartridge ROM. 
 

 

 

Apologies if this has been explored before—I haven’t looked for gotchas—it’s just what seems most direct to me.  Maybe I am mistaken about that ‘138…

 

[Bill R Sullivan]

32 minutes ago, FarmerPotato said:

I imagine an internal memory card that requires de-soldering and replacing the two console ROMS and the ‘138 that first decodes A0-A2.

 

 That gets you most of the necessary signals for the 16-bit bus. 
 

Then, the board would sit over the ROM sockets for 16-bit data. (Original ROMs mounted on board.)

 

There’s a small CPLD or PAL for logic. It takes over the function of the ‘138 decoder  (cable to socket maybe.)

 

The card decides if it will service addresses at pretty much anywhere; in which case it doesn’t forward that 8K enable signal into the ‘138 socket it replaced. 
 

other signals left to solder are WE, CRUCLK, CRUIN. 
 

The card can provide SAMS compatibility, while forwarding to the PEB as long as SAMS is turned off. 
 

it can have a power-up DSR that copies console ROM into RAM pages 0-1, to prepare for when you turn on paging.
 

It could map another Ram resident DSR into 4000 at a software-configurable CRU base. 
 

maybe you would even want it to override the cartridge ROM. 
 

 

 

Apologies if this has been explored before—I haven’t looked for gotchas—it’s just what seems most direct to me.  Maybe I am mistaken about that ‘138…

 

I think I got the basics, but in my case, I have an 80K GramKracker that I use frequently, and as you may already know, I don't do hardware modifications any more, as I can't even "touch type" doing software development (TIB+ & X4th99), so I would have to pay someone to do all the necessary TI console modification.  Any, and all better suggestions welcome.

 

RetroBill (FDOS), the old guy

[+FarmerPotato]

1 hour ago, Bill R Sullivan said:

I think I got the basics, but in my case, I have an 80K GramKracker that I use frequently, and as you may already know, I don't do hardware modifications any more, as I can't even "touch type" doing software development (TIB+ & X4th99), so I would have to pay someone to do all the necessary TI console modification.  Any, and all better suggestions welcome.

 

RetroBill (FDOS), the old guy

Yeah, I figured I was tossing in a “commercial” kit level idea. I just like solving problems in stuff I’ve been close to for 4 decades!

but I consider that a solution ought not to require soldering wires! Clean, reversible, but requires installing sockets. 

 

 

[Asmusr]

On 2/13/2022 at 9:36 PM, apersson850 said:

You're right, the SAMS will replace the 32 K RAM expansion. My design is such that if I turn off my internal 32 K RAM expansion (16 bit wide), then whatever is available at the same address range on the 8-bit bus will show up.

With your design it makes sense to talk about 32K on the 16bit bus and SAMS or the 8bit bus because you can switch between the RAM extensions using CRU.

[apersson850]

Yes, of course. Then I can do the same with the remaining 32 K. By 8 K pages, I can enable the internal RAM over the entire range. Not much works if I enable RAM over 0x8000 - 0x9FFF, but it can be used as a buffer in an assembly program, or whatever. It's a bit like the old Commodore 64, which could have 64 K of contiguous RAM, but it hid all memory-mapped IO.

I designed the hardware so that when the computer is reset, it disables pages 0, 2, 3 and 4, and enables 1, 5, 6 and 7. Thus I have 32 K 16-bit RAM on startup, as well as all the normal system functions.

 

I got the original idea from somebody who installed 64 K RAM, to get 32 K 16-bit memory, but never used the other half. The install of 64 K was just a shortcut to be able to access 16 kilowords of memory. I thought it was a pity not to be able to use the other memory, so I figured out a design where I can interrupt the normal memory decoding and enable the rest of the RAM instead.