• Please review our updated Terms and Rules here

GRiD 1530 Becomes unresponsive after idling for 30 seconds?

0xDEADBEEF said:
So it was DNS after all? I mean RAM ;-)
Click to expand...
0xDEADBEEF said:
interesting, toshiba again? is there some weird timing issue on toshiba or something?
Click to expand...
eswan is the one that posted earlier that he had fixed his problem by replacing Toshiba RAM, not me. I haven't had the opportunity to do that yet for the same reasons mentioned before (namely that I don't have any others to test without ordering parts and building a set with other possibly incompatible RAM chips or doing more risky desoldering of ICs on the one original set I have).

I am suspicious of the Toshiba DRAM having a timing incompatibility of some sort though, which is why I posted about the datasheets earlier. The RAM itself really does not seem to be bad\defective. It has passed multiple passes of multiple types of memory tests (memtest, Checkit, GRID, conventional, extended, etc.).

I don't really have much knowledge of the inner workings of DRAM chips but I will look through the datasheets to see if any specific differences jump out at me. Now that I can see exactly which ones eswan used I have some more data to compare. If I can find some clear difference between the toshiba chips and the ones that work then I will try to find 8 chips that I currently own which are more like the originals and swap those out. I am willing to give that a try since it has a chance of fixing the problem AND actually leaving me with 4MB of RAM as I had intended.

I really do hope this is the solution, because the alternative is trying to fix the "black box" that is the motherboard.

EDIT: By the way, if anyone who has 1Mbyte SIPPs working properly in a 1530 has some time to pull one out and show us exactly what chips are being used that would be a big help. Please let it sit idle for 30+ seconds first to be sure it doesn't actually have this problem, lol.
 
Last edited:
Okay. I did some more digging and went back to the idea that maybe the system does go into an "idle" state and reduced memory refreshes when it isn't active.

For those that want to read it, I was able to dig up a bunch of information using an AI tool. I have no idea if it is all hallucinated or not, but it seems pretty logical and it builds on what 0xDEADBEEF and one or two others said several days ago. It is a bit frustrating when there are good suggestions brought up and others say "no, it doesn't work that way" , when it fact, it might work that way. I am comfortable doing a deep dive into this stuff, but I am not an expert by any means. I am here to learn about these things and fix problems, so if someone makes a good suggestion ("it is memory"; "dram refresh is slowed at idle", etc.) and others shoot it down it is very hard to know who is correct or what is worth following up on (especially in this case where I have no easy way to test the machine with different memory).

Anyway, for those interested, here is the "discussion" or whatever you want to call it.

I will summarize the idea very quickly.

The idea is that if the system has some kind of rudimentary power saving features that reduce memory refreshes at idle, then it could simply not be refreshing enough rows (per chip) fast enough at idle for the memory to avoid bit rot. The original configuration could handle it because there was less memory to refresh per chip, per cycle. Now, without a way to tell the system that something has changed and that the more dense memory chips need more\faster refreshes to stay stable, memory is getting corrupted once the refreshes are slowed down and results in immediate instability once it is read or accessed again.

Don't ask me to explain it, I am just interpreting what I read and I'm sure some of my wording is off. Check the link above for more detail... Like I said, it could be a stupid AI hallucination, or it could be accurate.

A possible solution would be to find "Low Power" memory that is intended for these exact situations and usually has a significantly longer refresh interval. I am currently looking through my stash to determine if anything I have qualifies. It looks like they tend to have an L in the suffix, but this is fairly general. Across various manufacturers "J" refers to SOJ, while "S" seems to refer to a different sized SOJ package... I don't think it ever refers to "Self Refresh" during this era.

It would be very helpful at this point to see the 1Mbyte SIPPs that people are using their GRID systems of this era. It could reveal a lot about what these systems are intended to be equipped with.

EDIT: Looks like the Faraday FE3010B specifically mentions "refresh circuitry for 256K or 1MB DRAMs" . So I'm guessing there must be some way to select this manually? This *has* to be what is going on. I have not yet figured out what controls this.

 
Last edited:
The service manual mentions jumpering J3 when using four SIPPs, but I don't have a J3 anywhere.

1530mem_config (Custom).png

It is not right below the memory slots like on the other 1530 board pictured in another thread. Regardless, I have not changed the number of SIPPs and it said it would be needed for a set of four 256K or 1M , so I don't think this particular jumper is an issue.

I don't see any jumpers anywhere on the board other than J5 near the BIOS chips (pulling it results in a beep code B_BBB_BBB and no POST), and unsoldered positions for J4 near the BIOS chips, J6 near the big LSI Logic chip and a very well hidden J400 near the right edge of the keyboard headers. I have tried poking around the board a bit to discern where J4, J6 and J400 go but haven't come up with anything yet. I might have to remove the board from the case again. -_-
 
Last edited:
older 1520 board revisions supported only 256KB SIPPs. i think the jumper you remove tells the board it should expect 8 SIPPs according to the manual?
the unsoldered jumper next to bios chips is to connect eprom address line to the bus to support 64KB BIOS, see my post about adding xtide.
as for slow refresh. i dont think that is the problem, the refresh circuitry doesnt care much about ram sizes because it goes through whole pages. it just activates the ram pages using RAS/CAS and refreshes whole page at a time when it is activated?

it is possible the toshiba chips you are using just have timings weird/marginal enough that the chipset doesnt like them or the refresh is too slow for them?
 
0xDEADBEEF said:
older 1520 board revisions supported only 256KB SIPPs. i think the jumper you remove tells the board it should expect 8 SIPPs according to the manual?
the unsoldered jumper next to bios chips is to connect eprom address line to the bus to support 64KB BIOS, see my post about adding xtide.
Click to expand...
It is very hard to know what jumper is what when there are so many different versions of the boards and the 1520 and 1530 have mostly the same documentation (at least what is available online), despite having very different layouts and component\jumper numbering.

0xDEADBEEF said:
as for slow refresh. i dont think that is the problem, the refresh circuitry doesnt care much about ram sizes because it goes through whole pages. it just activates the ram pages using RAS/CAS and refreshes whole page at a time when it is activated?
Click to expand...
0xDEADBEEF said:
it is possible the toshiba chips you are using just have timings weird/marginal enough that the chipset doesnt like them or the refresh is too slow for them?
Click to expand...
Sorry, I'm a little confused because these statements seem contradictory. That is basically what this post was about. Of particular interest is the note in the FE3010B's datasheet about "refresh circuitry for 256K or 1MB DRAMs" .

I really appreciate your help BTW. I have had this system on my workbench for MONTHS now and I feel like we're getting close. I still can't say 100% that it is memory causing both of the issues I'm experiencing at this point, but after hearing eswan's experience and reading some of this extra information it is definitely feeling like the best lead I have. I still believe that the memory is not "bad" per-se, but I'm sorry that I didn't focus on that when you had initially suggested it. It is hard to know what do when there are conflicting suggestions from people who likely all know more than I do about these systems.
 
Last edited:
If it's any consolation, mine has been apart for around 8 years. It's this thread, the xtide one, and the stopped posting one that have motivated me to get it running again.


Attached are the NEC 41256 and Toshiba TC514400J datasheets.
 

Attachments

what i mean i dont think the chipset switches between fast/slow refresh modes. there may be a config register for refresh timings though. we would have to look in bios disassembly if it ever gets programmed.
 
Okay, one thing I have determined is that memory chips with an L suffix for Low Power (usually with longer refresh intervals, like 128 ms) are quite uncommon. I have a pretty decently large collection of 30pin and 72pin SIMMs that I have been building for 25+ years and I found a grand total of one pair of 72pin modules (32 chips total), one set of four 30pin modules (8 chips total) and one partial set of three 30 pin modules (6 chips total).

The 72pin SIMMs are double sided with eight Hitachi HM5144ALS-60 chips on each side.

The set of four 30PIN SIMMs each have two Fujitsu MB814400A-70L chips, plus parity. As a side note, it is annoying how Fujitsu did not print their full product codes on most chips back then. If you don't remember to put MB ahead of the number they do not come up in searches online.

The partial set of three 30pin SIMMs each have Toshiba TC514400ASJL-70 chips (see page 412 of the PDF). The fact that I found these with one missing is really unfortunate because these would have been the perfect test to figure out if it was JUST the low power and\or refresh interval aspect that was the problem. They are otherwise identical to the chips that both eswan and I have tried that do not work correctly.

It was an easy choice to sacrifice a single unpaired module to do the upgrade the first time a month ago... but I hate to have to use or break up whole sets of RAM. I will probably use one of the 72pin modules. Having enough chips for four 4MB sets of RAM chips that may be compatible with extra-picky systems like this is arguably more useful than having one 16MB set of low power 72pin RAM that is unlikely to ever end up in a system that needs it. I'm sure there are mobile systems out there that use 72pin SIMMs that need to be low power, but they are probably even less common than GRiD systems.

0xDEADBEEF said:
what i mean i dont think the chipset switches between fast/slow refresh modes. there may be a config register for refresh timings though. we would have to look in bios disassembly if it ever gets programmed.
Click to expand...
That would be very interesting. Determining what registers to mod in a BIOS is way outside my skillset, but if anyone ever figures that out I would be interested to see the result. It could make a good addition to RomBuster's GRID 1530 mods.
Istarian said:

TC514400J/Z-80
TC514400J/Z-10

A-271 (pdf pg. 306/730)

1Mx4 is also called 4M where M stands for Megabit.

The line in the table of contents/parts list suggested the datasheet was originally issue in October 1989 (10-89).

-----

Also,


MB81C4256-70/-80/-10/-12

pg. 382/618 (PDF), 2-187 (document page numbering)

The MB81C4256A is in there too, as are the ones ending in L (low power?).

EDIT

Evidently J, Z refer to the package type where J means SOJ and Z means ZIP.

I suspect the A just signifies a different speed class, not unlike the Z80A and Z80B having different maximum clock speeds.
Click to expand...
I forgot to thank you for digging these up earlier. I am familiar with bitsavers but I am used to documents from there just popping up in google searches. These databooks did not come up when I searched, so I may not have found them if you hadn't posted them. Those are extremely helpful to have. :)
 
Last edited:
i had a great plan for converting bunch of SIMMs to SIPPs using the pins i bought at digikey. so finally i got inspired by this thread to do it. i converted one set of 1MB SIMMs that used Samsung 4+4+1 chips.
take a wild guess what happens if i leave it running for like 30 seconds?
also, if i run my refresh utility in the background it keeps on working.
but it did hang in dos or volkov commander idle loop.

so here are some theories.
a) the chipset does not like 4+4(+1) ram configurat ion and fails to refresh it
b) the chipset does not like fast 60/70ns ram and it loses it contents because the refresh is too slow? but i just tried a little tool that programs 2x faster refresh rate and it didnt help.
 

Attachments

  • samsungram.jpg
    samsungram.jpg
    638.6 KB · Views: 2
0xDEADBEEF said:
i had a great plan for converting bunch of SIMMs to SIPPs using the pins i bought at digikey. so finally i got inspired by this thread to do it. i converted one set of 1MB SIMMs that used Samsung 4+4+1 chips.
take a wild guess what happens if i leave it running for like 30 seconds?
also, if i run my refresh utility in the background it keeps on working.
but it did hang in dos or volkov commander idle loop.

so here are some theories.
a) the chipset does not like 4+4(+1) ram configurat ion and fails to refresh it
b) the chipset does not like fast 60/70ns ram and it loses it contents because the refresh is too slow? but i just tried a little tool that programs 2x faster refresh rate and it didnt help.
Click to expand...
Wow, thanks for going ahead and converting some SIMMs to SIPPs. That is good to know.

Possibly the most important bit of info here is that those are using KM44C1000ALJ-70 chips, with the L indicating low power. According to the databook (page 201 of the PDF), these are in fact low power chips with a refresh interval of 128ms. So... BLEH. I would have expected those to work.

One thing I am noticing though is that the parity chips are not L variants, and have a standard 512cycle/8ms interval refresh. I would not rule out having a higher supported refresh interval as the solution until we try using memory that has all Low Power ICs (with a high refresh interval). If you have a heat gun it would probably take a matter of minutes to remove them and the 1530 will likely not care at all whether they are there or not.

Running these without the non-L parity chips would be 100% confirmation of whether this can be fixed just by using low power DRAM chips or if the problem lies elsewhere.
 
Last edited:
Parity is handled by pins 26, 28, and 29. Could just leave those pins off.

I'm trying to come up with a sipp -> extension -> simm socket adapter, raising the sockets above the leds and video board. Tried pin headers, but the pins are too big to fit the sipp sockets and each other. That would allow testing simms before permanently modifying them.
 
so, perusing claude and gemini, points to interesting difference between 4M and 1M chips
do 1Mx4 and 1Mx1 FPM chips from late 80s use different refresh timings?

Yes, they can differ — and the key is that data width doesn't determine refresh requirements, internal row organization does.

1Mx1 (1Mbit total) Organized as roughly 512 rows × 2048 columns internally (10-bit row address is common). JEDEC standardized these at 512 refresh cycles per 8ms refresh period. Some earlier versions used 4ms periods.

1Mx4 (4Mbit total) Same number of addressable locations (1M), but the chip stores 4× the bits. To do that, the array is physically larger — typically 1024 rows, so the controller needs 1024 RAS cycles per refresh period (still usually 8ms). Some later 1Mx4 parts pushed to 4096-cycle / 64ms schemes but that's more early-90s.

So the period (8ms) is often the same, but the number of refresh strobes required within that window is doubled for the 1Mx4. A memory controller designed for 1Mx1 that only issues 512 refresh cycles per 8ms will leave half the rows in a 1Mx4 unrefreshed — corruption at room temperature, faster failures when warm.
Click to expand...

so, unfortunately, this points to 4M chips being fundamentally incompatible with faraday chipset. which sucks because they are used in low profile SIMMs which are possible to convert to SIPPs that would fit in gridcase. i have a collection of 9 chip SIPPs that are all too tall to under the cover. ;(
 
0xDEADBEEF said:
so, perusing claude and gemini, points to interesting difference between 4M and 1M chips


so, unfortunately, this points to 4M chips being fundamentally incompatible with faraday chipset. which sucks because they are used in low profile SIMMs which are possible to convert to SIPPs that would fit in gridcase. i have a collection of 9 chip SIPPs that are all too tall to under the cover. ;(
Click to expand...
Ah... that is unfortunate if true. I won't rule it out completely without more input from people that have systems with 4MB or 8MB of RAM though. We really need some people to tell us what RAM they have in their machines (with the DRAM chip part numbers and quantity, please). Hopefully we can get some more input on that from other 1530 owners.

Also, it makes more sense now that the FE3010B's datasheet says "refresh circuitry for 256K or 1MB DRAMs" . They are referring to Kbits and Mbits, and are referring specifically to the ICs, not the modules... which makes sense but wasn't really obvious to me until now because of their incorrect (outdated?) use of the capital B when clearly talking about megabits. The 256Kbyte SIPP that eswan showed earlier used 8 DRAMs, so those are 256Kbits each. The datasheet is saying that it supports either that 8 x 256Kbit configuration, 2 x 1Mbit (128KByte) or 8 x 1Mbit (1MByte). I wonder if anyone has ever tried using 2 x 256Kbit SIPPs to downgrade these to 256KBytes of RAM... it would probably work, heh.

Still... it is odd that the systems work mostly fine and have no problem running extended memory tests. Maybe it is because those tests only ever change small amounts of memory at one time so the refresh limitations of the chipset aren't a problem? I have absolutely no idea how this would work, but it could explain why I get crashing and errors when mashing repeatedly on specific keys too... it could be tripping up different parts of the memory that aren't always being refreshed properly with each other. Just a guess... I have no idea what I'm talking about. lol
 
Last edited:
using memory refreshes it. thats why my refresh.com helps. it does software memory refresh.
 
I was worried that it was a problem with Fast Page Mode ram, but Ozzuneoj's original 256k sticks look to be FPM and are 2 256x4 chips. I seem to remember seeing some systems that required 9 or 8 chip simms.
 
Last edited:
Well... I think I am going to admit defeat on this one now that we have basically figured it out. Unless someone chimes in and shows that they have 4Mbit DRAM chips working in a 1530, I will just accept that my machine is going to be limited to 1MB RAM for the foreseeable future. I kept the original chips so it shouldn't be too hard to just put them back on if that is the only way they are ever going to be usable. I just kind of wish I had back all the hours I spent screwing around with this (or not having my workbench) over the past two months... though, admitedly, a good portion of that was spent fighting with storage issues that were unrelated to memory and have since been resolved.

If it is possible to make a note of this 4Mbit DRAM chip incompatibility somewhere so that people don't waste time attempting this in the future, that would probably be good.

Someone with the proper knowledge could pretty easily design a modern 8 x 1Mbit PCB design that will fit these systems without having to be cut down. It is so easy and cheap to get a tiny and simple PCB like this made from PCBWay or JLCPCB these days, this is a perfect candidate for such a project (though people would have to source their own pins and chips, of course).

If anyone has a set of 100% working GRiD compatible SIPPs with 8 x 1Mbit chips each, it would probably massively increase the chances of this happening if we could get PCB shots of both sides with the chips removed. I know that is a stretch, but it's worth throwing out there. We might need to know the values of whatever caps are on them too.

I don't know if the 8 x 256Kbit SIPPs would work to just swap 1Mbit chips to (or to use them as a PCB design reference) since they could be missing a line that is needed to address 1Mbit chips.
 
I must say, I have found Claude to be very good at breaking this stuff down since I don't have a great grasp of how memory works.

***(me) What if the memory that was supported use 8 x 1Mbit chips rather than 2 x 4Mbit chips? Is it possible that it cannot refresh the 4Mbit chips but it can refresh the larger quantity of 1Mbit chips per module?
2:32 AM




That's a really elegant insight — and it's entirely plausible.

The key distinction

With 8x 1Mbit (256Kx4) chips, each individual chip only has 512 rows, so a 512-cycle refresh counter covers them completely. The total memory capacity is the same 4MB, but achieved through more numerous, simpler chips rather than fewer, denser ones.

If the Faraday chipset's refresh counter is a 512-cycle design, it would:

  • Perfectly refresh 8x 256Kx4 chips — every row of every chip gets hit
  • Only half-refresh 2x 1Mx4 chips — the upper 512 rows of each chip never get a refresh cycle
This would be completely invisible to GRiD's engineers if they only ever tested with 256Kx4-based modules. The chipset would work flawlessly with the original design, and nobody would ever discover the 4Mbit incompatibility unless someone later tried to upgrade using denser chips.

This also fits the timeline perfectly

  • 256Kx4 chips were the natural choice for a 4MB module designed around 1989-1990
  • 1Mx4 chips were newer and more expensive at that point
  • By the time 1Mx4 chips became the cheap commodity option for upgrades, the GRiDCase 1530 was already obsolete
This would mean your problem has no software fix — disabling suspend wouldn't help if the refresh counter simply never reaches row 512 and above. The only solutions would be finding original GRiD modules using 256Kx4 chips, or somehow confirming whether your symptoms occur during normal operation or only on suspend.

Have you actually tested whether the upper portion of RAM is reliable during normal operation, outside of any suspend cycle?
Click to expand...

I even threw in some discussion of the odd crashes I get when I repeatedly press certain keys (while others never cause it to crash) and it helped to make sense of that too. After a somewhat lengthy discussion including with the most recent info we've gathered in this thread, this was where the conversation ended:

***(me) Are you sure about the memtest86 testing being an indicator that the 1024-row refresh is working? If that was the case, is there any other possible way that the keyboard interrupts\addresses could be corrupted by the refresh being too slow?
2:49 AM




You're absolutely right to challenge that — I was too confident. Let me think through it more carefully.

Why Memtest86 passing doesn't confirm 1024-row refresh

Memtest86 is a very active, CPU-intensive test. While it's running:

  • The CPU is continuously accessing memory at full speed
  • The memory bus is constantly active
  • The system is very unlikely to enter any power-saving or reduced-clock state
In other words, Memtest86 inadvertently prevents the exact condition that causes the failure. It's testing memory under the best possible refresh conditions, not the idle conditions that cause corruption. It's almost the worst possible tool for detecting a suspend/idle refresh problem, despite being excellent for detecting genuine chip faults.

So the 1024-row question is actually still open

The chipset might only be issuing 512 refresh cycles, with the upper half of each chip never being refreshed even during normal operation — but Memtest86 would still pass because it's accessing memory fast enough that the capacitor charge doesn't decay significantly between accesses. Normal memory reads and writes incidentally refresh rows as a side effect.

Which brings us back to the keyboard crashes

If the upper rows of RAM are never properly refreshed during normal idle operation, then:

  • BIOS keyboard handler lookup tables sitting in upper memory regions could be corrupt
  • Specific key scan codes that reference those corrupted addresses would crash consistently
  • Keys whose handler addresses fall in the reliably-refreshed lower rows would work fine every time
This actually makes the 512-row counter theory uncomfortably plausible again — and would mean L-suffix chips alone wouldn't solve it.




***(me) Okay, I will probably just replace the 4Mbit chips with the original 256Kbit chips and be content with 1MB of RAM. It is plenty for CGA games. :)
2:51 AM




That's a very pragmatic conclusion! And it neatly closes the loop on your original question about CGA games and memory — as we discussed, essentially no CGA games need more than 1MB anyway, so you're not giving up anything useful for your intended purpose.

And you've contributed something useful in the process

The diagnostic journey you've been through — combined with the other users' experiences — has actually built a fairly solid body of evidence about 4Mbit DRAM compatibility with the GRiDCase 1530 that didn't seem to be well documented before. The key findings:

  • Standard non-L 4Mbit modules crash reliably
  • The crash mechanism is likely refresh-related but the exact cause (suspend throttling vs 512-row counter limit) remains unconfirmed
  • Memtest86 is not a valid diagnostic for this class of problem
  • The parity chip is not required
  • L-suffix modules with non-L parity also crash
  • The system works correctly with its original 256Kx4 chips
That's genuinely useful information for anyone else trying to upgrade a GRiDCase 1530, and the fact that philip-searle.me.uk is already archiving GRiD documentation suggests there's a community that would appreciate having this documented somewhere.

Enjoy your CGA games! The GRiDCase is a fascinating machine to be keeping alive.
Click to expand...

Seems pretty on-point and logical.
 
eswan said:
And probably why the memory tests pass.
What were the original GRiD supplied 1 meg sticks?
Click to expand...
very low profile 9*1Mbit chips with the pin on the backside, so they are only as high as the memory chip length. very tightly packed, siemens/hynix memory.

as for designining your own memory. these are as simple as they can be. just bunch of wires between the pins and chips. i dont know kicad though but it is doable.
now going back to soldering 500 ram chips on sgi o2 memory modules sdz designed recently ... https://sdz-mods.com/index.php/2026/01/15/sgi-o2-128mb-dram-module/
purple ram and anothed dude have 30 pin simms so it is doable
 
Last edited:
You must log in or register to reply here.
Back
Top