Anyone have any deeper knowlege on how the high speed channels work?

66 views
Skip to first unread message

Bill E

unread,
Oct 29, 2025, 2:55:28 PM (8 days ago) Oct 29
to [PiDP-1]
As usual, the documentation is vague. I know it cycle-steals. I assumed it takes one every other cycle, but something in the description implies it actually halts the processor for the entire memory transfer time. Anyone actually know? If the latter, that seems a bit extreme.
Bill

Unibus

unread,
Oct 29, 2025, 9:33:59 PM (8 days ago) Oct 29
to Bill E, [PiDP-1]
Hi,

There was an article on the BBN Timesgharing systemN

On Thu, 30 Oct 2025 at 05:55, Bill E <wjegr...@gmail.com> wrote:
As usual, the documentation is vague. I know it cycle-steals. I assumed it takes one every other cycle, but something in the description implies it actually halts the processor for the entire memory transfer time. Anyone actually know? If the latter, that seems a bit extreme.
Bill

--
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/3da8a7da-faad-46f2-9693-60ce05ad9f5bn%40googlegroups.com.

Unibus

unread,
Oct 30, 2025, 11:07:45 AM (8 days ago) Oct 30
to Bill E, [PiDP-1]
Hi,

My impression from the PDP-1 Input-Output Systems Manual is that under some circumstances I/O can stop the processor. See the introductory material and sections starting at Page 17. Also look at the UNIVAC FASTRAND and Datamation articles about BBN Timesharing and the MGH hospital.

Regards,
Garry

On Thu, 30 Oct 2025 at 05:55, Bill E <wjegr...@gmail.com> wrote:
As usual, the documentation is vague. I know it cycle-steals. I assumed it takes one every other cycle, but something in the description implies it actually halts the processor for the entire memory transfer time. Anyone actually know? If the latter, that seems a bit extreme.
Bill

--

Bill E

unread,
Oct 30, 2025, 11:20:16 AM (8 days ago) Oct 30
to [PiDP-1]
That's the conclusion I've come to. For one thing, the manual says it can to 200K transfers/sec. Since the memory cycle time is 5us, the only way that can happen is if it takes over the memory for the duration of the transfer. I've changed my high speed channel impl to allow the same behavior. Since it's not something controlled from the -1 side but rather a tool to use in IOTs, I allow controlling that. You can either use the 'take over' style, an immediate 'do it instantly inside the call to the channel controller' or 'take 5us per, but hide that so the processor still runs at full speed', all possible of course because modern memory is so much faster.
Bill

Unibus

unread,
Oct 30, 2025, 4:42:40 PM (7 days ago) Oct 30
to Bill E, [PiDP-1]
Hi,

If you read the MGH hospital timesharing system articles in Datamation it provides an overview of the BBN Timesharing system. To me it reads like every user is allocated 4K words. Using a  dual channel configuration, for each timeslice the entire 4K words of a user is written to disk while the 4K words of the next user are read from disk. execute for ~135ms then repeat swapping ,

From the changing description over time, it appears it started as a small demonstration system before being expanded with more memory and the FASTRAND.

Regards,
Garry

On Fri, 31 Oct 2025 at 02:20, Bill E <wjegr...@gmail.com> wrote:
That's the conclusion I've come to. For one thing, the manual says it can to 200K transfers/sec. Since the memory cycle time is 5us, the only way that can happen is if it takes over the memory for the duration of the transfer. I've changed my high speed channel impl to allow the same behavior. Since it's not something controlled from the -1 side but rather a tool to use in IOTs, I allow controlling that. You can either use the 'take over' style, an immediate 'do it instantly inside the call to the channel controller' or 'take 5us per, but hide that so the processor still runs at full speed', all possible of course because modern memory is so much faster.
Bill

--
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.

Milo Velimirović

unread,
Oct 30, 2025, 4:55:53 PM (7 days ago) Oct 30
to [PiDP-1], Bill E, Unibus
Amd how long for the swap-out/swap-in? A back of the envelope calculation says 20.5 mS for 4096 words at 5 µS per memory access. Is there other overhead I’m not counting? How does this compare with other swapping algorithms?

—Milo

Unibus

unread,
Oct 30, 2025, 5:04:42 PM (7 days ago) Oct 30
to Milo Velimirović, [PiDP-1], Bill E
Hi,

Bitsaver's Parallel Drum Type 23 manual, Section 1, Introduction includes:
...
The drum contains 32 fields; each fields is capable of storing 4096 word.
...
Transfer of from 1 to 4096 words can be executed at a rate of 8.5 microseconds per word, exclusive of set-up and access time. Transfer or exchange of 4096 words is accomplished in approximately 35 milliseconds.

Regards,
Garry

Angelo Papenhoff/aap

unread,
Oct 30, 2025, 5:16:13 PM (7 days ago) Oct 30
to [PiDP-1]
The flow charts show it. Haven't looked into the schematics in a while. I didn't have any peripherals to test it with so i hadn't implemented it, but essentially it's just a memory cycle that occurs instead of a 3-cycle break.

Bill E

unread,
Oct 30, 2025, 7:31:38 PM (7 days ago) Oct 30
to [PiDP-1]
The drum does transfer a full track, 4096 words, in 34.8 ms, but you also have to add in the time for the drum to rotate to the correct position, another 8.5 us for each word position.
The HS channel hardware seems to be word at a time, and the transfer preempts the next 5us clock cycle. The hardware using it looks for a ready status, puts the word and/or gets the word from one of two hardware registers and tells the HSC it's ready. So, if the hardware can have words ready fast enough, it will just own the processor until the hardware is finished. In the case of the drum, this can be up to a full bank, 4096 words.

My HSC implementation isn't like that, would be difficult given that the IOTs aren't hardware. Instead, you pass one or two buffers of the size of the total number of words you want to transfer, one for read, one for write. The 'transfer' happens immediately, but the ready bit and cycle stealing use the correct computed time delay 5us times the total transfer count. Also note that the original could do a read and a write in one 5us cycle. This was taken advantage of for swapping core and drum contents. That was a requirement for the timesharing implementations. My implementation supports that also.

Finally, if Angelo adds my dynamic IOT code and HSC code, the drum is implemented in its corresponding IOTs and will be dynamically loaded, no recompile of the emulator needed.  The HSC code is one file that has one call made to it from the emulator execution loop, but does have to be linked with the emulator.

Bill

Angelo Papenhoff/aap

unread,
Oct 30, 2025, 7:37:21 PM (7 days ago) Oct 30
to [PiDP-1]
Oh i definitely want to have nice rotation simulation though :) we should see the high-speed cycles as they happen i think. since we now have some test programs for the drum as i've seen, maybe i should get to implementing the drum the aap-way :D

Bill E

unread,
Oct 30, 2025, 7:45:36 PM (7 days ago) Oct 30
to [PiDP-1]
My HSC emulation turns on HS at the beginning of a transfer, off when complete. That could be 1 word or many words duration. Note that the original HSC used 16 bit addresses, totally bypassing bank selection. So in theory you could transfer all 64k of memory. That would only take 327.68 msecs. :)
Bill

Unibus

unread,
Oct 30, 2025, 11:15:26 PM (7 days ago) Oct 30
to Bill E, [PiDP-1]
Hi,

This is a very random walk around the BBN Timesharing topic. Note how the PDP-1D system configuration changes over time.

Wikipedia entry for the BBN Time-Sharing System includes:-
The machine we used has 8192 words, 4096 of which are reserved for the time-sharing system. Each user sees a 4096 word memory.... Attached to the computer is a high speed magnetic drum memory divided into 22 fields each of 4096 words. A basic operation of the drum system is the memory-swap accomplished in 33 milliseconds. In this operation 4096 words are transferred from the core memory to a drum field and simultaneously the core memory is loaded from a different drum field.... A 4096 word drum field is allocated for saving the core image of each user when his program is not running. A user's program in run status is run for 140 milliseconds, then if there is another user also in run status, the state of core memory is stored in the first user's core image on drum and simultaneously the second user's core image is loaded into core and the second user's program is started in the appropriate place."
Given the 33ms delay this may be a description of an early version/configuration of the PDP-1 based on the DEC Drum Type 23.

Bitsaver's Parallel Drum Type 23 manual, Section 1, Introduction includes:
...
The drum contains 32 fields; each fields is capable of storing 4096 word.
...
Transfer of from 1 to 4096 words can be executed at a rate of 8.5 microseconds per word, exclusive of set-up and access time. Transfer or exchange of 4096 words is accomplished in approximately 35 milliseconds.

Massachusetts General Hospital, Laboratory of Computer Science, Celebrating 50 Years of Innovation web page, 1965 entry, has the configuration as:-
The initial system was based on PDP-1 computer with 16K of memory, housed at BBN. Across the river in Boston, at Massachusetts General Hospital, several Teletype terminals were set up. Telegraph lines carried communications at a speed of 10 words per second. With this set up, up to 5 users at a time were able access the database.

Datamation December 1965, Joint Venture at Massachusetts General article, Page 29 includes:-
Dr. Baruch: The central processor is a modified PDP-1 manufactured by Digital Equipment Corp. (Fig. 4). The modifications include instructions to facilitate 6-bit charaсter handling, memory protection to cause trapping to the  exec program when a user program tries to perform an instruction that addresses outside its own core, a trappedinstruction buffer to help the exec handle trapped instructions, and a 16-channel sequence break system and a crystal controlled real-time clock which provides 32 ms interrupts for time slicing and 1-min. interrupts for timeof-day. There are three independent banks of memory, each with its own memory address register and memory buffer. The 12K bank is used for storage of the exec and common routines and the two 4K memories hold user programs. Two other "processor like" devices, once started by the central processor, can operate independently and simultaneously: the high-speed swapping drum stores up to 32 programs in the time-sharing queue; the data channel handles transfers between memory and the Univac FASTRAND and tapes. The FASTRAND gives us 50 million characters of random access storage. The interconnections between the three memories and the three processors are controlled by an electronic crossbar switch which is controlled by the central processor. The Teletype interface has a 1-character transmitter buffer and a 1- character receiver buffer for each of 64 lines. The exес does the rest of the buffering internally.

The 1963 PDP-1 Handboook describes the optional Sequence Break System (Page 7) plus In-Out Transfer Group (Page 22) which includes:-
The computer will then enter the special waiting state until the device returns the in-out restart pulse.

The PDP-1 Maintenance Manual provides details of the instruction break and high speed halt, etc. It also includes the Sequence Break Indicator Panel (Page 5-11) operation (also see the 1963 PDP-1 Handbook, Page 30) which is not included on the PiDP-1. These indicators are linked into the interrupts and high speed data operations. 

On BBN drawing 00701_BS_D-1D-45-7_1of1.tif and Stanford University drawing 01701_BS_D-1D-48-17_1of1.TIF are the Priority Assignments table.
Chan BBN Device                                     Stanford Uni Device
00     
01      Data Channel                                                               Reader
02      Paper Tape Reader                                                      131D (7090 Chan)
03      External Break                                                              131M (Display Chan)
04      Return from IO Devices (FASTRAND & Tape)              32 Field Drum 
05      32 Field Drum                                                               
06      630-3 D.C.S.                                                                 Punch                       
07                                                                                            Typewriter (ty0)
10      1 Minute Clock                                                              Typewriter (ty1)
11                                                                                             Keyboard (Display)
12       Paper Tape Punch                                                        Teletype                    
13                                                                                             Visual (Display)
14       Type Out & Type In
15                                                                                             1 Minute Clock
16       Trap                                                                               Restrict Mode BR
17       32 ms Clock                                                                  32 ms Clock

So the BBN and Standford 32 Field Drum is the DEC Drum 23. BBN's Channel 04 will be the Drum 23's interrupt pulse. At the higher priority BBN Channel 03 was the text "FASTRAND"

Wikipedia entry for UNIVAC FASTRAND includes:
A FASTRAND subsystem consisted of one or two Control Units and up to eight FASTRAND units.
...
At the time of their introduction the storage capacity exceeded any other random access mass storage disk or drum. 

There were three models of FASTRAND drives
...
Specifications (FASTRAND II)
Storage capacity: 22,020,096 36-bit words = 132,120,576 6-bit FIELDATA characters = 99 megabytes (8-bit bytes) per device.

Datamation September 1964 issue, Page 19, Time-Sharing Marches On article includes:-
The Mass. General Hospital and Bolt Baranek & Newman, Cambridge consultants, have developed a prototype on-line computer-based communication system under an NIH research contract, with additional support from AHA (American Hospital Assoc.). Now being checked out, the system is built around a 24K PDP-I, includes a Fastrand drum, a 128K DEC drum and a 1.1 mc bit-rate
Univac channel. 

Remote mod 33 Teletypes have been installed at the hospital, and another 12 reserved for programmers. Purpose of the research: to determine the feasibility of time-sharing for real-time acquisition and use of medical record information in a general hospital.
...
The central processor has access to dedicated telegraph lines through a communications interface (DEC Mod. 630) which can handle up to 64 lines. The lines end in the user terminals. 
Our terminals are general purpose keyboard printing telegraph instruments, rather than dense coded keyboard instruments which limit you to a fairly poor vocabulary. Specifically, we use model 33 Teletypes. Several are located at various places in the hospital, others are in our offices for the use of the programmers, and five are in schools around Boston. The system is configured by the programmers for the use of the medical people at the moment, with the schools as paying guests.

Interesting that 8-Bit (well 7 bits ASCII characters plus parity), Teletype Model 33 terminals were used on a 6-Bits per character system. 

630 Data Communications System interface modules descriptions are on Bitsavers in the dec/modules/4000_series subdirectory.

As I warned, a very random walk.

Regards,
Garry

jim stephens

unread,
Oct 31, 2025, 5:47:31 AM (7 days ago) Oct 31
to Unibus, Bill E, [PiDP-1]
I had 2 ASR 33 5 level TTYs. They were used for TWX and industrial control programming. 

So the terminals could have been those. 

Bill E

unread,
Oct 31, 2025, 6:54:08 AM (7 days ago) Oct 31
to [PiDP-1]
The BBN summary matches what I've seen around the Type 23 drum and the 'timesharing' clock. The drum was specifically required to be able to read from one track (field in DEC terminology) while simultaneously writing to a different one. My implementation follows the requirements, as does my timesharing clock impl. The priority levels were confusing and hard to find, now I know why. Hmm, maybe we need a Fastrand now. Well, I do need a new project. :)
Bill

Bill E

unread,
Oct 31, 2025, 7:06:16 AM (7 days ago) Oct 31
to [PiDP-1]
The wiki read on the Fastrand is amusing. " There were reported cases of drum bearing failures that caused the machine to tear itself apart and send the heavy drum crashing through walls". It, despite the name, was slow, massively heavy, and cost more that the PDP-1. There was some strange engineering back then. I remember one system I worked on had a Bryant disk drive system. It was massive, each platter being the size of a coffee table. It rarely worked, we ended up scrapping it, we got a platter as a souvenir. No idea what happened to mine, unfortunately.
Bill

dave avery

unread,
Oct 31, 2025, 8:38:43 AM (7 days ago) Oct 31
to Bill E, [PiDP-1]
I know CDC had a closed chamber disk system with ~36 inch platters. One of the PMs was opening a hatch in the side of the chamber and using a towel covered wand wiping down the platter surface!


Sent from Gmail Mobile


On Fri, Oct 31, 2025 at 5:06 AM Bill E <wjegr...@gmail.com> wrote:
The wiki read on the Fastrand is amusing. " There were reported cases of drum bearing failures that caused the machine to tear itself apart and send the heavy drum crashing through walls". It, despite the name, was slow, massively heavy, and cost more that the PDP-1. There was some strange engineering back then. I remember one system I worked on had a Bryant disk drive system. It was massive, each platter being the size of a coffee table. It rarely worked, we ended up scrapping it, we got a platter as a souvenir. No idea what happened to mine, unfortunately.
Bill

--
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.

Unibus

unread,
Nov 1, 2025, 12:17:01 AM (6 days ago) Nov 1
to dave avery, Bill E, [PiDP-1]
Hi,

Our Burroughs B5500 system had a fixed head disk with platters the size of a coffee table. When the B5500 was shut down/destroyed for its gold content the fixed head disk unit was moved to the B6700 system. I only ever had to work on this disk subsystem once for something so minor I don't remember what had been the hardware issue. Probably something to do with actuators. This was so incredibly reliable compared to the Burroughs disk packs subsystems. 

When I had nothing to do I would be installing field change orders to our single and double density disk pack subsystems. There was so little confidence that any of the changes were going to increase their reliability that these upgrades were only done as the lowest priority task. I mean refilling the oil reservoirs in the B6700 system cabinets was a higher priority task. 

I can remember doing multiple changes to what was basically a phase locked loop. First there would be minor component changes as an upgrade then a later change would replace the entire circuit. All the time spent doing the minor component changes was pointless.

The Burroughs B5500 was a second generation system using transistors wired in small plugin modules. Each module was constructed with long pins and they were all gold plated. When I was working on the hardware I can't remember if the transistors were also gold plated. They had used the university's chemistry labs to work out how much gold per module. When the B5500 system was shut down some of the staff thought they were sitting on a gold mine and bought the system from the university. They became responsible for dismantling and disposing of the system. As they wanted to keep all the profit they didn't didn't have any of the other hardware maintenance staff helping to dismantle the B5500.

They sent the modules to a company that used a furnace/crucible to melt down computer systems for recovery of gold. This was a very low tech operation. Our 'gold miners' only received a fraction of the gold they had calculated so they were very unhappy about the financial return for all their work. They never said how much gold they had received back. It appeared they were too embarrassed.

This company also received some systems for secure destruction. My personal computers at home eventually included a PDP-11/10, LPS-11, PDP-11/34A and various VAX systems including a VAX-11/750. I would then search through the company's pile of hardware and buy items from this company to expand my systems. They didn't care what they sold so I was not surprised they only returned a fraction of the calculated gold.

Regards,
Garry

Unibus

unread,
Nov 1, 2025, 9:06:56 PM (5 days ago) Nov 1
to Bill E, [PiDP-1]
Reply all
Reply to author
Forward
0 new messages