Is there a file system forr the PDP-1? Why, yes, there is (or will be)...

[Bill E]

I've started my next project in my step-by-step plan to do interesting things with my -1. Comments are welcome before I get too far along.

The progression should start looking clear, dynamic IOTs to implement various 'hardware' bits, an assembler up to the task of multi-bank coding, a communications layer, a drum storage layer, and now to make all that stuff useful. Seems I just can't stop coding.

Bill

[Unibus]

Hi,

Any chance of a file having a date/time stamp for version control?

Regards,

Garry

--
You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-1/862981bf-1410-4776-9fd2-5de7c6641a0fn%40googlegroups.com.

[Bill E]

It's just code, :)

The problem is, however, there is no time-of-day clock. I think there might have been some version of one; if anyone can find documentation, I can implement it. I suppose I could, in the spirit of the original -1 hacks, dream one up.

Bill

[Unibus]

Hi,

I keep coming across references to a DEC Real Time Clock Option. The different interrupt priority configurations included two different Clock/Timer interrupts per system. There is a good chance the Computer History Museum buried in their collection of time sharing systems printouts will be one or more implementations of a time of day clock. For example the DEC Options included:-

Type 152 18-Bit Real Time Clock

Counts according to frequency of a crystal-controlled oscillator. Counter contents can be cleared or read into the processor at any time. Counter overflow causes a sequence break.

The may have been a later DEC clock option in the Type 800 series numbers. Also seen references to 1kHz and 250Hz Clocks

There was an rsk Reset Clock instruction plus I think I've seen references to Clock On/Off IOTs.

rsk – Reset the Clock

PiDP Status – Not implemented

Operation Code 720047

References

D-1D-45-56, Clock

F25 PDP-1 Input-Output Systems Manual (Preliminary Manual), Appendix I, Page 3

I haven't spent much time looking into clocks and timers documentation. I came across a reference to a Technical Note on an Interval Timer in the Computer History Museum documentation. I've already  submitted a request for access to this document. Submitted just a day ago, answer expected in three weeks. So far I found this reference but I haven't found a document title in their collection that looks plausible. It may be the case they never received the relevant Technical Note/Memo.

Regards,

Garry

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/fc3b22c2-4838-4934-bb06-de214c102c47n%40googlegroups.com.

[Matthias Barthel]

Just today I was thinking about a clock implementation. I was thinking of a clock with several registers. 

For example: 

register 1 contains the time in an 18 bit word, 6 bits each for hour, minute, year, 

register 2 contains the date, 

register 3 contains the current UNIX timestamp... 

Either as a real device for the backplane or as software...

The register can be called with a 72rrrrDD opcode, rrrr = number of the register, DD = devicenumber of your choice.

I'll let my thoughts mature for a few more days before I have time for the pidp1 again on the weekend🙃

Matthias 

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/CAHDxiR6QYGXC3ay86gr62vpGDyqu7pSAE0qwLG7fLer00bpWvg%40mail.gmail.com.

[Milo Velimirović]

See also pp 40-42

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/CAHvYjvH2sV6vRoSg1y3K0njj1hpR-_A_d3wxCpuKHo5ASJ%2Bwsg%40mail.gmail.com.

[Matthias Barthel]

Wow, looks interesting, thanks milo 👍

[Unibus]

Hi,

Looks like there might be something in the implementation of the Drum.

The character time on the punch is 16 milliseconds. To be on the safe side it was thought there should be between one and two interrupts during this period. A convenient source of time pulses is the next to the most significant bit of the drum counter. The drum takes 33 1/3 milliseconds per revolution, and this will change state every 1/4 revolution or 8 1/3 milliseconds. This could also be used as a convenient means of synchronizing the ER to the drum for swaps.

Regards,

Garry

[Bill E]

The clock described in the MIT document is fairly similar to the BBN clock. The BBN clock ticks at 1msec and can interrupt every 32msec or 1min. Reading it returns the current 1msec count. However, it doesn't keep a full 18 bits in the msec timer. I added a countdown timer to my implementation that counts down in msecs and can then interrupt. Extending the 1ms clock register  to the full 18 bits is trivial, but I kept it the same as the BBN spec. Note that the MIT system described is the -1x it seems, and that is a very strange beast indeed.

[Unibus]

Hi,

There was a code fragment somewhere for a time clock of loading a counter with a -negative number then getting an alarm when it reached zero. Haven't found any system info that would support that mode but then I'm probably looking in all the wrong places. 

Regards,

Garry

On Wed, 7 Jan 2026 at 12:22, Bill E <wjegr...@gmail.com> wrote:

The clock described in the MIT document is fairly similar to the BBN clock. The BBN clock ticks at 1msec and can interrupt every 32msec or 1min. Reading it returns the current 1msec count. However, it doesn't keep a full 18 bits in the msec timer. I added a countdown timer to my implementation that counts down in msecs and can then interrupt. Extending the 1ms clock register  to the full 18 bits is trivial, but I kept it the same as the BBN spec. Note that the MIT system described is the -1x it seems, and that is a very strange beast indeed.

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/92da76f6-a6c0-4b3b-8c86-00ae581707c8n%40googlegroups.com.

[Bill E]

Here's my latest thinking on this. One more question, should this be user-space code, as documented, or would it be more useful implemented as an IOT?

Using an IOT is a bit of a departure from normal, since a file system isn't hardware, although it could be argued that IOTs were used for some abstracted control ideas back in the day.

The IOT approach simplifies usage a bit.

Bill

[Glenn Babecki]

Bill,

Your request for feedback on the latest proposal for your SFS implementation sort of jumped out at me so I have to offer my 2 cents, for what it's worth.  I don't have a good understanding of your rationale for implementing SFS in the IOT subsystem, so my thoughts are purely based on notions of architectural layering.

I view a file system as being a system function that utilizes the various resources of the computer system like peripheral device I/O, and as such I don't think it should be implemented any where near the IOT subsystem.  The PiDP-1 IOT subsystem is a software simulation of the hardware which controls the I/O transfers between the processor and peripheral device hardware.  While some of the past IOT subsystems may have "abstracted control ideas" for I/O processing, file system functionality has nothing to do with lower-level hardware control.  I believe in the interest of architectural layering that your implementation of the SFS should be in the application space of the processor.

I don't know of any file systems that would be embedded in the lower layers of a computer system.  My fear is that implementing SFS in the IOT subsystem could complicate future evolution and maintenance of both functions.

This is my perspective given the available information and it will be interesting to hear if other people have different thoughts.

Regards,

Glenn

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/6e29e94a-a903-46be-b0a0-d631fd6c8ecdn%40googlegroups.com.

[Bill E]

On Friday, January 9, 2026 at 2:59:28 PM UTC-5 glenn....@gmail.com wrote:

Bill,

Your request for feedback on the latest proposal for your SFS implementation sort of jumped out at me so I have to offer my 2 cents, for what it's worth.  I don't have a good understanding of your rationale for implementing SFS in the IOT subsystem, so my thoughts are purely based on notions of architectural layering.

Actually, I fully agree. I just thought I'd throw the IOT bit out there for two reasons. One, no extended memory use in user code would be needed, and two, I could write it in C instead of assembler. :)

I'll stick with the user-space assembler.

Bill 

[Unibus]

Hi,

Just a dump of random MIT Clock info for this thread. There was a comment about a clock register being limited, the MIT implementation appears to be a 36-Bit clock.

PDP-1 Clocks

PDP-1D

PDP-35-5A Instruction Manual Part 5A – Basic System Calls¹, February 1975

5A.10.5.6 Hardware I/O

The design of the PDP-1 allows some I/O operations to be performed directly by users. An extensive and somewhat accurate description of this facility may be found in memo PDP-33, Input/Output in the PDP-1X. PRL² must be on to operate hardware directly (see section 5A.8).

Assignment of hardware devices is described in section 5A.10.5. The following device numbers are currently used:

1 New drum side A

2 New drum side В

16 Teletpe input

17 Teletype output

20 Microtape unit monitor

21 Microtape data controller

25 PDP-11 link transmitter

26 PDP-11 link receiver

27 Calcomp plotter (see below)

30 Clock (see below)

31 Real-time clock alarm device (see below)

32 Special user device.

76 Real-time Clock (see below)

77 Microtape motion controller

Some of these devices are described in separate memos. Most require special turn-on procedures. Devices 1, 2, 20, 21, and 77 cannot be assigned.

Real Time Clock

The real-time clock is implemented as two devices, the clock device (hardware device 76) and the alarm device (device 31).

The clock device maintains a 36 bit time register, which is incremented every 100 microseconds. It may be read but not written. The time register overflows only about every 79 days.

The alarm device is usable as a timer for intervals of up to 26.2144 seconds. It maintains an internal 18 bit register which counts down by one every 100 microseconds, and which turns on a flag when it reaches zero.

For the alarm device, variant 17 acts as an I/0 clear. The execution of any nonwaiting variant is legal even if another process is at that time waiting on the alarm, and it will have its normal function. Attempting to execute a waiting variant while another process is waiting causes a function busy error. Variants 0 and 1 are the only waiting variants.

Dervice	Variant	Function
76 (clock)	any	Read current contents of time register. A contains the high 18 Bits. I contains the low 18 Bits.
31 (alarm)	0	Clear flag, load alarm register from I, and wait. When flag comes on, clear it again and complete.
	1	Wait. When flag is on, clear it and complete.
	2	Clear flag, load alarm register from I, and complete immediately.
	3	Test flag. Skip if flag is on. Clear flag and complete immediately.
	17	I/O clear. Clear flag and cause any other process now in an alarm wait to complete. Complete immediately.

Clock

This is an adjustable speed clock designed to tick in the vicinity of 60 times per second. The clock is assigned as device 30 as described in section 5A.10.5. All ivks on this clock will hang until the clock "ticks". All registers are unchanged by this ivk.

Ticking rates of greater than about 365 times per second are not possible because of the system scheduling overhead needed. The minimum rate of ticking is around 2.1 ticks per second. The tick rate is adjustable with a knob in bay 10.

Programs wishing to keep track of long time periods by using this device might employ one of the techniques exampled below:

ivk 66 / device 30 assigned to capability 66, PRL on

idx time / will cycle to zero in 1hr, 12min,

jmp.-2 /49 1/15 sec assuming 60 ticks per second

ivk 66 / same as above

idx time / will_cycle back to zero in 6years, 17days,

sza / 8hours, 17minuteş, 15 ¹⁷/₄₅ seconds

jmp .-3 / (assuming two leap years) given a tick rate

idx time2 / of 360 ticks per second

jmp.-5

Temporary Clock

5A.10.5.3

The system provides a clock which ticks 1760 times per minute, or slightly less than 30 decimal ticks per second³. The clock is assigned as indicated in section 5A.10.5, and an unlimited number of clock capabilities are available.

A process invoking a clock capability will hang as follows:

1. if the value in A is positive, plus or minus zero, processing will resume immediately and the contents of A will be unchanged.

2. If the value in A. is less than 0777777, each clock tick will (one’s complement) add 1 to the contents of A. When the contents become zero the process will be unhung.

All arithmetic on clock time is done in one's complement. If time larger than 1hr 14min 28 ²⁹/₈₈ seconds is needed, the user should write a loop into his program that invokes the clock as many times as necessary to get the desired total waiting time.

The following programs are offered as examples.

1. law 1 30. / will wait slightly over a second
ivk 10 / if a clock ca pability is at index 10
sza
hlt / will never be executed

2. law 30. / will never be executed
ivk 10 / (clock on capability 10)

1MIT PDP-35-5A Instruction Manual Part 5A – Basic System Calls, February 1975:- https://bitsavers.trailing-edge.com/pdf/mit/rle_pdp1/memos/pdp35_part5A_feb75.pdf

2Program Reference List (PRL). Execute an mta 403 to enter PRL mode.

31,760 Ticks per Minute is equivalent to 29 ¹/₃ Ticks per Second or Equivalent to 29 ¹/₃Hz or 34ms.

Regards,

Garry

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/6ceaf538-da7b-4d66-9f1f-cb56bc427998n%40googlegroups.com.

[Bill E]

On Sunday, January 11, 2026 at 12:53:35 AM UTC-5 uni...@gmail.com wrote:

Hi,

Just a dump of random MIT Clock info for this thread. There was a comment about a clock register being limited, the MIT implementation appears to be a 36-Bit clock.

I think I'll remove the arbitrary limit in the BBN clock (which is what I implemented) to allow the full 18 bits. It turns out the BBN clock is what simh also provides. So far, I've seen references to 4 different clock implementations, BBN, MIT, and 2 DEC ones. As usual, everyone seems to have modded their PDP-1s as they desired.

Bill 

[Matthias Barthel]

Bill,

I think it doesn't matter which watch you install, because apparently everyone has 🙃 used their own watch, the only important thing is that it is well documented. 

I also wanted to continue working on my clock, but I was too busy with snow, family and sleeping 😅 

I still think of a realtime date time clock and an alarm clock with programmable time registers

I also think about a implementation of a database structure to create a simple smart home control with a pidp1 👌

Matthias 

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/01ceea4e-4a62-4dd2-8741-dab3af62a848n%40googlegroups.com.