• Please review our updated Terms and Rules here

GRiD 1530 Becomes unresponsive after idling for 30 seconds?

0xDEADBEEF said:
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
Click to expand...
Just curious, do you have any interest in trying your Samsung memory without the parity chip? I know we're quite confident at this point that it is just a matter of the chipset not supporting the 1024-row refresh required to properly use 4Mbit DRAM chips... but that parity chip not being a low power module really sticks in my brain.

I think it would really help to solidify these findings and to 100% rule out any issues related to refresh intervals.

No pressure, it would just be far quicker and easier for you to pull 4 chips and then test again than it would be for me to desolder 8 L-suffix chips from a donor, desolder the 8 chips currently on my SIPPs, solder the 8 L-suffix chips, test (and likely have it not fix anything), then have to desolder them yet again and then solder the original 256Kbit chips back in.

My brain would love to have closure on this particular aspect if you have time. :)
 
Last edited:
the parity doesnt matter, if there was any problem with parity we would get an NMI
the L mode ram has probably self refresh so it can be put in low power mode with cas/ras asserted together and refreshing internally while machine sleeps.
 
0xDEADBEEF said:
the parity doesnt matter, if there was any problem with parity we would get an NMI
the L mode ram has probably self refresh so it can be put in low power mode with cas/ras asserted together and refreshing internally while machine sleeps.
Click to expand...
I am not familiar with parity errors or what an NMI looks like, so after a bit of research I am inclined to agree with you. If it was just the parity chip causing problems it would (should?) display a parity related message and the system would freeze after that. It should not cause the system to just freeze with no error messages.

Regarding self refresh though, I have looked into that and I can't find anything about self refreshing DRAM being a thing before SDRAM other than something about PSRAM, which I don't think is relevant. The Low Power chips seem to just be built to hold charge for longer between refreshes to accommodate systems that refresh less often to save power. They can't refresh on their own or hold it forever, though the 128ms interval is effectively forever compared to 8ms or 16ms.

But, yeah, Low Power DRAM features seem to be irrelevant if the system isn't even built to properly refresh full 4Mbit DRAM chips in the first place.

I will consider the issue solved then unless someone can show a 1530 not freezing with 4Mbit DRAM chips installed.

Thanks again for all your help, testing and research. I will make sure to post back here once I've had time to downgrade my system back to 1MB. I'm hoping it all works perfectly after that so I can finally get it off my workbench...
 
0xDEADBEEF said:
i think the issue will be solved when all my gridcases have 8mb ram each ;-)
Click to expand...
Fair enough! :D

If you end up making a design that people can use to order some blank PCBs I would probably add it to my list of future projects to build, because maxing out the RAM in something like this would be cool, even if it is totally unnecessary.

At the moment I don't think I'm going to need more than 1MB on this thing considering the video limitations and the CPU only running at 12.5Mhz rather than 16Mhz. I will put lots of CGA and monochrome capable games on it to tinker with, but I doubt any of those will need more RAM. Also, since Windows 3.x apparently doesn't work well (or at all) in Enhanced mode on this I would probably also opt for some older version of Windows or some other OS\shell to tinker with. So, for me, the requirements will be low.
 
Last edited:
Oh my...

Well, I just reinstalled the original chips onto the SIPPs to bring the system back down to 1MByte of RAM. The 30 second freeze is now fixed, as expected. However, the crash caused by repeatedly using certain keys on the keyboard remains. You can read about this problem here.

I am at a loss...

I will try reverting to the original BIOS and hard drive to see if this problem goes away. If it does, then this entire upgrade project has been a complete waste of time.
 
I wouldn't call it a complete waste of time. If nothing else you've satisfied your curiosity on the matter and now have a clearer sense of what the limits/requirements are for upgrading.

-----

Kinda random, but in principle you could do something like crazy like add a memory mapped device in there...

E.g. a self-refreshing ramdisk made with whatever ram you want, accessed via a small window of memory

The the only thing that really needs to be timing compatible there is whatever interface circuitry you come up with.
 
Well, I put the original BIOS and hard drive back in and it doesn't freeze up when pressing certain keys anymore. What a weird problem. 😵

EDIT: Okay... hmm. When booting from a DOS 6.22 floppy, even with the modded BIOS and the CF card in place as C: drive it does not freeze up when pressing certain keys. Interestingly, it still doesn't do it even when I am at the C: prompt (after booting from floppy) and typing jibberish and pressing enter, so it doesn't seem to be CF card access that is causing the problem either.

So, this is an entirely separate problem from everything else that has been going on. This specific issue could just be software, though I don't know how since it is basically a bone-stock DOS 6.22 installation on the CF card.

Istarian said:
I wouldn't call it a complete waste of time. If nothing else you've satisfied your curiosity on the matter and now have a clearer sense of what the limits/requirements are for upgrading.
Click to expand...
Of course there is always that, but my goal was to upgrade the computer to make it slightly more useful. I have a hard time letting projects go and admitting defeat, so it is frustrating taking three months to learn that the limits of modernizing and upgrading a GRiDCase 1530 are currently: You can't, because they still don't work right with a modded BIOS to support CF cards, and there are currently no SIPP modules available to buy or to build that will work in these machines aside from ones that were pulled from other GRiD systems.

After owning this computer for ~5 years, my whole reason for starting down this path was reading about the BIOS mods that finally make the systems stable with CF cards.

And it seems odd that I've never found a single mention anywhere of these systems being limited to 256kbit and 1mbit DRAM chips. Apparently in 35+ years no one has tried upgrading the RAM in these with non-GRiD parts, or at least hasn't documented that you cannot use 4Mbit DRAM chips, therefor only GRiD memory will work in them (unless someone starts making custom PCB to replicate the original super compact 9x1mbit SIPPs).

It doesn't seem like others have reported issues with the modded BIOS so I am hopeful that I will be able to get DOS working reliably on the CF card at least. I really just want to be done with this so I can reassemble this poor thing, get it off my workbench and finish some other projects.

Istarian said:
Kinda random, but in principle you could do something like crazy like add a memory mapped device in there...

E.g. a self-refreshing ramdisk made with whatever ram you want, accessed via a small window of memory

The the only thing that really needs to be timing compatible there is whatever interface circuitry you come up with.
Click to expand...
Interesting idea. At this point, it is already back to 1MB of memory so that is what the machine will have for now.
 
Last edited:
Your difficulties with memory may ultimately just be a limitation of the chipset used in the Grid 1530.

"Refresh circuitry for 256K or 1 MB DRAMs" (page 1)

Memory refresh - Wikipedia

en.wikipedia.org en.wikipedia.org
https://downloads.reactivemicro.com/Electronics/DRAM/DRAM Refresh.pdf

Assuming the fundamental problem is with memory refresh and that the REFRESH.COM executable (earlier in topic) fixes it even part of the time,
it may be that the keyboard interrupt interferes with memory refresh causing loss of some of the memory contents.

It might be worth comparing whatever version of MS-DOS was shipped with the Grid (presumably a customized version) to a more generic version.
 
Istarian said:
Your difficulties with memory may ultimately just be a limitation of the chipset used in the Grid 1530.

"Refresh circuitry for 256K or 1 MB DRAMs" (page 1)

Memory refresh - Wikipedia

en.wikipedia.org en.wikipedia.org
https://downloads.reactivemicro.com/Electronics/DRAM/DRAM Refresh.pdf

Assuming the fundamental problem is with memory refresh and that the REFRESH.COM executable (earlier in topic) fixes it even part of the time,
it may be that the keyboard interrupt interferes with memory refresh causing loss of some of the memory contents.

It might be worth comparing whatever version of MS-DOS was shipped with the Grid (presumably a customized version) to a more generic version.
Click to expand...
The memory issue was resolved a few posts ago. I have the original memory chips soldered back on the SIPPs and it is working fine with 1MB of memory. I found that part of the datasheet the other day, but I didn't catch on to what they were saying since they erroneously said 1MB instead of 1Mb. I wrongly assumed they were talking about entire 1MByte sticks\modules, which is obviously incorrect now that we have evidence of them not working. And yes, that explains why it isn't compatible with 4Mbit chips.

As mentioned in my previous post, the keyboard input errors with certain keys are unrelated and don't happen when booting from a floppy. When I have time I will figure out what is causing it.
 
So did it just not work at all with the 4 Mbit chips?

I was under the impression that it was partially working, but you had issues.

Presumably you could get them to work, but you would need to add proper refresh circuitry and keep the refresh synchronized properly to avoid memory access contention.
 
Holy smokes, I figured out how to fix the problem with the system locking up when entering certain commands or pressing certain keys at the DOS prompt!

I had originally intended to run DOS 6.22 + Windows 3.11 on this system before reading about how it does not work properly with enhanced mode. So, I had a Windows directory on the hard drive but not being used. I have not once actually run win.com on this system.

Apparently, having PATH=C:\WINDOWS;C:\DOS in the autoexec.bat was causing DOS to look for and load "something" from the Windows folder. Doing so was causing the system to crash at seemingly random times when pressing certain keys (other keys would not do it). It was 100% repeatable by alternating "y" and "enter" at the command prompt repeatedly. Eventually, pressing enter would drop the cursor to a blank line below the prompt and the system would be unresponsive.

I have absolutely no idea what it was loading. I will say again, I am not loading windows or running win.com. himem.sys is disabled... absolutely everything is commented out in the config.sys and autoexec.bat files for testing. The ONLY thing that makes the keyboard related crashing return is leaving C:\WINDOWS in the PATH.

By leaving C:\WINDOWS out of the PATH, the system is 100% stable now.

Running mem /c showed no additional drivers or TSRs running regardless of the PATH setting. It looks like there might be a slight difference in free conventional memory depending on whether Windows is in the PATH or not, but I'm not 100% sure. I will investigate this later when I have more time.

This is an absolute mind-bender and I cannot fathom what would be going on here. I am glad it's fixed by simply removing Windows from the PATH, but if anyone has any idea what is going on here, please let me know.

(Also, to be clear, this has nothing to do with the memory issue, which would cause a hang after 30 seconds at idle. That happened even with a boot floppy. All of my findings regarding upgrading this 1530 to 4MB of RAM can be found in the last couple pages. I am done thinking about that memory issue now that we know what caused it.)
 
Last edited:
Further developments in the mystery freeze when executing commands:

1. It is not the Windows folder being in the PATH that causes it! Even just having two copies of the DOS folder does it. (PATH=C:\DOS2;C:\DOS)

2. I have noticed that the hard drive activity LED always stays on when it does this. (the 30 second memory issue happened whether the LED was lit or not, so I hadn't thought about it this time.)

3. After 20+ seconds it unfreezes! I guess I just never waited long enough to notice. (again, the previous issue was a permanent lock, so I hadn't noticed that this one would eventually unfreeze)

4. After doing it for a very very long time with the number 1 (hitting 1 and then enter at the prompt) it did it! So it isn't character specific after all. However, slashes \ / do not. This makes sense, because the system isn't even attempting to look for programs in the PATH that start with a slash.

So, this is making a lot more sense now. I am thinking that maybe the BIOS mod that is meant to stop the system from freezing during high speed disk access is not 100% fixing the problem. When the system has lots of files to look through (more than would be found in one DOS folder), it is creating lots of high speed disk accesses and is sometimes getting "stuck" somehow.

I also just flashed a freshly modded set of EVEN\ODD BIOS files to some different ROMs and it made no difference, so the mod should be applied properly.

I think it's time to bring this up in the thread about Rombuster.
 
Last edited:
You must log in or register to reply here.
Back
Top