Jump to content
IGNORED

Fully populated Scratch Pad for Ballmann-Clulow 32K mem expansion


hhos

Recommended Posts

BEWARE: I have not tested this but, it is so simple and I can see no reason for it not to work.

 

If you have already installed this 32K console SRAM mod, then it won't take much more work to fully populate the RAM space at >8000 to >83FF. That would give you 1024 bytes instead of just 256. It seems to me that disconnecting the CS* from the 6810s and moving that signal over to pin 4 of U504 C2 (first remove the +5VDC from it) should be all that is necessary. I see two possibilities for doing this.

 

I think this might be the easier of the two but, you may find other possibilities that I didn't consider. The signal could be removed from the 6810s by cutting the trace coming from pin 8 of U507. Run a jumper from pin 8 of U507 to pin 4 of U504 C2. Do not forget to remove the 5VDC from pin 4 prior to connecting this jumper, though. Cutting this trace at this point cuts off the connection to U606, pin 12. In all likelihood, you would want to reestablish the connection from U507, pin 8 to pin 12 of U606. This would be required, if you have the defeat switch installed, so the Scratch Pad memory would still be fast memory when the switch is in bypass mode.

 

The 2nd solution I came up with was to pull or cut the CS* pin on BOTH 6810s. Then run a jumper from the hole that is left under pin 11 to U504 C2-4 (again, remove the 5VDC from it first). This doesn't break the connection to pin 12, U606, so nothing more should have to be done. Alternatively, you could remove both 6810s from the board since they will not be used anymore. I intend to leave them in, possibly to be used as a small buffer for another idea with which I have been toying.

 

I made up schematics for what I call the Clulow-Guion 32K upgrade, and I am attaching them to this post. They are intended as an addendum to "Hardware Manual for the Texas Instruments 99/4A Home Computer" by Michael L. Bunyard. The largest difference between the CG32K and the BC32K is the CG32K can be switched back and forth between 0 wait states and the normal 4 wait states using a toggle switch. I don't think you can hot swap it, though I can't offer first hand test results. Even though I am going to use this as a basis for the 1st stage of my own design, I do not intend to use a toggle switch to bypass the zero wait state in mine, so chances are that I never will test a hot swap of this particular mod. I want to be able to hot swap mine via software, and perhaps a mechanical push button. Instructions for the three current Ballmann-based mods are found here: http://www.mainbyte.com/ti99/16bit32k/32kconsole.html

 

Please let me know if you think I'm in error with the schematics or the modification I've suggested. If you try it and it works, please let me know. If it doesn't work... well, that's your fault for trusting me. ;-)

 

 

Clulow-Guion_32K.upgrade.tar.gz

  • Like 7
Link to comment
Share on other sites

I modified a couple of the pictures from the Ballmann-Clulow project to show the jumpers and soldering points. There are two pictures in the attached file. You only follow ONE of them. They both have the same result. It's just a question of whether you want to cut a trace, or pull/cut one pin on each of the two 6810s. Pulling/cutting the pin looks easier but, sometimes it's a little tricky pulling the pin. You might break off the pin from the chip, or pull the trace up off the board. Cutting the pin is easier. Just be careful, in either case, when you solder your wire into the hole underneath the bent up pin.

 

Cutting the trace is the easier way to go, especially if you feel you lack soldering skills. There is just one more point to solder to, and about 5 times the length of wire for the jumper, but each solder point is unobstructed, and there is virtually no chance of accidentally pulling a trace away from the board.

 

HH

CG_32K_console_1K.Scratch.tar.gz

  • Like 3
Link to comment
Share on other sites

I like my own design better.

First, it makes the 32 K RAM internal and 16 bit wide, no wait states.

Second, it adds another 32 K RAM, 16 bit wide, which can be switced in or out, in 8 K banks, to replace memory anywhere in the machine. Console ROM, cartridge space - you can make it RAM instead. With all RAM enabled, you have 64 K contiguous RAM.

Third, you can disable the 32 K 16-bit internal RAM, in which case you instead access the normal 32 K RAM expansion.

Fourth, it's possible to run at 16-bit wide speed, no wait states, but enable a hardware wait state Circuit which only activates on VDP access, where it's necessary.

Fifth, all these options are accessible to the CPU, so they can be done under software control.

  • Like 4
Link to comment
Share on other sites

...

Fourth, it's possible to run at 16-bit wide speed, no wait states, but enable a hardware wait state Circuit which only activates on VDP access, where it's necessary.

...

 

Why do you need a wait-state for VDP access? I realize back-to-back memory operations to the 9918A need consideration, but the individual memory access cycle (#CSR or #CSW low) is only 200ns on the 9918A. The 9900 takes 7 clock phases for a no-wait-state read or write cycle at the typical 3MHz clock, which is around 582ns.

Link to comment
Share on other sites

I like my own design better.

I'm not advocating this mod so much as evaluating it. I just analyzed what it is doing, realized how easy it would be to include fully populated Scratch Pad, and wrote up something on it. It is here essentially because I think this is a simple, cheap and effective way to speed the TI99 up. I figure, for that very reason, quite a few people have used it, and don't realize with a little bit of time, solder and wire, they could add just a little bit of out of the way memory. This mod also leaves a number of unused resources which could be useful for further expansion, some of which could start to resemble aspects of your system. There's not enough to put together a paging system for the RAM blocks, but it would be a cheap start.

 

Right now, my focus is on designing a system that only uses technology that was available in the early 80s. No FGPAs or CPLDs. PALs are out simply because even if I can find them, the expense would be too great. GALs, PALCEs, PEELs, and similar chips programmed with only the capabilities of a PAL chip are OK. And, of course, I will use SRAMs that weren't available in the 80s, also because of availability and expense. As the system matures I'll allow more modern technologies into the design. The first goal though, is to make it as fast as I can with 74XXX technology chips.

 

First, it makes the 32 K RAM internal and 16 bit wide, no wait states.

Second, it adds another 32 K RAM, 16 bit wide, which can be switced in or out, in 8 K banks, to replace memory anywhere in the machine. Console ROM, cartridge space - you can make it RAM instead. With all RAM enabled, you have 64 K contiguous RAM.

This one also adds 64K, no wait states, to the console. It just uses only 32K of it. :) It is a minimal expansion to give a developer an idea of how his software would play on an early 80s machine, and then on an 80s machine with zero wait states. At least that is how I look at it.

 

I'm assuming that since you can switch RAM into the memory I/O space, that you use the CRU to switch the 8K blocks in and out? Where did you map that into the CRU space?

 

Third, you can disable the 32 K 16-bit internal RAM, in which case you instead access the normal 32 K RAM expansion.

I might put that into my next mod. How many wait states do you have when accessing that external RAM expansion?

 

 

Fourth, it's possible to run at 16-bit wide speed, no wait states, but enable a hardware wait state Circuit which only activates on VDP access, where it's necessary.

Only on VDP access? How many wait states does it insert? I believe GROM is even slower than VDP, possibly because it is on the 8 bit side of the MUX? What about GROM access? And the other memory mapped devices? Sound chip? Speech Synthesizer? Anything else?

 

I'm still looking at ideas for my own TI99 mod design, but this one still looks like a good basis to start with on the first one. Yours sounds like it will be more similar to my #3 or #4. Does your modified system use only legacy 74XXX chips? PALs or GALs? Something more sophisticated?

 

HH

Link to comment
Share on other sites

VDP is only "slow" because of the need to set the address before accessing, the VDP can run at the speed of the bus otherwise (and so reads/writes are the same speed as reads/writes to RAM). Wait states are not necessary to talk to it, but if you remove them fully, more software than before will have overrun issues. ;)

 

GROMs are quite slow but they halt the CPU, so wait states are not necessary to access them.

Link to comment
Share on other sites

VDP is only "slow" because of the need to set the address before accessing, the VDP can run at the speed of the bus otherwise (and so reads/writes are the same speed as reads/writes to RAM). Wait states are not necessary to talk to it, but if you remove them fully, more software than before will have overrun issues. ;)

 

GROMs are quite slow but they halt the CPU, so wait states are not necessary to access them.

According to this at least one wait state, after A15 toggles LOW, is needed when accessing GROM.

 

"Solving the GROM access problem

.......

 

But there is a problem here: the cicuitery that generates this holding signal is fairly complex (two 74LS138, and two 74LS03). As a result, it takes time for SysRdy to go low after A15 has toggled. If we remove wait state #4, the request for a hold actually arrives too late for the CPU to take it into account. The situation is even worse with zero-wait-states timing, where there is no way the signal can get there in time."

 

According to my understanding one wait state after A15 toggles LOW is all that is ever provided by the circuitry around the 74LS194 (wait state generator).

 

HH

Link to comment
Share on other sites

 

Why do you need a wait-state for VDP access?

Oh, it was a long time ago I designed this memory expansion. I'm not sure without checking, but I have a feeling that it was setting up the address to the VDP that required a wait, if you didn't have any operation between sending the two bytes. TI does advice that you should do a NOP or SWPB or whatever in between, but some programmers realized that with the wait-state hampered execution in a stock TI, you could remove that instruction. Then it fails if both workspace and code are in fast RAM.

I've not encountered any program that has a problem with sound or speech or anything else but VDP access.

 

I used CRU base address 0x0400, or >0400 if you prefer the TI notation, for the memory bank switching. There are 8 bits used to select the RAM banks to switch in RAM over ROM etc., and switch out the internal RAM over the normal expansion RAM.

When using the normal expansion RAM, the wait states are as usual.

 

No, I have 7 bits available for memory bank switching, because I have one bit that enables the hardware wait state for the VDP as well. Normally it's off. I don't remember now exactly how tight I decoded the VDP address for inserting the wait, and I don't remember exactly how long I made that wait either. I'd have to check the documentation I made.

 

The RAM that's overlaying other memory areas doesn't provied write-through. I thought there was a risk it would cause issues in a machine that has quite a lot of memory mapped devices, including memory bank switching in some modules and so. So if I want to modify the machine ROM, the easiest and most efficient method is like this.

  1. Enable RAM in DSR space (>4000).
  2. Copy ROM >0000 - >1FFF to >4000 - >5FFF.
  3. Enable RAM at ROM space (>0000).
  4. Copy RAM block at >4000 to >0000.
  5. Disable RAM over DSR space.

Now I can start writing to the "ROM", as it's actually in RAM. Hence interrupt vectors and such things can be modified. There's no speed penalty, since this RAM is as fast as ROM at that location.

 

One could imagine expanding this idea to include 16 CRU bits, and thus be able to control things a little better. One could imagine being able to switch in RAM only at >8000 - >83FF, not the entire block with all memory mapped I/O, have more granularity than 8 K blocks, add LED visible from the outside to show some interesting status about how memory is configured or whatever. But there's not too much space inside, as long as you piggyback everything on existing circuits.

Edited by apersson850
  • Like 2
Link to comment
Share on other sites

From testing on faster systems, I'm pretty sure the only place the VDP needs wait states is when accessing VRAM, which makes sense since the VDP needs to wait for an access slot. Register access (including address register) seems to be fine, at least up to a 3.5 MHz Z80 ;)

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...