[Simh] PDP10: KS10 console lights?

[Lars Brinkhoff]

Hello,

There is a USB device called the Panda Display. Its purpose is to allow
PDP-10 simulators to display internal state using LEDs, much like a
front panel. I have patched Richard Cornwell's KA10 simulator to make
the DATA PI, instruction display on the LEDs.

I have checked the KS10 instruction set. It doesn't have a DATAO PI,
instruction. However that particular opcode isn't in used, so it's just
a UUO. This is also the case for ITS microcode. Before I start working
on anything, I'd like to ask if it would be OK to repurpose this opcode
for its traditional use?

https://gitlab.com/DavidGriffith/panda-display

[Timothe Litt]

Post by Lars Brinkhoff
Hello,
There is a USB device called the Panda Display. Its purpose is to allow
PDP-10 simulators to display internal state using LEDs, much like a
front panel. I have patched Richard Cornwell's KA10 simulator to make
the DATA PI, instruction display on the LEDs.
I have checked the KS10 instruction set. It doesn't have a DATAO PI,
instruction. However that particular opcode isn't in used, so it's just
a UUO. This is also the case for ITS microcode. Before I start working
on anything, I'd like to ask if it would be OK to repurpose this opcode
for its traditional use?
https://gitlab.com/DavidGriffith/panda-display

Neither the KL nor the KS use DATAO PI,.  I don't have a problem with
implementing it for the KS.  It would need to act like any IO
instruction - MUUO in user mode, functional in Exec and with
User-In-Out.  It's also useless unless there is a place to display the
lights - so unless the display hardware is present, you might as well
let it MUUO.

The LIGHTS UUO (calli -1) was disabled in TOPS-10 when support for the
KI was dropped.  Early KS monitors compiled it as a NOP.  So to be
useful, you need a (trivial) monitor patch.  EDDT might need a tweak to
properly decode it.

Note that the corresponding DATAO PTR, (set switches, KI only) overlaps
TIOE on the KS, and thus could not be implemented.

[Lars Brinkhoff]

Post by Lars Brinkhoff
I have checked the KS10 instruction set. It doesn't have a DATAO
PI, instruction. However that particular opcode isn't in used, so
it's just a UUO. This is also the case for ITS microcode. Before I
start working on anything, I'd like to ask if it would be OK to
repurpose this opcode for its traditional use?

Neither the KL nor the KS use DATAO PI,. I don't have a problem with
implementing it for the KS. It would need to act like any IO
instruction - MUUO in user mode, functional in Exec and with
User-In-Out.

Of course.

The next problem is, how to access USB from SIMH? I have something that
works in Linux. I checked SIMH to see if there's a built in USB API
that works across operating system, but I didn't see any.

[Clem Cole]

Post by Lars Brinkhoff

Post by Lars Brinkhoff
I have checked the KS10 instruction set. It doesn't have a DATAO
PI, instruction. However that particular opcode isn't in used, so
it's just a UUO. This is also the case for ITS microcode. Before I
start working on anything, I'd like to ask if it would be OK to
repurpose this opcode for its traditional use?

Neither the KL nor the KS use DATAO PI,. I don't have a problem with
implementing it for the KS. It would need to act like any IO
instruction - MUUO in user mode, functional in Exec and with
User-In-Out.

Of course.
The next problem is, how to access USB from SIMH? I have something that
works in Linux. I checked SIMH to see if there's a built in USB API
that works across operating system, but I didn't see any.

I believe that device is using an FTDI chip set, which Linux/MacOS/Winders
etc will see as a dynamic serial port that appears at attach time. You
use open it and used traditional read and write. FWIW: If you grab the
sources to the Arduino IDE and look at the interface code in there - it
knows rules on how the port names will be generated in the different OSses
which will be thr one tricky part, since the rules.

[Bob Eager]

On Fri, 7 Sep 2018 23:17:56 -0400

Post by Clem Cole

Post by Lars Brinkhoff

Post by Lars Brinkhoff
I have checked the KS10 instruction set. It doesn't have a
DATAO PI, instruction. However that particular opcode isn't in
used, so it's just a UUO. This is also the case for ITS
microcode. Before I start working on anything, I'd like to ask
if it would be OK to repurpose this opcode for its traditional
use?

Neither the KL nor the KS use DATAO PI,. I don't have a problem
with implementing it for the KS. It would need to act like any IO
instruction - MUUO in user mode, functional in Exec and with
User-In-Out.

Of course.
The next problem is, how to access USB from SIMH? I have something
that works in Linux. I checked SIMH to see if there's a built in
USB API that works across operating system, but I didn't see any.

I believe that device is using an FTDI chip set, which
Linux/MacOS/Winders etc will see as a dynamic serial port that
appears at attach time. You use open it and used traditional read
and write. FWIW: If you grab the sources to the Arduino IDE and
look at the interface code in there - it knows rules on how the port
names will be generated in the different OSses which will be thr one
tricky part, since the rules.

The problem can also be (in at least FreeBSD) that the order of
enumeration of the USB ports can change depending on what else is
plugged in. This means that there is no consistent 'serial' port name.

I solved this by setting up a symbolic link to the correct port and
opening that in the program.

The symlink is generated (on FreeBSD) by an entry in devd.conf, which
detects the correct USB port by serial number, then matches that with
the 'serial' port name using the sysctl entries. Sounds complicated but
it's all scripted. One would hope that other systems can do something
similar.