Kchula-Rrit Posted October 11, 2020 Share Posted October 11, 2020 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. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/ Share on other sites More sharing options...
JJB Posted October 11, 2020 Share Posted October 11, 2020 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 1 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4651712 Share on other sites More sharing options...
Tursi Posted October 11, 2020 Share Posted October 11, 2020 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. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4652234 Share on other sites More sharing options...
Kchula-Rrit Posted October 12, 2020 Author Share Posted October 12, 2020 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. 2 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4652522 Share on other sites More sharing options...
+Lee Stewart Posted October 12, 2020 Share Posted October 12, 2020 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 1 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4652535 Share on other sites More sharing options...
JJB Posted October 12, 2020 Share Posted October 12, 2020 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 ? 1 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4652577 Share on other sites More sharing options...
wierd_w Posted October 12, 2020 Share Posted October 12, 2020 (edited) 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 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4652579 Share on other sites More sharing options...
senior_falcon Posted October 12, 2020 Share Posted October 12, 2020 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? 1 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4652667 Share on other sites More sharing options...
Kchula-Rrit Posted October 12, 2020 Author Share Posted October 12, 2020 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. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4652872 Share on other sites More sharing options...
+DuaneAL Posted October 12, 2020 Share Posted October 12, 2020 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? Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4652965 Share on other sites More sharing options...
senior_falcon Posted October 12, 2020 Share Posted October 12, 2020 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. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4653047 Share on other sites More sharing options...
+dhe Posted October 12, 2020 Share Posted October 12, 2020 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. 1 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4653054 Share on other sites More sharing options...
speccery Posted October 16, 2020 Share Posted October 16, 2020 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. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4655516 Share on other sites More sharing options...
+dhe Posted October 16, 2020 Share Posted October 16, 2020 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. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4655591 Share on other sites More sharing options...
apersson850 Posted October 19, 2020 Share Posted October 19, 2020 (edited) 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 2 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4657834 Share on other sites More sharing options...
Kchula-Rrit Posted October 20, 2020 Author Share Posted October 20, 2020 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. 1 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4658565 Share on other sites More sharing options...
apersson850 Posted October 20, 2020 Share Posted October 20, 2020 Yes, I've published it here earlier. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4658973 Share on other sites More sharing options...
Reciprocating Bill Posted November 1, 2020 Share Posted November 1, 2020 (edited) 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. 1 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4667606 Share on other sites More sharing options...
Tursi Posted November 1, 2020 Share Posted November 1, 2020 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! Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4667927 Share on other sites More sharing options...
Reciprocating Bill Posted November 2, 2020 Share Posted November 2, 2020 (edited) 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 1 1 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4668450 Share on other sites More sharing options...
Tursi Posted November 2, 2020 Share Posted November 2, 2020 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. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4668829 Share on other sites More sharing options...
apersson850 Posted November 2, 2020 Share Posted November 2, 2020 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. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4668843 Share on other sites More sharing options...
Reciprocating Bill Posted November 3, 2020 Share Posted November 3, 2020 (edited) 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 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4669042 Share on other sites More sharing options...
apersson850 Posted November 3, 2020 Share Posted November 3, 2020 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. 1 Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4669228 Share on other sites More sharing options...
+DuaneAL Posted November 4, 2020 Share Posted November 4, 2020 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. Quote Link to comment https://forums.atariage.com/topic/312282-16-bit-ram-and-the-rf-shield/#findComment-4669792 Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.