I've Done All The Dumb Things

[Unibus]

Hi,

I have a PiDP-1 Rack with USB for Tape I/O, keyboard and mouse. Attached is a video capture of go,[tab]lac x[return]lup,[tab]cma[return][tab]sar 4s[return] i.e code taken from the Programming the DEC PDP-1 web page.

Some problems:-

• First Tab on line 3 (before the sar 4s) has gone.  Text is shown at the 1 minute mark of the vidro with missing tab. If I had typed [space][tab] it would've tabbed correctly for the instruction. 
• Punched a tape to the USB stick with Sense Switch 6 up (on). On readback after moving the USB stick from the punch to the reader slot with switch 6 up (on) I received parity errors.
• When punching to the USB stick there were two installed (Reader and Punch). On readback only one USB stick (after move from punch to reader) and no files created.
• I double checked the USB assignments and they were OK.
• There were a couple of hidden files on the USBs from the manufacturer. Reformatted the USB sticks and a punch file was produced. Still had parity issues on the read.

What have I done wrong this time?

Regards,

Garry

[Unibus]

Hi,

Just out of curiosity I wanted to disassemble the Expensive Typewriter code to try to work out the problems I'm having with reading and punching text. The first section of tape didn't visually appear to match the disassembled code. Binary code values of the tape was:-

32
77
51
73
00
02
32
77
52
32
77
51

Converting to 18-bits

327751

730002

327752

327751

Translates to

 Memory   Memory

Address  Contents

   7751     730002 

      7752

 

   

[Matthias Barthel]

Hi,

This is on every rim-file the beginning. This is the rim-loader. The rim-loader ends with 2 jmp-codes, then comes the the start address and the end address from the first program block. It looks like 320100 and 320150, this is followed by the first lines of the program.

On linux you can easily view the bits octal with the xxd command .

Here you can see the code of the rim-loader : https://bitsavers.org/bits/DEC/pdp1/papertapeImages/utils/dmpRIM.c

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/CAHDxiR6%3DQP9QgfrZ5e31SOJz0kjah3a_O46J9UY_DVyVZCcfVQ%40mail.gmail.com.

[Bill E]

And here it is, annotated. You can also look at tapes with my disassembler, included in the regular distribution, which is more informative than an octal dump.

* BIN loader that is typically loaded by an initial RIM: (digital-1-3-s-mb_ddt.bin)
 *
 * 7751: 730002 rpb          read tape
 * 7752: 327760 dio 7760     will be a 'dio startaddr' or a 'jmp progstart', deposit to 7760
 * 7753: 107760 xct 7760     execute what we just read; if a jmp, we're done otherwise it's meaningless
 * 7754: 327776 dio 7776     initialize checksum
 * 7755: 730002 rpb          read tape
 * 7756: 327777 dio 7777     deposit to 7777, will be 'dio endaddr + 1'
 * 7757: 730002 rpb          read tape, top of loading loop
 * 7760: 60aaaa dio cur_addr put word in current pc location
 * 7761: 217760 lac i 7760   add the word we stored to the checksum
 * 7762: 407776 add 7776     add to checksum
 * 7763: 247776 dac 7776     update checksum
 * 7764: 447760 idx 7760     7760++, makes the dio point to the next adress to store in
 * 7765: 527777 sas 7777     skip if AC == 'dio endaddr + 1'
 * 7766: 607757 jmp 7757     not done, loop
 * 7767: 207776 lac 7776     add 'dio endaddr + 1' to checksum
 * 7770: 407777 add 7777     the computed checksum is is now in the AC
 * 7771: 730002 rpb          read tape, is checksum from tape
 * 7772: 327776 dio 7776     deposit to 7776
 * 7773: 527776 sas 7776     skip if AC == 7776
 * 7774: 760400 hlt          bad checksum
 * 7775: 607751 jmp 7751     ready for another block or a jmp, back to top
 * 7776: checksum
 * 7777: 32aaaa     dio endaddr + 1
 *
Bill

[Unibus]

Hi,

Just something strange and probably never a problem. I was trying to understand the rcr (rotate right) instruction by hand assembling then single stepping code using the switches on my PiDP-1 Rack. When single stepping I seemed to be getting weird display results on rotates with the Accumulator changing when executing NOPs.

Addr Machine Assembler Telewriter In-Out Accumulator  Comment

0xx0 760200  cla               25 xxxxxx 000000       Clear Accumulator

0xx1 764000  cli               25 000000 000000       Clear In-Out Register

0xx2 720000  tyi               25 000025 000000       Type In (Typewriter Buffer held Concise Code - Letter V)

0xx3 760000  nop               25 000025 000000       NOP

0xx4 673077  rcr 6s            25 000000 520000       Rotate Right 6 bits

0xx5 760000  nop               25 000000 250000       NOP

Tried another bit pattern.

0xx4 673077  rcr 6s            47 000001 160000       Rotate Right 6 bits (Concise Code - Letter J)

0xx5 760000  nop               47 000000 470000       NOP

Replacing the nop with a dac stored the correct accumulator contents into memory. So not a significant problem, just something to remember if manually single stepping on the console. 

In the dim, dark past I had to single step microcode on occasion. I was hoping to move from single instruction to single step mode but it appeared only single instruction mode was functional for me. 

Regards,

Garry

[Matthias Barthel]

Garry,

I think I have read in the manual or the maintainance-manual that some opcodes work differently in single step mode, because they need more than one cycle to be fully processed. I think that it especially affects the rotate and shift group.

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/CAHDxiR4f4yMM2K9994qVoJwGrw6kGte8F3ATEE6OmzCxmo1iCw%40mail.gmail.com.

[Bill E]

That's correct and annoying. It particularly affects rotate/shift and some other AC operations. Makes debugging via the classic single-step a bit challenging. However, the lights to update to the proper state eventually and the instructions actually execute properly. Looking at the pc and mem buffer are good indications of what's actually going on. DEC even notes this behavior in one offhand sentence in the manual.

Bill

[Unibus]

Hi,

That sent me digging and I loved reading the text buried in the Maintenance Manual:

However, during the next cycle zero (in which a new instruction is retrieved from memory) the command level SH / RO remains true until IR is cleared at TP4 . Thus the last three possible SH / RO pulses in a shift group instruction actually occur during cycle zero of the following instruction.

Which explains why the Accumulator and In-Out Register contents changed when executing a NOP.

And a totally unrelated subject. There was

• Type 23 parallel drum drive which could simultaneously read and write 4,096 words of core memory. 
• Type 24 serial drum that could store 64, 128 or 256 data blocks of 256 words.

Regards,

Garry

On Sat, 6 Dec 2025 at 23:20, Bill E <wjegr...@gmail.com> wrote:

That's correct and annoying. It particularly affects rotate/shift and some other AC operations. Makes debugging via the classic single-step a bit challenging. However, the lights to update to the proper state eventually and the instructions actually execute properly. Looking at the pc and mem buffer are good indications of what's actually going on. DEC even notes this behavior in one offhand sentence in the manual.

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/1934024e-aa38-4a86-abe7-50700f38abe8n%40googlegroups.com.

[Bill E]

I implemented the type 23 drum a while back, it's quite useful. The type 24 drum is far slower, not of particular use. One nice thing, using it is simple. Much, much simpler than the mag tape interface.

Bill

[Unibus]

I started trying to learn PDP-1 assembly code and started running across some obscure instructions. So in keeping with doing all the dumb things and wasting some time, I went hunting and found the same functionality could have multiple names. For example, various documents had the Line Printer with various entries for the same functions. While the Clock hardware related codes didn't seem to be fully documented. It appears some codes may have been deleted when moving into production while others were introduced e.g. PDP-1D variant. 

Regards,

Garry