kishy
Veteran Member
Between a friend and I, we have recently acquired several (somewhere between 3 and 8 once we reconcile what's damaged) EduQuest Thirty all-in-one computers. All of them except one are working (as in, POST, video out, boot, and accept input) but have various chassis damage.
There is one curious problem I've found that is common to all of them, and I'm wondering if anyone here has any useful commentary.
These units use a Dallas DS1287 RTC module. In order to get them to boot from the HDD (or even remember that it has one at all), settings must be adjusted in the (Phoenix) setup menu. Those settings are lost on the reboot after saving the settings, so a working RTC module is completely necessary to boot the unit from HDD.
Initially, I swapped in a DS12887 new-old-stock module I had, and found that the unit would not keep time. On power off, the calendar and clock would return to their default values, or close to them. I suspected maybe I had found one of the unusual cases where a 12887 cannot replace a 1287, so I dug through my things for a modded one, and put that in, and found the same thing.
Then, since I wasn't sure if my modded one might have also been a 12887, I modded one of the EduQuest original 1287s...and found the exact same thing.
So now this scenario is proven across many EduQuest motherboards, with several RTC modules of both 1287 and 12887 varieties, with multiple batteries. It's starting to look like this is intended functionality. The settings are being kept, just the clock and date are not.
All of these units had token ring cards installed, so some type of NTP implementation is not really out of reach. It's just odd that the RTC doesn't seem to do its most core function in these. I would prefer to have them internally managing their date and time, but I'm not sure how they were used in their previous lives without it.
Any thoughts, please?
There is one curious problem I've found that is common to all of them, and I'm wondering if anyone here has any useful commentary.
These units use a Dallas DS1287 RTC module. In order to get them to boot from the HDD (or even remember that it has one at all), settings must be adjusted in the (Phoenix) setup menu. Those settings are lost on the reboot after saving the settings, so a working RTC module is completely necessary to boot the unit from HDD.
Initially, I swapped in a DS12887 new-old-stock module I had, and found that the unit would not keep time. On power off, the calendar and clock would return to their default values, or close to them. I suspected maybe I had found one of the unusual cases where a 12887 cannot replace a 1287, so I dug through my things for a modded one, and put that in, and found the same thing.
Then, since I wasn't sure if my modded one might have also been a 12887, I modded one of the EduQuest original 1287s...and found the exact same thing.
So now this scenario is proven across many EduQuest motherboards, with several RTC modules of both 1287 and 12887 varieties, with multiple batteries. It's starting to look like this is intended functionality. The settings are being kept, just the clock and date are not.
All of these units had token ring cards installed, so some type of NTP implementation is not really out of reach. It's just odd that the RTC doesn't seem to do its most core function in these. I would prefer to have them internally managing their date and time, but I'm not sure how they were used in their previous lives without it.
Any thoughts, please?
Last edited: