• Please review our updated Terms and Rules here

Does a vintage system have a limit as to the fastest RAM access time it can use?

T-Squared

Veteran Member
Joined
May 29, 2011
Messages
657
Location
San Antonio, TX
I am working on restoring my Game Gear, and I seem to have zapped its SRAM by accident.

The system began giving me badly-placed tile images, and when I clipped out its video SRAM, it gave me gibberish. No biggie. Floating pads with no inputs? That's expected.

However, when I bought some new SRAM to replace it, it was as if the chip was never soldered on. It gave me the same gibberish as before.

I've read about RAM access time from YouTube user JoulesperCoulomb, with how he's repaired ZX Spectrum systems before.

The old chip's maximum access time was around the neighborhood of 150-100ns, and the new chip's maximum access time was 55ns.

Is there a limit to the maximum access ability of older systems, or did something permanently malfunction on my Game Gear?

I'm sorry if this isn't appropriate for this subforum, but it does have to do with memory, which is relevant to computer hardware.
 
The faster access time of the new chip does not make the system use the faster access time. It will use whatever access time it was designed to use. So the faster chip is simply driven slower as it could be. It will make no difference.

In some cases (DRAM mainly), it can cause issues but not because of the access time itself, but because faster RAM often uses more advanced designes like going from fast-page (e.g. 70ns) to EDO (60ns and faster), which a system may not support and refuse to work.
 
I have found that with some (very few though) video circuits that the access time of the video RAM is fairly critical. Too fast or too slow can cause problems. You need a 'goldilocks' chip...

In this case, however, I don't think it is a problem.

The access time is the time between the CPU/video controller requesting data and that data appearing (as valid) on the data bus. With normal SRAM - faster = better.

I suspect there may be a problem elsewhere.

What did you actually do to 'zap' the RAM in the first place?

Dave
 
According to a Game Gear tech site the part number for the original VRAM actually resolves to a Psuedo-Static device, which there only seems to be a partial datasheet floating around for, but from what’s in it I don’t see any deal-breakers for replacing it with a pin compatible 32KB SRAM. Faster is almost certainly better, actually, because the datasheet alludes to the original device having *two* effective access times, IE, the full ~100ns for “random” access, and ~55ns if sequential reads are on the same column, IE, it apparently invisibly supports something like fast page mode.

That last bit does worry me a *tiny* bit, IE, if there might be some proprietary twiddling of the control lines to signal those fast mode accesses. I *doubt* it, I’d think that would be an important point to emphasize in the datasheet and there’s no sign of it, but technically it doesn’t appear to be all there.(?)

But minus that tiny potential gotcha I would think it’d be fine, your SRAM is as fast as the ‘fast’ mode.
 
If it is anything like the Zilog Z6132 it could be set-up in 'dumb' mode resulting in a refresh after every memory access.

You could (however) 'optimise' this by setting 'clever' mode. This did result in more external logic - so it was only ever used for time-critical applications where the cost of the external logic was worth the speed improvement.

Dave
 
Yes. It can make a difference and not work. It all depends on the devices and the timing of the circuit. You may need to hook up a logic analyzer to get a full picture of what is happening. You may need to delay a signal a bit or some other timing tweaks to get it to work. I see this more often when trying to replace a .300" SRAM chip as so many are "cache RAM" types with speeds in the 10 to 25ns vs. 100 to 250ns of standard RAM.
 
There are two (2) parts in this particular computer. One is SRAM - and any speed 'should' work more often than not. The video RAM is pseudo-static - so you may have more problems with this.

Which actual device did you replace?

Dave
 
If it is anything like the Zilog Z6132 it could be set-up in 'dumb' mode resulting in a refresh after every memory access.

You could (however) 'optimise' this by setting 'clever' mode. This did result in more external logic - so it was only ever used for time-critical applications where the cost of the external logic was worth the speed improvement.

I found a more complete datasheet for the 65256BLFP, and it looks like it can run refresh completely on auto-pilot *or* you can externally trigger refreshes by cycling OE low while keeping CE high. (This is thing that would "just happen" in a lot of designs anyway if a shared bus READ signal was used directly on OE; any read targeted at device *not* the RAM chip would effectively do this.) It also has an explanation of the "Static Column" mode, which simply consists of holding OE low while cycling different values on A8-A14. (This is the case where the data-out will be valid in only half the time than it would be if the whole address was changed.)

Anyway, I'd have to see the datasheet for the SRAM that was substituted but off the top of my head I'd think even if the controller chip made use of the static column mode it shouldn't matter; most SRAMs are happy to run in an "address following" mode where they output continuously with the data being valid X-many NS after an address change; as long is "X" is as fast or faster than the 60ns that this amounts to for the 65256BLFP-12 in static column mode everything should be fine and dandy. Likewise, even if the controller in the device did some of the twiddling of CE/OE to adjust refresh cycles that's documented in the datasheet it looks to me like it would be activity a SRAM would just ignore.

That said, maybe my google-fu is failing me, but I'm having trouble explicitly finding a forum post or whatever where someone replaces it with a different part.
 
That is, apparently the Video SRAM chip's legs came into contact with the battery terminal solder points, because the graphics went bad (which I've seen on the failing memory of a vintage video card, so I recognize it), and when I felt the batteries afterwards, they were very warm, even through the plastic casing of the Game Gear.
 
That is, apparently the Video SRAM chip's legs came into contact with the battery terminal solder points, because the graphics went bad (which I've seen on the failing memory of a vintage video card, so I recognize it), and when I felt the batteries afterwards, they were very warm, even through the plastic casing of the Game Gear.

That doesn't sound good at all. It probably means that more devices could have died as well. Warm batteries usually indicate a high current. That high current was probably flowing through the input protection diodes on various ICs and could well have done damage to them all as a result of localised heating. Replacing the video RAM may be only a partial solution I am afraid.

Dave
 
From what (little) I know of the game gear architecture (long and short of I'm pretty sure its video chip is basically an enhanced TMS-9918) the VRAM is entirely a slave to the VDP, so I would think it pretty likely that if you did something to smoke the video memory you've probably also smoked the VDP.
 
Well, I got pulsing on the video RAM, at last check, with a logic probe. I know that probably is a weak argument, but it's not entirely dead.
 
Also, I think there's a chance, because before I clipped out the memory, what I got was extremely similar to this (Not my system):

407762_5faf9ee26abb4fc2b59baa79f22aa3db_mv2.png

Like I said, the entirety of the tiles looked very scrambled, not the entirety of the base graphics themselves. I did have some bad graphical corruption, but I did also see a few good tiles here and there that I could recognize, just repeated. (Like I did with an S3 Virge video card I put some bad J-Wing-Lead SMD/PLCC memory into.)

Also, I saw horizontal and vertical scrolling of corrupted graphics, so something has to be working...
 
Last edited:
If it is anything like the Zilog Z6132 it could be set-up in 'dumb' mode resulting in a refresh after every memory access.

So… I managed to find a service manual schematic for a game gear:


The schematic on page 8 shows how the VRAM is connected to the primary ASIC, and it has me wondering if I completely missed something in the datasheet for the original PSRAM that might be a deal breaker for subbing a SRAM?

Short version: what is with using the same I/O lines for A0-A6 (A7 is tied to ground, it only uses 16K?) as D0-D7? I’m squinting at the timing diagrams and I‘m starting to think this chip may latch A0-7 at the assertion of CE so the same lines can be multiplexed with data? If that the case I’m less confident any random SRAM chip is going to behave the same way.
 
I may have a GameGear mainboard in the scrap bin. I'll take a look in the next couple days. I don't know about the operational condition of any of the components, but I'd be willing to part with it if you need parts.
 
Good spot Eudi - that will screw everything up!

In fact, I forgot about that little gem on the Zilog Z6132 as well (the address bus is latched on the low/high transition of the address clock - AC)...

The Z6132 was designed to interface with a wide range of busses (including multiplexed address/data busses).

Dave
 
The Z6132 was designed to interface with a wide range of busses (including multiplexed address/data busses).

Yeah. The thing about this HM65256 part is the datasheet is *extremely* vague about this and the physical pinout is identical to the equivalent 32K SRAM part so other than the passing mention of that static column mode it's really easy to come away with the impression that's completely interchangable with a standard SRAM. (The Z6132 has special refresh chaining pin that's at least kind of a giveaway.) I think this theory holds water based on a reasonable interpretation of the timing diagram and the signal table but there's no actual paragraph text describing these behavioral differences.

If this is what's actually happening then unless there's an SRAM part that replicates this behavior you'll need an external address latch. (I have a bag of CY62256s in my parts drawer so I looked up the datasheet for that, and from what I can tell it has no such latching mode, data always directly follows address.)
 
Last edited:
Back
Top