Real Time Clock For PiDP-11/70

[Garry Lockyer]

In anticipation of receiving a PiDP-11/70, I’m considering creating a Real Time Clock peripheral that provides the correct date and time. It will be based on the DS3231 chip and interface via I2C - see https://www.maximintegrated.com/en/products/digital/real-time-clocks/DS3231.html.

First effort will be with a DS3231 breakout board by KEYES, sold by HobbyMaker via amazon.ca for $3.89 CDN. Similar boards are available elsewhere such as Adafruit and Sparkfun.

I don’t think any PDP11 had a RTC or that there was a DEC RTC option. Yes, I am aware of the KW11-L and -P. DigitalPathways offered a few RTC products and I might base my design on their TCU-150 (http://www.bitsavers.org/pdf/digitalPathways/tcu-150.pdf). Or I could look at the Time Of Year (TOY) clock on VAXen.

The hope is that I can eliminate the need to enter the date and time when a PDP11 operating system starts up, but that might require some OS hacking beyond my capability.

Anyway, all comments and advice are welcomed!

Regards,

Garry

[Mark Matlock]

Garry,
   Actually the PDP-11/93 and PDP-11/94 systems did have real time clocks. These are properly emulated in Simh and RSX11M+ V4.6 will automatically
load the correct time from the simh emulated 11/9x clock. Thus if one is only interested in not entering time and date to simh alone setting the CPU to 11/9x
works. The PDP-11/70 true emulation used in the PiDP-11/70 does not work this way so adding it would certainly be a worthwhile project. If RSX doesn't see
the TOY clock it asks the console as would many other operating systems. At any rate taking a look at simh code for 11/93 or 11/94 as that would be a good starting point to explore.

Best,
Mark

[Garry Lockyer]

Thanks! I’ll look at the 11/9X docs.

Garry

[Chris Smith]

Given that a notable fraction of PiDP-11s running on simh will run networked, why not just build the simulated peripheral to get the "real time" from the Pi?

This is then a "no more hardware" solution for many users.

For those running standalone and unnetworked, there are already RTC solutions drop-in for the Pi.

HOWEVER ... I strongly suspect that both your work and the existing solutions will run up against the same hardware limitations - lack of GPIOs. The PiDP series tends to use all the GPIOs, including the SDA and SCL that these clock chips typically use.

All that said - I like the idea! The only other question then - did *real* PDP-11s require the time to be entered every time they were started?

[Garry Lockyer]

Oscar’s “first hack” uses the I2C interface to talk to a pressure/temperature sensor so I’m confident I can use it for a RTC.

Getting the date/time from the Pi would probably work but that eliminates the fun of using the prototype area Oscar has provided. But it probably wouldn't take much to write the simulator software to look for a physical RTC and use Pi time if none is found.

And yes, you had to enter date and time when starting PDP11 OSs, at least up until the PDP 11/9X, as I just learned.

Regards,

Garry

[oscarv]

Garry, Chris,

Yes, the PiDP-11 has the I2C port free for this kind of hack. Although never discussed, so does the PiDP-8 actually. The I2C pins are the ones with the annoying pull-up resistor, which makes them no good for front panel service.

So you could make an I2C hardware device, as per Garry.

Or make it an otherwise identical device in terms of how it presents itself to the PDP-11 'inside', but use the Pi's own clock instead of an I2C hardware bit. The Pi's own clock, IIRC, is kept updated as long as there is an internet connection (although I'd expect the time not to be updated yet when the PDP-11 OS is booting up, which is a few seconds after the Pi itself woke up. It might still be establishing its wifi connection at that moment. In which case, you get the 'last time' the Pi knew about before shutdown...)

Either way, it could be a 'new' Unibus device, or maybe we could enable the simh simulation of the 11/93 under the 11/70 CPU mode of simh?

The toughest part of such a hack might be letting RSX or Unix know of the RTC's existence? I'd be way out of my depth there. But adding an I2C clock device to the hardware is very feasible indeed!

Kind regards,

Oscar.

[Johnny Billquist]

On 2018-07-03 22:39, Garry Lockyer wrote:
> In anticipation of receiving a PiDP-11/70, I’m considering creating a Real Time Clock peripheral that provides the correct date and time. It will be based on the DS3231 chip and interface via I2C - see https://www.maximintegrated.com/en/products/digital/real-time-clocks/DS3231.html.
>
> First effort will be with a DS3231 breakout board by KEYES, sold by HobbyMaker via amazon.ca for $3.89 CDN. Similar boards are available elsewhere such as Adafruit and Sparkfun.

Hmm. This seems like going over the bridge to get some water.

> I don’t think any PDP11 had a RTC or that there was a DEC RTC option. Yes, I am aware of the KW11-L and -P. DigitalPathways offered a few RTC products and I might base my design on their TCU-150 (http://www.bitsavers.org/pdf/digitalPathways/tcu-150.pdf). Or I could look at the Time Of Year (TOY) clock on VAXen.

The 11/93 and 11/94 do have a TOY. In addition to that, there were
several companies that made both Unibus and Qbus boards with an RTC.
I have cards for both in storage from a company called BIT, and I also
have the documentation and software somewhere.

> The hope is that I can eliminate the need to enter the date and time when a PDP11 operating system starts up, but that might require some OS hacking beyond my capability.
>
> Anyway, all comments and advice are welcomed!

If you run RSX, this is trivial. The prompt for the time and date are in
a normal script that is run at boot, and you can edit that to not
prompt, or to run some other program that pulls the date from somewhere
else.

And writing a program to pull date and time from some device is rather
trivial, and setting the date and time of the system is just a simple
system call, so such a program tend to be very trivial.

All that said, this is the kind of thing that you do not need to hack
any hardware at all to accomplish. The host OS (Linux) already have date
and time, so all you need to do is write a device handler in simh that
exposes this information to the simh machine, and then all that is left
is the software under the PDP-11. Although, if you actually set it to
emulate an 11/93 or 11/94, all of this has already been solved for you.

Finally, if you install RSX, and my TCP/IP, you can also use the NTP
client that exists.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Johnny Billquist]

On 2018-07-03 22:59, Chris Smith wrote:
> Given that a notable fraction of PiDP-11s running on simh will run
> networked, why not just build the simulated peripheral to get the "real
> time" from the Pi?

Networked or not, the Pi is always there, and it do have some concept of
time, so the PDP-11 can always get it from there. However, if that does
not have an RTC (I expect it does), then you would possibly just get the
wrong time in the PDP-11. But this would still be the natural place to
pull the information from.

> This is then a "no more hardware" solution for many users.

Indeed. This would for me be the obvious solution for everyone.

> For those running standalone and unnetworked, there are already RTC
> solutions drop-in for the Pi.
>
> HOWEVER ... I strongly suspect that both your work and the existing
> solutions will run up against the same hardware limitations - lack of
> GPIOs. The PiDP series tends to use all the GPIOs, including the SDA and
> SCL that these clock chips typically use.

There are no needs for an external hardware implementation here.

> All that said - I like the idea! The only other question then - did
> *real* PDP-11s require the time to be entered every time they were started?

Depends. And different OSes solved it in different ways.

In RSX, it was trivial to set the time from somewhere else, or even just
ignore the actual date and time. The system will run fine even if the
date is wrong. And for some embedded systems, that was all there was to it.

[Mark Matlock]

Johnny,
   I was just looking at the RSX11M+ source code TIMOV.MAC to try to understand what how TIME /SYNC worked to get time and date from the TOY clock and I discovered an undocumented featured (at least I was unaware of the ability to ask for Roman dates).

> TIME /ROMAN
Julius III, Anno Domini MMXVIII   XVI:XXV
The moon is at last quarter. Today is Tuesday.

   I don't know my Roman months very well \, but today is Tuesday and the moon phase is correct.

Best,
Mark

[Johnny Billquist]

Mark, yes that is a fun little easter egg. And yes, the date and time is
correct roman numerals.

As for how TIM /SYNC works, you probably fist of all want to read the
CPU documentation which explains how you actually access that device. I
think it's rather ugly. It's just one CSR, and you are supposed to write
specific bit patterns to it, and then you do a bunch of reads, which
gives the different values of the date and clock.

However, RSX also checks if you are actually an 11/93 or 11/94 before it
even tries to access that clock, so if you enabled that TOY, but emulate
an 11/70, RSX will not allow TIM /SYNC anyway, since RSX knows that an
11/70 don't have a TOY...
I can fix that, if needed. But I haven't really bothered, since I use
NTP anyway.

Johnny

> email: b...@softjar.se <javascript:>             ||  Reading murder

> books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/9e7087fb-bad3-4d6e-becf-c0d3e457db87%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/9e7087fb-bad3-4d6e-becf-c0d3e457db87%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[terry-...@glaver.org]

On Tuesday, July 3, 2018 at 5:51:07 PM UTC-4, Johnny Billquist wrote:

However, RSX also checks if you are actually an 11/93 or 11/94 before it
even tries to access that clock, so if you enabled that TOY, but emulate
an 11/70, RSX will not allow TIM /SYNC anyway, since RSX knows that an
11/70 don't have a TOY...
I can fix that, if needed. But I haven't really bothered, since I use
NTP anyway.

I'll take a look at the RSTS/E 10.1 sources (I just need to unzip the TPC file, then attach it to simh and extract it under an emulated RSTS/E (9.x or 10.x) system. It should be possible to patch it to always query the TOY, assuming it is easy to have simh provide the 11/93 TOY on non-11/9x systems.  

 

[Garry Lockyer]

Thanks for all the responses!

I really appreciate the offers to modify OSs but no need to take any action at this time.

I’ll post here if I actually do anything.

Regards,

Garry

[andy]

Hi everyone - resurrecting this old thread... 

I notice the clock time drifts quite a lot in a few days (RSTS/E 10) and wonder if anyone had any luck in this in this regard?

thanks!

Andy

[Ron Pool]

On Wednesday, November 14, 2018 at 9:05:20 PM UTC-5, andy wrote:

I notice the clock time drifts quite a lot in a few days (RSTS/E 10) and wonder if anyone had any luck in this in this regard?

It would be hacky, but in SIMH you could attach a simulated serial port to incoming telnet, then in Linux script a telnet login to RSTS/E over that telnet port using expect or some other tool, and have your script set the time and then logout.  Then schedule that Linux script to run every few hours.

Before bothering with any of that, have you made sure that the line time clock in SIMH is configured to run at the same frequency that RSTS/E is configured to expect?  Choices are 50Hz and 60Hz and would usually be set to match the frequency of your A/C power supplied by your local electric utility provider.  But since the line frequency is simulated in SIMH, either 50Hz or 60Hz should work just fine as long as SIMH and RSTS/E agree.  If one is set to 50Hz and the other to 60Hz, then you should expect the time of day to drift a lot in RSTS/E.

Here's my line time clock in SIMH:

sim> show clk
CLK    60Hz, address=17777546-17777547, vector=100, BR6

You can change the frequency in SIMH with one of:

sim> set CLK 50HZ
sim> set CLK 60HZ

You can check what RSTS/E expects from the RSTS/E console before you start/boot it.  You can also change what it expect to 50Hz or 60Hz.  Here's me checking what my RSTS/E 10.1 install expects:

Option: <Start> HARDWR

  HARDWR suboption? LIST

(LIST output trimmed for brevity)

  KW11L  177546   100
  SR     177570
  DR     177570

  Hertz = 60.

(more of LIST output trimmed)

You can type ? to get context-sensitive help at any of the prompts before you boot/start RSTS/E.  For example:

  HARDWR suboption? HERTZ
    New AC line hertz? ?
    The AC line hertz may be either 50Hz or 60Hz.
    Type the new value, either '50' or '60'.
    New AC line hertz? 60

[andy]

Thanks Ron!  Looks like my clock is now good