internal 16 bit 32K upgrade

[JamesD]

Have any of you tried one of these? I've been thinking about performing this upgrade ever since I bought my TI but I had too many other projects I wanted to finish first. (I might have already asked about it before)

Any drawbacks? Known conflicts?

 

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

[senior_falcon]

Works great. Pay attention to detail and avoid static. Be sure to add the switch that adds the wait states because there are some programs that do not like the higher speed. I would estimate the speed increase at around 60% based on some testing I did. Good luck!

[Willsy]

I tried to email Richard at his swim4home at aol email address but it bounced. Does anyone have his latest email address?

 

Thanks

 

Mark

[RXB]

Great stuff. Wish I was more of a hard ware geek.

So does the extra scratch pad work >8000 to >8300?

[Willsy]

Yep - just been reading on the web site. It expands PAD ram so that it runs from >8000 to >83FF - 1K of PAD RAM.

 

Swooon!

[RXB]

Wow I wonder how much faster I could make GPL with that?

[JamesD]

Works great. Pay attention to detail and avoid static. Be sure to add the switch that adds the wait states because there are some programs that do not like the higher speed. I would estimate the speed increase at around 60% based on some testing I did. Good luck!

You wouldn't happen to remember the programs that don't like it off the top of your head would you?

[JamesD]

I would think the extra scratch pad RAM would never need disabled since scratch pad RAM is 16 bit anyway and no old software would take advantage of it anyway.

[+Lee Stewart]

I would think the extra scratch pad RAM would never need disabled since scratch pad RAM is 16 bit anyway and no old software would take advantage of it anyway.

 

It's not the extra pad RAM that is the problem. It's all the rest of the new RAM where your program is loaded and run.

 

...lee

[JamesD]

It's not the extra pad RAM that is the problem. It's all the rest of the new RAM where your program is loaded and run.

Exactly!

You could just jumper the extra scratchpad setting as enabled and should never have a problem.

It would be one less switch to drill a hole in the case for.

<edit>

Or leave the switch connection disconnected if it's enabled by default.

Edited December 16, 2012 by JamesD

[marc.hull]

This project is in my opinion the best of the 32K in console mods and you won't be wasting your time doing it. I have used one for about 5 years and have had no issue with it nor have I actually ever run into any problems with programs not liking the faster memory (this includes file managers and Telco.) I theorize that that statement was a disclaimer in case one ever popped up that didn't like the faster environment and has since stuck. This of course does not take into consideration programs that use CPU timing loops such as games but rather programs that crash or otherwise STB because of the extra speed. At any rate the board does have the switch option to throttle back the speed so to speak if you need to slow things down.

 

The PAD RAM option really just adds another 3/4K to the machine. Theoretically it could cause a problem if some program out there uses multiple base addresses to reference the PAD location. On an unmodified TI the code would work but with the expanded PAD you could have some issues. Don't know if there are any programs out there that do this. Don't think it advisable to use this feature on software you plan to distribute as it would only work on a like equipped machine.

 

The option that hasn't been mentioned is the one that pages in 8K of the memory as cartridge ROM. This could be very useful to the cart enthusiast. This option allows you to code, assemble and convert on a TI and then test immediately by paging in the cart space and loading to it. No burning to an EPROM or having to use other specialized hardware.

 

Richard Bell is the only one I know of who sells these devices. If you can't reach him directly via Email he can be pinged on one of the Y! groups or on Kyle's BBS 'HEATWAVE'.

 

Good luck with it and please keep us updated.

[RXB]

I have seen source code that uses >8000 instead of >8300 for scratch pad, but as that memory is not available it works fine.

 

So if the Scratch Pad was used yes there are a few programs that would crash. Including some GROM games.

[Willsy]

I have seen source code that uses >8000 instead of >8300 for scratch pad, but as that memory is not available it works fine.

 

So if the Scratch Pad was used yes there are a few programs that would crash. Including some GROM games.

 

We'll cross those bridges when we come to them Rich have dis-assembler, will hack!

[marc.hull]

I have seen source code that uses >8000 instead of >8300 for scratch pad, but as that memory is not available it works fine.

 

So if the Scratch Pad was used yes there are a few programs that would crash. Including some GROM games.

 

What I did not make very clear was this....

 

Provided the original programmer equated the scratchpad space to one area (IE >8000 or >8100 or >8200 or >8300) then it would make no difference whether or not the 1K of PAD RAM was enabled. The console does not fullu decode this area so that >8000,>8100,>8200 and >8300 all appear as the same location.

 

The only problem that might occur is if the same program has different equates as to the PAD location. For example if two people were creating code and one coder defined the PAD as >8000 while the other defined the PAD as >8100 then there would most definately be a problem running this on a TI with the option enabled. They would then be two completely different memory locations and probably would cause a glitch or two.

 

Programs that define the PAB as something other than >8300 will work just fine with the option enabled provided they stay consistant with their location (IE not calling it >8000 in one segment and then calling it >8300 in another.) Don't know if that is even an issue in any programs or not.

 

At any rate. Defining your PAB @ >8000 will not in and of itself create a problem with a modified machine that has the option on.

[senior_falcon]

I've only seen one program that I knew was unhappy with the extra speed of 32K on the 16bit bus. That program was Tennis. With the faster speed memory the sprites would split in half at the waist, leaving the upper body half floating in the air swinging its racket and disconnected with the lower half. I seemed kind of comical to see a pair of legs moon-walking across the tennis court! I might look into the program to see how they managed to write to the VDP so fast.

[Willsy]

I've only seen one program that I knew was unhappy with the extra speed of 32K on the 16bit bus. That program was Tennis. With the faster speed memory the sprites would split in half at the waist, leaving the upper body half floating in the air swinging its racket and disconnected with the lower half. I seemed kind of comical to see a pair of legs moon-walking across the tennis court! I might look into the program to see how they managed to write to the VDP so fast.

 

This is a total guess, but it sounds like the tennis player was two or sprites and I'm guessing that the faster software was simply hitting the vdp processor too fast.

[apersson850]

Yes, that's true. When using a 16-bit RAM at full speed, Tennis doesn't work. It's also almost impossible to beat, since the gameplay speeds up as well.

What I did with my own 16-bit RAM design was to let it co-exist with the normal 32 k RAM in the expansion box. I installed a latch, so by using a CRU bit, I can switch out the 16-bit RAM, and then the standard 32 k RAM is accessed instead. Doing that, Tennis plays normally.

I also installed a decoding of the actual write to the VDP, that's the problem, and can thus inject a wait state if, but only if, it's the VDP that's accessed. It works. Tennis plays with correct sprite handling, just faster than normal. This feature is also enabled with a CRU bit, since I don't want it active when running programs normally.

You've probably seen the note to put in an extra NOP when writing certain data to the VDP. That's not really necessary, unless both code and WP is in fast RAM. But TI recommended it all the time. Software which doesn't adhere to the recommendation fails with the fast RAM.

Finally, I actually installed 64 k RAM, 16 bits wide, and used a few other CRU bits to overlay all other address spaces in the system with fast RAM. I can thus enable RAM over the cartridge space, instead of the operating system and so on. This allows modifying the interrupt vectors and other system data, if I want to, but on a reset the normal ROM is brought back in, to allow the machine to start properly again.

 

If everything is in expansion RAM, i.e. workspace, code and all operands, then the speed increase is about 110%. But sensible code uses workspace in the RAM PAD, which already is 16-bit wide, so a more normal figure is around 50-60% speed increase, depending upon how the code is written.

 

Edit: Following the link to the kit above, I see that they too have a couple of my modifications, for enabling and disabling memory, but I've never seen anyone else thinking about making it possible for the CPU to do that. It makes it possible to use all extra memory by a program, like when I simulate a RAM disk with my memory, since there's no switch which must be operated manually.

Edited January 4, 2013 by apersson850

[marc.hull]

Yes, that's true. When using a 16-bit RAM at full speed, Tennis doesn't work. It's also almost impossible to beat, since the gameplay speeds up as well.What I did with my own 16-bit RAM design was to let it co-exist with the normal 32 k RAM in the expansion box. I installed a latch, so by using a CRU bit, I can switch out the 16-bit RAM, and then the standard 32 k RAM is accessed instead. Doing that, Tennis plays normally.

 

Could you elaborate on the scheme you used to page in the new memory and page out the PBOX card ? I have seen thierry's mod using CRU to control oscillators but never this. Sounds good.

 

 

I also installed a decoding of the actual write to the VDP, that's the problem, and can thus inject a wait state if, but only if, it's the VDP that's accessed. It works. Tennis plays with correct sprite handling, just faster than normal. This feature is also enabled with a CRU bit, since I don't want it active when running programs normally.

You've probably seen the note to put in an extra NOP when writing certain data to the VDP. That's not really necessary, unless both code and WP is in fast RAM. But TI recommended it all the time. Software which doesn't adhere to the recommendation fails with the fast RAM.

 

Actually I think the VDP has been shown to be pretty bullet proof to the fast memory situation. The only circumstance that I am aware of that can cause VDP problems is Writing to the VDP almost immediatly after reading from it and this is a hit or miss afair.

 

Finally, I actually installed 64 k RAM, 16 bits wide, and used a few other CRU bits to overlay all other address spaces in the system with fast RAM. I can thus enable RAM over the cartridge space, instead of the operating system and so on. This allows modifying the interrupt vectors and other system data, if I want to, but on a reset the normal ROM is brought back in, to allow the machine to start properly again.

 

Again if you can I'd like to to elaborate on how this was done. Especially your technique for paging out certain segments like the ROMs. How did you account for the mapped devices and segment control signals?

 

If everything is in expansion RAM, i.e. workspace, code and all operands, then the speed increase is about 110%. But sensible code uses workspace in the RAM PAD, which already is 16-bit wide, so a more normal figure is around 50-60% speed increase, depending upon how the code is written.

 

Edit: Following the link to the kit above, I see that they too have a couple of my modifications, for enabling and disabling memory, but I've never seen anyone else thinking about making it possible for the CPU to do that. It makes it possible to use all extra memory by a program, like when I simulate a RAM disk with my memory, since there's no switch which must be operated manually.

 

Sounds like you have quite a system. Any chance of posting a PIC or some schematics of how you did some of this ? Were you involved with the SNUG group ? How about a name ?

[JamesD]

Anyone find new contact info for the guy that makes this board?

[apersson850]

I may still have some schematics of my design. If I can find it I can scan and post.

I was a member of the Swedish group Programbiten. My name is Anders Persson. If you read old newletters from the group, you'll find my name in there in some issues.

I also had some contacts with some Americans, mainly through my friend Maurice E. T. Swinnen, a man many TI users at least know by name.

[apersson850]

OK, here's a first attempt to upload some documentation I found about my 16 bit 64 kbyte memory upgrade design. I managed to improve the scans - they should be reasonably readable now, in spite of being pencil drawings.

memexp_ap_99.pdf

Edited February 26, 2013 by apersson850

[CantStopClicking]

OK, here's a first attempt to upload some documentation I found about my 16 bit 64 kbyte memory upgrade design. I managed to improve the scans - they should be reasonably readable now, in spite of being pencil drawings.

 

Wow, this sounds cool. Just to make sure I understand; this would allow one to modify the console ROM's, in effect, as well as utilize as SuperCART? (Not to mention the 32k RAM expansion itself).

 

Any pictures of your solution by chance?

 

Thanks for sharing!

 

-Dano

[apersson850]

This design allows 64 kbyte RAM across the full address range. Separate CRU bits, at 400H, control whether the segments in the expansion are active or not.

The 32 kbyte segment at addresses 2000H-3FFFH and A000H-FFFFH are active by default, since you usually want the memory expansion to be available. That segment is 32 kbyte as a unity.

The remaining parts are split in 8 kbyte segments, each one enabled individually. Since they cover addresses used by other parts of the system, normally, they are off by default.

 

Designs like this one, where RAM covers ROM, often have write-through capability. That is, when the RAM is disabled, reading returns data from ROM, but writing writes into the RAM. Since my design also covers memory mapped I/O and regular RAM, I have not given it this capability. Thus to copy console ROM (0H-1FFFH) into RAM, you have to write a small program which reads the ROM data to another segment of RAM, in ordinary RAM expansion or in one of the new segments in my memory design, then enables RAM over the ROM addresses and transfers the whole thing back there again. Now you have an identical copy of the ROM, but in RAM, and can change the interrupt vectors or whatever you like. Allows you to use the timer in the TMS 9901 PSI for something else, for example.

So while making copying ROM a bit more complex, it allows the co-existence of my RAM expansion with the normal memory expansion, if you like. As soon as you disable my part, the normal one shows up at the same addresses.

You can also use this together with any module, since this RAM isn't visible when disabled, but overrides access to module memory space (6000H-7FFFH) when enabled. I have for example used this memory, together with RAM in a MaxiMem module and the conventional 32 K expansion, to create a RAM disk for my p-code system.

 

I probably should have split the 32 K RAM part in smaller pieces, since now it's a bit difficult to both run a program in RAM and use the other 32 K RAM for something useful at the same time. You have to move your running program elsewhere, like to module space, to accomplish that.

At the time when I did the design, I was limited to conventional chip select logic (didn't have access to parts needed to implement a PAL or similar), and also had to do something which could be soldered piggy-back to chips already in the computer, since I didn't have any PCB manufacturing equipment.

[CantStopClicking]

Well I got about 90% of that, and I'll probably lose 10% by the time I click "post". I'm no electronics expert by any stretch, matter of fact I'm probably terrible, but that doesn't stop me from trying to understand it!

 

So, when you say you created a RAM disk for your p-code system; aren't you limited on size at that point? Like 32k or something? And how does that help you with your p-code? I'm curious because I have the p-code card but have no idea how to use it properly. Maybe even better stated, I don't know how to use it at all. I've got the disks and have booted to it but I'm lost at that point.

 

-Dano

[apersson850]

Since my memory expansion doesn't replace the normal 32 Kbyte RAM expansion, but co-exists with it, my design effectively adds 64 Kbytes of RAM.

In addition to that, I have a Maximem module (similar to GRAM cracker), which adds another 56 Kbytes of RAM. Add to that some RAM on my own expansion cards (real time clock and I/O card), and I had a total of about 128 Kbytes of RAM to use as a RAM disk.

The p-system is designed to handle six drives. TI only enabled three, since their own controller could handle no more. I have a CorComp controller with four DS/DD drives, so I already had to change a byte in the p-system's RAM tables to enable the fourth drive. But nothing in the p-system requires the different drives to have the same driver software. So I just wrote a driver for my RAM disk, which behaves like a normal disk, just at a different address. The p-system keep tables of the driver's addresses, so adding a new driver is as easy as plugging in the address to it.

When this RAM disk software is running, it shows up as a fifth drive in the p-system (volume #11, after the conventional drives #4, #5, #9 and #10). I have my startup software create the drive, install the directory (equivalent to formatting it) and then copy some system files, like SYSTEM.COMPILER, SYSTEM.EDITOR and SYSTEM.FILER to this RAM drive. It's not big enough to also store SYSTEM.ASSMBLER and SYSTEM.LINKER. I usually don't copy any of them, but use the remaining space on the RAM disk for program files and stuff. But it's not really needed, since the brunt of the disk activity during program development is by the heavily segmented compiler. Having the compiler stored on a RAM disk reduces compile time to about half.

Combining this with the 16 bit RAM memory expansion enhanches p-system performance in general by around 10%. A lot of the memory accesses are either already in scratch pad RAM, to the p-code card or to VDP RAM. Thus the modest speed increase by the faster memory. But it allows you to store assembly support routines for the p-system anywhere without any speed penalty. Thus you don't have to use the p-system's primary workspace at 8380H, where only R0-R7 are available, since the other registers are used by the PME.

 

Should perhaps add that my design does not support adding any wait states for normal memory access, since it allows you to still use the ordinary 32 K RAM expansion instead, if you prefer that. Or need to, due to some software relying on the timing you get. But I can engage a wait state for VDP access, a feature which can allow you to still use the full speed of the 16 bit wide memory but not suffer from timing issues when interfacing with the VDP.

Edited March 3, 2013 by apersson850