Setting PiDP-11 LEDs in C via 2.11BSD?
42 views
Skip to first unread message
Jon Lopez
May 12, 2026, 10:57:54 AM (2 days ago) May 12
to [PiDP-11]
Hello,
I've recently gotten a PiDP-11 and I've been having a great time with it! I've mostly been playing around in 2.11BSD, writing some simple C programs. I'm interested in possibly writing a program to control the data LEDs, however I'm not too sure where to start or if it's even possible from such a relatively high level language running on a largely abstracted OS. Does anyone have any ideas? Thanks!
Johnny Billquist
May 12, 2026, 12:02:37 PM (2 days ago) May 12
to pid...@googlegroups.com
Hi.
In principle, this is fairly easy. But there are some trickyness involved.
First of all, if you look at it from the hardware point of view, the
data LEDs on the front panel can show a few different things, depending
on what you select with that rotary dial.
What you want here is to display the display register, which is a
register programatically controlled. Which means that if you just write
to the right register, the data will show on the data LEDs.
Now, the display register is actually at a specific physical address in
memory. So all you need to do then, is actually somehow write to that
physical address, and you're done. And the display register is at
physical address location 17 777 570 (octal).
Now, with that explained, the question is now just how you get to a
specific physical address from within a C program under 2.11BSD.
And the easiest way is to open /dev/mem, or even /dev/kmem, which is a
device that just maps into physical memory. /dev/mem is all of physical
address space. So you seek to the right location, and write. /dev/kmem
is actually the kernel address space, but the I/O page (where the
display register is) is mapped into kernel space, so 177 570 (octal) is
the address in kernel space where you'll find the display register.
There have been talks about creating a device, or a sysctl function to
be able to set the display register (you're not the first wanting to do
this), but I don't know if anything has been done yet that you can find.
But you could look around...
I'm starting to think that maybe I should do a device for it, with an
ioctl() to both read the switch register and set the display register.
We'll see...
Johnny
First of all, if you look at it from the hardware point of view, the
data LEDs on the front panel can show a few different things, depending
on what you select with that rotary dial.
What you want here is to display the display register, which is a
register programatically controlled. Which means that if you just write
to the right register, the data will show on the data LEDs.
Now, the display register is actually at a specific physical address in
memory. So all you need to do then, is actually somehow write to that
physical address, and you're done. And the display register is at
physical address location 17 777 570 (octal).
Now, with that explained, the question is now just how you get to a
specific physical address from within a C program under 2.11BSD.
And the easiest way is to open /dev/mem, or even /dev/kmem, which is a
device that just maps into physical memory. /dev/mem is all of physical
address space. So you seek to the right location, and write. /dev/kmem
is actually the kernel address space, but the I/O page (where the
display register is) is mapped into kernel space, so 177 570 (octal) is
the address in kernel space where you'll find the display register.
There have been talks about creating a device, or a sysctl function to
be able to set the display register (you're not the first wanting to do
this), but I don't know if anything has been done yet that you can find.
But you could look around...
I'm starting to think that maybe I should do a device for it, with an
ioctl() to both read the switch register and set the display register.
We'll see...
Johnny
John D. Bruner
May 12, 2026, 12:59:04 PM (2 days ago) May 12
to Johnny Billquist, pid...@googlegroups.com
Yes, a C program could open /dev/kmem, seek to 0177570, and write 2 bytes to the display register. However, init changes the kernel security level to 1 when it goes multi-user. This is a one-way change. Until the next reboot, nothing can open /dev/mem or /dev/kmem for writing, so the C program would only work in single-user mode.
In some earlier versions of UNIX, the kernel read the switch register on every line clock interrupt. It fetched the word at that address (data space, using the low-order bit to determine if it was kernel or user space) and wrote it to the display register. Thus, you could put the address of an interesting kernel variable into the switches and watch its value change in real-time. So, although a C program could write the display register, its value would be clobbered by the kernel.
Another option would be to use the bus register, as the kernel idle loop does: execute a loop that moves the desired value to R0 and executes a WAIT instruction. The processor will wait for the next interrupt, displaying the last value on the bus. The process will look to the kernel like it is CPU-bound, but if there's nothing else happening then it'll keep running. There's no way to get the C compiler to generate a WAIT instruction, but it's pretty trivial to implement a function that calls it in assembly.
--John
> --
> 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.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/16b2ea71-81e5-42bc-aa54-4671c1b75679%40softjar.se.
>
In some earlier versions of UNIX, the kernel read the switch register on every line clock interrupt. It fetched the word at that address (data space, using the low-order bit to determine if it was kernel or user space) and wrote it to the display register. Thus, you could put the address of an interesting kernel variable into the switches and watch its value change in real-time. So, although a C program could write the display register, its value would be clobbered by the kernel.
Another option would be to use the bus register, as the kernel idle loop does: execute a loop that moves the desired value to R0 and executes a WAIT instruction. The processor will wait for the next interrupt, displaying the last value on the bus. The process will look to the kernel like it is CPU-bound, but if there's nothing else happening then it'll keep running. There's no way to get the C compiler to generate a WAIT instruction, but it's pretty trivial to implement a function that calls it in assembly.
--John
> 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.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/16b2ea71-81e5-42bc-aa54-4671c1b75679%40softjar.se.
>
Johnny Billquist
May 12, 2026, 1:00:21 PM (2 days ago) May 12
to pid...@googlegroups.com
Fair point. However, you can go multiuser without changing the security
level, which is what is needed for this.
Johnny
level, which is what is needed for this.
Johnny
Johnny Billquist
May 12, 2026, 1:03:51 PM (2 days ago) May 12
to pid...@googlegroups.com
Ah. I had a couple of more comments as well... :-)
On 5/12/26 18:58, 'John D. Bruner' via [PiDP-11] wrote:
> In some earlier versions of UNIX, the kernel read the switch register on every line clock interrupt. It fetched the word at that address (data space, using the low-order bit to determine if it was kernel or user space) and wrote it to the display register. Thus, you could put the address of an interesting kernel variable into the switches and watch its value change in real-time. So, although a C program could write the display register, its value would be clobbered by the kernel.
So basically just copying the switch register to the display register?
Never seen that. But if that happens, yeah. You couldn't play with it on
your own.
> Another option would be to use the bus register, as the kernel idle loop does: execute a loop that moves the desired value to R0 and executes a WAIT instruction. The processor will wait for the next interrupt, displaying the last value on the bus. The process will look to the kernel like it is CPU-bound, but if there's nothing else happening then it'll keep running. There's no way to get the C compiler to generate a WAIT instruction, but it's pretty trivial to implement a function that calls it in assembly.
Indeed. However, a user level program can have a WAIT instruction in
there, but it's a NOP. So you need to do that in kernel mode then. Which
is what the kernel does itself, and is how you have the rotating lights,
while at the same time, if the system becomes loaded, you see less of
that rotating light pattern...
Johnny
On 5/12/26 18:58, 'John D. Bruner' via [PiDP-11] wrote:
> Yes, a C program could open /dev/kmem, seek to 0177570, and write 2 bytes to the display register. However, init changes the kernel security level to 1 when it goes multi-user. This is a one-way change. Until the next reboot, nothing can open /dev/mem or /dev/kmem for writing, so the C program would only work in single-user mode.
As mentioned - secure level can be kept at 0, if desired.
> In some earlier versions of UNIX, the kernel read the switch register on every line clock interrupt. It fetched the word at that address (data space, using the low-order bit to determine if it was kernel or user space) and wrote it to the display register. Thus, you could put the address of an interesting kernel variable into the switches and watch its value change in real-time. So, although a C program could write the display register, its value would be clobbered by the kernel.
Never seen that. But if that happens, yeah. You couldn't play with it on
your own.
> Another option would be to use the bus register, as the kernel idle loop does: execute a loop that moves the desired value to R0 and executes a WAIT instruction. The processor will wait for the next interrupt, displaying the last value on the bus. The process will look to the kernel like it is CPU-bound, but if there's nothing else happening then it'll keep running. There's no way to get the C compiler to generate a WAIT instruction, but it's pretty trivial to implement a function that calls it in assembly.
there, but it's a NOP. So you need to do that in kernel mode then. Which
is what the kernel does itself, and is how you have the rotating lights,
while at the same time, if the system becomes loaded, you see less of
that rotating light pattern...
Johnny
Ville Laitinen
May 12, 2026, 1:49:32 PM (2 days ago) May 12
to pid...@googlegroups.com
hi, some examples of kernel extensions for manipulating the swreg at
-ioctl / fd access
-sysctl
-new syscalls (DigbyT posted these on the list years ago)
Did not check if the patches can be applied to a current kernel or not.. ymmv.
If someone wants to try them out but the patches cannot be applied / you can't compile the kernel for some reason let me know
and i will try to help (or upload an pl499 with the mods applied)
br,
-Ville
ps. an idle loop that would inspect the memory location set by the switches is a really nice debug idea :D
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/64a2affc-2bdc-48da-9253-d7a7aef4792d%40softjar.se.
Ville Laitinen
May 12, 2026, 1:53:52 PM (2 days ago) May 12
to pid...@googlegroups.com
oh,
forgot there is a later revision with some explanation of what's under the hood for the "mem" driver
-V
Jon Lopez
May 12, 2026, 6:06:40 PM (2 days ago) May 12
to [PiDP-11]
Hello, thanks for the great replies!
I might look into the /dev/kmem solution, although I'm not sure how to start 2.11BSD multiuser without changing the security level. I'm also somewhat concerned about if there could be any negative side effects such as system instability when running at 0.
Having a device created that allows interacting with the switches and LEDs would be really neat. It would be super useful if you could interact with a program via the front switches.
Those kernel extensions also look very promising, I might have to download the disk image and try it out for myself! I'm not the most skilled when it comes to doing stuff like this, especially in C, but I'm always down to experiment.
Johnny Billquist
May 12, 2026, 7:42:33 PM (2 days ago) May 12
to pid...@googlegroups.com
The "risk" by not changing the security level is just that things like
being able to write to /dev/mem is possible. It's still protected via
the normal file protections mechanisms, so it most likely have no
negative impact on the system, but it does mean one level of security is
dropped.
As for how to set this up at boot. Before you go multiuser, set the
securelevel to -1 using sysctl. Then go to multiuser.
Johnny
On 2026-05-13 00:06, Jon Lopez wrote:
> Hello, thanks for the great replies!
>
> I might look into the /dev/kmem solution, although I'm not sure how to
> start 2.11BSD multiuser without changing the security level. I'm also
> somewhat concerned about if there could be any negative side effects
> such as system instability when running at 0.
>
> Having a device created that allows interacting with the switches and
> LEDs would be really neat. It would be super useful if you could
> interact with a program via the front switches.
>
> Those kernel extensions also look very promising, I might have to
> download the disk image and try it out for myself! I'm not the most
> skilled when it comes to doing stuff like this, especially in C, but I'm
> always down to experiment.
> On Tuesday, May 12, 2026 at 1:53:52 PM UTC-4 vlai...@gmail.com wrote:
>
> oh,
> https://github.com/vlait/211bsd-csw <https://github.com/
> vlait/211bsd-csw>
> github.com/vlait/2.11BSD-swreg-ioctl>
> aa54-4671c1b75679%40softjar.se <https://groups.google.com/d/
> msgid/pidp-11/16b2ea71-81e5-42bc-
> aa54-4671c1b75679%40softjar.se>.
> d7a7aef4792d%40softjar.se <https://groups.google.com/d/
> msgid/pidp-11/64a2affc-2bdc-48da-9253-
> d7a7aef4792d%40softjar.se>.
> <https://groups.google.com/d/msgid/
> pidp-11/0a64edfb-8695-4dc0-8d81-620a34f4cd73n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.
--
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
being able to write to /dev/mem is possible. It's still protected via
the normal file protections mechanisms, so it most likely have no
negative impact on the system, but it does mean one level of security is
dropped.
As for how to set this up at boot. Before you go multiuser, set the
securelevel to -1 using sysctl. Then go to multiuser.
Johnny
On 2026-05-13 00:06, Jon Lopez wrote:
> Hello, thanks for the great replies!
>
> I might look into the /dev/kmem solution, although I'm not sure how to
> start 2.11BSD multiuser without changing the security level. I'm also
> somewhat concerned about if there could be any negative side effects
> such as system instability when running at 0.
>
> Having a device created that allows interacting with the switches and
> LEDs would be really neat. It would be super useful if you could
> interact with a program via the front switches.
>
> Those kernel extensions also look very promising, I might have to
> download the disk image and try it out for myself! I'm not the most
> skilled when it comes to doing stuff like this, especially in C, but I'm
> always down to experiment.
> On Tuesday, May 12, 2026 at 1:53:52 PM UTC-4 vlai...@gmail.com wrote:
>
> oh,
> vlait/211bsd-csw>
>
> forgot there is a later revision with some explanation of what's
> under the hood for the "mem" driver
>
> -V
>
> On Tue, May 12, 2026 at 8:49 PM Ville Laitinen <vlai...@gmail.com>
> wrote:
>
> hi, some examples of kernel extensions for manipulating the
> swreg at
> https://github.com/vlait/2.11BSD-swreg-ioctl <https://
> forgot there is a later revision with some explanation of what's
> under the hood for the "mem" driver
>
> -V
>
> On Tue, May 12, 2026 at 8:49 PM Ville Laitinen <vlai...@gmail.com>
> wrote:
>
> hi, some examples of kernel extensions for manipulating the
> swreg at
> github.com/vlait/2.11BSD-swreg-ioctl>
> msgid/pidp-11/16b2ea71-81e5-42bc-
> aa54-4671c1b75679%40softjar.se>.
> >>
> >
>
> --
> 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.
> To view this discussion visit https://groups.google.com/d/
> msgid/pidp-11/64a2affc-2bdc-48da-9253-
> >
>
> --
> 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.
> To view this discussion visit https://groups.google.com/d/
> d7a7aef4792d%40softjar.se <https://groups.google.com/d/
> msgid/pidp-11/64a2affc-2bdc-48da-9253-
> d7a7aef4792d%40softjar.se>.
>
> --
> 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>.
> --
> 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
> To view this discussion visit https://groups.google.com/d/msgid/
> pidp-11/0a64edfb-8695-4dc0-8d81-620a34f4cd73n%40googlegroups.com
> <https://groups.google.com/d/msgid/
> pidp-11/0a64edfb-8695-4dc0-8d81-620a34f4cd73n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.
--
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
Chuck McManis
May 12, 2026, 8:02:02 PM (2 days ago) May 12
to Johnny Billquist, pid...@googlegroups.com
This is a lot easier in RT-11 :-)
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/8b8777cd-534f-41bb-88d0-94c29a0973eb%40softjar.se.
Johnny Billquist
May 12, 2026, 8:27:38 PM (2 days ago) May 12
to Chuck McManis, pid...@googlegroups.com
Of course. A single user system is a completely different world than a
multiuser, timesharing system, where you have to consider what any one
user/process can do that could impact others.
It's sortof complex in RSX and RSTS/E as well. It's just RT-11 that is
way simpler in this sense.
Johnny
> > github.com/vlait/2.11BSD-swreg-ioctl <http://github.com/
> address
> > of an interestingkernel variable into the switches and
> > trickyness involved.
> > >>
> > >> First of all,if you look at it from the hardware
> > >> But you couldlook around...
> > d/msgid/pidp-11/16b2ea71-81e5-42bc-
> > aa54-4671c1b75679%40softjar.se <http://40softjar.se>
> <https://groups.google.com/d/ <https://groups.google.com/d/>
> > msgid/pidp-11/16b2ea71-81e5-42bc-
> > aa54-4671c1b75679%40softjar.se <http://40softjar.se>>.
> > >>
> > >
> >
> > --
> > You received thismessage because you are subscribed
> > msgid/pidp-11/64a2affc-2bdc-48da-9253-
> > d7a7aef4792d%40softjar.se <http://40softjar.se>
> <https://groups.google.com/d/ <https://groups.google.com/d/>
> > msgid/pidp-11/64a2affc-2bdc-48da-9253-
> > d7a7aef4792d%40softjar.se <http://40softjar.se>>.
> > <mailto:pidp-11+u...@googlegroups.com
> <mailto:pidp-11%2Bunsu...@googlegroups.com>>.
> > pidp-11/0a64edfb-8695-4dc0-8d81-620a34f4cd73n%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>
> > pidp-11/0a64edfb-8695-4dc0-8d81-620a34f4cd73n%40googlegroups.com
> <http://40googlegroups.com>?
> groups.google.com/d/msgid/
> pidp-11/8b8777cd-534f-41bb-88d0-94c29a0973eb%40softjar.se>.
multiuser, timesharing system, where you have to consider what any one
user/process can do that could impact others.
It's sortof complex in RSX and RSTS/E as well. It's just RT-11 that is
way simpler in this sense.
Johnny
> <mailto:vlai...@gmail.com> wrote:
> >
> > oh,
> > https://github.com/vlait/211bsd-csw <https://github.com/
> vlait/211bsd-csw> <https://github.com/ <https://github.com/>
> >
> > oh,
> > https://github.com/vlait/211bsd-csw <https://github.com/
> > vlait/211bsd-csw>
> >
> > forgot there is a later revision with some explanation of what's
> > under the hood for the "mem" driver
> >
> > -V
> >
> > On Tue, May 12, 2026 at 8:49 PM VilleLaitinen
> <vlai...@gmail.com <mailto:vlai...@gmail.com>>
> >
> > forgot there is a later revision with some explanation of what's
> > under the hood for the "mem" driver
> >
> > -V
> >
> > On Tue, May 12, 2026 at 8:49 PM VilleLaitinen
> > wrote:
> >
> > hi, some examples of kernel extensions for manipulating the
> > swreg at
> > https://github.com/vlait/2.11BSD-swreg-ioctl <https://github.com/
> vlait/2.11BSD-swreg-ioctl> <https://
> >
> > hi, some examples of kernel extensions for manipulating the
> > swreg at
> > https://github.com/vlait/2.11BSD-swreg-ioctl <https://github.com/
> > github.com/vlait/2.11BSD-swreg-ioctl <http://github.com/
> vlait/2.11BSD-swreg-ioctl>>
> >
> > -ioctl / fd access
> > -sysctl
> > -new syscalls (DigbyT posted these on the list years ago)
> >
> > Did not check if the patches can be applied to a current
> kernel
> > or not.. ymmv.
> > If someone wants to try them out but the patches cannot be
> > applied / you can't compile thekernel for some reason
> >
> > -ioctl / fd access
> > -sysctl
> > -new syscalls (DigbyT posted these on the list years ago)
> >
> > Did not check if the patches can be applied to a current
> kernel
> > or not.. ymmv.
> > If someone wants to try them out but the patches cannot be
> let me know
> > and i will try to help (or upload an pl499 with the mods
> applied)
> >
> > br,
> > -Ville
> >
> > ps. an idle loop that would inspect the memory location
> set by
> > the switches is a really nice debug idea :D
> >
> > On Tue, May 12, 2026 at 8:03 PM Johnny Billquist
> > and i will try to help (or upload an pl499 with the mods
> applied)
> >
> > br,
> > -Ville
> >
> > ps. an idle loop that would inspect the memory location
> set by
> > the switches is a really nice debug idea :D
> >
> > On Tue, May 12, 2026 at 8:03 PM Johnny Billquist
> > <b...@softjar.se <mailto:b...@softjar.se>> wrote:
> >
> > Ah. I had a couple of more comments as well... :-)
> >
> > On 5/12/26 18:58,'John D. Bruner' via [PiDP-11] wrote:
> > > Yes, a C program could open /dev/kmem, seek to
> 0177570,
> > and write 2 bytesto the display register. However, init
> >
> > Ah. I had a couple of more comments as well... :-)
> >
> > On 5/12/26 18:58,'John D. Bruner' via [PiDP-11] wrote:
> > > Yes, a C program could open /dev/kmem, seek to
> 0177570,
> > changes the kernel security level to 1 when it goes
> multi-
> > user. This is a one-way change. Until the next reboot,
> > nothing can open /dev/mem or /dev/kmem for writing,
> so the C
> > program would only work in single-user mode.
> >
> > As mentioned - secure level can be kept at 0, if desired.
> >
> > > In some earlier versions of UNIX, the kernel read the
> > switch register on every line clock interrupt. It fetched
> > the word at that address (data space, using the low-order
> > bit to determine if it was kernel or user space) and
> wrote
> > it to the displayregister. Thus, you could put the
> multi-
> > user. This is a one-way change. Until the next reboot,
> > nothing can open /dev/mem or /dev/kmem for writing,
> so the C
> > program would only work in single-user mode.
> >
> > As mentioned - secure level can be kept at 0, if desired.
> >
> > > In some earlier versions of UNIX, the kernel read the
> > switch register on every line clock interrupt. It fetched
> > the word at that address (data space, using the low-order
> > bit to determine if it was kernel or user space) and
> wrote
> address
> > of an interestingkernel variable into the switches and
> > watch its value change in real-time. So, although a C
> > program could write the display register, its value
> would be
> > clobbered by the kernel.
> >
> > So basically justcopying the switch register to the
> > program could write the display register, its value
> would be
> > clobbered by the kernel.
> >
> display
> > register?
> > Never seen that. But if that happens, yeah. You couldn't
> > play with it on
> > your own.
> >
> > > Another optionwould be to use the bus register,
> > register?
> > Never seen that. But if that happens, yeah. You couldn't
> > play with it on
> > your own.
> >
> as the
> > kernel idle loop does: execute a loop that moves the
> desired
> > value to R0 and executes a WAIT instruction. The
> processor
> > will wait for thenext interrupt, displaying the last
> > kernel idle loop does: execute a loop that moves the
> desired
> > value to R0 and executes a WAIT instruction. The
> processor
> value
> > on the bus. The process will look to the kernel like
> it is
> > CPU-bound, but ifthere's nothing else happening then
> > on the bus. The process will look to the kernel like
> it is
> it'll
> > keep running. There's no way to get the C compiler to
> > generate a WAIT instruction, but it's pretty trivial to
> > implement a function that calls it in assembly.
> >
> > Indeed. However, a user level program can have a WAIT
> > instruction in
> > there, but it's aNOP. So you need to do that in
> > keep running. There's no way to get the C compiler to
> > generate a WAIT instruction, but it's pretty trivial to
> > implement a function that calls it in assembly.
> >
> > Indeed. However, a user level program can have a WAIT
> > instruction in
> kernel mode
> > then. Which
> > is what the kernel does itself, and is how you have the
> > rotating lights,
> > while at the sametime, if the system becomes loaded, you
> > then. Which
> > is what the kernel does itself, and is how you have the
> > rotating lights,
> > see less of
> > that rotating light pattern...
> >
> > Johnny
> >
> > >
> > > --John
> > >
> > > On Tuesday, May 12th, 2026 at 09:02, Johnny Billquist
> > that rotating light pattern...
> >
> > Johnny
> >
> > >
> > > --John
> > >
> > > On Tuesday, May 12th, 2026 at 09:02, Johnny Billquist
> > <b...@softjar.se <mailto:b...@softjar.se>> wrote:
> > >
> > >> Hi.
> > >>
> > >> On 5/12/26 16:57, Jon Lopez wrote:
> > >>> Hello,
> > >>>
> > >>> I've recently gotten a PiDP-11 and I've been
> having a
> > great time with
> > >>> it! I've mostly been playing around in 2.11BSD,
> writing
> > some simple C
> > >>> programs. I'm interested in possibly writing a
> program
> > to control the
> > >>> data LEDs, however I'm not too sure where to
> start or
> > if it's even
> > >>> possible from such a relatively high level language
> > running on a largely
> > >>> abstracted OS. Does anyone have any ideas? Thanks!
> > >>
> > >> In principle,this is fairly easy. But there are some
> > >
> > >> Hi.
> > >>
> > >> On 5/12/26 16:57, Jon Lopez wrote:
> > >>> Hello,
> > >>>
> > >>> I've recently gotten a PiDP-11 and I've been
> having a
> > great time with
> > >>> it! I've mostly been playing around in 2.11BSD,
> writing
> > some simple C
> > >>> programs. I'm interested in possibly writing a
> program
> > to control the
> > >>> data LEDs, however I'm not too sure where to
> start or
> > if it's even
> > >>> possible from such a relatively high level language
> > running on a largely
> > >>> abstracted OS. Does anyone have any ideas? Thanks!
> > >>
> > trickyness involved.
> > >>
> > >> First of all,if you look at it from the hardware
> point
> > of view, the
> > >> data LEDs on the front panel can show a few different
> > things, depending
> > >> on what you select with that rotary dial.
> > >>
> > >> What you wanthere is to display the display
> > of view, the
> > >> data LEDs on the front panel can show a few different
> > things, depending
> > >> on what you select with that rotary dial.
> > >>
> > >>
> > >> I'm starting to think that maybe I should do a device
> > for it, with an
> > >> ioctl() to both read the switch register and set the
> > display register.
> > >> We'll see...
> > >>
> > >> Johnny
> > >>
> > >> --
> > >> 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%2Bu...@googlegroups.com>.
> > >> I'm starting to think that maybe I should do a device
> > for it, with an
> > >> ioctl() to both read the switch register and set the
> > display register.
> > >> We'll see...
> > >>
> > >> Johnny
> > >>
> > >> --
> > >> 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
> > >> To view this discussion visit https://
> groups.google.com/ <https://groups.google.com/>
> > d/msgid/pidp-11/16b2ea71-81e5-42bc-
> > aa54-4671c1b75679%40softjar.se <http://40softjar.se>
> <https://groups.google.com/d/ <https://groups.google.com/d/>
> > msgid/pidp-11/16b2ea71-81e5-42bc-
> > aa54-4671c1b75679%40softjar.se <http://40softjar.se>>.
> > >>
> > >
> >
> > --
> > You received thismessage 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%2Bu...@googlegroups.com>.
> > Google Groups "[PiDP-11]" group.
> > To unsubscribe from this group and stop receiving emails
> > from it, send an email to
> > To view this discussion visit https://
> groups.google.com/d/ <https://groups.google.com/d/>
> > msgid/pidp-11/64a2affc-2bdc-48da-9253-
> > d7a7aef4792d%40softjar.se <http://40softjar.se>
> <https://groups.google.com/d/ <https://groups.google.com/d/>
> > msgid/pidp-11/64a2affc-2bdc-48da-9253-
> > d7a7aef4792d%40softjar.se <http://40softjar.se>>.
> >
> > --
> > 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%2Bunsu...@googlegroups.com>
> > --
> > 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
> <mailto:pidp-11%2Bunsu...@googlegroups.com>>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/>
> > pidp-11/0a64edfb-8695-4dc0-8d81-620a34f4cd73n%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>
> > pidp-11/0a64edfb-8695-4dc0-8d81-620a34f4cd73n%40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>.
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se <mailto:b...@softjar.se> ||
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> 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%2Bunsu...@googlegroups.com>.
> 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
> To view this discussion visit https://groups.google.com/d/msgid/
> pidp-11/8b8777cd-534f-41bb-88d0-94c29a0973eb%40softjar.se <https://
> groups.google.com/d/msgid/
> pidp-11/8b8777cd-534f-41bb-88d0-94c29a0973eb%40softjar.se>.
Chuck McManis
May 12, 2026, 8:46:08 PM (2 days ago) May 12
to Johnny Billquist, pid...@googlegroups.com
On Tue, May 12, 2026 at 5:27 PM Johnny Billquist <b...@softjar.se> wrote:
Of course. A single user system is a completely different world than a
multiuser, timesharing system, where you have to consider what any one
user/process can do that could impact others.
Yup, memory management and all that. We had an 11/20 running RT-11 that was scanning images by stepping what was essentially a microscope across an image. I modified the code to display status in the display register and it was "easy", on the 11/55t we had running RSX-11M I don't recall if there was a QIO for it or not. Then again it was writing it in the idle process so unlikely you could map SYSPOOL or something like that to poke in new values.
--Chuck
Reply all
Reply to author
Forward
0 new messages