GRiD 1530 Becomes unresponsive after idling for 30 seconds?

[Ozzuneoj]

This is a follow up to this thread since I have gotten far past getting the system to POST, and now have a new and very odd issue.

To start, here is what I have done to the system:

New RTC\Battery a few years back (it still works)
Replaced a blown tantalum and all RIFA caps in the removable power supply and reflowed cracked solder joints on power contacts
Replaced leaky\stinky Nichicon PC capacitor in removable power supply
Upgraded 1MB RAM to 4MB by replacing the ICs on the original SIPPs (passes memtest86 with no errors at all)
Added Intel 387DX 16Mhz co-processor
Modded BIOS as described here to improve CF card support and swapped 20MB Conner drive for 512MB "X-431" CF card using a single 6" IDE extension.
Replaced two electrolytic caps on drive backplane and reflowed all of the flat ribbon cable pins
Installed DOS 6.22 to CF card (c: sys) and then copied additional files for DOS 6.22 to drive
All tested programs seem to be working, scandisk passes, can copy hundreds of files at once without problems, etc.

The problem:
I can run programs and they seem to keep working as long as I keep interacting with the system. I can enter gibberish commands at the DOS prompt every second for 2-3 minutes straight, I can wait ~15 seconds between entering commands and it will keep working, but if I wait 30+ seconds without inputting anything it will immediately become unresponsive. The cursor will blink but the only thing I can do is flip the switch on the back to power the system down.

As mentioned in the other thread, I had been diagnosing other issues for a while and got basically all of them sorted out, but before putting the CF card back in I started noticing the unresponsive-system issue while using the stock BIOS and original 20MB hard drive. I was able to run a full scandisk on the hard drive and copy files over and over. After some long file copy operations or other things that I walked away from, I would come back to it being unresponsive. The cursor would be blinking but I could not type anything. One time I came back after a file copy and it responded to the first key press with a beep and showed a pi symbol at the DOS prompt... which I definitely didn't type with the keyboard. Then it was frozen and would beep each time I pressed a key.

So, it isn't the CF card or modded BIOS causing it to become unresponsive at idle since it was doing something similar with the hard drive and original BIOS.

I am planning to replace some more electrolytic capacitors, but I'm not real confident that this will help since all of the caps I have measured so far seem to measure right where they should be with regard to capacitance, ESR and dissipation factor.

If anyone has any suggestion as to what would cause a 1530 to get weird at idle, please let me know.

 

[NeXT]

If you are getting a blinking cursor, the system has not locked hard. This sounds like some sort of an event timer is going off and it softlocks the keyboard.

-What happens if you boot from a floppy disk and let it idle?

-What happens if you direct the prompt to the serial port and use an external terminal?

 

[Ozzuneoj]

If you are getting a blinking cursor, the system has not locked hard. This sounds like some sort of an event timer is going off and it softlocks the keyboard.

-What happens if you boot from a floppy disk and let it idle?

-What happens if you direct the prompt to the serial port and use an external terminal?

Thanks for the suggestions. It always will show a blinking cursor, but beyond that the behavior is a little inconsistent. It seems that most of the time it will eventually start beeping if I keep pressing keys while it is unresponsive. Other times it never beeps no matter how many keys I press. It also stopped responding once when Scandisk got to a point where it had to ask for my input. The scan had worked fine, but because I didn't get to it fast enough it wouldn't respond when I tried to confirm what it was asking me. Ctrl-alt-del did not reboot the system so I had to power it down that time too.

It's odd because I could probably do back-to-back-to-back scans for hours as long as I didn't let it sit there when it asked for my input.

The system is currently partially dismantled again but when I get a chance I will try booting from the floppy. I believe it still does it there but I haven't tested that in a few days.

I have never done anything with external terminals before, so I will have to look into how to do that.

Where would an event timer like this be set exactly? I had been thinking that it was some kind of keyboard locking or power saving thing, but I don't see any way to configure anything like that on these systems that would be independent of the OS since there is no BIOS configuration utility. The CF card has a clean DOS 6.22 install with nothing in the autoexec except for PATH and nothing in config.sys except for HIMEM. It also did it on the hard drive which is totally different installation of DOS and also has basically nothing in the autoexec or config.sys.

 

[NeXT]

It seems that most of the time it will eventually start beeping if I keep pressing keys while it is unresponsive. Other times it never beeps no matter how many keys I press.

Could still be softlocked, but in that case, the display is no longer updating and the beeps are the keyboard buffer overflowing.

Are you running any TSR's or any nonstandard drivers that might be clobbering themselves, or have you used one of those socket compatible 486 upgrades?

Where would an event timer like this be set exactly?

Not a configurable timer but a watchdog. Like how on the hard drive GRiDcase 3 after five seconds it auto-parks the head.

 

[Ozzuneoj]

Could still be softlocked, but in that case, the display is no longer updating and the beeps are the keyboard buffer overflowing.

Are you running any TSR's or any nonstandard drivers that might be clobbering themselves, or have you used one of those socket compatible 486 upgrades?

Not a configurable timer but a watchdog. Like how on the hard drive GRiDcase 3 after five seconds it auto-parks the head.

Okay, I just tested it by booting from a DOS 6.22 floppy and it does the same thing. It works, but after 30 seconds or so it stops responding to the keyboard. I continued pressing lots of keys and the speaker gave one really short beep, but not the usual "stop pushing keys, I'm busy..." beep... almost like it tried to do that but the next key press cut it short. And it only did it once. The cursor is still blinking but now it does not respond to key presses, even with beeps. It does not respond to Ctrl-Alt-Del. If I power it down and turn it back on it works fine until I let it sit again.

Since the autoexec and config.sys in all of these configurations are fresh and nearly empty, there aren't any TSRs or drivers being loaded.

It has the original 386 16Mhz CPU and the Intel 387 that I added recently. I can try taking that out, just in case.

 

[Ozzuneoj]

Alright, I took the 387 out and it did not change anything. I also checked to be sure the keyboard connectors were fully seated and they are.

I got out a stop watch to try to nail down the timing of it. I just left it at a DOS prompt and hit "1" then backspace each time. If it worked, I restarted the timer. I found the following.

After 10 seconds it was fine.
After 20 seconds it was fine.
After 29.5 seconds it was fine.
After 30.5 seconds it SEEMED to be fine, then after a couple characters the C:\> prompt disappeared and I was typing on the line where the prompt should be. Then after typing 10 or so characters it, it stopped responding and would beep when I pressed more keys. Eventually it stopped beeping and I had to shut it off.

So, it doesn't seem like intentional behavior, but the timing being so dead on at 30 seconds just seems strange.

Is there any kind of basic power saving built into this system? Even something very low-level, like it uses the RTC to wait for 30 seconds to pass and then it switches something off or does something to reduce power consumption?

If there isn't any hardware feature of the system that does that, then all I can think is that it is just the result of a failing component that just coincidentally causes issues at almost exactly 30 seconds every time. Sadly, I would have no clue where to start to diagnose that, aside from just replacing every last electrolytic capacitor and hoping it isn't a waste of time and caps.

EDIT: I will say, it is very repeatable, so it should be easy to tell once it is fixed. I just started the system, ran some commands, read some information on the screen, realized it had probably been over 30 seconds, hit a random key and it input a pi symbol at the prompt and then was no longer responding to input. Cursor was still blinking, no beeps.

EDIT2: I was looking a bit more at the capacitors on the motherboard and I saw a 47uf 20v one of these (C15) and had to look it up. This is actually my first time ever seeing a tantalum capacitor that looks like this. I thought it would be some ancient aluminum electrolytic, but I was wrong. In my experience, if a tantalum has lasted this long and didn't blow or short out when I first powered it on, it will probably last another 35 years.

I see there is another large-ish capacitor (C4) in the back left corner of the board that is wrapped in black and I can't identify it yet. Aside from that, I think that the lone 220uf 25v Nichicon VX (C47) is the only other aluminum electrolytic on the motherboard. There are plenty of them in the two power supplies though...

 

[nolan7]

I have very similar problem with one of my GRiDcase 3 computers for several years and I never found a solution. It works normally when I do something with it, but when I let it in a command prompt for a while, it gets stuck, just like yours. Cursor blinking, but no response on keystroke. Multiple keystrokes fill buffer and then it beeps. Only solution is power cycle. Inputs from keyboard keeps it alive, if they are frequent, but once I let it stay for a while, it gets stuck. I also thought it is a problem with some power saving feature. Strange. Must be something that is on both machines, GRiDcase 3 and also on 1530. It is something like 30 seconds, and if I remember correctly, in my case, that time interval is not always the same. Sometimes it stays alive longer, sometimes it freezes sooner. But it never stay alive for longer than maybe two minutes.

 

[Istarian]

If the problem is truly with a watchdog timer of some type, then it could be forcibly resetting the CPU somehow.

The important question is whether the problem is originating with the hardware or primarily a software issue.

-----

Since this happens consistently at the command prompt, perhaps the keyboard interrupt is involved?

Or maybe the issue is that the problem occurs while servicing an interrupt and leaves the system in a state where interrupts are disabled.

That could explain a system
that appears to be running, but is unresponsive to keyboard input.

 

[eswan]

Just tested my gridcase 3, ms-dos 2.11 booted from rom doesn't seem to have any problems after a half hour. The 3.5 doesn't seem to be able to read or write any of the 720k floppies I've thrown at it, so no way to test it currently with a different dos. My 1530 is throwing a kb controller error. I just discovered that my 1530 has a 720k Epson SMD-240 drive, which explains why I've never gotten it to boot from a 1.44 floppy.

Has anyone disected the grid MODE.COM command? I've heard that it controls the modem power, maybe it has some options for other power management.

 

[0xDEADBEEF]

I swear I had similar problems with my 1530 as well. I was convinced it was bad chipset or something. Then I tried the RAM I used in 1520 and it detected bad RAM at post. I tried different RAM on my 1530 and it worked fine afterwards. So maybe try different ram.

 

[Ozzuneoj]

Thanks for all the input everyone!

I'm relieved to hear that others have experienced this at least.

Sadly, I am not able to test it with any other RAM because these are the original SIPPs which I swapped the actual chips on to bring them from 1MB to 4MB total. RAM that fits into these machines is pretty tough to find.

I will say, it passes memtest86 fine... though I don't know how much that matters since it dies at idle rather than when it is actually doing something.

If I had four more sticks of RAM to test it with, I would absolutely do that just to rule out a RAM issue. If I had known this freezing at idle issue was a possibility I'd have definitely tested for it before I upgraded the RAM, but I honestly just don't know if it was doing that before or not.

The timing of the problem seems so consistent... Almost like there is an intentional 30 second timer that shouldn't even be noticeable but is causing something else to freak out due to a defect.

 

[0xDEADBEEF]

yeah, mine would totally die after idling a while in volkov commander or dos prompt.
i think idling may be worse when ram is not used actively because using ram refreshes it.
does your ram have parity?

 

[Plasma]

Seems like a watchdog problem to me. Maybe standard MS-DOS is missing some expected functionality. Does it also freeze when using GRiD OEM MS-DOS?

 

[nolan7]

I have several GRiDCASE 3 computers, and I tested them simultaneously. Only one of them exhibited this issue. I used the same floppy disks for all tests, so I assume the problem is hardware-related rather than software-related. I also own many other GRiD systems of different types, and only this particular GRiDCASE 3 has this problem. The fault appears to lie somewhere on the mainboard. I have swapped various components in an attempt to get as many units working as possible. While troubleshooting those problematic JVC hard drives, I believe I also tried swapping RAM and may have even tested it using a standalone RAM tester to rule out memory issues. However, I cannot confirm this with absolute certainty. Based on this, I suspect a hardware fault on the mainboard, but not in the RAM itself.

 

[daver2]

Does the board have a keyboard interface microcontroller, or is it built into a large chip somewhere?

If the machine continues to execute software, but becomes unresponsive to the keyboard, and you get a 'beep' after so many keypresses - then the main board has stopped processing keypresses and the keyboard is filling up it's buffer.

Something is temperature sensitive, and I would start at whatever device is supposed to be processing the keyboard codes.

Dave

 

[Ozzuneoj]

yeah, mine would totally die after idling a while in volkov commander or dos prompt.
i think idling may be worse when ram is not used actively because using ram refreshes it.
does your ram have parity?

No parity. The SIPPs originally just had two 128KB chips each, with nothing soldered in the parity position. I just swapped them out with 512KB chips since buying or making SIPPs that fit is a lot more expensive or a lot more work.

Seems like a watchdog problem to me. Maybe standard MS-DOS is missing some expected functionality. Does it also freeze when using GRiD OEM MS-DOS?

I will download that and give it a try. I don't think this is a software issue though. It seems like more people would report the problem if it was something that happened with non-GRiD DOS installations.

I have several GRiDCASE 3 computers, and I tested them simultaneously. Only one of them exhibited this issue. I used the same floppy disks for all tests, so I assume the problem is hardware-related rather than software-related. I also own many other GRiD systems of different types, and only this particular GRiDCASE 3 has this problem. The fault appears to lie somewhere on the mainboard. I have swapped various components in an attempt to get as many units working as possible. While troubleshooting those problematic JVC hard drives, I believe I also tried swapping RAM and may have even tested it using a standalone RAM tester to rule out memory issues. However, I cannot confirm this with absolute certainty. Based on this, I suspect a hardware fault on the mainboard, but not in the RAM itself.

That is very helpful info to have, thank you. I will take the board out and inspect it thoroughly when I get a chance.

Does the board have a keyboard interface microcontroller, or is it built into a large chip somewhere?

If the machine continues to execute software, but becomes unresponsive to the keyboard, and you get a 'beep' after so many keypresses - then the main board has stopped processing keypresses and the keyboard is filling up it's buffer.

Something is temperature sensitive, and I would start at whatever device is supposed to be processing the keyboard codes.

Dave

I believe the 1530 has a standard-ish looking keyboard controller, but I will have to check when I get some time.

Regarding it being temperature sensitive, it seems strange that I could mash on the keys forever and it will never have an issue, but leaving it sit for exactly 30 seconds causes it to stop processing keyboard codes.

I think you may be on the right track with regard to it being related to the keyboard controller though.

I have a thermal camera so I will try running it and looking for anything on the motherboard that seems unusually hot or unusually cold (dead). I'll also check the motherboard for cracked solder joints, and I'll replace the lone electrolytic cap on it while I'm at it.

 

[Ozzuneoj]

yeah, mine would totally die after idling a while in volkov commander or dos prompt.
i think idling may be worse when ram is not used actively because using ram refreshes it.
does your ram have parity?

I have several GRiDCASE 3 computers, and I tested them simultaneously. Only one of them exhibited this issue. I used the same floppy disks for all tests, so I assume the problem is hardware-related rather than software-related. I also own many other GRiD systems of different types, and only this particular GRiDCASE 3 has this problem. The fault appears to lie somewhere on the mainboard. I have swapped various components in an attempt to get as many units working as possible. While troubleshooting those problematic JVC hard drives, I believe I also tried swapping RAM and may have even tested it using a standalone RAM tester to rule out memory issues. However, I cannot confirm this with absolute certainty. Based on this, I suspect a hardware fault on the mainboard, but not in the RAM itself.

Sorry, I forgot to ask this in my last post and I can't edit it...

Can you guys describe any other hardware changes or updates you have made to the systems with the problem?

Did you replace electrolytic caps? If so, did you do specific ones (power supply boards, motherboard, etc.) or did you replace everything?

Did you replace the RTC? If so, what model did you use? I know that there can be compatible ones that have slight variations. I put a Dallas DS12887+ in mine back in 2020 and it seems to keep time quite well, but I won't rule out an incompatibility there. I really wish I could go back a month or so before I did any other work on the system to tell if it was freezing after 30 seconds then too.

Do you run the system with an internal (removable) power supply or an external AC\DC adapter?

Also, at any point did you guys try different IDE hard drives or CF cards, or do anything non-standard with the IDE interface? I had some issues (as described in the other thread) related to trying to extend the IDE connection using a cable (first attempts did not account for IDE cables flipping the top and bottom rows of pins from one end to the other, so the drives weren't connected properly... woops) and I'm hoping I didn't mess up some totally unrelated part of the board in the process. I doubt it since even the CF card is working great now... but you never know.

I have attached some pictures of the motherboard too for anyone interested. The keyboard controller is an Intel P8742AH. I have a TL866A programmer and a really old ART EPP-1, but I don't believe either of those would be much help if I wanted to program a new keyboard controller just to test.

 

[0xDEADBEEF]

there is no watchdog in gridcase 15xx
i dont remember i replaced rtc in this particular 1530. but it is not rtc. when it was hanging the screen was getting corrupted. in retrospect it was clearly memory issue. there are barely any caps on gridcase mobo and they are just 5v stabilization. i did recap all my power supplies.
anyway, my bet is you have bad memory. as for messing with bios, i did a lot, also irrelevant.
btw now mine is running cyrix 486drx2 just fine with good memory.

 

[Ozzuneoj]

Is there any chance that anyone in the US has a working set of 4 256K SIPPs for one of these that they'd want to part with?

At this point, I don't want to risk removing all of the chips I attached to the original ones to get them to 4MB. It seems strange that bad memory would cause the system to stop responding to keyboard inputs after exactly 30 seconds of idling, while having no problems passing extensive memory testing or playing games.

If I had one more set of RAM that fit I could find out if that was the problem without wasting a bunch of time and risking lifting a pad on the original SIPPs.

 

[Plasma]

I highly doubt it's bad memory. DRAM refresh runs constantly regardless of CPU activity.