16-Bit RAM and the RF Shield...

[Kchula-Rrit]

I've seen articles about putting RAM on the 16-bit part of the bus to gain some speed, and am thinking of building one.  However, I'm not sure about being able to fit it under the RF shielding clamshells.

 

Ideas?

What kind of metal are the clamshells made of?  Is it readily available?

 

K-R.

[JJB]

I have used several different solutions to add 32K to consoles and none of them had trouble fitting under the shielding. There is at least one IC height space between the shielding and the motherboard due to the TMS9919/29 heatsink.

 

One thing to keep in mind is that, unless you have a specific reason, the speed gain is not spectacular by any means and there are some programs that are incompatible with the 16-bit mod. I have attached the 8-bit mod I have used in my current console.

 

Jochen

TI 32k Mod.pdf

[Tursi]

There aren't very many incompatible programs -- and frankly these days, if you come across a deal breaker we can probably fix it.

 

You can consider installing a switch as well, that will let you go back to the original timing, which solves the incompatibility issues.

 

All that said, I got tired of the increased complexity and ... well, that PDF /is/ my 8-bit version.

 

But when I was using my TI as my sole console, I really appreciated the speed up.

 

[Kchula-Rrit]

Since the vast majority of my TI work is with Ed/Assem, I've been thinking of filling-in the 0x6000-7FFF hole where the cartridge has no RAM.  The easiest (least difficult?) solution would be to make a board to plug in to the side port, but seeing some 16-bit RAM chips on the Digi-Key Web-site gave me delusions of grandeur.

 

I'm trying to decide if I want to do it as 8- or 16-bits.

 

It might be fascinating to try making it CRU-switchable, just as a challenge.  I'd have to make a feed-through to the Nano-PEB, though.

 

My next project after I get my TI UPS done.

 

K-R.

 

[+Lee Stewart]

41 minutes ago, Kchula-Rrit said:

Since the vast majority of my TI work is with Ed/Assem, I've been thinking of filling-in the 0x6000-7FFF hole where the cartridge has no RAM.  The easiest (least difficult?) solution would be to make a board to plug in to the side port, but seeing some 16-bit RAM chips on the Digi-Key Web-site gave me delusions of grandeur.

 

That is what the SuperCart is for. Of course, you need to get the E/A GROM chip from an E/A cartridge to put it in the SuperCart.

 

...lee

[JJB]

Using Tursi's schematic (thanks Tursi, didn't realise it was yours; great writeup) I used a 256Kx8 RAM chip I had lying around and made two 32K pages switchable through unused TMS9901 I/O pins. Still haven't got a use for it though ?

[wierd_w]

It could be useful for running a debugger.  Data could be stored in the alternate page, about the actual program in the primary page.

(alternatively, you could keep two copies of the same memory, one where you make and test binary patches, and the other undoctored. Flip the GPIO to switch sets of data in memory.)

 

Alternatively, if you dont mind it being specific to just your system, you could write software that makes use of it.

Edited October 12, 2020 by wierd_w

[senior_falcon]

On 10/11/2020 at 3:06 AM, JJB said:

One thing to keep in mind is that, unless you have a specific reason, the speed gain is not spectacular by any means and there are some programs that are incompatible with the 16-bit mod. I have attached the 8-bit mod I have used in my current console.

 

Jochen

 

Actually the speed gain is quite noticeable if you are running an assembly program. Spad 13 Mk 2 is an example where the extra speed is much appreciated. it is much more responsive.

Extended BASIC is another story. A stopwatch will show a slight speed increase of around 1 percent.

What I did involves 2 ram chips piggybacked on the console rom chips and then 2 or 4 piggybacked logic chips with wires connecting all this. I have a switch to select between fast memory or slow memory. There are plans out there for this modification.

What I don't know is whether this is compatible with some of the new hardware that contains 32K on the 8 bit bus. Does the computer ignore the peripheral's 32K or do they conflict?

[Kchula-Rrit]

Any programs I wrote would likely be specific to my system, or any other that had this RAM installed.  Some of my ideas were:

Fast data buffers (if new RAM is 16-bit)

A loader that could use all of Low-RAM

More data buffers

Larger programs

 

On the timing issue, I looked at my PDF copy of the TMS9900 data sheet and figured that a register-to-register MOV instruction would save 12 clock cycles, and a register-indirect-autoincrement-to-same would save 24 clock cycles.  Considering that the R-to-R MOV is 14 cycles, it looks like a very good improvement.  This is just off the top of my head, assuming three wait states per memory access.

 

I use C99 and assembly, so that kind of improvement looks pretty attractive.

 

K-R.

[+DuaneAL]

6 hours ago, senior_falcon said:

Actually the speed gain is quite noticeable if you are running an assembly program. Spad 13 Mk 2 is an example where the extra speed is much appreciated. it is much more responsive.

Extended BASIC is another story. A stopwatch will show a slight speed increase of around 1 percent.

What I did involves 2 ram chips piggybacked on the console rom chips and then 2 or 4 piggybacked logic chips with wires connecting all this. I have a switch to select between fast memory or slow memory. There are plans out there for this modification.

What I don't know is whether this is compatible with some of the new hardware that contains 32K on the 8 bit bus. Does the computer ignore the peripheral's 32K or do they conflict?

Does the speed increase show up with a compiled basic program?

[senior_falcon]

1 hour ago, DuaneAL said:

Does the speed increase show up with a compiled basic program?

Yes, you should definitely notice that it is faster. Of course this may depend on whether delays were put into the program to slow it down to make a game more playable.

[+dhe]

Every time I see a 32K ram on the 16bit bus, I wish Gary and Don had finished the Accelerator, or I had box full of Top Radio Supply - 16bit boards to sell.

[speccery]

On 10/13/2020 at 12:06 AM, dhe said:

Every time I see a 32K ram on the 16bit bus, I wish Gary and Don had finished the Accelerator, or I had box full of Top Radio Supply - 16bit boards to sell.

I'm curious - are there pictures of those 16-bit memory boards? Watching at recent TI-99/4A repair videos made me think that for the repair purposes alone it would be useful to have a memory plugin board (for RAMs and ROMs). I could design such a board.

[+dhe]

A good pic here:

 

Jeff White and I put together a similar device for testing and debugging..

VDP+XTAL+32K of Static Ram - of course half the ram was wasted, and signals you didn't want you could snip of off the wire wrap socket. So yea, those parts, wirewrap socket and a proto board.

 

[apersson850]

I have 64 K RAM, 16 bit wide, in my console. It can cover the whole address range. Mapped in and out in 8K blocks by CRU bits at >400. One advantage of this is that if I map out the 32 K RAM part, then anything "below" becomes visible. So my design allows for simply paging out the 16 bit wide RAM, and revert to the standard memory expansion in the PEB, if necessary.

It also allows for copying the resident monitor program to RAM, then modify it, if desired.

Edited October 19, 2020 by apersson850

[Kchula-Rrit]

20 hours ago, apersson850 said:

I have 64 K RAM, 16 bit wide, in my console. It can cover the whole address range. Mapped in and out in 8K blocks by CRU bits at >400. One advantage of this is that if I map out the 32 K RAM part, then anything "below" becomes visible. So my design allows for simply paging out the 16 bit wide RAM, and revert to the standard memory expansion in the PEB, if necessary.

It also allows for copying the resident monitor program to RAM, then modify it, if desired.

Do you have a schematic for this?

 

K-R.

[apersson850]

Yes, I've published it here earlier.

[Reciprocating Bill]

I'm new here. What a great forum.

 

Coincidently, I recently (I mean literally yesterday) successfully completed the 16-bit upgrade described here: 

 

http://www.mainbyte.com/ti99/16bit32k/32kconsole.html

 

Took about four hours. The shield is not a factor.  

 

I've found that speed increase varies depending upon what my code is doing. And the upgraded computer occasionally does some flakey things.

 

Here are the results of some tests I ran. First number is 16-bit console, second is stock, and third is stock performance as a percentage of 16-bit performance. All these programs were already optimized as much as I was able, e.g. using registers in scratchpad, along with small snippets of code in PAD. These are stopwatch timings. 

 

- Assembly program calculates and displays 3500 points of the Lorenz attractor with heavy use of console FP routines:

 

 139"     147"    94%       - stock runs at 94% of the speed of the upgrade. Not a big gain because of heavy use of ROM routines. 

 

- Same assembly program replays above 3500 points 15 times from RAM storage:

 

12.9"     14.6"   83%      - better, the bottleneck now being VDP reads and writes

 

- Assembly program calculates and displays 4 levels of the Mandelbrot Snowflake. Again many calls to console ROM for FP calculations:

 

105"      111"    94%

 

- Assembly program replays above four levels of Snowflake from RAM storage (five times):

 

18.1"     22.5"   80%      - I rolled my own Bresenham. 

 

- Assembly program displays first 6 levels of Hilbert Curve on bitmap (three times):

 

31.9"     39.8"   80%      - same Bresenham.

 

Some fbForth and TurboForth results - no large gains expected, given that these Forths are running from cartridge ROM:

 

- fbForth loads four screens from cold start (on real iron with floppy storage).

 

22.7"    23.15"  96%    

 

- fbForth loads same four screens a second time, so no disk access:

 

14.2"    14.6"    97%   

 

- fbForth runs Sieve of Erastothanes benchmark as presented in January 1983 Byte Magazine (a very dog-eared copy of which I still own).  (1 iteration rather than 10).

 

15.8"    17.6"    89%      

 

- TurboForth Sieve of Erastothanes (1 iteration):

 

10.5"    11.9"    88%       - again, this makes sense.  

 

- Wycove Forth Sieve of Erastothanes (1 iteration):

 

11.2"    15"       75%       - the biggest Forth beneficiary.  Makes sense - Wycove Forth runs entirely out of RAM.

 

My assembly version of the Sieve of Erastothanes.  Registers in scratchpad.  (10 iterations). 

 

6.37"    10"       67%       

 

Sieve on stock console with registers and central loop of code squeezed into scratchpad:

 

7.1"  

 

This is not overwhelming, but about what I expected. Due to the occasional flakeyness of the upgraded board (occasional garbage written to the home screen, even with no module in place), as well as my not having a satisfactory second keyboard for a second console, I've reverted for now to my nearly pristine and very stable stock console. There is something to be said for stable versus modestly faster but flakey.  

 

Edited November 2, 2020 by Reciprocating Bill
Minor corrections, deleted white space.

[Tursi]

Congratulations! Definitely take a look at your upgraded console when you have a moment, though, it should not be flakey on the title screen at all (especially because the console code doesn't even look at memory expansion, but also from experience - I ran a 32k console with a wait state switch for years). You'll probably find a cold solder joint.

 

Well, assuming it was solid before the upgrade, of course. Failing VRAM is an increasing problem on our machines, and that would be the second guess... Of course, you can replace that too!

[Reciprocating Bill]

I do plan to reheat suspicious joints (I think that's legal now). Prior to surgery I powered up the board briefly to assure myself that it fired up but didn't run it for any period of time - there may have been problems lurking that emerge over time. Also, as I have seen on an unmodified console, the screen brightness sometimes flickers slightly with this logic board with a period of about one second, a problem that fluctuates slightly over time (annoying but not fatal). That occurs when the computer is stable and does not appear to be related to the upgrade.

 

I've run the upgraded console for hours with either a 32K RAM burn-in or some of my own assembly programs without problems, so the RAM itself seems solid. In fact, that is when the console is most stable. The haywire behavior comes on suddenly and then progressively, sometimes on the startup screen or when running out of a module (e.g. MunchMan from FinalGrom). It appears that VDP ram is being written to as the pattern table becomes progressively more corrupted, while the underlying program keeps running. Sometimes switching contexts (e.g. going into TI Basic and back) restores the system to normalcy. A couple times the video has lost its sync altogether.  

 

At any rate, I'm thinking I'll find a beat up console with a known solid logic board and re-do the operation, as I am feeling more confident in my ability to pull it off, and probably more quickly. I don't want to modify my main console, as it is too nice to risk.  

Edited November 2, 2020 by Reciprocating Bill
Correction

[Tursi]

Okay, yeah, that definitely points to the VRAM starting to go. Over at Ninerpedia there's a selection of title page images that show each VDP RAM chip individually corrupted -- if you catch catch the title page corruption matching one of them, that could tell you which chip to replace. (Or, of course, replacing them all). 

 

https://www.ninerpedia.org/index.php?title=Troubleshooting

 

There's also the F18A upgrade - the older VGA one is harder to come by at the moment, but Matt will hopefully have the newer version in a few months. That is a plug-in replacement for the VDP that obsoletes the on-board video memory, and so bypasses the issue.

 

[apersson850]

If you have a program running with both code and workspace in the expansion memory, then the speed increase is about 110%. Or a reduction of the time to 48% of the standard, if you prefer it that way.

So for programs where you have problems using the 16-bit RAM for your workspace, the speed increase is quite substantial.

[Reciprocating Bill]

4 hours ago, apersson850 said:

If you have a program running with both code and workspace in the expansion memory, then the speed increase is about 110%. Or a reduction of the time to 48% of the standard, if you prefer it that way.

So for programs where you have problems using the 16-bit RAM for your workspace, the speed increase is quite substantial.

I get very similar results given those conditions with assembly versions of the sieve. Illustrates the invaluable contribution of the scratch pad to performance on the stock design. 

Edited November 3, 2020 by Reciprocating Bill

[apersson850]

Yes, and it also illustrates the significance of all-over 16-bit RAM, for not having to worry about where you put your workspace but still get the full possible performance.

I designed my 16-bit RAM expansion myself, and made it possible to bank it out using CRU bits. If I do that, underlaying memory becomes accessible, so I can keep the standard 32 K RAM expansion in the box and set CRU bits to use that instead of the 16-bit wide expansion in the console. Thus it's very easy for me to test the difference, in the same console.

[+DuaneAL]

Is the scratchpad limited to 256?  I seem to recall that it could be expanded but I don't know if there would be a benefit to doing that.  Although, if you had a larger scratchpad, that might make Playground more interesting.

23 hours ago, Reciprocating Bill said:

I get very similar results given those conditions with assembly versions of the sieve. Illustrates the invaluable contribution of the scratch pad to performance on the stock design.