Examine/Deposit buttons (et al) don't work while PiDP-10 is running
80 views
Skip to first unread message
Ric Werme
Aug 16, 2025, 9:17:27 PMAug 16
to PiDP-10
This is my first post, though I've made a few comments on other conversations along the way.
In poking around on ITS, and now the far more familiar (to me) TOPS-10, it appears simh isn't allowing the console buttons Examine This and Deposit this to work while the PDP-10 is running. And probably XCT (Execute) too. My first exposure to a KA-10 was as a computer operator, then I grew into an OS engineer. I spent a lot of time pushing buttons and looking at lights.
I'm finally getting serious about putting my PiDP-10 to good use, and I think I'm the first to report this problem. This is rather fundamental - to me, but few "normal" users dealt with this, and I guess most of us here are playing with programs that use the lights as an output device or are happy to see any relevant lights. BTW, programs that write to the data lights set the Program Data flag, pressing Examine This clears that and sets the Memory Data flag instead. The following is not impacted by program data.
Read the below, then refer to pages 4-20 and 4-23 at https://bitsavers.org/pdf/dec/pdp10/KA10/DEC-10-HMAA_D_KA10_Maint_Dec68.pdf for very gory details if you like them.
On a real KA-10, the Examine This and Deposit This buttons work while the machine is running. They inject memory references in between instructions. Therefore, I could look at kernel memory structures and whatnot from the console just by setting the address switches and pressing the examine button. (The "next" buttons didn't work as the address register got set to the PC before the next instruction executed, and there is no place to remember the last location touched.) On TOPS-10 we could force a crash be depositing something non-zero in location 30, and that would be checked every clock interrupt.
Furthermore, and even better, while the PDP-10 was running, if the program accessed the same address as was set in the address switches, the CPU would display the data value in the data lights - no need to push Examine This. This was very handy to see if the data structure in question was being accessed.
The most obvious way this was used was in the null job - when there was nothing else to run, the scheduler zeroed AC 0 (location 0), loaded a "AOJA 0,1" instruction into AC 1 and jumped there. Normally the address switches were set to 0, and we'd see AC 0 steadily increment until a real job needed the CPU. A glance at the console and we'd know if the machine was idle. If it was busy, we'd see if it was I/O bound or compute bound, and sometimes say what was running.
Reproducers:
By the console switches:
Start blinky running (pdpcontrol start 0)
Push STOP
Set address switches to zero
Set data switches to zero
Push Deposit This
Set address switches to 1
Set data switches to 344000,,000001 (AOJA 0,1) (Burned in my memory forever.)
Push Deposit This
Push Start
Set the address switches to 0
The data lights should display a running binary count.
The data lights will display, I guess the current instruction, 344000,,1. Fie!
Push Stop
Push Examine This
Note that AC0 has a non-zero number in it.
By simh:
Start blinky running (pdpcontrol start 0)
Push Stop (is there a simh way to do that? Oh - type ^E, it appears.)
Do: d 0 0
Do: d 1 344000000001
Do: go 1
Push Stop or type ^E
Do: e 0-1
See a non-zero number in AC0, 344...1 still in AC1.
I mentioned Execute above. That button also worked while the machine was running, but there wasn't much you could do with it, at least while TOPS-10 was running. On an idle system, I once wrote an infinite loop and XCT'ed the EXIT UUO (CALLI 12, IIRC) on the console. My program exited, as I hoped. It would have been ugly had the line clock interrupt code been running instead of my loop.
In poking around on ITS, and now the far more familiar (to me) TOPS-10, it appears simh isn't allowing the console buttons Examine This and Deposit this to work while the PDP-10 is running. And probably XCT (Execute) too. My first exposure to a KA-10 was as a computer operator, then I grew into an OS engineer. I spent a lot of time pushing buttons and looking at lights.
I'm finally getting serious about putting my PiDP-10 to good use, and I think I'm the first to report this problem. This is rather fundamental - to me, but few "normal" users dealt with this, and I guess most of us here are playing with programs that use the lights as an output device or are happy to see any relevant lights. BTW, programs that write to the data lights set the Program Data flag, pressing Examine This clears that and sets the Memory Data flag instead. The following is not impacted by program data.
Read the below, then refer to pages 4-20 and 4-23 at https://bitsavers.org/pdf/dec/pdp10/KA10/DEC-10-HMAA_D_KA10_Maint_Dec68.pdf for very gory details if you like them.
On a real KA-10, the Examine This and Deposit This buttons work while the machine is running. They inject memory references in between instructions. Therefore, I could look at kernel memory structures and whatnot from the console just by setting the address switches and pressing the examine button. (The "next" buttons didn't work as the address register got set to the PC before the next instruction executed, and there is no place to remember the last location touched.) On TOPS-10 we could force a crash be depositing something non-zero in location 30, and that would be checked every clock interrupt.
Furthermore, and even better, while the PDP-10 was running, if the program accessed the same address as was set in the address switches, the CPU would display the data value in the data lights - no need to push Examine This. This was very handy to see if the data structure in question was being accessed.
The most obvious way this was used was in the null job - when there was nothing else to run, the scheduler zeroed AC 0 (location 0), loaded a "AOJA 0,1" instruction into AC 1 and jumped there. Normally the address switches were set to 0, and we'd see AC 0 steadily increment until a real job needed the CPU. A glance at the console and we'd know if the machine was idle. If it was busy, we'd see if it was I/O bound or compute bound, and sometimes say what was running.
Reproducers:
By the console switches:
Start blinky running (pdpcontrol start 0)
Push STOP
Set address switches to zero
Set data switches to zero
Push Deposit This
Set address switches to 1
Set data switches to 344000,,000001 (AOJA 0,1) (Burned in my memory forever.)
Push Deposit This
Push Start
Set the address switches to 0
The data lights should display a running binary count.
The data lights will display, I guess the current instruction, 344000,,1. Fie!
Push Stop
Push Examine This
Note that AC0 has a non-zero number in it.
By simh:
Start blinky running (pdpcontrol start 0)
Push Stop (is there a simh way to do that? Oh - type ^E, it appears.)
Do: d 0 0
Do: d 1 344000000001
Do: go 1
Push Stop or type ^E
Do: e 0-1
See a non-zero number in AC0, 344...1 still in AC1.
I mentioned Execute above. That button also worked while the machine was running, but there wasn't much you could do with it, at least while TOPS-10 was running. On an idle system, I once wrote an infinite loop and XCT'ed the EXIT UUO (CALLI 12, IIRC) on the console. My program exited, as I hoped. It would have been ugly had the line clock interrupt code been running instead of my loop.
Lars Brinkhoff
Aug 17, 2025, 2:22:33 AMAug 17
to PiDP-10
Ric wrote:
In poking around on ITS, and now the far more familiar (to me) TOPS-10, it appears simh isn't allowing the console buttons Examine This and Deposit this to work while the PDP-10 is running. And probably XCT (Execute) too. My first exposure to a KA-10 was as a computer operator, then I grew into an OS engineer. I spent a lot of time pushing buttons and looking at lights.
This is something that we discussed back and forth between me, Oscar, Rich, and Angelo. My recollection is we concluded those switches are ineffective when the computer is in a running state. But I'm not so sure I remember everything correctly. The manual you refer to certainly seems to say otherwise.
By the way, I started writing down some procedures for testing the functions of the PiDP-10 panel. Maybe you can suggest some additions?
BTW, programs that write to the data lights set the Program Data flag, pressing Examine This clears that and sets the Memory Data flag instead. The following is not impacted by program data.
This should work. If it doesn't, that's a bug.
Ric Werme
Aug 17, 2025, 8:15:17 AMAug 17
to PiDP-10
Lars Brinkhoff wrote:
By the way, I started writing down some procedures for testing the functions of the PiDP-10 panel. Maybe you can suggest some additions?
I certainly belong there! I have some distractions today, then the weather turns cool enough to replace a small set of stairs outside, so I just wanted to post this quick note now. I'll look at it in detail soon enough.
I played around with Address Break and Stop a little. I remember one instance at DEC where someone claimed a 7 bit byte pointer used for I/O buffers was getting changed by the OS into a 36 bit byte pointer. I used either the Addr Break switches or DDT access and very quickly found the location in his program where he overwrote it. Very handy feature - once in a while.
Also, I do have a mental note to try clearing all of memory (gottta learn the simh command to install/remove core). We did that by pressing Stop, setting address and data switches to zero, pressing Deposit This, setting NXM Stop and Rept, then Deposit Next. The address lights would count up and freeze after the last word zeroed.
Oh - maintenance panel - I loved the speed control, it affects the rate that Rept repeats. I have to write up the hardest CPU problem I ever diagnosed. Rept, Examine This, and the speed control convinced me that _something_ was triggering random memory writes. By changing the speed and watching the read and write lights on a bay panel I concluded they recorded that last operation. It turned out a free running monostable in the DATAI path was playing havoc by writing whatever data was in some register to some location saved in some other register.
Also, it was fun running the CPU shift/rotate diagnostic with the Shift Counter Maintenance (?) switch set - that controlled the CPU shift logic so you could see every one bit shift within those instructions. The counter and data were on one of the CPU bay panels. No justification to emulate that!
Also, it was fun running the CPU shift/rotate diagnostic with the Shift Counter Maintenance (?) switch set - that controlled the CPU shift logic so you could see every one bit shift within those instructions. The counter and data were on one of the CPU bay panels. No justification to emulate that!
BTW, programs that write to the data lights set the Program Data flag, pressing Examine This clears that and sets the Memory Data flag instead. The following is not impacted by program data.This should work. If it doesn't, that's a bug.
Not a problem. I added that just in case someone asked about Program Data. You were supposed to read it and ignore it.
Richard C
Aug 17, 2025, 9:23:30 AMAug 17
to PiDP-10
I think this could be because on console Examine/Deposit on console might be accessing real memory, whereas simh is accessing Fast Memory. I would have to go through the schematics to see whether examine/deposit only work with real memory or would use fast registers while they are enabled.
In terms of using examine/deposit while the emulator is in RUN mode, these do work. The documented way to stop TOPS10 is to deposit a non-zero value into location 033. You can do this on emulator. Examine also works, however the lights are updated quicker then you could see.
Rich
Ric Werme
Aug 17, 2025, 9:31:27 PMAug 17
to PiDP-10
On a physical KA10, with Fast ACs enabled, it's impractical to get to the ghosted memory. The best way I could come up with would be to do disk I/O and have the DF10 data channel access locations 0-017.
The console only dealt with the same 0-017 locations that programs saw. That's why the TOPS-10 single instruction null job was used - it was easily recognized in the lights.
You mentioned "Examine also works, however the lights are updated quicker than you could see." From my experience it's completely okay that lights get updated quickly. That's fine, and completely desirable. Any access to the address in the switches should show the data. Set the address to 0, and almost any program will have that updating thousands of time per second.
Notes:
Notes:
1) When I boot TOPS-10, one of the programs opser starts runs in an infinite loop. I'll make a new post on that.
2) The 6.03 null job is more than "AOJA 0,1" I had always seen. It's now checking some location in memory and executing a UUO if it's non-zero or something like that. However, location 0 is still being incremented. I'll probably write a separate post on that too.
2) The 6.03 null job is more than "AOJA 0,1" I had always seen. It's now checking some location in memory and executing a UUO if it's non-zero or something like that. However, location 0 is still being incremented. I'll probably write a separate post on that too.
3) What is the PiDP-10 displaying? Mine is at the 6.03 null job, the PC is usually 1, which is a "SOJG 6,1" loop that reduces how often it checks real memory. That instruction is also being displayed in the Instruction lights (as it should ) and the Memory data, as it should but only if the address switches are set to 1. If they're set to 6, I should see the effect of the SOJG instruction, if they are set to 0, I should see that register increment. That's why your "however the lights are updated quicker than you could see" caught my eye. :-)
4) I'll set up the "AOJA 0,1" when I get a chance and try pressing Deposit This to zero location 0. That should restart the counter.
4) I'll set up the "AOJA 0,1" when I get a chance and try pressing Deposit This to zero location 0. That should restart the counter.
-Ric
Ric Werme
Aug 25, 2025, 9:56:14 PM (12 days ago) Aug 25
to PiDP-10
As I work my way along the learning curve, the memory data displayed on my PiDP-10 console has been demanding attention. My guess was that it is displaying whatever is going by in terms of memory references, which would explain why it looks a lot like the SOJG instruction in the TOPS-10 null job. That's seems to be what Rich was saying before.
I finally sat down and had a look at ka10_pipanel.c and kx10_cpu.c, confirming my suspicion. Basically, the simulator thread maintains a bunch of PDP-10 registers, including AB (Address Buffer), MB (Memory Buffer), and the Address Switches (AS). MB is getting displayed in the lights, when it's not commandeered by "DATAO PI,xxx" code.
I added a new "register", MBL (Memory Buffer we want in Lights), and display that instead of MB in ka10_pipanel.c, e.g.:
! leds = (((MI_flag)? MI : MBL) & MB_MASK0) >> MB_V_0;
The changed Mem_read_ka() and Mem_write_ka() in kx10_cpu.c to set MBL when that location is referenced with a read or write, e.g.:
*** 4084,4089 ****
--- 4085,4094 ----
if (AB < 020) {
MB = get_reg(AB);
+ #if PIDP10 /* If operator watching this location, show data */
+ if (AS == AB)
+ MBL = MB;
+ #endif
} else {
if (!page_lookup_ka(AB, flag, &addr, mod, cur_context, fetch))
return 1;
***************
*** 4096,4101 ****
--- 4101,4110 ----
watch_stop = 1;
sim_interval--;
MB = M[addr];
+ #if PIDP10 /* If operator watching this location, show data */
+ if (AS == addr)
+ MBL = MB;
+ #endif
}
if (fetch == 0 && hst_lnt) {
hst[hst_p].mb = MB;
***************
That's where the Examine This and Deposit This buttons are handled, so I added support there too:
--- 4502,4513 ----
if (examine_sw) { /* Examine memory switch */
AB = AS;
(void)Mem_read_nopage();
+ MBL = MB;
examine_sw = 0;
}
if (deposit_sw) { /* Deposit memory switch */
AB = AS;
! MBL = MB = SW;
(void)Mem_write_nopage();
deposit_sw = 0;
}
And hey - I can see the null job run! And see locations update on the fly if the program accesses them, and Examine This works, and as for Deposit This.... Oh, I can look at OS memory easily with a SPYseg (I can tell a CALLI that I want to see physical memory in my HISEG) The UUO/system call is in location 40, but I see an "AOS 601". I don't recall TOPS-10 counting the number of system calls executed, but 6.03 does. And when did they change the null job? Was I at DEC then?
.debug hello
LINK: Loading
[LNKDEB DDT Execution]
1/ 0 100000
calli 1,42$x
<SKP>
400040/ CALLI 5,@.JB41(17)
400041/ JSR 10730
410730/ CAM 3307
410731/ MOVEM 17,723
410732/ AOS 601
400601/ 2702 ./ 2724 ./ 2746 0 [I should not be able to modify it]
? [Error - I can't]
./ 3005
Yay, now it looks like a PDP-10 should! And I can deposit into 601 safely on the fly.
Over dinner it occurred to me that a neat option might be to display the "virtual" (the user's LOSEG/HISEG) address instead of always displaying the physical address, but that wouldn't be very useful on a busy system. E.g. setting the address switches to 601 could change the display with every context switch, at least if that's a frequently used location in a program. Probably not even worth an experiment. Well, maybe. Not tonight.
I am impressed at the details in the simulation. E.g. I had no idea that /* On KA or KI the AC is stored before Memory */. Heck, what does that even mean? What might POP P,P do? I'm sure I've never tried.
I finally sat down and had a look at ka10_pipanel.c and kx10_cpu.c, confirming my suspicion. Basically, the simulator thread maintains a bunch of PDP-10 registers, including AB (Address Buffer), MB (Memory Buffer), and the Address Switches (AS). MB is getting displayed in the lights, when it's not commandeered by "DATAO PI,xxx" code.
I added a new "register", MBL (Memory Buffer we want in Lights), and display that instead of MB in ka10_pipanel.c, e.g.:
! leds = (((MI_flag)? MI : MBL) & MB_MASK0) >> MB_V_0;
The changed Mem_read_ka() and Mem_write_ka() in kx10_cpu.c to set MBL when that location is referenced with a read or write, e.g.:
*** 4084,4089 ****
--- 4085,4094 ----
if (AB < 020) {
MB = get_reg(AB);
+ #if PIDP10 /* If operator watching this location, show data */
+ if (AS == AB)
+ MBL = MB;
+ #endif
} else {
if (!page_lookup_ka(AB, flag, &addr, mod, cur_context, fetch))
return 1;
***************
*** 4096,4101 ****
--- 4101,4110 ----
watch_stop = 1;
sim_interval--;
MB = M[addr];
+ #if PIDP10 /* If operator watching this location, show data */
+ if (AS == addr)
+ MBL = MB;
+ #endif
}
if (fetch == 0 && hst_lnt) {
hst[hst_p].mb = MB;
***************
That's where the Examine This and Deposit This buttons are handled, so I added support there too:
--- 4502,4513 ----
if (examine_sw) { /* Examine memory switch */
AB = AS;
(void)Mem_read_nopage();
+ MBL = MB;
examine_sw = 0;
}
if (deposit_sw) { /* Deposit memory switch */
AB = AS;
! MBL = MB = SW;
(void)Mem_write_nopage();
deposit_sw = 0;
}
Oops - I forgot the #ifdefs.
.debug hello
LINK: Loading
[LNKDEB DDT Execution]
1/ 0 100000
calli 1,42$x
<SKP>
400040/ CALLI 5,@.JB41(17)
400041/ JSR 10730
410730/ CAM 3307
410731/ MOVEM 17,723
410732/ AOS 601
400601/ 2702 ./ 2724 ./ 2746 0 [I should not be able to modify it]
? [Error - I can't]
./ 3005
Yay, now it looks like a PDP-10 should! And I can deposit into 601 safely on the fly.
Over dinner it occurred to me that a neat option might be to display the "virtual" (the user's LOSEG/HISEG) address instead of always displaying the physical address, but that wouldn't be very useful on a busy system. E.g. setting the address switches to 601 could change the display with every context switch, at least if that's a frequently used location in a program. Probably not even worth an experiment. Well, maybe. Not tonight.
I am impressed at the details in the simulation. E.g. I had no idea that /* On KA or KI the AC is stored before Memory */. Heck, what does that even mean? What might POP P,P do? I'm sure I've never tried.
Hey Rich, we need to talk about this getting this into the real code and what else I've missed. I didn't touch the KI/KL/KS code, KI needs it. Well, kinda, sorta. Nor the alternate KAs - ITS, BBN, and WAITS. Do they need it? Probably. I wouldn't think their pager hardware would modify console-related stuff.
-Ric
Richard C
Aug 26, 2025, 12:32:44 AM (12 days ago) Aug 26
to PiDP-10
Hi,
This is a neat patch, however this is not how the real machine behaved. One possible way to do this is to change the code so that when SINGLE_CYCLE is selected, the AS and SW registers are disconnected. And the display shows whatever the AS register is pointing at. Examine and Deposit could work during this time. Same with examine next and deposit next. If you look at the schematics of the KA and KI, the displays show the AB register and either the MB or MI register.
A simple modification would be to co-opted the Single Cycle switch to stop updating the AS and SW registers and use another internal register to hold the address switches (if examine next is desired), and to display (or modify) the contents of M[address switches],.
In terms of ./* On KA or KI the AC is stored before Memory */ this effects some what value gets put into the stack register if the pointer is to the register. On KA and KI the stack pointer AC is updated before the write of TOS. On others the update occurs after writing TOS. This is why the processor reference manual says not to use POP AC,AC as the results can vary. On KA & KI AC will have value of TOS, on others the correct stack pointer.
Rich
Ric Werme
Aug 26, 2025, 11:09:43 AM (12 days ago) Aug 26
to PiDP-10
Rich,
I'll add sitting down and communing with the schematics (I saw a link somewhere) on my to do list, but it won't be very high. I haven't looked at them on over 50 years.
Do note though while you say that's not how the KA10 worked:
I spent five years at CMU on two different KAs starting my operator days with plugging zeros into the running OS to see how it would crash before our nightly power-down to poking around OS data structures and progressing to studying how my kernel-level ARPAnet code behaved. The KA address switches made a great binary abacus, and I often made use of the fact that MI indicator lights updated when the OS touched the location of interest.
https://wermenh.com/rsb/ (seismic stuff)
I'll add sitting down and communing with the schematics (I saw a link somewhere) on my to do list, but it won't be very high. I haven't looked at them on over 50 years.
Do note though while you say that's not how the KA10 worked:
I spent five years at CMU on two different KAs starting my operator days with plugging zeros into the running OS to see how it would crash before our nightly power-down to poking around OS data structures and progressing to studying how my kernel-level ARPAnet code behaved. The KA address switches made a great binary abacus, and I often made use of the fact that MI indicator lights updated when the OS touched the location of interest.
The TOPS-10 "AOJA 0,1" null job would be pointless, as would the nifty Stanford null job.
Page 4-23 of https://bitsavers.org/pdf/dec/pdp10/KA10/DEC-10-HMAA_D_KA10_Maint_Dec68.pdf clearly states "The memory indicator register (MI) usually follows the contents of the register addressed in the address switches. This is accomplished by a comparator, which dynamically compares the the address selected by the memory address interface (MAI) with the AS (address switches)...."
That last item will be helpful when I get to the schematics.
I also have to figure out how to upload files to TOPS-10. There seems to be weird stuff in the telnet 2020 links with delays in sending/echoing stuff (it may be why kermit doesn't work for me). I can read one file per boot from the PTR: device, but apparently I have to tell something when I "mount" a new "paper tape". I also promised folks to prepare a post on meteor explosions to join my https://raspberryshake.org/raspberry-shakes-and-booms-hear-helicopters/ , but that's a whole separate project (and an awesome device that uses a Raspberry Pi).
-RicI also have to figure out how to upload files to TOPS-10. There seems to be weird stuff in the telnet 2020 links with delays in sending/echoing stuff (it may be why kermit doesn't work for me). I can read one file per boot from the PTR: device, but apparently I have to tell something when I "mount" a new "paper tape". I also promised folks to prepare a post on meteor explosions to join my https://raspberryshake.org/raspberry-shakes-and-booms-hear-helicopters/ , but that's a whole separate project (and an awesome device that uses a Raspberry Pi).
https://wermenh.com/rsb/ (seismic stuff)
Reply all
Reply to author
Forward
0 new messages