22 Jun
2016
22 Jun
'16
6:45 p.m.
On Wed, 22 Jun 2016, Rich Alderson wrote:
We have one running at LCM, attached to an instance of
dtCyber, the
6000/Cyber simulator, via John Zabolitzky's Xilinx-based display
adapter. We're in the process of refurbing the one that came with the
6500, which we may attach to the system at some point.
Is that "Living Computer Museum" ? You are in Seattle, right? I'll stop by
for sure if I'm in the area. I'm in Denver.
Not a matter of "didn't bother with",
but rather "were never allowed
to". You don't get to fuck with the console of a multimillion dollar
machine if you're not part of the operations or systems programming
staff.
Like I was saying with Chuck, I just wasn't thinking about that, but it
makes total sense when you put the $$$ into perspective.
For the same reason you do it in the PDP-6/PDP-10:
Data often comes in
the form of text characters, which are much smaller than the word size,
so it makes sense to pack them in.
I get it. I just wondered about the mechanics of it.
On the 6/10, the common method was 7-bit ASCII packed
5 per word. [...]
Everyone had some whack-a-doodle way to encode character sets back then
(and now it's just as bad or worse with things like UTF-8). People who
complain about twos-compliment being a weird hack should focus more on all
the ways folks encoded their charset. That's a veritable cornucopia of the
arbitrary.
ADJBP (ADJust Byte Pointer, which can back up as well
as move forward).
I find that weird, but possibly useful once I figured out how to implement
it. Did that morph into something else as the platform matured or newer
microcode hit the deck?
The networking code uses a lot of 8- and 16-bit byte
pointers, to handle
the fields in IP datagrams.
Convenient in this case, for sure. Hehe, not as convenient as me calling
bind(), connect(), and send(), but hey apples to oranges, I know. :-)
Other I/O code uses other byte sizes, to pull out or
set the relevant
parts of device register values.
Well, I'd think it'd be helpful with I/O related code to deal with the
real-world constellation of block devices from different devices. You
could ratchet up when you needed throughput, and back down when you needed
lower latency and finesse.
A quick example, which substitutes a space for a
rubout in a text string
without having to copy it into a second:
txtptr: point 7,string ; sets up to point to the non-existent byte
; before string
move 10,txtptr ; initialize pointer in loop
top: ildb 11,10 ; increments pointer, copies byte into AC 11
skipn 11 ; non-null value?
jrst bottom ; no, end of string, exit loop
caie 11,177 ; is it a rubout character
jrst top ; no, get next character in string
movei 11,40 ; change a rubout to a space
dpb 11,10 ; deposit byte into same location it came from
jrst top ; and continue
bottom: <whatever>
Ah. labels are grand, and yes no extra register or buffer needed!
PDP-10 operating systems in general use
null-terminated strings.
You mean the way $DIETY intended? :-)
Hope that helps you with capital wrapping.
Har! These days folks let the MS Paper Clip do that!
-Swift