The long way around to RTC Alternative

[TheDrip]

This is more of a blog post, feel free to let the discussion flow where it might from here!

I have spent the last few nerd-nights building, debugging and optimizing a Micro8088 build.

after some initial setbacks that were pretty minor, I had the machine up and running. SD card hard drive figured out and working, even came up with a good workflow for taking the SD image and working in a VM, then writing it back to boot on the hardware.

I couldn't decide if my next step was a working network card. or a real time clock.

I ordered a NIC on ebay, hoping I could get it working. The manual said it worked in 8 bit mode, I figured there had to be a way.

The card I received is an Asante EtherPac 2000+3. After some digging around for a config program as it has soft config, not jumpers, I figured out it is the forerunner to the D-LINK DL-220 series.

Armed with that knowledge I was able to get the packet driver working, then mTCP for the tcp/ip stack.

Now back to the real-time-clock and the long trip to get there.

After the packet driver is loaded, autoexec executes mTCP dhcp, then mTCP ntp to set the time.

The biggest trick of the night that took more than a minute to figure out, the DHCP lease expires as soon as the time is updated. It makes sense, no DHCP lease is that long.

The default time when the machine powers on is 1-1-1980 12:00 ... it's late into 2020, so the date jumps by more than 40 years.

The trick? run DHCP a second time.

The computer is sitting at the command prompt with the correct date and network connectivity.

WHO NEEDS A RTC when you have the internet?

[Chuck(G)]

Well, briefly, the Internet didn't exist in the heyday of the 8088...

Now, if you wanted to be period-authentic, you'd rig up a receiver and decoder for the WWV time signal.

[Timo W.]

The biggest trick of the night that took more than a minute to figure out, the DHCP lease expires as soon as the time is updated. It makes sense, no DHCP lease is that long.

No, it does not make sense, as the lease is given by the DHCP server. The lease time is also checked by the DHCP server, not by the client. The time of the client is not important at all, as it is not used (or even known) by the DHCP server.

It's more likely to be a bug in the TCP/IP stack that causes the connection to be lost when the time changes.

[ropersonline]

Well, briefly, the Internet didn't exist in the heyday of the 8088...

I was considering whether I should politely contradict and say the Internet kind of did exist, barely, though the WWW didn't. In looking things up, I found that even NTP was on the verge of springing into existence. Note the interesting RFC evolution chart.

Then I found this, and couldn't figure out if DCNET was DECnet or some WAN in Washington, D.C., or something else.

Does anyone know?

Now, if you wanted to be period-authentic, you'd rig up a receiver and decoder for the WWV time signal.

Oh, interesting.

[whartung]

WHO NEEDS A RTC when you have the internet?

Well, to quibble, you still need an RTC to maintain time set by NTP, you just don't need it to have a battery backup.

[Chuck(G)]

WWV-synchronized clocks were available in the consumer market at least starting in the 1980s. The signals are pretty strong throughout the US (and probably a good segment of Canada and Mexico), although Canada also has CHU at 7.85 MHz.

Networks in 1983 were still very much exotica in the consumer world; connectivity, at least on the consumer end, was primarily voice-grade lines using modems. I don't think your setup reflects that.

[Agent Orange]

Wasn't "America Online" sort of a stepping stone to the internet? Also, there was a business oriented subscription service (can't remember the name) about that time - middle to late 80's.

[krebizfan]

CompuServe dates back to 1969 for business use with the consumer services starting in 1979.

[Eudimorphodon]

It's more likely to be a bug in the TCP/IP stack that causes the connection to be lost when the time changes.

With MTCP there is no stack, there is only Zuul. Or, more precisely, there’s just a packet driver resident and each program runs its own stack that loads the IP information from the mtcp config file, which dhcp updates when it runs. And as it happens all the programs compiled against the MTCP framework look to see if there’s a current lease when they start up if the config file is set for DHCP. It’s not a bug, it’s a feature to try to prevent the client from stomping on an IP that’s been given out to someone else, since the dhcp client isn’t a resident daemon that renews the lease regularly. Could have been weeks, or forty years, since they last asked the dhcp server for a free IP.

[Agent Orange]

CompuServe dates back to 1969 for business use with the consumer services starting in 1979.

That's the one.