Obtaining RTC Information From a 486
Many people tinker with vintage computers with much the same reason for climbing mountains — for the challenge and pleasure. Once in a while, traveling down the proverbial rabbit hole to absurdity is a bit of twisted fun. For example, attempting to programmatically collect RTC information with the 486 in the house network vintage computer collection. Specifically, wanting to know whether the RTC future date capacity is up to one day, month, or year.
The 486 BIOS and power supply do not support APM or ACPI. The BIOS has no power management features. Without APM or ACPI support the alarm feature can’t be used to self-awaken a system. Who knows what ways the alarm feature was used more than 30 years ago.
The dead tree documentation provides nominal clues. The 486 mainboard has a UM82C480 chip set. There are three chips in the set: a UM82C481 memory controller; a UM82C482 system controller; and a UM82C206 integrated peripheral controller, the latter of which is where the RTC is located. The documentation has a simple table listing the RTC address locations for alarm seconds, alarm minutes, and alarm hour. That information implies up to one day in the future.
Sleuthing around the web finds that the UM82C206 RTC is Motorola MC146818 compatible. The MC146818 could store one alarm up to one day. That seems to imply the UM82C206 RTC is limited to a 24 hour future date, but being compatible does not necessarily mean limited to.
Presuming a limit of one alarm up to one day seems sane considering the technology of the day. Many people might stop there and just say the mountain is beautiful.
So much for clues and presumptions. This is the rabbit hole where “curiouser and curiouser” is the general rule. Software from the vintage MS-DOS and Windows for Workgroups (WFWG) days leave a bit to be desired. In hindsight, software from that day unlikely would be designed to include that information. Can a Linux system software find this information?
Modern Linux systems provide many useful tools to find hardware details. The conundrum is Linux kernels since 2.6 choke with 16 MB of RAM. The most recent kernel that tolerates 16 MB of RAM is the 2.4 kernel, last included in Slackware 11.0 in 2006. The 2.4 kernel will boot with the limited amount of RAM.
Modern kernels will find real-time clock (RTC) information. Those older kernels do not.
Booting with a Slackware 11.0 install CD helps only a little. With only the install CD there is no /dev/rtc device node. The /dev/rtc device node does exist after installing to disk.
With the install CD there is a /proc/driver/rtc file. The existence of that file and eventual device node confirms the existence of an RTC chip although lacking details. Other clues an RTC chip exists is grep -i rtc /proc/ioports and dmesg | grep ‘Real Time Clock'. The logs are void of related information. None of this definitively reveals the future date capacity.
Creating a Slackware 11.0 virtual machine (VM) to test further does not help. There is no sysfs (/sys) file system that was introduced in the 2.6 kernel.
Installed in two vintage computers in the house network, the 3.10.107 kernel included in Slackware 14.1 finds the RTC future date capacity. The log information looks like this:
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc_cmos rtc_cmos: alarms up to one day, 114 bytes nvram
On more modern systems with a more recent kernel the logs look like this:
rtc_cmos 00:06: RTC can wake from S4
rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
rtc_cmos 00:06: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
The 3.10.107 kernel could be a starting point for detecting future date capacity. Traveling backwards in time, the Slackware 12.2 install CD with the 2.6.27.7 kernel does not log any relevant RTC information. Testing in a VM is required to ensure sufficient RAM. The stock Slackware 2.6.27.7 kernel fails to boot with 16 MB of RAM. While the 11.0 install CD boots in the 486, using a stock 2.6 kernel in 11.0 will fail to boot. No sense trying to boot with a stock 3.10.107 kernel.
Searching for extreme lightweight distros proved futile. Poking around the web finds Tiny Core Linux requiring more than 16 MB of RAM, including old releases. The Slitaz “low ram” ISO image fails to boot with 16 MB of RAM. Anything that might boot with 16 MB of RAM presents the same limitation of being too old and lacking support to query the RTC information.
Slackware 11.0 came with an apmd package that included the apmsleep command. That command will not help solve the question. The output of /proc/driver/rtc in a Slackware 11.0 system does not have an alrm_date field. Only an alarm field exists, in the format of clock time that matches the table in the manual. This output again seems to imply the future date capacity is limited to 24 hours.
Would more RAM help resolve the question? In a VM the Slackware 14.1 install CD with that 3.10 kernel tries but fails to boot with 48 MB of RAM, the maximum RAM the 486 can have without a special memory expansion card, which then still limits the system to a total of 64 MB. The Slackware 14.1 Slackware-HOWTO specifies a minimum of 128 MB to install, but testing in a VM found at least 160 MB of RAM needed.
Would a custom kernel starting with the make tinyconfig option programmatically find this RTC information? The tinyconfig option was not added to the kernel until version 3.17.
The Red Queen is running and going nowhere. For now the conclusion is the 486 RTC only supports alarms up to one day in the future. Time to leave the rabbit hole.
Posted: Category: Usability Tagged: General
Next: Computer Rest Breaks
Previous: Laptop Battery Management