Re: Purchased a Microvax 3800
On Tue, Dec 1, 2015 at 7:25 PM, devin davison wrote: > > Just figured id post about it here, to show my progress twords getting it > running. > > http://postimg.org/gallery/fztxjqbe/ Another tip: If you haven't done so already, remove the CPU console panel and check to see if there is still a NiCad battery pack installed. The battery pack is mounted under the console panel PCB and you have to remove a few screws holding the PCB in place to get to it. If the pack is still installed then remove it. If it hasn't already started leaking it is only a matter of time before it does and starts corroding the PCB.
Re: Purchased a Microvax 3800
On Tue, Dec 1, 2015 at 7:25 PM, devin davison wrote: > > I purchased a m7769 DSSI controller card online, so that is one more step > in the direction of getting the machine all together. Still waiting to find > the controller for the tape drive and a dssi hard drive, although they look > to be pretty affordable on ebay. > > Just figured id post about it here, to show my progress twords getting it > running. > > http://postimg.org/gallery/fztxjqbe/ > > --Devin Those pictures show an H3602 console panel for an M7626 KA660 VAX 4000 Model 200 CPU. That CPU (and also the M7624 KA640 MicroVAX 3300/3400 CPU which uses the same H3602 console panel) has a built in DSSI controller so there shouldn't be a real need to add a separate M7769 KFQSA DSSI controller. An M7559 TQK70 controller should be easy and cheap to find, but that's the last thing I would spend money on myself. Dealing with TK50 / TK70 drives has never been worth the bother for me. If I already had a working DSSI disk drive to use but no way to load software I would consider buying an M5976 KZQSA SCSI controller which can be used with a SCSI CD-ROM drive to install software. (Make an offer on this one maybe: http://www.ebay.com/itm/151702502097 ) If I didn't already have a working DSSI disk drive to use I might consider buying a general purpose SCSI controller such as an Emulex UC07 which can be used with both SCSI disks and CD-ROMs. There are some on eBay around the $200 range. http://www.ebay.com/itm/161129117629 http://www.ebay.com/itm/141122593003 I don't have any Emulex SCSI controller myself. I have several CMD and Dilog SCSI controllers which work well.
Purchased a Microvax 3800
I purchased a Microvax 3800 a few weeks ago. I have not really had the time to really take a good look at it until now. I still do not have the needed power cord to power it Up. Looks like a standard PC power cord with a notch in it. I found a place that sells them online, still waiting for it to get here. I was told the machine was removed from working service, however it looks like it has been sitting for quite some time. The hard drive, hard drive controller, and tape controller have been removed. I purchased a m7769 DSSI controller card online, so that is one more step in the direction of getting the machine all together. Still waiting to find the controller for the tape drive and a dssi hard drive, although they look to be pretty affordable on ebay. Just figured id post about it here, to show my progress twords getting it running. http://postimg.org/gallery/fztxjqbe/ --Devin
Re: [multicians] Emacs humor
(Pst - Henry Burkhardt III based Data General's original program editor on DEC's 1967 version incarnation of "TECO", and it is still still alive today...) On 12/1/2015 7:13 PM, Rich Alderson wrote: From: Johnny Billquist Sent: Tuesday, December 01, 2015 5:44 PM Thanks for chiming in, Johnny! Keeps me from having to do it. :-) But, of course, Emacs was not developed on Lisp machines. TECO was a DEC edtior/language, and Emacs came about on PDP-10 machines. I think originally with ITS, but it could also be ran on TOPS-20. Well, technically, the original TECO was developed on the PDP-1 at MIT, taken up by DEC, and ported to most of their subsequent systems. The version of TECO in which EMACS was developed was an MIT-AI Lab local creation with no DEC input, for ITS; that version of TECO, and therefore EMACS, was ported to TENEX and TOPS-20. About the cokebottle reference, here's the quote from JARGON.TXT: COKEBOTTLE n. Any very unusual character. MIT people complain about the "control-meta-cokebottle" commands at SAIL, and SAIL people complain about the "altmode-altmode-cokebottle" commands at MIT. So that really did not have anything to do with Emacs. But this is all ancient history by now, and I'm not surprised history has twisted some facts... :-) The history of "bucky bits" goes back even further than most people know. Before the PDP-6 came into existence, SAIL ran a computer-assisted lab using a PDP-1 with specially modified terminals. These were designed by a Swiss computer scientist later known for creating a paedogogical Algol derivative, a gentleman whom the SAIL graduate students did not like and called (referring to a malocclusion) "Bucky Beaver".[1] The extra 2 bits on the terminals became "bucky bits". With the PDP-6 came a design for special terminals which included not 2 but 5 bucky bits (though 2 were unnamed on the Stanford keyboard), in a 14-bit character set[2] where Control was the 200 bit, Meta was the 400 bit, and Top was the 4000 bit. Top referred to non-Latin characters on the keys, above the usual typewriter characters we all know and love. Internally, Top+character was translated to a value in the range 0-37, which were graphical rather than ASCII control characters. I used to use one of these terminals from time to time, to read mailing lists hosted on SU-AI (AKA Sail.Stanford.EDU in a more modern era), and to SUPDUP to my account on MIT-AI, where I could use EMACS with real bucky bits just as $DEITY intended. Up next here is to modify a terminal emulation program to provide SUPDUP and the Stanford character set in order to talk to our WAITS[3] system on the net. Rich [1] The name of an animated spokescreature for Ipana toothpaste. [2] Hey, if RMS can do that in the EMACS manual... [3] The OS, descended from the PDP-6 monitor and thus related to Tops-10 which SAIL ran on the PDP-6, the PDP-10/PDP-6 dual processor, the KL-10/PDP-10/PDP-6 triprocessor, and KL-10/PDP-10 dual processor and the KL-10 uniprocessor between 1964 and 1990. Also ran on a Foonly at CCRMA and a KL-10 at Lawrence Livermore Labs, but retired earlier. Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/
RE: [multicians] Emacs humor
From: Johnny Billquist Sent: Tuesday, December 01, 2015 5:44 PM Thanks for chiming in, Johnny! Keeps me from having to do it. :-) > But, of course, Emacs was not developed on Lisp machines. TECO was a DEC > edtior/language, and Emacs came about on PDP-10 machines. I think > originally with ITS, but it could also be ran on TOPS-20. Well, technically, the original TECO was developed on the PDP-1 at MIT, taken up by DEC, and ported to most of their subsequent systems. The version of TECO in which EMACS was developed was an MIT-AI Lab local creation with no DEC input, for ITS; that version of TECO, and therefore EMACS, was ported to TENEX and TOPS-20. > About the cokebottle reference, here's the quote from JARGON.TXT: > COKEBOTTLE n. Any very unusual character. MIT people complain about > the "control-meta-cokebottle" commands at SAIL, and SAIL people > complain about the "altmode-altmode-cokebottle" commands at MIT. > So that really did not have anything to do with Emacs. But this is all > ancient history by now, and I'm not surprised history has twisted some > facts... :-) The history of "bucky bits" goes back even further than most people know. Before the PDP-6 came into existence, SAIL ran a computer-assisted lab using a PDP-1 with specially modified terminals. These were designed by a Swiss computer scientist later known for creating a paedogogical Algol derivative, a gentleman whom the SAIL graduate students did not like and called (referring to a malocclusion) "Bucky Beaver".[1] The extra 2 bits on the terminals became "bucky bits". With the PDP-6 came a design for special terminals which included not 2 but 5 bucky bits (though 2 were unnamed on the Stanford keyboard), in a 14-bit character set[2] where Control was the 200 bit, Meta was the 400 bit, and Top was the 4000 bit. Top referred to non-Latin characters on the keys, above the usual typewriter characters we all know and love. Internally, Top+character was translated to a value in the range 0-37, which were graphical rather than ASCII control characters. I used to use one of these terminals from time to time, to read mailing lists hosted on SU-AI (AKA Sail.Stanford.EDU in a more modern era), and to SUPDUP to my account on MIT-AI, where I could use EMACS with real bucky bits just as $DEITY intended. Up next here is to modify a terminal emulation program to provide SUPDUP and the Stanford character set in order to talk to our WAITS[3] system on the net. Rich [1] The name of an animated spokescreature for Ipana toothpaste. [2] Hey, if RMS can do that in the EMACS manual... [3] The OS, descended from the PDP-6 monitor and thus related to Tops-10 which SAIL ran on the PDP-6, the PDP-10/PDP-6 dual processor, the KL-10/PDP-10/PDP-6 triprocessor, and KL-10/PDP-10 dual processor and the KL-10 uniprocessor between 1964 and 1990. Also ran on a Foonly at CCRMA and a KL-10 at Lawrence Livermore Labs, but retired earlier. Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/
Re: [multicians] Emacs humor
On 12/1/2015 5:43 PM, Johnny Billquist wrote: Nice. But, of course, Emacs was not developed on Lisp machines. TECO was a DEC edtior/language, and Emacs came about on PDP-10 machines. I think originally with ITS, but it could also be ran on TOPS-20. About the cokebottle reference, here's the quote from JARGON.TXT: COKEBOTTLE n. Any very unusual character. MIT people complain about the "control-meta-cokebottle" commands at SAIL, and SAIL people complain about the "altmode-altmode-cokebottle" commands at MIT. So that really did not have anything to do with Emacs. But this is all ancient history by now, and I'm not surprised history has twisted some facts... :-) It is emacs, if you read other discussions of emacs. The evolution of various OS, input methods and terminals and the many homes for versions of emacs lead to these terms being deeply embedded in the editor. Just hitting a key and having the cursor move back was once a difficult feat. Then having the character there erased by a space (and accurately have both motions accurately reflected in the buffer) was another event. Emacs truly went crazy expanding the editing and keyboard motions. I don't have an article to point to, and am not an emacs expert / fan. I sent this thread on to another friend who is a very old time user as my usual aggravation. thanks Jim Johnny On 2015-12-02 02:31, jwsmobile wrote: This is a funny cartoon and subsequent discussion thread from the Multics discussion group about emacs. Names and personal info edited out due to archival by unknown parties of the list and that these folks might not want names and certainly not email addresses archived. Mentioning that not as a criticism, just to explain the format. I also edited the thread back to bottom posting. Original XKCD cartoon link. https://xkcd.com/378/ >> From: Multicians >> Subject: Re: [multicians] Emacs humor >> >>> >>> >>> Thanks, Gary. As an emacs diehart, I fully appreciate that. In fact, there is a silly phrase that many emacs users use, when referring to all the obscure key bindings that you get by default with emacs, or can create. It.s called: >>> >>> Control-Meta-Shift-Cokebottle >>> >>> I believe the history (someone can correct me if I.m wrong) is that Emacs was developed at the MIT AI Lab (by Richard Stallman) and initially written in Teco. It was developed on Lisp machines, which sported lots of modification keys on its keyboard. These included Control, Shift, Hyper, Meta, Super (and perhaps more). Naturally, emacs took advantage of some of these . at least those that were available on multiple terminals or could be emulated on lesser terminals. I remember when I worked at MIT LCS (down the hall from MIT AI), we had a key binding on our Lisp Machines that called the elevator to the 8th floor. I don.t remember the key binding, but I.m sure it used a few of these modification keys (and probably .e. for .elevator. as the modified key). In any case, the class of these funky key bindings was referred to as Control-Meta-Shift-Cokebottle. >>> >>> I.m sure I.ve gotten some of the facts wrong, but I.m also sure that at least someone on this list will correct me! >>> >>> . Eric >> > > >> On Dec 1, 2015, at 11:30 AM, Ken > wrote: >> >> >> I seem to recall that one of the Lisp machine keyboard modifiers was "Top", and that the phrase was therefore >> >>> Control-Shift-Meta-Top-Cokebottle >>> >> Where, of course, you were typing the "Cokebottle" key with the Control, Shift, Meta, and Top modifier keys depressed. >> >> I think the elevator hack involved the AI Lab PDP-6 (or maybe, later, PDP-10), but I wouldn't be surprised if it migrated to the Lisp machines, too The old -6, especially, had added hardware to enable it to control the various robot devices the AI lab played with. Some AI Lab hardware guys gained access to the machinery room on the 10th floor and added some extra relay circuitry to one of the elevator controllers, and it wasn't much of a stretch to run the control wires down to the 9th floor machine room. IIRC it took a few years for whatever company was responsible for maintaining the elevators to discover the unauthorized modification and remove it. >> >> How long it stayed removed is an entirely different question, of course. >> >> Ken >> MIT-LCS '72-'80 >> Multics ARPANET software >> On 12/1/2015 11:42 AM, Eric [multicians] wrote: > > > I just knew I had that facts wrong! Yes, you.re right. I remember the Top key now. > > I do know that the elevator hack worked on Lisp machines, but I think you.re right that it also worked on some other interfaces. I remember getting frustrated when I.d be .ready to leave. (at 2am, or so), and would call the elevator, and then I.d have to fix .one more bug., and by the time I got to the elevator, I actually had to push the boring old button to get the elevator doors to open! :-) > > . Eric
Re: [multicians] Emacs humor
On 2015-12-02 02:43, Johnny Billquist wrote: Nice. But, of course, Emacs was not developed on Lisp machines. TECO was a DEC edtior/language, and Emacs came about on PDP-10 machines. I think originally with ITS, but it could also be ran on TOPS-20. I should probably correct myself right away. TECO was developed at MIT. DEC included it in pretty much all systems they made, but it did not originate with them. I don't know if TECO was ported elsewhere back then, but there certainly exists TECO ports to other system nowadays. But the ITS TECO was/is rather different than most other dialects of TECO, so don't expect to be able to run Emacs on any TECO interpreter you might have... Johnny About the cokebottle reference, here's the quote from JARGON.TXT: COKEBOTTLE n. Any very unusual character. MIT people complain about the "control-meta-cokebottle" commands at SAIL, and SAIL people complain about the "altmode-altmode-cokebottle" commands at MIT. So that really did not have anything to do with Emacs. But this is all ancient history by now, and I'm not surprised history has twisted some facts... :-) Johnny On 2015-12-02 02:31, jwsmobile wrote: This is a funny cartoon and subsequent discussion thread from the Multics discussion group about emacs. Names and personal info edited out due to archival by unknown parties of the list and that these folks might not want names and certainly not email addresses archived. Mentioning that not as a criticism, just to explain the format. I also edited the thread back to bottom posting. Original XKCD cartoon link. https://xkcd.com/378/ >> From: Multicians >> Subject: Re: [multicians] Emacs humor >> >>> >>> >>> Thanks, Gary. As an emacs diehart, I fully appreciate that. In fact, there is a silly phrase that many emacs users use, when referring to all the obscure key bindings that you get by default with emacs, or can create. It.s called: >>> >>> Control-Meta-Shift-Cokebottle >>> >>> I believe the history (someone can correct me if I.m wrong) is that Emacs was developed at the MIT AI Lab (by Richard Stallman) and initially written in Teco. It was developed on Lisp machines, which sported lots of modification keys on its keyboard. These included Control, Shift, Hyper, Meta, Super (and perhaps more). Naturally, emacs took advantage of some of these . at least those that were available on multiple terminals or could be emulated on lesser terminals. I remember when I worked at MIT LCS (down the hall from MIT AI), we had a key binding on our Lisp Machines that called the elevator to the 8th floor. I don.t remember the key binding, but I.m sure it used a few of these modification keys (and probably .e. for .elevator. as the modified key). In any case, the class of these funky key bindings was referred to as Control-Meta-Shift-Cokebottle. >>> >>> I.m sure I.ve gotten some of the facts wrong, but I.m also sure that at least someone on this list will correct me! >>> >>> . Eric >> > > >> On Dec 1, 2015, at 11:30 AM, Ken > wrote: >> >> >> I seem to recall that one of the Lisp machine keyboard modifiers was "Top", and that the phrase was therefore >> >>> Control-Shift-Meta-Top-Cokebottle >>> >> Where, of course, you were typing the "Cokebottle" key with the Control, Shift, Meta, and Top modifier keys depressed. >> >> I think the elevator hack involved the AI Lab PDP-6 (or maybe, later, PDP-10), but I wouldn't be surprised if it migrated to the Lisp machines, too The old -6, especially, had added hardware to enable it to control the various robot devices the AI lab played with. Some AI Lab hardware guys gained access to the machinery room on the 10th floor and added some extra relay circuitry to one of the elevator controllers, and it wasn't much of a stretch to run the control wires down to the 9th floor machine room. IIRC it took a few years for whatever company was responsible for maintaining the elevators to discover the unauthorized modification and remove it. >> >> How long it stayed removed is an entirely different question, of course. >> >> Ken >> MIT-LCS '72-'80 >> Multics ARPANET software >> On 12/1/2015 11:42 AM, Eric [multicians] wrote: > > > I just knew I had that facts wrong! Yes, you.re right. I remember the Top key now. > > I do know that the elevator hack worked on Lisp machines, but I think you.re right that it also worked on some other interfaces. I remember getting frustrated when I.d be .ready to leave. (at 2am, or so), and would call the elevator, and then I.d have to fix .one more bug., and by the time I got to the elevator, I actually had to push the boring old button to get the elevator doors to open! :-) > > . Eric -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: [multicians] Emacs humor
Nice. But, of course, Emacs was not developed on Lisp machines. TECO was a DEC edtior/language, and Emacs came about on PDP-10 machines. I think originally with ITS, but it could also be ran on TOPS-20. About the cokebottle reference, here's the quote from JARGON.TXT: COKEBOTTLE n. Any very unusual character. MIT people complain about the "control-meta-cokebottle" commands at SAIL, and SAIL people complain about the "altmode-altmode-cokebottle" commands at MIT. So that really did not have anything to do with Emacs. But this is all ancient history by now, and I'm not surprised history has twisted some facts... :-) Johnny On 2015-12-02 02:31, jwsmobile wrote: This is a funny cartoon and subsequent discussion thread from the Multics discussion group about emacs. Names and personal info edited out due to archival by unknown parties of the list and that these folks might not want names and certainly not email addresses archived. Mentioning that not as a criticism, just to explain the format. I also edited the thread back to bottom posting. Original XKCD cartoon link. https://xkcd.com/378/ >> From: Multicians >> Subject: Re: [multicians] Emacs humor >> >>> >>> >>> Thanks, Gary. As an emacs diehart, I fully appreciate that. In fact, there is a silly phrase that many emacs users use, when referring to all the obscure key bindings that you get by default with emacs, or can create. It.s called: >>> >>> Control-Meta-Shift-Cokebottle >>> >>> I believe the history (someone can correct me if I.m wrong) is that Emacs was developed at the MIT AI Lab (by Richard Stallman) and initially written in Teco. It was developed on Lisp machines, which sported lots of modification keys on its keyboard. These included Control, Shift, Hyper, Meta, Super (and perhaps more). Naturally, emacs took advantage of some of these . at least those that were available on multiple terminals or could be emulated on lesser terminals. I remember when I worked at MIT LCS (down the hall from MIT AI), we had a key binding on our Lisp Machines that called the elevator to the 8th floor. I don.t remember the key binding, but I.m sure it used a few of these modification keys (and probably .e. for .elevator. as the modified key). In any case, the class of these funky key bindings was referred to as Control-Meta-Shift-Cokebottle. >>> >>> I.m sure I.ve gotten some of the facts wrong, but I.m also sure that at least someone on this list will correct me! >>> >>> . Eric >> > > >> On Dec 1, 2015, at 11:30 AM, Ken > wrote: >> >> >> I seem to recall that one of the Lisp machine keyboard modifiers was "Top", and that the phrase was therefore >> >>> Control-Shift-Meta-Top-Cokebottle >>> >> Where, of course, you were typing the "Cokebottle" key with the Control, Shift, Meta, and Top modifier keys depressed. >> >> I think the elevator hack involved the AI Lab PDP-6 (or maybe, later, PDP-10), but I wouldn't be surprised if it migrated to the Lisp machines, too The old -6, especially, had added hardware to enable it to control the various robot devices the AI lab played with. Some AI Lab hardware guys gained access to the machinery room on the 10th floor and added some extra relay circuitry to one of the elevator controllers, and it wasn't much of a stretch to run the control wires down to the 9th floor machine room. IIRC it took a few years for whatever company was responsible for maintaining the elevators to discover the unauthorized modification and remove it. >> >> How long it stayed removed is an entirely different question, of course. >> >> Ken >> MIT-LCS '72-'80 >> Multics ARPANET software >> On 12/1/2015 11:42 AM, Eric [multicians] wrote: > > > I just knew I had that facts wrong! Yes, you.re right. I remember the Top key now. > > I do know that the elevator hack worked on Lisp machines, but I think you.re right that it also worked on some other interfaces. I remember getting frustrated when I.d be .ready to leave. (at 2am, or so), and would call the elevator, and then I.d have to fix .one more bug., and by the time I got to the elevator, I actually had to push the boring old button to get the elevator doors to open! :-) > > . Eric -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
RE: Seattle free teletype??
From: Jason Howe Sent: Tuesday, December 01, 2015 4:03 PM > Check out the 3rd picture > http://seattle.craigslist.org/skc/zip/5340655886.html > Someone go get this -- I'm stuck at work with no car at the moment Our TTY specialist (who also works at the Communications Museum in Seattle) pointed out that this is a KSR32 (with ASR capability added), that is, a 5-level rather than 8-level machine. Should whoever acquired this not need a Baudot TTY, please get in touch! We can certainly put it to use on old hardware. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/
Re: [multicians] Emacs humor
This is a funny cartoon and subsequent discussion thread from the Multics discussion group about emacs. Names and personal info edited out due to archival by unknown parties of the list and that these folks might not want names and certainly not email addresses archived. Mentioning that not as a criticism, just to explain the format. I also edited the thread back to bottom posting. Original XKCD cartoon link. https://xkcd.com/378/ >> From: Multicians >> Subject: Re: [multicians] Emacs humor >> >>> >>> >>> Thanks, Gary. As an emacs diehart, I fully appreciate that. In fact, there is a silly phrase that many emacs users use, when referring to all the obscure key bindings that you get by default with emacs, or can create. It.s called: >>> >>> Control-Meta-Shift-Cokebottle >>> >>> I believe the history (someone can correct me if I.m wrong) is that Emacs was developed at the MIT AI Lab (by Richard Stallman) and initially written in Teco. It was developed on Lisp machines, which sported lots of modification keys on its keyboard. These included Control, Shift, Hyper, Meta, Super (and perhaps more). Naturally, emacs took advantage of some of these . at least those that were available on multiple terminals or could be emulated on lesser terminals. I remember when I worked at MIT LCS (down the hall from MIT AI), we had a key binding on our Lisp Machines that called the elevator to the 8th floor. I don.t remember the key binding, but I.m sure it used a few of these modification keys (and probably .e. for .elevator. as the modified key). In any case, the class of these funky key bindings was referred to as Control-Meta-Shift-Cokebottle. >>> >>> I.m sure I.ve gotten some of the facts wrong, but I.m also sure that at least someone on this list will correct me! >>> >>> . Eric >> > > >> On Dec 1, 2015, at 11:30 AM, Ken > wrote: >> >> >> I seem to recall that one of the Lisp machine keyboard modifiers was "Top", and that the phrase was therefore >> >>> Control-Shift-Meta-Top-Cokebottle >>> >> Where, of course, you were typing the "Cokebottle" key with the Control, Shift, Meta, and Top modifier keys depressed. >> >> I think the elevator hack involved the AI Lab PDP-6 (or maybe, later, PDP-10), but I wouldn't be surprised if it migrated to the Lisp machines, too The old -6, especially, had added hardware to enable it to control the various robot devices the AI lab played with. Some AI Lab hardware guys gained access to the machinery room on the 10th floor and added some extra relay circuitry to one of the elevator controllers, and it wasn't much of a stretch to run the control wires down to the 9th floor machine room. IIRC it took a few years for whatever company was responsible for maintaining the elevators to discover the unauthorized modification and remove it. >> >> How long it stayed removed is an entirely different question, of course. >> >> Ken >> MIT-LCS '72-'80 >> Multics ARPANET software >> On 12/1/2015 11:42 AM, Eric [multicians] wrote: > > > I just knew I had that facts wrong! Yes, you.re right. I remember the Top key now. > > I do know that the elevator hack worked on Lisp machines, but I think you.re right that it also worked on some other interfaces. I remember getting frustrated when I.d be .ready to leave. (at 2am, or so), and would call the elevator, and then I.d have to fix .one more bug., and by the time I got to the elevator, I actually had to push the boring old button to get the elevator doors to open! :-) > > . Eric
Re: "Bounce buffer" copyright [was Re: flash (or ide) storage for unibus 11?]
On 12/01/2015 7:52 AM, Johnny Billquist wrote: On 2015-12-01 16:49, John Robertson wrote: On 11/28/2015 3:41 PM, Mouse wrote: Love that term, "bounce buffer" (I wrote a whole package to support them in a packet switch I did) - I'm officially adopting it, right now! :-) Hey - anything that anyone writes is automatically copyrighted. I realize you...may have been less than entirely serious. But what you wrote could easily be taken seriously, especially by someone only partially inside our culture. So I'm going to be a minor killjoy here. Yes, anything written now is automatically copyrighted in most jursidctions. But (a) the term "bounce buffer" is small enough and obvious enough it probably cannot be copyrighted on its own (and is not infringing when copied in isolation), (b) was quite possibly published without copyright claim before automatic copyright and is thus in the public domain now, and (c) is of uncertain authorship anyway. So... So first you need permission to use that! ...you actually don't. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B Further to this discussion on 'automatic' copyright. That only came into being in 1989 - prior to that ALL documents had to have either the symbol (c) or the word COPYRIGHT as well as the name of the person or organization on the document (if a single page) or the front page or the index page. This was true for the period prior to 1978, however during the period 1978 through 1989 you had up to five years to copyright the document, otherwise it passed into public domain. https://copyright.cornell.edu/resources/publicdomain.cfm One could trademark an expression 'bounce buffer', however as Mouse points out you can't exactly copyright it. And all of these commands are only relevant if you are in the US. Much of the rest of the world signed the Berne convention long before that. Johnny Or if you are dealing with documents published only in the United States. As the US did not adhere to the Berne convention until 1989 many products are public domain. I also don't know what the situation is in the Berne convention with respect to corporate ownership of copyrights (works for hire). Here in Canada such corporate rights do not exist - the creator of the document is the holder of the copyright. My point was that depending on when the document was published in the US it may (or may not) be public domain if at the time of publishing it had the then required Copyright symbol or word. John :-#)# -- John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9 Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames) www.flippers.com "Old pinballers never die, they just flip out"
Re: Oberon and the OberonStation (retro-style FPGA computing)
On 11/23/2015 7:28 PM, William Maddox wrote: The revived 2013 re-issue of Niklaus Wirth's Oberon system is a joy to behold. If you've never heard of Oberon before, it is a minimalistic education-oriented language and operating system designed after Wirth had taken a (second) sabattical at PARC in the 80's. The new version runs on a custom RISC processor, implemented in an FPGA, instead of the NS3032 in the orginal Ceres workstations. Originally, it required a Digilent "Spartan 3 Starter Kit" with a custom-built daughterboard providing a few additional connectors. This board is no longer made, however, and no other FPGA development board appears to provide the 32-bit wide fast SRAM the Oberon CPU required. Recently, a new board, the OberonStation, has come onto the market that was designed specifically for Oberon, and will boot up Oberon 2013 out of the box. It also looks like an excellent platform for other retro-style FPGA CPU designs that want to stay away from complex SDRAM controllers and the caches they like to feed. My OberonStation arrived a couple of days ago, and it's really amazing to see what can be done with a hardware and software stack that is small enough to actually read and understand. https://www.inf.ethz.ch/personal/wirth/ Do you have 5 volt I/O with the OberonStaion FPGA? I was thinking of using it as general FPGA card. Ben.
Re: Seattle free teletype??
Already says 'teletype machine is gone'... Mike On Wed, Dec 2, 2015 at 1:02 PM, Jason Howe wrote: > Check out the 3rd picture > > http://seattle.craigslist.org/skc/zip/5340655886.html > > > Someone go get this -- I'm stuck at work with no car at the moment > > > --Jason -- http://www.corestore.org 'No greater love hath a man than he lay down his life for his brother. Not for millions, not for glory, not for fame. For one person, in the dark, where no one will ever know or see.'
Re: Seattle free teletype??
It's gone now! Sent from my iPhone > On Dec 1, 2015, at 6:02 PM, Jason Howe wrote: > > Check out the 3rd picture > > http://seattle.craigslist.org/skc/zip/5340655886.html > > > Someone go get this -- I'm stuck at work with no car at the moment > > > --Jason
Re: Interfacing PDP 11/05 to VT 50
On Tue, Dec 1, 2015 at 3:37 PM, Mattis Lind wrote: > ... should be passive... > The same goes for the VT1XX option on > the VT100 which had two switches which one could set. I have a couple of the VT1XX 20mA options, if anyone is looking. New in Box. -ethan
Seattle free teletype??
Check out the 3rd picture http://seattle.craigslist.org/skc/zip/5340655886.html Someone go get this -- I'm stuck at work with no car at the moment --Jason
Re: Interfacing PDP 11/05 to VT 50
2015-12-01 20:58 GMT+01:00 Joseph Lang : > The current loop is actually "proper" . > There are 3 parts to current loop > 1) transmitter (switch) > 2) receiver (opto coupler in dec stuff) > 3) current source > > You will have problems if things don't match. An active transmitter has to > connect to a passive receiver. > Passive transmitter to active receiver. > Active means it has a current source,passive no current source. > > The 11/05 is active tx active rx. So expects contacts on the keyboard and > the selector magnet in the printer. > Most industrial current loop converters are not this way out of the box. > Now, if this is a VT50, according to my printset it should be passive and thus if polarity matches should work (unless broken of course). Looking in the VT52 printset the current loop adapter seems to be configureable using jumpers for either active or passive. The same goes for the VT1XX option on the VT100 which had two switches which one could set. /Mattis > > Joe > > > On Dec 1, 2015, at 1:56 PM, Paul Koning wrote: > > > > > >> On Dec 1, 2015, at 1:22 PM, william degnan > wrote: > >> > >> ... > >> Sorry about the wording of my question. Thanks for the replies. I was > >> only able to get the VT50 to receive, I could not send. So I decided to > >> research the problem. I found the link above, the author of the page > says > >> in effect 20mA did not work (for him) as desired. So I was wondering if > >> anyone here has been successful to attach a M9970 to a VT50 or VT52. I > >> spend more time on it, but I was curious if it was even worth it given > the > >> hardware. > >> > >> The author writes: > >> > >> -start quote-- > >> > >> I first tried to connect a PC with the 11/05 over a industrial > >> RS232-to-20mA converter, but this failed. > >> > >> A 20mA interface works by one side providing a 20mA current, which > drives > >> receiver and transmitter of the closed loops for Transmit and Receive. > >> > >> But the 20mA interface of the PDP-11/05 is not a proper one: the > receiver > >> is more like a low impedance voltage sensor, while the transmitter > simply > >> switches voltage at the levels +3.5V to -15 V. At best you call the > >> PDP-11/05 serial interface a "TTY interface": it is well suited to read > >> data generated by mechanical switches to GND, and driving solenoids for > >> transmit data. > >> -end quote-- > > > > Hm. I wonder by what definition it is not "proper". A current loop > transmitter, in an electronic terminal as opposed to a mechanical one, > would be a switching transistor that turns the current on and off. The > only issues I can think of are the voltage rating used, and the polarity. > For example, in earlier 60 mA loops (for the Model 15 Teletype and machines > of that era) you might find loop voltages around 100 volts or so, with a > big series resistor. The purpose was to reduce the distortion from the > inductance in the loop (in the receive solenoid). In the later 20 mA loops > I would expect lower voltages to be used. But the specification is pretty > wide open -- "20 mA" is really about all there is. You can build > conforming devices with optocouplers, switching transistors, solenoids and > cam operated switches, etc. > > > > I don't know what "simply switches voltage at the levels +3.5V to -15 V" > means. The voltages at the pins aren't directly relevant, only the voltage > difference between the two transmit pins -- or more precisely, the > resulting current in the loop. I could easily imagine that in the off > state both pins are at -15 while in the on state one goes to +3.5, or > something like that, driving through a resistor of a bit under 1000 ohms. > > > > The fact that the "industrial converter" didn't work does not imply that > the VT50 would have troubles. Just the opposite, actually; I would assume > that DEC would make sure that its 20 mA terminals work with its 20 mA host > interfaces. > > > > Did you check the voltage and current in the two loops when you hooked > it up? I wonder if you might have the polarity backwards on one of the > circuits, assuming that the devices involved care. > > > >paul > > >
Re: Interfacing PDP 11/05 to VT 50
The current loop is actually "proper" . There are 3 parts to current loop 1) transmitter (switch) 2) receiver (opto coupler in dec stuff) 3) current source You will have problems if things don't match. An active transmitter has to connect to a passive receiver. Passive transmitter to active receiver. Active means it has a current source,passive no current source. The 11/05 is active tx active rx. So expects contacts on the keyboard and the selector magnet in the printer. Most industrial current loop converters are not this way out of the box. Joe > On Dec 1, 2015, at 1:56 PM, Paul Koning wrote: > > >> On Dec 1, 2015, at 1:22 PM, william degnan wrote: >> >> ... >> Sorry about the wording of my question. Thanks for the replies. I was >> only able to get the VT50 to receive, I could not send. So I decided to >> research the problem. I found the link above, the author of the page says >> in effect 20mA did not work (for him) as desired. So I was wondering if >> anyone here has been successful to attach a M9970 to a VT50 or VT52. I >> spend more time on it, but I was curious if it was even worth it given the >> hardware. >> >> The author writes: >> >> -start quote-- >> >> I first tried to connect a PC with the 11/05 over a industrial >> RS232-to-20mA converter, but this failed. >> >> A 20mA interface works by one side providing a 20mA current, which drives >> receiver and transmitter of the closed loops for Transmit and Receive. >> >> But the 20mA interface of the PDP-11/05 is not a proper one: the receiver >> is more like a low impedance voltage sensor, while the transmitter simply >> switches voltage at the levels +3.5V to -15 V. At best you call the >> PDP-11/05 serial interface a "TTY interface": it is well suited to read >> data generated by mechanical switches to GND, and driving solenoids for >> transmit data. >> -end quote-- > > Hm. I wonder by what definition it is not "proper". A current loop > transmitter, in an electronic terminal as opposed to a mechanical one, would > be a switching transistor that turns the current on and off. The only issues > I can think of are the voltage rating used, and the polarity. For example, > in earlier 60 mA loops (for the Model 15 Teletype and machines of that era) > you might find loop voltages around 100 volts or so, with a big series > resistor. The purpose was to reduce the distortion from the inductance in > the loop (in the receive solenoid). In the later 20 mA loops I would expect > lower voltages to be used. But the specification is pretty wide open -- "20 > mA" is really about all there is. You can build conforming devices with > optocouplers, switching transistors, solenoids and cam operated switches, etc. > > I don't know what "simply switches voltage at the levels +3.5V to -15 V" > means. The voltages at the pins aren't directly relevant, only the voltage > difference between the two transmit pins -- or more precisely, the resulting > current in the loop. I could easily imagine that in the off state both pins > are at -15 while in the on state one goes to +3.5, or something like that, > driving through a resistor of a bit under 1000 ohms. > > The fact that the "industrial converter" didn't work does not imply that the > VT50 would have troubles. Just the opposite, actually; I would assume that > DEC would make sure that its 20 mA terminals work with its 20 mA host > interfaces. > > Did you check the voltage and current in the two loops when you hooked it up? > I wonder if you might have the polarity backwards on one of the circuits, > assuming that the devices involved care. > >paul >
Re: Interfacing PDP 11/05 to VT 50
> On Dec 1, 2015, at 1:22 PM, william degnan wrote: > > ... > Sorry about the wording of my question. Thanks for the replies. I was > only able to get the VT50 to receive, I could not send. So I decided to > research the problem. I found the link above, the author of the page says > in effect 20mA did not work (for him) as desired. So I was wondering if > anyone here has been successful to attach a M9970 to a VT50 or VT52. I > spend more time on it, but I was curious if it was even worth it given the > hardware. > > The author writes: > > -start quote-- > > I first tried to connect a PC with the 11/05 over a industrial > RS232-to-20mA converter, but this failed. > > A 20mA interface works by one side providing a 20mA current, which drives > receiver and transmitter of the closed loops for Transmit and Receive. > > But the 20mA interface of the PDP-11/05 is not a proper one: the receiver > is more like a low impedance voltage sensor, while the transmitter simply > switches voltage at the levels +3.5V to -15 V. At best you call the > PDP-11/05 serial interface a "TTY interface": it is well suited to read > data generated by mechanical switches to GND, and driving solenoids for > transmit data. > -end quote-- Hm. I wonder by what definition it is not "proper". A current loop transmitter, in an electronic terminal as opposed to a mechanical one, would be a switching transistor that turns the current on and off. The only issues I can think of are the voltage rating used, and the polarity. For example, in earlier 60 mA loops (for the Model 15 Teletype and machines of that era) you might find loop voltages around 100 volts or so, with a big series resistor. The purpose was to reduce the distortion from the inductance in the loop (in the receive solenoid). In the later 20 mA loops I would expect lower voltages to be used. But the specification is pretty wide open -- "20 mA" is really about all there is. You can build conforming devices with optocouplers, switching transistors, solenoids and cam operated switches, etc. I don't know what "simply switches voltage at the levels +3.5V to -15 V" means. The voltages at the pins aren't directly relevant, only the voltage difference between the two transmit pins -- or more precisely, the resulting current in the loop. I could easily imagine that in the off state both pins are at -15 while in the on state one goes to +3.5, or something like that, driving through a resistor of a bit under 1000 ohms. The fact that the "industrial converter" didn't work does not imply that the VT50 would have troubles. Just the opposite, actually; I would assume that DEC would make sure that its 20 mA terminals work with its 20 mA host interfaces. Did you check the voltage and current in the two loops when you hooked it up? I wonder if you might have the polarity backwards on one of the circuits, assuming that the devices involved care. paul
Re: Interfacing PDP 11/05 to VT 50
> > > There is a DF11-F module that converts TTY to EIA and back again, 2 2-slot cards, cable,e tc. (Page 4-80 in the peripheral handbook from 73-74). The handbook did not indicate a specific PDP 11 from this time (05/10/35/40, etc) Anyway, the teletype is fine for now, I need to be able to save/load programs than see on a pretty screen.I will probably just use a serial card if it came to that. -- Bill
Re: Interfacing PDP 11/05 to VT 50
On Tue, Dec 1, 2015 at 12:43 PM, Ethan Dicks wrote: > On Tue, Dec 1, 2015 at 11:55 AM, Paul Koning > wrote: > > I'm not sure I understand the question correctly. That article clearly > points out the 20 mA wires, and presumably that's where your ASR33 is > connected. The VT50 comes (according to the peripherals handbook) with a > standard 20 mA interface, optional RS232 interface. So it sounds like it > would be a matter of finding where the 20 mA connector on the VT50 is, and > plugging into that. > > > > Interestingly enough, the VT52 is listed as supporting either kind of > interface, but only one; "specify at time of order". > > I don't know that I've taken apart a VT50 or if there are internal > differences, but for the VT52, there's a ~2"x5" (from memory) PCB with > interface circuitry for either EIA or 20mA and a permanently-attached > cable with the appropriate connector on the host end. You take the > bottom of the terminal off, pop the board, pop the other one on and > it's switched. > > It would not be difficult to replicate either board, either by hand or > with a fabricated PCB. > > -ethan > Sorry about the wording of my question. Thanks for the replies. I was only able to get the VT50 to receive, I could not send. So I decided to research the problem. I found the link above, the author of the page says in effect 20mA did not work (for him) as desired. So I was wondering if anyone here has been successful to attach a M9970 to a VT50 or VT52. I spend more time on it, but I was curious if it was even worth it given the hardware. The author writes: -start quote-- I first tried to connect a PC with the 11/05 over a industrial RS232-to-20mA converter, but this failed. A 20mA interface works by one side providing a 20mA current, which drives receiver and transmitter of the closed loops for Transmit and Receive. But the 20mA interface of the PDP-11/05 is not a proper one: the receiver is more like a low impedance voltage sensor, while the transmitter simply switches voltage at the levels +3.5V to -15 V. At best you call the PDP-11/05 serial interface a "TTY interface": it is well suited to read data generated by mechanical switches to GND, and driving solenoids for transmit data. -end quote-- -- Bill
Re: Sector Interleave
On 2015-12-01 19:04, Johnny Billquist wrote: On 2015-12-01 18:09, Paul Koning wrote: I suppose it's possible to do something like interleaving where consecutive sector addresses are not physically adjacent on the media. Come to think of it, that's exactly what the MSCP RX50 controllers do, since MSCP implements the mapping from LBA to physical addresses in the controller, not the host. But in older systems where the controllers handle physical addresses and the mapping from LBA is in the driver, interleave is handled there (or above). Yes, the "hardware" interleave is what I was assuming everyone here was talking about. Otherwise there is no point/need to format to get the interleaving... With disks, this is perfectly doable, as the block number is in the block header, and the drive/controller scans headers until the current block passes by. There is no real reason to actually place the disk blocks in consecutive physical order on the disk. Any order will work. That's what soft sectors gets you. To point it out more clearly, in case this seems muddled. The hardware interlaving done by MSCP for the RX50 do not really have anything to do with MSCP and the ability to map blocks around. When the floppies are formatted, the sector numbers are written in the header of each sector. All later operations always search for the correct sector by checking the sector header. As such, this not only works on MSCP controllers, but any floppy, on any floppy controller. And in theory also on pretty much any other kind of disk as well. The trick is the ability to format the disk and write the header. For most disks you cannot do that yourself. Johnny
Re: Sector Interleave
On 12/01/2015 09:25 AM, Charles Anthony wrote: This meant that a command to "read sector 4" would return whichever sector 4 passed under the head first. If you did 'read sector 2', 'read sector 4' you would get the first one; 'read sector 6', 'read sector 4', you would get the second. Interleaving for obfustication, not efficiency. A particularly cute one was employed with early versions of Harvard Graphics for the PC. A protection key was encoded in the gap between sectors. Since the PC 765 controller writes individual sectors (i.e. looks for a IDAM, then a DAM, then turns on Write Gate), it was very difficult (but not impossible) to replicate this stuff, as using a regular write command would cause the data separator to lose sync in the write splice area. On the other hand, it was pretty simple for a WD-17/27 type FDC to duplicate this. --Chuck
Re: Sector Interleave
On 2015-12-01 18:09, Paul Koning wrote: On Nov 30, 2015, at 8:39 PM, Johnny Billquist wrote: On 2015-12-01 02:19, Paul Koning wrote: On Nov 30, 2015, at 8:12 PM, Johnny Billquist wrote: ... DECtape never did interleaving that I know of. Sure it does. The DOS format, which was adopted by RSTS, has 4 way interleaving. If you write a 500 block file, it writes every 4th block forward, then fills in one set of gaps reverse, then forward and backward again, resulting in finally all blocks used. This is a software function, of course, and actually implemented in the file system, but it's certainly interleaving. It doesn't apply to contiguous files (supported in DOS but not RSTS), which is why RSTS V4A sysgen with output to DECtape took so long -- writing a contiguous CIL file, in block order, madly seeking back & forth. Oh. You mean that the software decided to use blocks 0,4,8,12,... Yes, that would be doable. I was thinking of interleaving at the format level. But such interleaving means the software have to keep rather good track of things... True. Interleaving, as described in this thread, is typically a software function; the software uses the blocks in an order different from the "ascending by 1" natural ordering. I suppose it's possible to do something like interleaving where consecutive sector addresses are not physically adjacent on the media. Come to think of it, that's exactly what the MSCP RX50 controllers do, since MSCP implements the mapping from LBA to physical addresses in the controller, not the host. But in older systems where the controllers handle physical addresses and the mapping from LBA is in the driver, interleave is handled there (or above). Yes, the "hardware" interleave is what I was assuming everyone here was talking about. Otherwise there is no point/need to format to get the interleaving... With disks, this is perfectly doable, as the block number is in the block header, and the drive/controller scans headers until the current block passes by. There is no real reason to actually place the disk blocks in consecutive physical order on the disk. Any order will work. That's what soft sectors gets you. And in addition to the interleaving someone also mentioned that you can stagger blocks between tracks, so that you have time for a track switch and then hit the next sector in optimal time, if you really work at it. Johnny
RE: Interfacing PDP 11/05 to VT 50
> The VT50 comes (according to the peripherals handbook) with a standard 20 mA > interface, optional RS232 interface. So it sounds like it would be a matter > of finding > where the 20 mA connector on the VT50 is, and plugging into that. > > Interestingly enough, the VT52 is listed as supporting either kind of > interface, but only > one; "specify at time of order". I suspect it's the same as the VT55 which I have. That terminal has a little daughterboard on the main logic board which contains the interface buffers etc. Mine is 20mA current loop, I assume the RS232 interface is a simialr daughterboard that replaces it.
Re: Sector Interleave
On Tue, 1 Dec 2015, Paul Koning wrote:
On the subject of DECtape, and "keeping good track of things" -- DOS
format DECtape has 510 bytes per tape block, the other two bytes are
used as the link word. It's a bit like MSDOS FAT format (or CDC 6000
series, which did it 20 years earlier), but with the links in the blocks
rather than in a separate region. The directory points to the first
block, and you get the next block address when you read the first.
Take a look also at Apple-DOS!
"Beneath Apple DOS" seemed to be the canonical reference to it.
IFF I'm remembering correctly, . . .
DIRectory on track 17.
256 bytes per sector.
Each sector within a file has 252 bytes of data and a 4 byte pointer to
the track and sector number of the next sector
GCR (with a different GCR pattern for the 13 sector V 16 sector disks)
It had a sector interleave, but inefficiencies in the OS (copying bytes
to and from a buffer) resulted in the need to change the interleave a few
times.
There are prob'ly some here who remember all of the details.
I had little to no experience with it, other than writing the file
system software to go with a crude flux-transition board ("Apple
Turnover") to copy files from 13 and 16 sector Apple DOS, Apple CP/M,
Apple Pascal, and Pro-DOS.
It never worked well.
Re: Interfacing PDP 11/05 to VT 50
On Tue, Dec 1, 2015 at 11:55 AM, Paul Koning wrote: > I'm not sure I understand the question correctly. That article clearly > points out the 20 mA wires, and presumably that's where your ASR33 is > connected. The VT50 comes (according to the peripherals handbook) with a > standard 20 mA interface, optional RS232 interface. So it sounds like it > would be a matter of finding where the 20 mA connector on the VT50 is, and > plugging into that. > > Interestingly enough, the VT52 is listed as supporting either kind of > interface, but only one; "specify at time of order". I don't know that I've taken apart a VT50 or if there are internal differences, but for the VT52, there's a ~2"x5" (from memory) PCB with interface circuitry for either EIA or 20mA and a permanently-attached cable with the appropriate connector on the host end. You take the bottom of the terminal off, pop the board, pop the other one on and it's switched. It would not be difficult to replicate either board, either by hand or with a fabricated PCB. -ethan
Re: Interfacing PDP 11/05 to VT 50
> On Nov 30, 2015, at 9:14 PM, william degnan wrote: > > I have an 11/05 with ASR 33 for I/O. I am using the M9970 console card to > make the connection. I have loaded papertape BASIC into core (16K) and it > boots up from 000 000 to the TTY, I can type in programs, etc. > > Question - I'd like to switch over to a VT 50 in 20ma mode. Not sure if > this is possible based on what I read here: > > http://www.retrocmp.com/how-tos/interfacing-to-a-pdp-1105/144-interfacing-with-a-pdp-1105-sorting-the-wires I'm not sure I understand the question correctly. That article clearly points out the 20 mA wires, and presumably that's where your ASR33 is connected. The VT50 comes (according to the peripherals handbook) with a standard 20 mA interface, optional RS232 interface. So it sounds like it would be a matter of finding where the 20 mA connector on the VT50 is, and plugging into that. Interestingly enough, the VT52 is listed as supporting either kind of interface, but only one; "specify at time of order". paul
Re: Sector Interleave
On Tue, Dec 1, 2015 at 9:09 AM, Paul Koning wrote: > > > On Nov 30, 2015, at 8:39 PM, Johnny Billquist wrote: > > > > On 2015-12-01 02:19, Paul Koning wrote: > >> > >>> On Nov 30, 2015, at 8:12 PM, Johnny Billquist > wrote: > >>> > >>> ... > >>> DECtape never did interleaving that I know of. > >> > >> Sure it does. The DOS format, which was adopted by RSTS, has 4 way > interleaving. If you write a 500 block file, it writes every 4th block > forward, then fills in one set of gaps reverse, then forward and backward > again, resulting in finally all blocks used. > >> > >> This is a software function, of course, and actually implemented in the > file system, but it's certainly interleaving. It doesn't apply to > contiguous files (supported in DOS but not RSTS), which is why RSTS V4A > sysgen with output to DECtape took so long -- writing a contiguous CIL > file, in block order, madly seeking back & forth. > > > > Oh. You mean that the software decided to use blocks 0,4,8,12,... > > > > Yes, that would be doable. I was thinking of interleaving at the format > level. > > > > But such interleaving means the software have to keep rather good track > of things... > > True. Interleaving, as described in this thread, is typically a software > function; the software uses the blocks in an order different from the > "ascending by 1" natural ordering. > > I suppose it's possible to do something like interleaving where > consecutive sector addresses are not physically adjacent on the media. > Come to think of it, that's exactly what the MSCP RX50 controllers do, > since MSCP implements the mapping from LBA to physical addresses in the > controller, not the host. But in older systems where the controllers > handle physical addresses and the mapping from LBA is in the driver, > interleave is handled there (or above). > > A long time ago, I reverse-engineered an Atari 800/400 copy protection scheme which was based on using multiple sectors with the same sector number. Apparently the floppy controller put sector number information in a date preamble when formatting the floppy. The scheme (somehow) overwrote the preamble on some of the sectors, changing their number; the track contained something like: 1 2 3 4 5 6 7 4 This meant that a command to "read sector 4" would return whichever sector 4 passed under the head first. If you did 'read sector 2', 'read sector 4' you would get the first one; 'read sector 6', 'read sector 4', you would get the second. Interleaving for obfustication, not efficiency. -- Charles
Re: Sector Interleave
> On Nov 30, 2015, at 8:39 PM, Johnny Billquist wrote: > > On 2015-12-01 02:19, Paul Koning wrote: >> >>> On Nov 30, 2015, at 8:12 PM, Johnny Billquist wrote: >>> >>> ... >>> DECtape never did interleaving that I know of. >> >> Sure it does. The DOS format, which was adopted by RSTS, has 4 way >> interleaving. If you write a 500 block file, it writes every 4th block >> forward, then fills in one set of gaps reverse, then forward and backward >> again, resulting in finally all blocks used. >> >> This is a software function, of course, and actually implemented in the file >> system, but it's certainly interleaving. It doesn't apply to contiguous >> files (supported in DOS but not RSTS), which is why RSTS V4A sysgen with >> output to DECtape took so long -- writing a contiguous CIL file, in block >> order, madly seeking back & forth. > > Oh. You mean that the software decided to use blocks 0,4,8,12,... > > Yes, that would be doable. I was thinking of interleaving at the format level. > > But such interleaving means the software have to keep rather good track of > things... True. Interleaving, as described in this thread, is typically a software function; the software uses the blocks in an order different from the "ascending by 1" natural ordering. I suppose it's possible to do something like interleaving where consecutive sector addresses are not physically adjacent on the media. Come to think of it, that's exactly what the MSCP RX50 controllers do, since MSCP implements the mapping from LBA to physical addresses in the controller, not the host. But in older systems where the controllers handle physical addresses and the mapping from LBA is in the driver, interleave is handled there (or above). The CDC 844 controller (which handles drives that look like the RP04 or RP06) had a command to set 1:1 or 2:1 interleave. The reason is that it would allow reading or writing several sectors without an intervening "seek" command. Depending on the selected mode, the current sector address would advance by 1 or by 2 at the end of the operation (and, in the case of 2:1, wrap at track end the first time around). That's the only case I have seen of interleave support in pre-MSCP controllers. On the subject of DECtape, and "keeping good track of things" -- DOS format DECtape has 510 bytes per tape block, the other two bytes are used as the link word. It's a bit like MSDOS FAT format (or CDC 6000 series, which did it 20 years earlier), but with the links in the blocks rather than in a separate region. The directory points to the first block, and you get the next block address when you read the first. Yes, that means no random access supported; in DOS, if you needed random access you were required to use a contiguous file, in which all 512 bytes per block are payload. The interleaving is simply a side effect of the block allocation algorithm: when looking for the next block to allocate, it would start looking at current + 4 or current - 4 (depending on the direction for this block). So starting from an empty tape you'd get a regular layout, but if there were already some allocated blocks you might get larger skips, and on a very nearly full tape possibly a smaller skip. A very odd interleave shows up in the THE operating system for the Electrologica EL-X8 by Dijkstra, in its addressing for the paging drum. That device is word addressable (think of an RF11, but somewhat larger: 512k 27-bit words). The start word address of sector n is given by (n * 1025) mod 512k. I assume that's done for the usual reasons interleaving is used, but while the formula is nicely spelled out in the literature, no explanation is given for why it was used. paul
Re: "Bounce buffer" copyright [was Re: flash (or ide) storage for unibus 11?]
On 2015-12-01 16:49, John Robertson wrote: On 11/28/2015 3:41 PM, Mouse wrote: Love that term, "bounce buffer" (I wrote a whole package to support them in a packet switch I did) - I'm officially adopting it, right now! :-) Hey - anything that anyone writes is automatically copyrighted. I realize you...may have been less than entirely serious. But what you wrote could easily be taken seriously, especially by someone only partially inside our culture. So I'm going to be a minor killjoy here. Yes, anything written now is automatically copyrighted in most jursidctions. But (a) the term "bounce buffer" is small enough and obvious enough it probably cannot be copyrighted on its own (and is not infringing when copied in isolation), (b) was quite possibly published without copyright claim before automatic copyright and is thus in the public domain now, and (c) is of uncertain authorship anyway. So... So first you need permission to use that! ...you actually don't. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B Further to this discussion on 'automatic' copyright. That only came into being in 1989 - prior to that ALL documents had to have either the symbol (c) or the word COPYRIGHT as well as the name of the person or organization on the document (if a single page) or the front page or the index page. This was true for the period prior to 1978, however during the period 1978 through 1989 you had up to five years to copyright the document, otherwise it passed into public domain. https://copyright.cornell.edu/resources/publicdomain.cfm One could trademark an expression 'bounce buffer', however as Mouse points out you can't exactly copyright it. And all of these commands are only relevant if you are in the US. Much of the rest of the world signed the Berne convention long before that. Johnny
Re: "Bounce buffer" copyright [was Re: flash (or ide) storage for unibus 11?]
On 11/28/2015 3:41 PM, Mouse wrote: Love that term, "bounce buffer" (I wrote a whole package to support them in a packet switch I did) - I'm officially adopting it, right now! :-) Hey - anything that anyone writes is automatically copyrighted. I realize you...may have been less than entirely serious. But what you wrote could easily be taken seriously, especially by someone only partially inside our culture. So I'm going to be a minor killjoy here. Yes, anything written now is automatically copyrighted in most jursidctions. But (a) the term "bounce buffer" is small enough and obvious enough it probably cannot be copyrighted on its own (and is not infringing when copied in isolation), (b) was quite possibly published without copyright claim before automatic copyright and is thus in the public domain now, and (c) is of uncertain authorship anyway. So... So first you need permission to use that! ...you actually don't. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B Further to this discussion on 'automatic' copyright. That only came into being in 1989 - prior to that ALL documents had to have either the symbol (c) or the word COPYRIGHT as well as the name of the person or organization on the document (if a single page) or the front page or the index page. This was true for the period prior to 1978, however during the period 1978 through 1989 you had up to five years to copyright the document, otherwise it passed into public domain. https://copyright.cornell.edu/resources/publicdomain.cfm One could trademark an expression 'bounce buffer', however as Mouse points out you can't exactly copyright it. John :-#)# -- John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9 Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames) www.flippers.com "Old pinballers never die, they just flip out"
Re: A stored collection piece is a Schrodinger's cat
On 1 December 2015 at 01:12, Adrian Graham wrote: > The > ROM/RAM replacement board he sells is an excellent 40 pin toolkit to help > tracing faults in the vast majority of PETs so with the help of Dave and the > good folk here I've got life back into my most dead 4032. He's a smart and very helpful chap. He built a Raspberry Pi 2 into my old LMT 68FX2 ZX Spectrum replacement keyboard. The snag is, a Spectrum keyboard layout is really very little use with anything else (e.g. Linux or RISC OS.) Shame, as it has a good action and feel -- individual sprung keys. -- Liam Proven • Profile: http://lproven.livejournal.com/profile Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
Re: Interfacing PDP 11/05 to VT 50
On Nov 30, 2015 9:14 PM, "william degnan" wrote: > > I have an 11/05 with ASR 33 for I/O. I am using the M9970 console card to make the connection. I have loaded papertape BASIC into core (16K) and it boots up from 000 000 to the TTY, I can type in programs, etc. > > Question - I'd like to switch over to a VT 50 in 20ma mode. Not sure if this is possible based on what I read here: > > http://www.retrocmp.com/how-tos/interfacing-to-a-pdp-1105/144-interfacing-with-a-pdp-1105-sorting-the-wires To clarify, I meant I don't think you can interface with the vt50 with loop 20ma, so instead I wanted to split the IO between the TTY for program storage and vt50 using M7856 serial card. I am guessing this is the way to go, but I have never done this before. Good plan? Anyone have this kind of set up now? Bill
Interfacing PDP 11/05 to VT 50
I have an 11/05 with ASR 33 for I/O. I am using the M9970 console card to make the connection. I have loaded papertape BASIC into core (16K) and it boots up from 000 000 to the TTY, I can type in programs, etc. Question - I'd like to switch over to a VT 50 in 20ma mode. Not sure if this is possible based on what I read here: http://www.retrocmp.com/how-tos/interfacing-to-a-pdp-1105/144-interfacing-with-a-pdp-1105-sorting-the-wires Anyone successfully connect a VT 50 or 52 to a 11/05 or 11/10 over to the EIN M7856 for printer and typewriter only, leaving the M9970 for program i/o to save and load programs? -- Bill
