Jump to content

Photo

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

Upgrade Memory expansion console

11 replies to this topic

#1 hhos OFFLINE  

hhos

    Space Invader

  • 45 posts

Posted Sun Jan 20, 2019 6:10 PM

 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....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. ;-)

 

 

Attached Files



#2 hhos OFFLINE  

hhos

    Space Invader

  • Topic Starter
  • 45 posts

Posted Mon Jan 21, 2019 5:15 PM

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

Attached Files



#3 apersson850 OFFLINE  

apersson850

    Dragonstomper

  • 569 posts

Posted Mon Jan 21, 2019 5:56 PM

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.



#4 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,606 posts
  • Location:Castaic, California

Posted Tue Jan 22, 2019 1:32 AM

...

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.



#5 hhos OFFLINE  

hhos

    Space Invader

  • Topic Starter
  • 45 posts

Posted Tue Jan 22, 2019 11:31 AM

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



#6 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,499 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jan 22, 2019 12:13 PM

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.

#7 hhos OFFLINE  

hhos

    Space Invader

  • Topic Starter
  • 45 posts

Posted Tue Jan 22, 2019 1:08 PM

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



#8 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,499 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jan 22, 2019 1:41 PM

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


In theory there is no difference between theory and practice, but in practice there is. ;)

#9 hhos OFFLINE  

hhos

    Space Invader

  • Topic Starter
  • 45 posts

Posted Tue Jan 22, 2019 2:37 PM

In theory there is no difference between theory and practice, but in practice there is. ;)

:ponder: :lol: :rolling:  :cool:



#10 apersson850 OFFLINE  

apersson850

    Dragonstomper

  • 569 posts

Posted Tue Jan 29, 2019 3:14 AM

 

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, Tue Jan 29, 2019 3:36 AM.


#11 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,499 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jan 29, 2019 1:25 PM

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 ;)

#12 apersson850 OFFLINE  

apersson850

    Dragonstomper

  • 569 posts

Posted Tue Jan 29, 2019 4:01 PM

Looking at my own documentation, it says "VDP read delay logic" on the block diagram of the memory expansion. The delay circuit is triggered each time the *CS VDP R signal (Chip Select Video Display Processor Read) goes true.







Also tagged with one or more of these keywords: Upgrade, Memory expansion, console

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users