RE: TU-58
> -Oorspronkelijk bericht- > Van: cctalk [mailto:cctalk-boun...@classiccmp.org] Namens Rod Smallwood > Verzonden: woensdag 2 december 2015 23:20 > Aan: General Discussion: On-Topic and Off-Topic Posts > Onderwerp: Re: TU-58 > > Hi > Well it certainly works for you Rik. > I dont speak Dutch and its not clear exactly which of the products you refer to. > The end of hub appears to have been turned on a lathe. > So if you speak Dutch and have a nice big lathe in your shed you can fix your > TU58 For us lesser mortals the search goes on. > > Rod > Rod, I don't use the lathe but I use a small dc motor in my vice , most of the time the motor from the drive. I use a "Eze-Lap Fine Diamond Pocket Stone 1" x6" (600)" to make them to the right size. Some times when I have to remove more material I start with Scotch Wet and Dry 150 sanding paper wrapped around the Eze-Lap. It's all about craftsmanship and a steady hand if you keep the motor running at a steady speed about 50% of its nominal voltage everybody should be able to do this. After gluing the rubber to the capstan it takes me about 20-40 minutes to get the rubber to the right size. So you lesser mortals should be able to do this too. For the tubing use something with the right inner size (a little smaller than the hub) the outer size should be a little larger. And look for an industrial hose/rubber supplier both PU and Neoprene should work. -Rik
RE: TU-58
> -Oorspronkelijk bericht- > Van: cctalk [mailto:cctalk-boun...@classiccmp.org] Namens Chuck Guzis > Verzonden: woensdag 2 december 2015 23:24 > Aan: General Discussion: On-Topic Posts > Onderwerp: Re: TU-58 > > On 12/02/2015 01:51 PM, Rik Bos wrote: > > > It's not the first time this discussion comes around.. Poly Urethane > > rubber, it's called in dutch 'precisie buis/slang' and you can get it > > in several sizes from 6mm to . large http://www.deboerit.nl/ is my > > supplier it's a local firm. > > That's curious--when this popped into my inbox, I was in the middle of asking if > anyone used PU hose for this purpose. I'll add a caution that PU comes in many > durometer ratings and that I don't know what's appropriate for this use. > > But yeah, the stuff is very common. I'd be surprised if McMaster-Carr didn't sell > it. > > --Chuck It shouldn't be too soft, soft rollers have too much friction. But normal hose grade PU should perform ok. -Rik
Re: TU-58
Thanks .. That helps. 1. The hub measures about 11mm so I should be able to get a 10mm bore hose on (warm it up a bit might help) . 2. What type of glue is best? 3. You can see how thick the old one was but yours seems a little bigger? 4. From what I have seen on the list the actual outer diameter is 0.625 inches. I calculate that as 15.9 mm Thanks ... Rod Smallwood On 03/12/2015 10:02, Rik Bos wrote: -Oorspronkelijk bericht- Van: cctalk [mailto:cctalk-boun...@classiccmp.org] Namens Rod Smallwood Verzonden: woensdag 2 december 2015 23:20 Aan: General Discussion: On-Topic and Off-Topic Posts Onderwerp: Re: TU-58 Hi Well it certainly works for you Rik. I dont speak Dutch and its not clear exactly which of the products you refer to. The end of hub appears to have been turned on a lathe. So if you speak Dutch and have a nice big lathe in your shed you can fix your TU58 For us lesser mortals the search goes on. Rod Rod, I don't use the lathe but I use a small dc motor in my vice , most of the time the motor from the drive. I use a "Eze-Lap Fine Diamond Pocket Stone 1" x6" (600)" to make them to the right size. Some times when I have to remove more material I start with Scotch Wet and Dry 150 sanding paper wrapped around the Eze-Lap. It's all about craftsmanship and a steady hand if you keep the motor running at a steady speed about 50% of its nominal voltage everybody should be able to do this. After gluing the rubber to the capstan it takes me about 20-40 minutes to get the rubber to the right size. So you lesser mortals should be able to do this too. For the tubing use something with the right inner size (a little smaller than the hub) the outer size should be a little larger. And look for an industrial hose/rubber supplier both PU and Neoprene should work. -Rik
Re: Purchased a Microvax 3800
> > Yes, that is an M7626 KA660 VAX 4000-200 CPU. The blue connector is > the H3602 console panel connector, the bottom grey connector is the > memory connector, and the top grey connector with two notches is the > DSSI connector. > > I recently removed the battery from my M7627 KA660 and documented with photos, at the bottom of my 4000-200 restoration thread. Hopefully you will find the visuals useful. I found no similar photos on the web when I attempted the job: http://vintagecomputer.net/browse_thread.cfm?id=608 Bill
RE: TU-58
> Thanks .. > That helps. > > 1. The hub measures about 11mm so I should be able to get a 10mm >bore hose on (warm it up a bit might help) . Yep. > 2. What type of glue is best? I use 2k but in the past I used PU-glue, both works fine. > 3. You can see how thick the old one was but yours seems a little bigger? It's important the tape cassette presses both switches but doesn't reach the bulkhead (right name?). The tape cassette is spring loaded and needs a little room to move (<1mm). Put an tape without cover (just the ground plate) in the drive and you can measure the distance between the drive wheel and the capstan ad a little (about 1mm or less) and got the thickness of the rubber. There is enough tolerance in the electronics, so you have room to experiment. > 4. From what I have seen on the list the actual outer diameter is > 0.625 inches. I calculate that as 15.9 mm, looks good to me. -Rik
Pi (was: Re: TU-58)
On Dec 2, 2015, at 5:22 PM, Fred Cisin wrote: > I tried measuring a whole bunch of circles, and I can't find any rational > reason why dividing the circumference by the diameter never came out even! :-) Howzabout: go to Fort Smith, NT, Canada (or thereabouts, 60° N) Walk or swim as appropriate, measuring distance, due East until you get back to Fort Smith. You got back, so it must have been a circle, yes? Walk or swim to the N. pole, measuring distance again. Compute ratio of distances. I think both Pythagoras and Eratosthenes would be thrilled at the result. - Mark
Pi (was: Re: TU-58)
On Dec 2, 2015, at 5:27 PM, Johnny Billquist wrote: > You need to measure more of them! You've just been unlucky. > > Johnny Unfair advantage! Johnny might actually have driven through Hagfors or Uddeholm! (Also 60° N)
Re: Purchased a Microvax 3800
Well that works out. I've got a couple Of dssi controllers now. Not sure what that 50 pin cable could have gone to either. I have not opened the top half of the machine yet. Thank you for the pictures of where the battery are. I was looking on the main cpu board itself. Ive yet to take that apart but it is next on my list. I stockpiled a bunch of lithium batteries fror phone handsets when radio shack closed down, they were throwing a bunch of them away. odds are something in the pile will be what i need as a replacement. On Thu, Dec 3, 2015 at 7:49 AM, william degnan wrote: > > > > Yes, that is an M7626 KA660 VAX 4000-200 CPU. The blue connector is > > the H3602 console panel connector, the bottom grey connector is the > > memory connector, and the top grey connector with two notches is the > > DSSI connector. > > > > > I recently removed the battery from my M7627 KA660 and documented with > photos, at the bottom of my 4000-200 restoration thread. Hopefully you > will find the visuals useful. I found no similar photos on the web when I > attempted the job: > > http://vintagecomputer.net/browse_thread.cfm?id=608 > > Bill >
Fabritek MP-12 Loader
A colleague and I are working on getting our respective Fabritek MP-12s working. The MP-12 is an industrial-looking computer with a very limited front panel (deposit doesn't increment PC...gah!) but does emulate most respects of a PDP-8. So far, we've been able to find the device codes for updating the 7-segment LED displays on the front, turning on and off relays, and setting some arbitrary open-collector outputs. It appears as though there is no serial port option on ours, which is unfortunate. There are three 512-by-4 bipolar (configured as 512-by-12) PROMs that seem to override the core memory at the top of the 4k field. If the PROM's value is octal, the core memory is accessible. Otherwise, you're stuck with ROM, best I can tell. We've dumped the ROMs to verify, but here's the code I've backed out of them, disassembled and labeled where appropriate: *7756 TEMP, 7755 /NOT IN ROM CLA HLT /7602 ADDR, 7755 /7755 STARTING ADDRESS? START, TAD ADDR /1360 GET STARTING ADDRESS? DCA TEMP /3356 SAVE TEMPORARILY LOOP, RRB /6012 GET CHAR CLL RTL /7106 RTL /7006 RTL /7006 ROTATE SO BIT 0 IS IN BIT 7, BIT 4 IN BIT 11, ETC. 6015 /6015 SKIP ON FLAG? JMP .-1 /5367 SNL /7420 SKIP IF LINK IS SET (BIT 6 OF PAPER TAPE IS SET) JMP LOOP /5363 DCA I TEMP /3756 ISZ TEMP /2356 JMP 7755 /5355 7776 /NOT IN ROM JMP START /5361 $ The "NOT IN ROM" indicates that the ROM's value is unprogrammed, so that you can in fact access those core locations. The values I've provided just happen to be what's in my machine's memory at this time. It looks a lot like a RIM loader, except I can't figure out for the life of me what the format should look like. Best I can tell, if RRB ORs the read buffer with the accumulator, you'll never be able to send anything but patterns matching (data & 7737). At least, that's what I've simulated. Due to the fact that they're clearing the link after the second go around, you'd be losing one bit of data. So, maybe this isn't really a program loading routine, but rather just something to store 8-bit values in core? Any other ideas? Thanks, Kyle
Re: Fabritek MP-12 Loader
> So far, we've been able to find the device codes for > updating the 7-segment LED displays on the front, turning on and off > relays, and setting some arbitrary open-collector outputs. Do you mean the seven segment displays on the paper tape reader? > There are three 512-by-4 bipolar (configured as 512-by-12) PROMs that seem > to override the core memory at the top of the 4k field. If the PROM's value > is octal, the core memory is accessible. Otherwise, you're stuck with > ROM, best I can tell. So if you jam the PROMs output to for any address, you can get to all the core (and make the machine useful)? The source for the PROM may be with that CD I gave to Al. -- Will
Re: Fabritek MP-12 Loader
On Thu, Dec 3, 2015 at 10:41 AM, William Donzelli wrote: > Do you mean the seven segment displays on the paper tape reader? > That's correct. There are seven 7-segment displays on the front, with 6 grouped together. It should make for a nice clock. :) You can even add a Sonalert to the output for an alarm, and have a 7-day calendar stored with alarms updated with paper tape! Okay...I surely don't have that much free time. So if you jam the PROMs output to for any address, you can get to > all the core (and make the machine useful)? > Or you can just remove the PROMs altogether. There's sockets for a total of 2k of PROM. Only 512 bytes are populated in these, though. > > The source for the PROM may be with that CD I gave to Al. > I asked Al a while back, and he seemed to indicate that everything you gave him is up on bitsavers already, which appears to just be the manual. If there is more information out there, that would surely help us. Kyle
Re: Fabritek MP-12 Loader
On 12/3/15 8:27 AM, Kyle Owen wrote: A colleague and I are working on getting our respective Fabritek MP-12s working. The MP-12 is an industrial-looking computer with a very limited front panel (deposit doesn't increment PC...gah!) but does emulate most respects of a PDP-8. So far, we've been able to find the device codes for updating the 7-segment LED displays on the front, turning on and off relays, and setting some arbitrary open-collector outputs. It appears as though there is no serial port option on ours, which is unfortunate. There are three 512-by-4 bipolar (configured as 512-by-12) PROMs that seem to override the core memory at the top of the 4k field. If the PROM's value is octal, the core memory is accessible. Otherwise, you're stuck with ROM, best I can tell. We've dumped the ROMs to verify, but here's the code I've backed out of them, disassembled and labeled where appropriate: *7756 TEMP, 7755 /NOT IN ROM CLA HLT /7602 ADDR, 7755 /7755 STARTING ADDRESS? START, TAD ADDR /1360 GET STARTING ADDRESS? DCA TEMP /3356 SAVE TEMPORARILY LOOP, RRB /6012 GET CHAR CLL RTL /7106 RTL /7006 RTL /7006 ROTATE SO BIT 0 IS IN BIT 7, BIT 4 IN BIT 11, ETC. 6015 /6015 SKIP ON FLAG? JMP .-1 /5367 SNL /7420 SKIP IF LINK IS SET (BIT 6 OF PAPER TAPE IS SET) JMP LOOP /5363 DCA I TEMP /3756 ISZ TEMP /2356 JMP 7755 /5355 7776 /NOT IN ROM JMP START /5361 $ The "NOT IN ROM" indicates that the ROM's value is unprogrammed, so that you can in fact access those core locations. The values I've provided just happen to be what's in my machine's memory at this time. It looks a lot like a RIM loader, except I can't figure out for the life of me what the format should look like. Best I can tell, if RRB ORs the read buffer with the accumulator, you'll never be able to send anything but patterns matching (data & 7737). At least, that's what I've simulated. Due to the fact that they're clearing the link after the second go around, you'd be losing one bit of data. So, maybe this isn't really a program loading routine, but rather just something to store 8-bit values in core? Any other ideas? Thanks, Kyle I have what sounds like the same machine outfitted with the same interface (basically it looks like a synchronous serial port). I don't have the paper tape reader, though. I appear to have the same PROMs in mine; here's my disassembly from a couple of years back: AddrData 77577602CLA, HLT / Probably data 77607755/ Also data 77611360TAD 7660/ Read starting address 77623356DCA 7756/ Deposit AC (7755) in 7756 77636012 / Start high-speed reader operation 77647106CLL, RTL/ Clear link, rotate left twice 77657006RTL/ twice more 77667006RTL/ and again (rotated left 6 bits, bit 7 is in link) 77676015/ according to MP-12 docs, a command of "5" indicates "skip if device ready and transfer data" 77705367JMP 7767/ loop until data ready 77717420SNL/ skip on link set - end of word? 77725363JMP 7763/ read next if link not set 77733756DCA I 7756/ deposit at address in 7756 77742356ISZ 7756/ increment address, skip if zero 77755355JMP 7755/ jump to instruction loaded at 7755 from tape? 77762175ISZ 175/ data (not in PROM) -- overwritten by tape (JMP to start of routine)? 5361JMP 7761/ jump to start of routine I haven't spent much more time with it and I've probably screwed up, but to me it looks like it loads in two 6-bit quantities off tape, expecting the 2nd of the two to have bit 7 set; this word is then stored in memory, the address incremented and the next pair loaded. It increments until the write address falls off the top of memory and then (i assume) executes the data at 7776, which I assume would be a JMP to the start of the code loaded from tape... My MP-12 also lacks an async serial interface, I was thinking of building some glue logic to convert from the sync (paper-tape) interface to RS232 (probably with a small microcontroller) so I could load code in, but I haven't gotten around to it yet... - Josh
Help w/ HP 88780 Tape Drive
So I got my hands on an HP 88780 1/2" Tape Drive from list Member Mark (Thanks!). The drive physically looks to be in good shape but was pretty dirty when I got it. I've cleaned up the drive and powered it up. The good news: The drive powers up. Initially I had trouble getting it to load a tape but that seems to have been resolved.
Help w/ HP 88780 Tape Drive (corrected email).
*sorry a copy went out prematurely... So I got my hands on an HP 88780 1/2" Tape Drive from list Member Mark (Thanks!). The drive physically looks to be in good shape but was pretty dirty when I got it. I've cleaned up the drive and powered it up. The good news: The drive powers up. Initially I had trouble getting it to load a tape but that seems to have been resolved. The BOT, EOT sensors are good and the basic drive mechanism (motor, eject, etc.) seem to be working. The bad news: Some of the front panel buttons are not working. Running test 72 shows failure in the unload/rewind and online buttons. Luckily it seems to be a mechanical problem. If I short the switch on the circuit board then the test passes. The switches are mechanical push buttons that are soldered on so should be easy to replace. Anyone know of a good or OEM equivalent replacement? If need be I can get pictures of the buttons off the PCB. The worse news: The tape drive will not read/write. I ran test 01 which per the service manual does a full general checkout of the drive. The test is a conglomerate of other test routines. It fails when it tries to run test 177 (Buffer Write Density ID). This is where I am currently stock and need advice on how to proceed. Any help is appreciated. TIA -Ali
Re: Pi (was: Re: TU-58)
I tried measuring a whole bunch of circles, and I can't find any rational
reason why dividing the circumference by the diameter never came out even! :-)
On Thu, 3 Dec 2015, Tapley, Mark wrote:
Howzabout: go to Fort Smith, NT, Canada (or thereabouts, 60? N)
Walk or swim as appropriate, measuring distance, due East until you get back to
Fort Smith. You got back, so it must have been a circle, yes?
Walk or swim to the N. pole, measuring distance again.
Compute ratio of distances.
I think both Pythagoras and Eratosthenes would be thrilled at the result.
Thanks to Riemann for removing the IRRATIONALITY of
imposing a Euclidean structure!
Now, for the fun geometric calculations:
What latitude would give you a value of PI of 3.0?
(the distance [on a great circle] to the pole would
be 1/6 (1/(2*PI)) the circumference of your circle)
And, of course, "a spherical chicken in a vacuum",
we'll assume that the earth were a perfect sphere.
Can I get crowd-funding for the expedition?
We could put a plaque there!
("Distance to the pole is x,
distance due east all the way back to here is 6x,
therefore, right here, PI is 3.0")
(I think that Ethan Dicks has been to the southern one)
Another calculation that has been bothering me, . . .
For a message of length of N bits, it will presumably
occur somewhere in PI. Rather than store the entire
message, we could, instead, store the number of bits
offset into PI where that message first occurs.
Acknowledging that PI is random, as far as we are concerned,
what would the AVERAGE offset be as a function of N?
OB_CC: What were the early significant projects of calculating PI?
--
Grumpy Ol' Fred ci...@xenosoft.com
Re: Help w/ HP 88780 Tape Drive (corrected email).
On Thu, Dec 3, 2015 at 1:05 PM, Ali wrote: > So I got my hands on an HP 88780 1/2" Tape Drive... > > The bad news: > > Some of the front panel buttons are not working. Running test 72 shows > failure in the unload/rewind and online buttons. Luckily it seems to be a > mechanical problem. If I short the switch on the circuit board then the test > passes. The switches are mechanical push buttons that are soldered on so > should be easy to replace. Anyone know of a good or OEM equivalent > replacement? If need be I can get pictures of the buttons off the PCB. I have been recently cleaning and testing an HP 7980A. I also had problems with some of the mechanical buttons, verified with TEST 72. I was able to clean most of them with contact cleaner and agitation, but the ONLINE button was stubborn. I ended up replacing it with a generic 2-pin tactile switch. I do not know where to get OEM switches of this exact type - they are somewhat taller than cheap tactile switches, and appear to have a solid conductive rubber button/pad instead of a plastic top and metal internals. My defective button has a closed resistance measuring in multiple K ohms. I would also love to hear of a source of replacement buttons of the original style. -ethan
Re: Help w/ HP 88780 Tape Drive (corrected email).
> On Dec 3, 2015, at 10:05 , Ali wrote: > So I got my hands on an HP 88780 1/2" Tape Drive from list Member Mark > (Thanks!). I bought that drive and a Kennedy 9610 (which I'm keeping for myself) at the recycler who has the System/32. I saw them under a pile and snatched them immediately, hoping they would be useful. Both ended up having SCSI interfaces. I haven't done much with my Kennedy drive yet other than ordering a replacement power switch for it. -- Mark J. Blair, NF6X http://www.nf6x.net/
RE: TU-58
> > I tried measuring a whole bunch of circles, and I can't find any rational > reason why dividing the circumference by the diameter never came out even! > :-) Groan! -tony
RE: Triprocessor PDP-10 [Was: Re: [multicians] Emacs humor]
From: Pontus Pihlgren Sent: Wednesday, December 02, 2015 11:30 PM > On Wed, Dec 02, 2015 at 06:47:12PM +, Rich Alderson wrote: >> From: Pontus Pihlgren >> Sent: Wednesday, December 02, 2015 12:19 AM >>> On Wed, Dec 02, 2015 at 02:13:06AM +, Rich Alderson wrote: KL-10/PDP-10/PDP-6 triprocessor, and KL-10/PDP-10 dual processor and >>> You make it sound like someone hacked up a computer consisting of one >>> KL-10, one PDP-10 and one PDP-6. But I assume you mean homogenic >>> three-processor machines? >> You assume incorrectly. I mean exactly what it sounds like. > Wow, that's impressive. How was it done? Was it done with DEC or was it > a local "hack"? As far as I know, it was a local hack, but if you really care I can ask my friends who were the systems programmers on SAIL back in the day. 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: TU-58
> Hi > Well it certainly works for you Rik. > I dont speak Dutch and its not clear exactly which of the products you > refer to. > The end of hub appears to have been turned on a lathe. > So if you speak Dutch and have a nice big lathe in your shed you can fix > your TU58 Surely you don't need a big lathe. A small lathe, a Unimat, a Taig/Peatol, etc would be easily big enough to make hubs for the TU58. I hate to say it, but IMHO if you are restoring a classic computer which needs significant mechanical work (drive rollers, pulleys, spacers, tapped bushes, etc) then access to an engineer's lathe (and the ability to use it) is almost essential. -tony
Re: Fabritek MP-12 Loader
On Thu, Dec 3, 2015 at 11:09 AM, Josh Dersch wrote: > > I have what sounds like the same machine outfitted with the same interface > (basically it looks like a synchronous serial port). I don't have the > paper tape reader, though. Yes, sounds like the same configuration indeed! > I appear to have the same PROMs in mine; here's my disassembly from a > couple of years back: > > AddrData > 77577602CLA, HLT / Probably data > 77607755/ Also data > 77611360TAD 7660/ Read starting address > 77623356DCA 7756/ Deposit AC (7755) in 7756 > 77636012 / Start high-speed reader operation > 77647106CLL, RTL/ Clear link, rotate left twice > 77657006RTL/ twice more > 77667006RTL/ and again (rotated left 6 bits, bit 7 is in > link) > 77676015/ according to MP-12 docs, a command of "5" > indicates "skip if device ready and transfer data" > 77705367JMP 7767/ loop until data ready > 77717420SNL/ skip on link set - end of word? > 77725363JMP 7763/ read next if link not set > 77733756DCA I 7756/ deposit at address in 7756 > 77742356ISZ 7756/ increment address, skip if zero > 77755355JMP 7755/ jump to instruction loaded at 7755 from tape? > 77762175ISZ 175/ data (not in PROM) -- overwritten by tape > (JMP to start of routine)? > 5361JMP 7761/ jump to start of routine > Yeah, that's identical to mine. Thanks for the confirmation! I haven't spent much more time with it and I've probably screwed up, but to > me it looks like it loads in two 6-bit quantities off tape, expecting the > 2nd of the two to have bit 7 set; this word is then stored in memory, the > address incremented and the next pair loaded. It increments until the write > address falls off the top of memory and then (i assume) executes the data > at 7776, which I assume would be a JMP to the start of the code loaded from > tape... > At first glance, that's what I'd expect it to do too. However, (and more testing is required on my part to confirm) I don't think the 6015 instruction modifies the accumulator at all. If it does, I can foresee this working more or less as you mentioned. However, I can't figure out why after incrementing the pointer located at 7756, it needs to jump to 7755. Presumably that would be the first location changed by the paper tape loading, so if you want to continue loading, wouldn't you want your first instruction on tape to be a jump back to the loader? That's the stumper for me. My MP-12 also lacks an async serial interface, I was thinking of building > some glue logic to convert from the sync (paper-tape) interface to RS232 > (probably with a small microcontroller) so I could load code in, but I > haven't gotten around to it yet... It doesn't look like it'd be too hard. The synchronous interface provides much more support that for just the reader; you also get the relays, 7-segment displays, 8-bit parallel output, and presumably the buttons on the front of the reader unit too. Still figuring out the buttons; I haven't spent much time investigating them just yet. Thanks! Kyle
Re: Fabritek MP-12 Loader
On Thu, Dec 3, 2015 at 12:15 PM, Kyle Owen wrote: > On Thu, Dec 3, 2015 at 11:09 AM, Josh Dersch wrote: > > > > I have what sounds like the same machine outfitted with the same > interface > > (basically it looks like a synchronous serial port). I don't have the > > paper tape reader, though. > > > Yes, sounds like the same configuration indeed! > > > > I appear to have the same PROMs in mine; here's my disassembly from a > > couple of years back: > > > > AddrData > > 77577602CLA, HLT / Probably data > > 77607755/ Also data > > 77611360TAD 7660/ Read starting address > > 77623356DCA 7756/ Deposit AC (7755) in 7756 > > 77636012 / Start high-speed reader operation > > 77647106CLL, RTL/ Clear link, rotate left twice > > 77657006RTL/ twice more > > 77667006RTL/ and again (rotated left 6 bits, bit 7 is in > > link) > > 77676015/ according to MP-12 docs, a command of "5" > > indicates "skip if device ready and transfer data" > > 77705367JMP 7767/ loop until data ready > > 77717420SNL/ skip on link set - end of word? > > 77725363JMP 7763/ read next if link not set > > 77733756DCA I 7756/ deposit at address in 7756 > > 77742356ISZ 7756/ increment address, skip if zero > > 77755355JMP 7755/ jump to instruction loaded at 7755 from > tape? > > 77762175ISZ 175/ data (not in PROM) -- overwritten by > tape > > (JMP to start of routine)? > > 5361JMP 7761/ jump to start of routine > > > > Yeah, that's identical to mine. Thanks for the confirmation! > > I haven't spent much more time with it and I've probably screwed up, but to > > me it looks like it loads in two 6-bit quantities off tape, expecting the > > 2nd of the two to have bit 7 set; this word is then stored in memory, the > > address incremented and the next pair loaded. It increments until the > write > > address falls off the top of memory and then (i assume) executes the data > > at 7776, which I assume would be a JMP to the start of the code loaded > from > > tape... > > > > At first glance, that's what I'd expect it to do too. However, (and more > testing is required on my part to confirm) I don't think the 6015 > instruction modifies the accumulator at all. My understanding is that 6015 does modify the accumulator -- from the manual ( http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/fabritek/402-1001-00_MP12refMan_1974.pdf ) Function code 5(8) is interpreted as "...if th the addressed device is DONE, the next instruction in sequence is skipped, the contents of the device buffer are inclusive OR'd with the accumulator, and the result is retained in the accumulator..." So 6015 reads the next 8-bit quantity from the paper tape and ORs it onto AC. > If it does, I can foresee this > working more or less as you mentioned. However, I can't figure out why > after incrementing the pointer located at 7756, it needs to jump to 7755. > Presumably that would be the first location changed by the paper tape > loading, so if you want to continue loading, wouldn't you want your first > instruction on tape to be a jump back to the loader? That's the stumper for > me. > Yeah, I was actually just looking at that again and the jump to 7755 is rather odd. I think that's what stumped me a couple of years back and since I never got around to building the interface... I think I just assumed a couple of bits had gone south on my PROMs, to be honest. > > My MP-12 also lacks an async serial interface, I was thinking of building > > some glue logic to convert from the sync (paper-tape) interface to RS232 > > (probably with a small microcontroller) so I could load code in, but I > > haven't gotten around to it yet... > > > It doesn't look like it'd be too hard. The synchronous interface provides > much more support that for just the reader; you also get the relays, > 7-segment displays, 8-bit parallel output, and presumably the buttons on > the front of the reader unit too. Still figuring out the buttons; I haven't > spent much time investigating them just yet. > That's interesting -- on my MP-12, the sync interface brings out (IIRC) three lines: clock, data in, and data out. I'd be interested to know what hardware's hooked up to yours to provide all the goodies you have. - Josh > > Thanks! > > Kyle >
Re: TU-58
Great! We take it off list from here. Very nice work on the HP by the way! /Anders > Date: Wed, 2 Dec 2015 21:04:55 +0100 > From: Rik Bos > To: "General Discussion: On-Topic Posts" > Subject: RE: TU-58 > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Anders, > > I can fix them, if you look at my Flickr page you can see some examples of > new capstans I made.about halfway the site. > www.flickr.com/hp-fix > And of the HP3000 ;) > > -Rik
Re: Fabritek MP-12 Loader
On Thu, Dec 3, 2015 at 2:24 PM, Josh Dersch wrote: > > My understanding is that 6015 does modify the accumulator -- from the > manual > ( > > http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/fabritek/402-1001-00_MP12refMan_1974.pdf > ) > Function code 5(8) is interpreted as "...if th the addressed device is > DONE, the next instruction in sequence is skipped, the contents of the > device buffer are inclusive OR'd with the accumulator, and the result is > retained in the accumulator..." > > So 6015 reads the next 8-bit quantity from the paper tape and ORs it onto > AC. > Yes, it might very well. I wrote up a bit of code to test it out and don't remember that being the case, but then again, it was late and I was probably not thinking clearly. Yeah, I was actually just looking at that again and the jump to 7755 is > rather odd. I think that's what stumped me a couple of years back and > since I never got around to building the interface... I think I just > assumed a couple of bits had gone south on my PROMs, to be honest. > Well, fear not for bad bits, unless three of these units have failing PROMs. I think the ones in my colleague's unit are from the 1990s. Impressive they were using these units up until then (or considerably after, perhaps!). That's interesting -- on my MP-12, the sync interface brings out (IIRC) > three lines: clock, data in, and data out. I'd be interested to know what > hardware's hooked up to yours to provide all the goodies you have. > Indeed. All of the functions mentioned are all transferred via the synchronous interface. I'm not sure how much decoding is done in the big box versus the little box, but if I were a betting man, I'd say it's mostly done in the big box. The little box has the seven 7-segment displays, a paper tape reader, some arbitrary outputs, and some buttons. There are three removable cards to make it all happen, and the DA-15 connector supplies 120VAC as well as the synchronous data/clock lines to the little box. There's an effort to reverse engineer the little box, then move up to the big box. My colleague has already reverse engineered the 7-segment driver board. It's my goal to get all of this information collected together somewhere where it can be made available to all. I think the size and surprising capability of the Fabritek makes it the most clone-able of the TTL PDP-8s; much of the functionality of a Straight-8 for instance, without the bulk. If we went with surface-mount 7400-series, as well as battery-backed SRAM, there's a good chance we could improve upon the functionality (especially front panel operations!) and add more memory, switchable ROM space, etc. It'll be a pipe dream for now, though. Kyle
Re: TU-58
Hi Tony Thats interesting I had thought about a model makers lathe. I have a pillar drill and the usual set of tools. I did start out as a mechanical engineer and my top subjects at school were metalwork and technical drawing. My metalwork master put me in for those subjects in GCE a year early ie 15 instead of 16. I duly passed and come September and the first metalwork class and I'm already to go. The teacher pounces on me an asks me where the hell do I think I'm going. You passed didn't you? Yes says I. So I got excused school one afternoon a week. Shucks.. My favorite lessons and I couldn't go!!! I only changed to electronics for reasons beyond my control. It looks like a visit to Machine Mart may be coming up. On 03/12/15 17:32, tony duell wrote: Hi Well it certainly works for you Rik. I dont speak Dutch and its not clear exactly which of the products you refer to. The end of hub appears to have been turned on a lathe. So if you speak Dutch and have a nice big lathe in your shed you can fix your TU58 Surely you don't need a big lathe. A small lathe, a Unimat, a Taig/Peatol, etc would be easily big enough to make hubs for the TU58. I hate to say it, but IMHO if you are restoring a classic computer which needs significant mechanical work (drive rollers, pulleys, spacers, tapped bushes, etc) then access to an engineer's lathe (and the ability to use it) is almost essential. -tony
Re: Triprocessor PDP-10 [Was: Re: [multicians] Emacs humor]
On Thu, Dec 3, 2015 at 12:29 AM, Pontus Pihlgren wrote:
[about KL10/KA10/PDP-6 tri-processor
> Wow, that's impressive. How was it done? Was it done with DEC or was it
> a local "hack"?
Prior to the 1091 and 20xx, all PDP-10 processors used essentially the
same memory bus, and the memory boxes were multiported. The necessary
hardware configuration might not have been quite as simple as just
cabling the three dissimilar processors to the memory boxes, but it
probably wasn't too terribly complicated.
Getting standard DEC software to run on such a configuration would
have required quite a bit of work. DEC supported asymmetric
multiprocessing on the KA10 (DECsystem-1055) and KI10
(DECsystem-1077), and possibly on the KL10 (DECsystem-1088). Symmetric
multiprocessing (SMP) wasn't available in TOPS-10 until some time
after the KL10 was available, and for SMP only multi-KL10 systems were
supported. I think SAIL ran the WAITS operating system, rather than a
DEC OS, though WAITS probably started out as a fork of an early DEC
PDP-10 "Monitor". ("Monitor" was the name of the OS before it became
TOPS-10.)
My understanding is that the SAIL tri-processor configuration was
asymmetric multiprocessing. (Not just asymmetric in that the CPUs
were different, but also in how I/O devices were configured on them,
and which CPU the operating system mostly ran on.) However, I wasn't
there and only heard about the system second-hand at best.
