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
