Technical Inquiry - 64K Memory/16 Bit Bus (Why it never happened)

[Omega-TI]

I'm curious, why a 64K memory expansion on the 16 bit buss never came to fruition. Logically it SEEMS like a no-brainer, but since it obviously never happened, I'm wondering why.

 

Some of the things that I think 'could have been reasons', may not have been, and I may be totally off-base in my thinking. So, I figure THIS is the place to ask, since many of you are experts on the TI and have been involved with it since the beginning.

 

Please, don't laugh too hard, as I'm not a hardware designer or programmer, these are the only possibilities I could think of...

 

1) 64K on the 16 Bit buss would require no wait states correct? If this is the case, it could render some programs in-operable or maybe they would run too fast, right? So no one wanted to make their TI's incompatible with existing software?

 

2) I would have figured the extra memory would have been addressable, but I might be off-base here too.

 

3) It conflicts with something else in the consoles architecture.

 

4) The complexity of installing it would be to great for the average user?

 

5) The 4A had already been abandoned by TI and was being abandoned by users as well, so there was no point in making something that only a small percentage of a dwindling user base would want, especially with few prospects of software ever being developed for it.

 

Did I get even close to the mark, or did I miss it entirely? If I missed it, what is the reason it never came to be?

 

[Gary from OPA]

I pick your points 4) and 5) for the most logical reasons why third-party people didn't push this after the crash in '83.

 

Other reasons of course breaking software, and the fact most people that still were using their 4A's for things after '83 already had PE-BOX with 32K in it.

 

Even the replacements for 32K like Myarc 512k didn't take off, and even the AMS (which I designed the first PCBoard layout for Asgard, before it moved to SW99ers) and that didn't take off either.

 

Another problem was at time was cost, Memory was still very costly, that was why Horizon ramdisks were at first using only 8k static chips, and most of them out there only have 192k or less of memory.

 

It was not until the late '90s that memory prices started to fall to make a project like this worthwhile more, by then the amount of 4A users was alot less.

 

Its only been recently I think in the last 5 years that interest in the 4A has picked back up and people now building things that were not done before, like things NanoPEB which does the best without any soldering needed inside the console.

 

Something like ZENOBOARD would I think work again now due to the renewed interest, so maybe now a 64Kx16bit designed that does not need much soldering would be successful project, there was design in PCBoard form done in past, and I have a console with one in it, and I like it very much, except its only gives me access to 32k of space, but a wire hooked up to unused CRU bit on console's 9901 could give a easy software way to swap banks.

[matthew180]

Probably the biggest reason is that it would require motherboard level modifications to the 99/4A, and most 99/4A users probably can't make those modifications. There is no plug-n-play solution for this, and certainly nothing that could be plugged in externally to an existing port.

 

Also, the entire addressing range of the 9900 is only 64K and the memory map is not clear, i.e. 100% of the 64K is not, and cannot be used for RAM. To get a full 64K of RAM you would need a banking scheme or memory mapping controller, which forces software level support and cannot be used transparently by software.

[JamesD]

FYI, 32K x 16 bits = 64K x 8 bits
The TMS9900 cannot address 64K x 16 bits without bank switching as it only has 15 address lines.

http://www.mainbyte.com/ti99/32K16/32k16.html

[Omega-TI]

Hmm, software level support & bank switching, with today's low prices. In today's world that would not exactly shut the door on a project such as this. That would be an interesting way to finally support a GUI or DOS environment on the TI though... just stick it all up in 'expanded high memory', and without a program to 'turn it on', a modified unit would appear and act just like a regular TI, sort of like how Matthew's F18A behaves.

 

The complexity of the install looks like a killer though... pity.

[matthew180]

You can't add 16-bit memory to the 99/4A without modifying the motherboard. This is the main problem. Only the two system ROMs and two SRAMs (that make up the scratchpad RAM) on the motherboard are on the 16-bit bus. After that you hit the 16-to-1 multiplexor and all other devices and memory are on the wait-state 8-bit bus.

 

There are people who have put the 32K inside the console on the 16-bit bus, and there is even a kit for it I believe. However, you are now into the realm of custom modifications and that is a slippery slope. This becomes a philosophical discussion because at some point your modified system is no longer a 99/4A and you might as well just build a completely different machine.

 

If you can't produce something easy and cheap enough and just plug it in to an existing port then you are off into the land of custom mods. Even the F18A being a "plug-in" replacement is a stretch for some people to install into the 99/4A, and it is a show-stopper for some people on systems where the original VDP is soldered to the motherboard.

 

IMO the best place to make changes like this are in emulators, or in an FPGA-based SoC.

[Asmusr]

A bit off topic, but I'm just curious how difficult it would be to make a 1KB scratch pad mod?

[+mizapf]

I believe this is not too difficult when I look at the schematics. There are actually no precautions to unmap 8000-82FF (which in fact yields mirrors of 8300-83FF). You need two SRAMs 512x8; the only problem would be to wire the additional address lines to the address bus, maybe soldering them to the pins of the ROM circuits.

[Willsy]

1K of CPU RAM at >8000 would be a *huge* improvement to the machine IMO. I believe the SGCPU card has 1K in the >8000 area.

[matthew180]

There exist mods to do this I believe. There is very little full-range decoding anywhere in the 99/4A, so most base addresses repeat at alternate addresses across a larger section of the memory map. You could really hack something in, but the right way (if there is such a thing) would be to desolder the ROM and SRAM ICs and replace them with a carrier board. I believe this is what the existing kit I'm thinking of does.

 

Otherwise I'm sure you could find a way to piggy-back the SRAMs, bend some pins that have to be isolated, and do some point-to-point wire soldering to pick up the extra signals as needed. Personally I don't like this kind of modification, but then again I'd still be laying out a circuit board when you would be done with the mod.

 

Ah yes, here is the kit I was thinking of. Put together by Richard Bell:

 

http://www.mainbyte.com/ti99/32K16/32k16.html

 

16-bit 32K in the console as well as expanding scratch pad.

[Gary from OPA]

Ah yes, here is the kit I was thinking of. Put together by Richard Bell:

 

http://www.mainbyte.com/ti99/32K16/32k16.html

 

16-bit 32K in the console as well as expanding scratch pad.

 

Yep, I got that (kit by Bell) one in one of my consoles, and love it very much. -- Sadly that same console also now has bad video RAM, so I going to have super-mod it some more and replace the 9918 with F18A soon, just need to get somehow an F18A down here in DR.

 

The console also has the timing crystal mod, replacing the 12mhz with 14.38 and 16mhz settable by dip switchs on the back for even more speed.

 

The only way I could see a 64kx16 kit making it more or less plug and play would design a board that pushs pins right down over the main 9900 cpu, then only a few traces would need to be cut, the problem with pushover piggybacking sockets is they can get loose over time, which means still some tiny neat soldering would need to be done to secure the board to the 9900.

[Tursi]

I just wanted to add to the discussion that the 32k on 16-bit mod that I saw floating around the most often (and did myself) used to 32k chips and actually had 64k of memory, it just ignored the second half. The article mentioned that "someday" maybe the rest of the mod to bank it in would be done.

 

I did the mod myself later, in the cheapest, simplest way, I just tied an unused CRU pin to the RAM circuit to bank the /entire/ 32k block at once. That was on my page for a while but I pulled it because it's unstable, the 9901's "high" level is only about 2v, too low for the RAM chips to take reliably. But such a mod is only one wire more than the 16-bit RAM mod many did anyway.

 

I suspect the main reason it never happened was that nobody ever needed it. It's certainly arguable that doubling available RAM, even in a hacky way like I tried, could be very helpful, but until software using it exists, most people won't care.

Edited February 26, 2015 by Tursi

[+OLD CS1]

Would it be possible to bank in the second 32k via CRU?

[matthew180]

It would, but from a programmer's point of view that is a pain in the ass really. Something transparent to the your running program would be nice, which is where higher level language come in handy and can hide the banking details. Having a memory-mapped bank switch mechanism is much easier, and if the implementation was clever enough you might get away with quasi-direct support via BL, BLWP, or XOP.

 

The idea I'm noodling is that in branching to a subroutine in the bank area, the process of executing a BL (or BLWP, or XOP) against a specific address would cause the bank switch. If banking and landing on the exact routine is not possible, then maybe landing on a vector table in the banked-in memory to complete the jump to the proper routine... Maybe.

Edited February 26, 2015 by matthew180

[sometimes99er]

Hope this is on topic.

apersson850 talked about his 64K a few times.

 

http://atariage.com/forums/topic/152434-texas-instruments-ti-998-and-other-unreleased/?view=findpost&p=3162723

http://atariage.com/forums/topic/232771-using-the-tms9901-as-a-timer/?view=findpost&p=3152019

http://atariage.com/forums/topic/206520-internal-16-bit-32k-upgrade

[Willsy]

I suspect the main reason it never happened was that nobody ever needed it. It's certainly arguable that doubling available RAM, even in a hacky way like I tried, could be very helpful, but until software using it exists, most people won't care.

It would be great for cart based Forths, such as TurboForth and fbForth, as we could use all of that ram to compile Forth code into

[Omega-TI]

It would be great for cart based Forths, such as TurboForth and fbForth, as we could use all of that ram to compile Forth code into

 

I was thinking along those same lines in a 'Gazoo Cart'! The way these new carts can grab control over the TI is perfect for this application. It would lend itself perfectly for a DOS or GUI environment. A 'Cart & Mod Combo-Package' sounds pretty sweet to me!

[JamesD]

It would be great for cart based Forths, such as TurboForth and fbForth, as we could use all of that ram to compile Forth code into

Because we all know everyone uses Forth.

[+OLD CS1]

It would, but from a programmer's point of view that is a pain in the ass really. Something transparent to the your running program would be nice, which is where higher level language come in handy and can hide the banking details. Having a memory-mapped bank switch mechanism is much easier, and if the implementation was clever enough you might get away with quasi-direct support via BL, BLWP, or XOP.

 

The idea I'm noodling is that in branching to a subroutine in the bank area, the process of executing a BL (or BLWP, or XOP) against a specific address would cause the bank switch. If banking and landing on the exact routine is not possible, then maybe landing on a vector table in the banked-in memory to complete the jump to the proper routine... Maybe.

 

Would have been nice to have something so transparent on the Commodore 128. 16 different "banks," which are really not banks but different configurations of 180k of memory space containing 128k RAM (in two real 64k banks,) I/O devices, and ROM. You have to keep track of where you are or else.

 

EDIT: I have to take that back. The Commodore 128 kernel provides two routines, JSRFAR and JMPFAR, for cross-bank calls. I rolled my own, however, as ISTR others speaking of bugs or limitations using the routines so I completely forgot about them until I found reference in some old source code.

[JamesD]

Enlarging the scratchpad area won't help existing software unless you patch it or GPL.
If someone were to modify GPL you could certainly see a speedup there but you'll be replacing the system GROMs (ROMs?).
I think the math libraries would definitely benefit.
I vaguely remember the "floating point registers" being located in video RAM and moving them to new scratchpad RAM would definitely help.
I'm sure many other functions would benefit as well but that was the first that came to mind.
With a larger RAM upgrade, GPL could at least be patched to use a bank of 16K RAM rather than video RAM.

If you bank switch the entire RAM at the same time, your registers instantly change.
You have to have some fixed memory or it just won't work. At the very least, it would be really ugly to set up.
I think you would at least want the scratchpad RAM to be fixed and make calls through a stub routine located there.
1K is not a lot of RAM to do something like that.

The easiest and probably most practical approach is to bank switch 8K or 16K (x 16 bit) at a shot and in one area of the memory map.
A more complex but more flexible design would be to use an MMU that allow the programmer to chose where or even how much RAM is banked.
Either way you could use one program with multiple banks or switch between multiple programs that each have their own bank.
Using banks of RAM of 8K to 16K allows commonly called subroutines such as the OS, basic video access, common data, stub routines, register file and the main body of the program to lie in fixed RAM and less commonly used data or subroutines to lie in banks.
You group related code in the same banks to avoid having to perform a lot of calls from one bank of RAM to another.
The stub routines are directly called in place of code in the banked RAM. They switch to the bank where the actual code lies and call it.
Then the main code or subroutines don't have to directly deal with bank switching themselves.

The only way to make bank switching transparent to the programmer is for the language to handle it.
This can be done by an interpreter automatically or with some direction of the programmer as to how code is linked and loaded into RAM.
Apple Pascal (modified UCSD Pascal) is a perfect example of the language handling it.
Straight UCSD Pascal expected 64K (x 8 bit) RAM but Apple Pascal actually allowed programs larger than RAM to be run by swapping pieces of code in from disk.
There were patches that cached these sections of code on the larger RAM cards as a RAM disk.
The same type of patches could be made to the TI version of UCSD Pascal.

Forth could certainly do the same type of thing as Apple Pascal but who in their right mind would write that large of a Forth program?

TI BASIC and GPL could certainly be rewritten to use banked RAM but it would be easiest to leave variables in common RAM or one bank of RAM.

Edited February 26, 2015 by JamesD

[JamesD]

If you bank switch the entire RAM at the same time, your registers instantly change.

You have to have some fixed memory or it just won't work. At the very least, it would be really ugly to set up.

I think you would at least want the scratchpad RAM to be fixed and make calls through a stub routine located there.

1K is not a lot of RAM to do something like that.

VDP RAM could be used to communicate between banks for RAM but you still have the register file issue if you don't have some fixed RAM.

[kl99]

It might be worth to compare our machine to the tms990 mini computers that were released with more Ram. As far as I read this was going up to 2MB of memory mapped Ram. They either used the TMS9900 or a Schottky TTL processor as Cpu:

http://en.wikipedia.org/wiki/TI-990

[JamesD]

It might be worth to compare our machine to the tms990 mini computers that were released with more Ram. As far as I read this was going up to 2MB of memory mapped Ram. They either used the TMS9900 or a Schottky TTL processor as Cpu:

http://en.wikipedia.org/wiki/TI-990

The 9900 based models had 64K.

I think the models that had over 64K used the 99000 series CPUs or discrete logic.

[Willsy]

Because we all know everyone uses Forth.

Everyone in my house that owns a TI does

[Gary from OPA]

Everyone in my house that owns a TI does

Just imagine instead of designing GPL, that TI99 put a Forth Interpretar in the Console ROM and GROMs were really FROMs running Forth instead of GPL.

 

(Ok, getting off-topic here now!, but these days we could easy replace the console roms with a whole new stock boot-up along with new simulated GROMs running the new code.)

 

Similar to how the 99/8 was to have P-Code built-in, and how P-Code Card on the TI99/4a used GROMs.

 

BTW, If you have no tried Willsy's TurboForth you should, as its not at all like TI's original crappy one.

 

(ok, I really off-topic now, lets get back to this 64Kx16 design/kit idea, I think it is great if somehow it can be produced to be easy enough to install, that been the problem with the idea from day one I think).