DecServer 550 chassis
These are the cards in the DecServer 550. Looks to be an expansion chassis with 108 ports or so. Thanks Jim Photos of the DecServer 550 https://drive.google.com/folderview?id=0B4AXJXpUCE-hQ2lsc2lqS3VHd0U&usp=sharing
Re: DecServer 550 chassis
Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. http://home.windstream.net/engdahl/kdj11.htm /P On Mon, Oct 19, 2015 at 12:30:00AM -0700, jwsmobile wrote: > > These are the cards in the DecServer 550. Looks to be an expansion > chassis with 108 ports or so. > > Thanks > Jim > > Photos of the DecServer 550 > > https://drive.google.com/folderview?id=0B4AXJXpUCE-hQ2lsc2lqS3VHd0U&usp=sharing > >
Re: DecServer 550 chassis
On 10/19/2015 12:42 AM, Pontus Pihlgren wrote: Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. http://home.windstream.net/engdahl/kdj11.htm /P Thanks for the link. I've already been analyzing that. Tomorrow will pull it out, clean it off and see what more details can be had. The KDJ was an interesting surprise. We may have enough to do the conversion talked about in the articles he has, but they aren't for the faint hearted w/o reading all that he has there. We may have the RQ controller which is pretty much an essential bit to have. The disk drive is another matter. Will take some rummaging around to find a suitable candidate. Thanks Jim On Mon, Oct 19, 2015 at 12:30:00AM -0700, jwsmobile wrote: These are the cards in the DecServer 550. Looks to be an expansion chassis with 108 ports or so. Thanks Jim Photos of the DecServer 550 https://drive.google.com/folderview?id=0B4AXJXpUCE-hQ2lsc2lqS3VHd0U&usp=sharing
Re: DecServer 550 chassis
Its a terminal concentrator. I have a load of those 8 and 16 line cards. They would have fanned out to via splitter cables to back /front panels with 9/25 way D connectors. They look in a bit of a sorry state. I would not apply power or plug into any other chassis. Rod On 19/10/2015 08:30, jwsmobile wrote: These are the cards in the DecServer 550. Looks to be an expansion chassis with 108 ports or so. Thanks Jim Photos of the DecServer 550 https://drive.google.com/folderview?id=0B4AXJXpUCE-hQ2lsc2lqS3VHd0U&usp=sharing
Re: PDP8 / ETOS
At 11:08 PM 10/18/2015, Johnny Billquist wrote: On 2015-10-19 04:58, ben wrote: On 10/18/2015 8:43 PM, Johnny Billquist wrote: thus making it also able to run under MULTOS-8. Memory requirements and availability is a different story, but yes, ADVENT will require the full 32K, as far as I remember. I think a few changes where made a few years back, It could be a bit smaller now with the latest code. Not significantly. Small enough to be much less likely to run out of memory even with multiple 2-page handlers installed, but certainly not small enough to allow it to run in 16K, for example. The loader map says: 7 = 1ST FREE LOCATION That means that it uses up all of 28K (with FRTS) without any device drivers installed. If it was possible to bum another couple of pages it might be possible to get it to work with 28K, but currently it won't. 32K is required for it to work. As always with trying to make code more compact, the more times you go back to try to shrink things the harder it gets. I haven't tried for several years, however. That would be interesting to check out. You know where I could find it? http://www.rickmurphy.net/adventure.html -Rick
Re: PDP8 / ETOS
On 2015-10-19 12:40, Rick Murphy wrote: At 11:08 PM 10/18/2015, Johnny Billquist wrote: On 2015-10-19 04:58, ben wrote: On 10/18/2015 8:43 PM, Johnny Billquist wrote: thus making it also able to run under MULTOS-8. Memory requirements and availability is a different story, but yes, ADVENT will require the full 32K, as far as I remember. I think a few changes where made a few years back, It could be a bit smaller now with the latest code. Not significantly. Small enough to be much less likely to run out of memory even with multiple 2-page handlers installed, but certainly not small enough to allow it to run in 16K, for example. The loader map says: 7 = 1ST FREE LOCATION That means that it uses up all of 28K (with FRTS) without any device drivers installed. If it was possible to bum another couple of pages it might be possible to get it to work with 28K, but currently it won't. 32K is required for it to work. As always with trying to make code more compact, the more times you go back to try to shrink things the harder it gets. I haven't tried for several years, however. Unless I remember wrong, the space for device drivers is already reserved in FRTS...? Device handlers always sits in field 0. Thus, they cannot really be loaded dynamically, and certainly not beyond the top of the program. Johnny -- 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: PDP8 / ETOS
On 2015-10-19 13:03, Johnny Billquist wrote: On 2015-10-19 12:40, Rick Murphy wrote: At 11:08 PM 10/18/2015, Johnny Billquist wrote: On 2015-10-19 04:58, ben wrote: On 10/18/2015 8:43 PM, Johnny Billquist wrote: thus making it also able to run under MULTOS-8. Memory requirements and availability is a different story, but yes, ADVENT will require the full 32K, as far as I remember. I think a few changes where made a few years back, It could be a bit smaller now with the latest code. Not significantly. Small enough to be much less likely to run out of memory even with multiple 2-page handlers installed, but certainly not small enough to allow it to run in 16K, for example. The loader map says: 7 = 1ST FREE LOCATION That means that it uses up all of 28K (with FRTS) without any device drivers installed. If it was possible to bum another couple of pages it might be possible to get it to work with 28K, but currently it won't. 32K is required for it to work. As always with trying to make code more compact, the more times you go back to try to shrink things the harder it gets. I haven't tried for several years, however. Unless I remember wrong, the space for device drivers is already reserved in FRTS...? Device handlers always sits in field 0. Thus, they cannot really be loaded dynamically, and certainly not beyond the top of the program. (And to clarify myself, by dynamically I mean that you could just allocate random memory somewhere, and load a device driver in there. They have to be in field 0, and you need to more carefully manage memory in field 0 for that, and other reasons.) By the way, could you describe how you managed to squeeze some memory from ADVENT? And if the first free location is 7, then it sounds like it would be possible to run in 28K. Johnny -- 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: 8" hard sector (Was DG S/130 status)
Hey Guys-- Sorry for the delay getting this out there. I finally found the documentation package I had put together back in 2010 and it's now on my GDrive here, https://drive.google.com/folderview?id=0B6A73VHTVh23MS1MVERNcUZkd1U The photos are of the 10-hole punch. We also did a 16-hole as Dwight has mentioned and he as a few of those still available. Dwight, I double checked the metal and we're both mis-remembering. It's not aluminum or stainless but just tool steel that Russ polished. You can stick a magnet to it. Therefore, probably keep these out of the humidity or they will rust. I also put the latest copy of the user instructions along with photos. We may have updated that document later but this was the only copy I could find here. Chris On Friday (10/16/2015 at 01:00PM -0500), Chris Elmquist wrote: > On Friday (10/16/2015 at 08:53AM -0700), Chris Osborn wrote: > > > > On Oct 16, 2015, at 8:18 AM, dwight wrote: > > > > > I do still have some 16 hole 5-1/4 punches left. ( anyone want one? ) > > > > I’d love to see a picture of one just to see how it was made and how it > > clamps to the disk. > > I will take some photos later today and round up some of the documentation > we had for them and then send another note with links to same. > > Chris > -- > Chris Elmquist -- Chris Elmquist
Re: "Farm" slang terms
On Sunday (10/18/2015 at 03:26PM -0700), Fred Cisin wrote: > On Sun, 18 Oct 2015, Dave Wade wrote: > >I can see that Antenna Farms is an older term, dating back to at least 1950, > >but of course as antenna's are usually in fields.. > > It gradually evolved from agricultural to ANYTHING, > and then from fields to ANY space. > > > Does it correlate with the decline of actual FARMING? It's part of the name of the tower facility and the company that owns the towers here in Minneapolis where ALL of the TV transmitters for the Twin Cities are located, https://en.wikipedia.org/wiki/Telefarm_Towers_Shoreview I'm also familiar with the term as it relates to employment. Eg, "I lost my engineering job when it got farmed out to India". -- Chris Elmquist
Re: 8" hard sector (Was DG S/130 status)
On Mon, 19 Oct 2015, Chris Elmquist wrote: The photos are of the 10-hole punch. We also did a 16-hole as Dwight has mentioned and he as a few of those still available. Dwight, I double checked the metal and we're both mis-remembering. It's not aluminum or stainless but just tool steel that Russ polished. You can stick a magnet to it. Therefore, probably keep these out of the humidity or they will rust. Very timely. I had an occasion to drag out my 10-hole punch yesterday and modify a couple of diskettes for my N*. The first time around I had a lot of tearing that resulted in the dreaded "hanging chads". When I took a close look at the die plate I noticed an irregular raised burr around all the holes. After taking some fine-grit sandpaper to the surface and leveling the holes it started working a lot better. Maybe this will be helpful to other users. --
RE: 8" hard sector (Was DG S/130 status)
We need to be able to do 32 sector 8" floppies :) J
Re: DecServer 550 chassis
> On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren wrote: > > Interesting. I thought Tthe DECserver 550 was merely the big brother in > the terminal server line. But it looks like it is essentially a > PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. It's been a while, but I think it may be a member of the "pluto" family. The original plan for terminal servers was that they would run CTERM. But the initial Pluto terminal server was incredibly slow, not surprising given how complex that protocol is. So an AD project was started which created LAT, originally also in a PDP-11 processor (perhaps even the same one, I forgot). And that turned out to be so superior in practice that it ended up being the main product instead of the original plan. But we still have CTERM as a leftover from all this. paul
Re: DecServer 550 chassis
On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren wrote: > Interesting. I thought Tthe DECserver 550 was merely the big brother in > the terminal server line. But it looks like it is essentially a > PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. Yep. It's essentially an S-box KDJ11 with different ROMs. I happen to have a CPU board from one, but not the box itself. One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD up on mine. That and my Pro380 are my only KDJ11 machines. -ethan
Re: 8" hard sector (Was DG S/130 status)
On Monday (10/19/2015 at 10:20AM -0400), Steven Hirsch wrote: > On Mon, 19 Oct 2015, Chris Elmquist wrote: > > >The photos are of the 10-hole punch. We also did a 16-hole as Dwight > >has mentioned and he as a few of those still available. > > > >Dwight, I double checked the metal and we're both mis-remembering. > >It's not aluminum or stainless but just tool steel that Russ polished. > >You can stick a magnet to it. Therefore, probably keep these out of > >the humidity or they will rust. > > Very timely. I had an occasion to drag out my 10-hole punch yesterday and > modify a couple of diskettes for my N*. The first time around I had a lot > of tearing that resulted in the dreaded "hanging chads". When I took a > close look at the die plate I noticed an irregular raised burr around all > the holes. After taking some fine-grit sandpaper to the surface and > leveling the holes it started working a lot better. > > Maybe this will be helpful to other users. Yes. Thanks Steven. The whole project was an experiment no doubt. In the end, I think we pushed the limits of my buddy's prototype machine shop, asking him to make the quantity of these that he did. This resulted in some quality issues such as you have found, where basically, he got bored with all the detail work finishing them to perfection. It quickly changed from being fun to being work and for hobby stuff, I think we all understand what that means. If we were to do these again, today, we'd need to farm out the work to a production shop for better, more reproducible results I think. Chris -- Chris Elmquist
Re: PDP8 / ETOS
On Mon, 19 Oct 2015, Johnny Billquist wrote: Unless I remember wrong, the space for device drivers is already reserved in FRTS...? Yes. For normal device assignment, you use the command decoder to assign unit numbers to files, which loads the handlers for same. Adventure uses the USR routines written by Robert Phelps, which allows it to dynamically load a driver into memory and open a file at run time. Space for those handlers is allocated just above the FRTS allocation. -Rick
Re: DecServer 550 chassis
On 2015-10-19 16:32, Paul Koning wrote: On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren wrote: Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. It's been a while, but I think it may be a member of the "pluto" family. The original plan for terminal servers was that they would run CTERM. But the initial Pluto terminal server was incredibly slow, not surprising given how complex that protocol is. So an AD project was started which created LAT, originally also in a PDP-11 processor (perhaps even the same one, I forgot). And that turned out to be so superior in practice that it ended up being the main product instead of the original plan. But we still have CTERM as a leftover from all this. Yeah, that should be PLUTO. It's based on RSX, and talks LAT. I never knew that they considered using CTERM (a horrible protocol). The interface in PLUTO, once it has booted, is pretty much like other DECservers, as far as I understand. But they were larger, more flexible, and so on, than later DECserver models, since they were built on PDP-11s in a Qbus chassis. Johnny
Re: DecServer 550 chassis
I would appreciate thoughts on the conversion of the processor to normal PDP11 eproms. The page pointed to earlier has a mention of that too, but the poster had access to another "real" KDJ and I am guessing copied that. I don't have access to any version of the system with appropriate eproms and would appreciate any pointers to the binaries needed. As to the condition most of the material is the result of moving it from where it was stored. It will be totally disassembled and tested before being brought back up. There is about 5 or 6 large deep freeze (for reference) sized piles of material being sent for e-waste from the place that is pretty much just junk material under the weather. Think of this as a Dusenberg rescued from a barn though. thanks for all the suggestions and observations. Next thing to go over is a Sun 4/260 "mini" tower. Gads those were heavy. Back is still aching from moving that. Jim On 10/19/2015 7:32 AM, Ethan Dicks wrote: On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren wrote: Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. Yep. It's essentially an S-box KDJ11 with different ROMs. I happen to have a CPU board from one, but not the box itself. One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD up on mine. That and my Pro380 are my only KDJ11 machines. -ethan
Re: DecServer 550 chassis
Not sure what you expect a "conversion" means. Creating new PROMs imply finding actual proms, a prom programmer, the code to program into the PROMs, and then just replace the proms on the card. Only the last piece will actually require any modification of the card, and I would expect them to be socketed anyway, so replacing means just removing the old proms, and inserting the new ones. The note also mentioned that you might want/need to install a pull-up. But it would still be an extremely simple process. You just need the right bits... Johnny On 2015-10-19 18:28, jwsmobile wrote: I would appreciate thoughts on the conversion of the processor to normal PDP11 eproms. The page pointed to earlier has a mention of that too, but the poster had access to another "real" KDJ and I am guessing copied that. I don't have access to any version of the system with appropriate eproms and would appreciate any pointers to the binaries needed. As to the condition most of the material is the result of moving it from where it was stored. It will be totally disassembled and tested before being brought back up. There is about 5 or 6 large deep freeze (for reference) sized piles of material being sent for e-waste from the place that is pretty much just junk material under the weather. Think of this as a Dusenberg rescued from a barn though. thanks for all the suggestions and observations. Next thing to go over is a Sun 4/260 "mini" tower. Gads those were heavy. Back is still aching from moving that. Jim On 10/19/2015 7:32 AM, Ethan Dicks wrote: On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren wrote: Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. Yep. It's essentially an S-box KDJ11 with different ROMs. I happen to have a CPU board from one, but not the box itself. One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD up on mine. That and my Pro380 are my only KDJ11 machines. -ethan
ADVENT on TSX-Plus system?
My reply didn’t show up for some reason... resubmitting: It should directly in TSX-Plus . Make sure your current memory limit is 56K. See below for my attempt. BTW TSX should only use RT11 to “boot”. TSX doesn’t run over RT11SJ in this version. TSX replaces all the OS code. .sh memory …... Current job memory limit = 56Kb Maximum job memory limit = 64Kb .sh ver 6.20 .run advent WELCOME TO ADVENTURE!! WOULD YOU LIKE INSTRUCTIONS? --- It turns out I have (at least the pack that’s in the drive) TSX-Plus 6.16, not 6.50. But ADVENT does work now. I have to admit to “operator error” The bootable XM pack is currently in drive 0, and the bootable SJ pack with TSX-Plus is in drive 1. Somehow I’d forgotten to copy one of the ADVENT files from one pack to the other. So when I rebooted from DL1: it couldn’t find ADVTXT and crashed! Anyhow it does now run (on both the console and the other time-sharing terminal). Thanks for the information, though. -Charles
Re: PDP8 / ETOS
On 10/19/2015 8:56 AM, Rick Murphy wrote: On Mon, 19 Oct 2015, Johnny Billquist wrote: Unless I remember wrong, the space for device drivers is already reserved in FRTS...? Yes. For normal device assignment, you use the command decoder to assign unit numbers to files, which loads the handlers for same. Adventure uses the USR routines written by Robert Phelps, which allows it to dynamically load a driver into memory and open a file at run time. Space for those handlers is allocated just above the FRTS allocation. -Rick Since the original email was running simh, does not the emulator have the hardware floating point as a option, so you can free up a bit more memory?.
Re: ADVENT on TSX-Plus system?
On 10/19/2015 11:04 AM, Charles wrote: Anyhow it does now run (on both the console and the other time-sharing terminal). Thanks for the information, though. -Charles Did advent run under PDP11 unix? Ben.
IBM 1401
there is a cool video in the hackaday link below http://hackaday.com/2015/10/19/repairing-55000-of-vintage-core-memory/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29&utm_content=FeedBurner+user+view -- The contents of this e-mail and any attachments are intended solely for the use of the named addressee(s) and may contain confidential and/or privileged information. Any unauthorized use, copying, disclosure, or distribution of the contents of this e-mail is strictly prohibited by the sender and may be unlawful. If you are not the intended recipient, please notify the sender immediately and delete this e-mail.
Re: Oddball floppies for trade - 8", HS (outer edge), weird cutout
On 10/18/15 6:00 PM, Chuck Guzis wrote: it's truly amazing that Memorex still exists--as a brand of Imation. Thank Ella Fitzgerald "Is it live, or is it Memorex" http://www.totalmedia.com/content/trivia-and-tips/maxells-chair-man-hell-blow-you-away-part-1.html
Re: DecServer 550 chassis
> On Oct 19, 2015, at 12:17 PM, Johnny Billquist wrote: > > On 2015-10-19 16:32, Paul Koning wrote: >> >>> On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren wrote: >>> >>> Interesting. I thought Tthe DECserver 550 was merely the big brother in >>> the terminal server line. But it looks like it is essentially a >>> PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. >> >> It's been a while, but I think it may be a member of the "pluto" family. >> The original plan for terminal servers was that they would run CTERM. But >> the initial Pluto terminal server was incredibly slow, not surprising given >> how complex that protocol is. So an AD project was started which created >> LAT, originally also in a PDP-11 processor (perhaps even the same one, I >> forgot). And that turned out to be so superior in practice that it ended up >> being the main product instead of the original plan. But we still have >> CTERM as a leftover from all this. > > Yeah, that should be PLUTO. > It's based on RSX, and talks LAT. I never knew that they considered using > CTERM (a horrible protocol). Oh yes... and I think the original PLUTO was an 11/23, which would certainly explain why it had performance issues. CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics of the terminal drivers in all the DEC operating systems, and to export as much as possible to the server end. In other words, the goal of the protocol was to be line oriented as much as possible. That meant, for example, exporting the command line editing machinery to the server. That doesn't seem so bad until you realize that the server has to be told a whole lot about what is going on at the client in order to do that. The eventual goal was to have not just command line mode but also other modes, like screen editing mode (think distributed EDT). That's why there are two layers, with the foundation layer common to all modes, and Cterm the first of the modes to be defined. Some example of the complexities: the ability to define what characters are line edings; immediate vs. delayed echo; command line completion in TOPS-20; and so on. When the dust settled, the 36 bit machines were starting to disappear around this time, and management was trying to do similar things to PDP11s in general and non-RSX in particular, so CTerm ended up being really just a ridiculously complex way of doing what the old VMS terminal protocol did just as well. paul
Re: DecServer 550 chassis
On 2015-10-19 19:42, Paul Koning wrote: On Oct 19, 2015, at 12:17 PM, Johnny Billquist wrote: On 2015-10-19 16:32, Paul Koning wrote: On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren wrote: Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. It's been a while, but I think it may be a member of the "pluto" family. The original plan for terminal servers was that they would run CTERM. But the initial Pluto terminal server was incredibly slow, not surprising given how complex that protocol is. So an AD project was started which created LAT, originally also in a PDP-11 processor (perhaps even the same one, I forgot). And that turned out to be so superior in practice that it ended up being the main product instead of the original plan. But we still have CTERM as a leftover from all this. Yeah, that should be PLUTO. It's based on RSX, and talks LAT. I never knew that they considered using CTERM (a horrible protocol). Oh yes... and I think the original PLUTO was an 11/23, which would certainly explain why it had performance issues. CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics of the terminal drivers in all the DEC operating systems, and to export as much as possible to the server end. In other words, the goal of the protocol was to be line oriented as much as possible. That meant, for example, exporting the command line editing machinery to the server. That doesn't seem so bad until you realize that the server has to be told a whole lot about what is going on at the client in order to do that. The eventual goal was to have not just command line mode but also other modes, like screen editing mode (think distributed EDT). That's why there are two layers, with the foundation layer common to all modes, and Cterm the first of the modes to be defined. Some example of the complexities: the ability to define what characters are line edings; immediate vs. delayed echo; command line completion in TOPS-20; and so on. When the dust settled, the 36 bit machines were starting to disappear around this time, and management was trying to do similar things to PDP11s in general and non-RSX in particular, so CTerm ended up being really just a ridiculously complex way of doing what the old VMS terminal protocol did just as well. An interesting way to describe it. I've always looked at CTERM as an RPC service that essentially have all the functions of the VMS terminal driver. Makes it easy to implement in VMS, as you have a 1:1 mapping. Makes it horrible for everyone else, since other systems do not have the same functionality in the terminal driver, and now have to implement all the remote procedure calls of the VMS terminal driver, and somehow map that into how the native terminal driver works... Johnny
Re: ADVENT on TSX-Plus system?
> From: Ben Franchuk > Did advent run under PDP11 unix? There was a version on the V6 PDP11 Unix at MIT; not sure if that was a local port, or one we picked up from somewhere else. Noel
Re: DecServer 550 chassis
> On Oct 19, 2015, at 2:30 PM, Johnny Billquist wrote: > > On 2015-10-19 19:42, Paul Koning wrote: >> ... >> CTERM was an attempt to wrap a single protocol around the terribly >> inconsistent semantics of the terminal drivers in all the DEC operating >> systems, and to export as much as possible to the server end. ... > > An interesting way to describe it. > I've always looked at CTERM as an RPC service that essentially have all the > functions of the VMS terminal driver. Makes it easy to implement in VMS, as > you have a 1:1 mapping. Makes it horrible for everyone else, since other > systems do not have the same functionality in the terminal driver, and now > have to implement all the remote procedure calls of the VMS terminal driver, > and somehow map that into how the native terminal driver works... You can certainly view it as an RPC, and given that Cterm ended up basically doing VMS, looking at it as the RPC version of the VMS terminal driver is reasonably accurate. But the original version aimed to support both VMS and TOPS-20 as primary clients, and other operating systems as well. So it was supposed to be an RPC version of the union of all terminal drivers. Which means that a full CTERM server (as opposed to client) would be hard to do for everyone, even VMS. paul
RE: "Farm" slang terms
Definitely recall "disk farm" being used at Pan American Airways data center in the early 1970s, perhaps earlier to describe other large IBM/Memorex customers. The term appears in print in a 1983 Datamation and a 1989 Compaq product brochure Tom -Original Message- From: Chuck Guzis [mailto:ccl...@sydex.com] Sent: Sunday, October 18, 2015 1:09 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: "Farm" slang terms On 10/18/2015 12:46 PM, Fred Cisin wrote: > Later, it began to be used for moderately open land, with collections > of other stuff, such as a group of windmills became a "wind farm" > (Altamont pass). I recall a room full of a hundred or more disk drives being referred to as a disk farm--but I don't think the usage was standard. --Chuck
Re: DecServer 550 chassis
On 2015-10-19 20:43, Paul Koning wrote: On Oct 19, 2015, at 2:30 PM, Johnny Billquist wrote: On 2015-10-19 19:42, Paul Koning wrote: ... CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics of the terminal drivers in all the DEC operating systems, and to export as much as possible to the server end. ... An interesting way to describe it. I've always looked at CTERM as an RPC service that essentially have all the functions of the VMS terminal driver. Makes it easy to implement in VMS, as you have a 1:1 mapping. Makes it horrible for everyone else, since other systems do not have the same functionality in the terminal driver, and now have to implement all the remote procedure calls of the VMS terminal driver, and somehow map that into how the native terminal driver works... You can certainly view it as an RPC, and given that Cterm ended up basically doing VMS, looking at it as the RPC version of the VMS terminal driver is reasonably accurate. But the original version aimed to support both VMS and TOPS-20 as primary clients, and other operating systems as well. So it was supposed to be an RPC version of the union of all terminal drivers. Which means that a full CTERM server (as opposed to client) would be hard to do for everyone, even VMS. The amount of swearwords from TOPS-20 people exceed all others combined, in my experience. So if they intended CTERM to be something reasonable for TOPS-20 it was an utter failure. :-) And it's really silly and sad, considering that something like telnet is very simple and straight forward, and can be done right on both VMS and TOPS-20, and will in the end work much better for people connecting from one to the other, than using CTERM... (I have the same issues with CTERM under RSX. telnet makes so much more sense.) Johnny
Re: ADVENT on TSX-Plus system?
On Mon, Oct 19, 2015 at 02:37:08PM -0400, Noel Chiappa wrote: > > From: Ben Franchuk > > > Did advent run under PDP11 unix? > > There was a version on the V6 PDP11 Unix at MIT; not sure if that was a local > port, or one we picked up from somewhere else. There was a hack for PDP11 Unix which added RT-11 compatibility syscalls to the kernel. (UofT Spencer) Thus games compiled for RT-11 would run on PDP-11 and VAX-11 (in PDP-11 compatilibty mode) Unix. > > Noel > Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db
Re: ADVENT on TSX-Plus system?
On Mon, Oct 19, 2015 at 2:51 PM, Diane Bruce wrote: > There was a hack for PDP11 Unix which added RT-11 compatibility syscalls > to the kernel. (UofT Spencer) Thus games compiled for RT-11 would > run on PDP-11 and VAX-11 (in PDP-11 compatilibty mode) Unix. Ooh... I'd love to see that. I've fiddled a lot with RT-11 and VAX UNIX (Ultrix and Sys V), and some with 2.9BSD on the PDP-11. Could be fun to cross those streams. Is that still floating around anywhere? -ethan
Re: DecServer 550 chassis
> On Oct 19, 2015, at 2:46 PM, Johnny Billquist wrote: > > On 2015-10-19 20:43, Paul Koning wrote: >> >>> On Oct 19, 2015, at 2:30 PM, Johnny Billquist wrote: >>> >>> On 2015-10-19 19:42, Paul Koning wrote: ... CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics of the terminal drivers in all the DEC operating systems, and to export as much as possible to the server end. ... >>> >>> An interesting way to describe it. >>> I've always looked at CTERM as an RPC service that essentially have all the >>> functions of the VMS terminal driver. Makes it easy to implement in VMS, as >>> you have a 1:1 mapping. Makes it horrible for everyone else, since other >>> systems do not have the same functionality in the terminal driver, and now >>> have to implement all the remote procedure calls of the VMS terminal >>> driver, and somehow map that into how the native terminal driver works... >> >> You can certainly view it as an RPC, and given that Cterm ended up basically >> doing VMS, looking at it as the RPC version of the VMS terminal driver is >> reasonably accurate. But the original version aimed to support both VMS and >> TOPS-20 as primary clients, and other operating systems as well. So it was >> supposed to be an RPC version of the union of all terminal drivers. Which >> means that a full CTERM server (as opposed to client) would be hard to do >> for everyone, even VMS. > > The amount of swearwords from TOPS-20 people exceed all others combined, in > my experience. So if they intended CTERM to be something reasonable for > TOPS-20 it was an utter failure. :-) Yes. > And it's really silly and sad, considering that something like telnet is very > simple and straight forward, and can be done right on both VMS and TOPS-20, > and will in the end work much better for people connecting from one to the > other, than using CTERM... > (I have the same issues with CTERM under RSX. telnet makes so much more > sense.) Sure, telnet in character mode (not line mode) works for everyone because it doesn't try to export any real work to the server end. For the same reason, the older remote terminal protocols (the set of 4, before Cterm was perpetrated) work great. Those simply export primitives suitable for the OS in question. Simple line mode with the ability to switch to character mode for RSTS, character mode all the time for TOPS-20, and a much simpler RSX and VMS terminal driver QIO RPC for those two operating systems. All these are so easy that RSTS can implement them all, quite unlike Cterm. paul
Re: DecServer 550 chassis
On 10/19/2015 10:03 AM, Johnny Billquist wrote: Not sure what you expect a "conversion" means. Creating new PROMs imply finding actual proms, a prom programmer, the code to program into the PROMs, and then just replace the proms on the card. Only the last piece will actually require any modification of the card, and I would expect them to be socketed anyway, so replacing means just removing the old proms, and inserting the new ones. That is basically what I said. I don't have one that isn't part of a DecServer and i need images, or someone with a non DecServer to provide them. I guess you restated what I said. if you have one, I'd appreciate copies. I didn't post the original link from the top of this thread, you might want to read it. I'm just stating what someone did back in the 2001 time frame and posted a page about the conversion and info on his experiences. The note also mentioned that you might want/need to install a pull-up. But it would still be an extremely simple process. You just need the right bits... What I said. Johnny On 2015-10-19 18:28, jwsmobile wrote: I would appreciate thoughts on the conversion of the processor to normal PDP11 eproms. The page pointed to earlier has a mention of that too, but the poster had access to another "real" KDJ and I am guessing copied that. I don't have access to any version of the system with appropriate eproms and would appreciate any pointers to the binaries needed. As to the condition most of the material is the result of moving it from where it was stored. It will be totally disassembled and tested before being brought back up. There is about 5 or 6 large deep freeze (for reference) sized piles of material being sent for e-waste from the place that is pretty much just junk material under the weather. Think of this as a Dusenberg rescued from a barn though. thanks for all the suggestions and observations. Next thing to go over is a Sun 4/260 "mini" tower. Gads those were heavy. Back is still aching from moving that. Jim On 10/19/2015 7:32 AM, Ethan Dicks wrote: On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren wrote: Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. Yep. It's essentially an S-box KDJ11 with different ROMs. I happen to have a CPU board from one, but not the box itself. One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD up on mine. That and my Pro380 are my only KDJ11 machines. -ethan
Re: DecServer 550 chassis
I have a decserver 550 CPU converted to a real KDJ. It's as simple as new ROMS and one resistor. I also removed the s-box bracket to fit my chassis. Runs BSD 2.11 just fine (RQDX3 disks) Joe > On Oct 19, 2015, at 12:28 PM, jwsmobile wrote: > > I would appreciate thoughts on the conversion of the processor to normal > PDP11 eproms. > > The page pointed to earlier has a mention of that too, but the poster had > access to another "real" KDJ and I am guessing copied that. > > I don't have access to any version of the system with appropriate eproms and > would appreciate any pointers to the binaries needed. > > As to the condition most of the material is the result of moving it from > where it was stored. It will be totally disassembled and tested before being > brought back up. There is about 5 or 6 large deep freeze (for reference) > sized piles of material being sent for e-waste from the place that is pretty > much just junk material under the weather. > > Think of this as a Dusenberg rescued from a barn though. > > thanks for all the suggestions and observations. > > Next thing to go over is a Sun 4/260 "mini" tower. Gads those were heavy. > Back is still aching from moving that. > > Jim > >> On 10/19/2015 7:32 AM, Ethan Dicks wrote: >>> On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren >>> wrote: >>> Interesting. I thought Tthe DECserver 550 was merely the big brother in >>> the terminal server line. But it looks like it is essentially a >>> PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. >> Yep. It's essentially an S-box KDJ11 with different ROMs. I happen >> to have a CPU board from one, but not the box itself. >> >> One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD >> up on mine. That and my Pro380 are my only KDJ11 machines. >> >> -ethan >> >> >
Re: ADVENT on TSX-Plus system?
> From: Diane Bruce >> There was a version on the V6 PDP11 Unix at MIT; not sure if that was >> a local port, or one we picked up from somewhere else. > There was a hack for PDP11 Unix which added RT-11 compatibility > syscalls to the kernel. (UofT Spencer) The PDP-11 Unix machines are Tech Sq definitely did not have that; it would have run on standard Unix (although it may have included an RT11 emulator in the application - I don't at the moment have access to all that MIT stuff - yet!) Noel
Re: DecServer 550 chassis
On Mon, Oct 19, 2015 at 11:57 AM, jwsmobile wrote: > > That is basically what I said. I don't have one that isn't part of a > DecServer and i need images, or someone with a non DecServer to provide > them. > > I guess you restated what I said. if you have one, I'd appreciate copies. > The 23-261E5 / 23-262E5 firmware images for the M7554 11/53 are available on Pete's DECROM archive. http://www.dunnington.info/public/DECROMs/
Re: DecServer 550 chassis
On 10/19/2015 12:03 PM, Glen Slick wrote: On Mon, Oct 19, 2015 at 11:57 AM, jwsmobile wrote: That is basically what I said. I don't have one that isn't part of a DecServer and i need images, or someone with a non DecServer to provide them. I guess you restated what I said. if you have one, I'd appreciate copies. The 23-261E5 / 23-262E5 firmware images for the M7554 11/53 are available on Pete's DECROM archive. http://www.dunnington.info/public/DECROMs/ Thanks, Glen!
Re: DecServer 550 chassis
Well, you did ask for "thoughts in the conversion", so I gave you mine. Sorry if you felt they were unhelpful. I just thought the "conversion" was basically a no-work. Programming proms is something I have spent more time than I can count on, and is so routine that I don't even think about it. Johnny On 2015-10-19 20:57, jwsmobile wrote: On 10/19/2015 10:03 AM, Johnny Billquist wrote: Not sure what you expect a "conversion" means. Creating new PROMs imply finding actual proms, a prom programmer, the code to program into the PROMs, and then just replace the proms on the card. Only the last piece will actually require any modification of the card, and I would expect them to be socketed anyway, so replacing means just removing the old proms, and inserting the new ones. That is basically what I said. I don't have one that isn't part of a DecServer and i need images, or someone with a non DecServer to provide them. I guess you restated what I said. if you have one, I'd appreciate copies. I didn't post the original link from the top of this thread, you might want to read it. I'm just stating what someone did back in the 2001 time frame and posted a page about the conversion and info on his experiences. The note also mentioned that you might want/need to install a pull-up. But it would still be an extremely simple process. You just need the right bits... What I said. Johnny On 2015-10-19 18:28, jwsmobile wrote: I would appreciate thoughts on the conversion of the processor to normal PDP11 eproms. The page pointed to earlier has a mention of that too, but the poster had access to another "real" KDJ and I am guessing copied that. I don't have access to any version of the system with appropriate eproms and would appreciate any pointers to the binaries needed. As to the condition most of the material is the result of moving it from where it was stored. It will be totally disassembled and tested before being brought back up. There is about 5 or 6 large deep freeze (for reference) sized piles of material being sent for e-waste from the place that is pretty much just junk material under the weather. Think of this as a Dusenberg rescued from a barn though. thanks for all the suggestions and observations. Next thing to go over is a Sun 4/260 "mini" tower. Gads those were heavy. Back is still aching from moving that. Jim On 10/19/2015 7:32 AM, Ethan Dicks wrote: On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren wrote: Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. Yep. It's essentially an S-box KDJ11 with different ROMs. I happen to have a CPU board from one, but not the box itself. One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD up on mine. That and my Pro380 are my only KDJ11 machines. -ethan
Archeological dig, update Sun 4/260
Word comes in that there is a number of "cartons" of Sun 4 and HP QIC tapes in the pile, which I'm hoping may be install media. Bad news is that it is QIC and in the place it is in. Good news is that it surfaced at all. I will see if Al or someone can image them if they are of interest. The HP tapes may just be brand names and not software, unknown at this time. Also there are some half inch 9 and 7 track tapes in the pile. The dig also turned up Sunsoft manual sets, which are promising as far as the 4/260 is concerned. Suggests that the software and manuals are for that system and not another. Once I get an inventory of the tapes, I'd appreciate any updates as to whether they are already imaged and saved somewhere. thanks Jim
Re: DecServer 550 chassis
On 19/10/2015 20:24, jwsmobile wrote: On 10/19/2015 12:03 PM, Glen Slick wrote: The 23-261E5 / 23-262E5 firmware images for the M7554 11/53 are available on Pete's DECROM archive. http://www.dunnington.info/public/DECROMs/ Thanks, Glen! Glen beat me to it :-) -- Pete Pete Turnbull
Re: DecServer 550 chassis
On 10/19/2015 12:39 PM, Johnny Billquist wrote: Well, you did ask for "thoughts in the conversion", so I gave you mine. Sorry if you felt they were unhelpful. I just thought the "conversion" was basically a no-work. Programming proms is something I have spent more time than I can count on, and is so routine that I don't even think about it. I didn't mean that in disrespect. The contents of what I posted was on the page and I basically needed the binaries and needed some direction as to which went where. I appreciate you taking time to reply, but am coming from a lot less capability than you have. I do a lot of computing and the like, but I've purposely not kept up with eprom technology to the point that i can't reliably swear I can program them right now. There are only so many things one can keep up with and eproms were not one that was cheap to follow, and I was more into EE type devices anyway. I may need a favor by swapping you some of my eproms (I have a 12" x 12" x 12" box of pulls) maybe to get you to make me a set for my board. I've pulled out probably 500 and returned them to the original owner and owe him more. but I do probably have a lot of the 27xx proms. Do you think these are 27C or just straight 27 type eproms, and if so what speeds? That is what I need to know too. thanks Jim Johnny On 2015-10-19 20:57, jwsmobile wrote: On 10/19/2015 10:03 AM, Johnny Billquist wrote: Not sure what you expect a "conversion" means. Creating new PROMs imply finding actual proms, a prom programmer, the code to program into the PROMs, and then just replace the proms on the card. Only the last piece will actually require any modification of the card, and I would expect them to be socketed anyway, so replacing means just removing the old proms, and inserting the new ones. That is basically what I said. I don't have one that isn't part of a DecServer and i need images, or someone with a non DecServer to provide them. I guess you restated what I said. if you have one, I'd appreciate copies. I didn't post the original link from the top of this thread, you might want to read it. I'm just stating what someone did back in the 2001 time frame and posted a page about the conversion and info on his experiences. The note also mentioned that you might want/need to install a pull-up. But it would still be an extremely simple process. You just need the right bits... What I said. Johnny On 2015-10-19 18:28, jwsmobile wrote: I would appreciate thoughts on the conversion of the processor to normal PDP11 eproms. The page pointed to earlier has a mention of that too, but the poster had access to another "real" KDJ and I am guessing copied that. I don't have access to any version of the system with appropriate eproms and would appreciate any pointers to the binaries needed. As to the condition most of the material is the result of moving it from where it was stored. It will be totally disassembled and tested before being brought back up. There is about 5 or 6 large deep freeze (for reference) sized piles of material being sent for e-waste from the place that is pretty much just junk material under the weather. Think of this as a Dusenberg rescued from a barn though. thanks for all the suggestions and observations. Next thing to go over is a Sun 4/260 "mini" tower. Gads those were heavy. Back is still aching from moving that. Jim On 10/19/2015 7:32 AM, Ethan Dicks wrote: On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren wrote: Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. Yep. It's essentially an S-box KDJ11 with different ROMs. I happen to have a CPU board from one, but not the box itself. One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD up on mine. That and my Pro380 are my only KDJ11 machines. -ethan
Looking for Serial Terminals
Hi there, I've been wanting to get a nice serial terminal to use with my old systems (mostly UNIX) for a while now, but I haven't managed to find anything locally. Over the past few years I've been to thrifts, garage sales, surplus shops... But I haven't found any. This sort of surprises me, as Toronto isn't a small town. Is there anybody around the Toronto area that has a few extra dumb terminals lying around, or does anybody know of a good source for them around the Toronto area? Thanks -Brian
Re: Looking for Serial Terminals
I've got a few (ADM-11, several Falco models) but would have to check to see which ones (if any) are still working; if you're patient, contact me off-list. You could also have a look through A-1 Electronics on North Queen; never know what you'll find there. mike - Original Message - From: "Brian Adams" To: Sent: Monday, October 19, 2015 2:16 PM Subject: Looking for Serial Terminals Hi there, I've been wanting to get a nice serial terminal to use with my old systems (mostly UNIX) for a while now, but I haven't managed to find anything locally. Over the past few years I've been to thrifts, garage sales, surplus shops... But I haven't found any. This sort of surprises me, as Toronto isn't a small town. Is there anybody around the Toronto area that has a few extra dumb terminals lying around, or does anybody know of a good source for them around the Toronto area? Thanks -Brian
Re: Looking for Serial Terminals
a decent deal for a new terminal http://www.ebay.com/itm/WYSE-55-Terminal-NEW-Green-Terminal-/151828013094?hash=item2359a7a026:g:wPkAAOSwjVVVoAQY lot more used on ebay too On 10/19/2015 11:16 AM, Brian Adams wrote: > Hi there, > > I've been wanting to get a nice serial terminal to use with my old systems > (mostly UNIX) for a while now, but I haven't managed to find anything locally. > Over the past few years I've been to thrifts, garage sales, surplus shops... > But I haven't found any. This sort of surprises me, as Toronto isn't a small > town. > > Is there anybody around the Toronto area that has a few extra dumb terminals > lying around, or does anybody know of a good source for them around the > Toronto area? > > Thanks > > -Brian > -- The contents of this e-mail and any attachments are intended solely for the use of the named addressee(s) and may contain confidential and/or privileged information. Any unauthorized use, copying, disclosure, or distribution of the contents of this e-mail is strictly prohibited by the sender and may be unlawful. If you are not the intended recipient, please notify the sender immediately and delete this e-mail.
Re: Looking for Serial Terminals
I have a few extra VT 300s. I'm not sure of the exact model, I'll need to check on the weekend. I'm in Oshawa, contact me off line if interested. Sent from my iPhone > On Oct 19, 2015, at 2:16 PM, Brian Adams wrote: > > Hi there, > > I've been wanting to get a nice serial terminal to use with my old systems > (mostly UNIX) for a while now, but I haven't managed to find anything locally. > Over the past few years I've been to thrifts, garage sales, surplus shops... > But I haven't found any. This sort of surprises me, as Toronto isn't a small > town. > > Is there anybody around the Toronto area that has a few extra dumb terminals > lying around, or does anybody know of a good source for them around the > Toronto area? > > Thanks > > -Brian
Re: Looking for Serial Terminals
On 2015-10-19 6:11 PM, Mike Stein wrote: I've got a few (ADM-11, several Falco models) but would have to check to see which ones (if any) are still working; if you're patient, contact me off-list. You could also have a look through A-1 Electronics on North Queen; never know what you'll find there. Is that the de-facto Active Surplus, now that they've shut down? :( --Toby mike - Original Message - From: "Brian Adams" To: Sent: Monday, October 19, 2015 2:16 PM Subject: Looking for Serial Terminals Hi there, I've been wanting to get a nice serial terminal to use with my old systems (mostly UNIX) for a while now, but I haven't managed to find anything locally. Over the past few years I've been to thrifts, garage sales, surplus shops... But I haven't found any. This sort of surprises me, as Toronto isn't a small town. Is there anybody around the Toronto area that has a few extra dumb terminals lying around, or does anybody know of a good source for them around the Toronto area? Thanks -Brian
Re: Looking for Serial Terminals
- Original Message - From: "Toby Thain" To: ; "discuss...@classiccmp.org:On-Topic and Off-Topic Posts" Cc: Sent: Monday, October 19, 2015 6:28 PM Subject: Re: Looking for Serial Terminals On 2015-10-19 6:11 PM, Mike Stein wrote: I've got a few (ADM-11, several Falco models) but would have to check to see which ones (if any) are still working; if you're patient, contact me off-list. You could also have a look through A-1 Electronics on North Queen; never know what you'll find there. Is that the de-facto Active Surplus, now that they've shut down? :( --Toby Pretty well, IMO; there's also Sayal for new stuff and of course Toronto Surplus if you're looking for something they've got and can afford it ;-) m - mike - Original Message - From: "Brian Adams" To: Sent: Monday, October 19, 2015 2:16 PM Subject: Looking for Serial Terminals Hi there, I've been wanting to get a nice serial terminal to use with my old systems (mostly UNIX) for a while now, but I haven't managed to find anything locally. Over the past few years I've been to thrifts, garage sales, surplus shops... But I haven't found any. This sort of surprises me, as Toronto isn't a small town. Is there anybody around the Toronto area that has a few extra dumb terminals lying around, or does anybody know of a good source for them around the Toronto area? Thanks -Brian
Re: DecServer 550 chassis
On 2015-10-19 23:11, jwsmobile wrote: On 10/19/2015 12:39 PM, Johnny Billquist wrote: Well, you did ask for "thoughts in the conversion", so I gave you mine. Sorry if you felt they were unhelpful. I just thought the "conversion" was basically a no-work. Programming proms is something I have spent more time than I can count on, and is so routine that I don't even think about it. I didn't mean that in disrespect. The contents of what I posted was on the page and I basically needed the binaries and needed some direction as to which went where. I appreciate you taking time to reply, but am coming from a lot less capability than you have. I do a lot of computing and the like, but I've purposely not kept up with eprom technology to the point that i can't reliably swear I can program them right now. There are only so many things one can keep up with and eproms were not one that was cheap to follow, and I was more into EE type devices anyway. Well, EPROMs are getting sortof old fashioned nowadays. I may need a favor by swapping you some of my eproms (I have a 12" x 12" x 12" box of pulls) maybe to get you to make me a set for my board. Unfortunately all of my stuff in Sweden, while I nowadays live in Switzerland. So I could only possibly help out next summer. But I probably would have some 27256 around. I've pulled out probably 500 and returned them to the original owner and owe him more. but I do probably have a lot of the 27xx proms. Do you think these are 27C or just straight 27 type eproms, and if so what speeds? That is what I need to know too. I normally don't care about that. The difference is in how you program them, and there are more variations than that. Fortunately my programmer knows a whole bunch of them, and also can autodetect the different models. But once they are programmed, the actual pins are the same, so speed is the only possible issue. But I think most of them are 125ns, which is fast enough anyway. I replaced the firmware in some 11/93 boards a few years ago. But I think I just reused the existing proms that time. But I don't have any 11/53 boards, so I can't do that here. Johnny thanks Jim Johnny On 2015-10-19 20:57, jwsmobile wrote: On 10/19/2015 10:03 AM, Johnny Billquist wrote: Not sure what you expect a "conversion" means. Creating new PROMs imply finding actual proms, a prom programmer, the code to program into the PROMs, and then just replace the proms on the card. Only the last piece will actually require any modification of the card, and I would expect them to be socketed anyway, so replacing means just removing the old proms, and inserting the new ones. That is basically what I said. I don't have one that isn't part of a DecServer and i need images, or someone with a non DecServer to provide them. I guess you restated what I said. if you have one, I'd appreciate copies. I didn't post the original link from the top of this thread, you might want to read it. I'm just stating what someone did back in the 2001 time frame and posted a page about the conversion and info on his experiences. The note also mentioned that you might want/need to install a pull-up. But it would still be an extremely simple process. You just need the right bits... What I said. Johnny On 2015-10-19 18:28, jwsmobile wrote: I would appreciate thoughts on the conversion of the processor to normal PDP11 eproms. The page pointed to earlier has a mention of that too, but the poster had access to another "real" KDJ and I am guessing copied that. I don't have access to any version of the system with appropriate eproms and would appreciate any pointers to the binaries needed. As to the condition most of the material is the result of moving it from where it was stored. It will be totally disassembled and tested before being brought back up. There is about 5 or 6 large deep freeze (for reference) sized piles of material being sent for e-waste from the place that is pretty much just junk material under the weather. Think of this as a Dusenberg rescued from a barn though. thanks for all the suggestions and observations. Next thing to go over is a Sun 4/260 "mini" tower. Gads those were heavy. Back is still aching from moving that. Jim On 10/19/2015 7:32 AM, Ethan Dicks wrote: On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren wrote: Interesting. I thought Tthe DECserver 550 was merely the big brother in the terminal server line. But it looks like it is essentially a PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice. Yep. It's essentially an S-box KDJ11 with different ROMs. I happen to have a CPU board from one, but not the box itself. One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD up on mine. That and my Pro380 are my only KDJ11 machines. -ethan -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b.
Re: PDP8 / ETOS
At 07:07 AM 10/19/2015, Johnny Billquist wrote: By the way, could you describe how you managed to squeeze some memory from ADVENT? And if the first free location is 7, then it sounds like it would be possible to run in 28K. The primary way to cut memory usage was recoding the main function (ADVENTURE is one huge Fortran module) to use more compact code. The "compiler" is a really dumb code generator on the back end of a parser, and emits a lot of redundant instructions and poor code sequences. For example, "J = J + 1" gets output as something like FLDA J FADD #LIT+ (where the reference is to a literal with floating point value 1) FSTA J You can do that with two instructions: FLDA ONE FADDM J Putting common literals on the base page also makes the instruction stream shorter. Or, redundant loads like IF (DTOTAL .EQ. 0) GOTO 2000 IF (DTOTAL .EQ. 1) GOTO 74 Would emit FLDA DTOTAL JEQ #2000 FLDA DTOTAL FSUB #LIT+ JEQ #75 That second FLDA can be dropped. Also, for small literals, the code K = 52 would compile to FLDA#LIT+ FSTAK Replacing that with LDX 64,0/ put 52 (64 octal) into index register 0 XTA 0 FSTAK That's smaller, since you don't store a full float literal for 52 (3 words), and the LDX/XTA is more compact. Lots and lots of fun like that. What an space optimizer would do if there was one. :) I don't know how close this is to falling below the 28K boundary, but it's just barely made the 7 limit. It's entirely possible that you could get ADVENT to run on a 28K system if you only used resident drivers (SYS, for example..) but that would require changes to the USR.RA code to configure it to expect only 28K. Basically, I'm out of ideas for continuing bumming of space and didn't think 28K versus 32K was all that big a deal. (i.e. I don't think there's many machines at the 28K limit. Now if it was close to working on 16K it would be worth another major pass.) -Rick
Re: "Farm" slang terms
On Sun, Oct 18, 2015 at 6:26 PM, Fred Cisin wrote: > Does it correlate with the decline of actual FARMING? FARMING hasn't declined, only the number of farmers. (Not a farmer, but surrounded by them.)
Re: "Farm" slang terms
Does it correlate with the decline of actual FARMING? On Mon, 19 Oct 2015, Charles Dickman wrote: FARMING hasn't declined, only the number of farmers. (Not a farmer, but surrounded by them.) Is modern "agribusiness" really "farming"?
Re: "Farm" slang terms
On Mon, Oct 19, 2015 at 8:04 PM, Fred Cisin wrote: >>> Does it correlate with the decline of actual FARMING? > > > On Mon, 19 Oct 2015, Charles Dickman wrote: >> >> FARMING hasn't declined, only the number of farmers. >> (Not a farmer, but surrounded by them.) > > > Is modern "agribusiness" really "farming"? At the risk of drifting FAR OT... The farmers I know aren't any different than thier grandfathers. Modern technology just makes them much more productive.
Re: PDP8 / ETOS
At 01:10 PM 10/19/2015, ben wrote: Since the original email was running simh, does not the emulator have the hardware floating point as a option, so you can free up a bit more memory?. I don't think there's any way to re-purpose the memory used by the FPP emulator. And, to be honest, when running under SIMH you can just say that there's 32K of memory - why would FPP and 28K be any better? (Running with the FPP enabled under SIMH does significantly improve the performance, so it's good to use that in any case.) -Rick
Re: "Farm" slang terms
On 10/19/2015 06:05 PM, Charles Dickman wrote: The farmers I know aren't any different than thier grandfathers. Modern technology just makes them much more productive. "Farmer" can mean different things, for instance, growing stuff up by Booneville. (right, Fred?) --Chuck
RE: Looking for Serial Terminals
A1 is rather nice, they had lots of neat stuff last time I was there... Don't remember anything terminal-ey though. -Brian -Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Mike Stein Sent: Monday, October 19, 2015 7:05 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Looking for Serial Terminals - Original Message - From: "Toby Thain" To: ; "discuss...@classiccmp.org:On-Topic and Off-Topic Posts" Cc: Sent: Monday, October 19, 2015 6:28 PM Subject: Re: Looking for Serial Terminals > On 2015-10-19 6:11 PM, Mike Stein wrote: >> I've got a few (ADM-11, several Falco models) but would have to check >> to see which ones (if any) are still working; if you're patient, >> contact me off-list. >> >> You could also have a look through A-1 Electronics on North Queen; >> never know what you'll find there. > > Is that the de-facto Active Surplus, now that they've shut down? :( > > --Toby Pretty well, IMO; there's also Sayal for new stuff and of course Toronto Surplus if you're looking for something they've got and can afford it ;-) m - >> >> mike >> >> - Original Message - From: "Brian >> Adams" >> To: >> Sent: Monday, October 19, 2015 2:16 PM >> Subject: Looking for Serial Terminals >> >> >> Hi there, >> >> I've been wanting to get a nice serial terminal >> to use with my old >> systems (mostly UNIX) for a while now, but I >> haven't managed to find >> anything locally. >> Over the past few years I've been to thrifts, >> garage sales, surplus >> shops... But I haven't found any. This sort of >> surprises me, as Toronto >> isn't a small town. >> >> Is there anybody around the Toronto area that >> has a few extra dumb >> terminals lying around, or does anybody know of >> a good source for them >> around the Toronto area? >> >> Thanks >> >> -Brian >> >
Re: 8" hard sector (Was DG S/130 status)
On 10/19/2015 07:35 AM, Chris Elmquist wrote: If we were to do these again, today, we'd need to farm out the work to a production shop for better, more reproducible results I think. Find a shop with a wire EDM rig--it shouldn't take too long to spit a jig out. --Chuck
