From bhilpert at shaw.ca Fri Apr 1 01:52:32 2022 From: bhilpert at shaw.ca (Brent Hilpert) Date: Thu, 31 Mar 2022 23:52:32 -0700 Subject: Glass memory? In-Reply-To: References: Message-ID: On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote: > Hey all, found this on eBay: > > https://www.ebay.com/itm/Corning-Glass-memory-/125087612899 > > I can't find any info on it - was it some kind of delay-line or magnetic > laminate stack? > > Interesting! Very interesting - there were glass/quartz delay lines used in TV but never seen such before for digital. So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but wondered how the path would be long enough for delays needed (path too short for waves too fast). Second guess then could be a quartz internal reflection delay line. See pdfPg.9: https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf The period is right, those Sylvania ICs in the unit place it in mid-late 60s. I've analysed a couple of magneto-strictive wire acoustic delay lines so have some feel for properties/numbers there, but don't know how glass/quartz compares. From mhuffstutter at outlook.com Fri Apr 1 01:56:36 2022 From: mhuffstutter at outlook.com (Mark Huffstutter) Date: Fri, 1 Apr 2022 06:56:36 +0000 Subject: Glass memory? In-Reply-To: References: Message-ID: Here is some pretty good information. https://archive.org/details/TNM_Glass_computer_memories_-_Corning_Electronics_20171206_0185 Mark -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent Hilpert via cctalk Sent: Thursday, March 31, 2022 11:53 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Glass memory? On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote: > Hey all, found this on eBay: > > https://www.ebay.com/itm/Corning-Glass-memory-/125087612899 > > I can't find any info on it - was it some kind of delay-line or magnetic > laminate stack? > > Interesting! Very interesting - there were glass/quartz delay lines used in TV but never seen such before for digital. So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but wondered how the path would be long enough for delays needed (path too short for waves too fast). Second guess then could be a quartz internal reflection delay line. See pdfPg.9: https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf The period is right, those Sylvania ICs in the unit place it in mid-late 60s. I've analysed a couple of magneto-strictive wire acoustic delay lines so have some feel for properties/numbers there, but don't know how glass/quartz compares. From bhilpert at shaw.ca Fri Apr 1 02:12:55 2022 From: bhilpert at shaw.ca (Brent Hilpert) Date: Fri, 1 Apr 2022 00:12:55 -0700 Subject: Glass memory? In-Reply-To: References: Message-ID: On 2022-Mar-31, at 11:56 PM, Mark Huffstutter via cctalk wrote: > -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent Hilpert via cctalk > Sent: Thursday, March 31, 2022 11:53 PM > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: Glass memory? > > On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote: >> Hey all, found this on eBay: >> >> https://www.ebay.com/itm/Corning-Glass-memory-/125087612899 >> >> I can't find any info on it - was it some kind of delay-line or magnetic >> laminate stack? >> >> Interesting! > > > Very interesting - there were glass/quartz delay lines used in TV but never seen such before for digital. > > So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but wondered how the path would be long enough for delays needed (path too short for waves too fast). > > Second guess then could be a quartz internal reflection delay line. See pdfPg.9: > > https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf > > The period is right, those Sylvania ICs in the unit place it in mid-late 60s. > > I've analysed a couple of magneto-strictive wire acoustic delay lines so have some feel for properties/numbers there, but don't know how glass/quartz compares. ------------------------ > Here is some pretty good information. > > https://archive.org/details/TNM_Glass_computer_memories_-_Corning_Electronics_20171206_0185 > > Mark Great document! Yup, internal reflection. From bhilpert at shaw.ca Fri Apr 1 01:46:46 2022 From: bhilpert at shaw.ca (Brent Hilpert) Date: Thu, 31 Mar 2022 23:46:46 -0700 Subject: Glass memory? In-Reply-To: References: Message-ID: <425C1980-1D13-4E67-92D1-CDD2CFBE5C05@shaw.ca> On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote: > Hey all, found this on eBay: > > https://www.ebay.com/itm/Corning-Glass-memory-/125087612899 > > I can't find any info on it - was it some kind of delay-line or magnetic > laminate stack? > > Interesting! Very interesting - there were glass/quartz delay lines used in TV but never seen such before for digital. So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but wondered how the path would be long enough for delays needed (path too short for waves too fast). Second guess then could be a quartz internal reflection delay line. See pdfPg.9: https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf I've analysed a couple of magneto-strictive wire acoustic delay lines so have some feel for properties/numbers there, but don't know how glass/quartz compares. From mhuffstutter at outlook.com Fri Apr 1 03:08:00 2022 From: mhuffstutter at outlook.com (Mark Huffstutter) Date: Fri, 1 Apr 2022 08:08:00 +0000 Subject: Glass memory? In-Reply-To: <425C1980-1D13-4E67-92D1-CDD2CFBE5C05@shaw.ca> References: <425C1980-1D13-4E67-92D1-CDD2CFBE5C05@shaw.ca> Message-ID: That's where I first learned about SAW devices, in Broadcasting. Used to maintain Ikegami 79D ENG field cameras, Ike used them As H line delays to construct a mask signal of sorts to generate A Horizontal edge signal, which was applied to the video signal To add a "Detail" enhancement for sharpening the pix. Right up To a ringing edge, if You liked that sort of thing....... Mark -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent Hilpert via cctalk Sent: Thursday, March 31, 2022 11:47 PM To: Anders Nelson; General Discussion: On-Topic Posts Subject: Re: Glass memory? On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote: > Hey all, found this on eBay: > > https://www.ebay.com/itm/Corning-Glass-memory-/125087612899 > > I can't find any info on it - was it some kind of delay-line or magnetic > laminate stack? > > Interesting! Very interesting - there were glass/quartz delay lines used in TV but never seen such before for digital. So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but wondered how the path would be long enough for delays needed (path too short for waves too fast). Second guess then could be a quartz internal reflection delay line. See pdfPg.9: https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf I've analysed a couple of magneto-strictive wire acoustic delay lines so have some feel for properties/numbers there, but don't know how glass/quartz compares. From bhilpert at shaw.ca Fri Apr 1 04:05:35 2022 From: bhilpert at shaw.ca (Brent Hilpert) Date: Fri, 1 Apr 2022 02:05:35 -0700 Subject: PDP 11/24 - A Step Backwards In-Reply-To: <20220401024454.B0C3318C083@mercury.lcs.mit.edu> References: <20220401024454.B0C3318C083@mercury.lcs.mit.edu> Message-ID: On 2022-Mar-31, at 7:44 PM, Noel Chiappa wrote: >> From: Brent Hilpert >> DCLO & ACLO behave as power-on-reset signals to the system. > > Minor nit: actually, I think it's DCLO which performs that function in a lot > of places; see e.g. the latches on pg. K2 (pg. 153 of the PDF) and K7. (INIT, > usually in buffered form, is used more widely for this function, but I doubly > digress in that observation.) > > As I explained, ACLO is only used to trigger a 'power-failing' interrupt; CPU > operation is otherwise un-affected by ACLO (so the CPU can get ready). DEC P/S's > carefully sequence ACLO and DCLO such that on power-down, ACLO is asserted > first (to allow the CPU to get ready); on power-up, DCLO is de-asserted first > (the later de-assertion of ACLO is the signal for the CPU to start running). a) "ACLO is only used to trigger a 'power-failing' interrupt" b) "ACLO is the signal for the CPU to start running" Only a, or a & b? You know more about the overall/macro system function of these signals than I do, for current purposes I'm just looking at the electrical behaviour/requirements for the signals and the particulars of this environment. My point is that ACLO (and DCLO) are to remain in the same state as they are when power is off, until the power supplies are ready. Or at least the power supply design suggests (and enacts) such by intention. - Suppose ACLO were allowed to waffle high during power-up but then asserted low before CPU enable. That could trigger PF logic unless the PF logic has been designed to deal with it. Things could be designed to allow ACLO to waffle high as long as it's stable low (asserted) by the time DCLO goes high (deasserted) - maybe they are - but one would want to know that. - If bus-ACLO is left open to float high with power up, you have a slow edge feeding into FF (E67/K2_PFAIL) and thence to monostables (E126/K6). There are rise-time requirements for FF clock-edges, they can be unpredictable with slow edges (that's what Schmitt triggers are for). There's a gate there (E70) that may provide enough gain to adequately take care of the slow edge, I don't know what the specs on those bus receivers are. Now these things may well not be a problem here; I'm just looking for potential failure points because we're looking for an unknown fault by isolating things, and it's best done without introducing new potential problems, or at least being aware of the potential. > However, you make a good point with: > >> If they are allowed to just float up as the power supply comes up you >> have no guarantees as to the end result ('end' meaning the state of >> things after the power supply has come up) > > DEC specs state that DC power has to be up and stable 5 usec before DCLO can > be de-asserted ("pdp bus handbook", pg 53). This is precisly so that > everything is in a known state when operation commences. > > So I guess I'll go back to my original suggestion: disconnect the ACLO from > the P/S (with its bogus -15V), leaving DCLO, so that it can properly set > everything to a known state on power-on, and then you can see see if E70 has > been fried, or is still working. > > >> Manually connecting/disconnecting bus-ACLO to GND after power-up will >> ... disable the clock. > > I can't see anything in the clock circuitry on pg. K1 (pg. 152 of the PDF), > where all the clocks are generated, that looks at ACLO, or its inverted form > POWER OK, or its latched form, PFAIL (both generated in the bottom RH corner > of K2)? Did I miss something? All I can see is DCLO. ACLO exercises influence over DCLO and hence the CPU clock via those those monostables (we both) mentioned earlier. ACLO -edge: ==> inverted (E70.2/K2) to +edge ==> triggers FF (E67/K2_PFAIL) to latch high ==> triggers MonoFF (E126/K6_AC_TIM) ==> triggers MonoFF (E126.10-5/K6) ==> asserting K6_BUF_DCLO_L for some period ==> which disables MCLK counter (E41/K1) I haven't analysed things further in full to say what happens after that, whether the clock is stopped for good or just temporarily, just that there is a path of influence from ACLO (-edge) in there. It may be that it just stops the clock temporarily: DCLO asserted resets E67/K2_PFAIL, clearing it to register another ACLO / P FAIL. > I'm too burned out right now to check for uses of ACLO/POWER-OK/PFAIL, to see > definitively what it does do; tomorrow. Given Rob's message about alterations on the CPU board regarding ACLO - although it's not clear what those alterations are - I thinks he's right to poke around the clock circuitry looking for where the clock is being inhibited. From paulkoning at comcast.net Fri Apr 1 07:54:23 2022 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 1 Apr 2022 08:54:23 -0400 Subject: Glass memory? In-Reply-To: References: Message-ID: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> > On Apr 1, 2022, at 2:56 AM, Mark Huffstutter via cctalk wrote: > > Here is some pretty good information. > > https://archive.org/details/TNM_Glass_computer_memories_-_Corning_Electronics_20171206_0185 > > Mark Interesting stuff. When I saw Corning I thought glass fiber (optical pulse signals delay line) but their development of optical fiber came later, I think. That Corning document is also interesting because of its comparison of memory technologies it shows. Tunnel diode memories? Hm. And cryogenic, in 1962? Hm again. paul From paulkoning at comcast.net Fri Apr 1 08:02:41 2022 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 1 Apr 2022 09:02:41 -0400 Subject: Core memory Message-ID: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> When I looked at that ebay listing of "glass memory" it pointed me to another item, https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells. paul From jnc at mercury.lcs.mit.edu Fri Apr 1 12:17:11 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 1 Apr 2022 13:17:11 -0400 (EDT) Subject: PDP 11/24 - A Step Backwards Message-ID: <20220401171711.3597718C088@mercury.lcs.mit.edu> > From: Brent Hilpert >> ACLO is only used to trigger a 'power-failing' interrupt; CPU >> operation is otherwise un-affected by ACLO (so the CPU can get ready). >> DEC P/S's carefully sequence ACLO and DCLO such that on power-down, >> ACLO is asserted first (to allow the CPU to get ready); on power-up, >> DCLO is de-asserted first (the later de-assertion of ACLO is the >> signal for the CPU to start running). > a) "ACLO is only used to trigger a 'power-failing' interrupt" > b) "ACLO is the signal for the CPU to start running" > Only a, or a & b? Sorry, I tried to write only 10 words, when I should have just bitten the bullet and written 40. There are two different circumstances: i) AC power coming on, and ii) AC power going off. (Sorry if you already know this next, but I'm not skipping anything any more: DEC paid careful attention to both, as the PDP-11's were always intended to be able to deal well with un-attended operation over an un-expected power outage. So they had to shut down in an orderly way on ii), and start up in an orderly way on i). Having the operator press a 'reset' button after power-on was not an option! Of course, the software had to be written to handle it all, and not all of it did so; e.g. UNIX V6 didn't deal well with either, whereas RSTS-11 would go through an outage and automagically pick up exactly where it was when power went down.) So when I said "ACLO is only used to trigger a 'power-failing' interrupt", the un-stated circumstance was 'when AC power goes off'. The bit about "de-assertion of ACLO [on power-up] is the signal for the CPU to start running" is something I hadn't known, but just picked up (it's not anything I ever had to pay attention to before) from reading the "Initialization" section in the "pdp11 bus handbook" - which is not (alas) online. (Maybe I should scan, OCR and port that section; it's fairly short.) (There _is_ a "pdp-11 UNIBUS Design Description" document online: http://www.bitsavers.org/pdf/dec/unibus/UnibusSpec1979.pdf but alas it doesn't have anything like the detail given in the "pdp11 bus handbook". 2.5 there, "Initialization Section", has some text about ACLO, DCLO and INIT (which is generated by the CPU, not the P/S), but not much.) Here's what the "pdp11 bus handbook" says (pg. 54): "When [the processor] senses the negation of ACLO, [which happens after the negation of DCLO, which itself happens "5 useconds after DC power is within specifications" - i.e. plenty of time for all logic to reset itself to a known state, after good power is available to it all] the processor starts its power-up sequence." How that happens in the -11/24 I'm not sure; the -11/24 TM doesn't cover it, and the Fonz, which we don't have documentation on, will be involved. > Now these things may well not be a problem here; I'm just looking for > potential failure points because we're looking for an unknown fault by > isolating things, and it's best done without introducing new potential > problems, or at least being aware of the potential. Makes sense. > ACLO exercises influence over DCLO and hence the CPU clock via those > those monostables (we both) mentioned earlier. Right, I had forgotten about those - it was late, and my brain was shutting down as I was tired. > ACLO -edge: > ==> inverted (E70.2/K2) to +edge > ==> triggers FF (E67/K2_PFAIL) to latch high > ==> triggers MonoFF (E126/K6_AC_TIM) > ==> triggers MonoFF (E126.10-5/K6) > ==> asserting K6_BUF_DCLO_L for some period It's not clear to me what the _point_ of that all is; I had previously guessed that "there's a delay between the PFAIL H input .. and _the CPU_'s assertion of DCLO - i.e. if the P/S goes bonkers and indicates ACLO, and doesn't promptly (after a suitable short delay to allow for power-fail action) follow it with DCLO, as it is _supposed_ to, the CPU will indicate DCLO on its own - and do it on the bus so everbody else will freeze too." That might still be correct - I think that perhaps that path through the monostables only operates on power-down (but maybe I'n wrong there, I don't really understand completely how that all works) - on power-up, PFAIL H is going to be a falling edge - so will the two E126 monostables just ignore that? Alas, the -11/24 TM doesn't cover this, as far as I could find. AC TIM winds up being used on K1, on the monostable at top right, which I think generates a bus INIT pulse, when called for by the microcode (MIB14). No idea why they need AC TIM to clear that monostable. > ==> which disables MCLK counter (E41/K1) Right, but does that happen just on power-down, or on power-up too? I'd need to understand how that two monostable chain works in both cases, which I currently don't. (I only understand monostables when pulses trigger them, not edges, which is a big part of why I don't completely understand it.) > It may be that it just stops the clock temporarily: DCLO asserted resets > E67/K2_PFAIL, clearing it to register another ACLO / P FAIL. Could be; that's something else I don't understand completely; that flop's clear input depends on part on DGP06, which comes out of the E46 decoder on K1, which is again driven by the microcode. I'll have to look at the TM, and see if it explains that. > I thinks he's right to poke around the clock circuitry looking for > where the clock is being inhibited. Yup. I was hoping that if we just disconnected the busted ACLO, the clock would spring to life, and then we could move on to the next step(s), but maybe looking into that block in detail, e.g. to see if E41 is being reset by DCLO, would be the best way to go. Noel From cclist at sydex.com Fri Apr 1 12:25:46 2022 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 1 Apr 2022 10:25:46 -0700 Subject: Glass memory? In-Reply-To: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> Message-ID: <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> Wasn't some of this glass delay line memory used in early raster-scanned computer video displays? --Chuck From paulkoning at comcast.net Fri Apr 1 12:27:25 2022 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 1 Apr 2022 13:27:25 -0400 Subject: Glass memory? In-Reply-To: <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> Message-ID: > On Apr 1, 2022, at 1:25 PM, Chuck Guzis via cctalk wrote: > > Wasn't some of this glass delay line memory used in early raster-scanned > computer video displays? I don't know about that one, but a delay line is a key component of a PAL (European) system color TV receiver. paul From cclist at sydex.com Fri Apr 1 12:52:35 2022 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 1 Apr 2022 10:52:35 -0700 Subject: Glass memory? In-Reply-To: References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> Message-ID: On 4/1/22 10:27, Paul Koning wrote: > > >> On Apr 1, 2022, at 1:25 PM, Chuck Guzis via cctalk wrote: >> >> Wasn't some of this glass delay line memory used in early raster-scanned >> computer video displays? > > I don't know about that one, but a delay line is a key component of a PAL (European) system color TV receiver. I know that the CRT display controller on the CDC 200 series terminal (INTERCOM, Export/Import 200 software) used a 10 msec magnetostrictive delay line.for image storage. Glass would seem to be a more mechanically robust storage medium. See:page 1-5 http://bitsavers.org/pdf/cdc/terminal/82128000_200_User_Terminal_Hardware_Reference_Jul68.pdf Later raster terminals used MOS shift register memory. The STAR-100 stations used a track on the station microdrum for video refresh. --Chuck From go at ao-cs.com Fri Apr 1 13:04:27 2022 From: go at ao-cs.com (-Gary) Date: Fri, 01 Apr 2022 08:04:27 -1000 Subject: Glass memory? In-Reply-To: References: Message-ID: Oregon Status University constructed a general purpose computer (Nebula) in the mid 60s that used Corning glass delay lines both to construct a 4k x 34 bit main memory with an auxillary 2k Content Addressable Memory with 32 bits plus some 'tag' bits. Al archived a copy of the hardware manual on bitsavers (http://bitsavers.org/pdf/oregonState/nebula/Nebula_HardwareMan_Aug76.pdf). This manual doesn't give much detail on the physical hardware implementation, but there is design (part of the PhD thesis of designer.) If anyone has further interest, I will do a scan of the 'design' manual which has much more detail and some schematics. I am away on travel at the moment but can upload in about two weeks. At the time I was at OSU, Nebula was one of the fastest computers, measured by clock speed (27 MHz) but slowest by instruction cycle time (100uS) due to being fully bit serial. Lots of 1000-series mecl parts to do the 3 nS cycles needed for the memory bit times in the CAM but the rest as a mix of transistor, DTL and TTL devices. -Gary From bhilpert at shaw.ca Fri Apr 1 13:21:03 2022 From: bhilpert at shaw.ca (Brent Hilpert) Date: Fri, 1 Apr 2022 11:21:03 -0700 Subject: Glass memory? In-Reply-To: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> Message-ID: <061E0D90-7DF1-46F6-8E0B-2A867C170830@shaw.ca> On 2022-Apr-01, at 5:54 AM, Paul Koning via cctalk wrote: >> On Apr 1, 2022, at 2:56 AM, Mark Huffstutter via cctalk wrote: >> >> https://archive.org/details/TNM_Glass_computer_memories_-_Corning_Electronics_20171206_0185 > ... > That Corning document is also interesting because of its comparison of memory technologies it shows. Tunnel diode memories? Hm. And cryogenic, in 1962? Hm again. Are you alluding to a question of actual use in a practical large-scale implementation? Tunnel diodes did work as storage (state-holding elements), at least on a small scale. I have a frequency counter that uses a 5-stage tunnel-diode counter for the first high-speed counting stage. That is the most tunnel diodes I've seen in use in one place. As two-terminal negative-resistance devices, I wonder if there were some design attempts to put them in a matrix, something along the lines of providing the matrix axes in whole with a 'holding current' to retain state, along with 2D addressed R/W. Cryotrons I only know of from reading the period 'laboratory announcements', don't know how far they got in any practical use. From bhilpert at shaw.ca Fri Apr 1 13:21:18 2022 From: bhilpert at shaw.ca (Brent Hilpert) Date: Fri, 1 Apr 2022 11:21:18 -0700 Subject: Glass memory? In-Reply-To: References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> Message-ID: On 2022-Apr-01, at 10:52 AM, Chuck Guzis via cctalk wrote: > On 4/1/22 10:27, Paul Koning wrote: >> >>> On Apr 1, 2022, at 1:25 PM, Chuck Guzis via cctalk wrote: >>> >>> Wasn't some of this glass delay line memory used in early raster-scanned >>> computer video displays? >> >> I don't know about that one, but a delay line is a key component of a PAL (European) system color TV receiver. > > I know that the CRT display controller on the CDC 200 series terminal > (INTERCOM, Export/Import 200 software) used a 10 msec magnetostrictive > delay line.for image storage. Glass would seem to be a more > mechanically robust storage medium. > > See:page 1-5 > http://bitsavers.org/pdf/cdc/terminal/82128000_200_User_Terminal_Hardware_Reference_Jul68.pdf > > Later raster terminals used MOS shift register memory. > > The STAR-100 stations used a track on the station microdrum for video > refresh. CRT monitors would seem like a likely target application for them. Their higher speed may have worked to advantage to reduce the total memory requirement. The MOS-shif-register-memory displays typically had two R/W memories: a frame buffer and a character-line buffer, the line buffer captured one line of characters from the frame buffer as it cycled by, so it could be rescanned several times for the multiple H-scan lines forming a character. The higher speed of the glass memories perhaps would have eliminated the need for the line buffer. From bhilpert at shaw.ca Fri Apr 1 13:38:51 2022 From: bhilpert at shaw.ca (Brent Hilpert) Date: Fri, 1 Apr 2022 11:38:51 -0700 Subject: Core memory In-Reply-To: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote: > When I looked at that ebay listing of "glass memory" it pointed me to another item, https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells. Well, it would still work for 1-bit-wide words, so to speak. One wonders what the application was. There are a couple of Soviet core-rope memories up right now: https://www.ebay.com/itm/294558261336 https://www.ebay.com/itm/294851032351 Shipping from New York, curiously. The glass memory has apparently sold. From paulkoning at comcast.net Fri Apr 1 13:51:25 2022 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 1 Apr 2022 14:51:25 -0400 Subject: Core memory In-Reply-To: References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: > On Apr 1, 2022, at 2:38 PM, Brent Hilpert via cctalk wrote: > > On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote: > >> When I looked at that ebay listing of "glass memory" it pointed me to another item, https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells. > > Well, it would still work for 1-bit-wide words, so to speak. One wonders what the application was. I wonder if the sense wire was used as inhibit during write cycles -- that seems doable. It would make the core plane simpler at the expense of more complex electronics. With that approach, you have regular memory, not limited to 1 bit words. > There are a couple of Soviet core-rope memories up right now: > https://www.ebay.com/itm/294558261336 > https://www.ebay.com/itm/294851032351 Neat looking stuff. It doesn't look like core rope memory in the sense of the AGC ROM, nor in the sense of the Electrologica X1. It looks more like the transformer memory used in Wang calculators that you documented in your core ROM paper. paul From jwsmail at jwsss.com Fri Apr 1 14:05:52 2022 From: jwsmail at jwsss.com (jim stephens) Date: Fri, 1 Apr 2022 12:05:52 -0700 Subject: Core memory In-Reply-To: References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: On 4/1/2022 11:51 AM, Paul Koning via cctalk wrote: > >> On Apr 1, 2022, at 2:38 PM, Brent Hilpert via cctalk wrote: >> >> On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote: >> >>> When I looked at that ebay listing of "glass memory" it pointed me to another item, https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells. >> Well, it would still work for 1-bit-wide words, so to speak. One wonders what the application was. > I wonder if the sense wire was used as inhibit during write cycles -- that seems doable. It would make the core plane simpler at the expense of more complex electronics. With that approach, you have regular memory, not limited to 1 bit words. > >> There are a couple of Soviet core-rope memories up right now: >> https://www.ebay.com/itm/294558261336 >> https://www.ebay.com/itm/294851032351 > Neat looking stuff. It doesn't look like core rope memory in the sense of the AGC ROM, nor in the sense of the Electrologica X1. It looks more like the transformer memory used in Wang calculators that you documented in your core ROM paper. > > paul > > without the driver hardware there's no real way to determine for sure what the interface was.? It's clearly not structured as the Apollo or other roms were.? Not all of the core built that way for the Apollo systems were ROMs as well. Someone googled and found the descriptions of the Apollo use of core I suspect and has no clue.? No mention of documentation or provenance in the listing which would be absolutely required for this sort of artifact as it would be out of the normal for such use as the seller has. Sad about all the Soviet stuff, probably will be a long time before there is any more buying from there again. Thanks Jim From Rice43 at btinternet.com Fri Apr 1 14:38:39 2022 From: Rice43 at btinternet.com (Joshua Rice) Date: Fri, 1 Apr 2022 20:38:39 +0100 Subject: Core memory In-Reply-To: References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: > On Apr 1, 2022, at 7:51 PM, Paul Koning via cctalk wrote: > > Neat looking stuff. It doesn't look like core rope memory in the sense of the AGC ROM, nor in the sense of the Electrologica X1. It looks more like the transformer memory used in Wang calculators that you documented in your core ROM paper. > > paul > I second the Transformer ROM theory. I guess the transformers are the epoxied modules on the top half of the board, with some weird magnetic/inductance wizardry at the bottom doing the adressing. You may find it?s a hybrid of core rope and transformer ROM for super dense ROMs. I?m no expert at the nuances of this field though. Reminds me a bit of my Wagenr Computer transformer ROM: https://www.reddit.com/r/vintagecomputing/comments/m3pe29/a_very_photogenic_rom_board_from_an_early_70s/ Cheers, Josh Rice From paulkoning at comcast.net Fri Apr 1 14:54:16 2022 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 1 Apr 2022 15:54:16 -0400 Subject: Core memory In-Reply-To: References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: <64394C8A-9E95-4528-BD57-1CB334006094@comcast.net> > On Apr 1, 2022, at 3:38 PM, Joshua Rice wrote: > > > >> On Apr 1, 2022, at 7:51 PM, Paul Koning via cctalk wrote: >> >> Neat looking stuff. It doesn't look like core rope memory in the sense of the AGC ROM, nor in the sense of the Electrologica X1. It looks more like the transformer memory used in Wang calculators that you documented in your core ROM paper. >> >> paul >> > > I second the Transformer ROM theory. I guess the transformers are the epoxied modules on the top half of the board, with some weird magnetic/inductance wizardry at the bottom doing the adressing. You may find it?s a hybrid of core rope and transformer ROM for super dense ROMs. I?m no expert at the nuances of this field though. > > Reminds me a bit of my Wagenr Computer transformer ROM: https://www.reddit.com/r/vintagecomputing/comments/m3pe29/a_very_photogenic_rom_board_from_an_early_70s/ Nice. Is that actually a transformer ROM, or a square loop type core rope ROM? The physical appearance supports both conclusions. To be sure you'd have to analyze the driving circuitry, or check the properties of the cores used in it. paul From mhs.stein at gmail.com Fri Apr 1 15:17:46 2022 From: mhs.stein at gmail.com (Mike Stein) Date: Fri, 1 Apr 2022 16:17:46 -0400 Subject: Glass memory? In-Reply-To: References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> Message-ID: Hey, I've got one of those somewhere (the delay line, not the terminal ;-) )! I do still use the cabinet as a desk, as well as a few parts here and there; to think that today something like an Arduino nano can replace that desk-sized cabinet containing a substantial power supply and a card cage with at least a dozen cards IIRC... I'm still amazed by how far we've come in less than my lifetime... m On Fri, Apr 1, 2022 at 2:30 PM Chuck Guzis via cctalk wrote: > On 4/1/22 10:27, Paul Koning wrote: > > > > > >> On Apr 1, 2022, at 1:25 PM, Chuck Guzis via cctalk < > cctalk at classiccmp.org> wrote: > >> > >> Wasn't some of this glass delay line memory used in early raster-scanned > >> computer video displays? > > > > I don't know about that one, but a delay line is a key component of a > PAL (European) system color TV receiver. > > I know that the CRT display controller on the CDC 200 series terminal > (INTERCOM, Export/Import 200 software) used a 10 msec magnetostrictive > delay line.for image storage. Glass would seem to be a more > mechanically robust storage medium. > > See:page 1-5 > > http://bitsavers.org/pdf/cdc/terminal/82128000_200_User_Terminal_Hardware_Reference_Jul68.pdf > > Later raster terminals used MOS shift register memory. > > The STAR-100 stations used a track on the station microdrum for video > refresh. > > > --Chuck > > From bhilpert at shaw.ca Fri Apr 1 16:13:50 2022 From: bhilpert at shaw.ca (Brent Hilpert) Date: Fri, 1 Apr 2022 14:13:50 -0700 Subject: Core memory In-Reply-To: References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: On 2022-Apr-01, at 11:51 AM, Paul Koning wrote: >> On Apr 1, 2022, at 2:38 PM, Brent Hilpert via cctalk wrote: >> On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote: >> >>> When I looked at that ebay listing of "glass memory" it pointed me to another item,https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells. >> >> Well, it would still work for 1-bit-wide words, so to speak. One wonders what the application was. > > I wonder if the sense wire was used as inhibit during write cycles -- that seems doable. It would make the core plane simpler at the expense of more complex electronics. With that approach, you have regular memory, not limited to 1 bit words. Maybe I'm being overly cautious, but offhand I'm initially skeptical without doing the math or some good vector diagrams, or seeing an example. With the diagonal wire you're changing the current/magnetic sum vectors in direction and magnitude. The question is coming up with a current that reliably performs the cancellation function on the selected core of a bit-array while reliably *not* selecting another core, while accounting for all the variation tolerances in the array. While there's probably some value by which it would work in theory, I wonder whether the diagonal wire would narrow the operating margins. From some stuff I've seen, the hysteresis curves for cores weren't spectacularly square. With the usual 3D-3wire scheme of a close parallel inhibit wire you have 'cancellation by simplicity', you maximise the difference (cancellation) influence on one wire while minimising it's sum influence on the other. A related issue is the normal diagonal sense stringing (which this looks to have) has the wire entering the cores from both directions relative to the address wires, which is why sense amplifiers respond to pulses of both polarity. If this diagonal wire is put to use as an inhibit wire, some logic is needed to decide the direction of the inhibit current from the address, though that may not be very difficult. Some history of the 3-wire development might tell, whether inhibit was first applied to a diagonal sense stringing or whether sense was first applied to an adapted parallel-inhibit stringing. The real benefit of the 3-wire development was getting rid of the diagonal stringing for manufacturing ease. >> There are a couple of Soviet core-rope memories up right now: >> https://www.ebay.com/itm/294558261336 >> https://www.ebay.com/itm/294851032351 > > Neat looking stuff. It doesn't look like core rope memory in the sense of the AGC ROM, nor in the sense of the Electrologica X1. It looks more like the transformer memory used in Wang calculators that you documented in your core ROM paper. Yes, (I was, perhaps lazily, slipping into the habit of referring to both forms (of woven-wire ROM) as rope). From bill.gunshannon at hotmail.com Fri Apr 1 17:34:09 2022 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Fri, 1 Apr 2022 18:34:09 -0400 Subject: Glass memory? In-Reply-To: References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> Message-ID: On 4/1/22 16:17, Mike Stein via cctalk wrote: > Hey, I've got one of those somewhere (the delay line, not the terminal ;-) > )! > > I do still use the cabinet as a desk, as well as a few parts here and > there; to think that today something like an Arduino nano can replace that > desk-sized cabinet containing a substantial power supply and a card cage > with at least a dozen cards IIRC... I'm still amazed by how far we've come > in less than my lifetime... I was amazed 40 years ago. I was trained by the Army as a Systems Analyst/Programmer. At the time what was called "The Army Standard System" was an IBM 360/40. It came with 3 semi tractors to pull the two semi-trailers that held the computer and the third pulled the generator it tool to run them. I got my first unix system for my home in 1984. It was a pre-release of the Tandy Model 16. It fit on my desk. Had more memory than a 360/40. Had more storage than a 360/40 and handled more users than a 360/40. It cost less than 10% of a 360/40. I actually got mine for nothing but that's another story. :-) And, as you say, an Arduino or a Pi that fits in my pocket is orders of magnitude more powerful and costs pocket money. Of course, sometimes I still miss the old days and old ways. :-) But then, isn't that why we are all here? bill From paulkoning at comcast.net Fri Apr 1 19:32:24 2022 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 1 Apr 2022 20:32:24 -0400 Subject: Core memory In-Reply-To: References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: > On Apr 1, 2022, at 5:13 PM, Brent Hilpert via cctalk wrote: > > On 2022-Apr-01, at 11:51 AM, Paul Koning wrote: >>> On Apr 1, 2022, at 2:38 PM, Brent Hilpert via cctalk wrote: >>> On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote: >>> >>>> When I looked at that ebay listing of "glass memory" it pointed me to another item,https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells. >>> >>> Well, it would still work for 1-bit-wide words, so to speak. One wonders what the application was. >> >> I wonder if the sense wire was used as inhibit during write cycles -- that seems doable. It would make the core plane simpler at the expense of more complex electronics. With that approach, you have regular memory, not limited to 1 bit words. > > Maybe I'm being overly cautious, but offhand I'm initially skeptical without doing the math or some good vector diagrams, or seeing an example. With the diagonal wire you're changing the current/magnetic sum vectors in direction and magnitude. The question is coming up with a current that reliably performs the cancellation function on the selected core of a bit-array while reliably *not* selecting another core, while accounting for all the variation tolerances in the array. > > While there's probably some value by which it would work in theory, I wonder whether the diagonal wire would narrow the operating margins. From some stuff I've seen, the hysteresis curves for cores weren't spectacularly square. With the usual 3D-3wire scheme of a close parallel inhibit wire you have 'cancellation by simplicity', you maximise the difference (cancellation) influence on one wire while minimising it's sum influence on the other. > > A related issue is the normal diagonal sense stringing (which this looks to have) has the wire entering the cores from both directions relative to the address wires, which is why sense amplifiers respond to pulses of both polarity. If this diagonal wire is put to use as an inhibit wire, some logic is needed to decide the direction of the inhibit current from the address, though that may not be very difficult. You're right about the diagonal wiring, that suggests the idea isn't very practical. I suppose another possibility for a 3-wire core plane is that it's linear-select with inhibit (as, for example, in CDC 6000 series ECS, extended core storage). Speaking of CDC and inhibit, the CDC mainframe memories (12 bit by 4k modules) are peculiar in that they have inhibit wire pairs, one X and one Y, and four of them in each direction so a given inhibit acts on a 1/16th square of the full plane. The best reason I can figure for this is to have the number of cores traversed by the inhibit wires and by the address wires to be roughly the same, so the inductance is fairly consistent and a single design of ultra high speed current pulse drivers will work for all of them. The drivers used are current diversion drivers -- they don't switch on and off, instead they switch the current from an idling path to the core wire. It's pretty wild stuff, one of the 6600 training manuals describes it in a lot of detail. My assumption is that all this was done to achieve the unusually high speed: 1 microsecond full read/restore cycle in 1964. paul From lproven at gmail.com Sat Apr 2 05:27:19 2022 From: lproven at gmail.com (Liam Proven) Date: Sat, 2 Apr 2022 12:27:19 +0200 Subject: Glass memory? In-Reply-To: References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> Message-ID: On Sat, 2 Apr 2022 at 00:34, Bill Gunshannon via cctalk wrote: > > And, as you say, an Arduino or a Pi that fits in my pocket is orders > of magnitude more powerful and costs pocket money. The comparisons of size, power, storage, cost, power usage, heat output and so on are often made. What is less often observed are the facts that a machine that takes multiple trailers can be repaired with spare parts. Anything made from ICs basically can't, except by replacing the ICs. What if you can't make ICs any more? Or rather, what level of IC fabrication would it be possible to construct from scratch? And if the war were long (sticking to the military context) or the conditions extreme (say, radical rapid global warming and a retreat to polar regions) and so all the factories and infrastructure were lost or had to be abandoned... I'm thinking of the current global chip shortages, and the floods in Thailand that screwed up supplies of hard disks a decade ago. What could be constructed from scratch, given copious amounts of scrap and waste for source materials? And aside from the hardware: Yes, modern computers have vast amounts of storage and power, but we use them all on OSes and apps that need millions of lines of code in dozens of languages, and gigabytes of storage. As a result, although they are vastly quicker, latency is arguably _worse_ now: https://danluu.com/input-lag/ What if... we had to reconstruct entire OSes and software stacks from scratch? Maybe because the authors were dead. Maybe because the computers they needed didn't work any more and couldn't be repaired. Maybe because we had to make new computers and they were smaller and slower. How much could be rebuilt? What could be learned from the mistakes of old? I recently wrote these pieces, which were fun to research: https://www.theregister.com/2022/03/29/non_c_operating_systems/ https://www.theregister.com/2022/03/31/serenityos/ There are so many UNIX-like kernels in C on Github I couldn't count them all. In the many dozens, maybe hundreds. This is doable. But there are fewer in C++. Fewer still in Rust or Go. Very few in anything Wirthian or with garbage-collection. > Of course, sometimes I still miss the old days and old ways. :-) > But then, isn't that why we are all here? Well indeed! http://collapseos.org/ is relevant to this. But is an 8-bit the biggest we could realistically construct if all the IC fabs were destroyed? -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From jnc at mercury.lcs.mit.edu Sat Apr 2 05:49:16 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 2 Apr 2022 06:49:16 -0400 (EDT) Subject: PDP 11/24 - A Step Backwards Message-ID: <20220402104916.8475D18C08C@mercury.lcs.mit.edu> > does [disabling the MCLK counter via DCLO, asserted by the two > E126 monostable chain from ACLO] happen just on power-down, or on > power-up too? I'd need to understand how that two monostable chain > works in both cases, which I currently don't. (I only understand > monostables when pulses trigger them, not edges, which is a big part of > why I don't completely understand it.) So this was bugging me, so I hauled out my TI TTL databook and looked up the LS123. According to that, the 123 is triggered by the rising edge on the B (non-inverted) input, when the A (inverted) input is low (which it will be here; it's tied to ground). (Also by the falling edge on A when B is high, which we can ignore.) So I think that chain is probably triggered only on power-down, which will produce a rising edge on P FAIL. (Power-up will produce only a falling edge on P FAIL, once power is up and good.) (Note that the second monostable is triggered, also on B, by the -Q output of the first; i.e. by the 'falling' edge of the first's pulse. But see also at the bottom, below.) So that should happen (if I have correctly understood this, which is not certain, I'm just a software person :-) is that some time after P FAIL goes high - a delay set by the first 123 - the second 123 produces a pulse (of a width set by its RC pair) - which via E52 produces an assertion pulse on DCLO. WTF? (Not that we care in this machine's case, since i) it only happens on power-down, and ii) it's just a pulse, so it's affect on MCLK will be very transient; it can't cause it to stay off. My curiousity has been piqued, is all. :-) The TM does not, after a _thorough_ search (although there are a few mentions of power u/down, but not this), explin why, alas. (The TM for some _other_ -11 CPU, one which contains a similar circuit might, but I'm not _that_ curious! :-) My _guess_ is that the intent is to reset all devices to a good idle state, _before_ power actually goes out. (Don't ask me why it just doesn't use INIT, though!) The potential fly in the ointment of complete understanding is that a 123 can _also_ produce a pulse on a rising edge at the clear input - and there is some circuitry driving the clear input on the second 123. (The clear input on the _first_ 123 seems to be left hanging in space - odd!) It seems to be set off by the mysterious DGP03 signal, generated by the microcode - but the GP table on pg. 4-21 of the TM doesn't contain an entry for '3'? Unless it has a typo - there are two '5' entries. In which case it could be 'Toggle the HALT flip-flop (K6)' (which I don't see on K6, unless it's E78) but yah, pulsing DCLO will probably clear it, wherever it is! This machine is making my head hurt. Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. if not, then we'll have to work out why not. Noel From robert.jarratt at ntlworld.com Sat Apr 2 05:58:27 2022 From: robert.jarratt at ntlworld.com (Rob Jarratt) Date: Sat, 2 Apr 2022 11:58:27 +0100 Subject: PDP 11/24 - A Step Backwards In-Reply-To: <20220402104916.8475D18C08C@mercury.lcs.mit.edu> References: <20220402104916.8475D18C08C@mercury.lcs.mit.edu> Message-ID: <01f801d84680$9518fa70$bf4aef50$@ntlworld.com> > > Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. if > not, then we'll have to work out why not. This is my plan for later today. > > Noel From jnc at mercury.lcs.mit.edu Sat Apr 2 06:03:53 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 2 Apr 2022 07:03:53 -0400 (EDT) Subject: PDP 11/24 - A Step Backwards Message-ID: <20220402110353.B1B5118C08C@mercury.lcs.mit.edu> > and there is some circuitry driving the clear input on the second > 123. Never mind this section. I mis-read the print; the clear input is connected to an _input_ of the flop below (which is also tied high). Noel From robert.jarratt at ntlworld.com Sat Apr 2 09:12:06 2022 From: robert.jarratt at ntlworld.com (Rob Jarratt) Date: Sat, 2 Apr 2022 15:12:06 +0100 Subject: PDP 11/24 - A Step Backwards In-Reply-To: References: <20220331073642.64C9318C073@mercury.lcs.mit.edu> <478A63EB-0670-4344-AE19-5AFECD03FEF4@shaw.ca> <013d01d84544$5e9cd9e0$1bd68da0$@ntlworld.com> Message-ID: <022d01d8469b$a258e680$e70ab380$@ntlworld.com> > -----Original Message----- > From: Brent Hilpert > Sent: 31 March 2022 22:48 > To: rob at jarratt.me.uk; General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: PDP 11/24 - A Step Backwards > > On 2022-Mar-31, at 2:14 PM, Rob Jarratt wrote: > >> Those three comparators in the H777 are looking at a time-delay ramp > > > > Is that a typo? This is the H7140 not the H777. > > Groan. > > When this thread came up I went looking for the 11/24 schematic. I found > the document I linked earlier for the 11/24 and found 'the' +5 power supply. > So apparently I've been looking at the wrong +5V supply (H777) because the > rest of you are indeed looking at a different +5 supply (H7140), both of which > are in that same 11/24 pdf document. > > And indeed, the ACLO control is Q15 in the H7140. > > I really wish when people are asking for assistance or talking about a > schematic or circuit they would include a link/reference to exactly what they > are looking at (a) so the reader doesn't have to go scratching around to find it > and (b) to avoid effort-wasting screw-ups like this. Sorry about the wasted time. I think I did say at one point that it was the H7140, but that will be way down the thread somewhere. I will use PDF page numbers in future. > > So yes, you can ignore a lot of the details I described, though some of the > principals I mentioned are still valid. From cube1 at charter.net Sat Apr 2 10:11:05 2022 From: cube1 at charter.net (Jay Jaeger) Date: Sat, 2 Apr 2022 10:11:05 -0500 Subject: PDP 11/24 - A Step Backwards In-Reply-To: <20220402104916.8475D18C08C@mercury.lcs.mit.edu> References: <20220402104916.8475D18C08C@mercury.lcs.mit.edu> Message-ID: On 4/2/2022 5:49 AM, Noel Chiappa via cctalk wrote: > > does [disabling the MCLK counter via DCLO, asserted by the two > > E126 monostable chain from ACLO] happen just on power-down, or on > > power-up too? I'd need to understand how that two monostable chain > > works in both cases, which I currently don't. (I only understand > > monostables when pulses trigger them, not edges, which is a big part of > > why I don't completely understand it.) > > So this was bugging me, so I hauled out my TI TTL databook and looked up the > LS123. > And, if that 'LS123 wasn't made by TI, it could be considered suspect until it has been checked out with a 'scope. I remember, from somewhere back in the day, that not all '123s were created equal, and that TI's were demonstrably better than the others in terms of stability and trustworthiness. I also recall *vaguely* one experience where replacing a '123 made by someone else with a TI one fixed the issue. JRJ From jnc at mercury.lcs.mit.edu Sat Apr 2 10:14:20 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 2 Apr 2022 11:14:20 -0400 (EDT) Subject: PDP 11/24 - A Step Backwards Message-ID: <20220402151420.D4B6718C08C@mercury.lcs.mit.edu> Finally found time to get to this one... > From: Rob Jarratt > However, there is a puzzle. On the CPU I found that the track from the > pull up resistor to E70 has been cut. I don't know about the "pull up resistor" part, but I have several KDF11-U's, and _all_ of them have the trace on the bottom of the card connected to pin 1 of E70 cut, in the exact same place (about 1/8" from the pin). This suggests that it's not a local mod (as you suggest below), but an 'official' DEC ECO. > This would suggest that E70 pin 2 is floating, which I think means that > K2 BUF ACLO H is also floating The input (pin 1) will be floating, but not the output (pin 2); TTL doesn't work that way, I think. I may have this wrong, but I think open TTL inputs float high, so BUF ACLO should be low. I looked, and I don't see any other traces (e.g. on the top side) going to pin 1. So I'm a bit puzzled that DEC allowed that input to float, as open inputs can lead to erratic operaton; they're usually tied high, or to ground. > K2 BUS ACLO L however has been patched to E52 pin 4, which is the > output of a gate on sheet K6. Can't say I understand why. Me neither; that's an unused (on the prints) driver in the DS8641 (center bottom of the page) - although that gate seems to have been fully wired up (wires to pins 4, 5 and 6) as part of the ECO. There is an ECO list on pg. 167 of the -11/24 prints (2 pages after K14), but I don't see an E52 in it anywhere. The puzzle here, if E70p1 is cut, and the output is low, is why the CPU clock isn't running. The -15V on BUS ACLO shouldn't have taken out any other semiconductors; it's not attached to anything else. (It will have run C6, on the lower right of the card, the wrong way, but i) I think that's a non-polarized item - and 100V rated, per the prints, and ii) I don't think that goes anywhere else, even if it's not.) So what's stopping the clock from running, then? Noel From bfranchuk at jetnet.ab.ca Sat Apr 2 12:00:25 2022 From: bfranchuk at jetnet.ab.ca (ben) Date: Sat, 2 Apr 2022 11:00:25 -0600 Subject: Glass memory? In-Reply-To: References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> Message-ID: On 2022-04-02 4:27 a.m., Liam Proven via cctalk wrote: > On Sat, 2 Apr 2022 at 00:34, Bill Gunshannon via cctalk > wrote: >> >> And, as you say, an Arduino or a Pi that fits in my pocket is orders >> of magnitude more powerful and costs pocket money. > > The comparisons of size, power, storage, cost, power usage, heat > output and so on are often made. > > What is less often observed are the facts that a machine that takes > multiple trailers can be repaired with spare parts. Anything made from > ICs basically can't, except by replacing the ICs. > > What if you can't make ICs any more? Or rather, what level of IC > fabrication would it be possible to construct from scratch? > > And if the war were long (sticking to the military context) or the > conditions extreme (say, radical rapid global warming and a retreat to > polar regions) and so all the factories and infrastructure were lost > or had to be abandoned... > > I'm thinking of the current global chip shortages, and the floods in > Thailand that screwed up supplies of hard disks a decade ago. > > What could be constructed from scratch, given copious amounts of scrap > and waste for source materials? > > And aside from the hardware: > > Yes, modern computers have vast amounts of storage and power, but we > use them all on OSes and apps that need millions of lines of code in > dozens of languages, and gigabytes of storage. > > As a result, although they are vastly quicker, latency is arguably _worse_ now: > > https://danluu.com/input-lag/ > > What if... we had to reconstruct entire OSes and software stacks from > scratch? Maybe because the authors were dead. Maybe because the > computers they needed didn't work any more and couldn't be repaired. > Maybe because we had to make new computers and they were smaller and > slower. > > How much could be rebuilt? What could be learned from the mistakes of old? > > I recently wrote these pieces, which were fun to research: > > https://www.theregister.com/2022/03/29/non_c_operating_systems/ > > https://www.theregister.com/2022/03/31/serenityos/ > > There are so many UNIX-like kernels in C on Github I couldn't count > them all. In the many dozens, maybe hundreds. > > This is doable. But there are fewer in C++. Fewer still in Rust or Go. > Very few in anything Wirthian or with garbage-collection. > >> Of course, sometimes I still miss the old days and old ways. :-) >> But then, isn't that why we are all here? > > Well indeed! > > http://collapseos.org/ is relevant to this. > > But is an 8-bit the biggest we could realistically construct if all > the IC fabs were destroyed? > Computers need memory, not ALU's. 4K static and 16k dynamic were the last chips that seem to developed by hand. The late 1970's would be a realistic goal to rebuild a civilization to. Looking around even 1985 err 1955 is a good time frame if you want to include time travel,flying cars and hover-boards. :) Ben. PS: Hurry up and drop them nukes, get rid of the X86 forever. :) PPS: Did any computer implement multilevel/trinary bolean logic ( true false unknown ) From robert.jarratt at ntlworld.com Sat Apr 2 17:12:54 2022 From: robert.jarratt at ntlworld.com (Rob Jarratt) Date: Sat, 2 Apr 2022 23:12:54 +0100 Subject: PDP 11/24 - A Step Backwards In-Reply-To: <01f801d84680$9518fa70$bf4aef50$@ntlworld.com> References: <20220402104916.8475D18C08C@mercury.lcs.mit.edu> <01f801d84680$9518fa70$bf4aef50$@ntlworld.com> Message-ID: <000001d846de$cd8996e0$689cc4a0$@ntlworld.com> > -----Original Message----- > From: cctalk On Behalf Of Rob Jarratt via > cctalk > Sent: 02 April 2022 11:58 > To: 'Noel Chiappa' ; 'General Discussion: On-Topic > and Off-Topic Posts' > Subject: RE: PDP 11/24 - A Step Backwards > > > > > Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. > > if not, then we'll have to work out why not. > > This is my plan for later today. OK, so I disconnected ACLO only. It was quite a struggle to separate those nylon connectors, is there a trick to it? In doing so I spotted two backplane wire wrap pins touching and a couple of others that were quite close too, so I separated them and inspected all the backplane pins. I didn't see any other ones touching. When I powered on, the CPU LEDs did not light up. Some random characters appeared on the console, but probably just a bit of noise maybe? However, I did notice that the CLK LED flickered on briefly when I powered it off. I put a scope probe on TP1 (p152 of the PDF), there was no activity, the pin remained high. The problem now is that I expect I will need to probe various pins to find out what is going on. But I don't have a Unibus extender and I am reluctant to remove the backplane. From what I can tell in the Technical Manual you can't install the CPU in other slots to make room for attaching probes either. I am forced to tack solder probe wires to the chips, which works but is time consuming. Any other ways? Using tack soldered wires, I have traced back and I *think* I have found something. There could be a fault in E52 (sheet K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6 BUF DCLO H at an average 1.64V with 50us spikes at 2.08V. According to a NatSemi datasheet for the DS8641 (http://pdf.datasheetcatalog.com/datasheet/nationalsemiconductor/DS005806.PD F) the logical 0 output should be 0.4V max and the logical 1 output should be 2.4V min. I also measured K6 BUF DCLO L to be always low, suggesting it thinks the K6 BUF DCLO H is a logical 1. This seems to suggest that E52 may be faulty. Trace here: https://rjarratt.files.wordpress.com/2022/04/e52-dclo-signal.jpg. Regards Rob > > > > > Noel From curiousmarc3 at gmail.com Sat Apr 2 18:03:56 2022 From: curiousmarc3 at gmail.com (Curious Marc) Date: Sat, 2 Apr 2022 16:03:56 -0700 Subject: Core memory In-Reply-To: References: Message-ID: <65E1C6ED-517A-47AD-B3A8-5D2F478E3E17@gmail.com> You don?t strictly need an inhibit wire to write cores. You can write the core with just the addressing lines. The inhibit wire is just there to simplify the addressing electronics logic in early core memory, so you don?t need to have per core control of the current in the address lines when writing. You just do it wholesale: scan all address lines with current in one direction during reads, scan once again with current in the other direction during writes, with inhibit when needed. You could certainly use the sense wire as an inhibit. But that gets impractical with a diagonal weave, because you?d have to know in which direction the inhibit works and reverse the inhibit current accordingly. And it?s different for each core depending on the direction the sense wire crosses the core. So it defeats the purpose of simplifying the control logic with an inhibit wire. Therefore I don?t think that scheme is used. In practice, 3 wire systems that use the same wire for inhibit and sense (like some IBM core planes) have the sense go along the address lines, and use a half plane column shift to provide cancellation of the unwanted signal induced from the address line it is running along. We demonstrate such a 3 wire plane here: https://youtu.be/AwsInQLmjXc . So in your plane, the sense wire is likely just used for reads, and the writes are done uniquely with the address wires, like I demonstrate here: https://youtu.be/7ozNMgx7WtQ Marc > On Apr 1, 2022, at 2:14 PM, Brent Hilpert via cctalk wrote: > > ?On 2022-Apr-01, at 11:51 AM, Paul Koning wrote: >>>> On Apr 1, 2022, at 2:38 PM, Brent Hilpert via cctalk wrote: >>>> On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote: >>> >>>> When I looked at that ebay listing of "glass memory" it pointed me to another item,https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells. >>> >>> Well, it would still work for 1-bit-wide words, so to speak. One wonders what the application was. >> >> I wonder if the sense wire was used as inhibit during write cycles -- that seems doable. It would make the core plane simpler at the expense of more complex electronics. With that approach, you have regular memory, not limited to 1 bit words. > > Maybe I'm being overly cautious, but offhand I'm initially skeptical without doing the math or some good vector diagrams, or seeing an example. With the diagonal wire you're changing the current/magnetic sum vectors in direction and magnitude. The question is coming up with a current that reliably performs the cancellation function on the selected core of a bit-array while reliably *not* selecting another core, while accounting for all the variation tolerances in the array. > > While there's probably some value by which it would work in theory, I wonder whether the diagonal wire would narrow the operating margins. From some stuff I've seen, the hysteresis curves for cores weren't spectacularly square. With the usual 3D-3wire scheme of a close parallel inhibit wire you have 'cancellation by simplicity', you maximise the difference (cancellation) influence on one wire while minimising it's sum influence on the other. > > A related issue is the normal diagonal sense stringing (which this looks to have) has the wire entering the cores from both directions relative to the address wires, which is why sense amplifiers respond to pulses of both polarity. If this diagonal wire is put to use as an inhibit wire, some logic is needed to decide the direction of the inhibit current from the address, though that may not be very difficult. > > Some history of the 3-wire development might tell, whether inhibit was first applied to a diagonal sense stringing or whether sense was first applied to an adapted parallel-inhibit stringing. The real benefit of the 3-wire development was getting rid of the diagonal stringing for manufacturing ease. > > >>> There are a couple of Soviet core-rope memories up right now: >>> https://www.ebay.com/itm/294558261336 >>> https://www.ebay.com/itm/294851032351 >> >> Neat looking stuff. It doesn't look like core rope memory in the sense of the AGC ROM, nor in the sense of the Electrologica X1. It looks more like the transformer memory used in Wang calculators that you documented in your core ROM paper. > > Yes, (I was, perhaps lazily, slipping into the habit of referring to both forms (of woven-wire ROM) as rope). From jnc at mercury.lcs.mit.edu Sat Apr 2 21:41:15 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 2 Apr 2022 22:41:15 -0400 (EDT) Subject: PDP 11/24 - A Step Backwards Message-ID: <20220403024115.9EA2018C08C@mercury.lcs.mit.edu> > It was quite a struggle to separate those nylon connectors, is there a > trick to it? You mean the Mate-n-lok's? Not really; just make sure the catch is released. What did you do about DCLO? (Oh, I think I see the answer, below.... looks like you're relying on the pullup on K3...) > When I powered on, the CPU LEDs did not light up. Two of them ('0' and '1') are just bits in a special register, and thus only do anything when the bootstrap code fondles them. When you get ODT running, you can amuse yourself turning them off and on manually! :-) > I did notice that the CLK LED flickered on briefly when I powered it > off. Interesting. Not sure exactly what we can deduce from that; but interesting. > I put a scope probe on TP1 (p152 of the PDF), there was no activity, > the pin remained high. Yes; the signal there (MCLK H) is more or less the same one that drives the 'CLK' LED (MCLK L); so no big surprise there. Still, that reduces the problem space to a small part of K1. > The problem now is that I expect I will need to probe various pins to > find out what is going on. But I don't have a Unibus extender and I am > reluctant to remove the backplane. From what I can tell in the > Technical Manual you can't install the CPU in other slots Basically right; the backplane and CPU are designed to have it go in slot 1. It _might_ work in other MUD slots, with some loss of functionality (e.g. slot 2 doesn't have grant lines; MUD slots won't have the 'UNIBUS Map board pesent' line - pin FE1, on K11, UB TO MA VIA UBMAP) but I wouldn't want to chance it, there might be a clash. > I am forced to tack solder probe wires to the chips, which works but is > time consuming. Any other ways? Sorry, I don't have any experience to suggest any; too well supplied with extender cards, so I've never had to resort to alternatives! > I *think* I have found something. There could be a fault in E52 (sheet > K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6 BUF > DCLO H at an average 1.64V Yeah, that's wrong. E52 is bad, and will have to be replaced. (From the +5V on BUS DCLO, I guess you're relying on the pullup? DCLO on the UNIBUS, with the resistor network on the M9302, should be about 3.5V - but now I'm confused, even with the P/S connector unplugged, it should still be 3.5V or so. Oh well, it's late, the brain is powering down... :-) The 'unused' gate in E52 is the one that the added wires from the ACLO ECO went to; I wonder if it was damaged by the -15V, somehow? > logical 0 output should be 0.4V max Which is what you should be seeing. > I also measured K6 BUF DCLO L to be always low, suggesting it thinks > the K6 BUF DCLO H is a logical 1. Yup; and that definitely explains why the clock isn't running - BUF DCLO L is clearing E41 on K1. Anyway, you'll have to replace E52 (which will be a bit of a pain, with the 3 ECO eires tacked to it). The DS8641 is an old chip, no longer in production, so the usual suppliers may not have it, but there are some on eBait. Noel From robert.jarratt at ntlworld.com Sun Apr 3 01:43:14 2022 From: robert.jarratt at ntlworld.com (Rob Jarratt) Date: Sun, 3 Apr 2022 07:43:14 +0100 Subject: PDP 11/24 - A Step Backwards In-Reply-To: <20220403024115.9EA2018C08C@mercury.lcs.mit.edu> References: <20220403024115.9EA2018C08C@mercury.lcs.mit.edu> Message-ID: <000101d84726$186b1570$49414050$@ntlworld.com> > -----Original Message----- > From: cctalk On Behalf Of Noel Chiappa via > cctalk > Sent: 03 April 2022 03:41 > To: cctalk at classiccmp.org > Cc: jncx at mercury.lcs.mit.edu > Subject: RE: PDP 11/24 - A Step Backwards > > > It was quite a struggle to separate those nylon connectors, is there a > > trick to it? > > You mean the Mate-n-lok's? Not really; just make sure the catch is released. > > What did you do about DCLO? (Oh, I think I see the answer, below.... looks > like you're relying on the pullup on K3...) > > > When I powered on, the CPU LEDs did not light up. > > Two of them ('0' and '1') are just bits in a special register, and thus only do > anything when the bootstrap code fondles them. When you get ODT > running, you can amuse yourself turning them off and on manually! :-) > > > I did notice that the CLK LED flickered on briefly when I powered it > > off. > > Interesting. Not sure exactly what we can deduce from that; but interesting. > > > I put a scope probe on TP1 (p152 of the PDF), there was no activity, > > the pin remained high. > > Yes; the signal there (MCLK H) is more or less the same one that drives the > 'CLK' LED (MCLK L); so no big surprise there. Still, that reduces the problem > space to a small part of K1. > > > The problem now is that I expect I will need to probe various pins to > > find out what is going on. But I don't have a Unibus extender and I am > > reluctant to remove the backplane. From what I can tell in the > > Technical Manual you can't install the CPU in other slots > > Basically right; the backplane and CPU are designed to have it go in slot 1. > It _might_ work in other MUD slots, with some loss of functionality (e.g. > slot 2 doesn't have grant lines; MUD slots won't have the 'UNIBUS Map board > pesent' line - pin FE1, on K11, UB TO MA VIA UBMAP) but I wouldn't want to > chance it, there might be a clash. > > > I am forced to tack solder probe wires to the chips, which works but is > > time consuming. Any other ways? > > Sorry, I don't have any experience to suggest any; too well supplied with > extender cards, so I've never had to resort to alternatives! > > > > I *think* I have found something. There could be a fault in E52 (sheet > > K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6 BUF > > DCLO H at an average 1.64V > > Yeah, that's wrong. E52 is bad, and will have to be replaced. > > (From the +5V on BUS DCLO, I guess you're relying on the pullup? DCLO on > the UNIBUS, with the resistor network on the M9302, should be about 3.5V - > but now I'm confused, even with the P/S connector unplugged, it should still > be 3.5V or so. Oh well, it's late, the brain is powering down... :-) Sorry if I wasn't clear, I did plug the connector back in, so that DCLO and LTC are connected, I just removed the ACLO pin. > > The 'unused' gate in E52 is the one that the added wires from the ACLO ECO > went to; I wonder if it was damaged by the -15V, somehow? Oh, I forgot about that! That would seem highly likely. > > > logical 0 output should be 0.4V max > > Which is what you should be seeing. > > > I also measured K6 BUF DCLO L to be always low, suggesting it thinks > > the K6 BUF DCLO H is a logical 1. > > Yup; and that definitely explains why the clock isn't running - BUF DCLO L is > clearing E41 on K1. > > Anyway, you'll have to replace E52 (which will be a bit of a pain, with the 3 > ECO eires tacked to it). The DS8641 is an old chip, no longer in production, so > the usual suppliers may not have it, but there are some on eBait. I didn't look for replacements last night. Is there a modern equivalent? My initial searches show there isn't but I may have found a source of NOS. Worried about replacing it with the ECO wires as you say, I always marvel at how neatly those wires are done, I wish I knew how to do such a neat job. Thanks Rob > > Noel From ccth6600 at gmail.com Sun Apr 3 02:13:37 2022 From: ccth6600 at gmail.com (Tom Hunter) Date: Sun, 3 Apr 2022 15:13:37 +0800 Subject: Core memory In-Reply-To: <65E1C6ED-517A-47AD-B3A8-5D2F478E3E17@gmail.com> References: <65E1C6ED-517A-47AD-B3A8-5D2F478E3E17@gmail.com> Message-ID: DEC PDP-8/e core memories have a combined Sense/Inhibit line. There are only 3 wires through each core donut: X, Y, Sense/Inhibit. The PDP-8/e core memory is very well described starting at page 3-60 of the Maintenance Manual Volume 1: http://www.bitsavers.org/pdf/dec/pdp8/pdp8e/DEC-8E-HMM1A-D-D_PDP-8e_Maintenance_Manual_Volume_1_Processor_Sep73.pdf Tom Hunter On Sun, Apr 3, 2022 at 7:04 AM Curious Marc via cctalk < cctalk at classiccmp.org> wrote: > You don?t strictly need an inhibit wire to write cores. You can write the > core with just the addressing lines. The inhibit wire is just there to > simplify the addressing electronics logic in early core memory, so you > don?t need to have per core control of the current in the address lines > when writing. You just do it wholesale: scan all address lines with current > in one direction during reads, scan once again with current in the other > direction during writes, with inhibit when needed. > > You could certainly use the sense wire as an inhibit. But that gets > impractical with a diagonal weave, because you?d have to know in which > direction the inhibit works and reverse the inhibit current accordingly. > And it?s different for each core depending on the direction the sense wire > crosses the core. So it defeats the purpose of simplifying the control > logic with an inhibit wire. Therefore I don?t think that scheme is used. > > In practice, 3 wire systems that use the same wire for inhibit and sense > (like some IBM core planes) have the sense go along the address lines, and > use a half plane column shift to provide cancellation of the unwanted > signal induced from the address line it is running along. We demonstrate > such a 3 wire plane here: https://youtu.be/AwsInQLmjXc . > > So in your plane, the sense wire is likely just used for reads, and the > writes are done uniquely with the address wires, like I demonstrate here: > https://youtu.be/7ozNMgx7WtQ > > Marc > > > On Apr 1, 2022, at 2:14 PM, Brent Hilpert via cctalk < > cctalk at classiccmp.org> wrote: > > > > ?On 2022-Apr-01, at 11:51 AM, Paul Koning wrote: > >>>> On Apr 1, 2022, at 2:38 PM, Brent Hilpert via cctalk < > cctalk at classiccmp.org> wrote: > >>>> On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote: > >>> > >>>> When I looked at that ebay listing of "glass memory" it pointed me to > another item,https://www.ebay.com/itm/265623663142 -- described as "core > rope memory". Obviously it isn't -- it's conventional core RAM. > Interestingly enough, it seems to be three-wire memory (no inhibit line > that I can see). It looks to be in decent shape. No manufacturer marks, > and "GC-6" doesn't ring any bells. > >>> > >>> Well, it would still work for 1-bit-wide words, so to speak. One > wonders what the application was. > >> > >> I wonder if the sense wire was used as inhibit during write cycles -- > that seems doable. It would make the core plane simpler at the expense of > more complex electronics. With that approach, you have regular memory, not > limited to 1 bit words. > > > > Maybe I'm being overly cautious, but offhand I'm initially skeptical > without doing the math or some good vector diagrams, or seeing an example. > With the diagonal wire you're changing the current/magnetic sum vectors in > direction and magnitude. The question is coming up with a current that > reliably performs the cancellation function on the selected core of a > bit-array while reliably *not* selecting another core, while accounting for > all the variation tolerances in the array. > > > > While there's probably some value by which it would work in theory, I > wonder whether the diagonal wire would narrow the operating margins. From > some stuff I've seen, the hysteresis curves for cores weren't spectacularly > square. With the usual 3D-3wire scheme of a close parallel inhibit wire you > have 'cancellation by simplicity', you maximise the difference > (cancellation) influence on one wire while minimising it's sum influence on > the other. > > > > A related issue is the normal diagonal sense stringing (which this looks > to have) has the wire entering the cores from both directions relative to > the address wires, which is why sense amplifiers respond to pulses of both > polarity. If this diagonal wire is put to use as an inhibit wire, some > logic is needed to decide the direction of the inhibit current from the > address, though that may not be very difficult. > > > > Some history of the 3-wire development might tell, whether inhibit was > first applied to a diagonal sense stringing or whether sense was first > applied to an adapted parallel-inhibit stringing. The real benefit of the > 3-wire development was getting rid of the diagonal stringing for > manufacturing ease. > > > > > >>> There are a couple of Soviet core-rope memories up right now: > >>> https://www.ebay.com/itm/294558261336 > >>> https://www.ebay.com/itm/294851032351 > >> > >> Neat looking stuff. It doesn't look like core rope memory in the sense > of the AGC ROM, nor in the sense of the Electrologica X1. It looks more > like the transformer memory used in Wang calculators that you documented in > your core ROM paper. > > > > Yes, (I was, perhaps lazily, slipping into the habit of referring to > both forms (of woven-wire ROM) as rope). > From cc at informatik.uni-stuttgart.de Sun Apr 3 03:26:21 2022 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Sun, 3 Apr 2022 10:26:21 +0200 (CEST) Subject: Core memory In-Reply-To: References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: <60cd4dce-3e62-97cf-dce0-5bbe55ac9f0@informatik.uni-stuttgart.de> On Fri, 1 Apr 2022, Paul Koning wrote: >> On Apr 1, 2022, at 2:38 PM, Brent Hilpert via cctalk wrote: >> >> Well, it would still work for 1-bit-wide words, so to speak. One >> wonders what the application was. > I wonder if the sense wire was used as inhibit during write cycles -- > that seems doable. It would make the core plane simpler at the expense Wasn't that common in newer core memory days? I mean, there's nothing special about three-wire core memory with common sense/inhibit lines. Christian From cube1 at charter.net Sun Apr 3 07:41:22 2022 From: cube1 at charter.net (Jay Jaeger) Date: Sun, 3 Apr 2022 07:41:22 -0500 Subject: PDP 11/24 - A Step Backwards In-Reply-To: <000001d846de$cd8996e0$689cc4a0$@ntlworld.com> References: <20220402104916.8475D18C08C@mercury.lcs.mit.edu> <01f801d84680$9518fa70$bf4aef50$@ntlworld.com> <000001d846de$cd8996e0$689cc4a0$@ntlworld.com> Message-ID: <6b7f2334-2644-29f3-aa62-cc8cf9c1cf90@charter.net> On 4/2/2022 5:12 PM, Rob Jarratt via cctalk wrote: > > Using tack soldered wires, I have traced back and I *think* I have found > something. There could be a fault in E52 (sheet K6, p157 of the PDF). While > K6 BUS DCLO L is +5V, I am measuring K6 BUF DCLO H at an average 1.64V with > 50us spikes at 2.08V. According to a NatSemi datasheet for the DS8641 > (http://pdf.datasheetcatalog.com/datasheet/nationalsemiconductor/DS005806.PD > F) the logical 0 output should be 0.4V max and the logical 1 output should > be 2.4V min. I also measured K6 BUF DCLO L to be always low, suggesting it > thinks the K6 BUF DCLO H is a logical 1. This seems to suggest that E52 may > be faulty. Trace here: > https://rjarratt.files.wordpress.com/2022/04/e52-dclo-signal.jpg. > > Regards > > Rob > Also, consider having a look at whatever E52 is driving - something may be pulling at it's output - a bad chip, a short somewhere in what it drives, etc. That looks to be E53 pin 13, and wherever else that signal might go. And also look at K5 BUS DCLO L, pin 15 of E52, just in case. JRJ From bmr at ringman.ch Sun Apr 3 08:34:17 2022 From: bmr at ringman.ch (Magnus Ringman) Date: Sun, 3 Apr 2022 15:34:17 +0200 Subject: Core memory In-Reply-To: References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: On Fri, Apr 1, 2022 at 10:26 PM Marc Howard via cctech < cctech at classiccmp.org> wrote: > We need to onshore Nixie production now! ;-) > Gentle plug for https://www.daliborfarny.com/. From wrcooke at wrcooke.net Sun Apr 3 09:01:25 2022 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Sun, 3 Apr 2022 09:01:25 -0500 (CDT) Subject: Core memory In-Reply-To: References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> Message-ID: <823131440.1324227.1648994485331@email.ionos.com> > On 04/03/2022 8:34 AM Magnus Ringman via cctech wrote: > > > On Fri, Apr 1, 2022 at 10:26 PM Marc Howard via cctech < > cctech at classiccmp.org> wrote: > > > We need to onshore Nixie production now! ;-) > > Gentle plug for https://www.daliborfarny.com/. I got excited by that until I saw there was no pricing and no availability. :-( Will From jnc at mercury.lcs.mit.edu Sun Apr 3 10:28:56 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 3 Apr 2022 11:28:56 -0400 (EDT) Subject: PDP 11/24 - A Step Backwards Message-ID: <20220403152856.1E83918C08C@mercury.lcs.mit.edu> > The 'unused' gate in E52 is the one that the added wires from the ACLO > ECO went to; I wonder if it was damaged by the -15V, somehow? So, I checked, and the wire that goes from the plated-through hole next to the etch cut on E70p1 winds up at E52p4 (the bus line on that transceiver), thereby connecting the latter directly to UNIBUS ACLO (on pin BF1). So that's almost certainly what caused other gate(s) in E52 to fail. I think I have managed to trace where all the other two wires to that 'new' gate in E52 went to/from, to see exactly what the ECO is. Given that E52 is a transceiver, it was likely substituted for E70 so that the KDF11-U could also _drive_ BUS ACLO. I discovered that E52p5 (the new transceiver's input) is connected to E73p13 (an DS8640 quad NOR used as a bus reciver); that's in the upper left corner of K2. It's BUS PB L NOR BUS PA H - i.e. a parity error has been detected in memory - so it apparently then power-fails the system! The incoming BUF ACLO (E52p6) goes to a PTH next to E70p8. On the bottom, there's a trace from that PTH that goes to E66p13 - which is the inverter shown on K2 which converts BUF ACLO H to POWER OK H. So that probably the answer to my plaint about E70p1 being left floating: perhaps theres an etch cut somewhere that disconnected E66p13 from E70p2, so the former can now be driven by E52p6. I can't see one, but there's a trace from that latter PTH that dives under E70, and I can't see it well, but it looks like it goes to E70p2. It would be interesting to know what they did about the E70p2 -> E66p13 connection. Noel From jnc at mercury.lcs.mit.edu Sun Apr 3 10:55:57 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 3 Apr 2022 11:55:57 -0400 (EDT) Subject: PDP 11/24 - A Step Backwards Message-ID: <20220403155557.EA32B18C08C@mercury.lcs.mit.edu> > From: "Rob Jarratt" > I did plug the connector back in, so that DCLO and > LTC are connected, I just removed the ACLO pin. Ah, OK, good. Pulling the pins from those Mate-n-Loc shells without the right tool is tricky; glad you did it, because as Brent Hilpert pointed out, having a working DCLO is important, to reset everything to a known state on power-on. > I didn't look for replacements last night. Is there a modern > equivalent? Not that I know of. Even if you found something with the same pin-out, supposedly DEC selected ones that were 'good enough'. I've never had an issue with NOS ones that I bought from vendors, though. > I may have found a source of NOS. Great; get several, they're a useful chip to have around; the QBUS uses them, as well as the UNIBUS. If the same place has DS8640's (the receiver), save on shipping (and ordering delays) and get a couple of those too. I say that because depending on what else you had plugged into the UNIBUS post ACLO failure, the -15V may have damaged them too. The M9312 (not sure if you had one of those, but the -11/24 manual says it's common in them) uses ACLO (via a DS8640). The KY24 seems not to (as far as I can tell from a quick look - negative results from a quick print scan aren't 100.00% reliable, whereas positive ones are), oddly enough. In EUB memory (not sure which you have), the MS11-L and MS11M MS11-P don't seem to, whereas the MS11-P _drives_ ACLO (through an 8881) - probably to prevent CPU startup until the ECC is cleared). Etc, etc. > I always marvel at how neatly those wires are done, I wish I knew how > to do such a neat job. The same way the old joke says one gets to Carnegie Hall, I expect! :-) (I wonder what the UK equivalent of the Carnegie is - the Royal Albert, probably?) Noel From korpela at berkeley.edu Sun Apr 3 10:51:05 2022 From: korpela at berkeley.edu (Eric J. Korpela) Date: Sun, 3 Apr 2022 08:51:05 -0700 Subject: SETI@home (ca. 2000) servers heading to salvage. Message-ID: >From here: https://setiathome.berkeley.edu/forum_thread.php?id=85870&postid=2096776#2096776 They are bog standard Sun Enterprise systems, drive removed and destroyed for privacy reason. They are only interesting for what they've done. By university rules, our group can essentially "permanent loan" them to a non-profit, but any sale or transfer of ownership is up to University Excess and Salvage. A bit of history disappearing, which is nothing new in this group. From emu at e-bbes.com Sun Apr 3 15:16:41 2022 From: emu at e-bbes.com (emanuel stiebler) Date: Sun, 3 Apr 2022 16:16:41 -0400 Subject: SETI@home (ca. 2000) servers heading to salvage. In-Reply-To: References: Message-ID: <048d1b94-49d9-360e-8812-e4814a944378@e-bbes.com> On 2022-04-03 11:51, Eric J. Korpela via cctalk wrote: >>From here: > https://setiathome.berkeley.edu/forum_thread.php?id=85870&postid=2096776#2096776 > > They are bog standard Sun Enterprise systems, drive removed and destroyed > for privacy reason. They are only interesting for what they've done. By > university rules, our group can essentially "permanent loan" them to a > non-profit, but any sale or transfer of ownership is up to > University Excess and Salvage. > > A bit of history disappearing, which is nothing new in this group. I think in this group, we have plenty of DLT IV tape drives? How many tapes are we talking? From linimon at lonesome.com Sun Apr 3 16:36:52 2022 From: linimon at lonesome.com (Mark Linimon) Date: Sun, 3 Apr 2022 21:36:52 +0000 Subject: SETI@home (ca. 2000) servers heading to salvage. In-Reply-To: References: Message-ID: <20220403213652.GA22674@lonesome.com> How fortunate that I'm halfway across the continent :-) mcl From cclist at sytse.net Sun Apr 3 17:09:25 2022 From: cclist at sytse.net (Sytse van Slooten) Date: Mon, 4 Apr 2022 00:09:25 +0200 Subject: SETI@home (ca. 2000) servers heading to salvage. In-Reply-To: References: Message-ID: <213BF9DC-F87A-4563-82B4-B90F09CCA8CB@sytse.net> Ah setiathome. Those systems in the photo will have handled a lot of my personal data - well, compared to random other earthlings. I don't really have fond memories of that series of Sun Enterprise though - what are they, 3000 or 3500? Many a times that I stubbed my toes on that v-shaped thing protruding off the back side. Those systems only made sense for a cluster because they lacked internal reliability and power supply reduncancy - but cluster software back then didn't work too well, and I'm not sure anyone actually used that series as it was intended from the design - always as a cluster. Anyway, lots of very heavy metal frames, good enough to stub your toes on for sure - what I've come to call 'a stable platform' ie something you can put your weight on without worrying. Main issue for the 3000/3500 series were the power supplies as I recall, if you didn't get lucky, a 3500 would be a lot less reliable than a 250 - that didn't have all of the extra whoohow, but would work fine even after unbelievable abuse. Anyway, I still have some of the heatsinks that dropped off the several 3500 I had the privilege of knowing - one of them is now glued to the cpu of my spare server board. > On 3 Apr 2022, at 17:51, Eric J. Korpela via cctalk wrote: > > From here: > https://setiathome.berkeley.edu/forum_thread.php?id=85870&postid=2096776#2096776 > > They are bog standard Sun Enterprise systems, drive removed and destroyed > for privacy reason. They are only interesting for what they've done. By > university rules, our group can essentially "permanent loan" them to a > non-profit, but any sale or transfer of ownership is up to > University Excess and Salvage. > > A bit of history disappearing, which is nothing new in this group. From tangentdelta at protonmail.com Sun Apr 3 18:29:40 2022 From: tangentdelta at protonmail.com (TangentDelta) Date: Sun, 03 Apr 2022 23:29:40 +0000 Subject: Looking For HP-UX 5.1 9000/200 Series Kernel Disk Message-ID: Hello. I have an HP 9000/217 (9817) machine that I'd like to install HP-UX 5.1 onto. In order to do this, I need to find the boot disk containing the correct kernel, which has the part number "A98680B", and is described as "Multi-user kernel for S200". Alternatively, I could run just the single-user version of HP-UX 5.1, which has the part number of "A98670B". The disk images for HP-UX 5.1 on bitsavers.org and hpmuseum.net do not have this disk. I found these numbers in the HP-UX administrator manual. Page 370 lists the kernel disks and their contents. http://bitsavers.org/pdf/hp/9000_hpux/1985/97033-90049_HP-UX_System_Administrator_Manual_for_HP_9000_200_300_Computers_Dec1985.pdf If anyone can point me in the right direction, it'd be greatly appreciated! Thanks. From trash80 at internode.on.net Sun Apr 3 19:08:40 2022 From: trash80 at internode.on.net (Kevin Parker) Date: Mon, 4 Apr 2022 10:08:40 +1000 Subject: The Vertical Plane Message-ID: <05f501d847b8$26550410$72ff0c30$@internode.on.net> This may be of interest to some list members, particularly those who have an interest in the BBC computer or just like Twilight Zone type stories. Apart from being extremely interested in classic computers I also like the old stories that surround these old machines. A while ago I stumbled across a story about a BBC computer (this is the short version) that had been lent out from a school l think (as they did in those days due to the cost of machines back then) and this BBC, despite apparently not being connected to anything, started displaying messages from the past (a previous land owner) and someone in the future. As I said this is the short version of the story - it's also referred to as the Dodleston Messages or even the Dodleston Files if anyone wants to Google it. One of the claims was that this BBC proved the existence of time travel - WOW, a big claim. So the story eventually found its way into a book, The Vertical Plane by Ken Webster (1989). I believe the book gets its title from the way scientists describe time. So being interested in the stories I started my world-wide hunt for a copy. That was tough. A new copy unobtainable, an electronic copy not to my liking - I like the real thing, used copies were monumentally expensive (apparently the first edition was highly collectable). So I resigned myself to maybe one day I would stumble across a copy in a used book shop or an Op Shop (aka Thrift Shop) or a second hand shop. I visit these regularly because its amazing what pops up in them. Much to my surprise in February this year a Second Edition of The Vertical Plane was published and of course obtained for me by my local bookshop. My take - a good yarn - yes, do I believe the story - no. Please note, I have no connection with the editor or the publisher. Kevin Parker From rick at rickmurphy.net Sun Apr 3 20:24:12 2022 From: rick at rickmurphy.net (Rick Murphy) Date: Sun, 3 Apr 2022 21:24:12 -0400 Subject: Core memory In-Reply-To: <823131440.1324227.1648994485331@email.ionos.com> References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> <823131440.1324227.1648994485331@email.ionos.com> Message-ID: <2936bf0b-308e-c9fc-b3a5-5a3a1bd56a0c@rickmurphy.net> On 4/3/2022 10:01 AM, Will Cooke via cctech wrote: > >> On 04/03/2022 8:34 AM Magnus Ringman via cctech wrote: >> >> >> On Fri, Apr 1, 2022 at 10:26 PM Marc Howard via cctech < >> cctech at classiccmp.org> wrote: >> >>> We need to onshore Nixie production now! ;-) >> Gentle plug forhttps://www.daliborfarny.com/. > I got excited by that until I saw there was no pricing and no availability. :-( > > Will There's pricing. Prepare yourself. A four-digit Nixie clock is about $1900. No, I didn't move the decimal point to the wrong place. *https://www.daliborfarny.com/product/puri-nixie-clock/* ??? -Rick* * From korpela at berkeley.edu Sun Apr 3 20:30:17 2022 From: korpela at berkeley.edu (Eric J. Korpela) Date: Sun, 3 Apr 2022 18:30:17 -0700 Subject: SETI@home (ca. 2000) servers heading to salvage. In-Reply-To: <048d1b94-49d9-360e-8812-e4814a944378@e-bbes.com> References: <048d1b94-49d9-360e-8812-e4814a944378@e-bbes.com> Message-ID: > > > > > I think in this group, we have plenty of DLT IV tape drives? > How many tapes are we talking? > About 2000. Commercial archiving services seem out of reach price wise. From dave.g4ugm at gmail.com Mon Apr 4 06:28:35 2022 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Mon, 4 Apr 2022 12:28:35 +0100 Subject: AlphaServer 2100s available In-Reply-To: References: Message-ID: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> Folks, I got one of these from Antonio. It has 4 x CPU boards in plus a few disk drives, but it does not want to power up. It did spin the fans up then shut down. . I now have a lot of other projects on the go, so if anyone would like it please let me know. Its in Manchester, England. Replies off-list please. Dave > -----Original Message----- > From: cctalk On Behalf Of Antonio Carlini > via cctalk > Sent: 21 July 2020 20:58 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: AlphaServer 2100s available > > I have three AlphaServer 2100 systems in storage in the UK (Oxfordshire). > The storage, however, is due to be demolished (soon, but no fixed date). > > > I won't have room to store these three systems, so if anyone would be > interested in offering them a home, then please get in touch! > > > I can probably get some pictures in the next day or two. > > > These systems were SMP Alphas and could sport as many as 4 CPUs. I'm not > sure of the configuration of these systems but I can probably find that > out soon. > > They have not been run since ~2003 so they may be in need of some TLC. > OTOH they are not rusted to death so you have a chance of getting them > back to life. > > > Just so you know what you might be dealing with these systems are about: > 700mm H x 430mm W x 810mm L. > > > I can't find the weight in any of my references right now but they are > very heavy. Three people can move them up a slight slope with some > effort but you would not successfully lift it into a car (assuming that > it would fit). I'm planning to dismantle them to move them (i.e. remove > PSU/PSUs etc. until they are light enough to move). A tail-lift would > probably be the sane way to go (and is, indeed, how they got to their > current location. > > > I'm hoping that someone can step forward and offer one or more of these > machines a new home. Please contact me off-list (once you're sure you > understand what you are getting into :-)). > > > Antonio > > > -- > Antonio Carlini > antonio at acarlini.com From bmr at ringman.ch Mon Apr 4 08:48:25 2022 From: bmr at ringman.ch (Magnus Ringman) Date: Mon, 4 Apr 2022 15:48:25 +0200 Subject: Core memory In-Reply-To: <823131440.1324227.1648994485331@email.ionos.com> References: <0EBC0AEE-1FEA-4103-986C-56EFAFAC0538@comcast.net> <823131440.1324227.1648994485331@email.ionos.com> Message-ID: On Sun, Apr 3, 2022 at 4:01 PM Will Cooke via cctech wrote: > > Gentle plug for https://www.daliborfarny.com/. > > I got excited by that until I saw there was no pricing and no > availability. :-( > I know :-P I binge-watched their youtube channel (here ) last summer, and came to understand that they've moved offices and are building a better workshop (or factory.) Guess we'll see. Magnus From jules.richardson99 at gmail.com Mon Apr 4 09:20:58 2022 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 4 Apr 2022 09:20:58 -0500 Subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage) In-Reply-To: References: Message-ID: On 4/3/22 10:51, Eric J. Korpela via cctalk wrote: > drive removed and destroyed for privacy reason. For those in the know, how much success - assuming a "money is no object" approach - do data recovery companies have in retrieving data from drives that have a) been overwritten with zeros using dd or similar, and b) been overwritten with random data via a more comprehensive tool? cheers, Jules From paulkoning at comcast.net Mon Apr 4 09:28:47 2022 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 4 Apr 2022 10:28:47 -0400 Subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage) In-Reply-To: References: Message-ID: > On Apr 4, 2022, at 10:20 AM, Jules Richardson via cctalk wrote: > > On 4/3/22 10:51, Eric J. Korpela via cctalk wrote: >> drive removed and destroyed for privacy reason. > > For those in the know, how much success - assuming a "money is no object" approach - do data recovery companies have in retrieving data from drives that have a) been overwritten with zeros using dd or similar, and b) been overwritten with random data via a more comprehensive tool? There's a research group in, I think, UCSD which studies that question. From what I recall, in modern hard disk drives with microscopic tracks and not a whole lot of margin anywhere, one overwrite is plenty good. The legendary multiple erase schemes are mostly rumors -- I looked long and hard for the supposed government standards that specify these and found they don't seem to exist -- and no longer useful. SSDs are a different story entirely because there you don't write over the actual data; instead a write updates internal metadata saying where the most recent version of block number xyz lives. So, given that you tend to have a fair amount (10 or 20 percent if not more) of "spare space" in the SSD, previous data are likely to be hanging around. I suspect if you write long enough you could traverse all that, but how to do that depends on the internals of the firmware. That's likely to be confidential and may not even be reliably known. There are SSD SEDs. If designed correctly those would give you cryptographically strong security and "instant erase". Not all disk designers know how to do these designs correctly. If I needed an SED (of any kind) I'd insist on a detailed disclosure of its keying and key management. Prying that out of manyfacturers is hard. I've done it, but it may be that my employer's name and unit volume was a factor. paul From cz at alembic.crystel.com Mon Apr 4 09:34:31 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Mon, 4 Apr 2022 08:34:31 -0600 Subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage) In-Reply-To: References: Message-ID: Good data Paul! SSD's are a different beast, if you're going to put data on them that you do not want recovered I would recommend encrypting the drive before using it, then when done delete/destroy the key. That should turn your drive into a useless (but format-able) chunk of silicon. C On 4/4/2022 8:28 AM, Paul Koning via cctalk wrote: > SSDs are a different story entirely because there you don't write over the actual data; instead a write updates internal metadata saying where the most recent version of block number xyz lives. So, given that you tend to have a fair amount (10 or 20 percent if not more) of "spare space" in the SSD, previous data are likely to be hanging around. I suspect if you write long enough you could traverse all that, but how to do that depends on the internals of the firmware. That's likely to be confidential and may not even be reliably known. > > There are SSD SEDs. If designed correctly those would give you cryptographically strong security and "instant erase". Not all disk designers know how to do these designs correctly. If I needed an SED (of any kind) I'd insist on a detailed disclosure of its keying and key management. Prying that out of manyfacturers is hard. I've done it, but it may be that my employer's name and unit volume was a factor. From lists at glitchwrks.com Mon Apr 4 09:43:07 2022 From: lists at glitchwrks.com (Jonathan Chapman) Date: Mon, 04 Apr 2022 14:43:07 +0000 Subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage) In-Reply-To: References: Message-ID: > SSD's are a different beast, if you're going to put data > on them that you do not want recovered I would recommend encrypting the > drive before using it, then when done delete/destroy the key. That > should turn your drive into a useless (but format-able) chunk of silicon. That's our take on it. SSDs get FDE or they don't leave. Secure Erase is nice for blowing away old formatting/partitioning, but we're not trusting it on sensitive customer data. Thanks, Jonathan From imp at bsdimp.com Mon Apr 4 09:55:16 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 4 Apr 2022 08:55:16 -0600 Subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage) In-Reply-To: References: Message-ID: That's what a sanitize operation does. It forgets the key and reformats the metadata with a new key. Also, with SSDs, any erase block that's erased is going to not have any data that's recoverable. First, the erase voltage is huge, moving the cell to a negative voltage (the only abode that's negative is all 1's). Next, the microprocessor in the NAND dies are going to 'pre-program' the abodes to a uniform negative voltage that's easier to program when you start putting data on the ages. Finally, most (nearly all) NAND dies have randomization circuitry that randomizes the data after you send it to the drive (or whitens it) that you'll need the psuedorandom seed to read it back coherently. The problem, though, comes with erase blocks that have broken and no longer erase. These retired blocks can contain data still, but given the randomization/whitening and/or some global encryption key, the data can be difficult or impossible to meaningfully recover, even when other pathologies don't degrade the block more (not least is aging: if the block was retired a long time ago, the NAND cells, being tiny capacitors, will bleed the charge off to the erased state +/-). As with most forms of data destruction, putting a metal spike through the NAND dies themselves would likely suffice :) But it is a tad destructive.... Warner On Mon, Apr 4, 2022 at 8:34 AM Chris Zach via cctalk wrote: > Good data Paul! SSD's are a different beast, if you're going to put data > on them that you do not want recovered I would recommend encrypting the > drive before using it, then when done delete/destroy the key. That > should turn your drive into a useless (but format-able) chunk of silicon. > > C > > On 4/4/2022 8:28 AM, Paul Koning via cctalk wrote: > > SSDs are a different story entirely because there you don't write over > the actual data; instead a write updates internal metadata saying where the > most recent version of block number xyz lives. So, given that you tend to > have a fair amount (10 or 20 percent if not more) of "spare space" in the > SSD, previous data are likely to be hanging around. I suspect if you write > long enough you could traverse all that, but how to do that depends on the > internals of the firmware. That's likely to be confidential and may not > even be reliably known. > > > > There are SSD SEDs. If designed correctly those would give you > cryptographically strong security and "instant erase". Not all disk > designers know how to do these designs correctly. If I needed an SED (of > any kind) I'd insist on a detailed disclosure of its keying and key > management. Prying that out of manyfacturers is hard. I've done it, but > it may be that my employer's name and unit volume was a factor. > From paulkoning at comcast.net Mon Apr 4 10:37:24 2022 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 4 Apr 2022 11:37:24 -0400 Subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage) In-Reply-To: References: Message-ID: <2C6C1C2F-9C51-439E-8FED-91F17A9B264A@comcast.net> > On Apr 4, 2022, at 10:55 AM, Warner Losh via cctalk wrote: > > That's what a sanitize operation does. It forgets the key and reformats the > metadata with a new key. Yes, but the devil is in the details. For example, for the SSD case, it is necessary verify that the flash block that previously held the key information has been explicitly erased (successfully) and not merely put on the free list. That's a detail I once pried out of a manufacturer, insisting they were required to answer in order to get the business. paul From ethan at 757.org Mon Apr 4 11:06:36 2022 From: ethan at 757.org (Ethan O'Toole) Date: Mon, 4 Apr 2022 12:06:36 -0400 (EDT) Subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage) In-Reply-To: References: Message-ID: > For those in the know, how much success - assuming a "money is no object" > approach - do data recovery companies have in retrieving data from drives > that have a) been overwritten with zeros using dd or similar, and b) been > overwritten with random data via a more comprehensive tool? > cheers, > Jules I am pretty sure someone had a bounty out there, they give you a hard drive that had a phase on it that is stored linear on the platter. They write over it once with zeros. If you can recover the phrase then you win the bounty. It's unclaimed. Everyone talks about some theoretical ideas but no proof of it being done. My understanding is once you erase the data it's difficult to tell the difference between something recently erased and the noise floor. This was last time I looked into this which was a while ago. Maybe nation state has some ability but you or your customers data isn't worth the hassle. Prior employer would just have hundreds/thousands of pounds of hard drives ground up though. To eliminate any risk of data leakage. I am sure the same is done with SSDs by other companies and the US Government. Probably grinding up $9000 8TB SSDs all day. -- : Ethan O'Toole From jnc at mercury.lcs.mit.edu Tue Apr 5 07:07:51 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 5 Apr 2022 08:07:51 -0400 (EDT) Subject: UNIBUS powoer on/off spec Message-ID: <20220405120751.44FDF18C093@mercury.lcs.mit.edu> So, I looked at the early editions of the "pdp11 peripherals hanbook", which have good, detailed discussions of UNIBUS operations (at the back; chapter 5, "UNIBUS Theory and Operation", in the 1976 edition), but in contrast to the level of detail given for master/slave operations, and bus requests and interrupts, the level of detail on power up/down is very low, especially compared to that in the later "pdp11 bus hanbook" (which, as mentioned, does not seem to be online yet, alas). So, I have transcribed that section, and posted it: https://gunkies.org/wiki/UNIBUS_Initialization I have yet to scan and post the associated timing diagrams (which are useful, but not critical); the desktop that runs my scanner is down at the moment, alas. (If anyone who has a copy would like to volunteer to scan them, that would be great.) Noel From paulkoning at comcast.net Tue Apr 5 08:20:56 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 5 Apr 2022 09:20:56 -0400 Subject: UNIBUS powoer on/off spec In-Reply-To: <20220405120751.44FDF18C093@mercury.lcs.mit.edu> References: <20220405120751.44FDF18C093@mercury.lcs.mit.edu> Message-ID: Very impressive detail. You might give a precise source citation on that page. paul > On Apr 5, 2022, at 8:07 AM, Noel Chiappa via cctalk wrote: > > So, I looked at the early editions of the "pdp11 peripherals hanbook", which > have good, detailed discussions of UNIBUS operations (at the back; chapter 5, > "UNIBUS Theory and Operation", in the 1976 edition), but in contrast to the > level of detail given for master/slave operations, and bus requests and > interrupts, the level of detail on power up/down is very low, especially > compared to that in the later "pdp11 bus hanbook" (which, as mentioned, does > not seem to be online yet, alas). So, I have transcribed that section, and > posted it: > > https://gunkies.org/wiki/UNIBUS_Initialization > > I have yet to scan and post the associated timing diagrams (which are useful, > but not critical); the desktop that runs my scanner is down at the moment, > alas. (If anyone who has a copy would like to volunteer to scan them, that > would be great.) > > Noel From kevin.bowling at kev009.com Tue Apr 5 14:07:58 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 5 Apr 2022 12:07:58 -0700 Subject: Digital Control Applications with the TMS320 Family Message-ID: Does anyone have a hardcopy of this book they'd be willing to part with? http://www.bitsavers.org/components/ti/TMS320xx/1991_TI_Digital_Control_Applications_with_the_TMS320_Family.pdf USPS managed to lose the one I ordered but delivered me the damaged packaging with tire marks on it :( Regards, Kevin From ullbeking at andrewnesbit.org Tue Apr 5 16:14:52 2022 From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit) Date: Tue, 05 Apr 2022 22:14:52 +0100 Subject: Digital Control Applications with the TMS320 Family In-Reply-To: References: Message-ID: I cannot wait to read this!! Hardcopy or electronic copy, I don't mind. (Although if someone has a hardcopy selling for a not-insane price, please let me know :-) On Tue, 5 Apr 2022, at 20:07, Kevin Bowling via cctalk wrote: > Does anyone have a hardcopy of this book they'd be willing to part > with? > http://www.bitsavers.org/components/ti/TMS320xx/1991_TI_Digital_Control_Applications_with_the_TMS320_Family.pdf > > USPS managed to lose the one I ordered but delivered me the damaged > packaging with tire marks on it :( > > Regards, > Kevin From jnc at mercury.lcs.mit.edu Tue Apr 5 16:49:01 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 5 Apr 2022 17:49:01 -0400 (EDT) Subject: UNIBUS powoer on/off spec Message-ID: <20220405214901.9D90A18C083@mercury.lcs.mit.edu> > From: Paul Koning > You might give a precise source citation on that page. Done: https://gunkies.org/w/index.php?title=UNIBUS_Initialization&curid=6842&diff=25463&oldid=25451 Don't complain to me if the publication data is skimpy; that's all that's in it! (I mean, we all know that DEC is in Maynard, but the book doesn't say it...) Noel From dnm at pobox.com Tue Apr 5 19:52:25 2022 From: dnm at pobox.com (Daniel Moniz) Date: Tue, 05 Apr 2022 17:52:25 -0700 Subject: Any CodeWright users: still have patch installers? Message-ID: This is a long shot, but on the off chance anyone else on the list shares some of my particular weirdnesses, anyone got a line on the *patches* for Embarcadero (nee Borland (nee Starbase (nee Premia) CodeWright? I have the latest version Embarcadero sold (and maybe still sells?) as of not all that long ago -- 7.5 -- but it's basically patch level 3 (e.g., 7.5.3) instead of patch level 5 (e.g., 7.5.5). I'm hoping someone has the patch installers squirreled away somewhere, and that I can find that person. At least for Windows, patch installers were typically named something like "xcw753_4.exe", which would update an existing version 7.5.3 to version 7.5.4. Likewise xcw754_5.exe would update 7.5.4 to 7.5.5. Every now and again, I go looking for archives in The Wayback Machine, etc. or stashed away versions of the patch installers, but no dice so far. I've even attempted emailing folks who posted 10+ years ago or more on various fora about the patches/about CodeWright, but nothing has yet worked out there either. -- Daniel Moniz [http://pobox.com/~dnm/] From jnc at mercury.lcs.mit.edu Wed Apr 6 08:20:39 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Apr 2022 09:20:39 -0400 (EDT) Subject: UNIBUS powoer on/off spec Message-ID: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> > the later "pdp11 bus hanbook" (which, as mentioned, does not seem to be > online yet, alas) Arck, I'm a moron; Paul has pointed out to me that this is, in fact, online at Bitsavers: http://www.bitsavers.org/pdf/dec/pdp11/handbooks/PDP11_BusHandbook1979.pdf It didn't show up in a couple of pages of results in a Web search for it, though. I have noticed that things on Bitsavers often don't show up high up in Web search results, unless you add 'bitsavers' to the search term. I have been told that at one point Google was 'downgrading' results that used plain HTTP, instead of HTTPS, because they were trying to push people to switch to HTTPS (this was when everyone was hyperventilating over the Snowden revelations). Given the near-ubiquitous use of HTTPS these days, I'd have thought that piece of 'information credit engineering' by our tech overlords was past its 'sell by' date, and now serves primarily to block people from finding the material they are looking for (as here). Noel From pbirkel at gmail.com Wed Apr 6 08:27:11 2022 From: pbirkel at gmail.com (pbirkel at gmail.com) Date: Wed, 6 Apr 2022 09:27:11 -0400 Subject: UNIBUS powoer on/off spec In-Reply-To: <20220405214901.9D90A18C083@mercury.lcs.mit.edu> References: <20220405214901.9D90A18C083@mercury.lcs.mit.edu> Message-ID: <03a001d849ba$05e7c650$11b752f0$@gmail.com> I like the fact that https://williambader.com/museum/vax/pdphistory.html shows a cover image plus identifies the marking on the back cover ("EB-17525-20/79 070-14-55"). https://authors.library.caltech.edu/5363/1/MARprocieee06.pdf cites it in the same manner. Apparently the editors at Proc IEEE thought that was appropriate :->. -----Original Message----- From: cctalk On Behalf Of Noel Chiappa via cctalk Sent: Tuesday, April 5, 2022 5:49 PM To: cctalk at classiccmp.org Cc: jnc at mercury.lcs.mit.edu Subject: Re: UNIBUS powoer on/off spec > From: Paul Koning > You might give a precise source citation on that page. Done: https://gunkies.org/w/index.php?title=UNIBUS_Initialization&curid=6842&diff= 25463&oldid=25451 Don't complain to me if the publication data is skimpy; that's all that's in it! (I mean, we all know that DEC is in Maynard, but the book doesn't say it...) Noel From paulkoning at comcast.net Wed Apr 6 08:27:53 2022 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 6 Apr 2022 09:27:53 -0400 Subject: UNIBUS powoer on/off spec In-Reply-To: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> References: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> Message-ID: <6A8395D0-9CAB-4F55-A2BC-0A79E1550E28@comcast.net> > On Apr 6, 2022, at 9:20 AM, Noel Chiappa via cctalk wrote: > > ... > I have been told that at one point Google was 'downgrading' results that used > plain HTTP, instead of HTTPS, because they were trying to push people to > switch to HTTPS (this was when everyone was hyperventilating over the Snowden > revelations). Given the near-ubiquitous use of HTTPS these days, I'd have > thought that piece of 'information credit engineering' by our tech overlords > was past its 'sell by' date, and now serves primarily to block people from > finding the material they are looking for (as here). That's a classic example of a rule invented by people who can't think. In fact, HTTP is perfectly fine for sites that arenot conducting web-based business activity. Blogs are a good example, and I know at least one that runs HTTP for the simple reason that nothing else is needed. Bitsavers is another example; nothing would be gained by adding all the overhead inflicted by HTTPS. paul From toby at telegraphics.com.au Wed Apr 6 09:20:05 2022 From: toby at telegraphics.com.au (Toby Thain) Date: Wed, 6 Apr 2022 10:20:05 -0400 Subject: UNIBUS powoer on/off spec In-Reply-To: <6A8395D0-9CAB-4F55-A2BC-0A79E1550E28@comcast.net> References: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> <6A8395D0-9CAB-4F55-A2BC-0A79E1550E28@comcast.net> Message-ID: On 2022-04-06 9:27 a.m., Paul Koning via cctalk wrote: > > >> On Apr 6, 2022, at 9:20 AM, Noel Chiappa via cctalk wrote: >> >> ... >> I have been told that at one point Google was 'downgrading' results that used >> plain HTTP, instead of HTTPS, because they were trying to push people to >> switch to HTTPS (this was when everyone was hyperventilating over the Snowden >> revelations). Given the near-ubiquitous use of HTTPS these days, I'd have >> thought that piece of 'information credit engineering' by our tech overlords >> was past its 'sell by' date, and now serves primarily to block people from >> finding the material they are looking for (as here). > > That's a classic example of a rule invented by people who can't think. In fact, HTTP is perfectly fine for sites that arenot conducting web-based business activity. Blogs are a good example, and I know at least one that runs HTTP for the simple reason that nothing else is needed. Bitsavers is another example; nothing would be gained by adding all the overhead inflicted by HTTPS. That's true IF you don't care about malicious content being injected into the material you're loading over http. "Protecting credit card numbers" is not the only thing encryption is good for. Whoooosh and now watch this become the first 400 post off topic thread of 2022... > > paul > > From lars at nocrew.org Wed Apr 6 10:24:02 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 06 Apr 2022 15:24:02 +0000 Subject: UNIBUS powoer on/off spec In-Reply-To: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> (Noel Chiappa via cctalk's message of "Wed, 6 Apr 2022 09:20:39 -0400 (EDT)") References: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> Message-ID: <7wee2afd65.fsf@junk.nocrew.org> Noel Chiappa wrote: > I have been told that at one point Google was 'downgrading' results > that used plain HTTP, instead of HTTPS, because they were trying to > push people to switch to HTTPS (this was when everyone was > hyperventilating over the Snowden revelations). Given the > near-ubiquitous use of HTTPS these days, I'd have thought that piece > of 'information credit engineering' by our tech overlords was past its > 'sell by' date, and now serves primarily to block people from finding > the material they are looking for (as here). I often include the search term "site:bitsavers.org". From elson at pico-systems.com Wed Apr 6 11:40:22 2022 From: elson at pico-systems.com (Jon Elson) Date: Wed, 6 Apr 2022 11:40:22 -0500 Subject: UNIBUS powoer on/off spec In-Reply-To: <6A8395D0-9CAB-4F55-A2BC-0A79E1550E28@comcast.net> References: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> <6A8395D0-9CAB-4F55-A2BC-0A79E1550E28@comcast.net> Message-ID: On 4/6/22 08:27, Paul Koning via cctalk wrote: > > That's a classic example of a rule invented by people who can't think. In fact, HTTP is perfectly fine for sites that arenot conducting web-based business activity. Blogs are a good example, and I know at least one that runs HTTP for the simple reason that nothing else is needed. Bitsavers is another example; nothing would be gained by adding all the overhead inflicted by HTTPS. > > Yes, REALLY!? For anything that serves up static pages, there's no need for the security layer, unless the user is worried that somebody would snoop on the browsing history. Jon From lbickley at bickleywest.com Wed Apr 6 13:06:54 2022 From: lbickley at bickleywest.com (Lyle Bickley) Date: Wed, 6 Apr 2022 11:06:54 -0700 Subject: Short PDP-8 Memory Test... In-Reply-To: <7wee2afd65.fsf@junk.nocrew.org> References: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> <7wee2afd65.fsf@junk.nocrew.org> Message-ID: <20220406110654.4546eccc@asrock> I recently acquired another PDP-8/E and wanted to test basic CPU functions and memory before I added peripherals. There are some available short "memory tests" online, but most don't have have the flexibility to test multiple data patterns by design. The test below does a classic checkerboard type test - and permits easy modification of the data pattern used in testing. --- # Easy to enter, short memory test for PDP-8 systems # prior to adding peripheral equipment. # by Lyle Bickley # # Location 21 initially contains a zero. Therefore the # memory test is 0000 and 7777 in alternate locations. # Changing this location to 7070 will test 7070 and # 0707 in alternate locations. Changing it to 5252 will # test 5252 and 2525, etc. 0000 7300 CLA CLL 0001 1022 TAD 22 0002 3023 DCA 23 0003 7300 CLA CLL 0004 1021 TAD 21 0005 7040 CMA 0006 3021 DCA 21 0007 1021 TAD 21 0010 3423 DCA I 23 0011 1021 TAD 21 0012 7041 CMA IAC 0013 1423 TAD I 23 0014 7440 SZA 0015 7402 HLT (ERROR - AC SHOWS FAIL) 0016 2023 ISZ 23 0017 5003 JMP 3 (INC LOCATION AND LOOP) 0020 5000 JMP 0 (START OVER) 0021 0000 (0=ALT 7777 AND 0000) 0022 0025 (LOCATION TO START TEST - MAKE ODD) 0023 0000 (LOCATION BEING TESTED) --- Cheers, Lyle -- 73 NM6Y Bickley Consulting West https://bickleywest.com "Black holes are where God is dividing by zero" From lbickley at bickleywest.com Wed Apr 6 19:32:07 2022 From: lbickley at bickleywest.com (Lyle Bickley) Date: Wed, 6 Apr 2022 17:32:07 -0700 Subject: Short PDP-8 Memory Address Test.. Message-ID: <20220406173207.593ec700@asrock> Continuing the debugging of my recently acquired PDP-8/E, I wrote an address test that's easy to enter from the front panel: --- # PDP8 Quick Address Test # Pass 1: Loads locations 23-7777 with their own address. # Pass 2: Tests each location for the correct address. If # it fails (address does not equal it's own address) then # the diagnostic halts with the error location in 22. # The contents of that location displays the error. # By Lyle Bickley # 0000 7600 CLA 0001 1021 TAD 21 0002 3022 DCA 22 0003 1022 TAD 22 0004 3422 DCA I 22 0005 2022 ISZ 22 0006 5003 JMP 3 0007 1021 TAD 21 0010 3022 DCA 22 0011 1022 TAD 22 0012 7041 CMA IAC 0013 1422 TAD I 22 0014 7440 SZA 0015 7402 HLT (ERROR!) 0016 2022 ISZ 22 0017 5011 JMP 11 0020 5000 JMP 0 (START OVER) 0021 0023 0022 0000 --- Cheers, Lyle -- 73 NM6Y Bickley Consulting West https://bickleywest.com "Black holes are where God is dividing by zero" From paulkoning at comcast.net Wed Apr 6 20:22:30 2022 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 6 Apr 2022 21:22:30 -0400 Subject: Glass memory? In-Reply-To: References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> Message-ID: <0254FD63-0D38-4648-944C-736439000275@comcast.net> > On Apr 2, 2022, at 6:27 AM, Liam Proven via cctalk wrote: > > On Sat, 2 Apr 2022 at 00:34, Bill Gunshannon via cctalk > wrote: >> >> And, as you say, an Arduino or a Pi that fits in my pocket is orders >> of magnitude more powerful and costs pocket money. > > The comparisons of size, power, storage, cost, power usage, heat > output and so on are often made. > > What is less often observed are the facts that a machine that takes > multiple trailers can be repaired with spare parts. Anything made from > ICs basically can't, except by replacing the ICs. But that true for earlier machines, too. Replacing broken transistors requires having replacement transistors suitable for the circuit in question. For a 1960s era machine that may be quite hard; while transistors are easy to find, transistors with suitable characteristics might not be. And what are they? I'd love to know what the specs of the transistors in CDC's 6000 series "cordwood" modules are. Other than the stage delay (5 ns) I have no idea. > What if you can't make ICs any more? Or rather, what level of IC > fabrication would it be possible to construct from scratch? That's a fun question and a full answer would probably make a good book. For transistors the answer is only marginally simpler. For tubes, quite a lot simpler. (There's a nice Youtube video of someone making tubes, in his basement. You need glass blowing equipment, a spot welder, vacuum pumps, and an inductive heating system. That's about it for tools, as I recall. Materials: pyrex glass, kovar feed through wires, tungsten filaments, not sure what the electrodes are made of.) For semiconductors, you'd start with machinery to make ultra-pure materials (silicon, I'd assume). A Czochralski crystal growing machine to make the cylinders of pure mono-crystal silicon from which wafers are sliced. Polishing machinery. Wafer coating machines. Wafer steppers. Etching, metal coating, diffusion, etc......... most of which also require very pure and often exotic ingredients. (I remember being amazed to read that chlorine trifluoride is used as a cleaner in the semiconductor industry. Look up the properties of that compound, it will blow your mind.) Reading the specs of the latest generation wafer steppers from ASML (the only company in the world with the technology) boggles the mind, especially if you have some understanding of precision machinery design. And even earlier generation steppers are not easy devices to make. I'm not sure what's involved in doing one precise enough for, say, an 1980s era microprocessor. Or even an SN7400. Transistors are basically the same as small ICs, unless you go to really ancient types (point contact, mesa, alloy diffusion). If I had to build a simple computer starting from a pile of rubble I'd seriously consider building it from tubes. paul From bitwiz at 12bitsbest.com Wed Apr 6 20:31:41 2022 From: bitwiz at 12bitsbest.com (Mike Katz) Date: Wed, 6 Apr 2022 20:31:41 -0500 Subject: Short PDP-8 Memory Test... In-Reply-To: <20220406110654.4546eccc@asrock> References: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> <7wee2afd65.fsf@junk.nocrew.org> <20220406110654.4546eccc@asrock> Message-ID: Another PDP-8E?????? You are very lucky :) On 4/6/2022 1:06 PM, Lyle Bickley via cctalk wrote: > I recently acquired another PDP-8/E and wanted to test basic CPU functions and > memory before I added peripherals. There are some available short "memory > tests" online, but most don't have have the flexibility to test multiple data > patterns by design. > > The test below does a classic checkerboard type test - and permits easy > modification of the data pattern used in testing. > --- > # Easy to enter, short memory test for PDP-8 systems > # prior to adding peripheral equipment. > # by Lyle Bickley > # > # Location 21 initially contains a zero. Therefore the > # memory test is 0000 and 7777 in alternate locations. > # Changing this location to 7070 will test 7070 and > # 0707 in alternate locations. Changing it to 5252 will > # test 5252 and 2525, etc. > > 0000 7300 CLA CLL > 0001 1022 TAD 22 > 0002 3023 DCA 23 > 0003 7300 CLA CLL > 0004 1021 TAD 21 > 0005 7040 CMA > 0006 3021 DCA 21 > 0007 1021 TAD 21 > 0010 3423 DCA I 23 > 0011 1021 TAD 21 > 0012 7041 CMA IAC > 0013 1423 TAD I 23 > 0014 7440 SZA > 0015 7402 HLT (ERROR - AC SHOWS FAIL) > 0016 2023 ISZ 23 > 0017 5003 JMP 3 (INC LOCATION AND LOOP) > 0020 5000 JMP 0 (START OVER) > 0021 0000 (0=ALT 7777 AND 0000) > 0022 0025 (LOCATION TO START TEST - MAKE ODD) > 0023 0000 (LOCATION BEING TESTED) > --- > > Cheers, > Lyle From steven at malikoff.com Wed Apr 6 22:26:33 2022 From: steven at malikoff.com (steven at malikoff.com) Date: Thu, 7 Apr 2022 13:26:33 +1000 Subject: Glass memory? In-Reply-To: <0254FD63-0D38-4648-944C-736439000275@comcast.net> References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> <0254FD63-0D38-4648-944C-736439000275@comcast.net> Message-ID: Paul and others said >> What if you can't make ICs any more? Or rather, what level of IC >> fabrication would it be possible to construct from scratch? > For semiconductors, you'd start with machinery to make ultra-pure materials (silicon, I'd assume). A Czochralski crystal growing machine to make > the cylinders of pure mono-crystal silicon from which wafers are sliced. Polishing machinery. Wafer coating machines. Wafer steppers. Etching, > metal coating, diffusion, etc......... most of which also require very pure and often exotic ingredients. (I remember being amazed to read that > chlorine trifluoride is used as a cleaner in the semiconductor industry. Look up the properties of that compound, it will blow your mind.) Which brings to mind the amazing work of Sam Zeloof: https://www.youtube.com/results?search_query=zeloof+z1+chip From rice43 at btinternet.com Thu Apr 7 03:25:23 2022 From: rice43 at btinternet.com (Joshua Rice) Date: Thu, 7 Apr 2022 09:25:23 +0100 (BST) Subject: Glass memory? In-Reply-To: References: <31FEFA64-430C-4A42-87DB-508C38E4E7C0@comcast.net> <7dacc970-07fa-bf8a-53b6-bcbed748fb6e@sydex.com> <0254FD63-0D38-4648-944C-736439000275@comcast.net> Message-ID: <5b34cab2.263e9.1800320cf25.Webtop.118@btinternet.com> From: "steven--- via cctech" Paul and others said What if you can't make ICs any more? Or rather, what level of IC fabrication would it be possible to construct from scratch? For semiconductors, you'd start with machinery to make ultra-pure materials (silicon, I'd assume). A Czochralski crystal growing machine to make the cylinders of pure mono-crystal silicon from which wafers are sliced. Polishing machinery. Wafer coating machines. Wafer steppers. Etching, metal coating, diffusion, etc......... most of which also require very pure and often exotic ingredients. (I remember being amazed to read that chlorine trifluoride is used as a cleaner in the semiconductor industry. Look up the properties of that compound, it will blow your mind.) Which brings to mind the amazing work of Sam Zeloof: https://www.youtube.com/results?search_query=zeloof+z1+chip It really depends on how "from scratch" we have to go. In a more real world scenario where the ability to make large, low density MSI chips in the micrometer scale is somehow lost through scrapping and ignorance, recreating the machines required to make them on an industrial scale shouldn't cost a huge amount. It's proof, that if someone can make these chips in his garage on a shoestring budget, a few hundred grand should be able to recreate the technology in order to reproduce them industrially. Obviously there'd be an iterative process, much like happened in history, to shrink the die process if you were indeed trying to get smaller. However, if we had some sort of massive scale Carrington event (or larger) that fried every IC ever made, things would definitely take a step back. I imagine that the large crystal-growing tanks themselves would be fine, but the control gear etc would be truly sent back to the dark ages. It might take 5 years or more to re-engineer all the control gear to work in an electricity-free (or at least IC free) world, with many other things like food, water and fuel supplies taking precedence. Then there's the task of re-engineering the IC production from paper copies of research papers and documentation (no internet, remember), which could prove rather difficult to duplicate and distribute without photocopiers. We'd essentially be taken back to the early 60's when it came to IC production, having to re-engineer everything from scratch. Much of the non-electronic machinery and R&D would still be available, so i imagine getting back to where we are now would only take 20 or 30 years, instead of 60, but it would still be a long and iterative process which would be likely hampered by the whole "end-of-the-world Armageddon" thing the Carrington-scale event would have caused. I imagine most people would be worried about putting food in their bellies and keeping warm, rather than worrying about getting their Exchange server working. I think i may have overthought this. Josh Rice From brain at jbrain.com Thu Apr 7 10:32:51 2022 From: brain at jbrain.com (Jim Brain) Date: Thu, 7 Apr 2022 10:32:51 -0500 Subject: Bob Lucky Message-ID: I don't remember seeing this here, and not sure how many of you read his articles, but: https://spectrum.ieee.org/bob-lucky-obituary -- Jim Brain brain at jbrain.com www.jbrain.com From curiousmarc3 at gmail.com Thu Apr 7 11:14:02 2022 From: curiousmarc3 at gmail.com (Curious Marc) Date: Thu, 7 Apr 2022 11:14:02 -0500 Subject: Bob Lucky In-Reply-To: References: Message-ID: Thanks for the link. I met him when I was at Bell Labs. He was an outstanding technology speaker and writer, with a great sense of humor. His columns were hilarious and right in target. A written form of Dilbert for the technologist. Marc > On Apr 7, 2022, at 10:41 AM, Jim Brain via cctalk wrote: > > ?I don't remember seeing this here, and not sure how many of you read his articles, but: > > https://spectrum.ieee.org/bob-lucky-obituary > > > -- > Jim Brain > brain at jbrain.com www.jbrain.com From lbickley at bickleywest.com Thu Apr 7 11:28:45 2022 From: lbickley at bickleywest.com (Lyle Bickley) Date: Thu, 7 Apr 2022 09:28:45 -0700 Subject: Short PDP-8 Memory Test... In-Reply-To: References: <20220406132039.12F9F18C08B@mercury.lcs.mit.edu> <7wee2afd65.fsf@junk.nocrew.org> <20220406110654.4546eccc@asrock> Message-ID: <20220407092845.1df2fbdb@asrock> Hi Mike, I consider myself fortunate. I have a PDP-8/E, PDP-8/E with a PDP-8/M Front Panel and a PDP-8/M. My PDP-8/E has an RK05 HDD, RX02 dual FDD and VC8E XY with HP1311 XY Display, Extended Math, 32KW core, etc. I used to have a huge running PDP-12 with Dual TU56, TC08 w/TU55, Dual disk RF08, 9-Trk tape, PTR/PTP which I donated to the CHM. It'll probably never see the light of day :( Best, Lyle -- On Wed, 6 Apr 2022 20:31:41 -0500 Mike Katz wrote: > Another PDP-8E?????? You are very lucky :) > > On 4/6/2022 1:06 PM, Lyle Bickley via cctalk wrote: > > I recently acquired another PDP-8/E and wanted to test basic CPU functions > > and memory before I added peripherals. There are some available short > > "memory tests" online, but most don't have have the flexibility to test > > multiple data patterns by design. > > > > The test below does a classic checkerboard type test - and permits easy > > modification of the data pattern used in testing. > > --- > > # Easy to enter, short memory test for PDP-8 systems > > # prior to adding peripheral equipment. > > # by Lyle Bickley > > # > > # Location 21 initially contains a zero. Therefore the > > # memory test is 0000 and 7777 in alternate locations. > > # Changing this location to 7070 will test 7070 and > > # 0707 in alternate locations. Changing it to 5252 will > > # test 5252 and 2525, etc. > > > > 0000 7300 CLA CLL > > 0001 1022 TAD 22 > > 0002 3023 DCA 23 > > 0003 7300 CLA CLL > > 0004 1021 TAD 21 > > 0005 7040 CMA > > 0006 3021 DCA 21 > > 0007 1021 TAD 21 > > 0010 3423 DCA I 23 > > 0011 1021 TAD 21 > > 0012 7041 CMA IAC > > 0013 1423 TAD I 23 > > 0014 7440 SZA > > 0015 7402 HLT (ERROR - AC SHOWS FAIL) > > 0016 2023 ISZ 23 > > 0017 5003 JMP 3 (INC LOCATION AND LOOP) > > 0020 5000 JMP 0 (START OVER) > > 0021 0000 (0=ALT 7777 AND 0000) > > 0022 0025 (LOCATION TO START TEST - MAKE ODD) > > 0023 0000 (LOCATION BEING TESTED) > > --- > > > > Cheers, > > Lyle > -- 73 NM6Y Bickley Consulting West https://bickleywest.com "Black holes are where God is dividing by zero" From stueberahoo at yahoo.de Thu Apr 7 13:02:30 2022 From: stueberahoo at yahoo.de (Anke =?utf-8?Q?St=C3=BCber?=) Date: Thu, 7 Apr 2022 20:02:30 +0200 Subject: Lecture: A tour of Update's new premises, 2022-04-09, 19:00 References: <20220407180230.GC2110.ref@cortexcerebri.geruempel.org> Message-ID: <20220407180230.GC2110@cortexcerebri.geruempel.org> Hi all, you're invited to the Update computer club[0] public lecture series "Updateringar"[1]! When: 2022-04-09, 19:00 CEST Where: https://bbb.cryptoparty.se/b/upd-0mo-m2u-aq8 A tour of Update's new premises In December and January 2021/2022 Update moved out of the Uppsala University IT department's basement into rooms of its own (thanks again to all our volumteers who put in a huge effort!). The new premises offer 150 m? of space for Update's collection and activities, with a dedicated area for exhibitions. What has happened since the move? With this online tour we invite you to take a peek into our new home and at what we've been working on in the last couple of months. We will give you an insight into current and future projects and show off some of our collection items. Bjarni Juliusson, Anke St?ber (Update) The lecture is free and open to everyone. Don't want to miss upcoming events? Subscribe to our low-traffic announcement list here[2]! Hope to see you there, Anke [0] https://www.dfupdate.se/en/ [1] https://wiki.dfupdate.se/projekt:updateringar [2] https://lists.dfupdate.se/postorius/lists/announce.lists.dfupdate.se From Rice43 at btinternet.com Thu Apr 7 14:50:32 2022 From: Rice43 at btinternet.com (Joshua Rice) Date: Thu, 7 Apr 2022 20:50:32 +0100 Subject: RCA COSMAC MS2000 MicroDisk Development System Message-ID: Hi all, I?ve recently come across something i?ve soon realised really quite unusual. An RCA MS2000 MicroDisk Development System. I?m very green to the COSMAC scene, with this being my first 1802 machine. I?m very interested in knowing the pitfalls i may come across in restoring such a machine. I?ve had a quick cursory look over the machine, and it seems to be complete, with 2 RAM/ROM cards, CPU card, FDC and a (3rd party?) ROM programmer board, along with the PSU and floppy disk drives. It?s my understanding that these are pretty similar to the RCA Microboard development systems, which i believe are also pretty similar to the ELF ?homebrew? microcomputer this group revolves around. I?ve found some manuals on bitsavers,, a website on the Microboard system, along with disk images on the Emma02 emulator website, so I have a reasonable undertanding over what this actually is. I have a week off work next week, so am planning on taking my time on disassembling and checking the unit over next week. I?ll endevour to upload some pictures of said machine when i tear it apart. Thanks, Josh Rice From wrcooke at wrcooke.net Thu Apr 7 15:52:20 2022 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Thu, 7 Apr 2022 15:52:20 -0500 (CDT) Subject: RCA COSMAC MS2000 MicroDisk Development System In-Reply-To: References: Message-ID: <617380081.229366.1649364740158@email.ionos.com> > On 04/07/2022 2:50 PM Joshua Rice via cctalk wrote: > > > Hi all, > > I?ve recently come across something i?ve soon realised really quite unusual. An RCA MS2000 MicroDisk Development System. > > I?m very green to the COSMAC scene, with this being my first 1802 machine. I?m very interested in knowing the pitfalls i may come across in restoring such a machine. I?ve had a quick cursory look over the machine, and it seems to be complete, with 2 RAM/ROM cards, CPU card, FDC and a (3rd party?) ROM programmer board, along with the PSU and floppy disk drives. > > It?s my understanding that these are pretty similar to the RCA Microboard development systems, which i believe are also pretty similar to the ELF ?homebrew? microcomputer this group revolves around. I?ve found some manuals on bitsavers,, a website on the Microboard system, along with disk images on the Emma02 emulator website, so I have a reasonable undertanding over what this actually is. > > I have a week off work next week, so am planning on taking my time on disassembling and checking the unit over next week. > > I?ll endevour to upload some pictures of said machine when i tear it apart. > > Thanks, > > Josh Rice I recommend asking about it on the forum at http://cosmacelf.com/ Will From geneb at deltasoft.com Thu Apr 7 16:54:28 2022 From: geneb at deltasoft.com (geneb) Date: Thu, 7 Apr 2022 14:54:28 -0700 (PDT) Subject: RCA COSMAC MS2000 MicroDisk Development System In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022, Joshua Rice via cctalk wrote: > Hi all, > > I?ve recently come across something i?ve soon realised really quite unusual. An RCA MS2000 MicroDisk Development System. > Does it look like this? https://i.imgur.com/Q96sRhE.jpg Nice find! g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_! From billdegnan at gmail.com Thu Apr 7 19:08:30 2022 From: billdegnan at gmail.com (Bill Degnan) Date: Thu, 7 Apr 2022 20:08:30 -0400 Subject: RCA COSMAC MS2000 MicroDisk Development System In-Reply-To: References: Message-ID: This one is from 1975 just before the Altair 8800 https://www.vintagecomputer.net/rca/COSMAC/EDN_COSMAC_Microkit.jpg ...but I bet yours is more like 1976-77. What is the CPU type 1802 or something else? BIll On Thu, Apr 7, 2022 at 5:54 PM geneb via cctalk wrote: > > On Thu, 7 Apr 2022, Joshua Rice via cctalk wrote: > > > Hi all, > > > > I?ve recently come across something i?ve soon realised really quite unusual. An RCA MS2000 MicroDisk Development System. > > > Does it look like this? > https://i.imgur.com/Q96sRhE.jpg > > Nice find! > > > g. > > -- > Proud owner of F-15C 80-0007 > http://www.f15sim.com - The only one of its kind. > http://www.diy-cockpits.org/coll - Go Collimated or Go Home. > Some people collect things for a hobby. Geeks collect hobbies. > > ScarletDME - The red hot Data Management Environment > A Multi-Value database for the masses, not the classes. > http://scarlet.deltasoft.com - Get it _today_! From jdbryan at acm.org Thu Apr 7 16:40:09 2022 From: jdbryan at acm.org (J. David Bryan) Date: Thu, 07 Apr 2022 17:40:09 -0400 Subject: Any CodeWright users: still have patch installers? In-Reply-To: References: Message-ID: <20220407214007.66C2C273B7@mx1.ezwind.net> On Tuesday, April 5, 2022 at 17:52, Daniel Moniz via cctech wrote: > This is a long shot, but on the off chance anyone else on the list > shares some of my particular weirdnesses, anyone got a line on the > *patches* for Embarcadero (nee Borland (nee Starbase (nee Premia) > CodeWright? > > I have the latest version Embarcadero sold (and maybe still sells?) as > of not all that long ago -- 7.5 -- but it's basically patch level 3 > (e.g., 7.5.3) instead of patch level 5 (e.g., 7.5.5). I'm hoping > someone has the patch installers squirreled away somewhere, and that I > can find that person. I'm a 27-year-and-counting Codewright user, and I use it daily. I still think it's a terrific editor. I'm still on version 5.0d, but I thought I had picked up all of the patches from there through 7.5 against the day that I was going to upgrade. I was looking periodically to see if they had fixed two crash bugs that are in 5.0, and I kept waiting -- too long, as it turned out, as it was pulled from the market before I could buy the upgrade. In any event, I looked around here, and apparently I have a full set of release notes and a full set of user's guides through 7.5, but no patch files except for the ones for 5.0. Sorry I couldn't help, but I wanted to let you know that there is at least one other "weird" person out here who understands your affliction. -- Dave From rice43 at btinternet.com Fri Apr 8 02:01:20 2022 From: rice43 at btinternet.com (Joshua Rice) Date: Fri, 8 Apr 2022 08:01:20 +0100 (BST) Subject: RCA COSMAC MS2000 MicroDisk Development System In-Reply-To: References: Message-ID: <77a375ae.27ae7.18007fa382a.Webtop.118@btinternet.com> From: "Bill Degnan via cctech" ...but I bet yours is more like 1976-77. What is the CPU type 1802 or something else? It's definitely an 1802 family CPU, not sure of exact model, but i'll find that out later when i tear it down (and document/post it here). However, it's much newer than '77. The "MicroDisk" part of the name refers to the two early Sony 3.5" drives mounted in the front of the machine, so it dates from about 1984. It uses RCA Microboard cards, so fundamentally it's very similar. Here's a picture i took of it shortly after unboxing: https://imgur.com/gallery/bHYFoBV Cheers, Josh Rice From rice43 at btinternet.com Fri Apr 8 02:09:06 2022 From: rice43 at btinternet.com (Joshua Rice) Date: Fri, 8 Apr 2022 08:09:06 +0100 (BST) Subject: RCA COSMAC MS2000 MicroDisk Development System In-Reply-To: References: Message-ID: <2dd7d3f2.27b05.180080152fe.Webtop.118@btinternet.com> ------ Original Message ------ From: "geneb" Nice find! g. No, it looks like this: https://imgur.com/gallery/bHYFoBV ------ Original Message ------ From: "David Schultz" You didn't mention my web page: http://davesrocketworks.com/electronics/1802/microdos/index.html which might have some additional information useful to you. Thank you, i'm sure that will come in handy! Seems to be a rather poorly documented (and rather rare) system, so any information is good information! Cheers Josh Rice From geneb at deltasoft.com Fri Apr 8 10:02:04 2022 From: geneb at deltasoft.com (geneb) Date: Fri, 8 Apr 2022 08:02:04 -0700 (PDT) Subject: RCA COSMAC MS2000 MicroDisk Development System In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022, Bill Degnan wrote: > This one is from 1975 just before the Altair 8800 > https://www.vintagecomputer.net/rca/COSMAC/EDN_COSMAC_Microkit.jpg > Ah, ok. Thanks for the pic! > ...but I bet yours is more like 1976-77. What is the CPU type 1802 or > something else? > It's an 1802. It's got some serial port boards, RAM, a disk controller and the CPU board in there. I've also got the dual 8" drive and terminal that go with it. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_! From pschow at gmail.com Fri Apr 8 22:45:54 2022 From: pschow at gmail.com (Peter Schow) Date: Fri, 8 Apr 2022 21:45:54 -0600 Subject: Bob Lucky In-Reply-To: References: Message-ID: On Thu, Apr 7, 2022 at 9:41 AM Jim Brain via cctalk wrote: > > I don't remember seeing this here, and not sure how many of you read his > articles, but: > > https://spectrum.ieee.org/bob-lucky-obituary Thanks for letting us know. I got to meet Robert Lucky when he was at Bellcore in the mid-1990s and visited us at U S WEST Advanced Technologies in Boulder, CO. He said Bellcore spent years designing a public internet-like system at scale but their #1 concern was where content was going to come from. They secured preliminary deals with some content-providers, which at the time were the newspapers and wire services, but the whole system was scrapped when the internet took off, as we know it today. By far their biggest surprise was the volume of content that originated from end users (e.g. web sites); they didn't see that coming at all. From cz at alembic.crystel.com Fri Apr 8 22:55:00 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Fri, 8 Apr 2022 21:55:00 -0600 Subject: Bob Lucky In-Reply-To: References: Message-ID: <5f63788a-ccae-704c-eb30-0218d30e1e11@alembic.crystel.com> > Thanks for letting us know. I got to meet Robert Lucky when he was at > Bellcore in the mid-1990s and visited us at U S WEST Advanced > Technologies in Boulder, CO. He said Bellcore spent years designing a > public internet-like system at scale but their #1 concern was where > content was going to come from. They secured preliminary deals with > some content-providers, which at the time were the newspapers and wire > services, but the whole system was scrapped when the internet took > off, as we know it today. By far their biggest surprise was the > volume of content that originated from end users (e.g. web sites); > they didn't see that coming at all. That sounds like AT&T connect! I remember working on it in the late 80's, it was based on IPX/SPX, X400 mail and an X500 directory structure. In fact I think that was the identity system that Novell used for the later NDS directory system to replace the trusty rusty Bindery. It was all supposed to run on ISDN lines to consumers and would be the ultimate market/info place all lovingly run and curated by AT&T. Then of course those meddling kids at FTP released PKTDRV...... Anyone else remember this? CZ From Tim at Rikers.org Sat Apr 9 00:58:12 2022 From: Tim at Rikers.org (Tim Riker) Date: Fri, 8 Apr 2022 23:58:12 -0600 Subject: Quantum ATL-7100 DLT Changer in SLC Message-ID: <5234ec46-dfd0-d07c-f8cb-b3a0550ad317@Rikers.org> I have a Quantum ATL-7100 100 tape DLT changer. Last I checked it worked fine. It's almost as big as a fridge. I have around 100 tapes for it, not all the same density. It uses fast/wide scsi-3 differential for the drives. I think I have 2 working drives in the cabinet plus one or 2 separate external drives. I think my drives are DLT-7000 or similar which gives a total capacity of 7TB. Upgraded with SDLT 220 drives and tapes the chassis would have a capacity of 22TB. Anyone interested in picking this up in South Jordan Utah? (outside Salt Lake City). The only issues I know about it, is the tape loading pivoting door is not quite rotating correctly, and I replaced one of the AT power supplies with a unit that is NOT autoswitching. So if you want to run the unit on 220V instead of 110, you will need to change the chassis and the replaced internal power supply. It's really fun to load it up with tapes, then tell it to auto-shuffle them. I have the door hot wired so you can open the door while it's operating. Easy to restore the switch if you don't want to. Photos here: https://rikers.org/gallery/hardware-atl7100 Interested, please email directly, I don't check the list very often. Tim From Rice43 at btinternet.com Sat Apr 9 06:44:57 2022 From: Rice43 at btinternet.com (Joshua Rice) Date: Sat, 9 Apr 2022 12:44:57 +0100 Subject: RCA COSMAC MS2000 MicroDisk Development System In-Reply-To: References: Message-ID: I?ve torn it down this morning and put some pictures on Imgur. https://imgur.com/gallery/xwSvG8A Should be fairly comprehensive. It looks in good condition, with nothing obviously wrong with it. If there?s anything i?ve missed, or that you?d like better pictures of, let me know. I suppose all that?s left to do is warm it up and see if it works. Cheers, Josh Rice From cz at alembic.crystel.com Sat Apr 9 08:37:23 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Sat, 9 Apr 2022 07:37:23 -0600 Subject: Quantum ATL-7100 DLT Changer in SLC In-Reply-To: <5234ec46-dfd0-d07c-f8cb-b3a0550ad317@Rikers.org> References: <5234ec46-dfd0-d07c-f8cb-b3a0550ad317@Rikers.org> Message-ID: <325ce436-01a5-afb5-5e48-4c2bcdc69956@alembic.crystel.com> I have this strong desire to pick this up and install TK70 tape units. Finally I can back up my pdp11 items in style :-) C On 4/8/2022 11:58 PM, Tim Riker via cctalk wrote: > I have a Quantum ATL-7100 100 tape DLT changer. Last I checked it worked > fine. It's almost as big as a fridge. I have around 100 tapes for it, > not all the same density. It uses fast/wide scsi-3 differential for the > drives. I think I have 2 working drives in the cabinet plus one or 2 > separate external drives. > > I think my drives are DLT-7000 or similar which gives a total capacity > of 7TB. > > Upgraded with SDLT 220 drives and tapes the chassis would have a > capacity of 22TB. > > Anyone interested in picking this up in South Jordan Utah? (outside Salt > Lake City). > > The only issues I know about it, is the tape loading pivoting door is > not quite rotating correctly, and I replaced one of the AT power > supplies with a unit that is NOT autoswitching. So if you want to run > the unit on 220V instead of 110, you will need to change the chassis and > the replaced internal power supply. > > It's really fun to load it up with tapes, then tell it to auto-shuffle > them. I have the door hot wired so you can open the door while it's > operating. Easy to restore the switch if you don't want to. > > Photos here: > > https://rikers.org/gallery/hardware-atl7100 > > Interested, please email directly, I don't check the list very often. > > Tim > From emu at e-bbes.com Sat Apr 9 09:04:15 2022 From: emu at e-bbes.com (emanuel stiebler) Date: Sat, 9 Apr 2022 10:04:15 -0400 Subject: Quantum ATL-7100 DLT Changer in SLC In-Reply-To: <325ce436-01a5-afb5-5e48-4c2bcdc69956@alembic.crystel.com> References: <5234ec46-dfd0-d07c-f8cb-b3a0550ad317@Rikers.org> <325ce436-01a5-afb5-5e48-4c2bcdc69956@alembic.crystel.com> Message-ID: <43eef0be-cdbf-12b8-b792-3eac7561a8ba@e-bbes.com> On 2022-04-09 09:37, Chris Zach via cctalk wrote: > I have this strong desire to pick this up and install TK70 tape units. > Finally I can back up my pdp11 items in style :-) Just pick it up, and read the SETI tapes ;-) From healyzh at avanthar.com Sat Apr 9 10:58:28 2022 From: healyzh at avanthar.com (Zane Healy) Date: Sat, 9 Apr 2022 08:58:28 -0700 Subject: Quantum ATL-7100 DLT Changer in SLC In-Reply-To: <325ce436-01a5-afb5-5e48-4c2bcdc69956@alembic.crystel.com> References: <5234ec46-dfd0-d07c-f8cb-b3a0550ad317@Rikers.org> <325ce436-01a5-afb5-5e48-4c2bcdc69956@alembic.crystel.com> Message-ID: <3934919F-D0E5-4D91-9231-CF177A076B55@avanthar.com> You wouldn?t be able to put TK-70 drives in this, wrong interface. I don?t know if DEC DLT drives capable of reading TK50?s and TK70?s will work in one. We only used DLT III and DLT IV tapes in them. We first got one of these something like 25 years ago. The earliest ones are rock solid, really well built, and very simple to repair. Same with the smaller Quantum 4/52. At the time Quantum wouldn?t send out a Quantum FE to work on the 4/52?s or 7100?s. I?d get the guy out to diagnose the problem, get the replacement parts ordered, and then when the parts came in I?d never tell him, I simply replaced them myself. Just be careful when taking the big side panel off that hides the electronics, otherwise you?ll rip out the sense switch. If you can find a source of spares, you can probably keep one of these going without too much trouble. As for the problem this one has, with the load port, just fold a piece of corrugated cardboard in half, and use it to hold the door close, I ran one in production for a couple years, so I could avoid putting in a service call. I?ve worked with Tape Libraries for over 25 years, and the 4/52 and 7100 are two of my favorites. The Quantum P3000 is my least favorite. The Quantum i2000?s and i6000?s were also rock solid, but I wouldn?t want one of those at home. On the topic of old Quantum tape libraries, does anyone happen to know of a company that will provide 3rd Party support on them? Zane > On Apr 9, 2022, at 6:37 AM, Chris Zach via cctalk wrote: > > I have this strong desire to pick this up and install TK70 tape units. Finally I can back up my pdp11 items in style :-) > > C > > On 4/8/2022 11:58 PM, Tim Riker via cctalk wrote: >> I have a Quantum ATL-7100 100 tape DLT changer. Last I checked it worked fine. It's almost as big as a fridge. I have around 100 tapes for it, not all the same density. It uses fast/wide scsi-3 differential for the drives. I think I have 2 working drives in the cabinet plus one or 2 separate external drives. >> I think my drives are DLT-7000 or similar which gives a total capacity of 7TB. >> Upgraded with SDLT 220 drives and tapes the chassis would have a capacity of 22TB. >> Anyone interested in picking this up in South Jordan Utah? (outside Salt Lake City). >> The only issues I know about it, is the tape loading pivoting door is not quite rotating correctly, and I replaced one of the AT power supplies with a unit that is NOT autoswitching. So if you want to run the unit on 220V instead of 110, you will need to change the chassis and the replaced internal power supply. >> It's really fun to load it up with tapes, then tell it to auto-shuffle them. I have the door hot wired so you can open the door while it's operating. Easy to restore the switch if you don't want to. >> Photos here: >> https://rikers.org/gallery/hardware-atl7100 >> Interested, please email directly, I don't check the list very often. >> Tim From a.carlini at ntlworld.com Sat Apr 9 12:48:00 2022 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Sat, 9 Apr 2022 18:48:00 +0100 Subject: Quantum ATL-7100 DLT Changer in SLC In-Reply-To: <3934919F-D0E5-4D91-9231-CF177A076B55@avanthar.com> References: <5234ec46-dfd0-d07c-f8cb-b3a0550ad317@Rikers.org> <325ce436-01a5-afb5-5e48-4c2bcdc69956@alembic.crystel.com> <3934919F-D0E5-4D91-9231-CF177A076B55@avanthar.com> Message-ID: <15979aeb-51db-9004-d3ee-d8e5a32a7057@ntlworld.com> On 09/04/2022 16:58, Zane Healy via cctalk wrote: > You wouldn?t be able to put TK-70 drives in this, wrong interface. I don?t know if DEC DLT drives capable of reading TK50?s and TK70?s will work in one. I have two TZ877 units, each of which contains a TZ87, and those will read TK50 and TK70 tapes. Whether a TZ87 will work in this drive or not, I don't know. The internal interface board in the TZ877 presents a SCSI interface to the outside world. I realise no-one is going to put a TZ-anything inside a Quantum tape library, but just in case ... Antonio -- Antonio Carlini antonio at acarlini.com From Tim at Rikers.org Sat Apr 9 12:50:42 2022 From: Tim at Rikers.org (Tim Riker) Date: Sat, 9 Apr 2022 11:50:42 -0600 Subject: Quantum ATL-7100 DLT Changer in SLC In-Reply-To: <15979aeb-51db-9004-d3ee-d8e5a32a7057@ntlworld.com> References: <5234ec46-dfd0-d07c-f8cb-b3a0550ad317@Rikers.org> <325ce436-01a5-afb5-5e48-4c2bcdc69956@alembic.crystel.com> <3934919F-D0E5-4D91-9231-CF177A076B55@avanthar.com> <15979aeb-51db-9004-d3ee-d8e5a32a7057@ntlworld.com> Message-ID: I imagine someone hauling this to an event, and running it in shuffle mode with the door open. :) On 4/9/2022 11:48 AM, Antonio Carlini via cctalk wrote: > On 09/04/2022 16:58, Zane Healy via cctalk wrote: >> You wouldn?t be able to put TK-70 drives in this, wrong interface.? I >> don?t know if DEC DLT drives capable of reading TK50?s and TK70?s >> will work in one. > > I have two TZ877 units, each of which contains a TZ87, and those will > read TK50 and TK70 tapes. Whether a TZ87 will work in this drive or > not, I don't know. > > The internal interface board in the TZ877 presents a SCSI interface to > the outside world. > > I realise no-one is going to put a TZ-anything inside a Quantum tape > library, but just in case ... > > Antonio From cz at alembic.crystel.com Sat Apr 9 14:42:56 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Sat, 9 Apr 2022 13:42:56 -0600 Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff Message-ID: Hi all! I'm thinking about going up to VCF in Wall next weekend. I haven't been to it since it was the Trenton Computer Fest (think late 1990's) so I'm not sure what the protocol is on tailgating, trading stuff or whatnot. Appears that they have a "sale room" you drop things off in with prices. Ok.... Things I could "sell" if anyone's interested: HP1000e computer, dead power supply, basic boards, no advanced memory. HP9825B likewise does not power up, but it's there. Microvax 2 boards, stuff like that. Spare 11/24 CPU boards (I have a bunch, all work, no idea why I have all them) Stuff I could bring to get out of my house and into the right hands: Big box of pdp12 schematics. This came from my olden days when I had to turn up a pdp12 because it will not fit in a station wagon. Still it looks like board locations and a lot of 12 stuff. Big box, heavy to ship, easier to drive over. Ton of pdp8/12 IO cables. These are the black circular wire ones, I think negibus. There's also some posibus ribbon cables but I'll save those for my 8/L's. If you need a set, let me know. Stuff I'd trade for: AF01 A/D converter. I don't have Negibus anymore, but I did check/reform the power supply and hooked it up and things do light up. Bunch of extra channel cards (I think it might have all 64). Would trade for a memory box for an 8/L. Back to unearthing BLT.AI.MIT.EDU....... C From mjd.bishop at emeritus-solutions.com Sat Apr 9 16:46:03 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sat, 9 Apr 2022 21:46:03 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working Message-ID: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> A nicely made yellow box with a rather poor manual - both lost in translation and limited in scope. Working on setting one to work, but can't get anything out of the serial port. In drives the punch, and the punched data verifies (based on a QL). In also drives the printer, although somewhat garbled, perhaps due to BCD coding or perhaps due to invalid parity (which is configured as no check). The reader 'reads' tape both in response to X/ON over RS232 and in response to front panel keys. However, nothing is emitted onto 232. The D25 - D-9 transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately and indicating 'correctly' on blinkenlites. Interestingly, on long test tapes the reader does not fall off the end but stops, repeatably after ~49" which is remarkably close to 512 octets. Finally, the CNC termination octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the reader - nothing changes. Specific queries: - Are there any magic control codes or handshaking rituals to coax data out of the reader - Is the PPR to CNC Controller interface protocol manual available as pdf - Where can I find drawings for the PPR's electronics, most importantly the main board (with its 8031) - Suggestions on how to proceed with setting to work / fault diagnosis - Has anyone house trained one of these to read PDP-11 absolute binary tapes, their target market was G code (text) Martin From mooreericnyc at gmail.com Sat Apr 9 17:50:46 2022 From: mooreericnyc at gmail.com (Eric Moore) Date: Sat, 9 Apr 2022 17:50:46 -0500 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> Message-ID: Hi Martin, I use the PPR for all kinds of paper tape shennanigans. https://youtu.be/hGr0F9a7x1A Remove all but the first jumper, and that may help with your issues. I found at one point the jumper settings, but will need to search. -Eric On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk wrote: > A nicely made yellow box with a rather poor manual - both lost in > translation and limited in scope. > > Working on setting one to work, but can't get anything out of the serial > port. In drives the punch, and the punched data verifies (based on a QL). > In also drives the printer, although somewhat garbled, perhaps due to BCD > coding or perhaps due to invalid parity (which is configured as no check). > The reader 'reads' tape both in response to X/ON over RS232 and in response > to front panel keys. However, nothing is emitted onto 232. The D25 - D-9 > transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately > and indicating 'correctly' on blinkenlites. Interestingly, on long test > tapes the reader does not fall off the end but stops, repeatably after ~49" > which is remarkably close to 512 octets. Finally, the CNC termination > octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the reader > - nothing changes. > > Specific queries: > - Are there any magic control codes or handshaking rituals to coax data > out of the reader > - Is the PPR to CNC Controller interface protocol manual available as pdf > - Where can I find drawings for the PPR's electronics, most importantly > the main board (with its 8031) > - Suggestions on how to proceed with setting to work / fault diagnosis > - Has anyone house trained one of these to read PDP-11 absolute binary > tapes, their target market was G code (text) > > Martin > From mooreericnyc at gmail.com Sat Apr 9 18:09:26 2022 From: mooreericnyc at gmail.com (Eric Moore) Date: Sat, 9 Apr 2022 18:09:26 -0500 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> Message-ID: http://vtda.org/docs/computing/FANUC/B-54111E-02_FANUC_System_P_Model_G_Operators_1983.pdf Here you are, I knew I scanned the manual. This has all the jumper settings, and instructions on local vs remote modes. -Eric On Sat, Apr 9, 2022, 5:50 PM Eric Moore wrote: > Hi Martin, I use the PPR for all kinds of paper tape shennanigans. > > https://youtu.be/hGr0F9a7x1A > > Remove all but the first jumper, and that may help with your issues. I > found at one point the jumper settings, but will need to search. > > -Eric > > > > On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk < > cctalk at classiccmp.org> wrote: > >> A nicely made yellow box with a rather poor manual - both lost in >> translation and limited in scope. >> >> Working on setting one to work, but can't get anything out of the serial >> port. In drives the punch, and the punched data verifies (based on a QL). >> In also drives the printer, although somewhat garbled, perhaps due to BCD >> coding or perhaps due to invalid parity (which is configured as no check). >> The reader 'reads' tape both in response to X/ON over RS232 and in response >> to front panel keys. However, nothing is emitted onto 232. The D25 - D-9 >> transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately >> and indicating 'correctly' on blinkenlites. Interestingly, on long test >> tapes the reader does not fall off the end but stops, repeatably after ~49" >> which is remarkably close to 512 octets. Finally, the CNC termination >> octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the reader >> - nothing changes. >> >> Specific queries: >> - Are there any magic control codes or handshaking rituals to coax data >> out of the reader >> - Is the PPR to CNC Controller interface protocol manual available as pdf >> - Where can I find drawings for the PPR's electronics, most importantly >> the main board (with its 8031) >> - Suggestions on how to proceed with setting to work / fault diagnosis >> - Has anyone house trained one of these to read PDP-11 absolute binary >> tapes, their target market was G code (text) >> >> Martin >> > From billdegnan at gmail.com Sat Apr 9 18:13:30 2022 From: billdegnan at gmail.com (Bill Degnan) Date: Sat, 9 Apr 2022 19:13:30 -0400 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> Message-ID: I have a dostek 440a for sale and notes about my fanuc tape unit here. https://www.vintagecomputer.net/fanuc/index.cfm On Sat, Apr 9, 2022, 6:51 PM Eric Moore via cctalk wrote: > Hi Martin, I use the PPR for all kinds of paper tape shennanigans. > > https://youtu.be/hGr0F9a7x1A > > Remove all but the first jumper, and that may help with your issues. I > found at one point the jumper settings, but will need to search. > > -Eric > > > > On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk < > cctalk at classiccmp.org> > wrote: > > > A nicely made yellow box with a rather poor manual - both lost in > > translation and limited in scope. > > > > Working on setting one to work, but can't get anything out of the serial > > port. In drives the punch, and the punched data verifies (based on a > QL). > > In also drives the printer, although somewhat garbled, perhaps due to BCD > > coding or perhaps due to invalid parity (which is configured as no > check). > > The reader 'reads' tape both in response to X/ON over RS232 and in > response > > to front panel keys. However, nothing is emitted onto 232. The D25 - > D-9 > > transition has all the RTS/CTS and DSR/DTR/DCD lines knitted > appropriately > > and indicating 'correctly' on blinkenlites. Interestingly, on long test > > tapes the reader does not fall off the end but stops, repeatably after > ~49" > > which is remarkably close to 512 octets. Finally, the CNC termination > > octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the > reader > > - nothing changes. > > > > Specific queries: > > - Are there any magic control codes or handshaking rituals to coax data > > out of the reader > > - Is the PPR to CNC Controller interface protocol manual available as pdf > > - Where can I find drawings for the PPR's electronics, most importantly > > the main board (with its 8031) > > - Suggestions on how to proceed with setting to work / fault diagnosis > > - Has anyone house trained one of these to read PDP-11 absolute binary > > tapes, their target market was G code (text) > > > > Martin > > > From ethan at 757.org Sat Apr 9 19:01:36 2022 From: ethan at 757.org (Ethan O'Toole) Date: Sat, 9 Apr 2022 20:01:36 -0400 (EDT) Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff In-Reply-To: References: Message-ID: > I'm thinking about going up to VCF in Wall next weekend. I haven't been to it > since it was the Trenton Computer Fest (think late 1990's) so I'm not sure > what the protocol is on tailgating, trading stuff or whatnot. Appears that > they have a "sale room" you drop things off in with prices. Ok.... It's April 22nd to April 24th :-) https://vcfed.org/events/vintage-computer-festival-east/ -- : Ethan O'Toole From mjd.bishop at emeritus-solutions.com Sat Apr 9 19:18:10 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sun, 10 Apr 2022 00:18:10 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> Message-ID: <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> Eric Thank you for the manual and the suggestion of pulling all the jumpers. With all but jumper 1 out, it punches and remote starts (Xon) the reader at 4800 8N1; unchanged functionality. However, still, nothing is emitted from the 232 for consumption by Putty. Unfortunately, the SystemP manual contains identical pages on the PPR to those in the PPR?s own manual. Nonetheless useful as context, and for perusal in slow time. Martin From: Eric Moore [mailto:mooreericnyc at gmail.com] Sent: 10 April 2022 00:09 To: Martin Bishop ; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working http://vtda.org/docs/computing/FANUC/B-54111E-02_FANUC_System_P_Model_G_Operators_1983.pdf Here you are, I knew I scanned the manual. This has all the jumper settings, and instructions on local vs remote modes. -Eric On Sat, Apr 9, 2022, 5:50 PM Eric Moore > wrote: Hi Martin, I use the PPR for all kinds of paper tape shennanigans. https://youtu.be/hGr0F9a7x1A Remove all but the first jumper, and that may help with your issues. I found at one point the jumper settings, but will need to search. -Eric On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk > wrote: A nicely made yellow box with a rather poor manual - both lost in translation and limited in scope. Working on setting one to work, but can't get anything out of the serial port. In drives the punch, and the punched data verifies (based on a QL). In also drives the printer, although somewhat garbled, perhaps due to BCD coding or perhaps due to invalid parity (which is configured as no check). The reader 'reads' tape both in response to X/ON over RS232 and in response to front panel keys. However, nothing is emitted onto 232. The D25 - D-9 transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately and indicating 'correctly' on blinkenlites. Interestingly, on long test tapes the reader does not fall off the end but stops, repeatably after ~49" which is remarkably close to 512 octets. Finally, the CNC termination octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the reader - nothing changes. Specific queries: - Are there any magic control codes or handshaking rituals to coax data out of the reader - Is the PPR to CNC Controller interface protocol manual available as pdf - Where can I find drawings for the PPR's electronics, most importantly the main board (with its 8031) - Suggestions on how to proceed with setting to work / fault diagnosis - Has anyone house trained one of these to read PDP-11 absolute binary tapes, their target market was G code (text) Martin From mjd.bishop at emeritus-solutions.com Sat Apr 9 19:26:14 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sun, 10 Apr 2022 00:26:14 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> Message-ID: Bill Thanks for the offer of the DosTek 440a. However, my problem is getting the 232 output to wiggle a CRO not to input and log the serial data. Fanuc manuals 1788.pdf, on VintageComputer.net, looks as though it contains more detail than the PPR and System P manuals and may reward study. Martin -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Bill Degnan via cctalk Sent: 10 April 2022 00:14 To: Eric Moore ; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working I have a dostek 440a for sale and notes about my fanuc tape unit here. https://www.vintagecomputer.net/fanuc/index.cfm On Sat, Apr 9, 2022, 6:51 PM Eric Moore via cctalk wrote: > Hi Martin, I use the PPR for all kinds of paper tape shennanigans. > > https://youtu.be/hGr0F9a7x1A > > Remove all but the first jumper, and that may help with your issues. I > found at one point the jumper settings, but will need to search. > > -Eric > > > > On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk < > cctalk at classiccmp.org> > wrote: > > > A nicely made yellow box with a rather poor manual - both lost in > > translation and limited in scope. > > > > Working on setting one to work, but can't get anything out of the > > serial port. In drives the punch, and the punched data verifies > > (based on a > QL). > > In also drives the printer, although somewhat garbled, perhaps due > > to BCD coding or perhaps due to invalid parity (which is configured > > as no > check). > > The reader 'reads' tape both in response to X/ON over RS232 and in > response > > to front panel keys. However, nothing is emitted onto 232. The D25 > > - > D-9 > > transition has all the RTS/CTS and DSR/DTR/DCD lines knitted > appropriately > > and indicating 'correctly' on blinkenlites. Interestingly, on long > > test tapes the reader does not fall off the end but stops, > > repeatably after > ~49" > > which is remarkably close to 512 octets. Finally, the CNC > > termination octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to > > impress the > reader > > - nothing changes. > > > > Specific queries: > > - Are there any magic control codes or handshaking rituals to coax > > data out of the reader > > - Is the PPR to CNC Controller interface protocol manual available > > as pdf > > - Where can I find drawings for the PPR's electronics, most > > importantly the main board (with its 8031) > > - Suggestions on how to proceed with setting to work / fault > > diagnosis > > - Has anyone house trained one of these to read PDP-11 absolute > > binary tapes, their target market was G code (text) > > > > Martin > > > From mooreericnyc at gmail.com Sat Apr 9 20:00:58 2022 From: mooreericnyc at gmail.com (Eric Moore) Date: Sat, 9 Apr 2022 20:00:58 -0500 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> Message-ID: Hi Martin, do you have an RS232 light box like this one? RS232 Breakout Tester LED Monitor, DB9 Male to Female Breakout Module https://www.amazon.com/dp/B08CDQ76Q8/ I am so confused why you are not seeing anything, I have had 3 PPRs (2 bartered away) and never had any issues except a broken punch pin and one needing 220V power. -Eric On Sat, Apr 9, 2022, 7:18 PM Martin Bishop < mjd.bishop at emeritus-solutions.com> wrote: > Eric > > > > Thank you for the manual and the suggestion of pulling all the jumpers. > With all but jumper 1 out, it punches and remote starts (Xon) the reader at > 4800 8N1; unchanged functionality. However, still, nothing is emitted from > the 232 for consumption by Putty. > > > > Unfortunately, the SystemP manual contains identical pages on the PPR to > those in the PPR?s own manual. Nonetheless useful as context, and for > perusal in slow time. > > > > Martin > > > > *From:* Eric Moore [mailto:mooreericnyc at gmail.com] > *Sent:* 10 April 2022 00:09 > *To:* Martin Bishop ; General > Discussion: On-Topic and Off-Topic Posts > *Subject:* Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not > quite working > > > > > http://vtda.org/docs/computing/FANUC/B-54111E-02_FANUC_System_P_Model_G_Operators_1983.pdf > > > > Here you are, I knew I scanned the manual. This has all the jumper > settings, and instructions on local vs remote modes. > > > > -Eric > > > > > > > > On Sat, Apr 9, 2022, 5:50 PM Eric Moore wrote: > > Hi Martin, I use the PPR for all kinds of paper tape shennanigans. > > > > https://youtu.be/hGr0F9a7x1A > > > > Remove all but the first jumper, and that may help with your issues. I > found at one point the jumper settings, but will need to search. > > > > -Eric > > > > > > On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk < > cctalk at classiccmp.org> wrote: > > A nicely made yellow box with a rather poor manual - both lost in > translation and limited in scope. > > Working on setting one to work, but can't get anything out of the serial > port. In drives the punch, and the punched data verifies (based on a QL). > In also drives the printer, although somewhat garbled, perhaps due to BCD > coding or perhaps due to invalid parity (which is configured as no check). > The reader 'reads' tape both in response to X/ON over RS232 and in response > to front panel keys. However, nothing is emitted onto 232. The D25 - D-9 > transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately > and indicating 'correctly' on blinkenlites. Interestingly, on long test > tapes the reader does not fall off the end but stops, repeatably after ~49" > which is remarkably close to 512 octets. Finally, the CNC termination > octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the reader > - nothing changes. > > Specific queries: > - Are there any magic control codes or handshaking rituals to coax data > out of the reader > - Is the PPR to CNC Controller interface protocol manual available as pdf > - Where can I find drawings for the PPR's electronics, most importantly > the main board (with its 8031) > - Suggestions on how to proceed with setting to work / fault diagnosis > - Has anyone house trained one of these to read PDP-11 absolute binary > tapes, their target market was G code (text) > > Martin > > From cisin at xenosoft.com Sat Apr 9 21:05:53 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Sat, 9 Apr 2022 19:05:53 -0700 (PDT) Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> Message-ID: > to front panel keys. However, nothing is emitted onto 232. The D25 - D-9 > transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately > and indicating 'correctly' on blinkenlites. I don't know anything about that specific setup, nor anaything aabout your personal expertise. When you say "nothing on 232", is thatr per looking at the wires of the cable? Or just not getting anything displayed by Putty? When you say "knitted appropriately", since that is NOT referring to "as per the manual" (or is it?), have you checked all inputs and outputs? Sometimes devices, at either end of the cable, have unexpected requirements,that are not usual parts of the RS232 "standard". For example, I was once asked by the "Radio Shack Computer Center" to help them connect a Votrax to a Model 2 (for a blind customer). They had tried all of the obvious commodity "null modems", etc. I used a "matrix switch", but also had to solder one additional jumper for a pin that is not "normally" used for such things, and no obvious reason for being used. I no longer remember which pin; it was possibly #10 or #12, but it might just have been #22 ("ring indicator"). To avoid the bureaucratic administrative nonsense needed for them to pay me, I accepted a gift of a Model 2 Technical Reference manual as compensation. From cclist at sydex.com Sat Apr 9 21:28:53 2022 From: cclist at sydex.com (Chuck Guzis) Date: Sat, 9 Apr 2022 19:28:53 -0700 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> Message-ID: <9fe44bf2-1dc7-4f18-c352-99bd447a6ea5@sydex.com> On 4/9/22 17:26, Martin Bishop via cctalk wrote: > Bill > > Thanks for the offer of the DosTek 440a. However, my problem is getting the 232 output to wiggle a CRO not to input and log the serial data. > > Fanuc manuals 1788.pdf, on VintageComputer.net, looks as though it contains more detail than the PPR and System P manuals and may reward study. > Are you certain that the interface isn't wired for current loop? A lot of these CNC (I'm assuming that this Fanuc unit falls in that category) used the CL interface. Connector's the D-25. --Chuck From mjd.bishop at emeritus-solutions.com Sun Apr 10 04:44:37 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sun, 10 Apr 2022 09:44:37 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> Message-ID: <8bf9c84a1c2e4ce2b76ee861bbab10d0@WINHEXBEEU125.win.mail> Hi Eric I have a pair of light boxes and a CRO on the job: - Modular Technology MT25-IV on the PPR side, - BlackBox TS50A on the D-9 side, - CRO on p2 & p3 This unit says it takes and is receiving 220V power I can see codes going to the unit, but nothing coming out ? stuck at logical zero (-7.5 V) I could start to believe that the RS232 driver may have an issue It sounds as though your experience is feed tape and out come the octets ? Martin From: Eric Moore [mailto:mooreericnyc at gmail.com] Sent: 10 April 2022 02:01 To: Martin Bishop Cc: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working Hi Martin, do you have an RS232 light box like this one? RS232 Breakout Tester LED Monitor, DB9 Male to Female Breakout Module https://www.amazon.com/dp/B08CDQ76Q8/ I am so confused why you are not seeing anything, I have had 3 PPRs (2 bartered away) and never had any issues except a broken punch pin and one needing 220V power. -Eric On Sat, Apr 9, 2022, 7:18 PM Martin Bishop > wrote: Eric Thank you for the manual and the suggestion of pulling all the jumpers. With all but jumper 1 out, it punches and remote starts (Xon) the reader at 4800 8N1; unchanged functionality. However, still, nothing is emitted from the 232 for consumption by Putty. Unfortunately, the SystemP manual contains identical pages on the PPR to those in the PPR?s own manual. Nonetheless useful as context, and for perusal in slow time. Martin From: Eric Moore [mailto:mooreericnyc at gmail.com] Sent: 10 April 2022 00:09 To: Martin Bishop >; General Discussion: On-Topic and Off-Topic Posts > Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working http://vtda.org/docs/computing/FANUC/B-54111E-02_FANUC_System_P_Model_G_Operators_1983.pdf Here you are, I knew I scanned the manual. This has all the jumper settings, and instructions on local vs remote modes. -Eric On Sat, Apr 9, 2022, 5:50 PM Eric Moore > wrote: Hi Martin, I use the PPR for all kinds of paper tape shennanigans. https://youtu.be/hGr0F9a7x1A Remove all but the first jumper, and that may help with your issues. I found at one point the jumper settings, but will need to search. -Eric On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk > wrote: A nicely made yellow box with a rather poor manual - both lost in translation and limited in scope. Working on setting one to work, but can't get anything out of the serial port. In drives the punch, and the punched data verifies (based on a QL). In also drives the printer, although somewhat garbled, perhaps due to BCD coding or perhaps due to invalid parity (which is configured as no check). The reader 'reads' tape both in response to X/ON over RS232 and in response to front panel keys. However, nothing is emitted onto 232. The D25 - D-9 transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately and indicating 'correctly' on blinkenlites. Interestingly, on long test tapes the reader does not fall off the end but stops, repeatably after ~49" which is remarkably close to 512 octets. Finally, the CNC termination octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the reader - nothing changes. Specific queries: - Are there any magic control codes or handshaking rituals to coax data out of the reader - Is the PPR to CNC Controller interface protocol manual available as pdf - Where can I find drawings for the PPR's electronics, most importantly the main board (with its 8031) - Suggestions on how to proceed with setting to work / fault diagnosis - Has anyone house trained one of these to read PDP-11 absolute binary tapes, their target market was G code (text) Martin From mjd.bishop at emeritus-solutions.com Sun Apr 10 06:00:55 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sun, 10 Apr 2022 11:00:55 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> Message-ID: <53511be98e104ac6bd71ccff241c5a16@WINHEXBEEU125.win.mail> Fred You have a good measure of my problem. As for my expertise: its 40 years since I left schoool with a PhD in Signal Processing, I'm currently designing with Xilinx Zynqs, and if the RS232 driver has to be pulled there is a Pace SX-80 on the bench in the workshop. I have a pair of light boxes and a CRO on the job: - Modular Technology MT25-IV on the PPR side (first outing in 20+ years), - BlackBox TS50A on the D-9 side, - CRO on p2 & p3 The CRO can see codes (at 4800 baud) going to the unit, but nothing coming out - stuck at logical zero (-7.5 V). Putty talks to the PPR - characters to punch, Xon starts reader, etc. Putty etc also talks to other hardware, i.e. its been tested. Sometimes devices, at either end of the cable, have unexpected requirements,that are not usual parts of the RS232 "standard". That, essentially is my question, before I start chasing a hardware / driver issue. Although, to date, I have drawn a blank. Knitting, first the D25 with pins on the PPR's OEM cable (pin : C/I/O(wrt PPR) : color : presumed function): 1 - C - black - chassis ground 2 - I - yellow - TXD fr Pc to PPR (evidenced by lites / CRO) 3 - O - brown - RXD fr PPR to PC (evidenced by lites / -7v5 voltage) 4 - I - green - RTS 5 - O - yellow - CTS 6 - O - gray - DSR 7 - C - orange - signal gnd 8 - I - brown - DCD 20 - I - jumper (grey) to pin 8 - DTR Note no other pins, esp 9 13 18 the D-25 current loop pins; therefore unlikely to be either current loop serial or 8 bit parallel (and the volts are not TTL). D-25 to D-9 knitting (D25(PPR) : Direction : D9(Pc/FTDI 232) : function): 7 -- 5 common gnd 2 <- 3 TxD from Pc to PPR 3 -> 2 RxD from PPR to Pc 4 <- 7 RTS from Pc to PPR 5 -> 8 CTS from PPR to Pc 6 -> 6 & 1 DSR from PPR to Pc (DSR & DCD) 8 & 20 <- 4 DCD & DTR from Pc (DTR) to PPR (DCD & DTR) Note I'm well aware that RTS to RTS etc is not normative, however the volts tell another story; presume I have a pair of DTEs / DCEs Equally the classic quick bodge terminal (D-25) end jumpers don't deliver a result: 4-5 RTS-CTS 6-8-20 DSR-DTR-DCD Thanks for your interest in my problem, and motivating me to open / inspect the D-25. Martin -----Original Message----- From: Fred Cisin [mailto:cisin at xenosoft.com] Sent: 10 April 2022 03:06 To: Eric Moore ; General Discussion: On-Topic and Off-Topic Posts Cc: Martin Bishop Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working > to front panel keys. However, nothing is emitted onto 232. The D25 - > D-9 transition has all the RTS/CTS and DSR/DTR/DCD lines knitted > appropriately and indicating 'correctly' on blinkenlites. I don't know anything about that specific setup, nor anaything aabout your personal expertise. When you say "nothing on 232", is thatr per looking at the wires of the cable? Or just not getting anything displayed by Putty? When you say "knitted appropriately", since that is NOT referring to "as per the manual" (or is it?), have you checked all inputs and outputs? Sometimes devices, at either end of the cable, have unexpected requirements,that are not usual parts of the RS232 "standard". For example, I was once asked by the "Radio Shack Computer Center" to help them connect a Votrax to a Model 2 (for a blind customer). They had tried all of the obvious commodity "null modems", etc. I used a "matrix switch", but also had to solder one additional jumper for a pin that is not "normally" used for such things, and no obvious reason for being used. I no longer remember which pin; it was possibly #10 or #12, but it might just have been #22 ("ring indicator"). To avoid the bureaucratic administrative nonsense needed for them to pay me, I accepted a gift of a Model 2 Technical Reference manual as compensation. From mjd.bishop at emeritus-solutions.com Sun Apr 10 07:13:58 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sun, 10 Apr 2022 12:13:58 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> Message-ID: Bill Your link to https://www.vintagecomputer.net/fanuc/FanucManuals1788.pdf "Fanuc System 6T-Model B" is very helpful. The reader fitted to the PPR is a A860-0066-T001. The readers referenced in the manual are close relatives. Importantly, the manual provides significantly more detail on calibration and lubrication that the PPR manual. Specifically: - p 2 Block diagram - p 7 Block diagram - P 11 .. 20 Tape reader preventative maintenance (i.e. oiling) - p 62 .. 63 Tape reader fault finding; esp node 13 -- use black tape - p 81 .. 83 tape reader photo amplifier adjustment, tape pattern specification, observations and objectives (not in PPR manual - although not all applicable ?) - p84 System connection diagram - p 368 .. 369 Tape codes (ISO & EIA) - useful crib - p 384 .. 385 Tape Reader lubricant specifications None of the foregoing has resolved my problem. However, I now know that you have to adjust for tape color p 82 note 2. And, page 81 provides the cookery for a "zig zag" tape [referenced by pages 47 & 48 of the PPR operators manual]. Next step, make loop tapes (black and yellow) and attempt photo-amplifier adjustment. Martin -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Bill Degnan via cctalk Sent: 10 April 2022 00:14 To: Eric Moore ; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working I have a dostek 440a for sale and notes about my fanuc tape unit here. https://www.vintagecomputer.net/fanuc/index.cfm On Sat, Apr 9, 2022, 6:51 PM Eric Moore via cctalk wrote: > Hi Martin, I use the PPR for all kinds of paper tape shennanigans. > > https://youtu.be/hGr0F9a7x1A > > Remove all but the first jumper, and that may help with your issues. I > found at one point the jumper settings, but will need to search. > > -Eric > > > > On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk < > cctalk at classiccmp.org> > wrote: > > > A nicely made yellow box with a rather poor manual - both lost in > > translation and limited in scope. > > > > Working on setting one to work, but can't get anything out of the > > serial port. In drives the punch, and the punched data verifies > > (based on a > QL). > > In also drives the printer, although somewhat garbled, perhaps due > > to BCD coding or perhaps due to invalid parity (which is configured > > as no > check). > > The reader 'reads' tape both in response to X/ON over RS232 and in > response > > to front panel keys. However, nothing is emitted onto 232. The D25 > > - > D-9 > > transition has all the RTS/CTS and DSR/DTR/DCD lines knitted > appropriately > > and indicating 'correctly' on blinkenlites. Interestingly, on long > > test tapes the reader does not fall off the end but stops, > > repeatably after > ~49" > > which is remarkably close to 512 octets. Finally, the CNC > > termination octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to > > impress the > reader > > - nothing changes. > > > > Specific queries: > > - Are there any magic control codes or handshaking rituals to coax > > data out of the reader > > - Is the PPR to CNC Controller interface protocol manual available > > as pdf > > - Where can I find drawings for the PPR's electronics, most > > importantly the main board (with its 8031) > > - Suggestions on how to proceed with setting to work / fault > > diagnosis > > - Has anyone house trained one of these to read PDP-11 absolute > > binary tapes, their target market was G code (text) > > > > Martin > > > From cube1 at charter.net Sun Apr 10 08:51:02 2022 From: cube1 at charter.net (Jay Jaeger) Date: Sun, 10 Apr 2022 08:51:02 -0500 Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff In-Reply-To: References: Message-ID: <941ef5b2-3c5f-dbe6-d776-58a67b7a826a@charter.net> On 4/9/2022 2:42 PM, Chris Zach via cctalk wrote: > Hi all! > > I'm thinking about going up to VCF in Wall next weekend. I haven't been > to it since it was the Trenton Computer Fest (think late 1990's) so I'm > not sure what the protocol is on tailgating, trading stuff or whatnot. > Appears that they have a "sale room" you drop things off in with prices. > Ok.... > > Things I could "sell" if anyone's interested: > HP1000e computer, dead power supply, basic boards, no advanced memory. > HP9825B likewise does not power up, but it's there. > Microvax 2 boards, stuff like that. > Spare 11/24 CPU boards (I have a bunch, all work, no idea why I have all > them) > My 11/24 wouldn't mind having a spare CPU and/or Unibus Map - but I won't be at VCF. JRJ From mooreericnyc at gmail.com Sun Apr 10 11:22:50 2022 From: mooreericnyc at gmail.com (Eric Moore) Date: Sun, 10 Apr 2022 11:22:50 -0500 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: <8bf9c84a1c2e4ce2b76ee861bbab10d0@WINHEXBEEU125.win.mail> References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> <8bf9c84a1c2e4ce2b76ee861bbab10d0@WINHEXBEEU125.win.mail> Message-ID: Yep! That is my experience in remote mode, both driven via the panel or remotely. You know more than I do, I hope you get it figured out soon! The PPR is super fun to have on the bench if you have tapes to read or especially if you have a computer that works with paper tape. -Eric On Sun, Apr 10, 2022, 4:44 AM Martin Bishop < mjd.bishop at emeritus-solutions.com> wrote: > Hi Eric > > > > I have a pair of light boxes and a CRO on the job: > > - Modular Technology MT25-IV on the PPR side, > > - BlackBox TS50A on the D-9 side, > > - CRO on p2 & p3 > > > > This unit says it takes and is receiving 220V power > > > > I can see codes going to the unit, but nothing coming out ? stuck at > logical zero (-7.5 V) > > > > I could start to believe that the RS232 driver may have an issue > > > > It sounds as though your experience is feed tape and out come the octets ? > > > > Martin > > *From:* Eric Moore [mailto:mooreericnyc at gmail.com] > *Sent:* 10 April 2022 02:01 > *To:* Martin Bishop > *Cc:* General Discussion: On-Topic and Off-Topic Posts < > cctalk at classiccmp.org> > *Subject:* Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not > quite working > > > > Hi Martin, do you have an RS232 light box like this one? > > > > RS232 Breakout Tester LED Monitor, DB9 Male to Female Breakout Module > https://www.amazon.com/dp/B08CDQ76Q8/ > > > > I am so confused why you are not seeing anything, I have had 3 PPRs (2 > bartered away) and never had any issues except a broken punch pin and one > needing 220V power. > > > > -Eric > > > > > > On Sat, Apr 9, 2022, 7:18 PM Martin Bishop < > mjd.bishop at emeritus-solutions.com> wrote: > > Eric > > > > Thank you for the manual and the suggestion of pulling all the jumpers. > With all but jumper 1 out, it punches and remote starts (Xon) the reader at > 4800 8N1; unchanged functionality. However, still, nothing is emitted from > the 232 for consumption by Putty. > > > > Unfortunately, the SystemP manual contains identical pages on the PPR to > those in the PPR?s own manual. Nonetheless useful as context, and for > perusal in slow time. > > > > Martin > > > > *From:* Eric Moore [mailto:mooreericnyc at gmail.com] > *Sent:* 10 April 2022 00:09 > *To:* Martin Bishop ; General > Discussion: On-Topic and Off-Topic Posts > *Subject:* Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not > quite working > > > > > http://vtda.org/docs/computing/FANUC/B-54111E-02_FANUC_System_P_Model_G_Operators_1983.pdf > > > > Here you are, I knew I scanned the manual. This has all the jumper > settings, and instructions on local vs remote modes. > > > > -Eric > > > > > > > > On Sat, Apr 9, 2022, 5:50 PM Eric Moore wrote: > > Hi Martin, I use the PPR for all kinds of paper tape shennanigans. > > > > https://youtu.be/hGr0F9a7x1A > > > > Remove all but the first jumper, and that may help with your issues. I > found at one point the jumper settings, but will need to search. > > > > -Eric > > > > > > On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk < > cctalk at classiccmp.org> wrote: > > A nicely made yellow box with a rather poor manual - both lost in > translation and limited in scope. > > Working on setting one to work, but can't get anything out of the serial > port. In drives the punch, and the punched data verifies (based on a QL). > In also drives the printer, although somewhat garbled, perhaps due to BCD > coding or perhaps due to invalid parity (which is configured as no check). > The reader 'reads' tape both in response to X/ON over RS232 and in response > to front panel keys. However, nothing is emitted onto 232. The D25 - D-9 > transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately > and indicating 'correctly' on blinkenlites. Interestingly, on long test > tapes the reader does not fall off the end but stops, repeatably after ~49" > which is remarkably close to 512 octets. Finally, the CNC termination > octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the reader > - nothing changes. > > Specific queries: > - Are there any magic control codes or handshaking rituals to coax data > out of the reader > - Is the PPR to CNC Controller interface protocol manual available as pdf > - Where can I find drawings for the PPR's electronics, most importantly > the main board (with its 8031) > - Suggestions on how to proceed with setting to work / fault diagnosis > - Has anyone house trained one of these to read PDP-11 absolute binary > tapes, their target market was G code (text) > > Martin > > From mjd.bishop at emeritus-solutions.com Sun Apr 10 12:43:43 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sun, 10 Apr 2022 17:43:43 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> <8bf9c84a1c2e4ce2b76ee861bbab10d0@WINHEXBEEU125.win.mail> Message-ID: <66b1b3e533334211a5b54c94030f8e72@WINHEXBEEU125.win.mail> Eric Thanks for confirmation the reader should ?just work?. Unfortunately it does not ... One other specific : can the PPR punch absolute binary tapes, e.g. for a PDP-11, one potential use. Or, is it limited to ?alpha numeric? ASCII. Using the native controller, I can?t see any way of geting it to punch e.g. DC1 .. DC4, they control the logic and are absorbed prior to the punch. Is there an escape sequence ? The reader does not want to cal: - the procedure is in the PPR Operators manual [B-54584E/01 p 47-48] - the tape is a loop of U* with even parity, taken from ano Fanuc manual [see my 10 1314A Apr 21] - the tape feeds, but none of the indications illuminate : 50/60 Hz, sprocket signal, channel signal - beyond my doing it incorrectly (tried a few times), I would wonder if either lamp or optos are kaput Consequently, signal tracing to / from the reader looks the way to go, and the place to start is probably the sprocket opto. A job for another "weekend", preferably with the circuits to hand - although I have seen no sign of any. Martin From: Eric Moore [mailto:mooreericnyc at gmail.com] Sent: 10 April 2022 17:23 To: Martin Bishop Cc: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working Yep! That is my experience in remote mode, both driven via the panel or remotely. You know more than I do, I hope you get it figured out soon! The PPR is super fun to have on the bench if you have tapes to read or especially if you have a computer that works with paper tape. -Eric On Sun, Apr 10, 2022, 4:44 AM Martin Bishop wrote: Hi Eric ? I have a pair of light boxes and a CRO on the job: -????????? Modular Technology MT25-IV on the PPR side, -????????? BlackBox TS50A on the D-9 side, -????????? CRO on p2 & p3 ? This unit says it takes and is receiving 220V power ? I can see codes going to the unit, but nothing coming out ? stuck at logical zero (-7.5 V) ? I could start to believe that the RS232 driver may have an issue ? It sounds as though your experience is feed tape and out come the octets ? ? Martin From: Eric Moore [mailto:mooreericnyc at gmail.com] Sent: 10 April 2022 02:01 To: Martin Bishop Cc: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working ? Hi Martin, do you have an RS232 light box like this one? ? RS232 Breakout Tester LED Monitor, DB9 Male to Female Breakout Module https://www.amazon.com/dp/B08CDQ76Q8/ ? I am so confused why you are not seeing anything, I have had 3 PPRs (2 bartered away) and never had any issues except a broken punch pin and one needing 220V power.? ? -Eric ? ? On Sat, Apr 9, 2022, 7:18 PM Martin Bishop wrote: Eric ? Thank you for the manual and the suggestion of pulling all the jumpers.? With all but jumper 1 out, it punches and remote starts (Xon) the reader at 4800 8N1; unchanged functionality.? However, still, nothing is emitted from the 232 for consumption by Putty. ? Unfortunately, the SystemP manual contains identical pages on the PPR to those in the PPR?s own manual.? Nonetheless useful as context, and for perusal in slow time. ? Martin ? From: Eric Moore [mailto:mooreericnyc at gmail.com] Sent: 10 April 2022 00:09 To: Martin Bishop ; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working ? http://vtda.org/docs/computing/FANUC/B-54111E-02_FANUC_System_P_Model_G_Operators_1983.pdf ? Here you are, I knew I scanned the manual. This has all the jumper settings, and instructions on local vs remote modes. ? -Eric ? ? ? On Sat, Apr 9, 2022, 5:50 PM Eric Moore wrote: Hi Martin, I use the PPR for all kinds of paper tape shennanigans. ? https://youtu.be/hGr0F9a7x1A ? Remove all but the first jumper, and that may help with your issues. I found at one point the jumper settings, but will need to search. ? -Eric ? ? On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk wrote: A nicely made yellow box with a rather poor manual - both lost in translation and limited in scope. Working on setting one to work, but can't get anything out of the serial port.? In drives the punch, and the punched data verifies (based on a QL).? In also drives the printer, although somewhat garbled, perhaps due to BCD coding or perhaps due to invalid parity (which is configured as no check).? The reader 'reads' tape both in response to X/ON over RS232 and in response to front panel keys.? However, nothing is emitted onto 232.? The D25 - D-9 transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately and indicating 'correctly' on blinkenlites.? Interestingly, on long test tapes the reader does not fall off the end but stops, repeatably after ~49" which is remarkably close to 512 octets.? Finally, the CNC termination octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the reader - nothing changes. Specific queries: - Are there any magic control codes or handshaking rituals to coax data out of the reader - Is the PPR to CNC Controller interface protocol manual available as pdf - Where can I find drawings for the PPR's electronics, most importantly the main board (with its 8031) - Suggestions on how to proceed with setting to work / fault diagnosis - Has anyone house trained one of these to read PDP-11 absolute binary tapes, their target market was G code (text) Martin From mjd.bishop at emeritus-solutions.com Sun Apr 10 13:08:39 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sun, 10 Apr 2022 18:08:39 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: <9fe44bf2-1dc7-4f18-c352-99bd447a6ea5@sydex.com> References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <9fe44bf2-1dc7-4f18-c352-99bd447a6ea5@sydex.com> Message-ID: <273962b7718b47f8bdffe1767a576550@WINHEXBEEU125.win.mail> Chuck Thank you for the parallel port suggestion. I followed it up by opening the D-25 and reviewing the wiring. It looks very RS232 to me, the pin out I found is detailed in my 10 1314A Apr 22. That the punch and reader respond to RS232 input I think settles the issue - I was briefly optimistic ... Martin -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck Guzis via cctalk Sent: 10 April 2022 03:29 To: Martin Bishop via cctalk Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working On 4/9/22 17:26, Martin Bishop via cctalk wrote: > Bill > > Thanks for the offer of the DosTek 440a. However, my problem is getting the 232 output to wiggle a CRO not to input and log the serial data. > > Fanuc manuals 1788.pdf, on VintageComputer.net, looks as though it contains more detail than the PPR and System P manuals and may reward study. > Are you certain that the interface isn't wired for current loop? A lot of these CNC (I'm assuming that this Fanuc unit falls in that category) used the CL interface. Connector's the D-25. --Chuck From cclist at sydex.com Sun Apr 10 14:08:03 2022 From: cclist at sydex.com (Chuck Guzis) Date: Sun, 10 Apr 2022 12:08:03 -0700 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: <273962b7718b47f8bdffe1767a576550@WINHEXBEEU125.win.mail> References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <9fe44bf2-1dc7-4f18-c352-99bd447a6ea5@sydex.com> <273962b7718b47f8bdffe1767a576550@WINHEXBEEU125.win.mail> Message-ID: On 4/10/22 11:08, Martin Bishop wrote: > Chuck > > Thank you for the parallel port suggestion. I followed it up by opening the D-25 and reviewing the wiring. It looks very RS232 to me, the pin out I found is detailed in my 10 1314A Apr 22. That the punch and reader respond to RS232 input I think settles the issue - I was briefly optimistic ... No, not parallel port, but 20 ma current loop. Used extensively in teletype/industrial work. Still serial, but suited to long-haul or noisy environments. The original IBM PC serial card could be configured for CL. The advantage is that it's not voltage-sensitive per se, but rather to the current flowing through the loop. On long hauls, one could raise the voltage until the proper current level was obtained. RS232C, on the other hand is strictly voltage-sensitive. https://en.wikipedia.org/wiki/Current_loop for details. But it sounds as if you have a bog-standard RS232C setup. Very old teletype setups used, I believe 60 ma. CL. --Chuck From mooreericnyc at gmail.com Sun Apr 10 14:22:44 2022 From: mooreericnyc at gmail.com (Eric Moore) Date: Sun, 10 Apr 2022 14:22:44 -0500 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: <66b1b3e533334211a5b54c94030f8e72@WINHEXBEEU125.win.mail> References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> <8bf9c84a1c2e4ce2b76ee861bbab10d0@WINHEXBEEU125.win.mail> <66b1b3e533334211a5b54c94030f8e72@WINHEXBEEU125.win.mail> Message-ID: Yep! You can absolutely punch straight binary to tape. There is an escape, the details escape me but are enshrined in my silly network attached paper tape program: https://github.com/emooreatx/FANUC-PPR -Eric On Sun, Apr 10, 2022, 12:43 PM Martin Bishop < mjd.bishop at emeritus-solutions.com> wrote: > Eric > > Thanks for confirmation the reader should ?just work?. Unfortunately it > does not ... > > One other specific : can the PPR punch absolute binary tapes, e.g. for a > PDP-11, one potential use. Or, is it limited to ?alpha numeric? ASCII. > Using the native controller, I can?t see any way of geting it to punch e.g. > DC1 .. DC4, they control the logic and are absorbed prior to the punch. Is > there an escape sequence ? > > The reader does not want to cal: > - the procedure is in the PPR Operators manual [B-54584E/01 p 47-48] > - the tape is a loop of U* with even parity, taken from ano Fanuc manual > [see my 10 1314A Apr 21] > - the tape feeds, but none of the indications illuminate : 50/60 Hz, > sprocket signal, channel signal > - beyond my doing it incorrectly (tried a few times), I would wonder if > either lamp or optos are kaput > > Consequently, signal tracing to / from the reader looks the way to go, and > the place to start is probably the sprocket opto. A job for another > "weekend", preferably with the circuits to hand - although I have seen no > sign of any. > > Martin > > From: Eric Moore [mailto:mooreericnyc at gmail.com] > Sent: 10 April 2022 17:23 > To: Martin Bishop > Cc: General Discussion: On-Topic and Off-Topic Posts < > cctalk at classiccmp.org> > Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite > working > > Yep! That is my experience in remote mode, both driven via the panel or > remotely. > > You know more than I do, I hope you get it figured out soon! The PPR is > super fun to have on the bench if you have tapes to read or especially if > you have a computer that works with paper tape. > > -Eric > > > > On Sun, Apr 10, 2022, 4:44 AM Martin Bishop < > mjd.bishop at emeritus-solutions.com> wrote: > Hi Eric > > I have a pair of light boxes and a CRO on the job: > - Modular Technology MT25-IV on the PPR side, > - BlackBox TS50A on the D-9 side, > - CRO on p2 & p3 > > This unit says it takes and is receiving 220V power > > I can see codes going to the unit, but nothing coming out ? stuck at > logical zero (-7.5 V) > > I could start to believe that the RS232 driver may have an issue > > It sounds as though your experience is feed tape and out come the octets ? > > Martin > From: Eric Moore [mailto:mooreericnyc at gmail.com] > Sent: 10 April 2022 02:01 > To: Martin Bishop > Cc: General Discussion: On-Topic and Off-Topic Posts < > cctalk at classiccmp.org> > Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite > working > > Hi Martin, do you have an RS232 light box like this one? > > RS232 Breakout Tester LED Monitor, DB9 Male to Female Breakout Module > https://www.amazon.com/dp/B08CDQ76Q8/ > > I am so confused why you are not seeing anything, I have had 3 PPRs (2 > bartered away) and never had any issues except a broken punch pin and one > needing 220V power. > > -Eric > > > On Sat, Apr 9, 2022, 7:18 PM Martin Bishop < > mjd.bishop at emeritus-solutions.com> wrote: > Eric > > Thank you for the manual and the suggestion of pulling all the jumpers. > With all but jumper 1 out, it punches and remote starts (Xon) the reader at > 4800 8N1; unchanged functionality. However, still, nothing is emitted from > the 232 for consumption by Putty. > > Unfortunately, the SystemP manual contains identical pages on the PPR to > those in the PPR?s own manual. Nonetheless useful as context, and for > perusal in slow time. > > Martin > > From: Eric Moore [mailto:mooreericnyc at gmail.com] > Sent: 10 April 2022 00:09 > To: Martin Bishop ; General > Discussion: On-Topic and Off-Topic Posts > Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite > working > > > http://vtda.org/docs/computing/FANUC/B-54111E-02_FANUC_System_P_Model_G_Operators_1983.pdf > > Here you are, I knew I scanned the manual. This has all the jumper > settings, and instructions on local vs remote modes. > > -Eric > > > > On Sat, Apr 9, 2022, 5:50 PM Eric Moore wrote: > Hi Martin, I use the PPR for all kinds of paper tape shennanigans. > > https://youtu.be/hGr0F9a7x1A > > Remove all but the first jumper, and that may help with your issues. I > found at one point the jumper settings, but will need to search. > > -Eric > > > On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk < > cctalk at classiccmp.org> wrote: > A nicely made yellow box with a rather poor manual - both lost in > translation and limited in scope. > > Working on setting one to work, but can't get anything out of the serial > port. In drives the punch, and the punched data verifies (based on a QL). > In also drives the printer, although somewhat garbled, perhaps due to BCD > coding or perhaps due to invalid parity (which is configured as no check). > The reader 'reads' tape both in response to X/ON over RS232 and in response > to front panel keys. However, nothing is emitted onto 232. The D25 - D-9 > transition has all the RTS/CTS and DSR/DTR/DCD lines knitted appropriately > and indicating 'correctly' on blinkenlites. Interestingly, on long test > tapes the reader does not fall off the end but stops, repeatably after ~49" > which is remarkably close to 512 octets. Finally, the CNC termination > octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to impress the reader > - nothing changes. > > Specific queries: > - Are there any magic control codes or handshaking rituals to coax data > out of the reader > - Is the PPR to CNC Controller interface protocol manual available as pdf > - Where can I find drawings for the PPR's electronics, most importantly > the main board (with its 8031) > - Suggestions on how to proceed with setting to work / fault diagnosis > - Has anyone house trained one of these to read PDP-11 absolute binary > tapes, their target market was G code (text) > > Martin > From mjd.bishop at emeritus-solutions.com Sun Apr 10 14:23:05 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sun, 10 Apr 2022 19:23:05 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <9fe44bf2-1dc7-4f18-c352-99bd447a6ea5@sydex.com> <273962b7718b47f8bdffe1767a576550@WINHEXBEEU125.win.mail> Message-ID: <552cc88322de4f3f803d074a60940581@WINHEXBEEU125.win.mail> Chuck My error, you said 20 mA current loop, I bowdlerised it as parallel port. I have a punch with a parallel interface ... I can't recollect ever using a current loop interface on equipment, although I have met many in old documents. 4 .. 20 mA current loops reporting e.g. pressure actuated potentiometers are however old friends, if that is the correct term. As you observe current loop has good noise immunity. Martin -----Original Message----- From: Chuck Guzis [mailto:cclist at sydex.com] Sent: 10 April 2022 20:08 To: Martin Bishop Cc: CCtalk Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working On 4/10/22 11:08, Martin Bishop wrote: > Chuck > > Thank you for the parallel port suggestion. I followed it up by opening the D-25 and reviewing the wiring. It looks very RS232 to me, the pin out I found is detailed in my 10 1314A Apr 22. That the punch and reader respond to RS232 input I think settles the issue - I was briefly optimistic ... No, not parallel port, but 20 ma current loop. Used extensively in teletype/industrial work. Still serial, but suited to long-haul or noisy environments. The original IBM PC serial card could be configured for CL. The advantage is that it's not voltage-sensitive per se, but rather to the current flowing through the loop. On long hauls, one could raise the voltage until the proper current level was obtained. RS232C, on the other hand is strictly voltage-sensitive. https://en.wikipedia.org/wiki/Current_loop for details. But it sounds as if you have a bog-standard RS232C setup. Very old teletype setups used, I believe 60 ma. CL. --Chuck From mjd.bishop at emeritus-solutions.com Sun Apr 10 16:55:39 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Sun, 10 Apr 2022 21:55:39 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <3eb9a64465ab4fc9ae8f9e7b33a6934d@WINHEXBEEU125.win.mail> <8bf9c84a1c2e4ce2b76ee861bbab10d0@WINHEXBEEU125.win.mail> <66b1b3e533334211a5b54c94030f8e72@WINHEXBEEU125.win.mail> Message-ID: <7c4ea94b433b46b4a3dd8818c47de1e0@WINHEXBEEU125.win.mail> Eric Thanks for the link and insight. $11, $12, $13, $14 $1B, $93 - preface with $1B (esc) and all should be well. Martin From: Eric Moore [mailto:mooreericnyc at gmail.com] Sent: 10 April 2022 20:23 To: Martin Bishop Cc: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working Yep! You can absolutely punch straight binary to tape. There is an escape, the details escape me but are enshrined in my silly network attached paper tape program: https://github.com/emooreatx/FANUC-PPR -Eric << snip >> From ethan.dicks at gmail.com Sun Apr 10 17:05:42 2022 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Sun, 10 Apr 2022 18:05:42 -0400 Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff In-Reply-To: References: Message-ID: On Sat, Apr 9, 2022 at 3:43 PM Chris Zach via cctalk wrote: > I'm thinking about going up to VCF in Wall next weekend. 22-24 Apr, as mentioned... I should be there too. > I haven't been > to it since it was the Trenton Computer Fest (think late 1990's) Totally unrelated event. > so I'm > not sure what the protocol is on tailgating, trading stuff or whatnot. > Appears that they have a "sale room" you drop things off in with prices. > Ok.... Yes. There's a "consignment room" and you leave your stuff with labels and prices and there are volunteers staffing it to collect money and record sales, etc. There's a house cut (but I am unsure how much it is so I don't want to just guess). > Stuff I could bring to get out of my house and into the right hands: > > Big box of pdp12 schematics. This came from my olden days when I had to > turn up a pdp12 because it will not fit in a station wagon. Still it > looks like board locations and a lot of 12 stuff. Big box, heavy to > ship, easier to drive over. > > Ton of pdp8/12 IO cables. These are the black circular wire ones, I > think negibus. There's definitely some discussion going on about those. They are desired by 12-bit folks. -ethan From mloewen at cpumagic.scol.pa.us Sun Apr 10 17:46:47 2022 From: mloewen at cpumagic.scol.pa.us (Mike Loewen) Date: Sun, 10 Apr 2022 18:46:47 -0400 (EDT) Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff In-Reply-To: References: Message-ID: On Sun, 10 Apr 2022, Ethan Dicks via cctalk wrote: > On Sat, Apr 9, 2022 at 3:43 PM Chris Zach via cctalk > wrote: >> I'm thinking about going up to VCF in Wall next weekend. > > Yes. There's a "consignment room" and you leave your stuff with > labels and prices and there are volunteers staffing it to collect > money and record sales, etc. There's a house cut (but I am unsure how > much it is so I don't want to just guess). VCF takes 15% of the sale price: https://vcfed.org/events/vintage-computer-festival-east/vcf-east-consignment/ Mike Loewen mloewen at cpumagic.scol.pa.us Old Technology http://q7.neurotica.com/Oldtech/ From spectre at floodgap.com Sun Apr 10 18:31:44 2022 From: spectre at floodgap.com (Cameron Kaiser) Date: Sun, 10 Apr 2022 16:31:44 -0700 Subject: Dialcom, Telenet and The Source was Re: restoring a Silent 700 Model 765 In-Reply-To: <4c1d9e0d-4aba-df59-d24b-520e3a9225ff@floodgap.com> References: <05880e6b-299d-ccba-915c-a7aa7d49fa16@floodgap.com> <4c1d9e0d-4aba-df59-d24b-520e3a9225ff@floodgap.com> Message-ID: <859e0d9d-1f92-5825-a302-8b1dd635ef7b@floodgap.com> >>> 301 24 CONNECTED >>> DIALCOM NETWORK SYSTEM 10 >>> >> Please do scan these! It is hard as hell getting info on The Source >> and also on Dialcom! > > Yes, I definitely plan to transcribe them. There is potentially some > copyrighted material here but I think I can just excerpt that and still include > all the rest of the login process, etc. > > Still, would be nice to get the terminal itself working and see what's in the > ASR's bubble memory, assuming that's still operational, so any ideas people > have would be appreciated. > I've now transcribed the teletype transcripts and included some scans from the manual, including a nice picture from InfoWorld in 1984 of the Prime hardware. https://oldvcr.blogspot.com/2022/04/tonight-were-gonna-log-on-like-its-1979.html -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Humor is a drug which it's the fashion to abuse. -- William Gilbert -------- From cz at alembic.crystel.com Sun Apr 10 19:08:03 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Sun, 10 Apr 2022 20:08:03 -0400 Subject: Dialcom, Telenet and The Source was Re: restoring a Silent 700 Model 765 In-Reply-To: <859e0d9d-1f92-5825-a302-8b1dd635ef7b@floodgap.com> References: <05880e6b-299d-ccba-915c-a7aa7d49fa16@floodgap.com> <4c1d9e0d-4aba-df59-d24b-520e3a9225ff@floodgap.com> <859e0d9d-1f92-5825-a302-8b1dd635ef7b@floodgap.com> Message-ID: Wow. Thanks for an excellent trip down memory lane. One oddity, I think I was dialing into TYMNET as when I would call in it would say. PLEASE TYPE YOUR TERMINAL IDENTIFIER You would type "A" for ASCII. This would print very slowly, character by character at about 110 baud. I think it was for either ASCII or EBCDIC. Then you would get PLEASE LOG IN And I'd type something. Then it would say: P400 is online Please sign on. At which point you would type ID and your source username and password. Great for playing Star Trek if I recall. The version I remember would actually have the Klingon attack you even while you were typing, IE it was not a turn by turn game. Fun.... CZ On 4/10/2022 7:31 PM, Cameron Kaiser via cctalk wrote: >>>> 301 24 CONNECTED >>>> DIALCOM NETWORK SYSTEM 10 >>>> >>> Please do scan these! It is hard as hell getting info on The Source >>> and also on Dialcom! >> >> Yes, I definitely plan to transcribe them. There is potentially some >> copyrighted material here but I think I can just excerpt that and still include >> all the rest of the login process, etc. >> >> Still, would be nice to get the terminal itself working and see what's in the >> ASR's bubble memory, assuming that's still operational, so any ideas people >> have would be appreciated. >> > > I've now transcribed the teletype transcripts and included some scans from the > manual, including a nice picture from InfoWorld in 1984 of the Prime hardware. > > https://oldvcr.blogspot.com/2022/04/tonight-were-gonna-log-on-like-its-1979.html > From cclist at sydex.com Sun Apr 10 15:34:16 2022 From: cclist at sydex.com (Chuck Guzis) Date: Sun, 10 Apr 2022 13:34:16 -0700 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: <552cc88322de4f3f803d074a60940581@WINHEXBEEU125.win.mail> References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> <9fe44bf2-1dc7-4f18-c352-99bd447a6ea5@sydex.com> <273962b7718b47f8bdffe1767a576550@WINHEXBEEU125.win.mail> <552cc88322de4f3f803d074a60940581@WINHEXBEEU125.win.mail> Message-ID: On 4/10/22 12:23, Martin Bishop wrote: > Chuck > > My error, you said 20 mA current loop, I bowdlerised it as parallel port. I have a punch with a parallel interface ... I can't recollect ever using a current loop interface on equipment, although I have met many in old documents. 4 .. 20 mA current loops reporting e.g. pressure actuated potentiometers are however old friends, if that is the correct term. As you observe current loop has good noise immunity. There is a tie-in to parallel port, although somewhat tangentially. Back in the 80s and 90s, CL was promoted as a long-haul solution to (as well as other things) distant printers. In particular, I remember Inmac flogging them. --Chuck From cz at alembic.crystel.com Mon Apr 11 07:43:11 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Mon, 11 Apr 2022 08:43:11 -0400 Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff In-Reply-To: References: Message-ID: On 4/10/2022 6:05 PM, Ethan Dicks wrote: > Totally unrelated event. Ok. Does TCF still happen? > Yes. There's a "consignment room" and you leave your stuff with > labels and prices and there are volunteers staffing it to collect > money and record sales, etc. There's a house cut (but I am unsure how > much it is so I don't want to just guess). 15% sounds about Ebay amount and it's going to a good cause. I'll see about showing up late Saturday morning with some stuff. >> Big box of pdp12 schematics. This came from my olden days when I had to >> turn up a pdp12 because it will not fit in a station wagon. Still it >> looks like board locations and a lot of 12 stuff. Big box, heavy to >> ship, easier to drive over. >> >> Ton of pdp8/12 IO cables. These are the black circular wire ones, I >> think negibus. > > There's definitely some discussion going on about those. They are > desired by 12-bit folks. *nod* To me classic computer stuff falls into two categories. There is stuff that is common so you sell it for a reasonable price or trade it or whatnot on Ebay/whatever. Q bus boards, systems, normal pdp11's, stuff like that. You just either sell it on Ebay (whatever) or give it to someone for a minimal cost of shipping and handling who has a system and really needs it (think 11/24 CPU boards) Then there is the stuff that is "priceless" and goes for stupid amounts the few times they are on Ebay. This is stuff like IO cables, Perqs, old peripherals, and the like. To me these are things that can get someone with an old system up and running so they are beyond "value". Which means I give them away or trade em but only to people who can actually use them and make their old systems better. The IO cables fall into the latter category. So what's the best way to have them find a home with a person who will use them and not just another trophy in a box of parts or an exhibit in some museum? CZ From bill.gunshannon at hotmail.com Mon Apr 11 11:56:47 2022 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 11 Apr 2022 12:56:47 -0400 Subject: TRS-80 Question Message-ID: Here's one for whatever TRS-80 gurus still hang out. The Mode 4 had 64K RAM and pretended to be a Model III by loading an image of the Model III Rom and then running it. Would it be at all possible to do the same thing with an image from the Model I and thus make a Model 4 capable of running Model I programs? bill From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 12:02:07 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 11:02:07 -0600 Subject: Retro networking / WAN communities Message-ID: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> Hi, Does anyone know of any communities / mailing lists / newsgroups / et al. for retro networking / WAN technologies? I find myself interested in (at least) the following and would like to find others with similar (dis)interests to chat about things. - 10Base5 / 10Base2 / 10BaseT - ISDN - DSL / ADSL / SDSL / HDSL - T1 / E1 - ATM - Frame Relay - ARCnet - PSTN / PBX / PABX -- Grant. . . . unix || die From wrcooke at wrcooke.net Mon Apr 11 08:48:40 2022 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Mon, 11 Apr 2022 08:48:40 -0500 (CDT) Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff In-Reply-To: References: Message-ID: <129894361.417378.1649684920017@email.ionos.com> > On 04/11/2022 7:43 AM Chris Zach via cctech wrote: > > > On 4/10/2022 6:05 PM, Ethan Dicks wrote: > > Totally unrelated event. > Ok. Does TCF still happen? > > > It appears so: https://tcf-nj.org/program/ About 3 weeks ago. Will From billdegnan at gmail.com Mon Apr 11 09:26:11 2022 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 11 Apr 2022 10:26:11 -0400 Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff In-Reply-To: <129894361.417378.1649684920017@email.ionos.com> References: <129894361.417378.1649684920017@email.ionos.com> Message-ID: 2020 On Mon, Apr 11, 2022 at 9:57 AM Will Cooke via cctech wrote: > > > > > On 04/11/2022 7:43 AM Chris Zach via cctech wrote: > > > > > > On 4/10/2022 6:05 PM, Ethan Dicks wrote: > > > Totally unrelated event. > > Ok. Does TCF still happen? > > > > > > > It appears so: > https://tcf-nj.org/program/ > About 3 weeks ago. > > Will From wrcooke at wrcooke.net Mon Apr 11 09:34:13 2022 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Mon, 11 Apr 2022 09:34:13 -0500 (CDT) Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff In-Reply-To: <129894361.417378.1649684920017@email.ionos.com> References: <129894361.417378.1649684920017@email.ionos.com> Message-ID: <1363084083.423793.1649687653346@email.ionos.com> 2020: oops Here: https://tcf-nj.org/wp-content/uploads/2022/03/TCF2022-SCHEDULE-TALK-INFO-PIXs.pdf > On 04/11/2022 8:48 AM Will Cooke via cctech wrote: > > > > On 04/11/2022 7:43 AM Chris Zach via cctech wrote: > > > > > > On 4/10/2022 6:05 PM, Ethan Dicks wrote: > > > Totally unrelated event. > > Ok. Does TCF still happen? > > > > > > It appears so: > https://tcf-nj.org/program/ > About 3 weeks ago. > > Will "I was born not knowing and have had only a little time to change that here and there." Richard Feynman From billdegnan at gmail.com Mon Apr 11 12:09:25 2022 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 11 Apr 2022 13:09:25 -0400 Subject: TRS-80 Question In-Reply-To: References: Message-ID: I think there was a model 1 emulator thatwas disk driven, but I dont know if I have it myself. Maybe someone else has this? There are cassette and/or disk issues so it depends how youd loadand save programs. Bill On Mon, Apr 11, 2022, 12:56 PM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: > > Here's one for whatever TRS-80 gurus still hang out. > > The Mode 4 had 64K RAM and pretended to be a Model III by loading > an image of the Model III Rom and then running it. Would it be at > all possible to do the same thing with an image from the Model I > and thus make a Model 4 capable of running Model I programs? > > bill > From ethan at 757.org Mon Apr 11 12:12:37 2022 From: ethan at 757.org (Ethan O'Toole) Date: Mon, 11 Apr 2022 13:12:37 -0400 (EDT) Subject: Retro networking / WAN communities In-Reply-To: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> Message-ID: > Does anyone know of any communities / mailing lists / newsgroups / et al. for > retro networking / WAN technologies? > - PSTN / PBX / PABX There is a Central Office Groups.io list (which migrated from Yahoo Groups) located at https://groups.io/g/centraloffice . It is low traffic. There is a Discord server related to PBX and Telephone stuff, but will have to dig up that info later. It's pretty low traffic as well. - Ethan -- : Ethan O'Toole From paulkoning at comcast.net Mon Apr 11 12:27:45 2022 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 11 Apr 2022 13:27:45 -0400 Subject: Retro networking / WAN communities In-Reply-To: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> Message-ID: <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> > On Apr 11, 2022, at 1:02 PM, Grant Taylor via cctalk wrote: > > Hi, > > Does anyone know of any communities / mailing lists / newsgroups / et al. for retro networking / WAN technologies? > > I find myself interested in (at least) the following and would like to find others with similar (dis)interests to chat about things. > > - 10Base5 / 10Base2 / 10BaseT > - ISDN > - DSL / ADSL / SDSL / HDSL > - T1 / E1 > - ATM > - Frame Relay > - ARCnet > - PSTN / PBX / PABX I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). And I did ATM for a living for about 5 years, back around 1995, so I can still talk a bit of that. Hey, you didn't mention FDDI. :-) paul From ethan.dicks at gmail.com Mon Apr 11 12:37:06 2022 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 11 Apr 2022 13:37:06 -0400 Subject: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff In-Reply-To: References: Message-ID: On Mon, Apr 11, 2022 at 8:43 AM Chris Zach wrote: > On 4/10/2022 6:05 PM, Ethan Dicks wrote: > >> Ton of pdp8/12 IO cables. These are the black circular wire ones, I > >> think negibus. > > > > There's definitely some discussion going on about those. They are > > desired by 12-bit folks. > > *nod* To me classic computer stuff falls into two categories. There is > stuff that is common so you sell it for a reasonable price or trade it > or whatnot on Ebay/whatever. Q bus boards, systems, normal pdp11's, > stuff like that. You just either sell it on Ebay (whatever) or give it > to someone for a minimal cost of shipping and handling who has a system > and really needs it (think 11/24 CPU boards) Sure. > Then there is the stuff that is "priceless" and goes for stupid amounts... Agreed. > The IO cables fall into the latter category. So what's the best way to > have them find a home with a person who will use them and not just > another trophy in a box of parts or an exhibit in some museum? Thunderdome? ;-) But seriously, probably to ask here and on the Classic Computer Discord channel (a mix of folks from here and not from here, mostly US-based) who could even use such a thing. I have a couple of Negibus machines. The only one I'm really missing cables for is a PDP-8/S, so I can connect up a PT08 once I find/fabricate one. If someone had a PDP-12 or LINC-8, that would be, to me, a higher priority need (especially since I haven't even relamped my -8/S yet). I wish I'd gotten the ASR-33 that originally came with it (since some had the PT08 in the base) but alas, that was gone before I got there. Events like VCF concentrate the interested population - I've been part of a "12-bit panel", up on stage with Kyle Owen, Jack Rubin, Vince Slyngstad, etc., exactly the sort of people who would _use_ I/O cables not flip them. Trade stuff is harder. I know you are seeking external memory boxes for the -8/L, but those are quite rare. I just have the one and it's not an extra. Any 12-bit spare parts I might have are Omnibus bits. Cheers, -ethan From dittman at dittman.net Mon Apr 11 13:09:35 2022 From: dittman at dittman.net (Eric Dittman) Date: Mon, 11 Apr 2022 13:09:35 -0500 Subject: TRS-80 Question In-Reply-To: References: Message-ID: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> On 4/11/22 11:56 AM, Bill Gunshannon via cctalk wrote: > > Here's one for whatever TRS-80 gurus still hang out. > > The Mode 4 had 64K RAM and pretended to be a Model III by loading > an image of the Model III Rom and then running it.? Would it be at > all possible to do the same thing with an image from the Model I > and thus make a Model 4 capable of running Model I programs? The Model 4 had the Model III ROM included. It was the Model 4P that had to load the Model III ROM image from disk before operating in Model III mode. There were some hardware differences between the Model I and Model III, such as the disk interface being memory-mapped in the Model I and port-mapped in the Model III, but if the Model I programs don't use anything that's different in the Model III then the Model 4 in Model III mode should be able to run them. So a game that's loaded from cassette should work but a game that runs from disk and writes to the disk won't work. -- Eric Dittman From bill.gunshannon at hotmail.com Mon Apr 11 13:33:53 2022 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 11 Apr 2022 14:33:53 -0400 Subject: TRS-80 Question In-Reply-To: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> Message-ID: On 4/11/22 14:09, Eric Dittman via cctalk wrote: > On 4/11/22 11:56 AM, Bill Gunshannon via cctalk wrote: >> >> Here's one for whatever TRS-80 gurus still hang out. >> >> The Mode 4 had 64K RAM and pretended to be a Model III by loading >> an image of the Model III Rom and then running it.? Would it be at >> all possible to do the same thing with an image from the Model I >> and thus make a Model 4 capable of running Model I programs? > > The Model 4 had the Model III ROM included.? It was the Model 4P > that had to load the Model III ROM image from disk before operating > in Model III mode. Not surprised I got that part wrong. But then, I use my 4P all the time and haven't touched a normal 4 or 3 in quite a while. > > There were some hardware differences between the Model I and Model > III, such as the disk interface being memory-mapped in the Model I > and port-mapped in the Model III, but if the Model I programs don't > use anything that's different in the Model III then the Model 4 in > Model III mode should be able to run them.? So a game that's loaded > from cassette should work but a game that runs from disk and writes > to the disk won't work. Actually, the big difference is the memory map. Most Model 1 programs load right where the top off the Model III ROM sits so they can not be used on the 3 or 4. That's why I was hoping the ROM image trick could be used. I guess it was just wishful thinking. Thanks for the info, bill From andrew at carrierdetect.com Mon Apr 11 13:25:32 2022 From: andrew at carrierdetect.com (Andrew Back) Date: Mon, 11 Apr 2022 18:25:32 +0000 Subject: Retro networking / WAN communities In-Reply-To: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> Message-ID: <26ed4987-6445-d69f-9058-06dd4eac3dd5@carrierdetect.com> On 11/04/2022 18:02, Grant Taylor via cctech wrote: > Does anyone know of any communities / mailing lists / newsgroups / et > al. for retro networking / WAN technologies? > > I find myself interested in (at least) the following and would like to > find others with similar (dis)interests to chat about things. > > - 10Base5 / 10Base2 / 10BaseT > - ISDN > - DSL / ADSL / SDSL / HDSL > - T1 / E1 > - ATM > - Frame Relay > - ARCnet > - PSTN / PBX / PABX The Osmocom community have a retro networking project, with projects including TDM over IP. https://osmocom.org/projects/retronetworking/wiki/ They have also created an open hardware USB E1 interface that can be used with the aforementioned, as well as with older GSM base stations which implement Abis over E1 (which you can then operate with the Osmocom CNI software stack). https://osmocom.org/projects/e1-t1-adapter/wiki/IcE1usb There's also Osmocom-Analog, if your interests extend to retro cellular. http://osmocom-analog.eversberg.eu/ Andrew From healyzh at avanthar.com Mon Apr 11 14:36:27 2022 From: healyzh at avanthar.com (Zane Healy) Date: Mon, 11 Apr 2022 12:36:27 -0700 Subject: Retro networking / WAN communities In-Reply-To: <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> Message-ID: > On Apr 11, 2022, at 10:27 AM, Paul Koning via cctalk wrote: > > I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). And I did ATM for a living for about 5 years, back around 1995, so I can still talk a bit of that. > > Hey, you didn't mention FDDI. :-) > > Paul Hi Paul, You?re one of the people I?d expect to be running 10Base-2 at home. I only have one 10Mbit switch still online, it?s for my DECserver 90TL, the only 10Base-2 device that I keep online (I have a couple others). All my 10Base-T devices are plugged into 1Gbit managed switches. Zane From lars at nocrew.org Mon Apr 11 14:59:13 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 11 Apr 2022 19:59:13 +0000 Subject: Retro networking / WAN communities In-Reply-To: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> (Grant Taylor via cctalk's message of "Mon, 11 Apr 2022 11:02:07 -0600") References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> Message-ID: <7w1qy3crxq.fsf@junk.nocrew.org> Grant Taylor wrote: > I find myself interested in (at least) the following and would like to > find others with similar (dis)interests to chat about things. > > - 10Base5 / 10Base2 / 10BaseT > - ISDN > - DSL / ADSL / SDSL / HDSL > - T1 / E1 > - ATM > - Frame Relay > - ARCnet > - PSTN / PBX / PABX For your consideration: - Arpanet (NCP) - Tymnet - Chaosnet - PUP - UUCP From paulkoning at comcast.net Mon Apr 11 15:58:47 2022 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 11 Apr 2022 16:58:47 -0400 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> Message-ID: <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> > On Apr 11, 2022, at 3:36 PM, Zane Healy wrote: > > > >> On Apr 11, 2022, at 10:27 AM, Paul Koning via cctalk wrote: >> >> I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). And I did ATM for a living for about 5 years, back around 1995, so I can still talk a bit of that. >> >> Hey, you didn't mention FDDI. :-) >> >> Paul > > Hi Paul, > You?re one of the people I?d expect to be running 10Base-2 at home. :-) > I only have one 10Mbit switch still online, it?s for my DECserver 90TL, the only 10Base-2 device that I keep online (I have a couple others). I don't have a 10Base2 switch, but I have an old repeater with 4-5 10BaseT ports and a 10Base2 port. And I have a 10Base2 transceiver (as well as 2 or 3 10BaseT transceiver). Good thing because the Pro has an AUI connector. > All my 10Base-T devices are plugged into 1Gbit managed switches. Same here, except unmanaged. I didn't realize until years into the 1G era that 1G is backwards compatible TWO generations, not the usual one. And the switch seems to be happy to speak 10 Mb half duplex, nice. paul From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 16:57:58 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 15:57:58 -0600 Subject: Retro networking / WAN communities In-Reply-To: <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> Message-ID: <39b2e70c-633a-e470-7b11-5cbf94196db9@spamtrap.tnetconsulting.net> On 4/11/22 11:27 AM, Paul Koning via cctalk wrote: > I still have 10 Mb Ethernet at home (on my Pro, and while it's not > in use I have a few 10Base2 bits). Please expand "my Pro". There's not much to go on. #LivingRetroVicariouslyThoughOthers > And I did ATM for a living for about 5 years, back around 1995, > so I can still talk a bit of that. I've had some ATM equipment (FORE OC3 switch & FORE OC3 / Ethernet bridge) before the pre-move-purge. I'd like to mess with ATM again. I view ATM based DSL as a way to get back into ATM. }:-) > Hey, you didn't mention FDDI. :-) I'm sorry. It slipped my mind while trying to finish the email. Rest assured that both FDDI and it's CDDI cousin are on my list of things to mess with. :-D -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 17:07:27 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 16:07:27 -0600 Subject: Retro networking / WAN communities In-Reply-To: <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> Message-ID: On 4/11/22 2:58 PM, Paul Koning via cctalk wrote: > I don't have a 10Base2 switch, but I have an old repeater with 4-5 > 10BaseT ports and a 10Base2 port. And I have a 10Base2 transceiver > (as well as 2 or 3 10BaseT transceiver). Good thing because the Pro > has an AUI connector. I have to ask ... Q1 Would you be referring a "hub"? Q2 Are your transceivers from AUI to 10Base2 / 10BaseT? Or are they something else more mid-span? Sorry if this is too pedantic. But I do feel like the pedantry is somewhat warranted for this list. > Same here, except unmanaged. I didn't realize until years into the 1G > era that 1G is backwards compatible TWO generations, not the usual one. > And the switch seems to be happy to speak 10 Mb half duplex, nice. I'm running into issues with switches not supporting 10 / 100 Mbps management interfaces for other equipment. -- Grant. . . . unix || die From spectre at floodgap.com Mon Apr 11 17:18:35 2022 From: spectre at floodgap.com (Cameron Kaiser) Date: Mon, 11 Apr 2022 15:18:35 -0700 Subject: Retro networking / WAN communities In-Reply-To: <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> Message-ID: <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> > I don't have a 10Base2 switch, Were there ever actual true 10b2 switches? I've only ever seen them as hubs, and I haven't seen a 10bT switch that had a 10b2 port (all the 10bT devices I have with 10b2 ports are hubs). I just have one 10b2 system now, the VAXstation 3100 M76 (previously the HP 9000/350 was 10b2, but I replaced its IO board with a later one with an AUI port: http://oldvcr.blogspot.com/2021/04/refurb-weekend-hewlett-packard-9000350.html ). -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Proponents of other opinions will be merrily beaten to a bloody pulp. ------ From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 17:35:33 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 16:35:33 -0600 Subject: Retro networking / WAN communities In-Reply-To: <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> Message-ID: <055fe541-ec95-cbd7-3389-d59333d91c17@spamtrap.tnetconsulting.net> On 4/11/22 4:18 PM, Cameron Kaiser via cctalk wrote: > Were there ever actual true 10b2 switches? I've seen 10Base-T versions of -- what I would call -- bridges in box for sale. I've seen /many/ different software products that could be installed on computers with supported interfaces to be bridges. You could easily have 10Base2 / 10Base5 in those. IMHO an unmanaged switch is an evolution of a bridge. Or in the past, I used to say (a very long time ago) a switch was was three or more ports and a bridge was exactly two ports. -- Probably inaccurate in some way. But it worked for the conversation at the time. > I've only ever seen them as hubs, and I haven't seen a 10bT switch that > had a 10b2 port (all the 10bT devices I have with 10b2 ports are hubs). I /want/ to say that I've seen a switch with AUI or BNC connectors on it. But I can't remember any off hand. Maybe something modular that has optional add-in cards. But I can't think of any fixed configuration switches with AUI / BNC. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 17:39:53 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 16:39:53 -0600 Subject: Retro networking / WAN communities In-Reply-To: <7w1qy3crxq.fsf@junk.nocrew.org> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> Message-ID: <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> On 4/11/22 1:59 PM, Lars Brinkhoff via cctalk wrote: > For your consideration: > > - Arpanet (NCP) Is that "NCP" the same NCP that's in ancient BSDs? Or is it a term collision? > - Tymnet I think of Tymnet as a service and not as much as a protocol. Though maybe it implies a protocol and I'm unaware of it. > - Chaosnet Ya. Isn't Chaosnet mostly used in LISP machines? -- This seems fairly far afield for my interest. > - PUP Maybe. It also seems fairly afar afield for what I can get my hands on and / or emulate. > - UUCP There. Ding that. I'm even pontificating a custom UUCP configuration that is specific to my user. As in /not/ a system wide version. -- Grant. . . . unix || die From spectre at floodgap.com Mon Apr 11 17:39:53 2022 From: spectre at floodgap.com (Cameron Kaiser) Date: Mon, 11 Apr 2022 15:39:53 -0700 Subject: Retro networking / WAN communities In-Reply-To: <7w1qy3crxq.fsf@junk.nocrew.org> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> Message-ID: <82935f1e-5d5d-8b46-2a88-05caccd1c1e7@floodgap.com> >> I find myself interested in (at least) the following and would like to >> find others with similar (dis)interests to chat about things. >> >> - 10Base5 / 10Base2 / 10BaseT >> - ISDN >> - DSL / ADSL / SDSL / HDSL >> - T1 / E1 >> - ATM >> - Frame Relay >> - ARCnet >> - PSTN / PBX / PABX > > For your consideration: > > - Arpanet (NCP) > - Tymnet > - Chaosnet > - PUP > - UUCP If we're going to do Tymnet, we should definitely do Telenet. I'll also throw in SLIP, since I imagine most remote access nowadays is all PPP, and maybe even old school EtherTalk or LocalTalk. I had a T1 locally up until a couple months ago. I still have the smartjack and the wiring, but DSLX wouldn't support it anymore. They just left the T1 routers, too. They're embedded PowerPC systems I should figure out something fun to do with. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- MOVIE IDEA: The Never-Ending E-mail Signature ------------------------------ From imp at bsdimp.com Mon Apr 11 17:47:27 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 11 Apr 2022 16:47:27 -0600 Subject: Retro networking / WAN communities In-Reply-To: <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> Message-ID: On Mon, Apr 11, 2022, 4:39 PM Grant Taylor via cctalk wrote: > On 4/11/22 1:59 PM, Lars Brinkhoff via cctalk wrote: > > For your consideration: > > > > - Arpanet (NCP) > > Is that "NCP" the same NCP that's in ancient BSDs? Or is it a term > collision? > NCP was the forerunner of TCP/IP. Net Unix had it as its supported protocol and that was old enough that BSD had at least one implementation. Warner > - Tymnet > > I think of Tymnet as a service and not as much as a protocol. Though > maybe it implies a protocol and I'm unaware of it. > > > - Chaosnet > > Ya. Isn't Chaosnet mostly used in LISP machines? -- This seems fairly > far afield for my interest. > > > - PUP > > Maybe. It also seems fairly afar afield for what I can get my hands on > and / or emulate. > > > - UUCP > > There. Ding that. > > I'm even pontificating a custom UUCP configuration that is specific to > my user. As in /not/ a system wide version. > > > > -- > Grant. . . . > unix || die > From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 17:51:19 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 16:51:19 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> Message-ID: <12f88c6a-41d3-0679-3532-005ba97582b1@spamtrap.tnetconsulting.net> On 4/11/22 4:47 PM, Warner Losh via cctalk wrote: > NCP was the forerunner of TCP/IP. Net Unix had it as its supported > protocol and that was old enough that BSD had at least one > implementation. Thank you for confirmation of what I thought might be the case Warner. I've thought about messing with NCP on emulated VAXen in the past. I'm sure I'll consider such in the future. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 17:55:46 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 16:55:46 -0600 Subject: Retro networking / WAN communities In-Reply-To: <82935f1e-5d5d-8b46-2a88-05caccd1c1e7@floodgap.com> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <82935f1e-5d5d-8b46-2a88-05caccd1c1e7@floodgap.com> Message-ID: <5f7b066f-201f-f50f-e5c6-b6e49c3199a2@spamtrap.tnetconsulting.net> On 4/11/22 4:39 PM, Cameron Kaiser via cctalk wrote: > I'll also throw in SLIP, since I imagine most remote access nowadays > is all PPP, If you're adding SLIP, I'm going to add PLIP. > and maybe even old school EtherTalk or LocalTalk. Oh wow. Ya. That's more easily done / emulated on many systems. > I had a T1 locally up until a couple months ago. I still have the > smartjack and the wiring, but DSLX wouldn't support it anymore. They > just left the T1 routers, too. They're embedded PowerPC systems I > should figure out something fun to do with. If you're looking to move them. Send me an email. I've recently acquired things to do T1 / DSX-1 between multiple machines at home. I'd /like/ to do the TelCo side of that too, for at least one loop. But it seems as if the equipment to do that is even more specialized. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 17:58:31 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 16:58:31 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> Message-ID: On 4/11/22 11:12 AM, Ethan O'Toole via cctalk wrote: > There is a Central Office Groups.io list (which migrated from Yahoo > Groups) located at https://groups.io/g/centraloffice . It is low traffic. I've sent a subscribe request. > There is a Discord server related to PBX and Telephone stuff, but will > have to dig up that info later. It's pretty low traffic as well. I'd be curious to see the info at your convenience. Thank you for the pointers Ethan. -- Grant. . . . unix || die From healyzh at avanthar.com Mon Apr 11 18:30:23 2022 From: healyzh at avanthar.com (Zane Healy) Date: Mon, 11 Apr 2022 16:30:23 -0700 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> Message-ID: On Apr 11, 2022, at 12:36 PM, Zane Healy via cctalk wrote: > > You?re one of the people I?d expect to be running 10Base-2 at home. I only have one 10Mbit switch still online, it?s for my DECserver 90TL, the only 10Base-2 device that I keep online (I have a couple others). A correction here, I?m talking about a 10Base-T hub with a 10Base-2 connector, not a 10Mbit switch. I?m too used to using switches. I do have a 10Base-T to 10Base-2 media converter that I spent a **** of a lot money on, before I realized I simply needed a cheap 10Base-T switch with a 10Base-2 connector. The media converter is my backup plan if the hub dies. If the DECserver dies, I?m in trouble. Zane From paulkoning at comcast.net Mon Apr 11 19:09:52 2022 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 11 Apr 2022 20:09:52 -0400 Subject: Retro networking / WAN communities In-Reply-To: <39b2e70c-633a-e470-7b11-5cbf94196db9@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <39b2e70c-633a-e470-7b11-5cbf94196db9@spamtrap.tnetconsulting.net> Message-ID: <9B0389AF-AD34-4D7E-811C-8EBBCFD66762@comcast.net> > On Apr 11, 2022, at 5:57 PM, Grant Taylor via cctalk wrote: > > On 4/11/22 11:27 AM, Paul Koning via cctalk wrote: >> I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). > > Please expand "my Pro". There's not much to go on. #LivingRetroVicariouslyThoughOthers DEC Professional 380 (and a caseless 350) -- PDP-11s with a screwball bus and their own set of peripherals. I have an Ethernet card for one of them. Working on the driver. paul From spectre at floodgap.com Mon Apr 11 19:16:29 2022 From: spectre at floodgap.com (Cameron Kaiser) Date: Mon, 11 Apr 2022 17:16:29 -0700 Subject: Retro networking / WAN communities In-Reply-To: <9B0389AF-AD34-4D7E-811C-8EBBCFD66762@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <39b2e70c-633a-e470-7b11-5cbf94196db9@spamtrap.tnetconsulting.net> <9B0389AF-AD34-4D7E-811C-8EBBCFD66762@comcast.net> Message-ID: >>> I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). >> Please expand "my Pro". There's not much to go on. #LivingRetroVicariouslyThoughOthers > DEC Professional 380 (and a caseless 350) -- PDP-11s with a screwball bus and their own set of peripherals. I have an Ethernet card for one of them. Working on the driver. I'd love Ethernet to work in Venix/PRO but I think my 380 is just going to have to do some user-level SLIP driver. I suppose that's something I could write up for gits and shiggles. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Maybe this world is another planet's hell. -- Aldous Huxley ---------------- From paulkoning at comcast.net Mon Apr 11 19:16:48 2022 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 11 Apr 2022 20:16:48 -0400 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> Message-ID: <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> > On Apr 11, 2022, at 6:07 PM, Grant Taylor via cctalk wrote: > > On 4/11/22 2:58 PM, Paul Koning via cctalk wrote: >> I don't have a 10Base2 switch, but I have an old repeater with 4-5 10BaseT ports and a 10Base2 port. And I have a 10Base2 transceiver (as well as 2 or 3 10BaseT transceiver). Good thing because the Pro has an AUI connector. > > I have to ask ... > > Q1 Would you be referring a "hub"? I think "hub" is another word for "repeater" (just like "switch" is another word for "bridge"). The device I have is a small standalone box, about the size of today's small 4-6 port switches you buy at Staples for $100. But it's actually a repeater, not a switch, and one of its ports is a 10Base2 connector (BNC jack). > Q2 Are your transceivers from AUI to 10Base2 / 10BaseT? Or are they something else more mid-span? AUI connector, yes. Two are little boxes about the size of the connector body but maybe 2-3 inches long, with the coax or RJ45 connector at the other end. The 10BaseT is a DEC product, the 10Base2 I don't remember. I also have an ancient 10BaseT transceiver that's about twice as big, with a jack for an external power source, forgot the maker of that one. > Sorry if this is too pedantic. But I do feel like the pedantry is somewhat warranted for this list. You won't get an argument from me on that one... :-) >> Same here, except unmanaged. I didn't realize until years into the 1G era that 1G is backwards compatible TWO generations, not the usual one. And the switch seems to be happy to speak 10 Mb half duplex, nice. > > I'm running into issues with switches not supporting 10 / 100 Mbps management interfaces for other equipment. That's rather odd because even if someone doesn't obey the letter of the law you'd think they would at least support 100BaseT. Or was the problem lack of half duplex? Do those management interfaces want to run half duplex? I think I saw in the standard that Gigabit Ethernet in theory includes a half duplex mode, but I have never seen anyone use it and I wonder if it would work if tried. Perhaps I misread things. paul From paulkoning at comcast.net Mon Apr 11 19:33:33 2022 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 11 Apr 2022 20:33:33 -0400 Subject: Retro networking / WAN communities In-Reply-To: <055fe541-ec95-cbd7-3389-d59333d91c17@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> <055fe541-ec95-cbd7-3389-d59333d91c17@spamtrap.tnetconsulting.net> Message-ID: > On Apr 11, 2022, at 6:35 PM, Grant Taylor via cctalk wrote: > > On 4/11/22 4:18 PM, Cameron Kaiser via cctalk wrote: >> Were there ever actual true 10b2 switches? DECbridge-90: AUI or 10Base2 to 10Base2. > ... > IMHO an unmanaged switch is an evolution of a bridge. Or in the past, I used to say (a very long time ago) a switch was was three or more ports and a bridge was exactly two ports. -- Probably inaccurate in some way. But it worked for the conversation at the time. That's not accurate. "Switch" is a marketing term invented by certain companies that wanted to pretend their products were different from (and better than) other people's bridges. It never was true that bridges are specifically two port devices. Yes, the very first few models (DEC's DECbridge-100 for example) were two port devices, as was one whose manufacturer I no longer remember that bridged Ethernet over a satellite link (InterLAN?). But the standard never assumed that, neither the original DEC one nor its later 802.1d derivative. To pick one example, the DECbridge-500 is a four port bridge: FDDI to 3 Ethernets. The DECbridge-900 is a 7 port bridge: FDDI to 6 Ethernets. Neither, at the time when DEC introduced them, were called or described as anything other than bridges. The marketeers who flogged the other term also tried to use it to claim it referred to other supposed improvement, like cut-through operation. That was an oddball notion that never made much sense but some people seemed to like doing it in the 10 Mb and 100 Mb era. Of course it doesn't work for any mixed media, and at higher speeds the difficulty goes up while the benefits, if they ever were meaningful in the first place, shrink to microscopic values. For sure it hasn't been heard of in quite a while. I forgot the name of the company, mid 1980s I think, that made a big fuss over "cut through" and I think may also have been the inventer of the term "switch". Cisco bought them at some point. Also: neither "bridge" nor "switch" by itself implies either managed or unmanaged. I think DEC bridges were generally unmanaged, though that was mostly because no management standards existed yet. I wasn't around when SNMP became a big deal so I don't know if DEC adopted it when that happened. paul From paulkoning at comcast.net Mon Apr 11 19:38:21 2022 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 11 Apr 2022 20:38:21 -0400 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <39b2e70c-633a-e470-7b11-5cbf94196db9@spamtrap.tnetconsulting.net> <9B0389AF-AD34-4D7E-811C-8EBBCFD66762@comcast.net> Message-ID: > On Apr 11, 2022, at 8:16 PM, Cameron Kaiser via cctalk wrote: > >>>> I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). >>> Please expand "my Pro". There's not much to go on. #LivingRetroVicariouslyThoughOthers >> DEC Professional 380 (and a caseless 350) -- PDP-11s with a screwball bus and their own set of peripherals. I have an Ethernet card for one of them. Working on the driver. > > I'd love Ethernet to work in Venix/PRO but I think my 380 is just going to have > to do some user-level SLIP driver. I suppose that's something I could write up > for gits and shiggles. Perhaps you could adapt the Linux or NetBSD driver for the 82586. I'm not sure the NetBSD one is complete but the Linux one (sun3-82586.c) looks plausible. You'll also need to study the CNA chapter of the Pro technical manual (on Bitsavers) since the board includes some additional control logic as well as the packet memory that the chip talks to. And of course, you'll get to discover all over again that Intel never could design Ethernet chips for beans; the 586 is an especially ugly example of architural absurdity, with its linked list of descriptors that introduce lots of bad race conditions between the CPU and I/O device. (The depressing thing is that Dijkstra figured out and documented how to do this right 20 years earlier.) paul From dittman at dittman.net Mon Apr 11 21:37:28 2022 From: dittman at dittman.net (Eric Dittman) Date: Mon, 11 Apr 2022 21:37:28 -0500 Subject: TRS-80 Question In-Reply-To: References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> Message-ID: <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> On 4/11/22 1:33 PM, Bill Gunshannon via cctalk wrote: > On 4/11/22 14:09, Eric Dittman via cctalk wrote: >> On 4/11/22 11:56 AM, Bill Gunshannon via cctalk wrote: >>> >>> Here's one for whatever TRS-80 gurus still hang out. >>> >>> The Mode 4 had 64K RAM and pretended to be a Model III by loading >>> an image of the Model III Rom and then running it.? Would it be at >>> all possible to do the same thing with an image from the Model I >>> and thus make a Model 4 capable of running Model I programs? >> >> The Model 4 had the Model III ROM included.? It was the Model 4P >> that had to load the Model III ROM image from disk before operating >> in Model III mode. > > Not surprised I got that part wrong.? But then, I use my 4P all the > time and haven't touched a normal 4 or 3 in quite a while. > >> >> There were some hardware differences between the Model I and Model >> III, such as the disk interface being memory-mapped in the Model I >> and port-mapped in the Model III, but if the Model I programs don't >> use anything that's different in the Model III then the Model 4 in >> Model III mode should be able to run them.? So a game that's loaded >> from cassette should work but a game that runs from disk and writes >> to the disk won't work. > > Actually, the big difference is the memory map.? Most Model 1 > programs load right where the top off the Model III ROM sits > so they can not be used on the 3 or 4.? That's why I was hoping > the ROM image trick could be used.? I guess it was just wishful > thinking. Thanks for the info, There's a 2K hole in the Model I memory map above the ROM, this space is used by the Model III ROM (12K ROM on the Model I, 14K on the Model III). After that you have memory-mapped I/O on the Model I. Both of them then have the keyboard mapped at 3800H and the video at 3C00H. RAM starts at 4000H on both of them. How the first section of RAM is used depend on whether you are using disk or cassette and if you are using disk then which OS you use. There's a good breakdown of how the RAM is used here: https://www.trs-80.com/wordpress/zaps-patches-pokes-tips/ram-addresses-and-routines/ -- Eric Dittman From ard.p850ug1 at gmail.com Mon Apr 11 22:55:07 2022 From: ard.p850ug1 at gmail.com (Tony Duell) Date: Tue, 12 Apr 2022 04:55:07 +0100 Subject: Retro networking / WAN communities In-Reply-To: <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> Message-ID: On Mon, Apr 11, 2022 at 11:18 PM Cameron Kaiser via cctalk wrote: > > > I don't have a 10Base2 switch, > Were there ever actual true 10b2 switches? I've only ever seen them as hubs, > and I haven't seen a 10bT switch that had a 10b2 port (all the 10bT devices I > have with 10b2 ports are hubs). > I am not sure what the actual distinction is, but a 'managed bridge' turned up at the local antique market (!) some weeks back. It has a pair of AUI ports and from the amount of logic/processor power inside it does a lot more than just pass packets from one port to the other, The main board contains a pair of ethernet interfaces (AM7990 based), a 68020 processor, ROM, RAM, etc. A board on top of of it called the 'FLUT' (Frame Look Up Table?) contains a CY7C901 (16 bit slice ALU -- think of it as 4 off 2901 + carry loglc), a 29C10 seqencer, etc After removing the leaking NiCd from the mainboard and repairing the corroded tracks it powers up and passes the self-tests. No idea what I'll use it for, but... -tony From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 23:42:22 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 22:42:22 -0600 Subject: Retro networking / WAN communities In-Reply-To: <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> Message-ID: <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> On 4/11/22 6:16 PM, Paul Koning wrote: > I think "hub" is another word for "repeater" (just like "switch" is > another word for "bridge"). Interesting. Do you know of any documentation, preferably not marketing materials, that used "repeater" in lieu of "hub"? From my naive point of view, hubs came about when multiple stations connected to a central location, the center, or hub, of the start if you will. Conversely, I remember reading (after the fact) about repeaters as something that existed in pure 10Base5 / 10Base2 networks, predating hubs. I'm questioning form a place of ignorance. Like a child asking why fire is hot. I think there is a large, > 80%, overlap between switch and bridge, but they aren't perfect. Bridging some traffic between otherwise incompatible networks comes to mind; e.g. SNAP between Token Ring and Ethernet or Ethernet to xDSL (RFC 1483). > The device I have is a small standalone box, about the size of today's > small 4-6 port switches you buy at Staples for $100. But it's actually > a repeater, not a switch, and one of its ports is a 10Base2 connector > (BNC jack). I would firmly consider what you describe as a "hub". > AUI connector, yes. Two are little boxes about the size of the > connector body but maybe 2-3 inches long, with the coax or RJ45 > connector at the other end. The 10BaseT is a DEC product, the 10Base2 > I don't remember. I also have an ancient 10BaseT transceiver that's > about twice as big, with a jack for an external power source, forgot > the maker of that one. *nod*nod* I have had many such things various times in the past. I recently unboxed one that's (from memory) < 2" x < 3" x < 1", with AUI on one side and 10Base-T on the other side. > You won't get an argument from me on that one... :-) :-D > That's rather odd because even if someone doesn't obey the letter of > the law you'd think they would at least support 100BaseT. Or was the > problem lack of half duplex? Do those management interfaces want to > run half duplex? No. It's more nefarious than that. You mentioned supporting n - 1 generation. I'm talking about switches that support 1 Gbps / 10 Gbps / 25 Gbps / 40 Gbps / 50 Gbps / 100 Gbps. They quite simply don't scale down to 100 Mbps much less 10 Mbps. -- Why would someone want to support those slow speed connections on such a high speed switch? Devices like intelligent power strips or serial consoles or the likes in a cabinet that uses said switch as a Top of Rack device. -- Our reluctant solution has been to put in a lower end / un-manged 10 Mbps / 100 Mbps / 1 Gbps that can link at 1 Gbps to the main ToR. > I think I saw in the standard that Gigabit Ethernet in theory includes > a half duplex mode, but I have never seen anyone use it and I wonder > if it would work if tried. Perhaps I misread things. My understanding is that Gigabit Ethernet (and beyond) only supports full duplex. Maybe I'm mis-remembering or thinking about what is actually produced vs theoretical / lab experiments. Similarly, I know someone that has 100 Mbps Token Ring, a.k.a. High Speed Token Ring (HSTR) equipment for their mainframe. And 1 Gigabit Token Ring was designed in the lab but never actualized. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 23:52:35 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 22:52:35 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> <055fe541-ec95-cbd7-3389-d59333d91c17@spamtrap.tnetconsulting.net> Message-ID: <1adbbf7d-f023-b276-9a35-e071085a4988@spamtrap.tnetconsulting.net> On 4/11/22 6:33 PM, Paul Koning wrote: > DECbridge-90: AUI or 10Base2 to 10Base2. Interesting. > That's not accurate. > > "Switch" is a marketing term invented by certain companies that > wanted to pretend their products were different from (and better than) > other people's bridges. > > It never was true that bridges are specifically two port devices. Yes, > the very first few models (DEC's DECbridge-100 for example) were two > port devices, as was one whose manufacturer I no longer remember that > bridged Ethernet over a satellite link (InterLAN?). But the standard > never assumed that, neither the original DEC one nor its later 802.1d > derivative. To pick one example, the DECbridge-500 is a four port > bridge: FDDI to 3 Ethernets. The DECbridge-900 is a 7 port bridge: > FDDI to 6 Ethernets. Neither, at the time when DEC introduced them, > were called or described as anything other than bridges. Today I learned. > The marketeers who flogged the other term also tried to use it to claim > it referred to other supposed improvement, like cut-through operation. > That was an oddball notion that never made much sense but some people > seemed to like doing it in the 10 Mb and 100 Mb era. Of course it > doesn't work for any mixed media, and at higher speeds the difficulty > goes up while the benefits, if they ever were meaningful in the first > place, shrink to microscopic values. For sure it hasn't been heard of > in quite a while. I forgot the name of the company, mid 1980s I think, > that made a big fuss over "cut through" and I think may also have been > the inventer of the term "switch". Cisco bought them at some point. I vaguely remember that there were three main forms of switching: store and forward, cut-through, and a hybrid of the two. My understanding is that S&F had the ability to sanity check (checksum?) frames and only re-send out valid / non-corrupted frames. Conversely C.T. could not do this sanity checking and thus could re-send corrupted frames. The 3rd form did a sanity check on the first part of the frame. -- I think. I vaguely remember this as a past tense discussion topic at the turn of the century. I've heard exceedingly little about it since. > Also: neither "bridge" nor "switch" by itself implies either managed > or unmanaged. I think that /just/ "switch" without any other qualification implies an unmanaged layer 2 device. Anything operating above layer 2 will inherently /require/ some configuration thus management. Yes, layer 3 switches are a thing. Yes, routers, nominally layer 3 devices, can be configured to perform unmanaged layer 2 switching. > I think DEC bridges were generally unmanaged, though that was mostly > because no management standards existed yet. I wasn't around when SNMP > became a big deal so I don't know if DEC adopted it when that happened. I'm not even going as far as what management protocol is used. I'm including even something that has lowly stand alone serial interface for console / dumb terminal (emulator) based configuration through some interface. No remote management / protocol required. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Mon Apr 11 23:56:20 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 11 Apr 2022 22:56:20 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> Message-ID: On 4/11/22 9:55 PM, Tony Duell via cctalk wrote: > I am not sure what the actual distinction is, but a 'managed bridge' > turned up at the local antique market (!) some weeks back. It has a > pair of AUI ports and from the amount of logic/processor power inside > it does a lot more than just pass packets from one port to the other, Would you be willing to share pictures? > The main board contains a pair of ethernet interfaces (AM7990 based), > a 68020 processor, ROM, RAM, etc. A board on top of of it called the > 'FLUT' (Frame Look Up Table?) contains a CY7C901 (16 bit slice ALU -- > think of it as 4 off 2901 + carry loglc), a 29C10 seqencer, etc Hum.... > After removing the leaking NiCd from the mainboard and repairing the > corroded tracks it powers up and passes the self-tests. No idea what > I'll use it for, but... That seems like it would be an interesting piece of networking history to own. If you're into that sort of thing. ;-) -- Grant. . . . unix || die From Tim at Rikers.org Mon Apr 11 21:12:11 2022 From: Tim at Rikers.org (Tim Riker) Date: Mon, 11 Apr 2022 20:12:11 -0600 Subject: FYI: NDWiki - planned downtime In-Reply-To: References: Message-ID: <41fa8378-25f8-2c9d-91bc-f88945c309d1@Rikers.org> Might want to take this opportunity to upgrade MediaWiki. The site is running 1.26.4 and current LTS release is 1.35.6 and current stable is 1.37.2. 1.26.x dropped support back in 2017. On 9/10/2021 10:34 AM, Torfinn Ingolfsen via cctech wrote: > Bitraf[1] is moving, and the NDwiki[2] server moves with it. The move > starts Saturday September 11th 2021 at 12:00 hours local time, and is > expected to be completed sometime before midnight. > > References: > 1) https://bitraf.no/ > 2) http://www.ndwiki.org/ From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 01:08:22 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 00:08:22 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> Message-ID: <2ca31874-6f0b-5df3-1cee-82235ca91ce8@spamtrap.tnetconsulting.net> On 4/11/22 11:38 PM, Wayne S wrote: > In the beginning there was thick ethernet limited to 100 m. Um.... I *REALLY* thought the 5 & 2 in 10Base5 and 10Base2 was the number of hundreds of meters that the cable segment could exist on it's own. My understanding is that the 100 meter limit came about with 10Base-T. > People wanted computers that were on different floors connected > together between floors and buildings. That exceeded the 100 meter > spec so the repeater was born to connect two 100 m thick ethernet > seqments. I feel like even only 100 meters / 300(+) feet gives quite a bit of flexibility to connect multiple floors. Especially if you consider the AUI drop cable. Aside: I'm not sure how long an AUI drop cable could be. I'm anticipating between single and low double digit feet. > A repeater was basically a signal booster between two ethernet > segments. As you added segments interference and collisions became a > problem as traffic on one segment was passed to all the other connected > segments. Yep, the 3, 4, 5, rule. Up to five segments of cable with four repeaters and stations on no more than three of the segments. > Hence the bridge was born. It had some intelligence And didn?t > pass packets intended for computers on its own segment to the other > segments thereby reducing congestion and collisions. Didn't repeaters operate in the analog domain? Meaning that they would also repeat ~> amplify any noise / distortion too? Conversely bridges operated in the digital domain. Meaning that they received an Ethernet frame and then re-generated and transmitted a new pristine Ethernet frame? > Then the router was born to connect multiple segments together > at one point. And it had intelligence to determine what segment a > packet should go to and route it there. It also prevented packets > from going onto segments that didn?t have the packet?s intended > target thereby reducing congestion. I would say "network" as opposed to "segment" because a network could consist of multiple segments. But otherwise I agree. > Hubs were born approximately the same time to get over the ethernet > tap distance because by this time there were more computers in the > single area that needed to be connected together to the Ethernet. Hum.... I can see problems with having enough actual taps on a network segment to connect all the machines in a given area with AUI drop cable length issues. But I know that multi-port taps were a thing. I've read about them and seen pictures of them for sale. I think I've read about a singular tap that had eight AUI ports on it. I've seen pictures of four AUI ports on a single tap. So ... the idea of having too many multi-port taps to be able to connect machines in proximity seems ... questionable to me. Single port taps, maybe. > Hubs were dumb so every packet that hit them was forwarded to every > other computer connected to the hub into the segment the hub was > connected to, so, for a segment that had a lot of computers, there > was congestion and collisions. I feel like a hub is the 10Base-T evolution of a multi-AUI port tap. > The switch came about. It was a smart hub that had intelligence. It > could filter out packets that were not intended for other computers > connected to it thereby reducing congestion. I feel like the switch and the bridge are doing the same thing from a learning / forwarding / blocking perspective. I don't know which came first, but I suspect it was bridges. > So each device was really an evolution to solve a problem of congestion > and ethernet length. Sure. -- Grant. . . . unix || die From lars at nocrew.org Tue Apr 12 01:21:31 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 12 Apr 2022 06:21:31 +0000 Subject: Retro networking / WAN communities In-Reply-To: (Warner Losh via cctalk's message of "Mon, 11 Apr 2022 16:47:27 -0600") References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> Message-ID: <7wtuaybz4k.fsf@junk.nocrew.org> Warner Losh wrote: > NCP was the forerunner of TCP/IP. Net Unix had it as its supported > protocol and that was old enough that BSD had at least one > implementation. Are you saying there's a BSD Unix with Arpanet NCP? If so, where? From lars at nocrew.org Tue Apr 12 01:23:33 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 12 Apr 2022 06:23:33 +0000 Subject: Retro networking / WAN communities In-Reply-To: <82935f1e-5d5d-8b46-2a88-05caccd1c1e7@floodgap.com> (Cameron Kaiser via cctalk's message of "Mon, 11 Apr 2022 15:39:53 -0700") References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <82935f1e-5d5d-8b46-2a88-05caccd1c1e7@floodgap.com> Message-ID: <7wpmlmbz16.fsf@junk.nocrew.org> Cameron Kaiser wrote: > If we're going to do Tymnet, we should definitely do Telenet. Telenet is BBN's commercial network based on their IMP technology, right? How would you go about making a Telenet network? From lars at nocrew.org Tue Apr 12 01:30:36 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 12 Apr 2022 06:30:36 +0000 Subject: Retro networking / WAN communities In-Reply-To: <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> (Grant Taylor via cctalk's message of "Mon, 11 Apr 2022 16:39:53 -0600") References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> Message-ID: <7wlewabypf.fsf@junk.nocrew.org> Grant Taylor wrote: > I think of Tymnet as a service and not as much as a protocol. Though > maybe it implies a protocol and I'm unaware of it. Tymshare was a service, but the computers talked to each over over a vast network. The network was spun off as a separate business. There is code available for the SDS 940, Tymeshare's TYMCOM-X, and TENEX. > Isn't Chaosnet mostly used in LISP machines? Yes, but also all over the MIT campus really. There is Chaosnet for 4.1BSD, if that's your thing. Also various PDP-10 systems: ITS, TOPS-20, TENEX. From bill.gunshannon at hotmail.com Tue Apr 12 06:37:27 2022 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Tue, 12 Apr 2022 07:37:27 -0400 Subject: TRS-80 Question In-Reply-To: <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> Message-ID: On 4/11/22 22:37, Eric Dittman via cctalk wrote: > On 4/11/22 1:33 PM, Bill Gunshannon via cctalk wrote: >> On 4/11/22 14:09, Eric Dittman via cctalk wrote: >>> On 4/11/22 11:56 AM, Bill Gunshannon via cctalk wrote: >>>> >>>> Here's one for whatever TRS-80 gurus still hang out. >>>> >>>> The Mode 4 had 64K RAM and pretended to be a Model III by loading >>>> an image of the Model III Rom and then running it.? Would it be at >>>> all possible to do the same thing with an image from the Model I >>>> and thus make a Model 4 capable of running Model I programs? >>> >>> The Model 4 had the Model III ROM included.? It was the Model 4P >>> that had to load the Model III ROM image from disk before operating >>> in Model III mode. >> >> Not surprised I got that part wrong.? But then, I use my 4P all the >> time and haven't touched a normal 4 or 3 in quite a while. >> >>> >>> There were some hardware differences between the Model I and Model >>> III, such as the disk interface being memory-mapped in the Model I >>> and port-mapped in the Model III, but if the Model I programs don't >>> use anything that's different in the Model III then the Model 4 in >>> Model III mode should be able to run them.? So a game that's loaded >>> from cassette should work but a game that runs from disk and writes >>> to the disk won't work. >> >> Actually, the big difference is the memory map.? Most Model 1 >> programs load right where the top off the Model III ROM sits >> so they can not be used on the 3 or 4.? That's why I was hoping >> the ROM image trick could be used.? I guess it was just wishful >> thinking. Thanks for the info, > > There's a 2K hole in the Model I memory map above the ROM, this > space is used by the Model III ROM (12K ROM on the Model I, 14K > on the Model III).? After that you have memory-mapped I/O on > the Model I.? Both of them then have the keyboard mapped at > 3800H and the video at 3C00H.? RAM starts at 4000H on both of > them. > > How the first section of RAM is used depend on whether you are > using disk or cassette and if you are using disk then which OS > you use.? There's a good breakdown of how the RAM is used here: > > https://www.trs-80.com/wordpress/zaps-patches-pokes-tips/ram-addresses-and-routines/ > So, this just gets more and more confusing. (Have I really been away from all this for that long!!!) I dug up the tech manuals for the two of them (buried deep in my stacks of books) and compared them. And you are, of course, right. Which just brings more questions. Why do Model I cassette programs (not BASIC) not run on the Model III? Why did they relocate a Model I program that had a specific Model III version to a slightly higher location in memory? bill From paulkoning at comcast.net Tue Apr 12 08:49:10 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 09:49:10 -0400 Subject: Retro networking / WAN communities In-Reply-To: <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> Message-ID: <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> > On Apr 12, 2022, at 12:42 AM, Grant Taylor wrote: > > On 4/11/22 6:16 PM, Paul Koning wrote: >> I think "hub" is another word for "repeater" (just like "switch" is another word for "bridge"). > > Interesting. > > Do you know of any documentation, preferably not marketing materials, that used "repeater" in lieu of "hub"? DEC documentation. > From my naive point of view, hubs came about when multiple stations connected to a central location, the center, or hub, of the start if you will. Conversely, I remember reading (after the fact) about repeaters as something that existed in pure 10Base5 / 10Base2 networks, predating hubs. > > I'm questioning form a place of ignorance. Like a child asking why fire is hot. The concept of a repeater goes back to day 1 of Ethernet; you'll find them in the D/I/X Ethernet spec. And they were part of the first batch of Ethernet products from DEC. Yes, AUI based devices, two port. But the next thing out the door was the DEMPR, "Digital Multi-Port Repeater", an 8 port repeater. I think that's 10Base2. I first saw "structured wiring" -- the star wiring with a hierarchy of wiring closets and devices -- around 1986, in the new Littleton King Street DEC building. It had distribution cabinets at the end of each row of cubicles. These looked just like standard office supplies storage cabinets, with shelves; inside you'd find a bridge and a couple of DEMPR repeaters, connected to 10Base2 coax drops to each cubicle. > I think there is a large, > 80%, overlap between switch and bridge, but they aren't perfect. Bridging some traffic between otherwise incompatible networks comes to mind; e.g. SNAP between Token Ring and Ethernet or Ethernet to xDSL (RFC 1483). That's not where the term "switch" was introduced. And devices like that were called "bridge" by market leaders like DEC -- the two generations of FDDI to Ethernet bridges I mentioned were both called "bridge". Also, the general operation of the device is the same whether it does MAC frame tweaking or not, 802.1d applies unchanged. Ethernet to non-Ethernet bridges have to do some tinkering with Ethernet protocol type frames (which is where SNAP comes in, all nicely standardized in the FDDI days). For 802.5 they also have to deal with the misnamed "functional" addresses, but that's not hard. There also was such a thing as a "source routing bridge", an 802.5 only bad idea invented by IBM and sold for a while until the whole idea faded away. >> The device I have is a small standalone box, about the size of today's small 4-6 port switches you buy at Staples for $100. But it's actually a repeater, not a switch, and one of its ports is a 10Base2 connector (BNC jack). > > I would firmly consider what you describe as a "hub". I think "hub" is what DEC called the chassis that these boxes could plug in to. >> ... >> That's rather odd because even if someone doesn't obey the letter of the law you'd think they would at least support 100BaseT. Or was the problem lack of half duplex? Do those management interfaces want to run half duplex? > > No. It's more nefarious than that. You mentioned supporting n - 1 generation. I'm talking about switches that support 1 Gbps / 10 Gbps / 25 Gbps / 40 Gbps / 50 Gbps / 100 Gbps. They quite simply don't scale down to 100 Mbps much less 10 Mbps. -- Why would someone want to support those slow speed connections on such a high speed switch? Devices like intelligent power strips or serial consoles or the likes in a cabinet that uses said switch as a Top of Rack device. -- Our reluctant solution has been to put in a lower end / un-manged 10 Mbps / 100 Mbps / 1 Gbps that can link at 1 Gbps to the main ToR. I understand now. Yes, that's annoying indeed. >> I think I saw in the standard that Gigabit Ethernet in theory includes a half duplex mode, but I have never seen anyone use it and I wonder if it would work if tried. Perhaps I misread things. > > My understanding is that Gigabit Ethernet (and beyond) only supports full duplex. Maybe I'm mis-remembering or thinking about what is actually produced vs theoretical / lab experiments. I took a quick look in the 802.3 spec. In the 2002 edition, Part 3 describes gigabit Ethernet. The intro ("clause 34") has this to say: "In full duplex mode, the mini- mum packet transmission time has been reduced by a factor of ten. Achievable topologies for 1000 Mb/s full duplex operation are comparable to those found in 100BASE-T full duplex mode. In half duplex mode, the minimum packet transmission time has been reduced, but not by a factor of ten." So yes, it's theoretically part of the spec. As you said, it doesn't seem to be in actual use. > Similarly, I know someone that has 100 Mbps Token Ring, a.k.a. High Speed Token Ring (HSTR) equipment for their mainframe. And 1 Gigabit Token Ring was designed in the lab but never actualized. Curious. Clearly such things are possible. But FDDI came out well before HSTR, and it was crushed by 100 Mb Ethernet. All the reasons for that to happen would apply much more so for HSTR. Does anyone still remember the other 100 Mb Ethernet-like proposal, I think from HP, which added various types of complexity instead of simply being a faster Ethernet? I forgot what it was called, or what other things it added. Something about isochronous mode, perhaps? Or maybe I'm confused with FDDI 2 -- another concept that never got anywhere, being much more complicated even than regular FDDI. paul From tsg at bonedaddy.net Tue Apr 12 08:56:06 2022 From: tsg at bonedaddy.net (Todd Goodman) Date: Tue, 12 Apr 2022 09:56:06 -0400 Subject: Retro networking / WAN communities In-Reply-To: <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> Message-ID: On 4/12/2022 9:49 AM, Paul Koning via cctalk wrote: > >> On Apr 12, 2022, at 12:42 AM, Grant Taylor wrote: >> >> On 4/11/22 6:16 PM, Paul Koning wrote: >> [..SNIP..] >> I think there is a large, > 80%, overlap between switch and bridge, but they aren't perfect. Bridging some traffic between otherwise incompatible networks comes to mind; e.g. SNAP between Token Ring and Ethernet or Ethernet to xDSL (RFC 1483). > That's not where the term "switch" was introduced. And devices like that were called "bridge" by market leaders like DEC -- the two generations of FDDI to Ethernet bridges I mentioned were both called "bridge". > > Also, the general operation of the device is the same whether it does MAC frame tweaking or not, 802.1d applies unchanged. Ethernet to non-Ethernet bridges have to do some tinkering with Ethernet protocol type frames (which is where SNAP comes in, all nicely standardized in the FDDI days). For 802.5 they also have to deal with the misnamed "functional" addresses, but that's not hard. > > There also was such a thing as a "source routing bridge", an 802.5 only bad idea invented by IBM and sold for a while until the whole idea faded away. The big difference in my mind between bridge and switch is: * Switches learn what port given MACs are on and only sends unicast traffic destined for that MAC address on that port and not all * Bridges send unicast traffic to all ports Of course it's important for bridges to follow the standard and switches to make sure they don't cause packet storms by forwarding on ports they shouldn't [..SNIP..] My $.02 Todd From paulkoning at comcast.net Tue Apr 12 09:09:03 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 10:09:03 -0400 Subject: Retro networking / WAN communities In-Reply-To: <2ca31874-6f0b-5df3-1cee-82235ca91ce8@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> <2ca31874-6f0b-5df3-1cee-82235ca91ce8@spamtrap.tnetconsulting.net> Message-ID: > Begin forwarded message: > > From: Grant Taylor via cctalk > Subject: Re: Retro networking / WAN communities > Date: April 12, 2022 at 2:08:22 AM EDT > To: Wayne S , "General Discussion: On-Topic and Off-Topic Posts" > Reply-To: Grant Taylor , "General Discussion: On-Topic and Off-Topic Posts" > > On 4/11/22 11:38 PM, Wayne S wrote: >> In the beginning there was thick ethernet limited to 100 m. > > Um.... > > I *REALLY* thought the 5 & 2 in 10Base5 and 10Base2 was the number of hundreds of meters that the cable segment could exist on it's own. > > My understanding is that the 100 meter limit came about with 10Base-T. Yes, that is correct. 10Base5 is 500 meter segment limit, 10Base2 is 200 meters max. There are some other small differences: 10Base5 wants you to put the transceiver attachments on the marks on the cable (to avoid having impedance bumps aligned with the wave length); 10Base2 omits that requirement. See the 802.3 spec for all the gory details. >> People wanted computers that were on different floors connected together between floors and buildings. That exceeded the 100 meter spec so the repeater was born to connect two 100 m thick ethernet seqments. > > I feel like even only 100 meters / 300(+) feet gives quite a bit of flexibility to connect multiple floors. Especially if you consider the AUI drop cable. > > Aside: I'm not sure how long an AUI drop cable could be. I'm anticipating between single and low double digit feet. The spec says 50 meters. And given the 500 meter segment limit, 10Base5 would handle quite a large building. Repeaters serve several purposes. One is to allow a larger station count than is permitted on a single segment. Another is to allow multiple segments either for still greater distances or for convenience. For example, it would make a lot of sense to run a segment per floor, a backbone segment up the elevator shaft, and repeaters to connect floor to backbone, even if in principle you can zig-zag a single segment across several floors within the distance limits. >> A repeater was basically a signal booster between two ethernet segments. As you added segments interference and collisions became a problem as traffic on one segment was passed to all the other connected segments. > > Yep, the 3, 4, 5, rule. Up to five segments of cable with four repeaters and stations on no more than three of the segments. > >> Hence the bridge was born. It had some intelligence And didn?t pass packets intended for computers on its own segment to the other segments thereby reducing congestion and collisions. > > Didn't repeaters operate in the analog domain? Meaning that they would also repeat ~> amplify any noise / distortion too? No, they are digital devices (except that collision sense of course is an analog function, but that lives in the transceiver). They do clock recovery and regeneration. So you'd get some added jitter but not noise or distortion. > Conversely bridges operated in the digital domain. Meaning that they received an Ethernet frame and then re-generated and transmitted a new pristine Ethernet frame? Yes, except that bridges were encouraged to repeat the CRC rather than recalculate it, if possible. You can't do that on mixed LANs (like Ethernet to FDDI) but for the Ethernet to Ethernet case you can, and it's a very good thing to do so. >> Then the router was born to connect multiple segments together at one point. And it had intelligence to determine what segment a packet should go to and route it there. It also prevented packets from going onto segments that didn?t have the packet?s intended target thereby reducing congestion. Yes, except that historically speaking this is not accurate; routers predate Ethernet by 10 years or so. >> Hubs were born approximately the same time to get over the ethernet tap distance because by this time there were more computers in the single area that needed to be connected together to the Ethernet. > > Hum.... > > I can see problems with having enough actual taps on a network segment to connect all the machines in a given area with AUI drop cable length issues. > > But I know that multi-port taps were a thing. I've read about them and seen pictures of them for sale. I think I've read about a singular tap that had eight AUI ports on it. I've seen pictures of four AUI ports on a single tap. Yes, DEC came out with that very early on, the DELNI. > ... >> The switch came about. It was a smart hub that had intelligence. It could filter out packets that were not intended for other computers connected to it thereby reducing congestion. > > I feel like the switch and the bridge are doing the same thing from a learning / forwarding / blocking perspective. Learning and spanning tree were part of bridges from the start (the DECbridge 100). That's precisely what made bridges offer scaling benefits vs. repeaters. And DEC worked very hard to figure out how to do that at wire speed, in the early days of Ethernet that was an extremely hard thing to do. paul From paulkoning at comcast.net Tue Apr 12 09:12:02 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 10:12:02 -0400 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> Message-ID: > On Apr 12, 2022, at 9:56 AM, Todd Goodman via cctalk wrote: > ... > The big difference in my mind between bridge and switch is: > > * Switches learn what port given MACs are on and only sends unicast > traffic destined for that MAC address on that port and not all > * Bridges send unicast traffic to all ports Absolutely not. The only standard device that forwards unicast to all ports is the repeater. I don't know of any packet forwarding device that sends unicast traffic to all ports; certainly no such thing can be found in any standard. Learning was introduced by DEC in the DECbridge 100 (along with spanning tree); IEEE later standardized this, with some small mods, in 802.1d. paul From paulkoning at comcast.net Tue Apr 12 09:19:47 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 10:19:47 -0400 Subject: Retro networking / WAN communities In-Reply-To: <1adbbf7d-f023-b276-9a35-e071085a4988@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> <055fe541-ec95-cbd7-3389-d59333d91c17@spamtrap.tnetconsulting.net> <1adbbf7d-f023-b276-9a35-e071085a4988@spamtrap.tnetconsulting.net> Message-ID: <027D29DE-E0F4-49CB-AAEF-7FAD9C8817F6@comcast.net> > On Apr 12, 2022, at 12:52 AM, Grant Taylor wrote: > > ... > I vaguely remember that there were three main forms of switching: store and forward, cut-through, and a hybrid of the two. My understanding is that S&F had the ability to sanity check (checksum?) frames and only re-send out valid / non-corrupted frames. Conversely C.T. could not do this sanity checking and thus could re-send corrupted frames. The 3rd form did a sanity check on the first part of the frame. -- I think. The normal type of bridge / switch is the store and forward type, which discards bad packets and forwards only good ones. Cut through means starting to forward a packet before the end of it has been received. That necessarily means forwarding it without knowing if it's a good frame (good CRC, length, alignment if applicable). The remaining question is what happens with the cut-through frame when the end of packet arrives and is seen to be bad. One possibility is to propagate the received packet exactly, in which case (barring an unfortunate additional data error) it will be seen as bad by the eventual recipient. The other possibility is to force an explicit abort of some sort to make sure the packet is seen as bad. For a mixed LAN type bridge, only the second option is valid (because you aren't doing CRC forwarding in that case). Of course, a lot of mixed type bridges are also mixed speed, where cut through isn't really an option. Theoretically you could have, say, 100 Mb/s Ethernet to FDDI, but in practice I don't know if those existed and doubt that, if so, they used cut through. You can't do sanity checking on the frame beginning; there isn't anything that gives you a clue whether the start is valid or not. At least not apart from trivial checks like "source address can't be a multicast address". The only data link protocol I can think of that lets you check the frame beginning is DDCMP. paul From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 09:38:35 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 08:38:35 -0600 Subject: Retro networking / WAN communities In-Reply-To: <7wtuaybz4k.fsf@junk.nocrew.org> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> <7wtuaybz4k.fsf@junk.nocrew.org> Message-ID: <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> On 4/12/22 12:21 AM, Lars Brinkhoff via cctalk wrote: > Are you saying there's a BSD Unix with Arpanet NCP? If so, where? My understanding is that 4.3BSD that ran on VAXes had support for NCP. My naive assumption is that there is enough of it still around that it may be possible to bring up an NCP connection between multiple systems. Perhaps that's a /mis/understanding on my part. I'd love to learn supporting information either way. -- Grant. . . . unix || die From tsg at bonedaddy.net Tue Apr 12 09:44:04 2022 From: tsg at bonedaddy.net (Todd Goodman) Date: Tue, 12 Apr 2022 10:44:04 -0400 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> Message-ID: <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> On 4/12/2022 10:12 AM, Paul Koning wrote: > >> On Apr 12, 2022, at 9:56 AM, Todd Goodman via cctalk wrote: >> ... >> The big difference in my mind between bridge and switch is: >> >> * Switches learn what port given MACs are on and only sends unicast >> traffic destined for that MAC address on that port and not all >> * Bridges send unicast traffic to all ports > Absolutely not. The only standard device that forwards unicast to all ports is the repeater. I don't know of any packet forwarding device that sends unicast traffic to all ports; certainly no such thing can be found in any standard. > > Learning was introduced by DEC in the DECbridge 100 (along with spanning tree); IEEE later standardized this, with some small mods, in 802.1d. > > paul You snipped the part where I said except for ports that should not receive the traffic due to blocked ports from the Spanning Tree Protocol in 802.1d and that if that fails you end up with a broadcast storm. Well, I didn't mention STP in 802.1d specifically because I thought it was obvious. Bridges were useful even after switches arrived to allow monitoring of traffic on any port of the bridge.? It was useful before switches got port mirroring and even after as it didn't require any configuration. Todd From paulkoning at comcast.net Tue Apr 12 09:50:20 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 10:50:20 -0400 Subject: Retro networking / WAN communities In-Reply-To: <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> Message-ID: <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> > On Apr 12, 2022, at 10:44 AM, Todd Goodman wrote: > > > On 4/12/2022 10:12 AM, Paul Koning wrote: >> >>> On Apr 12, 2022, at 9:56 AM, Todd Goodman via cctalk wrote: >>> ... >>> The big difference in my mind between bridge and switch is: >>> >>> * Switches learn what port given MACs are on and only sends unicast >>> traffic destined for that MAC address on that port and not all >>> * Bridges send unicast traffic to all ports >> Absolutely not. The only standard device that forwards unicast to all ports is the repeater. I don't know of any packet forwarding device that sends unicast traffic to all ports; certainly no such thing can be found in any standard. >> >> Learning was introduced by DEC in the DECbridge 100 (along with spanning tree); IEEE later standardized this, with some small mods, in 802.1d. >> >> paul > > You snipped the part where I said except for ports that should not receive the traffic due to blocked ports from the Spanning Tree Protocol in 802.1d and that if that fails you end up with a broadcast storm. > > Well, I didn't mention STP in 802.1d specifically because I thought it was obvious. > > Bridges were useful even after switches arrived to allow monitoring of traffic on any port of the bridge. It was useful before switches got port mirroring and even after as it didn't require any configuration. Yes, I snipped part of what you said, but that doesn't affect my point. Learning has always been part of what bridges do. It's a core part of the DEC bridge spec, and a core part of the DECbridge-100 functionality. It is the reason why Tony Lauck and George Varghese invented the "timer wheels" scheme for keeping 8000 timers in constant time. A device that doesn't do address learning and floods unicast frames is not a bridge but rather a non-standard piece hardware. I don't actually know if anyone ever implemented such a device. Certainly I've never seen one or built one myself, even though what I built was called "bridge". paul From ard.p850ug1 at gmail.com Tue Apr 12 10:23:54 2022 From: ard.p850ug1 at gmail.com (Tony Duell) Date: Tue, 12 Apr 2022 16:23:54 +0100 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <5784fc97-f654-84a0-3169-5bee31be0017@floodgap.com> Message-ID: On Tue, Apr 12, 2022 at 5:55 AM Grant Taylor via cctalk wrote: > > On 4/11/22 9:55 PM, Tony Duell via cctalk wrote: > > I am not sure what the actual distinction is, but a 'managed bridge' > > turned up at the local antique market (!) some weeks back. It has a > > pair of AUI ports and from the amount of logic/processor power inside > > it does a lot more than just pass packets from one port to the other, > > Would you be willing to share pictures? I can do a little better than that, I think. How about reverse-engineered schematics. :-) It'll take a little time to dig them out (schematics and photos) but I am certainly happy to share them. > > > The main board contains a pair of ethernet interfaces (AM7990 based), > > a 68020 processor, ROM, RAM, etc. A board on top of of it called the > > 'FLUT' (Frame Look Up Table?) contains a CY7C901 (16 bit slice ALU -- > > think of it as 4 off 2901 + carry loglc), a 29C10 seqencer, etc > > Hum.... > > > After removing the leaking NiCd from the mainboard and repairing the > > corroded tracks it powers up and passes the self-tests. No idea what > > I'll use it for, but... > > That seems like it would be an interesting piece of networking history > to own. If you're into that sort of thing. ;-) It cost \pounds 5.00 (so <$10). At that price I bought it. If only for the 2U case, the SMPSU, the LCD module, etc. But since it powers up and passes the self tests I am keeping it whole. It is an odd bit of history, too many people preserve processors and not the other hardware that went with them. -tony From dittman at dittman.net Tue Apr 12 10:24:49 2022 From: dittman at dittman.net (Eric Dittman) Date: Tue, 12 Apr 2022 10:24:49 -0500 Subject: TRS-80 Question In-Reply-To: References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> Message-ID: On 4/12/22 6:37 AM, Bill Gunshannon via cctalk wrote: > So, this just gets more and more confusing. (Have I really been away > from all this for that long!!!) > > I dug up the tech manuals for the two of them (buried deep in my > stacks of books) and compared them.? And you are, of course, right. > > Which just brings more questions. > > Why do Model I cassette programs (not BASIC) not run on the Model III? > Why did they relocate a Model I program that had a specific Model III > version to a slightly higher location in memory? It was common to add a loader for cassette programs that would load the program in higher memory and relocate to the original location so they could be loaded from disk (on both the Model I and Model III). This is because the original location would typically be in low RAM used by the OS. In some cases there wasn't a disk version of the program, in other cases it was to avoid having to buy the disk version. For games if there was a disk version the only likely change was to add a high score table that was written to disk, so not worth paying again. There were a few games that added extra features to the disk version but right now I can't remember which ones. I think Big Five did a few this way. -- Eric Dittman From dave.g4ugm at gmail.com Tue Apr 12 10:34:47 2022 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Tue, 12 Apr 2022 16:34:47 +0100 Subject: AlphaServer 2100s available In-Reply-To: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> Message-ID: <1ae801d84e82$d821d300$88657900$@gmail.com> Folks, Does no one fancy a go at this. Had zero interest... Dave > -----Original Message----- > From: dave.g4ugm at gmail.com > Sent: 04 April 2022 12:29 > To: 'General Discussion: On-Topic and Off-Topic Posts' > > Subject: RE: AlphaServer 2100s available > > Folks, > > I got one of these from Antonio. It has 4 x CPU boards in plus a few disk > drives, but it does not want to power up. It did spin the fans up then shut > down. . I now have a lot of other projects on the go, so if anyone would like it > please let me know. > Its in Manchester, England. Replies off-list please. > > Dave > > > -----Original Message----- > > From: cctalk On Behalf Of Antonio > > Carlini via cctalk > > Sent: 21 July 2020 20:58 > > To: General Discussion: On-Topic and Off-Topic Posts > > > > Subject: AlphaServer 2100s available > > > > I have three AlphaServer 2100 systems in storage in the UK (Oxfordshire). > > The storage, however, is due to be demolished (soon, but no fixed date). > > > > > > I won't have room to store these three systems, so if anyone would be > > interested in offering them a home, then please get in touch! > > > > > > I can probably get some pictures in the next day or two. > > > > > > These systems were SMP Alphas and could sport as many as 4 CPUs. I'm > > not sure of the configuration of these systems but I can probably find > > that out soon. > > > > They have not been run since ~2003 so they may be in need of some TLC. > > OTOH they are not rusted to death so you have a chance of getting them > > back to life. > > > > > > Just so you know what you might be dealing with these systems are about: > > 700mm H x 430mm W x 810mm L. > > > > > > I can't find the weight in any of my references right now but they are > > very heavy. Three people can move them up a slight slope with some > > effort but you would not successfully lift it into a car (assuming > > that it would fit). I'm planning to dismantle them to move them (i.e. > > remove PSU/PSUs etc. until they are light enough to move). A tail-lift > > would probably be the sane way to go (and is, indeed, how they got to > > their current location. > > > > > > I'm hoping that someone can step forward and offer one or more of > > these machines a new home. Please contact me off-list (once you're > > sure you understand what you are getting into :-)). > > > > > > Antonio > > > > > > -- > > Antonio Carlini > > antonio at acarlini.com > From tsg at bonedaddy.net Tue Apr 12 10:40:24 2022 From: tsg at bonedaddy.net (Todd Goodman) Date: Tue, 12 Apr 2022 11:40:24 -0400 Subject: Retro networking / WAN communities In-Reply-To: <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> Message-ID: <2aee87e9-6d60-b6f3-1316-2a0fdbe94297@bonedaddy.net> On 4/12/2022 10:50 AM, Paul Koning wrote: > >> On Apr 12, 2022, at 10:44 AM, Todd Goodman wrote: >> >> >> On 4/12/2022 10:12 AM, Paul Koning wrote: >>>> On Apr 12, 2022, at 9:56 AM, Todd Goodman via cctalk wrote: >>>> ... >>>> The big difference in my mind between bridge and switch is: >>>> >>>> * Switches learn what port given MACs are on and only sends unicast >>>> traffic destined for that MAC address on that port and not all >>>> * Bridges send unicast traffic to all ports >>> Absolutely not. The only standard device that forwards unicast to all ports is the repeater. I don't know of any packet forwarding device that sends unicast traffic to all ports; certainly no such thing can be found in any standard. >>> >>> Learning was introduced by DEC in the DECbridge 100 (along with spanning tree); IEEE later standardized this, with some small mods, in 802.1d. >>> >>> paul >> You snipped the part where I said except for ports that should not receive the traffic due to blocked ports from the Spanning Tree Protocol in 802.1d and that if that fails you end up with a broadcast storm. >> >> Well, I didn't mention STP in 802.1d specifically because I thought it was obvious. >> >> Bridges were useful even after switches arrived to allow monitoring of traffic on any port of the bridge. It was useful before switches got port mirroring and even after as it didn't require any configuration. > Yes, I snipped part of what you said, but that doesn't affect my point. > > Learning has always been part of what bridges do. It's a core part of the DEC bridge spec, and a core part of the DECbridge-100 functionality. It is the reason why Tony Lauck and George Varghese invented the "timer wheels" scheme for keeping 8000 timers in constant time. > > A device that doesn't do address learning and floods unicast frames is not a bridge but rather a non-standard piece hardware. I don't actually know if anyone ever implemented such a device. Certainly I've never seen one or built one myself, even though what I built was called "bridge". > > paul I'm not talking about pre-standard DEC devices. I can show you a standard commodity bridge from multiple vendors right now that will allow you to monitor unicast traffic destined for other ports just by plugging in to one of the other ports on the bridge. I don't have my 802.1d spec I implemented a bridge from in the 90s But whatever, I've used that capability a lot over the years on a lot of different bridges so have nothing more on the topic Todd From lars at nocrew.org Tue Apr 12 10:48:11 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 12 Apr 2022 15:48:11 +0000 Subject: Retro networking / WAN communities In-Reply-To: <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> (Grant Taylor via cctalk's message of "Tue, 12 Apr 2022 08:38:35 -0600") References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> <7wtuaybz4k.fsf@junk.nocrew.org> <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> Message-ID: <7wbkx6b8w4.fsf@junk.nocrew.org> Grant Taylor wrote: > My understanding is that 4.3BSD that ran on VAXes had support for NCP. 4.3BSD released in 1986 was long after ARPANET switched from NCP to TCP/IP. Apparently early TCP/IP support was added to 4.1a in 1981. I'm going out on a limb to claim BSD never had NCP support. From pete at pski.net Tue Apr 12 10:49:59 2022 From: pete at pski.net (Peter Cetinski) Date: Tue, 12 Apr 2022 11:49:59 -0400 Subject: TRS-80 Question In-Reply-To: References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> Message-ID: > > On 4/12/22 6:37 AM, Bill Gunshannon via cctalk wrote: >> So, this just gets more and more confusing. (Have I really been away >> from all this for that long!!!) >> I dug up the tech manuals for the two of them (buried deep in my >> stacks of books) and compared them. And you are, of course, right. >> Which just brings more questions. >> Why do Model I cassette programs (not BASIC) not run on the Model III? >> Model I machine language cassette programs will run just fine on the Model III given that the restrictions on direct hardware access mentioned are respected. For example, for my game RoundUp!, you can load the 500 baud tape version on the Model I or Model III just fine. Of course, you need to specify ?L? for low rate baud of 500 at the Model III Cassette? prompt. The model I only supports 500 baud cassettes. From paulkoning at comcast.net Tue Apr 12 10:52:48 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 11:52:48 -0400 Subject: Retro networking / WAN communities In-Reply-To: <2aee87e9-6d60-b6f3-1316-2a0fdbe94297@bonedaddy.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> <2aee87e9-6d60-b6f3-1316-2a0fdbe94297@bonedaddy.net> Message-ID: <412171F8-8D22-4767-9A76-3C66C92F3C79@comcast.net> > On Apr 12, 2022, at 11:40 AM, Todd Goodman wrote: > > > On 4/12/2022 10:50 AM, Paul Koning wrote: >> >>> ... >> >> Learning has always been part of what bridges do. It's a core part of the DEC bridge spec, and a core part of the DECbridge-100 functionality. It is the reason why Tony Lauck and George Varghese invented the "timer wheels" scheme for keeping 8000 timers in constant time. >> >> A device that doesn't do address learning and floods unicast frames is not a bridge but rather a non-standard piece hardware. I don't actually know if anyone ever implemented such a device. Certainly I've never seen one or built one myself, even though what I built was called "bridge". >> >> paul > > > I'm not talking about pre-standard DEC devices. > > I can show you a standard commodity bridge from multiple vendors right now that will allow you to monitor unicast traffic destined for other ports just by plugging in to one of the other ports on the bridge. > > I don't have my 802.1d spec I implemented a bridge from in the 90s I do have 802.1d, but it's a box. I know for a fact that learning is part of it, just as it was in the DEC spec, for the obvious reason that they are basically the same architecture. So any compliant bridge forwards unicast traffic to the port on which that address is known to be, flooding only to unknown addresses. paul From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 11:45:30 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 10:45:30 -0600 Subject: Retro networking / WAN communities In-Reply-To: <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> Message-ID: On 4/12/22 7:49 AM, Paul Koning via cctalk wrote: > DEC documentation. Thank you. > The concept of a repeater goes back to day 1 of Ethernet; you'll find > them in the D/I/X Ethernet spec. And they were part of the first > batch of Ethernet products from DEC. Repeaters existing from day 1 of Ethernet sort of surprises me. I wonder if there is some difference in the original 3 Mbps Ethernet at Xerox PARC vs the 10 Mbps Ethernet (II?) that was commercialized. > Yes, AUI based devices, two port. ACK > But the next thing out the door was the DEMPR, "Digital Multi-Port > Repeater", an 8 port repeater. I think that's 10Base2. $ResearchList++ > I first saw "structured wiring" -- the star wiring with a hierarchy > of wiring closets and devices -- around 1986, in the new Littleton > King Street DEC building. It had distribution cabinets at the end of > each row of cubicles. These looked just like standard office supplies > storage cabinets, with shelves; inside you'd find a bridge and a couple > of DEMPR repeaters, connected to 10Base2 coax drops to each cubicle. Interesting use case. -- Now I'm wondering if each station run was standard 10Base2 with it's T connector and terminator. > That's not where the term "switch" was introduced. And devices > like that were called "bridge" by market leaders like DEC -- the two > generations of FDDI to Ethernet bridges I mentioned were both called > "bridge". I first saw "switch" used as a way to differentiate a (dumb) hub from an intelligent hub type of functionality. > Also, the general operation of the device is the same whether it does > MAC frame tweaking or not, 802.1d applies unchanged. Ethernet to > non-Ethernet bridges have to do some tinkering with Ethernet protocol > type frames (which is where SNAP comes in, all nicely standardized in > the FDDI days). For 802.5 they also have to deal with the misnamed > "functional" addresses, but that's not hard. I now feel the need to call out what I think are two very distinct things that need to be differentiated: 1) Learning of which port a source MAC address is on for the purposes of not sending a frame out to a destination segment when the location of the destination is known. 2) Spanning Tree / 802.1D learning the path to the root of the tree. The former is a fairly easy algorithm that doesn't require anything other than passive listening for data collection. The latter requires introduction of a new type of active traffic, namely BPDUs. > There also was such a thing as a "source routing bridge", an 802.5 > only bad idea invented by IBM and sold for a while until the whole > idea faded away. We are actually seeing "source routing" make a resurgence in IPv6 via Segment Routing. > I think "hub" is what DEC called the chassis that these boxes could > plug in to. > > I understand now. Yes, that's annoying indeed. Yes, quite annoying. I could actually see the use for a card that could go into non-fixed configuration switches that provided a few 10/100 ports specifically for this purpose. > So yes, it's theoretically part of the spec. As you said, it doesn't > seem to be in actual use. ACK > Curious. Clearly such things are possible. But FDDI came out well > before HSTR, and it was crushed by 100 Mb Ethernet. All the reasons > for that to happen would apply much more so for HSTR. Yep. Lab vs actual commercialized products are quite different. Then there's what the market purchases and uses. > Does anyone still remember the other 100 Mb Ethernet-like proposal, > I think from HP, which added various types of complexity instead of > simply being a faster Ethernet? I forgot what it was called, or what > other things it added. Something about isochronous mode, perhaps? > Or maybe I'm confused with FDDI 2 -- another concept that never got > anywhere, being much more complicated even than regular FDDI. I vaguely remember there being multiple 100 Mbps Ethernet specifications. I think one of them had "Any" in it's name. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 12:20:44 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 11:20:44 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> <7wtuaybz4k.fsf@junk.nocrew.org> <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> <7wbkx6b8w4.fsf@junk.nocrew.org> Message-ID: <211cd52a-72f1-7c60-d978-55acddd97009@spamtrap.tnetconsulting.net> On 4/12/22 10:11 AM, Wayne S wrote: > Wiki says ethernet became commercially available in 1980 and invented > in 1973. So if enet was 1980 what were routers routing 10 years > earlier in 1970? I feel like IMPs were "routing" and could be considered "routers" long before Ethernet was a thing. -- Grant. . . . unix || die From cruff at ruffspot.net Tue Apr 12 12:17:16 2022 From: cruff at ruffspot.net (Craig Ruff) Date: Tue, 12 Apr 2022 11:17:16 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: Message-ID: <1D0E3649-51F7-4FBB-81F3-0FF5BF042010@ruffspot.net> > I'm running into issues with switches not supporting 10 / 100 Mbps management interfaces for other equipment. Half duplex was apparently deprecated a few years back, and recent switches from Cisco (and probably other vendors) no longer support half duplex. We ran into this at work for long lifetime medical devices. From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 12:25:59 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 11:25:59 -0600 Subject: Retro networking / WAN communities In-Reply-To: <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> Message-ID: <2c56f2f7-d0b0-bfc6-b95f-48cb37590082@spamtrap.tnetconsulting.net> On 4/12/22 8:50 AM, Paul Koning via cctalk wrote: > A device that doesn't do address learning and floods unicast frames > is not a bridge but rather a non-standard piece hardware. I feel like a "hub" qualifies as "a device that doesn't do address learning and floods unicast frames". To me, the fundamental difference between a hub and a switch / bridge is address learning. I can't tell if your (quoted) statement is specific to /just/ bridges / switches or could include hubs. Your first comment addresses bridges directly, thus meaning that your second non-targeted comment might target more. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 12:28:33 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 11:28:33 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> Message-ID: <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> On 4/12/22 7:56 AM, Todd Goodman via cctalk wrote: > The big difference in my mind between bridge and switch is: > > ?* Switches learn what port given MACs are on and only sends unicast > ?? traffic destined for that MAC address on that port and not all > ?* Bridges send unicast traffic to all ports So what would differentiate the bridge (using your understanding) from a hub? -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 12:35:24 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 11:35:24 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> <7wtuaybz4k.fsf@junk.nocrew.org> <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> <7wbkx6b8w4.fsf@junk.nocrew.org> <211cd52a-72f1-7c60-d978-55acddd97009@spamtrap.tnetconsulting.net> Message-ID: <808d89a4-4f5a-7e1e-88d6-8f5bd61a32b1@spamtrap.tnetconsulting.net> On 4/12/22 11:23 AM, Wayne S wrote: > What?s an IMP? Don?t know that acronym. Interface Message Processor. #ARPANET -- Grant. . . . unix || die From w2hx at w2hx.com Tue Apr 12 12:31:31 2022 From: w2hx at w2hx.com (W2HX) Date: Tue, 12 Apr 2022 17:31:31 +0000 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> <7wtuaybz4k.fsf@junk.nocrew.org> <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> <7wbkx6b8w4.fsf@junk.nocrew.org> <211cd52a-72f1-7c60-d978-55acddd97009@spamtrap.tnetconsulting.net> Message-ID: Internet message processor (BBN I think) 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/c/w2hx-channel/videos -----Original Message----- From: cctech On Behalf Of Wayne S via cctech Sent: Tuesday, April 12, 2022 1:24 PM To: Grant Taylor Cc: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Retro networking / WAN communities What?s an IMP? Don?t know that acronym. Sent from my iPhone > On Apr 12, 2022, at 10:20, Grant Taylor wrote: > > ?On 4/12/22 10:11 AM, Wayne S wrote: >> Wiki says ethernet became commercially available in 1980 and invented in 1973. So if enet was 1980 what were routers routing 10 years earlier in 1970? > > I feel like IMPs were "routing" and could be considered "routers" long before Ethernet was a thing. > > > > -- > Grant. . . . > unix || die From paulkoning at comcast.net Tue Apr 12 12:41:09 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 13:41:09 -0400 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> Message-ID: <9778CCB9-9DE6-4A8D-859B-13B2E03B4454@comcast.net> > On Apr 12, 2022, at 12:45 PM, Grant Taylor via cctalk wrote: > > On 4/12/22 7:49 AM, Paul Koning via cctalk wrote: >> ... >> The concept of a repeater goes back to day 1 of Ethernet; you'll find them in the D/I/X Ethernet spec. And they were part of the first batch of Ethernet products from DEC. > > Repeaters existing from day 1 of Ethernet sort of surprises me. > > I wonder if there is some difference in the original 3 Mbps Ethernet at Xerox PARC vs the 10 Mbps Ethernet (II?) that was commercialized. I don't know anything about the 3 Mb/s prototype other than that it existed. When I speak of Ethernet and its "day 1" I mean 10 Mb/s Ethernet as defined by the DEC/Intel/Xerox spec. Repeaters are a core part of that spec, and they were among the first wave of products delivered by DEC. > ... >> I first saw "structured wiring" -- the star wiring with a hierarchy of wiring closets and devices -- around 1986, in the new Littleton King Street DEC building. It had distribution cabinets at the end of each row of cubicles. These looked just like standard office supplies storage cabinets, with shelves; inside you'd find a bridge and a couple of DEMPR repeaters, connected to 10Base2 coax drops to each cubicle. > > Interesting use case. -- Now I'm wondering if each station run was standard 10Base2 with it's T connector and terminator. I no longer remember. That's possible, or perhaps they were a number of small segments each with a handful of stations on them. >> ... > > I now feel the need to call out what I think are two very distinct things that need to be differentiated: > > 1) Learning of which port a source MAC address is on for the purposes of not sending a frame out to a destination segment when the location of the destination is known. > 2) Spanning Tree / 802.1D learning the path to the root of the tree. > > The former is a fairly easy algorithm that doesn't require anything other than passive listening for data collection. The latter requires introduction of a new type of active traffic, namely BPDUs. That's true but only part of the story. For one thing, as I said, both mechanisms were part of bridges from the start (at least from the start of DEC's bridges, which may not be quite the very earliest ever but certainly are the earliest significant ones). The learning part of bridging is actually the hard part. It involves (a) extracting the SA of each received address, (b) looking it up, in very short time, in a large address table (8k entries in the original DECbridge-100), (c) timing out each one of those addresses. And then also (d) looking up the DA of a received packet in that table and (e) if found, forwarding the packet only to the port for that address, or dropping it if output port == input port. (a) is easy, (b) through (d) are not. And (d)/(e) are the purpose of the exercise, it is why bridged networks have better scaling properties than repeater based networks. If you consider a two port 10 Mb Ethernet bridge, steps (b) and (d) amount to two table lookups every 30 microseconds (minimum packet interval across two ports), and step (b) includes restarting the aging timer for that address. With early 1980s technology this is a seriously hard problem; as I recall, in the DECbridge-100 it involved a hardware assist device to do the table lookup. And (c) is not easy either, it required the invention of the "timer wheel" algorithm which has the properties that starting, stopping, and keeping N timers is O(1) i.e., independent of N. (Expirationn of n timers is O(n), but most timers do not expire in this application.) Later on it became possible, with great care, to do these things in software. The DECbridge-900 (FDDI to 6 x 10M Ethernet) has its fast path in a 25 MHz 68040, very carefully handcrafted assembly code, with a bit of help from a 64-entry CAM acting as address cache. It can handle around 60 k packets/second, which means it needs some additional specialized rules to ensure it won't miss BPDUs under overload since it can't do worst case packet arrival at all ports concurrently in the normal forwarding path. We patented that. Spanning tree is indeed another algorithm / protocol, but it's a control plane algorithm with relatively easy time constraints, so it's just SMOP. >> ... >> Does anyone still remember the other 100 Mb Ethernet-like proposal, I think from HP, which added various types of complexity instead of simply being a faster Ethernet? I forgot what it was called, or what other things it added. Something about isochronous mode, perhaps? Or maybe I'm confused with FDDI 2 -- another concept that never got anywhere, being much more complicated even than regular FDDI. > > I vaguely remember there being multiple 100 Mbps Ethernet specifications. I think one of them had "Any" in it's name. That rings a bell. Someone reminded me of 100Base-T4. In any case, there were two proposed, one that made it. The other might have gone as far as one or two shipping products, but no further than that. paul From w2hx at w2hx.com Tue Apr 12 12:37:29 2022 From: w2hx at w2hx.com (W2HX) Date: Tue, 12 Apr 2022 17:37:29 +0000 Subject: Retro networking / WAN communities In-Reply-To: <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> Message-ID: <13c4a167fec34ab09245ac24a6086475@EXBE015SV3.NA02.MSEXCHANGEOUTLOOK.COM> I could be wrong, but I always thought the distinction between hub and bridge was, all traffic is broadcast to all ports on a hub. A bridge allows traffic to be segregated (albeit still on the same subnet). 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/c/w2hx-channel/videos -----Original Message----- From: cctalk On Behalf Of Grant Taylor via cctalk Sent: Tuesday, April 12, 2022 1:29 PM To: cctalk Subject: Re: Retro networking / WAN communities On 4/12/22 7:56 AM, Todd Goodman via cctalk wrote: > The big difference in my mind between bridge and switch is: > > ?* Switches learn what port given MACs are on and only sends unicast > ?? traffic destined for that MAC address on that port and not all > ?* Bridges send unicast traffic to all ports So what would differentiate the bridge (using your understanding) from a hub? -- Grant. . . . unix || die From w2hx at w2hx.com Tue Apr 12 12:31:31 2022 From: w2hx at w2hx.com (W2HX) Date: Tue, 12 Apr 2022 17:31:31 +0000 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> <7wtuaybz4k.fsf@junk.nocrew.org> <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> <7wbkx6b8w4.fsf@junk.nocrew.org> <211cd52a-72f1-7c60-d978-55acddd97009@spamtrap.tnetconsulting.net> Message-ID: Internet message processor (BBN I think) 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/c/w2hx-channel/videos -----Original Message----- From: cctech On Behalf Of Wayne S via cctech Sent: Tuesday, April 12, 2022 1:24 PM To: Grant Taylor Cc: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Retro networking / WAN communities What?s an IMP? Don?t know that acronym. Sent from my iPhone > On Apr 12, 2022, at 10:20, Grant Taylor wrote: > > ?On 4/12/22 10:11 AM, Wayne S wrote: >> Wiki says ethernet became commercially available in 1980 and invented in 1973. So if enet was 1980 what were routers routing 10 years earlier in 1970? > > I feel like IMPs were "routing" and could be considered "routers" long before Ethernet was a thing. > > > > -- > Grant. . . . > unix || die From paulkoning at comcast.net Tue Apr 12 12:44:19 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 13:44:19 -0400 Subject: Retro networking / WAN communities In-Reply-To: <2c56f2f7-d0b0-bfc6-b95f-48cb37590082@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> <2c56f2f7-d0b0-bfc6-b95f-48cb37590082@spamtrap.tnetconsulting.net> Message-ID: <6649A935-6E20-4982-9001-08B3D0D71936@comcast.net> > On Apr 12, 2022, at 1:25 PM, Grant Taylor via cctalk wrote: > > On 4/12/22 8:50 AM, Paul Koning via cctalk wrote: >> A device that doesn't do address learning and floods unicast frames is not a bridge but rather a non-standard piece hardware. > > I feel like a "hub" qualifies as "a device that doesn't do address learning and floods unicast frames". > > To me, the fundamental difference between a hub and a switch / bridge is address learning. > > I can't tell if your (quoted) statement is specific to /just/ bridges / switches or could include hubs. Your first comment addresses bridges directly, thus meaning that your second non-targeted comment might target more. In my experience, "hub" is a vague marketing term. It might mean a backplane into which networking modules are plugged -- the DEChub-90 and DEChub-900 are examples. It might mean a chassis accepting networking cards that offer repeater, bridging, or other services -- I think Chipcom and Cabletron used the term in that fashion. Non-learning layer 2 packet switching devices to me are hypothetical beast, I never met one and I'm glad I didn't. Building such a thing would be a silly thing to do in my view. So no, I don't think I would call that a "hub" because all the "hubs" I ever ran into were something different entirely. paul From tsg at bonedaddy.net Tue Apr 12 12:44:27 2022 From: tsg at bonedaddy.net (Todd Goodman) Date: Tue, 12 Apr 2022 13:44:27 -0400 Subject: Retro networking / WAN communities In-Reply-To: <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> Message-ID: <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> On 4/12/2022 1:28 PM, Grant Taylor via cctalk wrote: > On 4/12/22 7:56 AM, Todd Goodman via cctalk wrote: >> The big difference in my mind between bridge and switch is: >> >> ??* Switches learn what port given MACs are on and only sends unicast >> ??? traffic destined for that MAC address on that port and not all >> ??* Bridges send unicast traffic to all ports > > So what would differentiate the bridge (using your understanding) from > a hub? > > > To me a hub is a layer 1 device (physical layer) that doesn't look at the traffic at all while the bridge does look at the traffic and generally implements 802.1d Spanning Tree Protocol and processes BPDUs. Todd From paulkoning at comcast.net Tue Apr 12 12:47:28 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 13:47:28 -0400 Subject: Retro networking / WAN communities In-Reply-To: <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> Message-ID: <4AB3E1B2-9D3F-43DB-B11A-4733070CD8C3@comcast.net> > On Apr 12, 2022, at 1:44 PM, Todd Goodman via cctalk wrote: > > On 4/12/2022 1:28 PM, Grant Taylor via cctalk wrote: >> On 4/12/22 7:56 AM, Todd Goodman via cctalk wrote: >>> The big difference in my mind between bridge and switch is: >>> >>> * Switches learn what port given MACs are on and only sends unicast >>> traffic destined for that MAC address on that port and not all >>> * Bridges send unicast traffic to all ports >> >> So what would differentiate the bridge (using your understanding) from a hub? > To me a hub is a layer 1 device (physical layer) that doesn't look at the traffic at all while the bridge does look at the traffic and generally implements 802.1d Spanning Tree Protocol and processes BPDUs. For 802.3, a physical layer relay is called a repeater. Other LAN types, if they have such things, may use other names; for example FDDI calls it a concentrator. paul From paulkoning at comcast.net Tue Apr 12 12:49:46 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 13:49:46 -0400 Subject: Retro networking / WAN communities In-Reply-To: <211cd52a-72f1-7c60-d978-55acddd97009@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> <7wtuaybz4k.fsf@junk.nocrew.org> <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> <7wbkx6b8w4.fsf@junk.nocrew.org> <211cd52a-72f1-7c60-d978-55acddd97009@spamtrap.tnetconsulting.net> Message-ID: <866635C1-42F7-4661-A3CC-5DDF5B1DE0BE@comcast.net> > On Apr 12, 2022, at 1:20 PM, Grant Taylor via cctalk wrote: > > On 4/12/22 10:11 AM, Wayne S wrote: >> Wiki says ethernet became commercially available in 1980 and invented in 1973. So if enet was 1980 what were routers routing 10 years earlier in 1970? > > I feel like IMPs were "routing" and could be considered "routers" long before Ethernet was a thing. Exactly. For that matter, DECnet included routing before Ethernet came out (in Phase III, with DDCMP links). And Typeset-11 did routing before DECnet did, starting around 1977. I think the term used in the IMP days was "gateway" but by today's terminology they are routers. paul From paulkoning at comcast.net Tue Apr 12 13:05:45 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 14:05:45 -0400 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> <7wtuaybz4k.fsf@junk.nocrew.org> <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> <7wbkx6b8w4.fsf@junk.nocrew.org> <211cd52a-72f1-7c60-d978-55acddd97009@spamtrap.tnetconsulting.net> <866635C1-42F7-4661-A3CC-5DDF5B1DE0BE@comcast.net> Message-ID: Yes, that's the way the term was used by DEC. There have long been many things in our business that were called by multiple names. Gateway is one (router, protocol translator). Dataset (modem or file), file (file as we know it, disk drive) are other examples. paul > On Apr 12, 2022, at 2:01 PM, Wayne S wrote: > > Good clarification. > In my day, gateway was some unique device or software that provided access to a service or another non-standard device. > Think a device that dials out to batch send information to a specific service. > Router meant networking within the company. > Different times. > > Sent from my iPhone > >> On Apr 12, 2022, at 10:49, Paul Koning via cctalk wrote: >> >> ? >> >>> On Apr 12, 2022, at 1:20 PM, Grant Taylor via cctalk wrote: >>> >>>> On 4/12/22 10:11 AM, Wayne S wrote: >>>> Wiki says ethernet became commercially available in 1980 and invented in 1973. So if enet was 1980 what were routers routing 10 years earlier in 1970? >>> >>> I feel like IMPs were "routing" and could be considered "routers" long before Ethernet was a thing. >> >> Exactly. For that matter, DECnet included routing before Ethernet came out (in Phase III, with DDCMP links). And Typeset-11 did routing before DECnet did, starting around 1977. >> >> I think the term used in the IMP days was "gateway" but by today's terminology they are routers. >> >> paul >> From cclist at sydex.com Tue Apr 12 13:08:13 2022 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 12 Apr 2022 11:08:13 -0700 Subject: Retro networking / WAN communities In-Reply-To: <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> Message-ID: <938c70a8-c1ac-1318-b7dd-ed554e09a2f3@sydex.com> On 4/12/22 10:44, Todd Goodman via cctalk wrote: > To me a hub is a layer 1 device (physical layer) that doesn't look at > the traffic at all while the bridge does look at the traffic and > generally implements 802.1d Spanning Tree Protocol and processes BPDUs. Hub is a nebulous term. For example, I've got a couple of NS "Datamover" 10Base boxes that take the WAN connection via 10base2 and distribute it via 10BaseT; absolutely dumb boxes without any intelligence at all. I also have some Farallon 100baseT boxes that appear to provide filtering and logon for WAN connections. Of course, many hubs include NAT, port moderation, etc. Personally, I don't care, so long as the things work. --Chuck From bill.gunshannon at hotmail.com Tue Apr 12 13:14:48 2022 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Tue, 12 Apr 2022 14:14:48 -0400 Subject: TRS-80 Question In-Reply-To: References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> Message-ID: On 4/12/22 11:49, Peter Cetinski via cctalk wrote: >> >> On 4/12/22 6:37 AM, Bill Gunshannon via cctalk wrote: >>> So, this just gets more and more confusing. (Have I really been away >>> from all this for that long!!!) >>> I dug up the tech manuals for the two of them (buried deep in my >>> stacks of books) and compared them. And you are, of course, right. >>> Which just brings more questions. >>> Why do Model I cassette programs (not BASIC) not run on the Model III? >>> > > Model I machine language cassette programs will run just fine on the Model III given that the restrictions on direct hardware access mentioned are respected. OK. I was positive that I had tried this in the past without success but I don't trust me memory so much any more so I tried it again. > For example, for my game RoundUp!, you can load the 500 baud tape version on the Model I or Model III just fine. Of course, you need to specify ?L? for low rate baud of 500 at the Model III Cassette? prompt. The model I only supports 500 baud cassettes. I just loaded Tiny Pascal for the Model I into a Model III. Tape successfully loaded. Typed / and hit return. L3 ERROR. I may try something else just to see what happens, but being as Tiny Pascal is the program I want to work with, it really doesn't matter. :-) I have asked in other places but I guess I'll ask here, too. Does anyone have a copy of Tiny Pascal (a cassette program) for the Model III? While I still have my Model I version in one of my moves it appears I lost my Model III version. All I have is documentation, no tape. Has that particular program not managed to survive for some reason? bill From macro at orcam.me.uk Tue Apr 12 13:21:26 2022 From: macro at orcam.me.uk (Maciej W. Rozycki) Date: Tue, 12 Apr 2022 19:21:26 +0100 (BST) Subject: Retro networking / WAN communities In-Reply-To: <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> Message-ID: On Mon, 11 Apr 2022, Grant Taylor via cctalk wrote: > > I think "hub" is another word for "repeater" (just like "switch" is another > > word for "bridge"). > > Interesting. > > Do you know of any documentation, preferably not marketing materials, that > used "repeater" in lieu of "hub"? As I recall back in mid 1990s nobody around at the university used to call plain 10BASE2 repeaters hubs. We'd only call multiport 10BASE-T devices hubs (aka concentrators), where each port only serves one device in a point-to-point topology (i.e. no shared medium such as with 10BASE5 or 10BASE2). We had a bunch (4 or 5) of IIRC 5-port 10BASE2 repeaters for our network at our hall of residence. Each 10BASE2 port served ~20 hosts so as not to exceed 10BASE2's maximum segment length. I'm not sure anymore if the repeaters had an AUI port; I think they did, but if so, it wasn't used. They were connected into one network via a bridge, which was an 80286 PC equipped with a corresponding number of NE2000 clones and running a piece of DOS software called Kbridge. It was to reduce network congestion, which often happened anyway when multiple groups of people played networked (IPX) Doom all at a time. Also nobody would call a device a switch if it didn't do cut-through. We'd call devices doing store-and-forward only bridges; after all there's no actual circuit switching in store-and-forward. I guess these terms became fuzzier with time as non-techies started confusing them. FWIW, Maciej From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 13:51:36 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 12:51:36 -0600 Subject: Retro networking / WAN communities In-Reply-To: <6649A935-6E20-4982-9001-08B3D0D71936@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> <2c56f2f7-d0b0-bfc6-b95f-48cb37590082@spamtrap.tnetconsulting.net> <6649A935-6E20-4982-9001-08B3D0D71936@comcast.net> Message-ID: <6797bf55-534f-9d43-c866-62105dae5774@spamtrap.tnetconsulting.net> On 4/12/22 11:44 AM, Paul Koning wrote: > In my experience, "hub" is a vague marketing term. ... > > Non-learning layer 2 packet switching devices to me are hypothetical > beast, I never met one and I'm glad I didn't. Nope. Hubs are definitely not a marketing term, nor a hypothetical beast. See the quote from the following Cisco page. --8<-- Are an Ethernet switch and hub the same? No. While they are both examples of data network hardware, a hub is a Layer 1 device, which is part of the physical transport layer and acts as a broadcast/aggregator but does not manage any of the traffic. An Ethernet switch manages the flow of data, directing data it receives in one port to another port based on information in a data packet's header, namely the sending and receiving MAC addresses. The switching process significantly improves the efficiency of the network as opposed to a hub. -->8-- Link - What Is an Ethernet Switch? - https://www.cisco.com/c/en/us/products/switches/what-is-an-ethernet-switch.html#~q-a > Building such a thing would be a silly thing to do in my view. Well, it may be silly, but a non-learning device, or "hub", was ~> is very much a thing that was mass marketed and sold all over the place. Switches supplanted hubs for obvious reasons in the mid-to-late '90s. -- Grant. . . . unix || die From wrcooke at wrcooke.net Tue Apr 12 13:47:28 2022 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Tue, 12 Apr 2022 13:47:28 -0500 (CDT) Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <7w1qy3crxq.fsf@junk.nocrew.org> <998feb0a-4014-7680-4e7e-7585205ab6b7@spamtrap.tnetconsulting.net> <7wtuaybz4k.fsf@junk.nocrew.org> <14651803-4d27-d17b-598f-3d68e402a72d@spamtrap.tnetconsulting.net> <7wbkx6b8w4.fsf@junk.nocrew.org> <211cd52a-72f1-7c60-d978-55acddd97009@spamtrap.tnetconsulting.net> Message-ID: <161800946.1339629.1649789248646@email.ionos.com> > On 04/12/2022 12:42 PM Wayne S via cctech wrote: > > > Thanks for the info about IMP. > But now i?d have to question IMP routers being around in 1970 since the internet wasn?t around yet. > > The first response of "Interface" Message Processor is more correct. There was a LOT of networking before what we call the "Internet" now. It derived from the Arpanet in the 60s, which is where the IMPs were used. https://en.wikipedia.org/wiki/ARPANET#:~:text=The%20Advanced%20Research%20Projects%20Agency,technical%20foundation%20of%20the%20Internet. Will From paulkoning at comcast.net Tue Apr 12 14:05:45 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 15:05:45 -0400 Subject: Retro networking / WAN communities In-Reply-To: <6797bf55-534f-9d43-c866-62105dae5774@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> <2c56f2f7-d0b0-bfc6-b95f-48cb37590082@spamtrap.tnetconsulting.net> <6649A935-6E20-4982-9001-08B3D0D71936@comcast.net> <6797bf55-534f-9d43-c866-62105dae5774@spamtrap.tnetconsulting.net> Message-ID: > On Apr 12, 2022, at 2:51 PM, Grant Taylor via cctalk wrote: > > On 4/12/22 11:44 AM, Paul Koning wrote: >> In my experience, "hub" is a vague marketing term. ... >> Non-learning layer 2 packet switching devices to me are hypothetical beast, I never met one and I'm glad I didn't. > > Nope. Hubs are definitely not a marketing term, nor a hypothetical beast. > > See the quote from the following Cisco page. But that's a marketing document. > ... >> Building such a thing would be a silly thing to do in my view. > > Well, it may be silly, but a non-learning device, or "hub", was ~> is very much a thing that was mass marketed and sold all over the place. > > Switches supplanted hubs for obvious reasons in the mid-to-late '90s. That doesn't match how I see the history. From the DEC point of view, non-learning packet switches did not exist. We sold either real bridges, or routers, or (early on) repeaters. I never heard of a DEC customer using non-learning devices; if anyone had and ran into trouble I'm certain our answer would have been "please use a real bridge". paul From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 14:11:38 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 13:11:38 -0600 Subject: Retro networking / WAN communities In-Reply-To: <9778CCB9-9DE6-4A8D-859B-13B2E03B4454@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <9778CCB9-9DE6-4A8D-859B-13B2E03B4454@comcast.net> Message-ID: <48aee7c8-bb89-b85e-f27c-13b3be3c6866@spamtrap.tnetconsulting.net> On 4/12/22 11:41 AM, Paul Koning via cctalk wrote: > I don't know anything about the 3 Mb/s prototype other than that > it existed. When I speak of Ethernet and its "day 1" I mean 10 Mb/s > Ethernet as defined by the DEC/Intel/Xerox spec. Okay. Fair enough. I surmise that we're talking about Ethernet II a.k.a. the Digital / Intel / Xerox that was commercialized. > Repeaters are a core part of that spec, and they were among the first > wave of products delivered by DEC. I can see how the need for repeaters was learned during Ethernet research at Xerox PARC and incorporated into Ethernet II / DIX from the start. > I no longer remember. That's possible, or perhaps they were a number > of small segments each with a handful of stations on them. That would make /some/ sense. E.g. have a 10Base2 segment for a set of cubicles and then link the multiple segments together with a multi-port bridge. > That's true but only part of the story. For one thing, as I said, > both mechanisms were part of bridges from the start (at least from > the start of DEC's bridges, which may not be quite the very earliest > ever but certainly are the earliest significant ones). Fair enough. > The learning part of bridging is actually the hard part. ... I feel like the conceptual algorithm / logic is simple. I concede that implementing it within timing requirements could be non-trivial ~> difficult. > Spanning tree is indeed another algorithm / protocol, but it's a > control plane algorithm with relatively easy time constraints, so > it's just SMOP. I guess I always assumed that spanning tree came along /after/ and / or /independently/ of bridging / switching. After all, the BPDU in spanning tree is "Bridge ..." so that name tends to imply to me that it came about /after/ bridges were a thing on at least some level. > That rings a bell. Someone reminded me of 100Base-T4. T4 rings a bell for me. -- It reminds me of some references to T2 and T8. It seems as if there was great conflation between the number being reference to wires; 4 vs 8, and pairs; 2 vs 4, respectively. > In any case, there were two proposed, one that made it. The other > might have gone as far as one or two shipping products, but no further > than that. Yep. -- Grant. . . . unix || die From paulkoning at comcast.net Tue Apr 12 14:13:56 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 15:13:56 -0400 Subject: Retro networking / WAN communities In-Reply-To: <48aee7c8-bb89-b85e-f27c-13b3be3c6866@spamtrap.tnetconsulting.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <9778CCB9-9DE6-4A8D-859B-13B2E03B4454@comcast.net> <48aee7c8-bb89-b85e-f27c-13b3be3c6866@spamtrap.tnetconsulting.net> Message-ID: <7C582799-C241-44BF-BF3F-893D05506C10@comcast.net> > On Apr 12, 2022, at 3:11 PM, Grant Taylor via cctalk wrote: > > On 4/12/22 11:41 AM, Paul Koning via cctalk wrote: >> ... >> Spanning tree is indeed another algorithm / protocol, but it's a control plane algorithm with relatively easy time constraints, so it's just SMOP. > > I guess I always assumed that spanning tree came along /after/ and / or /independently/ of bridging / switching. > > After all, the BPDU in spanning tree is "Bridge ..." so that name tends to imply to me that it came about /after/ bridges were a thing on at least some level. No, definitely not. The DECbridge-100 included two critical elements: learning / selective forwarding, and spanning tree. Both were day-one features. paul From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 14:15:42 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 13:15:42 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <0219a394-486b-43d3-80d3-1d6f80721864@bonedaddy.net> <95E4A124-ABDA-4509-AD26-8FB41443B3F2@comcast.net> <2c56f2f7-d0b0-bfc6-b95f-48cb37590082@spamtrap.tnetconsulting.net> <6649A935-6E20-4982-9001-08B3D0D71936@comcast.net> <6797bf55-534f-9d43-c866-62105dae5774@spamtrap.tnetconsulting.net> Message-ID: On 4/12/22 1:05 PM, Paul Koning via cctalk wrote: > But that's a marketing document. Eh ... Maybe. Cisco has plenty of purely technical documentation on the same subject with effectively similar technical information. That was just the first link that I found that wasn't a "hub" in the social sense where people / community / etc gather to communicate; a la this mailing list is a hub of technical minds & discussion. > That doesn't match how I see the history. From the DEC point of view, > non-learning packet switches did not exist. We sold either real > bridges, or routers, or (early on) repeaters. I never heard of a DEC > customer using non-learning devices; if anyone had and ran into trouble > I'm certain our answer would have been "please use a real bridge". That may be the case inside the DEC ecosystem / community. I don't know. I do think "please use a real bridge" is definitely a sensible response. I know I've said "please use a switch instead of a hub" multiple times. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 14:17:57 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 13:17:57 -0600 Subject: Retro networking / WAN communities In-Reply-To: <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> Message-ID: <3737e8fc-71d6-fb8a-2060-03c27e02ff54@spamtrap.tnetconsulting.net> On 4/12/22 11:44 AM, Todd Goodman via cctalk wrote: > To me a hub is a layer 1 device (physical layer) that doesn't look at > the traffic at all while the bridge does look at the traffic and > generally implements 802.1d Spanning Tree Protocol and processes BPDUs. I think that you touch on a very germane point. Hubs operate at L1. Switches operate at L2 (and L1). Routers operate at L3 (and L2 and L1). I've seen MANY L2 switches that didn't implement STP. The quintessential Linksys / Netgear / Dlink 4~8 port switch comes to mind. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 14:24:26 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 13:24:26 -0600 Subject: Retro networking / WAN communities In-Reply-To: <938c70a8-c1ac-1318-b7dd-ed554e09a2f3@sydex.com> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> <938c70a8-c1ac-1318-b7dd-ed554e09a2f3@sydex.com> Message-ID: On 4/12/22 12:08 PM, Chuck Guzis via cctalk wrote: > Hub is a nebulous term. Yes and no. Hub can be a generic "connects things" a la. hub of wires. Or it can be a technical thing, e.g. layer 1 device. > For example, I've got a couple of NS "Datamover" 10Base boxes that > take the WAN connection via 10base2 and distribute it via 10BaseT; > absolutely dumb boxes without any intelligence at all. I believe there has to be some amount of intelligence, thus not absolutely dumb, in that it's connecting a WAN (quintessentially not Ethernet) with a disparate networking technology, Ethernet. The differences between the two require /some/ amount of intelligence. > I also have some Farallon 100baseT boxes that appear to provide > filtering and logon for WAN connections. That screams something more complex than a switch, much less hub, to me. In my opinion, it strongly shouts "router". > Of course, many hubs include NAT, port moderation, etc. Nope. Network Address Translation operates on the 3rd OSI layer, specifically Network Addresses. L2 switches (operating on source / destination MAC addresses) and L1 hubs don't understand, much less, alter the L3 network address. There are many people that use "hub" in an extremely generic sense of the word as something that connects things together. But is is absolutely not a technical term for what is being done. > Personally, I don't care, so long as the things work. Details matter. -- Grant. . . . unix || die From van.snyder at sbcglobal.net Tue Apr 12 14:26:35 2022 From: van.snyder at sbcglobal.net (Van Snyder) Date: Tue, 12 Apr 2022 12:26:35 -0700 Subject: Do you need a DLT-II drive? References: <9de2b2e0de8aee4d39e572b20723ddac5bb0596e.camel.ref@sbcglobal.net> Message-ID: <9de2b2e0de8aee4d39e572b20723ddac5bb0596e.camel@sbcglobal.net> I have a Quantum DLT-II drive that I'm no longer using. It has a 68-pin LVD/SE SCSI interface. It's yours if you send me a PDF for a Postal Service flat-rate box. The drive will fit in a medium box, but I have enough tape cartridges to pack into a large flat-rate box beside it. I'll throw in an PCI SCSI card if you need it. Van Snyder van.snyder at sbcglobal.net From jpstewart at personalprojects.net Tue Apr 12 14:45:28 2022 From: jpstewart at personalprojects.net (John-Paul Stewart) Date: Tue, 12 Apr 2022 15:45:28 -0400 Subject: Retro networking / WAN communities In-Reply-To: <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> Message-ID: <4037928c-e81d-8e89-7283-ab6a7df552aa@personalprojects.net> On 2022-04-12 09:49, Paul Koning via cctalk wrote: > > Does anyone still remember the other 100 Mb Ethernet-like proposal, I > think from HP, which added various types of complexity instead of simply > being a faster Ethernet? HP's proposal was called 100BaseVG, aka 100VG-AnyLAN, and could carry Token Ring frames in addition to Ethernet. https://en.wikipedia.org/wiki/100BaseVG From ylee at columbia.edu Tue Apr 12 14:11:11 2022 From: ylee at columbia.edu (Yeechang Lee) Date: Tue, 12 Apr 2022 12:11:11 -0700 Subject: TRS-80 Question In-Reply-To: <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> Message-ID: <25173.52943.965895.809836@dobie-old.ylee.org> Eric Dittman says: > There's a 2K hole in the Model I memory map above the ROM Is this the hole that causes stock Model I to not run CP/M? -- geo:37.783333,-122.416667 From wrcooke at wrcooke.net Tue Apr 12 14:15:23 2022 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Tue, 12 Apr 2022 14:15:23 -0500 (CDT) Subject: TRS-80 Question In-Reply-To: <25173.52943.965895.809836@dobie-old.ylee.org> References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> <25173.52943.965895.809836@dobie-old.ylee.org> Message-ID: <1631580960.593575.1649790923274@email.ionos.com> > On 04/12/2022 2:11 PM Yeechang Lee via cctech wrote: > > > Eric Dittman says: > > There's a 2K hole in the Model I memory map above the ROM > Is this the hole that causes stock Model I to not run CP/M? > The ROM at address 0 is the bigger issue. CP/M requires RAM starting at address 0. From cisin at xenosoft.com Tue Apr 12 14:46:07 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 12 Apr 2022 12:46:07 -0700 (PDT) Subject: TRS-80 Question In-Reply-To: <25173.52943.965895.809836@dobie-old.ylee.org> References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> <25173.52943.965895.809836@dobie-old.ylee.org> Message-ID: >> There's a 2K hole in the Model I memory map above the ROM On Tue, 12 Apr 2022, Yeechang Lee via cctech wrote: > Is this the hole that causes stock Model I to not run CP/M? NO. The problem with CP/M on TRS80 is that CP/M expects RAM from location 0 on up. Location 0 - FFh are used as a data structure for running programs, with location 100h and up as the "transient Program Area", where programs load and run. TRS80 has ROM in bottom 16K. There did exist MODIFIED CP/M ("FMG") that loaded above ROM, and ran programs that weren't too "hard-wired" to expect specific load location. Parasitic Engineering (Howard Fullmer) and Omikron Mapper both made sandwich boards for the model 1 that moved things (under software control) to run "real" CP/M. They both ALSO sold 8" drive conversions for the Expansion Interface. -- Grumpy Ol' Fred cisin at xenosoft.com From chris at groessler.org Tue Apr 12 15:09:41 2022 From: chris at groessler.org (Christian Groessler) Date: Tue, 12 Apr 2022 22:09:41 +0200 Subject: Retro networking / WAN communities In-Reply-To: <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> Message-ID: On 4/11/22 19:27, Paul Koning via cctalk wrote: > >> On Apr 11, 2022, at 1:02 PM, Grant Taylor via cctalk wrote: >> >> Hi, >> >> Does anyone know of any communities / mailing lists / newsgroups / et al. for retro networking / WAN technologies? >> >> I find myself interested in (at least) the following and would like to find others with similar (dis)interests to chat about things. >> >> - 10Base5 / 10Base2 / 10BaseT >> - ISDN >> - DSL / ADSL / SDSL / HDSL >> - T1 / E1 >> - ATM >> - Frame Relay >> - ARCnet >> - PSTN / PBX / PABX > I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). And I did ATM for a living for about 5 years, back around 1995, so I can still talk a bit of that. I should still have 2 ARCnet ISA cards somewhere.... From paulkoning at comcast.net Tue Apr 12 15:35:44 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Apr 2022 16:35:44 -0400 Subject: Retro networking / WAN communities In-Reply-To: <4037928c-e81d-8e89-7283-ab6a7df552aa@personalprojects.net> References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <4037928c-e81d-8e89-7283-ab6a7df552aa@personalprojects.net> Message-ID: <2D5E3927-8B0E-4E38-AF1C-4A391A0B5C05@comcast.net> > On Apr 12, 2022, at 3:45 PM, John-Paul Stewart via cctalk wrote: > > > On 2022-04-12 09:49, Paul Koning via cctalk wrote: >> >> Does anyone still remember the other 100 Mb Ethernet-like proposal, I >> think from HP, which added various types of complexity instead of simply >> being a faster Ethernet? > > HP's proposal was called 100BaseVG, aka 100VG-AnyLAN, and could carry > Token Ring frames in addition to Ethernet. Ah, that would certainly be one part of the explanation why it didn't go anywhere. Supporting Token Ring would add a vast amount of complexity for no real benefit. I noticed the Wikipedia article has a wrong and misleading description of the supposed "deterministic" behavior of token rings. It speaks of "consistent performance no matter how large the network became". That, of course, is nonsense. What is true is that, in the absence of errors, token rings have a hard upper bound on the time required to transmit the first frame in the NIC transmit queue. What is always unstated in the marketing documents making that claim is how large that upper bound is. I remember an IBM document that spent 30 or so pages saying "token ring good, ethernet bad". DEC, with some help from 3Com, wrote a detailed paragraph by paragraph refutation of that; I participated in creating that and have a copy somewhere. One of the points IBM made was that determinism claim. So we calculated the worst case transmit latency for a max size 802.5 ring. I don't remember the answer exactly; I'm pretty sure it was over a minute. FDDI is an entirely different protocol, with dramatically better latency at high load than 802.5. (Its ancestor is 802.4, not 802.5.) But even there, the max latency is surprisingly long. Ethernet, on the other hand, is nondeterministic (in the half duplex shared bus topology) but except at insanely high loads is much lower than the latency of any token ring. paul From cclist at sydex.com Tue Apr 12 16:03:41 2022 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 12 Apr 2022 14:03:41 -0700 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> <938c70a8-c1ac-1318-b7dd-ed554e09a2f3@sydex.com> Message-ID: On 4/12/22 12:24, Grant Taylor via cctalk wrote: > Details matter. I'll bow to the experts and refer to the things as a "boxes with n capabilities". That should pretty much cover the terrain. --Chuck From cctalk at gtaylor.tnetconsulting.net Tue Apr 12 16:11:39 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 12 Apr 2022 15:11:39 -0600 Subject: Retro networking / WAN communities In-Reply-To: References: <191f432f-31bc-f1e2-f7f0-f3b0d48d0d87@spamtrap.tnetconsulting.net> <1ACBAACF-2EC6-4A15-9BEA-B2093446B3F6@comcast.net> <70CADE59-5339-468A-A5A5-0773C03957D7@comcast.net> <7A18BB00-E58C-484D-921F-C98212E15316@comcast.net> <624edb54-53bb-36cf-25a3-fdbddd42d01d@spamtrap.tnetconsulting.net> <6B895291-4513-4CA0-9161-35E971E86892@comcast.net> <30e09160-3b48-24dc-5484-232df1af36e0@spamtrap.tnetconsulting.net> <28c0d3f3-f753-44d4-82d4-104b9450455c@bonedaddy.net> <938c70a8-c1ac-1318-b7dd-ed554e09a2f3@sydex.com> Message-ID: <70c01a64-9237-73d9-a2b0-171c7552a6dc@spamtrap.tnetconsulting.net> On 4/12/22 3:03 PM, Chuck Guzis via cctalk wrote: > I'll bow to the experts and refer to the things as a "boxes with in the blank>n capabilities". I'm definitely not an expert. Just some random on the Internet who has things to say. ;-) > That should pretty much cover the terrain. As some random on the Internet who has things to say I actually value "boxes with n capabilities" as it lets me know if I should treat the as a specific thing or a generic class description. E.g. Hoover brand vs Eureka hoover device. ;-) -- Grant. . . . unix || die From ryan at diskfutility.com Tue Apr 12 20:34:10 2022 From: ryan at diskfutility.com (Ryan Eisworth) Date: Tue, 12 Apr 2022 20:34:10 -0500 Subject: Looking for Atari Mega ST peripherals Message-ID: Hi folks, I'm looking for a keyboard and mouse for a Mega ST. Please contact me if you have either available. I'm in Texas, USA, 77833. Best, Ryan From doc at vaxen.net Tue Apr 12 21:33:08 2022 From: doc at vaxen.net (Doc Shipley) Date: Tue, 12 Apr 2022 21:33:08 -0500 Subject: Looking for Atari Mega ST peripherals In-Reply-To: References: Message-ID: <50D36AB4-7D27-4C0D-AEE5-8DD457CB800B@vaxen.net> On April 12, 2022 8:34:10 PM CDT, Ryan Eisworth via cctalk wrote: >Hi folks, > >I'm looking for a keyboard and mouse for a Mega ST. Please contact me if you have either available. I'm in Texas, USA, 77833. > >Best, >Ryan I have a mouse, and am in Texas. From shadoooo at gmail.com Wed Apr 13 00:35:46 2022 From: shadoooo at gmail.com (shadoooo) Date: Wed, 13 Apr 2022 05:35:46 +0000 (UTC) Subject: idea for a universal disk interface Message-ID: Hello, I'm a decent collector of big iron, aka mini computers, mainly DEC and DG. I'm often facing common problems with storage devices, magnetic discs and tapes are a little prone to give headaches after years, and replacement drives/media in case of a severe failure are unobtainable. In some cases, the ability to make a dump of the media, also without a running computer is very important. Whence the idea: realize an universal device, with several input/output interfaces, which could be used both as storage emulator, to run a computer without real storage, and as controller emulator, to read/write a media without a running computer. To reduce costs as much as possible, and to allow the better compatibility, the main board shall host enough electrical interfaces to support a large number of disc standard interfaces, ideally by exchanging only a personality adapter for each specific interface, i.e. connectors and few components. There are several orders of problems: - electrical signals, number and type (most disk employ 5V TTL or 3.3V TTL, some interfaces use differential mode for some faster signals?) - logical implementation: several electrical signals are used for a specific interface. These must be handled with correct timings - software implementation: the universal device shall be able to switch between interface modes and be controlled by a remote PC I suppose the only way to obtain this is to employ an FPGA for logic implementation of the interface, and a microprocessor running Linux to handle software management, data interchange to external (via Ethernet). This means a Xilinx Zynq module for instance. I know there are several ready devices based on cheaper microcontrollers, but I'm sure these can't support fast and tight timing required by hard disk interfaces (SMD-E runs at 24MHz). The main board should include a large enough array of bidirectional transceivers, possibly with variable voltage, to support as much interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point. The common factor determining what kind of disc interface can be support on hardware side is obviously the type of transceiver employed, for instance a SATA would require a differential serial channel, which could not be available. But most old electronic is based on TTL/CMOS 5V logic, so a large variety of computer generations should be doable. For the first phase, I would ask you to contribute with a list of interfaces which could be interesting to emulate, specially if these are similar to one from my list. I please submitters to send me by email or by web link when possible, detailed documentation about the interface they propose, so I can check if it could be doable and what kind of electrical signals are needed. Also detailed information about interfaced I listed is appreciated, as could give some detail I'm missing. Thanks Andrea From steven at malikoff.com Wed Apr 13 01:15:17 2022 From: steven at malikoff.com (steven at malikoff.com) Date: Wed, 13 Apr 2022 16:15:17 +1000 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <627c5d993ae9382433b1bf844ff63e07.squirrel@webmail04.register.com> shadoooo said > Hello, > I'm a decent collector of big iron, aka mini computers, mainly DEC and DG. > I'm often facing common problems with storage devices, magnetic discs and tapes are a little prone to give headaches after years, and replacement drives/media in case of a severe failure are unobtainable. > In some cases, the ability to make a dump of the media, also without a running computer is very important. > > Whence the idea: realize an universal device, with several input/output interfaces, which could be used both as storage emulator, to run a computer without real storage, and as controller emulator, to read/write a media without a running computer. > To reduce costs as much as possible, and to allow the better compatibility, the main board shall host enough electrical interfaces to support a large number of disc standard interfaces, ideally by exchanging only a personality adapter for each specific interface, i.e. connectors and few components.> > There are several orders of problems: > - electrical signals, number and type (most disk employ 5V TTL or 3.3V TTL, some interfaces use differential mode for some faster signals?) > - logical implementation: several electrical signals are used for a specific interface. These must be handled with correct timings > - software implementation: the universal device shall be able to switch between interface modes and be controlled by a remote PC > > I suppose the only way to obtain this is to employ an FPGA for logic implementation of the interface, and a microprocessor running Linux to handle software management, data interchange to external (via Ethernet). This means a Xilinx Zynq module for instance. > I know there are several ready devices based on cheaper microcontrollers, but I'm sure these can't support fast and tight timing required by hard disk interfaces (SMD-E runs at 24MHz). > > The main board should include a large enough array of bidirectional transceivers, possibly with variable voltage, to support as much interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point. > The common factor determining what kind of disc interface can be support on hardware side is obviously the type of transceiver employed, for instance a SATA would require a differential serial channel, which could not be available. > But most old electronic is based on TTL/CMOS 5V logic, so a large variety of computer generations should be doable. > > For the first phase, I would ask you to contribute with a list of interfaces which could be interesting to emulate, specially if these are similar to one from my list. > I please submitters to send me by email or by web link when possible, detailed documentation about the interface they propose, so I can check if it could be doable and what kind of electrical signals are needed. > Also detailed information about interfaced I listed is appreciated, as could give some detail I'm missing. The Diablo / Pertec interface was a popular industry standard. Here's a product (no connection) that implements it https://www.arraid.com/data-storage-products/product/aem-5c.html It would be great if there were open source or cheaper devices, maybe there are, I guess the Unibone can do this? (I don't have one yet) (btw I never actually subscribed to cctech but somehow my cctalk ones get echoed over there) From paulkoning at comcast.net Wed Apr 13 08:47:20 2022 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 13 Apr 2022 09:47:20 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <8F4B5C4A-B9CA-45C8-8580-CC1B7A051643@comcast.net> > On Apr 13, 2022, at 1:35 AM, shadoooo via cctalk wrote: > > Hello, > I'm a decent collector of big iron, aka mini computers, mainly DEC and DG. > I'm often facing common problems with storage devices, magnetic discs and tapes are a little prone to give headaches after years, and replacement drives/media in case of a severe failure are unobtainable. > In some cases, the ability to make a dump of the media, also without a running computer is very important. > > Whence the idea: realize an universal device, with several input/output interfaces, which could be used both as storage emulator, to run a computer without real storage, and as controller emulator, to read/write a media without a running computer. > To reduce costs as much as possible, and to allow the better compatibility, the main board shall host enough electrical interfaces to support a large number of disc standard interfaces, ideally by exchanging only a personality adapter for each specific interface, i.e. connectors and few components. > > There are several orders of problems: > - electrical signals, number and type (most disk employ 5V TTL or 3.3V TTL, some interfaces use differential mode for some faster signals?) > - logical implementation: several electrical signals are used for a specific interface. These must be handled with correct timings > - software implementation: the universal device shall be able to switch between interface modes and be controlled by a remote PC > > I suppose the only way to obtain this is to employ an FPGA for logic implementation of the interface, and a microprocessor running Linux to handle software management, data interchange to external (via Ethernet). This means a Xilinx Zynq module for instance. > I know there are several ready devices based on cheaper microcontrollers, but I'm sure these can't support fast and tight timing required by hard disk interfaces (SMD-E runs at 24MHz). Interesting idea. I wonder if it's cost-effective given the wide variety involved. It's surprising how tight timing you can manage with some modern programmable PIO blocks in devices like the Raspberry Pico or the BeagleBone Black. David Gesswein used the latter for his MFM emulator. That's not quite as fast as the SDM interface you mentioned. And I've used the Pico for some comms work, and realized at some point that it's fast enough to do Ethernet in software. Again, not quite as fast but close, and with care and under certain constraints that device (a $4 item) can indeed generate and receive 24 MHz waveforms. The thing that makes me wonder is the interfacing part. Disks might have anywhere from a few wires (SI port on DEC RA series disks) to dozens of wires (older disks like RP04 or RK05). Signal levels might be TTL at various voltages, differential, or even analog signals. Would you want to emulate the disk to formatter interface, or the formatter to controller interface? Another difficulty may be the low level format details. As I recall, there is a massive amount of research and code that went into David Gesswein's emulator to understand and reproduce the great variety of bit level layouts. If you're at a low enough level that might not matter, but if you want to manage data in terms of what the host thinks of as blocks, it does. Things might get very strange with more exotic stuff than you find at DEC -- for example, emulating IBM 360 disk drives with their variable length blocks and key/data capability would be interesting. Or CDC 6000 disks with sectors containing 322 12-bit words. So, it seems that building a device to emulate one class of disks with one class of interface, as David has done, is hard enough. Making something much more general is appealing, but I wonder if it's so hard, and requires so many parts, that it becomes infeasible and/or too expensive. paul From emu at e-bbes.com Wed Apr 13 10:12:21 2022 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 13 Apr 2022 11:12:21 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <29cdf08e-b5e8-8771-741f-37403839c9be@e-bbes.com> On 2022-04-13 01:35, shadoooo via cctalk wrote: > Hello, > For the first phase, I would ask you to contribute with a list of interfaces which could be interesting to emulate, specially if these are similar to one from my list. Just use a GIT repository for documents, schematics & layouts, or whatever. So this is not lost. From emu at e-bbes.com Wed Apr 13 10:12:21 2022 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 13 Apr 2022 11:12:21 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <29cdf08e-b5e8-8771-741f-37403839c9be@e-bbes.com> On 2022-04-13 01:35, shadoooo via cctalk wrote: > Hello, > For the first phase, I would ask you to contribute with a list of interfaces which could be interesting to emulate, specially if these are similar to one from my list. Just use a GIT repository for documents, schematics & layouts, or whatever. So this is not lost. From ggs at shiresoft.com Wed Apr 13 12:01:42 2022 From: ggs at shiresoft.com (Guy Sotomayor) Date: Wed, 13 Apr 2022 10:01:42 -0700 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: I've had a similar project in the works for a while (mainly for ESDI and SMD). I think the main issue you're going to face is that what you need to do for something like ESDI or SMD (or any of the bit serial interfaces) is going to be radically different than something like IDE or SCSI.? This is not just the interface signals but also what's needed in the FPGA as well as the embedded SW. For example, for the ESDI and SMD interface in order to meet the head switch times (1-2 microseconds) requires that a full cylinder be cached in HW.? Once you do that and look at the timings to move a max cylinder between the HW cache (that will serialize/de-serialize the data over the interface) and storage, you'll see that the only way to have any reasonable performance (e.g. not have seek times be > 40ms for *any* seek) is to cache the entire drive image in DRAM and lazily write back dirty tracks. I've been looking at the Xylinx Zynq SoCs for this (mainly the Zynq 7020 for single drive emulation and the Zynq Ultrascale+ for up to 4 drives).? In my case the HW, FPGA logic and SW will share significant portions but they will not be identical.? In my case there is no need for an external PC (just adds complexity) other than something to do basic configuration (e.g. drive parameters such as number of heads, number of cylinders, etc) which will actually be over USB/serial.? The actual persistent storage will be an SD card since all reading will be done at "boot time" and writes will be handled in a lazy manner (since the writes will first go to the DRAM based upon time or seek). It may also be sufficient for configuration purposes to have a file (text) on the SD card that defines the configuration so no external interactions would be necessary.? I'm still thinking about that one.? ;-) TTFN - Guy On 4/12/22 22:35, shadoooo via cctech wrote: > Hello, > I'm a decent collector of big iron, aka mini computers, mainly DEC and DG. > I'm often facing common problems with storage devices, magnetic discs and tapes are a little prone to give headaches after years, and replacement drives/media in case of a severe failure are unobtainable. > In some cases, the ability to make a dump of the media, also without a running computer is very important. > > Whence the idea: realize an universal device, with several input/output interfaces, which could be used both as storage emulator, to run a computer without real storage, and as controller emulator, to read/write a media without a running computer. > To reduce costs as much as possible, and to allow the better compatibility, the main board shall host enough electrical interfaces to support a large number of disc standard interfaces, ideally by exchanging only a personality adapter for each specific interface, i.e. connectors and few components. > > There are several orders of problems: > - electrical signals, number and type (most disk employ 5V TTL or 3.3V TTL, some interfaces use differential mode for some faster signals?) > - logical implementation: several electrical signals are used for a specific interface. These must be handled with correct timings > - software implementation: the universal device shall be able to switch between interface modes and be controlled by a remote PC > > I suppose the only way to obtain this is to employ an FPGA for logic implementation of the interface, and a microprocessor running Linux to handle software management, data interchange to external (via Ethernet). This means a Xilinx Zynq module for instance. > I know there are several ready devices based on cheaper microcontrollers, but I'm sure these can't support fast and tight timing required by hard disk interfaces (SMD-E runs at 24MHz). > > The main board should include a large enough array of bidirectional transceivers, possibly with variable voltage, to support as much interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point. > The common factor determining what kind of disc interface can be support on hardware side is obviously the type of transceiver employed, for instance a SATA would require a differential serial channel, which could not be available. > But most old electronic is based on TTL/CMOS 5V logic, so a large variety of computer generations should be doable. > > For the first phase, I would ask you to contribute with a list of interfaces which could be interesting to emulate, specially if these are similar to one from my list. > I please submitters to send me by email or by web link when possible, detailed documentation about the interface they propose, so I can check if it could be doable and what kind of electrical signals are needed. > Also detailed information about interfaced I listed is appreciated, as could give some detail I'm missing. > > Thanks > Andrea -- TTFN - Guy From tom94022 at comcast.net Wed Apr 13 13:51:03 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Wed, 13 Apr 2022 11:51:03 -0700 Subject: idea for a universal disk interface Message-ID: <008501d84f67$6e1279c0$4a376d40$@comcast.net> Interesting idea, there are three broad classes of HDD interfaces: 1. Dumb, that is serial data and parallel control 2. Intelligent parallel 3. Intelligent serial IMO if you can do dumb interraces then the others follow and given today?s technology I suspect it is feasible Within the dumb group there are several ?standards? with very similar controls but with different data rates and track formats * 2311/2314 including PCM versions * DEC RL0x which is pretty much the same as 2311/2314 except interface voltages and goes up to 200 MB disk pack drives, maybe higher * Diablo which is a simplified control version of RL0x * SMD which is an enhanced control version of RL0x * ST502/412/412 RLL which is a simplified control version of RL0x * ESDI which unfortunately serialized some of the control over the parallel interface otherwise similar to RL0x There are a few others like ANSI and CalComp but they are probably not worth investigating. I don?t know who invented the 1311 interface but IMHO he spawned an industry :) I think the maximum data rate is something on the order of 15 MHz so one ought to be able to read in an entire track at a sufficiently high data rate so as to be able to decode the data using an appropriately programmed DSP. Essentially all the hardware used for serializing/deserializing, formatting/deformatting and ECC in a traditional controller reduced to firmware Likewise there is a maximum number of control pins and only two voltage signaling levels (IBMs and DTL) so a combination of a programmable transceiver with a personality module ought to allow connection to and signaling with any physical device. Communicating control and status then is also a programming exercise Writing all the firmware would be a challenge but in the end you would be dealing with an array of blocks of good data, which would then be the starting point for tackling the intelligent interfaces which purport to start and stop at the same array of blocks of good data. I think u might be able to make this work with all the flavors of SCSI (with maybe a DSP on the personality module to handle the bus states) but good luck with intelligent serial interfaces. Just my 2 cents :) tom -----Original Message----- From: shadoooo [mailto:shadoooo at gmail.com] Sent: Tuesday, April 12, 2022 10:36 PM To: cctech at classiccmp.org Subject: idea for a universal disk interface Hello, I'm a decent collector of big iron, aka mini computers, mainly DEC and DG. I'm often facing common problems with storage devices, magnetic discs and tapes are a little prone to give headaches after years, and replacement drives/media in case of a severe failure are unobtainable. In some cases, the ability to make a dump of the media, also without a running computer is very important. Whence the idea: realize an universal device, with several input/output interfaces, which could be used both as storage emulator, to run a computer without real storage, and as controller emulator, to read/write a media without a running computer. To reduce costs as much as possible, and to allow the better compatibility, the main board shall host enough electrical interfaces to support a large number of disc standard interfaces, ideally by exchanging only a personality adapter for each specific interface, i.e. connectors and few components. There are several orders of problems: - electrical signals, number and type (most disk employ 5V TTL or 3.3V TTL, some interfaces use differential mode for some faster signals?) - logical implementation: several electrical signals are used for a specific interface. These must be handled with correct timings - software implementation: the universal device shall be able to switch between interface modes and be controlled by a remote PC I suppose the only way to obtain this is to employ an FPGA for logic implementation of the interface, and a microprocessor running Linux to handle software management, data interchange to external (via Ethernet). This means a Xilinx Zynq module for instance. I know there are several ready devices based on cheaper microcontrollers, but I'm sure these can't support fast and tight timing required by hard disk interfaces (SMD-E runs at 24MHz). The main board should include a large enough array of bidirectional transceivers, possibly with variable voltage, to support as much interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point. The common factor determining what kind of disc interface can be support on hardware side is obviously the type of transceiver employed, for instance a SATA would require a differential serial channel, which could not be available. But most old electronic is based on TTL/CMOS 5V logic, so a large variety of computer generations should be doable. For the first phase, I would ask you to contribute with a list of interfaces which could be interesting to emulate, specially if these are similar to one from my list. I please submitters to send me by email or by web link when possible, detailed documentation about the interface they propose, so I can check if it could be doable and what kind of electrical signals are needed. Also detailed information about interfaced I listed is appreciated, as could give some detail I'm missing. Thanks Andrea From cisin at xenosoft.com Wed Apr 13 16:27:27 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 13 Apr 2022 14:27:27 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022, shadoooo via cctech wrote: > The main board should include a large enough array of bidirectional > transceivers, possibly with variable voltage, to support as much > interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, > ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give > a starting point. Hmmm. rather than re-inventing the wheel, as we usually do, . . . It may be possible to accomplish a subset of those, specifically including Shugart floppy, ST506/412 MFM, RLL, ESDI, IDE, SASI, SCSI by repurposing certain commercial hardware. You would have a collection of boards, that you would remove/insert into a connector. The main board would have RAM, and a ROM for certain basic (and BASIC?) functions, but would load software for various modules and output results to and from one or more interfaces that remain connected. I don't doubt that you could design a far better system, but there already exists a crude version, ready to implement! It has a marginal power supply, and it has a poorly designed group of 8 62 pin connectors for the interfaces, although some of those would need to be dedicated for other functions of the device, including user interface hardware. Some software is already available, but some crude tools are available for creating more. It says "IBM", "5160" on the back panel label, although there were plenty of generic second sources. The updated "5170" version of it could be more easily set up even for USB. From cisin at xenosoft.com Wed Apr 13 16:51:10 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 13 Apr 2022 14:51:10 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: . . . and, if there is agreement to standardize the connection system for the "personality modules", then some of the other storage systems could be implemented, particularly including some of the tape systemmes. 'course, it would be a lot more fun, instead of the 62 pin card edge, to go with the 100 pin one that George Morrow and Howard Fullmer tried to standardize, . . . From paulkoning at comcast.net Wed Apr 13 18:57:45 2022 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 13 Apr 2022 19:57:45 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: > On Apr 13, 2022, at 5:27 PM, Fred Cisin via cctech wrote: > > On Wed, 13 Apr 2022, shadoooo via cctech wrote: >> The main board should include a large enough array of bidirectional transceivers, possibly with variable voltage, to support as much interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point. > > Hmmm. rather than re-inventing the wheel, as we usually do, . . . > > It may be possible to accomplish a subset of those, specifically including Shugart floppy, ST506/412 MFM, RLL, ESDI, IDE, SASI, SCSI by repurposing certain commercial hardware. > > You would have a collection of boards, that you would remove/insert into a connector. > > The main board would have RAM, and a ROM for certain basic (and BASIC?) functions, but would load software for various modules and output results to and from one or more interfaces that remain connected. > > I don't doubt that you could design a far better system, but there already exists a crude version, ready to implement! > > It has a marginal power supply, and it has a poorly designed group of 8 62 pin connectors for the interfaces, although some of those would need to be dedicated for other functions of the device, including user interface hardware. Some software is already available, but some crude tools are available for creating more. > > It says "IBM", "5160" on the back panel label, although there were plenty of generic second sources. > The updated "5170" version of it could be more easily set up even for USB. :-) But the main goal that was mentioned is device emulation, which existing products generally don't do. I see the idea as a generalized form of David Gesswein's MFM emulator, which is primarily a device emulator but is also capable of reading and writing devices to capture everything that's on them. The puzzle is how to make it do, say, 2311 emulation suitable to talk to an IBM/360, 1311 emulation for the decimal IBM 1620, or 844 emulation for a CDC 6600 -- to mention just a few of the more exotic cases. paul From cisin at xenosoft.com Wed Apr 13 19:12:50 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 13 Apr 2022 17:12:50 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: >> On Wed, 13 Apr 2022, shadoooo via cctech wrote: >>> The main board should include a large enough array of bidirectional transceivers, possibly with variable voltage, to support as much interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point. >> On Apr 13, 2022, at 5:27 PM, Fred Cisin via cctech wrote: >> Hmmm. rather than re-inventing the wheel, as we usually do, . . . >> . . . >> It says "IBM", "5160" on the back panel label, although there were >> plenty of generic second sources. >> The updated "5170" version of it could be more easily set up even for USB. On Wed, 13 Apr 2022, Paul Koning wrote: > :-) But the main goal that was mentioned is device emulation, which > existing products generally don't do. I see the idea as a generalized > form of David Gesswein's MFM emulator, which is primarily a device > emulator but is also capable of reading and writing devices to capture > everything that's on them. > > The puzzle is how to make it do, say, 2311 emulation suitable to talk to > an IBM/360, 1311 emulation for the decimal IBM 1620, or 844 emulation > for a CDC 6600 -- to mention just a few of the more exotic cases. You are absolutely right. I apologize for my error. My mindset is/was still stuck in the disk format conversion realm, of trying to get information (hopefully information in the form of files, not just data as track images) from alien media. And, more often than not, unidirectionally. I wasn't even thinking about the hardware emulation aspect, which is, in itself, fascinating. -- Grumpy Ol' Fred cisin at xenosoft.com From paulkoning at comcast.net Wed Apr 13 19:24:36 2022 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 13 Apr 2022 20:24:36 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: > On Apr 13, 2022, at 8:12 PM, Fred Cisin via cctech wrote: > > ... > My mindset is/was still stuck in the disk format conversion realm, of trying to get information (hopefully information in the form of files, not just data as track images) from alien media. > And, more often than not, unidirectionally. Indeed. Though even that is hard for the more exotic formats, if original controllers are unavailable. How would you read, for example, an IBM 1620 or CDC 6600 disk pack, given that the machine is hard to find and those that exists may not have the right controllers? But both are certainly doable with a "generic" track extractor engine. Turning track waveforms into data then becomes a matter of reverse engineering the encoding and constructing the software to do that. This may be hard, or not so hard. For example, if you wanted to do this for a CDC 844 disk pack (RP04/06 lookalike but with 322 12-bit word sectors) you'd get a lot of help from the fact that the source code of the disk controller firmware, and the manual describing it, have been preserved. Then as you said the real goal is to recover files, which means also having to reverse engineer the file system. That too may be documented adequately (it is in the 6600 case, for example) or not so much (does such documentation, or the OS source code, exists for the 1620 disk operating system?). paul From cclist at sydex.com Wed Apr 13 19:46:48 2022 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 13 Apr 2022 17:46:48 -0700 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <29783f9c-ed4b-bd7d-677c-3eab1e262558@sydex.com> I'll only mention that there were ICs that could interface to both MFM/ST506 hard drives as well as floppies (System/3 MFM). An example would be the SMC HDC9234, "Universal Disk Controller". Pretty cool chip for the time; has full 24 bit DMA address capability. But different register/controller setup than the stock PC AT. --Chuck From cisin at xenosoft.com Wed Apr 13 20:45:07 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 13 Apr 2022 18:45:07 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022, Paul Koning wrote: > Indeed. Though even that is hard for the more exotic formats, if > original controllers are unavailable. How would you read, for example, > an IBM 1620 or CDC 6600 disk pack, given that the machine is hard to > find and those that exists may not have the right controllers? But both > are certainly doable with a "generic" track extractor engine. Turning > track waveforms into data then becomes a matter of reverse engineering > the encoding and constructing the software to do that. This may be > hard, or not so hard. For example, if you wanted to do this for a CDC > 844 disk pack (RP04/06 lookalike but with 322 12-bit word sectors) you'd > get a lot of help from the fact that the source code of the disk > controller firmware, and the manual describing it, have been preserved. > > Then as you said the real goal is to recover files, which means also > having to reverse engineer the file system. That too may be documented > adequately (it is in the 6600 case, for example) or not so much (does > such documentation, or the OS source code, exists for the 1620 disk > operating system?). Some projects are well beyond the reach of even the most insane of us. I don't think that any of us here today have the ability to build a replacement drive from scratch. Even with full access to the original construction documents. Now, if we had NSA level of facilities, . . . It certainly seems that it would be THEORETICALLY POSSIBLE, with an extreme budget, to build a high resolution device similar to the 3M Magnetic Tape viewer, . . . https://blog.adafruit.com/2020/03/01/the-magnetic-tape-viewer-see-the-sound-on-a-tape/ . . . and use it to make optical imaging of the magnetic recording, followed by non-trivial analysis to decode that into track images, and then ultimately deciphering the encoding, track structure, and then directory structure, . . . It is certainly not feasible now, but someday, . . . I have a RAMAC platter! It is seriously FAR too damaged to consider restoring it to usable form. I was also told that it was extensively "degaussed" when it was discarded (possibly by Zellerbach Paper). 100 cylinders (with 100 heads in assembled structure), holding 5 million 6 bit characters, or a bit less than 100K per platter. So, I am making a 24" patio table out of it (under 3/8" tempered glass). http://www.ed-thelen.org/RAMAC/RAMAC_Plaque_v40.pdf When Khrshchev was denied access to go to Disneyland, they took him on a tour of the RAMAC factory, "to make up for it". _I_ would rather be at the RAMAC factory in 1959 than at Disneyland, but the Khrushchevs were disappointed. -- Grumpy Ol' Fred cisin at xenosoft.com From bear at typewritten.org Wed Apr 13 22:11:40 2022 From: bear at typewritten.org (r.stricklin) Date: Wed, 13 Apr 2022 20:11:40 -0700 Subject: idea for a universal disk interface In-Reply-To: <008501d84f67$6e1279c0$4a376d40$@comcast.net> References: <008501d84f67$6e1279c0$4a376d40$@comcast.net> Message-ID: > On Apr 13, 2022, at 11:51 AM, Tom Gardner via cctech wrote: > > There are a few others like ANSI and CalComp but they are probably not worth investigating. > They are if you?re someone who has a machine using one of these interfaces, or e.g. the 40-pin ?IMI bus?, or whatever else. ok bear. From jfoust at threedee.com Thu Apr 14 06:34:52 2022 From: jfoust at threedee.com (John Foust) Date: Thu, 14 Apr 2022 06:34:52 -0500 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <20220414113740.466164E6BF@mx2.ezwind.net> At 08:45 PM 4/13/2022, Fred Cisin via cctalk wrote: >It certainly seems that it would be THEORETICALLY POSSIBLE, with an extreme budget, to build a high resolution device similar to the 3M Magnetic Tape viewer, . . . https://blog.adafruit.com/2020/03/01/the-magnetic-tape-viewer-see-the-sound-on-a-tape/ And how often do those antique viewers come up on eBay and at what price? Modern ones are for sale for about $120: https://store.arnoldmagnetics.com/product/284/magnetic-viewer-b-1022 But you can't really use an optical method, right? You need to scan the field another way. And if you set a limit on disk platter tech to anything made before 1985, what's the magnetic resolution you'd need and what would you need to detect? Could the reconstruction be software-based, reconstructing from data gathered while scanning X-Y across surfaces using a mechanism not unlike a scanner or 3D printer? Or would you need to scan like the flying head that wrote the data back then? >So, I am making a 24" patio table out of it (under 3/8" tempered glass). >http://www.ed-thelen.org/RAMAC/RAMAC_Plaque_v40.pdf A rare item. How many others have you seen in the wild? - John From holm at freibergnet.de Thu Apr 14 07:27:26 2022 From: holm at freibergnet.de (Holm Tiffe) Date: Thu, 14 Apr 2022 14:27:26 +0200 Subject: DEC DC319A DLART (DL11 Compatible Asynchronous Receiver-Transmitter) In-Reply-To: <006c01d83e25$f38150c0$da83f240$@gmail.com> References: <006c01d83e25$f38150c0$da83f240$@gmail.com> Message-ID: pbirkel--- via cctalk wrote: > In case anyone else has been looking some of these, there is a listing for > multiple tubes-of-11 on eBay at a moderate price: > > > > https://www.ebay.com/itm/123710245814 > > QTY-11 PCS. AMI SEMICONDUCTOR DC319 C04090 Integrated Circuit - (UIC > 40378901) I've bought 11 pcs DC319A from the source above but need only 4 pcs. for my self. In the meantime I've sold 2 pcs for 8,50?/peace + shipping to a guy hiere in Germany. 8,18?/peace is the price I got myself including shipping and border taxes. I still have 5 pcs. left for sale for interested People from the euopean side of the pond. Just mail me if you are interested.. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583 info at tsht.de Fax +49 37292 709779 Tel +49 37292 709778 Mobil: 0172 8790 741 From lproven at gmail.com Thu Apr 14 09:10:22 2022 From: lproven at gmail.com (Liam Proven) Date: Thu, 14 Apr 2022 16:10:22 +0200 Subject: Looking for Atari Mega ST peripherals In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 at 03:42, Ryan Eisworth via cctalk wrote: > > Hi folks, > > I'm looking for a keyboard and mouse for a Mega ST. Please contact me if you have either available. I'm in Texas, USA, 77833. I have a keyboard. Possible snag: I live in Prague, Czechia. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From jfoust at threedee.com Thu Apr 14 09:45:29 2022 From: jfoust at threedee.com (John Foust) Date: Thu, 14 Apr 2022 09:45:29 -0500 Subject: idea for a universal disk interface In-Reply-To: <20220414113740.466164E6BF@mx2.ezwind.net> References: <20220414113740.466164E6BF@mx2.ezwind.net> Message-ID: <20220414144546.2ACE227392@mx1.ezwind.net> Magnetic visualizers also discussed here: http://qicreader.blogspot.com/p/track-visualization.html - John From paulkoning at comcast.net Thu Apr 14 08:26:14 2022 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 14 Apr 2022 09:26:14 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <73ECE2D8-1D6C-4B78-B5EC-5F0AD1C2DD7E@comcast.net> > On Apr 13, 2022, at 9:45 PM, Fred Cisin via cctech wrote: > > On Wed, 13 Apr 2022, Paul Koning wrote: >> Indeed. Though even that is hard for the more exotic formats, if original controllers are unavailable. How would you read, for example, an IBM 1620 or CDC 6600 disk pack, given that the machine is hard to find and those that exists may not have the right controllers? But both are certainly doable with a "generic" track extractor engine. Turning track waveforms into data then becomes a matter of reverse engineering the encoding and constructing the software to do that. This may be hard, or not so hard. For example, if you wanted to do this for a CDC 844 disk pack (RP04/06 lookalike but with 322 12-bit word sectors) you'd get a lot of help from the fact that the source code of the disk controller firmware, and the manual describing it, have been preserved. >> >> Then as you said the real goal is to recover files, which means also having to reverse engineer the file system. That too may be documented adequately (it is in the 6600 case, for example) or not so much (does such documentation, or the OS source code, exists for the 1620 disk operating system?). > > > Some projects are well beyond the reach of even the most insane of us. > > I don't think that any of us here today have the ability to build a replacement drive from scratch. Even with full access to the original construction documents. > > Now, if we had NSA level of facilities, . . . I don't think a 1970s era disk drive replica is quite as hard as you suggest. In my comment I wasn't actually thinking of that, but rather of the possibility that you might have a drive and packs, but no computer to connect the drive to. That said, consider what, say, a 1311 looks like. It's a spindle and a head carriage, each with the levels of precision you would find on a good quality lathe. That suggests the guts of a small CNC lathe, or the building blocks of such a thing, could be put to work for this. One data point: I remember when our RC11 spindle bearings failed (in college, 1974). DEC FS was called in, the tech decided to look for a low cost solution since the machine was not under contract. The normal procedure would have been to replace the spindle motor, of course. Instead, he disassembled the drive, took the motor to Appleton Motor Service Co., which pulled off the failed bearings and pressed on new ones, reinstalled the spindle motor, presto, good as new. He didn't even have to reformat the drive, all the data on it remained intact. So the tolerances on drives of that era are not all that severe, not out of reach for ordinary skilled machinists. paul From mjd.bishop at emeritus-solutions.com Thu Apr 14 10:14:53 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Thu, 14 Apr 2022 15:14:53 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working In-Reply-To: References: <152e419edf7e488fbe75b70d7e259e1b@WINHEXBEEU125.win.mail> Message-ID: <6065d51a786c4734bd8b261b78c35bee@WINHEXBEEU125.win.mail> Hi Bill Back with a suplementary query. Do you have a pin out for the Fanuc 50 way ribbon cable which goes to the BTR. As you may have read the reader electronics in my PPR look to be dead. However, probing signals in the PPR box does not look trivial : poor access, no schematics and the comparators are not evident. Consequently, in the first instance, I'm following in your footsteps with an A13B-0070-B001; the interface card is a A20B-0007-0750-07B. Similar, but different to your reel to reel unit. With four quad comparators on an exposed board it looks ideal for investigation and idc (hopefully) house training - the question is can I skip the reverse engineering phase. Thereafter, back to the PPR. If the DosTek was not 5 hours behind and limitless import hassle in prospect, I would consider using it as a test fixture. Best Regards Martin -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Bill Degnan via cctalk Sent: 10 April 2022 00:14 To: Eric Moore ; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fanuc PPR - Paper Tape Punch, Printer and Reader : Not quite working I have a dostek 440a for sale and notes about my fanuc tape unit here. https://www.vintagecomputer.net/fanuc/index.cfm On Sat, Apr 9, 2022, 6:51 PM Eric Moore via cctalk wrote: > Hi Martin, I use the PPR for all kinds of paper tape shennanigans. > > https://youtu.be/hGr0F9a7x1A > > Remove all but the first jumper, and that may help with your issues. I > found at one point the jumper settings, but will need to search. > > -Eric > > > > On Sat, Apr 9, 2022, 4:56 PM Martin Bishop via cctalk < > cctalk at classiccmp.org> > wrote: > > > A nicely made yellow box with a rather poor manual - both lost in > > translation and limited in scope. > > > > Working on setting one to work, but can't get anything out of the > > serial port. In drives the punch, and the punched data verifies > > (based on a > QL). > > In also drives the printer, although somewhat garbled, perhaps due > > to BCD coding or perhaps due to invalid parity (which is configured > > as no > check). > > The reader 'reads' tape both in response to X/ON over RS232 and in > response > > to front panel keys. However, nothing is emitted onto 232. The D25 > > - > D-9 > > transition has all the RTS/CTS and DSR/DTR/DCD lines knitted > appropriately > > and indicating 'correctly' on blinkenlites. Interestingly, on long > > test tapes the reader does not fall off the end but stops, > > repeatably after > ~49" > > which is remarkably close to 512 octets. Finally, the CNC > > termination octets : % (ASCII) and 0x80 (BCD : RS-244) don't seem to > > impress the > reader > > - nothing changes. > > > > Specific queries: > > - Are there any magic control codes or handshaking rituals to coax > > data out of the reader > > - Is the PPR to CNC Controller interface protocol manual available > > as pdf > > - Where can I find drawings for the PPR's electronics, most > > importantly the main board (with its 8031) > > - Suggestions on how to proceed with setting to work / fault > > diagnosis > > - Has anyone house trained one of these to read PDP-11 absolute > > binary tapes, their target market was G code (text) > > > > Martin > > > From tom94022 at comcast.net Thu Apr 14 10:55:02 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Thu, 14 Apr 2022 08:55:02 -0700 Subject: idea for a universal disk interface In-Reply-To: References: <008501d84f67$6e1279c0$4a376d40$@comcast.net> Message-ID: <000901d85018$0397b220$0ac71660$@comcast.net> The IMI 7710 34 pin flat cable interface is a variant on the SMD dumb interface which could be controlled by a UDI (universal disk interface) if someone cared enough to build an adapter and then program the UDI to deal with IMI's specific track format and peculiar command/status protocol. CalComp would be easier, but the question remains would either be worth the effort given their relatively low unit shipments compared to the other interfaces? Tom -----Original Message----- From: r.stricklin [mailto:bear at typewritten.org] Sent: Wednesday, April 13, 2022 8:12 PM To: t.gardner at computer.org; Tom Gardner; General Discussion: On-Topic Posts Subject: Re: idea for a universal disk interface > On Apr 13, 2022, at 11:51 AM, Tom Gardner via cctech wrote: > > There are a few others like ANSI and CalComp but they are probably not worth investigating. > They are if you?re someone who has a machine using one of these interfaces, or e.g. the 40-pin ?IMI bus?, or whatever else. ok bear.= From dkelvey at hotmail.com Thu Apr 14 12:47:45 2022 From: dkelvey at hotmail.com (dwight) Date: Thu, 14 Apr 2022 17:47:45 +0000 Subject: phishing increase lately Message-ID: I've been getting a bunch of "release of lien waiver" messages lately. I've not been opening the click bate. I'm just wondering if anyone else is getting them. I don't know what nasty is attached as I don't have a secure system to look at it. Dwight From paulkoning at comcast.net Thu Apr 14 12:56:34 2022 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 14 Apr 2022 13:56:34 -0400 Subject: phishing increase lately In-Reply-To: References: Message-ID: <626250DF-6637-4E4E-8340-5D2D44E55A25@comcast.net> What, on this list? I haven't seen any of that. I get a large amount of dishonest mail; much of it is caught by my "send this immediately to trash without reading it" filter rules. Like you, I have no idea what's attached, simply because I have no interest in investigating the machinations of criminal elements on the net. paul > On Apr 14, 2022, at 1:47 PM, dwight via cctalk wrote: > > I've been getting a bunch of "release of lien waiver" > messages lately. > I've not been opening the click bate. I'm just wondering if anyone else is getting them. > I don't know what nasty is attached as I don't have a secure system to look at it. > Dwight > From dkelvey at hotmail.com Thu Apr 14 13:08:43 2022 From: dkelvey at hotmail.com (dwight) Date: Thu, 14 Apr 2022 18:08:43 +0000 Subject: phishing increase lately In-Reply-To: <626250DF-6637-4E4E-8340-5D2D44E55A25@comcast.net> References: <626250DF-6637-4E4E-8340-5D2D44E55A25@comcast.net> Message-ID: I was just wondering if I was the only one. It may have been through someplace else I've been at. I just wanted to send the warning. I've seen 3 in the last day. I must be on someone's list. Dwight ________________________________ From: Paul Koning Sent: Thursday, April 14, 2022 10:56 AM To: dwight ; cctalk at classiccmp.org Subject: Re: phishing increase lately What, on this list? I haven't seen any of that. I get a large amount of dishonest mail; much of it is caught by my "send this immediately to trash without reading it" filter rules. Like you, I have no idea what's attached, simply because I have no interest in investigating the machinations of criminal elements on the net. paul > On Apr 14, 2022, at 1:47 PM, dwight via cctalk wrote: > > I've been getting a bunch of "release of lien waiver" > messages lately. > I've not been opening the click bate. I'm just wondering if anyone else is getting them. > I don't know what nasty is attached as I don't have a secure system to look at it. > Dwight > From barythrin at gmail.com Thu Apr 14 13:28:57 2022 From: barythrin at gmail.com (John Herron) Date: Thu, 14 Apr 2022 13:28:57 -0500 Subject: phishing increase lately In-Reply-To: References: <626250DF-6637-4E4E-8340-5D2D44E55A25@comcast.net> Message-ID: I think my mail client/provider catches a lot of that before I see it. I haven't seen that specific spam though, although our email addresses are scrapeable via the archives. A necessary evil though since I think the archives are a great service for folks. On Thu, Apr 14, 2022, 1:17 PM dwight via cctalk wrote: > I was just wondering if I was the only one. It may have been through > someplace else I've been at. > I just wanted to send the warning. I've seen 3 in the last day. > I must be on someone's list. > Dwight > > ________________________________ > From: Paul Koning > Sent: Thursday, April 14, 2022 10:56 AM > To: dwight ; cctalk at classiccmp.org < > cctalk at classiccmp.org> > Subject: Re: phishing increase lately > > What, on this list? I haven't seen any of that. > > I get a large amount of dishonest mail; much of it is caught by my "send > this immediately to trash without reading it" filter rules. Like you, I > have no idea what's attached, simply because I have no interest in > investigating the machinations of criminal elements on the net. > > paul > > > On Apr 14, 2022, at 1:47 PM, dwight via cctalk > wrote: > > > > I've been getting a bunch of "release of lien waiver" > > messages lately. > > I've not been opening the click bate. I'm just wondering if anyone else > is getting them. > > I don't know what nasty is attached as I don't have a secure system to > look at it. > > Dwight > > > > From jwsmail at jwsss.com Thu Apr 14 14:04:08 2022 From: jwsmail at jwsss.com (jim stephens) Date: Thu, 14 Apr 2022 12:04:08 -0700 Subject: phishing increase lately In-Reply-To: References: <626250DF-6637-4E4E-8340-5D2D44E55A25@comcast.net> Message-ID: The list doesn't send any of the emails, but I get forged emails that were harvested from someone with a folder full of different emails. They show up with all the addresses, a lot of them email addresses from here, all in the From: or CC: field, which the list mail server never does. I've not seen them, but you getting the spam is the luck of the draw having a list posts of yours with the email address in someones folder that was scanned. Paul? said he'd not seen any, because by luck he didn't have an email in the email client for whoever got scanned. I get them from a couple of different email lists that pinched my address, and is probably now sold bulk along with the harvested address. Again the only relation to this list was that your email post address was harvested from an email on someones email client.? The actual spams don't get sent thru the list out to all of us.? I've seen very little of that in a long time if any. thanks Jim On 4/14/2022 11:08 AM, dwight via cctalk wrote: > I was just wondering if I was the only one. It may have been through someplace else I've been at. > I just wanted to send the warning. I've seen 3 in the last day. > I must be on someone's list. > Dwight From cisin at xenosoft.com Thu Apr 14 16:28:36 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 14 Apr 2022 14:28:36 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: <20220414113740.466164E6BF@mx2.ezwind.net> References: <20220414113740.466164E6BF@mx2.ezwind.net> Message-ID: >> It certainly seems that it would be THEORETICALLY POSSIBLE, with an >> extreme budget, to build a high resolution device similar to the 3M >> Magnetic Tape viewer, . . . >> https://blog.adafruit.com/2020/03/01/the-magnetic-tape-viewer-see-the-sound-on-a-tape/ On Thu, 14 Apr 2022, John Foust via cctalk wrote: > And how often do those antique viewers come up on eBay and at what price? > Modern ones are for sale for about $120: > https://store.arnoldmagnetics.com/product/284/magnetic-viewer-b-1022 Alas, although still a lot of it around, magnetic recording is not as common as it once was, and increasingly, new technology is solid state. So, there isn't any where near as much incentive to build devices other than as novelties. > But you can't really use an optical method, right? You need to scan > the field another way. If the entire artifact were drenched with magnetic disclosing fluid, then it could be a simple optical capture. But the 3M device is truly non-destructive. It is only a tiny window. I am not aware of any 8" diameter versions of it. > And if you set a limit on disk platter tech to anything made before 1985, > what's the magnetic resolution you'd need and what would you need to detect? 1985 would include 96tpi "1.2M" "high density", 720K 3.5" (135tpi), and hard disks with at least 600 cylinders. > Could the reconstruction be software-based, reconstructing from data > gathered while scanning X-Y across surfaces using a mechanism not > unlike a scanner or 3D printer? Or would you need to scan like > the flying head that wrote the data back then? Yes, if there is a good clean opticl image, then the software would have to clean it up, including filling in by context for any uncertain spots, and convert the concentric circles in the image into an array of lines (tracks), decode the flux transition data into bit patterns (with a basic understanding of FM, MFM, GCR, and a few flavors of RLL). At that point, you would have a disk image comparable to what could be obtained by examining the disk in a drive. RAMAC platter: >> So, I am making a 24" patio table out of it (under 3/8" tempered glass). >> http://www.ed-thelen.org/RAMAC/RAMAC_Plaque_v40.pdf > A rare item. How many others have you seen in the wild? This is the only one that I have seen. I'm sure most decent sized museums have one, or even an assembled multi-platter (FIFTY-TWO!) system. I didn't even know that it was RAMAC until Mike Albaugh told me. Wil Price had it at Merritt College in the late 1960s, in the 1401 room, and brought it along when the college moved up onto the hill. I used it, core planes, cards, etc. in small history component of some of the classes that I taught. By the time that I was ready to retire (constructive discharge), the college shifted its focus from programming to "Remedial Computer Literacy For The Digital SweatShop", so I was the only one who could appreciate it. -- Grumpy Ol' Fred cisin at xenosoft.com From a.carlini at ntlworld.com Thu Apr 14 16:36:58 2022 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Thu, 14 Apr 2022 22:36:58 +0100 Subject: AlphaServer 2100s available In-Reply-To: <1ae801d84e82$d821d300$88657900$@gmail.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> Message-ID: <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> On 12/04/2022 16:34, Dave Wade G4UGM via cctalk wrote: > Folks, > Does no one fancy a go at this. Had zero interest... > Dave (OFFLIST, I think) I'm assuming the machine is safe, at least for the moment? I've actually got less room now than when I had to let it go, so hopefully it can just sit in a corner and be a useful table end or something for a while? I'm currently struggling with a uVAX 3600 PSu and a VAX 4000 PSU, so if I ever fix those, maybe I can help with the AS2100 ... Antonio -- Antonio Carlini antonio at acarlini.com From cisin at xenosoft.com Thu Apr 14 18:26:42 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 14 Apr 2022 16:26:42 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: <20220414144546.2ACE227392@mx1.ezwind.net> References: <20220414113740.466164E6BF@mx2.ezwind.net> <20220414144546.2ACE227392@mx1.ezwind.net> Message-ID: On Thu, 14 Apr 2022, John Foust via cctalk wrote: > Magnetic visualizers also discussed here: > http://qicreader.blogspot.com/p/track-visualization.html Thank you. That is what I was looking for. It doesn't imply current existence of anything already coupled with a digital camera, nor particularly suitable for an X/Y positioning system (such as a repurposed plodd^H^Htter) for scanning. Certainly possible. From a.carlini at ntlworld.com Thu Apr 14 19:10:41 2022 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Fri, 15 Apr 2022 01:10:41 +0100 Subject: AlphaServer 2100s available In-Reply-To: <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> Message-ID: On 14/04/2022 22:36, Antonio Carlini via cctalk wrote: > > (OFFLIST, I think) > I will learn to get this right eventually :-) -- Antonio Carlini antonio at acarlini.com From cctalk at gtaylor.tnetconsulting.net Thu Apr 14 19:55:59 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Thu, 14 Apr 2022 18:55:59 -0600 Subject: AlphaServer 2100s available In-Reply-To: References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> Message-ID: <57c7c71f-f86b-c507-073a-8fad79cbca83@spamtrap.tnetconsulting.net> On 4/14/22 6:10 PM, Antonio Carlini via cctalk wrote: > I will learn to get this right eventually :-) Some (if not many) of those that do eventually learn how to do it still make mistakes. So, try to do it correct, but be accepting of those that oops. ;-) Read: Don't beat yourself up for a mistake that we all have or will make. -- Grant. . . . unix || die From aperry at snowmoose.com Thu Apr 14 20:34:33 2022 From: aperry at snowmoose.com (Alan Perry) Date: Thu, 14 Apr 2022 18:34:33 -0700 Subject: AlphaServer 2100s available In-Reply-To: <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> Message-ID: <103c62e6-2fc4-cb85-258e-0ec0a058962d@snowmoose.com> What is an AlphaServer 2100 worth? There was one at RePC in Seattle a couple weeks ago and I was thinking about purchasing it. On 4/14/22 2:36 PM, Antonio Carlini via cctalk wrote: > On 12/04/2022 16:34, Dave Wade G4UGM via cctalk wrote: >> Folks, >> Does no one fancy a go at this. Had zero interest... >> Dave > > (OFFLIST, I think) > > I'm assuming the machine is safe, at least for the moment? > > I've actually got less room now than when I had to let it go, so > hopefully it can just sit in a corner and be a useful table end or > something for a while? > > I'm currently struggling with a uVAX 3600 PSu and a VAX 4000 PSU, so > if I ever fix those, maybe I can help with the AS2100 ... > > > Antonio > > From cclist at sydex.com Thu Apr 14 22:46:24 2022 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 14 Apr 2022 20:46:24 -0700 Subject: idea for a universal disk interface In-Reply-To: References: <20220414113740.466164E6BF@mx2.ezwind.net> <20220414144546.2ACE227392@mx1.ezwind.net> Message-ID: On 4/14/22 16:26, Fred Cisin via cctalk wrote: > On Thu, 14 Apr 2022, John Foust via cctalk wrote: >> Magnetic visualizers also discussed here: >> http://qicreader.blogspot.com/p/track-visualization.html > > Thank you. > > That is what I was looking for. > It doesn't imply current existence of anything already coupled with a > digital camera, nor particularly suitable for an X/Y positioning system > (such as a repurposed plodd^H^Htter) for scanning. I've used Kyread for decades; before that, Magansee and before that, Visamag. Some have complained about the price and availability. For those folks who'd like to roll their own, pyrolytic iron oxide is readily available. Stick a bunch in some appropriate ether and Bob's your uncle. --Chuck From cctalk at beyondthepale.ie Fri Apr 15 05:30:14 2022 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Fri, 15 Apr 2022 11:30:14 +0100 (WET-DST) Subject: AlphaServer 2100s available In-Reply-To: <103c62e6-2fc4-cb85-258e-0ec0a058962d@snowmoose.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> Message-ID: <01SC2B1ODNCM8X06AW@beyondthepale.ie> It's worth what someone is willing to pay for it and this will vary widely. I got one for EUR 20 in 2006. I didn't think this was a bargain because I was under the impression I was getting it for free before I travelled to pick it up. The previous owner had no further use for it and needed the space it was taking up. I think it's a nice machine although an Alphaserver 2100A would be nicer. It looks and sounds like a real computer except the front panel is a bit pathetic. It is great for heating the room in winter. However, it doesn't seem to have any commercial value. Regards, Peter Coghlan. > > What is an AlphaServer 2100 worth? There was one at RePC in Seattle a > couple weeks ago and I was thinking about purchasing it. > > On 4/14/22 2:36 PM, Antonio Carlini via cctalk wrote: >> On 12/04/2022 16:34, Dave Wade G4UGM via cctalk wrote: >>> Folks, >>> Does no one fancy a go at this. Had zero interest... >>> Dave >> >> (OFFLIST, I think) >> >> I'm assuming the machine is safe, at least for the moment? >> >> I've actually got less room now than when I had to let it go, so >> hopefully it can just sit in a corner and be a useful table end or >> something for a while? >> >> I'm currently struggling with a uVAX 3600 PSu and a VAX 4000 PSU, so >> if I ever fix those, maybe I can help with the AS2100 ... >> >> >> Antonio >> >> From cctalk at gtaylor.tnetconsulting.net Fri Apr 15 09:52:35 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 15 Apr 2022 08:52:35 -0600 Subject: AlphaServer 2100s available In-Reply-To: <01SC2B1ODNCM8X06AW@beyondthepale.ie> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> Message-ID: On 4/15/22 4:30 AM, Peter Coghlan via cctalk wrote: > However, it doesn't seem to have any commercial value. I suspect that the recent VAX Hobbyist License Program's expiration will be a shot in the arm for older Alpha systems value as some people migrate to Alpha to legally run OpenVMS as a hobbyist. -- Grant. . . . unix || die From aperry at snowmoose.com Fri Apr 15 09:59:45 2022 From: aperry at snowmoose.com (Alan Perry) Date: Fri, 15 Apr 2022 07:59:45 -0700 Subject: AlphaServer 2100s available In-Reply-To: <01SC2B1ODNCM8X06AW@beyondthepale.ie> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> Message-ID: <2b5a8d1a-d473-ae84-7d2c-06b0cbe57555@snowmoose.com> I wouldn't expect commercial value to come into the discussion on this list. I am wondering what other hobbyists pay in order to gauge whether the price that a local recycler is asking for one (which was around $100) is fair. On 4/15/22 3:30 AM, Peter Coghlan via cctalk wrote: > It's worth what someone is willing to pay for it and this will vary > widely. > > I got one for EUR 20 in 2006.? I didn't think this was a bargain because > I was under the impression I was getting it for free before I travelled > to pick it up.? The previous owner had no further use for it and needed > the space it was taking up. > > I think it's a nice machine although an Alphaserver 2100A would be nicer. > It looks and sounds like a real computer except the front panel is a bit > pathetic.? It is great for heating the room in winter.? However, it > doesn't > seem to have any commercial value. > > Regards, > Peter Coghlan. > >> >> What is an AlphaServer 2100 worth? There was one at RePC in Seattle a >> couple weeks ago and I was thinking about purchasing it. >> >> On 4/14/22 2:36 PM, Antonio Carlini via cctalk wrote: >>> On 12/04/2022 16:34, Dave Wade G4UGM via cctalk wrote: >>>> Folks, >>>> Does no one fancy a go at this. Had zero interest... >>>> Dave >>> >>> (OFFLIST, I think) >>> >>> I'm assuming the machine is safe, at least for the moment? >>> >>> I've actually got less room now than when I had to let it go, so >>> hopefully it can just sit in a corner and be a useful table end or >>> something for a while? >>> >>> I'm currently struggling with a uVAX 3600 PSu and a VAX 4000 PSU, so >>> if I ever fix those, maybe I can help with the AS2100 ... >>> >>> >>> Antonio >>> >>> From tom94022 at comcast.net Fri Apr 15 01:34:25 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Thu, 14 Apr 2022 23:34:25 -0700 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> I suggest if we are talking about an emulator it really isn't necessary to have the entire disk in DRAM, two tracks of DRAM acting as a buffer with a modern HDD holding the emulated drive's data should be fast enough to keep any old iron controller operating without missing any revolutions. The maximum unformatted track length of any old iron drive is well known and therefore one can allocate the number of blocks sufficient to store a full track and then write every track, gaps and all to the modern disk. Given the data rate, track size and sequential seek times of a modern HDD one should be able to fill then next track buffer before the current track buffer is read into the controller. If two track buffers and an HDD isn't fast enough then one could add a track buffer or two or go to SSD's. This was the approach IBM used in it's first RAMAC RAID where I think they had to buffer a whole cylinder but that was many generations ago Tom -----Original Message----- From: Guy Sotomayor [mailto:ggs at shiresoft.com] Sent: Wednesday, April 13, 2022 10:02 AM To: cctech at classiccmp.org Subject: Re: idea for a universal disk interface I've had a similar project in the works for a while (mainly for ESDI and SMD). I think the main issue you're going to face is that what you need to do for something like ESDI or SMD (or any of the bit serial interfaces) is going to be radically different than something like IDE or SCSI. This is not just the interface signals but also what's needed in the FPGA as well as the embedded SW. For example, for the ESDI and SMD interface in order to meet the head switch times (1-2 microseconds) requires that a full cylinder be cached in HW. Once you do that and look at the timings to move a max cylinder between the HW cache (that will serialize/de-serialize the data over the interface) and storage, you'll see that the only way to have any reasonable performance (e.g. not have seek times be > 40ms for *any* seek) is to cache the entire drive image in DRAM and lazily write back dirty tracks. I've been looking at the Xylinx Zynq SoCs for this (mainly the Zynq 7020 for single drive emulation and the Zynq Ultrascale+ for up to 4 drives). In my case the HW, FPGA logic and SW will share significant portions but they will not be identical. In my case there is no need for an external PC (just adds complexity) other than something to do basic configuration (e.g. drive parameters such as number of heads, number of cylinders, etc) which will actually be over USB/serial. The actual persistent storage will be an SD card since all reading will be done at "boot time" and writes will be handled in a lazy manner (since the writes will first go to the DRAM based upon time or seek). It may also be sufficient for configuration purposes to have a file (text) on the SD card that defines the configuration so no external interactions would be necessary. I'm still thinking about that one. ;-) TTFN - Guy On 4/12/22 22:35, shadoooo via cctech wrote: > Hello, > I'm a decent collector of big iron, aka mini computers, mainly DEC and DG. > I'm often facing common problems with storage devices, magnetic discs and tapes are a little prone to give headaches after years, and replacement drives/media in case of a severe failure are unobtainable. > In some cases, the ability to make a dump of the media, also without a running computer is very important. > > Whence the idea: realize an universal device, with several input/output interfaces, which could be used both as storage emulator, to run a computer without real storage, and as controller emulator, to read/write a media without a running computer. > To reduce costs as much as possible, and to allow the better compatibility, the main board shall host enough electrical interfaces to support a large number of disc standard interfaces, ideally by exchanging only a personality adapter for each specific interface, i.e. connectors and few components. > > There are several orders of problems: > - electrical signals, number and type (most disk employ 5V TTL or 3.3V > TTL, some interfaces use differential mode for some faster signals?) > - logical implementation: several electrical signals are used for a > specific interface. These must be handled with correct timings > - software implementation: the universal device shall be able to > switch between interface modes and be controlled by a remote PC > > I suppose the only way to obtain this is to employ an FPGA for logic implementation of the interface, and a microprocessor running Linux to handle software management, data interchange to external (via Ethernet). This means a Xilinx Zynq module for instance. > I know there are several ready devices based on cheaper microcontrollers, but I'm sure these can't support fast and tight timing required by hard disk interfaces (SMD-E runs at 24MHz). > > The main board should include a large enough array of bidirectional transceivers, possibly with variable voltage, to support as much interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point. > The common factor determining what kind of disc interface can be support on hardware side is obviously the type of transceiver employed, for instance a SATA would require a differential serial channel, which could not be available. > But most old electronic is based on TTL/CMOS 5V logic, so a large variety of computer generations should be doable. > > For the first phase, I would ask you to contribute with a list of interfaces which could be interesting to emulate, specially if these are similar to one from my list. > I please submitters to send me by email or by web link when possible, detailed documentation about the interface they propose, so I can check if it could be doable and what kind of electrical signals are needed. > Also detailed information about interfaced I listed is appreciated, as could give some detail I'm missing. > > Thanks > Andrea -- TTFN - Guy From dave at mitton.com Fri Apr 15 09:38:14 2022 From: dave at mitton.com (Dave Mitton) Date: Fri, 15 Apr 2022 10:38:14 -0400 Subject: Retro networking / WAN communities In-Reply-To: References: Message-ID: <20220415143818.0FD17273AC@mx1.ezwind.net> Texas Instruments was the first second source to create a Token Ring chipset, the TMS380. When we pointed out to them some the IBM?ism features we?d prefer to be fixed for 802.x compatibility they claimed they couldn?t because of legal agreements with IBM. The TI chipset had other issues and was not register compatible with IBM?s implementation. Later IBM worked with National Semiconductor to release the TROPIC chipset that was used by Madge and others. Some info I found here: https://www.ardent-tool.com/NIC/TROPIC.html Dave. Date: Wed, 13 Apr 2022 20:25:25 +0000 From: Wayne S Subject: Re: Retro networking / WAN communities There is some mention of Token Ring vs Ethernet here. IIRC, One issue that was pointed out was that IBM was the only single source for TR chips so the price of token ring could be kept artificially high. Was there ever a second or third source for token ring chips? Sent from my iPhone > On Apr 12, 2022, at 14:11, Grant Taylor via cctalk wrote: > > ?On 4/12/22 3:03 PM, Chuck Guzis via cctalk wrote: >> I'll bow to the experts and refer to the things as a "boxes with n capabilities". > > I'm definitely not an expert. Just some random on the Internet who has things to say. ;-) > >> That should pretty much cover the terrain. > > As some random on the Internet who has things to say I actually value "boxes with n capabilities" as it lets me know if I should treat the as a specific thing or a generic class description. E.g. Hoover brand vs Eureka hoover device. ;-) > > > > -- > Grant. . . . > unix || die Sent from Mail for Windows From dave.g4ugm at gmail.com Fri Apr 15 11:53:44 2022 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Fri, 15 Apr 2022 17:53:44 +0100 Subject: AlphaServer 2100s available In-Reply-To: <2b5a8d1a-d473-ae84-7d2c-06b0cbe57555@snowmoose.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> <2b5a8d1a-d473-ae84-7d2c-06b0cbe57555@snowmoose.com> Message-ID: <0e4101d850e9$5e65c6c0$1b315440$@gmail.com> > -----Original Message----- > From: cctalk On Behalf Of Alan Perry via > cctalk > Sent: 15 April 2022 16:00 > To: cctalk at classiccmp.org > Subject: Re: AlphaServer 2100s available > > I wouldn't expect commercial value to come into the discussion on this list. I > am wondering what other hobbyists pay in order to gauge whether the price > that a local recycler is asking for one (which was around > $100) is fair. If its working and boots up I would say that is very reasonable. Dave From robert.jarratt at ntlworld.com Fri Apr 15 12:49:33 2022 From: robert.jarratt at ntlworld.com (Rob Jarratt) Date: Fri, 15 Apr 2022 18:49:33 +0100 Subject: Advice on Desoldering an IC Message-ID: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really struggling to desolder it. I am using the technique of applying fresh solder and then removing it. But after multiple cycles of this I think I am starting to damage the PCB. I am using a fairly cheap desoldering station (this one https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is equivalent to that of the professional Hakko ones though. I am also trying a hand desoldering pump. None of these are able to clear many of the holes of solder, although some are doing better than others. Nevertheless, the IC remains stubbornly unmoving. Are there any tips for removing ICs? Thanks Rob From cz at alembic.crystel.com Fri Apr 15 12:51:23 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Fri, 15 Apr 2022 13:51:23 -0400 Subject: Advice on Desoldering an IC In-Reply-To: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> Message-ID: <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> Cut the pins with a very sharp set of dykes then remove them one at a time. Then use flux and detailer braid to remove the solder On April 15, 2022 1:49:33 PM EDT, Rob Jarratt via cctalk wrote: >I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really >struggling to desolder it. I am using the technique of applying fresh solder >and then removing it. But after multiple cycles of this I think I am >starting to damage the PCB. > > > >I am using a fairly cheap desoldering station (this one >https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD >01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is >equivalent to that of the professional Hakko ones though. I am also trying a >hand desoldering pump. None of these are able to clear many of the holes of >solder, although some are doing better than others. Nevertheless, the IC >remains stubbornly unmoving. > > > >Are there any tips for removing ICs? > > > >Thanks > > > >Rob > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From ethan at 757.org Fri Apr 15 12:55:54 2022 From: ethan at 757.org (Ethan O'Toole) Date: Fri, 15 Apr 2022 13:55:54 -0400 (EDT) Subject: Advice on Desoldering an IC In-Reply-To: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> Message-ID: > I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really > struggling to desolder it. I am using the technique of applying fresh solder > and then removing it. But after multiple cycles of this I think I am > starting to damage the PCB. > Are there any tips for removing ICs? > Thanks > Rob I use a Hakko 808 and have found cases where the pin size of the IC is close to the hole size, and then you can't get the solder out. Some tricks I have used include Chip quick. This is a different allow you "solder in" with existing solder. It has a lower melting point so stays liquid longer. It's great for SMD and troublesome through hole, but you have to clean it off and that part sucks. If you can get some of the legs loose on the chip and then apply some pressure to pull up chip and heat the troublesome pins, but be careful not to lift traces. This sometimes allows chip to "walk" up Flux also helps sometimes Hot air is another trick but probably left to modern boards. -- : Ethan O'Toole From bitwiz at 12bitsbest.com Fri Apr 15 13:08:10 2022 From: bitwiz at 12bitsbest.com (Mike Katz) Date: Fri, 15 Apr 2022 13:08:10 -0500 Subject: Advice on Desoldering an IC In-Reply-To: <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> Message-ID: I have to second this comment. I learned to solder in the early 70s building kits and again professionally in the early 80s. In the early days of thicker circuit boards (2 layer only).? A solder sucker and solder wick would work. However, the most expedient and safest way in terms of potential board damage, is to cut out the bad chip, then take the pins out one at a time and then suck and wick out the holes. This presents the smallest risk of damaging traces or the plating inside the holes. On 4/15/2022 12:51 PM, Chris Zach via cctalk wrote: > Cut the pins with a very sharp set of dykes then remove them one at a time. Then use flux and detailer braid to remove the solder > > On April 15, 2022 1:49:33 PM EDT, Rob Jarratt via cctalk wrote: >> I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really >> struggling to desolder it. I am using the technique of applying fresh solder >> and then removing it. But after multiple cycles of this I think I am >> starting to damage the PCB. >> >> >> >> I am using a fairly cheap desoldering station (this one >> https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD >> 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is >> equivalent to that of the professional Hakko ones though. I am also trying a >> hand desoldering pump. None of these are able to clear many of the holes of >> solder, although some are doing better than others. Nevertheless, the IC >> remains stubbornly unmoving. >> >> >> >> Are there any tips for removing ICs? >> >> >> >> Thanks >> >> >> >> Rob >> From a.carlini at ntlworld.com Fri Apr 15 13:33:27 2022 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Fri, 15 Apr 2022 19:33:27 +0100 Subject: Advice on Desoldering an IC In-Reply-To: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> Message-ID: <94f912ae-6b1d-7d1c-a051-e990356f657e@ntlworld.com> On 15/04/2022 18:49, Rob Jarratt via cctalk wrote: > I am using a fairly cheap desoldering station (this one > https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD > 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is > equivalent to that of the professional Hakko ones though. I am also trying a > hand desoldering pump. None of these are able to clear many of the holes of > solder, although some are doing better than others. Nevertheless, the IC > remains stubbornly unmoving. I have that one too and I've found it to be reasonably good (compared to a manual pump - I've never had access to an expensive desoldering station.). I've not tried it on anything Qbus related, only relatively modern motherboards and the like, but it has been quite good at getting the solder out. Sometimes I need to wiggle the end of the pins to break contact with the via. Removing a 20-pin IC can take a good 15 minutes but when the IC legs don't stick then it can be very quick. I have sometimes resorted to using a hot air gun with the fine nozzle to warm things up first and then use the Duratool. When I first got the desolder gun I played around with scrap motherboards to get the hang of it. There are a fair few YT videos about that Duratool (it seems to be a variant of the ZD-915) and there are various modifications that people have made. Those videos often have examples of it in action along with hints and tips that people have found useful. As usual, take with a hefty grain of salt. (The ones that modify the tool to try and increase the vacuum pressure seem particularly sketchy ... YMMV). Antonio -- Antonio Carlini antonio at acarlini.com From aperry at snowmoose.com Fri Apr 15 13:43:34 2022 From: aperry at snowmoose.com (Alan Perry) Date: Fri, 15 Apr 2022 11:43:34 -0700 Subject: AlphaServer 2100s available In-Reply-To: <0e4101d850e9$5e65c6c0$1b315440$@gmail.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> <2b5a8d1a-d473-ae84-7d2c-06b0cbe57555@snowmoose.com> <0e4101d850e9$5e65c6c0$1b315440$@gmail.com> Message-ID: <575fd556-3183-9ec5-24b6-25db2f191e5f@snowmoose.com> On 4/15/22 9:53 AM, Dave Wade G4UGM via cctalk wrote: >> -----Original Message----- >> From: cctalk On Behalf Of Alan Perry via >> cctalk >> Sent: 15 April 2022 16:00 >> To: cctalk at classiccmp.org >> Subject: Re: AlphaServer 2100s available >> >> I wouldn't expect commercial value to come into the discussion on this list. I >> am wondering what other hobbyists pay in order to gauge whether the price >> that a local recycler is asking for one (which was around >> $100) is fair. > If its working and boots up I would say that is very reasonable. > Oh, don't say that. My garage is filling up with sun3 desksides and drive pedestals :) The note on it says that it doesn't boot, but they had the same note on the Axil 320 (SS20 clone) that I got from them and it booted up fine once I put a HDD in it. From cctalk at gtaylor.tnetconsulting.net Fri Apr 15 14:37:16 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 15 Apr 2022 13:37:16 -0600 Subject: AlphaServer 2100s available In-Reply-To: <575fd556-3183-9ec5-24b6-25db2f191e5f@snowmoose.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> <2b5a8d1a-d473-ae84-7d2c-06b0cbe57555@snowmoose.com> <0e4101d850e9$5e65c6c0$1b315440$@gmail.com> <575fd556-3183-9ec5-24b6-25db2f191e5f@snowmoose.com> Message-ID: <47b47f38-dcee-b6c6-b3d2-c127f2471c2f@spamtrap.tnetconsulting.net> On 4/15/22 12:43 PM, Alan Perry via cctalk wrote: > The note on it says that it doesn't boot, but they had the same note on > the Axil 320 (SS20 clone) that I got from them and it booted up fine > once I put a HDD in it. There's posting and then there's booting into an OS. The former is most important. The latter is highly dependent on a working disk drive /and/ non-corrupted OS. -- Grant. . . . unix || die From w2hx at w2hx.com Fri Apr 15 14:27:14 2022 From: w2hx at w2hx.com (W2HX) Date: Fri, 15 Apr 2022 19:27:14 +0000 Subject: Advice on Desoldering an IC In-Reply-To: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> Message-ID: <77d37eccee19430384fd489f9afc7298@EXBE015SV3.NA02.MSEXCHANGEOUTLOOK.COM> I would not attempt any desoldering without my hakko 808. I never leave home with out it. While you are sucking and heating the pin, wiggle the pin and it work great. I've desoldered 40 pin chips without trouble, they drop right out of the board. I desoldered this 40 pin chip from a working device just to try it in another device I was repairing. Then I put it back. I had no concern about damaging the chip. I used to use the wick/sucker approach from childhood until about 20 years old. I always hated the results. Hakko is a game changer for me. 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/c/w2hx-channel/videos -----Original Message----- From: cctalk On Behalf Of Rob Jarratt via cctalk Sent: Friday, April 15, 2022 1:50 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Advice on Desoldering an IC I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really struggling to desolder it. I am using the technique of applying fresh solder and then removing it. But after multiple cycles of this I think I am starting to damage the PCB. I am using a fairly cheap desoldering station (this one https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is equivalent to that of the professional Hakko ones though. I am also trying a hand desoldering pump. None of these are able to clear many of the holes of solder, although some are doing better than others. Nevertheless, the IC remains stubbornly unmoving. Are there any tips for removing ICs? Thanks Rob From mdehling at gmail.com Fri Apr 15 14:46:29 2022 From: mdehling at gmail.com (Malte Dehling) Date: Fri, 15 Apr 2022 12:46:29 -0700 Subject: AlphaServer 2100s available In-Reply-To: <575fd556-3183-9ec5-24b6-25db2f191e5f@snowmoose.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> <2b5a8d1a-d473-ae84-7d2c-06b0cbe57555@snowmoose.com> <0e4101d850e9$5e65c6c0$1b315440$@gmail.com> <575fd556-3183-9ec5-24b6-25db2f191e5f@snowmoose.com> Message-ID: On Fri 15. Apr 2022 at 11:43, Alan Perry via cctalk wrote: > > On 4/15/22 9:53 AM, Dave Wade G4UGM via cctalk wrote: > >> -----Original Message----- > >> From: cctalk On Behalf Of Alan Perry > via > >> cctalk > >> Sent: 15 April 2022 16:00 > >> To: cctalk at classiccmp.org > >> Subject: Re: AlphaServer 2100s available > >> > >> I wouldn't expect commercial value to come into the discussion on this > list. I > >> am wondering what other hobbyists pay in order to gauge whether the > price > >> that a local recycler is asking for one (which was around > >> $100) is fair. > > If its working and boots up I would say that is very reasonable. > > > Oh, don't say that. My garage is filling up with sun3 desksides and > drive pedestals :) > > The note on it says that it doesn't boot, but they had the same note on > the Axil 320 (SS20 clone) that I got from them and it booted up fine > once I put a HDD in it. Unrelated to the current discussion, but since you mention your Axil 320: do you have a way of reading the OBP PROM for that? I have been looking for that! Cheers, Malte > From lee.gleason at comcast.net Fri Apr 15 14:48:57 2022 From: lee.gleason at comcast.net (Lee Gleason) Date: Fri, 15 Apr 2022 14:48:57 -0500 Subject: anyone ever connect a TU58 drive to a PDT-11/150 terminal port? Message-ID: <5d193fd7-e9f3-ef07-f10f-bd84dd080dd5@comcast.net> ? I've been tinkering with a PDT-11/150 lately. It's a little inconvenient to work on, since it doesn't have a simple way to transfer files back and forth (KRTMIN doesn't work when transferring files to the box, just from the box, for some reason I haven't been able to puzzle out, and pasting text into a KED screen or a PIP command usually overflows my terminal emulator). ? It occurred to me that the first application terminal line on the 150 is at 176500,300, the same as the default for a TU58's DL11. It's a very DL11 like interface, register wise. I'm wondering, if I could hook up a TU58 emulator and use it to move data back and forth to the 150. ? Has anyone had occasion to try this? Any advice on how to get it to go would? be appreciated, since I know very little about RT11. -- Lee K. Gleason N5ZMR Control-G Consultants lee.gleason at comcast.net From aperry at snowmoose.com Fri Apr 15 14:49:11 2022 From: aperry at snowmoose.com (Alan Perry) Date: Fri, 15 Apr 2022 12:49:11 -0700 Subject: AlphaServer 2100s available In-Reply-To: References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> <2b5a8d1a-d473-ae84-7d2c-06b0cbe57555@snowmoose.com> <0e4101d850e9$5e65c6c0$1b315440$@gmail.com> <575fd556-3183-9ec5-24b6-25db2f191e5f@snowmoose.com> Message-ID: <906b139c-b577-da3b-96ec-8ea1a04a34ae@snowmoose.com> On 4/15/22 12:46 PM, Malte Dehling wrote: > On Fri 15. Apr 2022 at 11:43, Alan Perry via cctalk > wrote: > > > On 4/15/22 9:53 AM, Dave Wade G4UGM via cctalk wrote: > >> -----Original Message----- > >> From: cctalk On Behalf Of Alan > Perry via > >> cctalk > >> Sent: 15 April 2022 16:00 > >> To: cctalk at classiccmp.org > >> Subject: Re: AlphaServer 2100s available > >> > >> I wouldn't expect commercial value to come into the discussion > on this list. I > >> am wondering what other hobbyists pay in order to gauge whether > the price > >> that a local recycler is asking for one (which was around > >> $100) is fair. > > If its working and boots up I would say that is very reasonable. > > > Oh, don't say that. My garage is filling up with sun3 desksides and > drive pedestals :) > > The note on it says that it doesn't boot, but they had the same > note on > the Axil 320 (SS20 clone) that I got from them and it booted up fine > once I put a HDD in it. > > > Unrelated to the current discussion, but since you mention your Axil > 320: do you have a way of reading the OBP PROM for that?? I have been > looking for that! I don't personally, but I am sure that I know someone locally who does. Send me e-mail - alanp at snowmoose.com. From mjd.bishop at emeritus-solutions.com Fri Apr 15 16:05:43 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Fri, 15 Apr 2022 21:05:43 +0000 Subject: Advice on Desoldering an IC In-Reply-To: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> Message-ID: Rob I would imagine that an 11/24 CPU is at least a 4 layer board, with power planes and hopefully thermal reliefs at pins connected to a plane. The pins you will be having difficulty with are most likely on the Gnd or Vcc plane. I often leave those pins for last, once in the groove. And, I'm not above cutting off the IC body or eliminating the connector body. To state the obvious the key to desoldering is to get the heat in; now, the solder is what gets it there. So with a desoldering tool and a suitable ID bit, load it with SnPb solder, put it to the pin and don't start sucking until the via's barrel is clean at completion (adjust for board, pin, tool and Jovian phase). Additionally, apply some circular motion to the tool / pin in the final stage of heating and during evaculation to preclude sticky spots. If the board is really tarnished some flux on the pin(s) may be necessary to initiate heat conduction, BGA gel flux would be my pick for this requirement. If the board really has it in for you a pre-heater may help, although I have yet require to use one for TH desoldering and the pins falling onto the quartz elements might be "unhelpful". I always use one of SMD PCB assembly with hot air. See e.g. https://www.pcb-soldering.co.uk/aoyue-853a-pro-quartz-infrared-heater-220v. Alternatively, you could use hot air to cook the board up; I always heat all the copper in the board rather than the joint - once the board is toasty a little more heat will flow the solder or if you get distracted it may just happen ... This aproach works well for SMD assy. HtH; BR Martin -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Rob Jarratt via cctalk Sent: 15 April 2022 18:50 To: General Discussion: On-Topic and Off-Topic Posts Subject: Advice on Desoldering an IC I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really struggling to desolder it. I am using the technique of applying fresh solder and then removing it. But after multiple cycles of this I think I am starting to damage the PCB. I am using a fairly cheap desoldering station (this one https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is equivalent to that of the professional Hakko ones though. I am also trying a hand desoldering pump. None of these are able to clear many of the holes of solder, although some are doing better than others. Nevertheless, the IC remains stubbornly unmoving. Are there any tips for removing ICs? Thanks Rob From robert.jarratt at ntlworld.com Fri Apr 15 16:32:38 2022 From: robert.jarratt at ntlworld.com (Rob Jarratt) Date: Fri, 15 Apr 2022 22:32:38 +0100 Subject: Advice on Desoldering an IC In-Reply-To: <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> Message-ID: <002801d85110$5479e1b0$fd6da510$@ntlworld.com> I do have some diagonal cutters, but although small they seem to be still too bulky to reach the pins. I will have to try to find some finer ones. These seem to look OK: https://uk.farnell.com/klein-tools/d275-5/wire-cutter-diagonal-127mm/dp/2839543 Also, I have seen the recommendations regarding a Hakko 808. It looks like the modern successor is the FR301 https://www.hakko.co.uk/product/fr-301-portable-desoldering-gun/. I think what may be better about this is the wider choice of nozzles. Regards Rob From: Chris Zach Sent: 15 April 2022 18:51 To: rob at jarratt.me.uk; Rob Jarratt ; General Discussion: On-Topic and Off-Topic Posts ; Rob Jarratt via cctalk Subject: Re: Advice on Desoldering an IC Cut the pins with a very sharp set of dykes then remove them one at a time. Then use flux and detailer braid to remove the solder On April 15, 2022 1:49:33 PM EDT, Rob Jarratt via cctalk > wrote: I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really struggling to desolder it. I am using the technique of applying fresh solder and then removing it. But after multiple cycles of this I think I am starting to damage the PCB. I am using a fairly cheap desoldering station (this one https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is equivalent to that of the professional Hakko ones though. I am also trying a hand desoldering pump. None of these are able to clear many of the holes of solder, although some are doing better than others. Nevertheless, the IC remains stubbornly unmoving. Are there any tips for removing ICs? Thanks Rob -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From johnhreinhardt at thereinhardts.org Fri Apr 15 16:44:05 2022 From: johnhreinhardt at thereinhardts.org (John H. Reinhardt) Date: Fri, 15 Apr 2022 16:44:05 -0500 Subject: Advice on Desoldering an IC In-Reply-To: <002801d85110$5479e1b0$fd6da510$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> <002801d85110$5479e1b0$fd6da510$@ntlworld.com> Message-ID: I bought a Hakko FR301-03 in mid 2020 and, while I haven't used it for a lot, I can attest it has worked very well for what I have done.? I have used it to replace the RIFA caps on the boards of 3 H7864 power supplies and the pico fuses on several KDJ11-B 11/73/83 CPU boards.? In each case the solder was removed quickly and the parts literally dropped off the boards.? I have also used it to rework some badly soldered (by me) sockets on a QBone card I was assembling.? While it was relatively expensive (to me) it has been worth the cost. John H. Reinhardt On 4/15/2022 4:32 PM, Rob Jarratt via cctalk wrote: > I do have some diagonal cutters, but although small they seem to be still too bulky to reach the pins. I will have to try to find some finer ones. These seem to look OK: https://uk.farnell.com/klein-tools/d275-5/wire-cutter-diagonal-127mm/dp/2839543 > > > > Also, I have seen the recommendations regarding a Hakko 808. It looks like the modern successor is the FR301 https://www.hakko.co.uk/product/fr-301-portable-desoldering-gun/. I think what may be better about this is the wider choice of nozzles. > > > > Regards > > > > Rob > > > > From: Chris Zach > Sent: 15 April 2022 18:51 > To: rob at jarratt.me.uk; Rob Jarratt ; General Discussion: On-Topic and Off-Topic Posts ; Rob Jarratt via cctalk > Subject: Re: Advice on Desoldering an IC > > > > Cut the pins with a very sharp set of dykes then remove them one at a time. Then use flux and detailer braid to remove the solder > > On April 15, 2022 1:49:33 PM EDT, Rob Jarratt via cctalk > wrote: > > I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really > struggling to desolder it. I am using the technique of applying fresh solder > and then removing it. But after multiple cycles of this I think I am > starting to damage the PCB. > > > > I am using a fairly cheap desoldering station (this one > https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD > 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is > equivalent to that of the professional Hakko ones though. I am also trying a > hand desoldering pump. None of these are able to clear many of the holes of > solder, although some are doing better than others. Nevertheless, the IC > remains stubbornly unmoving. > > > > Are there any tips for removing ICs? > > > > Thanks > > > > Rob From mjd.bishop at emeritus-solutions.com Fri Apr 15 16:52:18 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Fri, 15 Apr 2022 21:52:18 +0000 Subject: Advice on Desoldering an IC In-Reply-To: <002801d85110$5479e1b0$fd6da510$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> <002801d85110$5479e1b0$fd6da510$@ntlworld.com> Message-ID: If the Klein cutters are too bulky, you may care to investigate. Lindstrom 7191 https://uk.rs-online.com/web/p/cutters/3320341 are the usu first resort small cutters - they should be fine enough for 0.1" pitch ICs. A finer pair are Bondline 1570 https://www.bondline.co.uk/product/hand-tools-and-tweezers/esd-cutters/c1570 definitely fine enough for 0.1" IC legs (just put them to an IC), and probably 50 mil packages. And for a compact pair of 45 deg pin croppers Bondline C1582 https://www.bondline.co.uk/product/hand-tools-and-tweezers/esd-cutters/c1582 HtH; BR Martin -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Rob Jarratt via cctalk Sent: 15 April 2022 22:33 To: 'Chris Zach' ; 'General Discussion: On-Topic and Off-Topic Posts' Subject: RE: Advice on Desoldering an IC I do have some diagonal cutters, but although small they seem to be still too bulky to reach the pins. I will have to try to find some finer ones. These seem to look OK: https://uk.farnell.com/klein-tools/d275-5/wire-cutter-diagonal-127mm/dp/2839543 Also, I have seen the recommendations regarding a Hakko 808. It looks like the modern successor is the FR301 https://www.hakko.co.uk/product/fr-301-portable-desoldering-gun/. I think what may be better about this is the wider choice of nozzles. Regards Rob From: Chris Zach Sent: 15 April 2022 18:51 To: rob at jarratt.me.uk; Rob Jarratt ; General Discussion: On-Topic and Off-Topic Posts ; Rob Jarratt via cctalk Subject: Re: Advice on Desoldering an IC Cut the pins with a very sharp set of dykes then remove them one at a time. Then use flux and detailer braid to remove the solder On April 15, 2022 1:49:33 PM EDT, Rob Jarratt via cctalk > wrote: I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really struggling to desolder it. I am using the technique of applying fresh solder and then removing it. But after multiple cycles of this I think I am starting to damage the PCB. I am using a fairly cheap desoldering station (this one https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is equivalent to that of the professional Hakko ones though. I am also trying a hand desoldering pump. None of these are able to clear many of the holes of solder, although some are doing better than others. Nevertheless, the IC remains stubbornly unmoving. Are there any tips for removing ICs? Thanks Rob -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From cisin at xenosoft.com Fri Apr 15 17:54:13 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Fri, 15 Apr 2022 15:54:13 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> Message-ID: On Thu, 14 Apr 2022, Tom Gardner via cctalk wrote: > This was the approach IBM used in it's first RAMAC RAID where I think > they had to buffer a whole cylinder but that was many generations ago (my copy of the specs may not be exact): Buffering a whole cylinder, or a whole surface, of the RAMAC was no big deal. One hundred surfaces (52 platters, but not using bottom of bottommost nor top of topmost) totalling to 5 million 6 bit characters. That's 50,000 characters per surface. OR 50,000 characters per cylinder ("square geometry" :-) 100 tracks per side of a platter (at 20 tracks per inch) meant about 500 characters per track Problematic in the CP/M days, but such a buffer is small in current usage. From cisin at xenosoft.com Fri Apr 15 18:03:48 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Fri, 15 Apr 2022 16:03:48 -0700 (PDT) Subject: Advice on Desoldering an IC In-Reply-To: <002801d85110$5479e1b0$fd6da510$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> <002801d85110$5479e1b0$fd6da510$@ntlworld.com> Message-ID: Once the chip is out, for cleaning out the holes, I used a spring loaded solder sucker on one side of the board, with soldering iron on the other side. also, solder wick sometimes a wooden toothpick in extreme cases, a small drill bit turned by hand in a pin vise (NOT chucked up in a powered 1/2" drill!) From van.snyder at sbcglobal.net Fri Apr 15 18:18:23 2022 From: van.snyder at sbcglobal.net (Van Snyder) Date: Fri, 15 Apr 2022 16:18:23 -0700 Subject: Did I send you an IBM typewriter? References: <8666bab8b713c0109b41f11fd27afad6576ba12b.camel.ref@sbcglobal.net> Message-ID: <8666bab8b713c0109b41f11fd27afad6576ba12b.camel@sbcglobal.net> If you're the guy I sent an IBM typewriter to, contact me. I found a spring that was part of it. I thought I had lost it forever. Van Snyder van.snyder at sbcglobal.net From cclist at sydex.com Fri Apr 15 18:42:14 2022 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 15 Apr 2022 16:42:14 -0700 Subject: Advice on Desoldering an IC In-Reply-To: References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> <002801d85110$5479e1b0$fd6da510$@ntlworld.com> Message-ID: <8b6577ae-db5e-87ef-b035-16d16daa7ab9@sydex.com> For very-difficult de-soldering, I use a variation on the Chip-Quik idea. I take a hunk of Cerrobend 158 fusible alloy and a file and make a small pile of powder from it. I then pack the powder around the pins of the IC to remove and heat the area using the light from a 75 watt PAR-38 halogen reflector lamp. (apply from the reverse side of the PCB). In very little time, the area of the board heats up enough to melt the cerrobend and it fuses with the solder. The part can then be easily removed (SMT stuff just slides off). Since the board never even gets to 100C, everything else stays in place and you don't burn the board or lift traces. Clean up with a toothbrush. Discard the fused metal. I suppose that instead of the lamp, you could use a hot-air rework tool set low. Anyway, that's what I do. --Chuck From w2hx at w2hx.com Fri Apr 15 19:12:11 2022 From: w2hx at w2hx.com (W2HX) Date: Sat, 16 Apr 2022 00:12:11 +0000 Subject: Advice on Desoldering an IC In-Reply-To: <8b6577ae-db5e-87ef-b035-16d16daa7ab9@sydex.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> <002801d85110$5479e1b0$fd6da510$@ntlworld.com> <8b6577ae-db5e-87ef-b035-16d16daa7ab9@sydex.com> Message-ID: Just be careful around cerroblend. According to Wikipedia... "... is a metal alloy that is useful for soldering and making custom metal parts, but which is toxic to touch or breathe vapors from." "...is toxic because it contains lead and cadmium, and contamination of bare skin is considered harmful. Vapour from cadmium-containing alloys is also known to pose a danger to humans. Cadmium poisoning carries the risk of cancer, anosmia (loss of sense of smell), and damage to the liver, kidneys, nerves, bones, and respiratory system. Field's metal is a non-toxic alternative. The dust may form flammable mixtures with air." 73 Eugene W2HX Subscribe to my Youtube Channel:?https://www.youtube.com/c/w2hx-channel/videos -----Original Message----- From: cctalk On Behalf Of Chuck Guzis via cctalk Sent: Friday, April 15, 2022 7:42 PM To: Fred Cisin via cctalk Subject: Re: Advice on Desoldering an IC For very-difficult de-soldering, I use a variation on the Chip-Quik idea. I take a hunk of Cerrobend 158 fusible alloy and a file and make a small pile of powder from it. I then pack the powder around the pins of the IC to remove and heat the area using the light from a 75 watt PAR-38 halogen reflector lamp. (apply from the reverse side of the PCB). In very little time, the area of the board heats up enough to melt the cerrobend and it fuses with the solder. The part can then be easily removed (SMT stuff just slides off). Since the board never even gets to 100C, everything else stays in place and you don't burn the board or lift traces. Clean up with a toothbrush. Discard the fused metal. I suppose that instead of the lamp, you could use a hot-air rework tool set low. Anyway, that's what I do. --Chuck From paulkoning at comcast.net Fri Apr 15 19:32:56 2022 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 15 Apr 2022 20:32:56 -0400 Subject: idea for a universal disk interface In-Reply-To: References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> Message-ID: <2E837B98-24E5-4200-81A3-C8D0F9A84ADF@comcast.net> > On Apr 15, 2022, at 6:54 PM, Fred Cisin via cctalk wrote: > > On Thu, 14 Apr 2022, Tom Gardner via cctalk wrote: >> This was the approach IBM used in it's first RAMAC RAID where I think they had to buffer a whole cylinder but that was many generations ago > > (my copy of the specs may not be exact): > Buffering a whole cylinder, or a whole surface, of the RAMAC was no big deal. > One hundred surfaces (52 platters, but not using bottom of bottommost nor top of topmost) totalling to 5 million 6 bit characters. > > That's 50,000 characters per surface. > OR 50,000 characters per cylinder > ("square geometry" :-) "Was" as in "back in the day"? 50k characters would have been quiet a large memory in the 1950s. And for an I/O device, any kind of buffer is not necessarily all that useful. What does make sense is a track buffer in drum memory machines, as found for example in the Dutch ARMAC, where the first implementation of the famous "shortest path" algorithm was first implemented. paul From cctalk at beyondthepale.ie Fri Apr 15 17:49:31 2022 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Fri, 15 Apr 2022 23:49:31 +0100 (WET-DST) Subject: AlphaServer 2100s available In-Reply-To: <2b5a8d1a-d473-ae84-7d2c-06b0cbe57555@snowmoose.com> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> Message-ID: <01SC32K5H3GU8X078C@beyondthepale.ie> We occasionally hear of aged computers being employed in the nuclear power industry, certain military applications or long lifed medical equipment for example. I imagine that these machines can have a significant commercial value long after their contemporaries which are not involved in these roles. As far as I know, the Alphaserver 2100 was not commonly used for this sort of work and this is why I mentioned that I thought it was unlikely to have any commercial value. If the opposite was true, it would probably have a bearing on the current day value of the machine and the price may have been outside of the reach of any of us. So we are probably left with what a hobbyist / enthusiast / collector or scrap dealer will pay for one, which as I said I believe will vary widely (certainly for the former anyway). If you want to know what a scrap dealer will pay for one, you are probably asking the wrong people although certain people on this list did occasionally comment on the price of scrap. I haven't noticed any discussion along these lines for a long time now though. They may have become tired of repeating more or less what I am saying here. The fact that the thing is big, heavy and relatively difficult to ship is likely to further reduce the achievable price as more interested parties are less likely to be located nearby. If it's sitting in a recyclers with a $100 price tag and not moving, the answer to the original question is probably "less that $100", however, this information was not provided with the original question. Somebody some distance away might be willing to spring for more than $100 for it but may find the cost and effort of getting it shipped to be prohibitive. My Alphaserver 2100 is probably worth nothing. I am pretty certain it is not located close to anyone else who would be interested in it. If I wanted to get rid of it, I would probably have to pay someone to take it away or bring it to the recycling depot myself and cross my fingers that it would be accepted as domestic electronic equipment. On the other hand, if someone approached me looking to buy it from me, they would probably have to put at least four or maybe five figures in front of the decimal point before I would be motivated enough to think about letting it go. That's pretty widely varying. Sorry if it seems unhelpful but I find questions about the value of items that there is only a tiny market for to be pretty much impossible to answer. Regards, Peter Coghlan. Alan Perry via cctalk wrote: > I wouldn't expect commercial value to come into the discussion on this > list. I am wondering what other hobbyists pay in order to gauge whether > the price that a local recycler is asking for one (which was around > $100) is fair. > > On 4/15/22 3:30 AM, Peter Coghlan via cctalk wrote: >> It's worth what someone is willing to pay for it and this will vary >> widely. >> >> I got one for EUR 20 in 2006.? I didn't think this was a bargain because >> I was under the impression I was getting it for free before I travelled >> to pick it up.? The previous owner had no further use for it and needed >> the space it was taking up. >> >> I think it's a nice machine although an Alphaserver 2100A would be nicer. >> It looks and sounds like a real computer except the front panel is a bit >> pathetic.? It is great for heating the room in winter.? However, it >> doesn't >> seem to have any commercial value. >> >> Regards, >> Peter Coghlan. >> >>> >>> What is an AlphaServer 2100 worth? There was one at RePC in Seattle a >>> couple weeks ago and I was thinking about purchasing it. >>> >>> On 4/14/22 2:36 PM, Antonio Carlini via cctalk wrote: >>>> On 12/04/2022 16:34, Dave Wade G4UGM via cctalk wrote: >>>>> Folks, >>>>> Does no one fancy a go at this. Had zero interest... >>>>> Dave >>>> >>>> (OFFLIST, I think) >>>> >>>> I'm assuming the machine is safe, at least for the moment? >>>> >>>> I've actually got less room now than when I had to let it go, so >>>> hopefully it can just sit in a corner and be a useful table end or >>>> something for a while? >>>> >>>> I'm currently struggling with a uVAX 3600 PSu and a VAX 4000 PSU, so >>>> if I ever fix those, maybe I can help with the AS2100 ... >>>> >>>> >>>> Antonio >>>> >>>> From cisin at xenosoft.com Fri Apr 15 19:46:33 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Fri, 15 Apr 2022 17:46:33 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: <2E837B98-24E5-4200-81A3-C8D0F9A84ADF@comcast.net> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> <2E837B98-24E5-4200-81A3-C8D0F9A84ADF@comcast.net> Message-ID: >>> This was the approach IBM used in it's first RAMAC RAID where I think they had to buffer a whole cylinder but that was many generations ago >> (my copy of the specs may not be exact): >> Buffering a whole cylinder, or a whole surface, of the RAMAC was no big deal. >> One hundred surfaces (52 platters, but not using bottom of bottommost nor top of topmost) totalling to 5 million 6 bit characters. >> That's 50,000 characters per surface. >> OR 50,000 characters per cylinder >> ("square geometry" :-) > On Fri, 15 Apr 2022, Paul Koning wrote: > "Was" as in "back in the day"? 50k characters would have been quiet a > large memory in the 1950s. And for an I/O device, any kind of buffer is > not necessarily all that useful. 50K would be bordering on extreme in the 1950s, and considered a LARGE buffer through the 1970s. Certainly wasn't practical with less than 16 bits of addressing. > What does make sense is a track buffer in drum memory machines, as found > for example in the Dutch ARMAC, where the first implementation of the > famous "shortest path" algorithm was first implemented. From paulkoning at comcast.net Fri Apr 15 19:51:36 2022 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 15 Apr 2022 20:51:36 -0400 Subject: AlphaServer 2100s available In-Reply-To: <01SC32K5H3GU8X078C@beyondthepale.ie> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> <01SC32K5H3GU8X078C@beyondthepale.ie> Message-ID: <0EF9E43A-648E-44F3-AF02-85AF1F35B9BA@comcast.net> > On Apr 15, 2022, at 6:49 PM, Peter Coghlan via cctalk wrote: > > We occasionally hear of aged computers being employed in the nuclear > power industry, certain military applications or long lifed medical > equipment for example. I imagine that these machines can have a > significant commercial value long after their contemporaries which are > not involved in these roles. An example: in the past year, a CDC mainframe (the last generation of what started with the 6600 in 1964) was taken out of service at Vandenberg SFB. And actually, the architecture is still in use, but the replacement is an emulator rather than a "real" machine. paul From cclist at sydex.com Fri Apr 15 20:48:34 2022 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 15 Apr 2022 18:48:34 -0700 Subject: Advice on Desoldering an IC In-Reply-To: References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <168A06AC-314D-4086-899F-45B46311E497@alembic.crystel.com> <002801d85110$5479e1b0$fd6da510$@ntlworld.com> <8b6577ae-db5e-87ef-b035-16d16daa7ab9@sydex.com> Message-ID: <7e7b464f-40d5-e09c-da06-319ff1d956c2@sydex.com> On 4/15/22 17:12, W2HX wrote: > Just be careful around cerroblend. According to Wikipedia... > > "... is a metal alloy that is useful for soldering and making custom metal parts, but which is toxic to touch or breathe vapors from." > "...is toxic because it contains lead and cadmium, and contamination of bare skin is considered harmful. Vapour from cadmium-containing alloys is also known to pose a danger to humans. Cadmium poisoning carries the risk of cancer, anosmia (loss of sense of smell), and damage to the liver, kidneys, nerves, bones, and respiratory system. Field's metal is a non-toxic alternative. The dust may form flammable mixtures with air." > I've used Cerrobend for decades as a filler when bending thinwall brass tubing. The small amount used in occasional problem de-soldering isn't likely to cause problems. Oh, we've fooled with some terrible things; bright cadmium plate for everything from bolts to bicycle spokes, carbon tet for cleaning (used to be the basis of Carbona spot remover), Zinc chromate for rust prevention, lead pipes for water mains, leaded solder, mercury in all sorts of things from thermometers to switches; tetraethyl lead being spewed from automobile tailpipes for years... And yet I'm in my dotage and still alive and kicking, somehow. --Chuck From leec2124 at gmail.com Fri Apr 15 20:49:36 2022 From: leec2124 at gmail.com (Lee Courtney) Date: Fri, 15 Apr 2022 18:49:36 -0700 Subject: AlphaServer 2100s available In-Reply-To: <0EF9E43A-648E-44F3-AF02-85AF1F35B9BA@comcast.net> References: <04b701d84817$1f846e50$5e8d4af0$@gmail.com> <1ae801d84e82$d821d300$88657900$@gmail.com> <34e0ac15-5193-ceb2-9ba8-5790ea70ce9b@ntlworld.com> <01SC2B1ODNCM8X06AW@beyondthepale.ie> <01SC32K5H3GU8X078C@beyondthepale.ie> <0EF9E43A-648E-44F3-AF02-85AF1F35B9BA@comcast.net> Message-ID: There are still HP3000 systems being used in business critical functions, 12(?) years after the HP end-of-life date (no manufacturing or support) for the product line. (From a business continuity perspective that's insane.) Hardware support is not based on new manufacturer parts with warranty, but cannibalization from existing systems. And in that phase of the life cycle cannibalization leads to to fewer and fewer sources of parts, and increased prices. Until the point where the market has moved off of the hardware, for example onto Windows or emulation, and the commercial market collapses. Lee Courtney On Fri, Apr 15, 2022 at 5:52 PM Paul Koning via cctalk < cctalk at classiccmp.org> wrote: > > > > On Apr 15, 2022, at 6:49 PM, Peter Coghlan via cctalk < > cctalk at classiccmp.org> wrote: > > > > We occasionally hear of aged computers being employed in the nuclear > > power industry, certain military applications or long lifed medical > > equipment for example. I imagine that these machines can have a > > significant commercial value long after their contemporaries which are > > not involved in these roles. > > An example: in the past year, a CDC mainframe (the last generation of what > started with the 6600 in 1964) was taken out of service at Vandenberg SFB. > And actually, the architecture is still in use, but the replacement is an > emulator rather than a "real" machine. > > paul > > > -- Lee Courtney +1-650-704-3934 cell From useddec at gmail.com Fri Apr 15 23:01:24 2022 From: useddec at gmail.com (Paul Anderson) Date: Fri, 15 Apr 2022 23:01:24 -0500 Subject: Did I send you an IBM typewriter? In-Reply-To: <8666bab8b713c0109b41f11fd27afad6576ba12b.camel@sbcglobal.net> References: <8666bab8b713c0109b41f11fd27afad6576ba12b.camel.ref@sbcglobal.net> <8666bab8b713c0109b41f11fd27afad6576ba12b.camel@sbcglobal.net> Message-ID: Sorry, not me. On Fri, Apr 15, 2022 at 6:18 PM Van Snyder via cctalk wrote: > If you're the guy I sent an IBM typewriter to, contact me. I found a > spring that was part of it. I thought I had lost it forever. > > Van Snyder > van.snyder at sbcglobal.net > > From ggs at shiresoft.com Fri Apr 15 12:55:58 2022 From: ggs at shiresoft.com (Guy Sotomayor) Date: Fri, 15 Apr 2022 10:55:58 -0700 Subject: idea for a universal disk interface In-Reply-To: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> Message-ID: <7063b5b9-ca21-96a5-95cb-c6a0ca82d6a3@shiresoft.com> I ran the numbers for Zynq FPGAs.? First of all for ESDI and SMD the head switch time is 1-2us (basically the time it takes for the clocks to re-lock on the new data). Two tracks isn't sufficient (which is the "other" track...you will be wrong). So I decided to go and have a full cylinder (I'm allowing for up to 32KB tracks and up to 16 heads) which is 512KB.? The Zynq DMA from HW block RAM to DRAM (at 500MB/s) is ~1ms.? Given that the previous cylinder could be dirty (e.g. has written data), the worst case seek time is ~2ms.? This allows me to emulate any seek latency curve(s) I want. In my design, any dirty data is written back to storage in a lazy manner so the performance of the storage isn't really an issue. I should note that the Zynq 7020 module has 1GB of DRAM on it, so there is no additional cost to just put the entire disk contents in DRAM and I'm using the attached SD Card interface for storage (so you can use a $10 SD Card for storage).? Adding a high speed disk interface (e.g. MD.2, PCIe, or other serially attached storage) would add additional cost in terms of having to create the interface as well as a reasonably fast drive and I don't see the advantage. I'm planning on using a Zynq UltraScale+ module to allow for larger disks and multiple disk emulations (it has more block RAM and 4GB of DRAM on the module). TTFN - Guy On 4/14/22 23:34, Tom Gardner wrote: > I suggest if we are talking about an emulator it really isn't necessary to have the entire disk in DRAM, two tracks of DRAM acting as a buffer with a modern HDD holding the emulated drive's data should be fast enough to keep any old iron controller operating without missing any revolutions. The maximum unformatted track length of any old iron drive is well known and therefore one can allocate the number of blocks sufficient to store a full track and then write every track, gaps and all to the modern disk. Given the data rate, track size and sequential seek times of a modern HDD one should be able to fill then next track buffer before the current track buffer is read into the controller. If two track buffers and an HDD isn't fast enough then one could add a track buffer or two or go to SSD's. > > This was the approach IBM used in it's first RAMAC RAID where I think they had to buffer a whole cylinder but that was many generations ago > > Tom > > -----Original Message----- > From: Guy Sotomayor [mailto:ggs at shiresoft.com] > Sent: Wednesday, April 13, 2022 10:02 AM > To: cctech at classiccmp.org > Subject: Re: idea for a universal disk interface > > I've had a similar project in the works for a while (mainly for ESDI and SMD). > > I think the main issue you're going to face is that what you need to do for something like ESDI or SMD (or any of the bit serial interfaces) is going to be radically different than something like IDE or SCSI. This is not just the interface signals but also what's needed in the FPGA as well as the embedded SW. > > For example, for the ESDI and SMD interface in order to meet the head switch times (1-2 microseconds) requires that a full cylinder be cached in HW. Once you do that and look at the timings to move a max cylinder between the HW cache (that will serialize/de-serialize the data over the > interface) and storage, you'll see that the only way to have any reasonable performance (e.g. not have seek times be > 40ms for *any* > seek) is to cache the entire drive image in DRAM and lazily write back dirty tracks. > > I've been looking at the Xylinx Zynq SoCs for this (mainly the Zynq 7020 for single drive emulation and the Zynq Ultrascale+ for up to 4 drives). In my case the HW, FPGA logic and SW will share significant portions but they will not be identical. In my case there is no need for an external PC (just adds complexity) other than something to do basic configuration (e.g. drive parameters such as number of heads, number of cylinders, etc) which will actually be over USB/serial. The actual persistent storage will be an SD card since all reading will be done at "boot time" and writes will be handled in a lazy manner (since the writes will first go to the DRAM based upon time or seek). > > It may also be sufficient for configuration purposes to have a file > (text) on the SD card that defines the configuration so no external interactions would be necessary. I'm still thinking about that one. ;-) > > TTFN - Guy > > On 4/12/22 22:35, shadoooo via cctech wrote: >> Hello, >> I'm a decent collector of big iron, aka mini computers, mainly DEC and DG. >> I'm often facing common problems with storage devices, magnetic discs and tapes are a little prone to give headaches after years, and replacement drives/media in case of a severe failure are unobtainable. >> In some cases, the ability to make a dump of the media, also without a running computer is very important. >> >> Whence the idea: realize an universal device, with several input/output interfaces, which could be used both as storage emulator, to run a computer without real storage, and as controller emulator, to read/write a media without a running computer. >> To reduce costs as much as possible, and to allow the better compatibility, the main board shall host enough electrical interfaces to support a large number of disc standard interfaces, ideally by exchanging only a personality adapter for each specific interface, i.e. connectors and few components. >> >> There are several orders of problems: >> - electrical signals, number and type (most disk employ 5V TTL or 3.3V >> TTL, some interfaces use differential mode for some faster signals?) >> - logical implementation: several electrical signals are used for a >> specific interface. These must be handled with correct timings >> - software implementation: the universal device shall be able to >> switch between interface modes and be controlled by a remote PC >> >> I suppose the only way to obtain this is to employ an FPGA for logic implementation of the interface, and a microprocessor running Linux to handle software management, data interchange to external (via Ethernet). This means a Xilinx Zynq module for instance. >> I know there are several ready devices based on cheaper microcontrollers, but I'm sure these can't support fast and tight timing required by hard disk interfaces (SMD-E runs at 24MHz). >> >> The main board should include a large enough array of bidirectional transceivers, possibly with variable voltage, to support as much interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point. >> The common factor determining what kind of disc interface can be support on hardware side is obviously the type of transceiver employed, for instance a SATA would require a differential serial channel, which could not be available. >> But most old electronic is based on TTL/CMOS 5V logic, so a large variety of computer generations should be doable. >> >> For the first phase, I would ask you to contribute with a list of interfaces which could be interesting to emulate, specially if these are similar to one from my list. >> I please submitters to send me by email or by web link when possible, detailed documentation about the interface they propose, so I can check if it could be doable and what kind of electrical signals are needed. >> Also detailed information about interfaced I listed is appreciated, as could give some detail I'm missing. >> >> Thanks >> Andrea > -- > TTFN - Guy > > > -- TTFN - Guy From jay-tuhs9915 at toaster.com Fri Apr 15 13:07:42 2022 From: jay-tuhs9915 at toaster.com (Jay Logue) Date: Fri, 15 Apr 2022 11:07:42 -0700 Subject: Advice on Desoldering an IC In-Reply-To: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> Message-ID: <20220415180745.42F9F4E6C2@mx2.ezwind.net> As mentioned, I find it best to cut the pins off the IC right at the IC body and then remove them individually.? Once the IC is removed, I use a third hand to hold the board vertically, and then grab each pin with tweezers or needle-nose pliers from one side of the board and lightly touch the soldering iron to the hole on the other side until the pin pulls free. Once all the pins have been removed its fairly easy to clear the solder using a solder sucker.? Hold the solder sucker on one side of the hole, stick the a fine-tipped soldering iron into the hole from the other side, and then release the solder sucker.? Its a bit of a balancing act, but it works pretty well and introduces minimal heat into the board. Replaced a good 20+ chips across my various PDP-11 boards this way. --Jay On 4/15/2022 10:49 AM, Rob Jarratt via cctalk wrote: > I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really > struggling to desolder it. I am using the technique of applying fresh solder > and then removing it. But after multiple cycles of this I think I am > starting to damage the PCB. > > > > I am using a fairly cheap desoldering station (this one > https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD > 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is > equivalent to that of the professional Hakko ones though. I am also trying a > hand desoldering pump. None of these are able to clear many of the holes of > solder, although some are doing better than others. Nevertheless, the IC > remains stubbornly unmoving. > > > > Are there any tips for removing ICs? > > > > Thanks > > > > Rob > From tom94022 at comcast.net Fri Apr 15 14:12:12 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Fri, 15 Apr 2022 12:12:12 -0700 Subject: idea for a universal disk interface In-Reply-To: <7063b5b9-ca21-96a5-95cb-c6a0ca82d6a3@shiresoft.com> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> <7063b5b9-ca21-96a5-95cb-c6a0ca82d6a3@shiresoft.com> Message-ID: <016f01d850fc$b6d76620$24863260$@comcast.net> I haven't looked it up but I bet the head switch time is a lot longer than 1-2 usec - that's what the leading gap is for and the sync took most of the gap back in those days. The issue is sustained data rate isn't it? The ESMD raw data rate is 24 Mb/s but the formatted data is something like 80% of that or maybe 2.5 MB/sec. A modern HDD in sequential mode can sustain a much higher rate, e.g. Seagate SAS at 520 MB/sec. My understanding is that the sectors are slipped and/or cylinders are horizontal so that head switching doesn't lose any revolutions. Maybe one would run into a problem at the cylinder seek moment so maybe one would have to keep each full emulated cylinder on the modern drive?s cylinder, but with Terabytes of data on a modern drive who cares about some wasted storage Tom -----Original Message----- From: Guy Sotomayor [mailto:ggs at shiresoft.com] Sent: Friday, April 15, 2022 10:56 AM To: t.gardner at computer.org; cctech at classiccmp.org Subject: Re: idea for a universal disk interface I ran the numbers for Zynq FPGAs. First of all for ESDI and SMD the head switch time is 1-2us (basically the time it takes for the clocks to re-lock on the new data). Two tracks isn't sufficient (which is the "other" track...you will be wrong). So I decided to go and have a full cylinder (I'm allowing for up to 32KB tracks and up to 16 heads) which is 512KB. The Zynq DMA from HW block RAM to DRAM (at 500MB/s) is ~1ms. Given that the previous cylinder could be dirty (e.g. has written data), the worst case seek time is ~2ms. This allows me to emulate any seek latency curve(s) I want. In my design, any dirty data is written back to storage in a lazy manner so the performance of the storage isn't really an issue. I should note that the Zynq 7020 module has 1GB of DRAM on it, so there is no additional cost to just put the entire disk contents in DRAM and I'm using the attached SD Card interface for storage (so you can use a $10 SD Card for storage). Adding a high speed disk interface (e.g. MD.2, PCIe, or other serially attached storage) would add additional cost in terms of having to create the interface as well as a reasonably fast drive and I don't see the advantage. I'm planning on using a Zynq UltraScale+ module to allow for larger disks and multiple disk emulations (it has more block RAM and 4GB of DRAM on the module). TTFN - Guy On 4/14/22 23:34, Tom Gardner wrote: > I suggest if we are talking about an emulator it really isn't necessary to have the entire disk in DRAM, two tracks of DRAM acting as a buffer with a modern HDD holding the emulated drive's data should be fast enough to keep any old iron controller operating without missing any revolutions. The maximum unformatted track length of any old iron drive is well known and therefore one can allocate the number of blocks sufficient to store a full track and then write every track, gaps and all to the modern disk. Given the data rate, track size and sequential seek times of a modern HDD one should be able to fill then next track buffer before the current track buffer is read into the controller. If two track buffers and an HDD isn't fast enough then one could add a track buffer or two or go to SSD's. > > This was the approach IBM used in it's first RAMAC RAID where I think > they had to buffer a whole cylinder but that was many generations ago > > Tom > > -----Original Message----- > From: Guy Sotomayor [ mailto:ggs at shiresoft.com] > Sent: Wednesday, April 13, 2022 10:02 AM > To: cctech at classiccmp.org > Subject: Re: idea for a universal disk interface > > I've had a similar project in the works for a while (mainly for ESDI and SMD). > > I think the main issue you're going to face is that what you need to do for something like ESDI or SMD (or any of the bit serial interfaces) is going to be radically different than something like IDE or SCSI. This is not just the interface signals but also what's needed in the FPGA as well as the embedded SW. > > For example, for the ESDI and SMD interface in order to meet the head > switch times (1-2 microseconds) requires that a full cylinder be > cached in HW. Once you do that and look at the timings to move a max > cylinder between the HW cache (that will serialize/de-serialize the > data over the > interface) and storage, you'll see that the only way to have any > reasonable performance (e.g. not have seek times be > 40ms for *any* > seek) is to cache the entire drive image in DRAM and lazily write back dirty tracks. > > I've been looking at the Xylinx Zynq SoCs for this (mainly the Zynq 7020 for single drive emulation and the Zynq Ultrascale+ for up to 4 drives). In my case the HW, FPGA logic and SW will share significant portions but they will not be identical. In my case there is no need for an external PC (just adds complexity) other than something to do basic configuration (e.g. drive parameters such as number of heads, number of cylinders, etc) which will actually be over USB/serial. The actual persistent storage will be an SD card since all reading will be done at "boot time" and writes will be handled in a lazy manner (since the writes will first go to the DRAM based upon time or seek). > > It may also be sufficient for configuration purposes to have a file > (text) on the SD card that defines the configuration so no external > interactions would be necessary. I'm still thinking about that one. > ;-) > > TTFN - Guy > > On 4/12/22 22:35, shadoooo via cctech wrote: >> Hello, >> I'm a decent collector of big iron, aka mini computers, mainly DEC and DG. >> I'm often facing common problems with storage devices, magnetic discs and tapes are a little prone to give headaches after years, and replacement drives/media in case of a severe failure are unobtainable. >> In some cases, the ability to make a dump of the media, also without a running computer is very important. >> >> Whence the idea: realize an universal device, with several input/output interfaces, which could be used both as storage emulator, to run a computer without real storage, and as controller emulator, to read/write a media without a running computer. >> To reduce costs as much as possible, and to allow the better compatibility, the main board shall host enough electrical interfaces to support a large number of disc standard interfaces, ideally by exchanging only a personality adapter for each specific interface, i.e. connectors and few components. >> >> There are several orders of problems: >> - electrical signals, number and type (most disk employ 5V TTL or >> 3.3V TTL, some interfaces use differential mode for some faster >> signals?) >> - logical implementation: several electrical signals are used for a >> specific interface. These must be handled with correct timings >> - software implementation: the universal device shall be able to >> switch between interface modes and be controlled by a remote PC >> >> I suppose the only way to obtain this is to employ an FPGA for logic implementation of the interface, and a microprocessor running Linux to handle software management, data interchange to external (via Ethernet). This means a Xilinx Zynq module for instance. >> I know there are several ready devices based on cheaper microcontrollers, but I'm sure these can't support fast and tight timing required by hard disk interfaces (SMD-E runs at 24MHz). >> >> The main board should include a large enough array of bidirectional transceivers, possibly with variable voltage, to support as much interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point. >> The common factor determining what kind of disc interface can be support on hardware side is obviously the type of transceiver employed, for instance a SATA would require a differential serial channel, which could not be available. >> But most old electronic is based on TTL/CMOS 5V logic, so a large variety of computer generations should be doable. >> >> For the first phase, I would ask you to contribute with a list of interfaces which could be interesting to emulate, specially if these are similar to one from my list. >> I please submitters to send me by email or by web link when possible, detailed documentation about the interface they propose, so I can check if it could be doable and what kind of electrical signals are needed. >> Also detailed information about interfaced I listed is appreciated, as could give some detail I'm missing. >> >> Thanks >> Andrea > -- > TTFN - Guy > > > -- TTFN - Guy From ggs at shiresoft.com Fri Apr 15 17:25:28 2022 From: ggs at shiresoft.com (Guy Sotomayor) Date: Fri, 15 Apr 2022 15:25:28 -0700 Subject: idea for a universal disk interface In-Reply-To: <016f01d850fc$b6d76620$24863260$@comcast.net> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> <7063b5b9-ca21-96a5-95cb-c6a0ca82d6a3@shiresoft.com> <016f01d850fc$b6d76620$24863260$@comcast.net> Message-ID: I'm looking at what the spec says.? ;-)? The read command delay from the head set command is 15us (so I was wrong) but still not a lot of time (that is after a head set, a read command must be at least 15us later). Since I'm not looking at formatted data rate (just handling the raw bit stream) it doesn't really matter what the formatted rate is...and the formatted data is different between different controllers, so I don't want to even try to do that on the fly (and they might do tricks where different tracks/cylinders have different formats. If some one wants the "formatted" data, then I'd let them post process that off the captured data. As I said, I'm trying to do this with fairly simple logic and low cost storage (as such this isn't going to particularly cheap).? I don't want to add another $100+ to the cost just to have a high performance drive when the HW is capable of doing a suitable job with a $10 SD card. In reality an SD card (from a storage perspective) is way overkill.? We're talking about emulating drives with capacities < 1GB and good quality SD cards contain 32GB for $10 or so. TTFN - Guy On 4/15/22 12:12, Tom Gardner wrote: > > I haven't looked it up but I bet the head switch time is a lot longer > than 1-2 usec - that's what the leading gap is for and the sync took > most of the gap back in those days. > > The issue is sustained data rate isn't it?? The ESMD raw data rate is > 24 Mb/s but the formatted data is something like 80% of that or maybe > 2.5 MB/sec.? A modern HDD in sequential mode can sustain a much higher > rate, e.g. Seagate SAS > > at 520 MB/sec.? My understanding is that the sectors are slipped > and/or cylinders are horizontal so that head switching doesn't lose > any revolutions.? Maybe one would run into a problem at the cylinder > seek moment so maybe one would have to keep each full emulated > cylinder on the modern drive?s cylinder, but with Terabytes of data on > a modern drive who cares about some wasted storage > > Tom > > -----Original Message----- > From: Guy Sotomayor [mailto:ggs at shiresoft.com] > Sent: Friday, April 15, 2022 10:56 AM > To: t.gardner at computer.org; cctech at classiccmp.org > Subject: Re: idea for a universal disk interface > > I ran the numbers for Zynq FPGAs.? First of all for ESDI and SMD the > head switch time is 1-2us (basically the time it takes for the clocks > to re-lock on the new data). > > Two tracks isn't sufficient (which is the "other" track...you will be > wrong). > > So I decided to go and have a full cylinder (I'm allowing for up to > 32KB tracks and up to 16 heads) which is 512KB.? The Zynq DMA from HW > block RAM to DRAM (at 500MB/s) is ~1ms.? Given that the previous > cylinder could be dirty (e.g. has written data), the worst case seek > time is ~2ms.? This allows me to emulate any seek latency curve(s) I want. > > In my design, any dirty data is written back to storage in a lazy > manner so the performance of the storage isn't really an issue. > > I should note that the Zynq 7020 module has 1GB of DRAM on it, so > there is no additional cost to just put the entire disk contents in > DRAM and I'm using the attached SD Card interface for storage (so you > can use a > > $10 SD Card for storage).? Adding a high speed disk interface (e.g. > > MD.2, PCIe, or other serially attached storage) would add additional > cost in terms of having to create the interface as well as a > reasonably fast drive and I don't see the advantage. > > I'm planning on using a Zynq UltraScale+ module to allow for larger > disks and multiple disk emulations (it has more block RAM and 4GB of > DRAM on the module). > > TTFN - Guy > > On 4/14/22 23:34, Tom Gardner wrote: > > > I suggest if we are talking about an emulator it really isn't > necessary to have the entire disk in DRAM, two tracks of DRAM acting > as a buffer with a modern HDD holding the emulated drive's data should > be fast enough to keep any old iron controller operating without > missing any revolutions.? The maximum unformatted track length of any > old iron drive is well known and therefore one can allocate the number > of blocks sufficient to store a full track and then write every track, > gaps and all to the modern disk.? Given the data rate, track size and > sequential seek times of a modern HDD one should be able to fill then > next track buffer before the current track buffer is read into the > controller.? If two track buffers and an HDD isn't fast enough then > one could add a track buffer or two or go to SSD's. > > > > > > This was the approach IBM used in it's first RAMAC RAID where I think > > > they had to buffer a whole cylinder but that was many generations ago > > > > > > Tom > > > > > > -----Original Message----- > > > From: Guy Sotomayor [mailto:ggs at shiresoft.com > ] > > > Sent: Wednesday, April 13, 2022 10:02 AM > > > To: cctech at classiccmp.org > > > Subject: Re: idea for a universal disk interface > > > > > > I've had a similar project in the works for a while (mainly for ESDI > and SMD). > > > > > > I think the main issue you're going to face is that what you need to > do for something like ESDI or SMD (or any of the bit serial > interfaces) is going to be radically different than something like IDE > or SCSI.? This is not just the interface signals but also what's > needed in the FPGA as well as the embedded SW. > > > > > > For example, for the ESDI and SMD interface in order to meet the head > > > switch times (1-2 microseconds) requires that a full cylinder be > > > cached in HW.? Once you do that and look at the timings to move a max > > > cylinder between the HW cache (that will serialize/de-serialize the > > > data over the > > > interface) and storage, you'll see that the only way to have any > > > reasonable performance (e.g. not have seek times be > 40ms for *any* > > > seek) is to cache the entire drive image in DRAM and lazily write > back dirty tracks. > > > > > > I've been looking at the Xylinx Zynq SoCs for this (mainly the Zynq > 7020 for single drive emulation and the Zynq Ultrascale+ for up to 4 > drives).? In my case the HW, FPGA logic and SW will share significant > portions but they will not be identical.? In my case there is no need > for an external PC (just adds complexity) other than something to do > basic configuration (e.g. drive parameters such as number of heads, > number of cylinders, etc) which will actually be over USB/serial.? The > actual persistent storage will be an SD card since all reading will be > done at "boot time" and writes will be handled in a lazy manner (since > the writes will first go to the DRAM based upon time or seek). > > > > > > It may also be sufficient for configuration purposes to have a file > > > (text) on the SD card that defines the configuration so no external > > > interactions would be necessary. I'm still thinking about that one. > > > ;-) > > > > > > TTFN - Guy > > > > > > On 4/12/22 22:35, shadoooo via cctech wrote: > > >> Hello, > > >> I'm a decent collector of big iron, aka mini computers, mainly DEC > and DG. > > >> I'm often facing common problems with storage devices, magnetic > discs and tapes are a little prone to give headaches after years, and > replacement drives/media in case of a severe failure are unobtainable. > > >> In some cases, the ability to make a dump of the media, also > without a running computer is very important. > > >> > > >> Whence the idea: realize an universal device, with several > input/output interfaces, which could be used both as storage emulator, > to run a computer without real storage, and as controller emulator, to > read/write a media without a running computer. > > >> To reduce costs as much as possible, and to allow the better > compatibility, the main board shall host enough electrical interfaces > to support a large number of disc standard interfaces, ideally by > exchanging only a personality adapter for each specific interface, > i.e. connectors and few components. > > >> > > >> There are several orders of problems: > > >> - electrical signals, number and type (most disk employ 5V TTL or > > >> 3.3V TTL, some interfaces use differential mode for some faster > > >> signals?) > > >> - logical implementation: several electrical signals are used for a > > >> specific interface. These must be handled with correct timings > > >> - software implementation: the universal device shall be able to > > >> switch between interface modes and be controlled by a remote PC > > >> > > >> I suppose the only way to obtain this is to employ an FPGA for > logic implementation of the interface, and a microprocessor running > Linux to handle software management, data interchange to external (via > Ethernet). This means a Xilinx Zynq module for instance. > > >> I know there are several ready devices based on cheaper > microcontrollers, but I'm sure these can't support fast and tight > timing required by hard disk interfaces (SMD-E runs at 24MHz). > > >> > > >> The main board should include a large enough array of bidirectional > transceivers, possibly with variable voltage, to support as much > interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, > ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to > give a starting point. > > >> The common factor determining what kind of disc interface can be > support on hardware side is obviously the type of transceiver > employed, for instance a SATA would require a differential serial > channel, which could not be available. > > >> But most old electronic is based on TTL/CMOS 5V logic, so a large > variety of computer generations should be doable. > > >> > > >> For the first phase, I would ask you to contribute with a list of > interfaces which could be interesting to emulate, specially if these > are similar to one from my list. > > >> I please submitters to send me by email or by web link when > possible, detailed documentation about the interface they propose, so > I can check if it could be doable and what kind of electrical signals > are needed. > > >> Also detailed information about interfaced I listed is appreciated, > as could give some detail I'm missing. > > >> > > >> Thanks > > >> Andrea > > > -- > > > TTFN - Guy > > > > > > > > > > > -- > > TTFN - Guy > -- TTFN - Guy From cctalk at beyondthepale.ie Sat Apr 16 05:39:07 2022 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Sat, 16 Apr 2022 11:39:07 +0100 (WET-DST) Subject: Advice on Desoldering an IC In-Reply-To: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> Message-ID: <01SC3PKSHV3K8X03CA@beyondthepale.ie> I had to desolder a fairly large number of 14/16 pin ICs from a two layer PCB recently. I had an basic soldering iron and a spring loaded solder sucker thing. I also had some wick but never having had good results with this, I decided not to bother trying it this time. I was aware of the idea of cutting the pins to make removal easier but I preferred to keep the ICs intact in case they turned out not to be faulty. My first attempt was pretty bad and did quite a bit of damage. By the tenth time around, I was making a much nicer job of it so what worked for me was practice. I ended up propping the PCB up vertically, placing the sucker squarely over the joint on the solder side, heating the IC pin on the component side with the soldering iron and releasing the plunger in the sucker after allowing the solder a little time to melt. Sometimes this cleared all the solder out of the hole but usually it did not. I found it useful to get the tip of the solder sucker to seal well around the joint with little or no gaps for air to get through. I kept going around the pins until I could see through most of the holes when holding the board up to the light. At this point many of the pins were still stuck to the sides of the holes so I then applied the soldering iron to each pin in turn on the solder side, pushing the pin gently away from the side of the hole. When the solder melted, the pin would then move to the centre of the hole and sometimes come free entirely. Then I would go back to the first procedure with the solder sucker to clear more solder out of the holes. Using no more than finger pressure, I would try to pull the IC out while dabbing the soldering iron on any joints that seemed to be still holding it in place. After a several interations, the IC would pop out, maybe at one end only first. A bit tedious and not at all quick but it worked well enough in the end. Unfortunatly, the next time I have to do some desoldering, I will have probably forgotten what worked well this time and have to learn it all over again. I will probably also forget that it would be useful to get some practice in first... Regards, Peter Coghlan. Rob Jarratt via cctalk wrote: > I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really > struggling to desolder it. I am using the technique of applying fresh solder > and then removing it. But after multiple cycles of this I think I am > starting to damage the PCB. > > > > I am using a fairly cheap desoldering station (this one > https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD > 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is > equivalent to that of the professional Hakko ones though. I am also trying a > hand desoldering pump. None of these are able to clear many of the holes of > solder, although some are doing better than others. Nevertheless, the IC > remains stubbornly unmoving. > > > > Are there any tips for removing ICs? > > > > Thanks > > > > Rob > From dkelvey at hotmail.com Sat Apr 16 08:00:12 2022 From: dkelvey at hotmail.com (dwight) Date: Sat, 16 Apr 2022 13:00:12 +0000 Subject: Advice on Desoldering an IC In-Reply-To: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> Message-ID: Sometimes the IC has been installed with the pins under tension. This is typical of machine inserted ICs. When the solder is loose, bend the pin away from the side it is pressed against. Do this carefully, don't over bend. You want it to center in the hole. I recommend doing this with a separate iron than the desoldering tool, so you can see what you are doing. Once the pin is nicely centered in the hole use the desoldering tool to suck the solder out. Make sure to always use a clean tip. An oxidixed tip will require excess pressure to transfer heatand damage the trace. Keep the solder shinny with a spung or soft metal wool. Do mot use a hard metal to clean an iron clad tip or it will damage the iron and rot it from the inside ? When not using the iron but leaving it hot, always leave a blob of solder so that it won't have a thin oxide coating that is hard to remove. KEEP A CLEAN TIP! After sucking the solder with the tool, with a small screw driver, give the pin a slight sideways pressure and let the screw driver slip off the pin. It should make a plink sound or a momentary ring. This is something that you'll just have to learn the sound of. If it doesn't sound right it means it isn't free of the sides. Add solder and try to bend the pin. Often the body side of the IC will have a tiny film of solder right where the IC sits on the trace. If this is just the tiny amount to solder, one can break it loose with a pair of short needle nose pliers, By squeezing the two sides of the IC together. Don't expect to break loose a large blob. Of course, if you expect to throw the IC away, use sharp pointed dikes to cut the pins at the package and pull each pin individually while the solder is hot. Use a small vice to hold the board so you can work from both sides. Tweezers are best but heat the solder first and when hot grab the pin from the top. Work quickly while the solder is hot. You may need to refill the pin with fresh clean solder. Old oxidized solder does not remove easily. Use separate rosin flux if you have it ( not plumber flux!! ). Like I said earlier, use a really clean tip. It should be shinny before trying to heat the board. It is hard to do with the higher temperature solders. There is some low temperature stuff you can use to remove solder more quickly. I like using a large manual plastic solderpulit. Some like to use solder wick. The solder removal suckers are often hard to keep the tip clean. If you have to press hard on the tip to the work, the tip is not clean. It does help to have some really tiny flux core solder to touch right at the junction of the iron and work to start the heat transfer. Never use force to get the heat to start to transfer! Clean tip and a quick touch with solder is all that is needed. When you are not using the iron for some time, but leaving it on, add a thicker blob of solder on it so it doesn't get a thin hard to clean oxide on it. KEEP YOUR TIP FREE OF THIN OXIDE! Dwight ________________________________ From: cctalk on behalf of Rob Jarratt via cctalk Sent: Friday, April 15, 2022 10:49 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: Advice on Desoldering an IC I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really struggling to desolder it. I am using the technique of applying fresh solder and then removing it. But after multiple cycles of this I think I am starting to damage the PCB. I am using a fairly cheap desoldering station (this one https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is equivalent to that of the professional Hakko ones though. I am also trying a hand desoldering pump. None of these are able to clear many of the holes of solder, although some are doing better than others. Nevertheless, the IC remains stubbornly unmoving. Are there any tips for removing ICs? Thanks Rob From tom94022 at comcast.net Sat Apr 16 14:13:50 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Sat, 16 Apr 2022 12:13:50 -0700 Subject: idea for a universal disk interface In-Reply-To: References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> Message-ID: <00a301d851c6$1ba56bf0$52f043d0$@comcast.net> Not the RAMAC of 1956 but the RAMAC Virtual Array of 1996, https://www.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=897/ENUSC96-029&info type=AN&subtype=CA&appname=skmwww It emulated several different IBM DASD of varying CKD track lengths on fixed block HDDs The trick they used and the one I'm suggesting is they stored an entire track, index to index including, gaps, headers, etc, in a concatenated set of fixed blocks greater than the maximum length of the raw track. For example, an SMD drive turning at 3600 RPM and with a data rate of 15 Mb/sec and a 5% speed variation has a maximum track length of 31,250 bytes nominally but never more than 32,895 on the slowest drive. So allocating 65 sectors (512 byte) will fit the worst track. Of course since the emulator doesn't have any speed variation only 62 sectors need be allocated per track. I poked around in some old Disk/Trends and it seems the largest ESDI/SMD drive was on the order of 2.5 GB which is likely a formatted capacity so a full drive emulation might require a maximum of 3.3 GB which is well within the size of a modern PC and given the memory data rate I suspect an emulator wouldn't have to buffer more than two memory words. Tom -----Original Message----- From: Fred Cisin [mailto:cisin at xenosoft.com] Sent: Friday, April 15, 2022 3:54 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: RE: idea for a universal disk interface On Thu, 14 Apr 2022, Tom Gardner via cctalk wrote: > This was the approach IBM used in it's first RAMAC RAID where I think > they had to buffer a whole cylinder but that was many generations ago (my copy of the specs may not be exact): Buffering a whole cylinder, or a whole surface, of the RAMAC was no big deal. One hundred surfaces (52 platters, but not using bottom of bottommost nor top of topmost) totalling to 5 million 6 bit characters. That's 50,000 characters per surface. OR 50,000 characters per cylinder ("square geometry" :-) 100 tracks per side of a platter (at 20 tracks per inch) meant about 500 characters per track Problematic in the CP/M days, but such a buffer is small in current usage. From bfranchuk at jetnet.ab.ca Sat Apr 16 15:39:18 2022 From: bfranchuk at jetnet.ab.ca (ben) Date: Sat, 16 Apr 2022 14:39:18 -0600 Subject: idea for a universal disk interface In-Reply-To: <00a301d851c6$1ba56bf0$52f043d0$@comcast.net> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> <00a301d851c6$1ba56bf0$52f043d0$@comcast.net> Message-ID: <5beefb4c-2ce8-eb23-d331-85370cc41fc3@jetnet.ab.ca> On 2022-04-16 1:13 p.m., Tom Gardner via cctalk wrote: > Not the RAMAC of 1956 but the RAMAC Virtual Array of 1996, > https://www.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=897/ENUSC96-029&info > type=AN&subtype=CA&appname=skmwww > It emulated several different IBM DASD of varying CKD track lengths on fixed > block HDDs > > The trick they used and the one I'm suggesting is they stored an entire > track, index to index including, gaps, headers, etc, in a concatenated set > of fixed blocks greater than the maximum length of the raw track. > > For example, an SMD drive turning at 3600 RPM and with a data rate of 15 > Mb/sec and a 5% speed variation has a maximum track length of 31,250 bytes > nominally but never more than 32,895 on the slowest drive. So allocating 65 > sectors (512 byte) will fit the worst track. Of course since the emulator > doesn't have any speed variation only 62 sectors need be allocated per > track. > > I poked around in some old Disk/Trends and it seems the largest ESDI/SMD > drive was on the order of 2.5 GB which is likely a formatted capacity so a > full drive emulation might require a maximum of 3.3 GB which is well within > the size of a modern PC and given the memory data rate I suspect an emulator > wouldn't have to buffer more than two memory words. > > Tom > How do you handle the disk hardware timing, power up, seek and disk RPM?. Ben. From cisin at xenosoft.com Sat Apr 16 16:54:44 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Sat, 16 Apr 2022 14:54:44 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: <00a301d851c6$1ba56bf0$52f043d0$@comcast.net> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> <00a301d851c6$1ba56bf0$52f043d0$@comcast.net> Message-ID: ONCE MORE, I APOLOGIZE. (details bottom posted) >>> This was the approach IBM used in it's first RAMAC RAID where I think >>> they had to buffer a whole cylinder but that was many generations ago > (my copy of the specs may not be exact): > Buffering a whole cylinder, or a whole surface, of the RAMAC was no big > deal. > One hundred surfaces (52 platters, but not using bottom of bottommost nor > top of topmost) totalling to 5 million 6 bit characters. > That's 50,000 characters per surface. > OR 50,000 characters per cylinder > ("square geometry" :-) > 100 tracks per side of a platter (at 20 tracks per inch) meant about 500 > characters per track > Problematic in the CP/M days, but such a buffer is small in current usage. On Sat, 16 Apr 2022, Tom Gardner via cctalk wrote: > Not the RAMAC of 1956 but the RAMAC Virtual Array of 1996, > https://www.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=897/ENUSC96-029&info > type=AN&subtype=CA&appname=skmwww > It emulated several different IBM DASD of varying CKD track lengths on fixed > block HDDs > > The trick they used and the one I'm suggesting is they stored an entire > track, index to index including, gaps, headers, etc, in a concatenated set > of fixed blocks greater than the maximum length of the raw track. > > For example, an SMD drive turning at 3600 RPM and with a data rate of 15 > Mb/sec and a 5% speed variation has a maximum track length of 31,250 bytes > nominally but never more than 32,895 on the slowest drive. So allocating 65 > sectors (512 byte) will fit the worst track. Of course since the emulator > doesn't have any speed variation only 62 sectors need be allocated per > track. > > I poked around in some old Disk/Trends and it seems the largest ESDI/SMD > drive was on the order of 2.5 GB which is likely a formatted capacity so a > full drive emulation might require a maximum of 3.3 GB which is well within > the size of a modern PC and given the memory data rate I suspect an emulator > wouldn't have to buffer more than two memory words. THAT is an fascinating project! "Never mind" - Emily Litella (Gilda Radner) I need to step back and BUFFER my replies for a period of time. It seems that almost everything that I reply to, I misunderstand some part of what I am replying to, and need to apologize. As a mitigating factor, in this same thread, I had mentioned owning a RAMAC platter (from 60 years ago), that was too damaged to even consider trying to read from, so that I am making a patio table out of it. I don't consider 1996 to be "many generations ago" and, You had said buffer a whole CYLINDER. I wrote a reply assuming that you meant TRACK. When I noticed the cylinder/track confusion, I edited my reply to be numbers for a cylinder, but failed to completely edit out my comment that buffering the size of an entire [EARLY 1960] RAMAC TRACK was no big deal, and was promptly reminded that in the day, buffering 50K WAS a big deal. "Never mind" -- Grumpy Ol' Fred cisin at xenosoft.com From tom94022 at comcast.net Sat Apr 16 16:32:30 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Sat, 16 Apr 2022 14:32:30 -0700 Subject: idea for a universal disk interface In-Reply-To: References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> <7063b5b9-ca21-96a5-95cb-c6a0ca82d6a3@shiresoft.com> <016f01d850fc$b6d76620$24863260$@comcast.net> Message-ID: <00b801d851d9$7b6417e0$722c47a0$@comcast.net> -----Original Message----- From: Guy Sotomayor [mailto:ggs at shiresoft.com] Sent: Friday, April 15, 2022 3:25 PM To: t.gardner at computer.org; cctech at classiccmp.org Subject: Re: idea for a universal disk interface I'm looking at what the spec says. ;-) The read command delay from the head set command is 15us (so I was wrong) but still not a lot of time (that is after a head set, a read command must be at least 15us later). ----- And after the read command is given there is a gap, usually all zeros, at the end of which is a sync byte which is then followed by the first good data (or header) byte. In SMD the gaps can be 20 or 30 bytes long so there is quite a bit of time until good data. Tom From ggs at shiresoft.com Sat Apr 16 19:14:13 2022 From: ggs at shiresoft.com (Guy Sotomayor) Date: Sat, 16 Apr 2022 17:14:13 -0700 Subject: idea for a universal disk interface In-Reply-To: <00b801d851d9$7b6417e0$722c47a0$@comcast.net> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> <7063b5b9-ca21-96a5-95cb-c6a0ca82d6a3@shiresoft.com> <016f01d850fc$b6d76620$24863260$@comcast.net> <00b801d851d9$7b6417e0$722c47a0$@comcast.net> Message-ID: <818a6f59-7087-59c1-1077-3d5cd5a2b8dc@shiresoft.com> I think the issue is that you're thinking of somehow emulating the formatted data.? I'm working on just emulating the bit-stream as then it'll work with any controller and sector/track layout so I won't actually know what a sector really is (unless I do "hard sectoring" which some drives did support). At a 15Mhz clock rate, 30 bytes is 1.3333us.? Not a lot of time. And frankly, that's defined by the controller and not the drive (though usually the drives specify some layout but that's only a recommendation).? Dealing with drive speed variations doesn't solve anything because it's actually done via the drive itself (e.g. the drive provides the clock to the controller so any variation is already accounted for).? The drive really cares about total bits (e.g. bits-per-inch) that the media supports. If we assume 32KB track at 500MB/s DMA transfer rate, that takes 65us.? But as I've said, the spec says that the time between a head select and read is 15us or so, you can see that you can't just transfer a track and still meet the minimum timings.? I will agree that you can probably take longer but I'm trying to have a design that can meet all of the minimum timings so I can emulate any drive/controller combination with at least the same performance as a real drive (and in many cases I can provide *much* higher performance). By keeping a full cylinder in the FPGA Block RAM I can keep the head select time < 1us (it's basically just selecting the high order address bits going to the block RAM). By keeping the entire disk image in DRAM, I can emulate any drive (that fits in the DRAM) with identical (or faster) performance. If I wanted to do something simpler (not much though) I could have a smaller DRAM (but since the Zynq modules I'm using have 1GB or 4GB of DRAM there isn't much motivation) but then any seek would be limited by access to the backing store.? Also remember, in the worst case you have to write the previous track out if it was written to so that will slow things down as well.? With the full image maintained in DRAM, any writes can be performed in a lazy manner in the background so that won't impact the performance of the emulated drive. TTFN - Guy On 4/16/22 14:32, Tom Gardner wrote: > -----Original Message----- > From: Guy Sotomayor [mailto:ggs at shiresoft.com] > Sent: Friday, April 15, 2022 3:25 PM > To: t.gardner at computer.org; cctech at classiccmp.org > Subject: Re: idea for a universal disk interface > > I'm looking at what the spec says. ;-) The read command delay from the head set command is 15us (so I was wrong) but still not a lot of time (that is after a head set, a read command must be at least 15us later). > > > > ----- > And after the read command is given there is a gap, usually all zeros, at the end of which is a sync byte which is then followed by the first good data (or header) byte. In SMD the gaps can be 20 or 30 bytes long so there is quite a bit of time until good data. > > Tom > > -- TTFN - Guy From shadoooo at gmail.com Sun Apr 17 12:28:21 2022 From: shadoooo at gmail.com (shadoooo) Date: Sun, 17 Apr 2022 17:28:21 +0000 (UTC) Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: hello, there's much discussion about the right? method to transfer data in and out. Of course there are several methods, the right one must be carefully chosen after some review of all the disk interfaces that must be supported. The idea of having a copy of the whole disk in RAM is OK, assuming that a maximum size of around 512MB is required, as the RAM is also needed for the OS, and for Zynq maximum is 1GB. About logic implementation, we know that the device must be able to work with one cylinder at a time. Given RAM bandwidth, this doesn't means that it must fit completely in blockram, also it can be produced at output while it is read, so delay time is really the time between first data request and actual read response. In between an elastic FIFO is required to adapt synchronous constant rate transfer of the disk to the burst transfer toward RAM. Guy, you mentioned about development of a similar interface. So you already produced some working hardware? Andrea From paulkoning at comcast.net Sun Apr 17 13:12:26 2022 From: paulkoning at comcast.net (Paul Koning) Date: Sun, 17 Apr 2022 14:12:26 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: > On Apr 17, 2022, at 1:28 PM, shadoooo via cctalk wrote: > > hello, > there's much discussion about the right method to transfer data in and out. > Of course there are several methods, the right one must be carefully chosen after some review of all the disk interfaces that must be supported. The idea of having a copy of the whole disk in RAM is OK, assuming that a maximum size of around 512MB is required, as the RAM is also needed for the OS, and for Zynq maximum is 1GB. For reading a disk, an attractive approach is to do a high speed analog capture of the waveforms. That way you don't need a priori knowledge of the encoding, and it also allows you to use sophisticated algorithms (DSP, digital filtering, etc.) to recover marginal media. A number of old tape recovery projects have used this approach. For disk you have to go faster if you use an existing drive, but the numbers are perfectly manageable with modern hardware. If you use this technique, you do generate a whole lot more data than the formatted capacity of the drive; 10x to 100x or so. Throw in another order of magnitude if you step across the surface in small increments to avoid having to identify the track centerline in advance -- again, somewhat like the tape recovery machines that use a 36 track head to read 7 or 9 or 10 track tapes. Fred mentioned how life gets hard if you don't have a drive. I'm wondering how difficult it would be to build a useable "spin table", basically an accurate spindle that will accept the pack to be recovered and that will rotate at a modest speed, with a head positioner that can accurately position a read head along the surface. One head would suffice, RAMAC fashion. For slow rotation you'd want an MR head, and perhaps supplied air to float the head off the surface. Perhaps a scheme like this with slow rotation could allow for recovery much of the data on a platter that suffered a head crash, because you could spin it slowly enough that either the head doesn't touch the scratched areas, or touches it slowly enough that no further damage results. paul From ggs at shiresoft.com Sun Apr 17 15:35:00 2022 From: ggs at shiresoft.com (Guy Sotomayor) Date: Sun, 17 Apr 2022 13:35:00 -0700 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: I chose ESDI and SMD fundamentally because the interface is 100% digital (e.g. the data/clock separator is in the drive itself). So I don't need to do any oversampling. TTFN - Guy On 4/17/22 11:12, Paul Koning via cctalk wrote: > >> On Apr 17, 2022, at 1:28 PM, shadoooo via cctalk wrote: >> >> hello, >> there's much discussion about the right method to transfer data in and out. >> Of course there are several methods, the right one must be carefully chosen after some review of all the disk interfaces that must be supported. The idea of having a copy of the whole disk in RAM is OK, assuming that a maximum size of around 512MB is required, as the RAM is also needed for the OS, and for Zynq maximum is 1GB. > For reading a disk, an attractive approach is to do a high speed analog capture of the waveforms. That way you don't need a priori knowledge of the encoding, and it also allows you to use sophisticated algorithms (DSP, digital filtering, etc.) to recover marginal media. A number of old tape recovery projects have used this approach. For disk you have to go faster if you use an existing drive, but the numbers are perfectly manageable with modern hardware. > > If you use this technique, you do generate a whole lot more data than the formatted capacity of the drive; 10x to 100x or so. Throw in another order of magnitude if you step across the surface in small increments to avoid having to identify the track centerline in advance -- again, somewhat like the tape recovery machines that use a 36 track head to read 7 or 9 or 10 track tapes. > > Fred mentioned how life gets hard if you don't have a drive. I'm wondering how difficult it would be to build a useable "spin table", basically an accurate spindle that will accept the pack to be recovered and that will rotate at a modest speed, with a head positioner that can accurately position a read head along the surface. One head would suffice, RAMAC fashion. For slow rotation you'd want an MR head, and perhaps supplied air to float the head off the surface. Perhaps a scheme like this with slow rotation could allow for recovery much of the data on a platter that suffered a head crash, because you could spin it slowly enough that either the head doesn't touch the scratched areas, or touches it slowly enough that no further damage results. > > paul > > -- TTFN - Guy From ggs at shiresoft.com Sun Apr 17 15:32:18 2022 From: ggs at shiresoft.com (Guy Sotomayor) Date: Sun, 17 Apr 2022 13:32:18 -0700 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <567bd2b0-b1c0-00cd-e36f-2fda4a4fd2c7@shiresoft.com> I have proceeded as far as full block diagrams (still have to write all of the verilog) and basic SW architecture.? This is why I've had this discussion.? I've thought about this *a lot* and have gone through several iterations of what will or will not work given timing constraints. I have all of the components for putting a prototype together but I just haven't had the time yet to write the verilog, the Linux device driver and the "personality board".? That is, there is still a lot to do.? ;-) Some requirements that I've put on my design: * straight forward SW architecture * SW is *not* time critical (that is I didn't want SW in the critical path of keeping the data stream) * Must be able to emulate any SMD/ESDI drive * Must be able to match performance of the drive (or better) * Must be able to work with any controller (ESDI or SMD...depending upon interface) With those in mind, that's how I came up with my design. I found that the Zynq has sufficient Block RAM to contain a full cylinder of 512KB.? I'm keeping a full cylinder because that allows everything to be done in verilog except for seeks (see SW not being required to be in the critical path).? If I didn't do that, then SW would have to be involved in some aspects of head switch, etc and those can have tight (<< 100us) latencies and I just didn't want to try and get Linux to handle that.? Yes, I could use some form of RTOS (I'm actually in the middle of writing one...but that's still a ways away) but I don't see any that are really up to what I need/want to do for this project. BTW, I'm basing my initial implementation on the Zynq 7020 which has 1GB of DRAM.? However, I'm also planning on a "bigger/better" one based upon the Zynq Ultrascale+ which has 4GB of DRAM so that I can support multiple/larger drives. The amount required by Linux doesn't have to be large...I plan on having the KMD just allocate a really big buffer (e.g. sufficient for containing the entire drive image).? Linux will run happily in 128MB-256MB since there won't be any GUI.? It could be significantly less if I were to strip out everything that isn't needed by the kernel and only have a basic shell for booting/debug.? My plan is to have the emulated drive data and the configuration file on the SD card...so there's no real user interaction necessary (and Linux would not be on the SD card but on the embedded flash on the Zynq module). TTFN - Guy On 4/17/22 10:28, shadoooo via cctech wrote: > hello, > there's much discussion about the right? method to transfer data in and out. > Of course there are several methods, the right one must be carefully chosen after some review of all the disk interfaces that must be supported. The idea of having a copy of the whole disk in RAM is OK, assuming that a maximum size of around 512MB is required, as the RAM is also needed for the OS, and for Zynq maximum is 1GB. > About logic implementation, we know that the device must be able to work with one cylinder at a time. Given RAM bandwidth, this doesn't means that it must fit completely in blockram, also it can be produced at output while it is read, so delay time is really the time between first data request and actual read response. In between an elastic FIFO is required to adapt synchronous constant rate transfer of the disk to the burst transfer toward RAM. > > Guy, you mentioned about development of a similar interface. > So you already produced some working hardware? > > Andrea > -- TTFN - Guy From shadoooo at gmail.com Mon Apr 18 01:44:11 2022 From: shadoooo at gmail.com (shadoooo) Date: Mon, 18 Apr 2022 06:44:11 +0000 (UTC) Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <2fc22d4c-3ae8-40e4-bb39-2c9c65223d48@gmail.com> Hello Paul, using analog signal is not in my intentions, because usually you don't have access to analog signals on disk interface. For some media, e.g. floppy and MFM, you don't have a clock reference on the interface, so you need to detect magnetic pulses and then reconstruct data from timing. For more advanced media, e.g. SMD, data is transferred together with a clock on separate signal, so you need to sample only once for clock cycle. Building a mechanical tool like the one you describe would be very very difficult in my opinion. But I'm not a mechanical engineer. It would be far easier to modify a driver for a selected media, rebuilding the controller electronics for the purpose. Anyway it would be a tough work, useful only for a single media type. Andrea Apr 17, 2022 20:12:28 Paul Koning : > > >> On Apr 17, 2022, at 1:28 PM, shadoooo via cctalk wrote: >> >> hello, >> there's much discussion about the right? method to transfer data in and out. >> Of course there are several methods, the right one must be carefully chosen after some review of all the disk interfaces that must be supported. The idea of having a copy of the whole disk in RAM is OK, assuming that a maximum size of around 512MB is required, as the RAM is also needed for the OS, and for Zynq maximum is 1GB. > > For reading a disk, an attractive approach is to do a high speed analog capture of the waveforms.? That way you don't need a priori knowledge of the encoding, and it also allows you to use sophisticated algorithms (DSP, digital filtering, etc.) to recover marginal media.? A number of old tape recovery projects have used this approach.? For disk you have to go faster if you use an existing drive, but the numbers are perfectly manageable with modern hardware. > > If you use this technique, you do generate a whole lot more data than the formatted capacity of the drive; 10x to 100x or so.? Throw in another order of magnitude if you step across the surface in small increments to avoid having to identify the track centerline in advance -- again, somewhat like the tape recovery machines that use a 36 track head to read 7 or 9 or 10 track tapes. > > Fred mentioned how life gets hard if you don't have a drive.? I'm wondering how difficult it would be to build a useable "spin table", basically an accurate spindle that will accept the pack to be recovered and that will rotate at a modest speed, with a head positioner that can accurately position a read head along the surface.? One head would suffice, RAMAC fashion.? For slow rotation you'd want an MR head, and perhaps supplied air to float the head off the surface.? Perhaps a scheme like this with slow rotation could allow for recovery much of the data on a platter that suffered a head crash, because you could spin it slowly enough that either the head doesn't touch the scratched areas, or touches it slowly enough that no further damage results. > > ? paul From tom94022 at comcast.net Mon Apr 18 03:01:47 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Mon, 18 Apr 2022 01:01:47 -0700 Subject: idea for a universal disk interface In-Reply-To: <5beefb4c-2ce8-eb23-d331-85370cc41fc3@jetnet.ab.ca> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> <00a301d851c6$1ba56bf0$52f043d0$@comcast.net> <5beefb4c-2ce8-eb23-d331-85370cc41fc3@jetnet.ab.ca> Message-ID: <000d01d852fa$8e0985c0$aa1c9140$@comcast.net> -----Original Message----- From: ben [mailto:bfranchuk at jetnet.ab.ca] Sent: Saturday, April 16, 2022 1:39 PM To: cctalk at classiccmp.org Subject: Re: idea for a universal disk interface On 2022-04-16 1:13 p.m., Tom Gardner via cctalk wrote: > Tom > How do you handle the disk hardware timing, power up, seek and disk RPM?. Ben. -------- Those really shouldn't be any problem. RPM is data rate but unlike the disk drive the RPM and the data rate in an emulator are as precise as the crystal and hardware setting the data rate- no jitter, speed variation etc. Everything is on time The emulator would have to generate a synthetic Index signal (and sectors for hard sectored controllers) to keep the controller happy but that is just counting off a clock. Power up - most drives tell the controller when they are ready but some have a start/stop controls. Regardless, it is pretty easy for the emulator to respond to any commands and present appropriate status. It doesn't have to wait for a disk pack to spin up - as soon as it gets a start command it can present ready status. It would have to generate a home signal but all that means is the data pointer is pointing to the memory location of the first byte of the first track (Track 00 head 00) Seeks are near instantaneous - the controller issues the seek command and after a minimum delay the emulator presents ready status The only thing the emulator really has to worry about is too quick responses breaking the controller From bdweb at mindspring.com Mon Apr 18 11:59:34 2022 From: bdweb at mindspring.com (Bjoren Davis) Date: Mon, 18 Apr 2022 12:59:34 -0400 Subject: Replacement BOT/EOT markers for 1/2" tape Message-ID: Hello Retrofolks, I have a 1/2" 9-track magtape which is missing a BOT marker. Does anyone have a recommendation for a reflective tape to use to replace the BOT marker? I was looking at https://www.amazon.com/Metalized-Polyester-Adhesive-Multiple-Available/dp/B07TXN8TD8, but I have no idea if it's too stiff/thick/not sticky enough/etc. Thanks. --Bjoren From tom94022 at comcast.net Mon Apr 18 02:36:38 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Mon, 18 Apr 2022 00:36:38 -0700 Subject: idea for a universal disk interface In-Reply-To: <818a6f59-7087-59c1-1077-3d5cd5a2b8dc@shiresoft.com> References: <01a601d85092$da3ce1e0$8eb6a5a0$@comcast.net> <7063b5b9-ca21-96a5-95cb-c6a0ca82d6a3@shiresoft.com> <016f01d850fc$b6d76620$24863260$@comcast.net> <00b801d851d9$7b6417e0$722c47a0$@comcast.net> <818a6f59-7087-59c1-1077-3d5cd5a2b8dc@shiresoft.com> Message-ID: <000c01d852f7$0b0004e0$21000ea0$@comcast.net> Actually I am talking about emulating the bit stream, index to index - RLL encoded and containing gaps, marks, headers, data, CRC, ECC, etc. Exactly as the bit stream would come out of a theoretical disk drive, no bit shift, no write splices, no instantaneous speed variation, no long term speed variation. That means the controller will have a very easy time of it. My point is the ESDI/SME bit stream is 15 Mb/sec or lower and the others are lower still while any modern memory can transfer in the Gb/sec range so the track will arrive at the emulator hardware at much higher rate than the controller can absorb and since the track is coming from memory there is negligible latency. You seem to assume that the transfer out of the emulator can't start until the entire track is in the emulator - that's not what I am saying. To use your example, sure it takes 65us to transfer the entire track out of memory but it takes 16.67 msec to transfer it out of the emulator. I suggest transfer out of the emulator hardware can start with the first word into it. Tom -----Original Message----- From: Guy Sotomayor [mailto:ggs at shiresoft.com] Sent: Saturday, April 16, 2022 5:14 PM To: t.gardner at computer.org; cctech at classiccmp.org Subject: Re: idea for a universal disk interface I think the issue is that you're thinking of somehow emulating the formatted data. I'm working on just emulating the bit-stream as then it'll work with any controller and sector/track layout so I won't actually know what a sector really is (unless I do "hard sectoring" which some drives did support). At a 15Mhz clock rate, 30 bytes is 1.3333us. Not a lot of time. And frankly, that's defined by the controller and not the drive (though usually the drives specify some layout but that's only a recommendation). Dealing with drive speed variations doesn't solve anything because it's actually done via the drive itself (e.g. the drive provides the clock to the controller so any variation is already accounted for). The drive really cares about total bits (e.g. bits-per-inch) that the media supports. If we assume 32KB track at 500MB/s DMA transfer rate, that takes 65us. But as I've said, the spec says that the time between a head select and read is 15us or so, you can see that you can't just transfer a track and still meet the minimum timings. I will agree that you can probably take longer but I'm trying to have a design that can meet all of the minimum timings so I can emulate any drive/controller combination with at least the same performance as a real drive (and in many cases I can provide *much* higher performance). By keeping a full cylinder in the FPGA Block RAM I can keep the head select time < 1us (it's basically just selecting the high order address bits going to the block RAM). By keeping the entire disk image in DRAM, I can emulate any drive (that fits in the DRAM) with identical (or faster) performance. If I wanted to do something simpler (not much though) I could have a smaller DRAM (but since the Zynq modules I'm using have 1GB or 4GB of DRAM there isn't much motivation) but then any seek would be limited by access to the backing store. Also remember, in the worst case you have to write the previous track out if it was written to so that will slow things down as well. With the full image maintained in DRAM, any writes can be performed in a lazy manner in the background so that won't impact the performance of the emulated drive. TTFN - Guy On 4/16/22 14:32, Tom Gardner wrote: > -----Original Message----- > From: Guy Sotomayor [mailto:ggs at shiresoft.com] > Sent: Friday, April 15, 2022 3:25 PM > To: t.gardner at computer.org; cctech at classiccmp.org > Subject: Re: idea for a universal disk interface > > I'm looking at what the spec says. ;-) The read command delay from the head set command is 15us (so I was wrong) but still not a lot of time (that is after a head set, a read command must be at least 15us later). > > > > ----- > And after the read command is given there is a gap, usually all zeros, at the end of which is a sync byte which is then followed by the first good data (or header) byte. In SMD the gaps can be 20 or 30 bytes long so there is quite a bit of time until good data. > > Tom > > -- TTFN - Guy From cclist at sydex.com Mon Apr 18 12:28:31 2022 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 18 Apr 2022 10:28:31 -0700 Subject: Replacement BOT/EOT markers for 1/2" tape In-Reply-To: References: Message-ID: <530d090f-05c3-bc67-2b4a-ffb0365cce07@sydex.com> On 4/18/22 09:59, Bjoren Davis via cctalk wrote: > Hello Retrofolks, > > I have a 1/2" 9-track magtape which is missing a BOT marker. > > Does anyone have a recommendation for a reflective tape to use to > replace the BOT marker? > > I was looking at > https://www.amazon.com/Metalized-Polyester-Adhesive-Multiple-Available/dp/B07TXN8TD8, > but I have no idea if it's too stiff/thick/not sticky enough/etc. I still have my card of IBM foil strips, but sensing foil for 1/4" audio tape should also work fine. For example: https://www.ebay.com/itm/202810140272?hash=item2f386d2670:g:y4UAAOSw8fdduA74 Many (but not all) audio sensing tapes are reflective; some are conductive-only. TME claims theirs is reflective. --Chuck From shadoooo at gmail.com Mon Apr 18 12:26:08 2022 From: shadoooo at gmail.com (shadoooo) Date: Mon, 18 Apr 2022 17:26:08 +0000 (UTC) Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <7c3003ec-a0c4-4b96-a81f-f9ef580d79af@gmail.com> Guy, I agree on keeping Linux out of the loop, to allow fast access on head location, selection. However, I'm not convinced on the fact that a whole cylinder must be on blockram to achieve this. Given that ram access is fast (on Zynq with PL working at 200MHz and HP port at 64bits I'm running at around 1200MB/s peak), logic can jump across the whole disk without the software intervention, it's just a matter of being able to calculate conversion from CHS to address and read with sufficient buffer. Probably using Xilinx IP cores could be a severe limit, as these are really full of bugs and inefficient implementations... but are free, so you can't argue. On software side, given that you can go also slow, there's no need for very complex driver development, just an user level UIO driver could make do. About language, I know very well VHDL, and it's a little bit at higher level than Verilog, so development with implementation parameters is maybe a little easier. About interfaces which doesn't have separated clock recovery: these need a sort of oversampling, but you don't need to store every sample, just the ones with state change. Leveraging on IOSERDES you can work at a multiple of internal clock. Please keep in consideration that the idea is to develop a single device that can work both as drive and as interface, so implementation should be reversible. Probably this is not very difficult to obtain, as fast data paths for read and write are already in opposite directions. Andrea > I have proceeded as far as full block diagrams (still have to write all > of the verilog) and basic SW architecture.? This is why I've had this > discussion.? I've thought about this *a lot* and have gone through > several iterations of what will or will not work given timing constraints. > > I have all of the components for putting a prototype together but I just > haven't had the time yet to write the verilog, the Linux device driver > and the "personality board".? That is, there is still a lot to do.? ;-) > > Some requirements that I've put on my design: > > ? * straight forward SW architecture > ? * SW is *not* time critical (that is I didn't want SW in the critical > ??? path of keeping the data stream) > ? * Must be able to emulate any SMD/ESDI drive > ? * Must be able to match performance of the drive (or better) > ? * Must be able to work with any controller (ESDI or SMD...depending > ??? upon interface) > > With those in mind, that's how I came up with my design. > > I found that the Zynq has sufficient Block RAM to contain a full > cylinder of 512KB.? I'm keeping a full cylinder because that allows > everything to be done in verilog except for seeks (see SW not being > required to be in the critical path).? If I didn't do that, then SW > would have to be involved in some aspects of head switch, etc and those > can have tight (<< 100us) latencies and I just didn't want to try and > get Linux to handle that.? Yes, I could use some form of RTOS (I'm > actually in the middle of writing one...but that's still a ways away) > but I don't see any that are really up to what I need/want to do for > this project. > > BTW, I'm basing my initial implementation on the Zynq 7020 which has 1GB > of DRAM.? However, I'm also planning on a "bigger/better" one based upon > the Zynq Ultrascale+ which has 4GB of DRAM so that I can support > multiple/larger drives. > > The amount required by Linux doesn't have to be large...I plan on having > the KMD just allocate a really big buffer (e.g. sufficient for > containing the entire drive image).? Linux will run happily in > 128MB-256MB since there won't be any GUI.? It could be significantly > less if I were to strip out everything that isn't needed by the kernel > and only have a basic shell for booting/debug.? My plan is to have the > emulated drive data and the configuration file on the SD card...so > there's no real user interaction necessary (and Linux would not be on > the SD card but on the embedded flash on the Zynq module). > > > I chose ESDI and SMD fundamentally because the interface is 100% digital > (e.g. the data/clock separator is in the drive itself). So I don't need > to do any oversampling. From billdegnan at gmail.com Mon Apr 18 14:03:22 2022 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 18 Apr 2022 15:03:22 -0400 Subject: IMSAI SIO2 cable part number Message-ID: Hi all... What is the cable partnumber for the IMSAI SIO2? I need to order a set of cables. I thought in all of my boxes and boxes of cables I might have one...but nope. Here is a picture: https://deramp.com/downloads/mfe_archive/010-S100%20Computers%20and%20Boards/00-Imsai/10-Imsai%20S100%20Boards/Imsai%20SIO-2%20dual%20serial%20IO/SIO%20with%20cables.JPG Thanks in advance. BIll From elson at pico-systems.com Mon Apr 18 17:46:00 2022 From: elson at pico-systems.com (Jon Elson) Date: Mon, 18 Apr 2022 17:46:00 -0500 Subject: Replacement BOT/EOT markers for 1/2" tape In-Reply-To: References: Message-ID: <6b398854-6e7c-fb3e-78db-9af28b3c5add@pico-systems.com> On 4/18/22 11:59, Bjoren Davis via cctalk wrote: > Hello Retrofolks, > > I have a 1/2" 9-track magtape which is missing a BOT marker. > > Does anyone have a recommendation for a reflective tape to > use to replace the BOT marker? > > I was looking at > https://www.amazon.com/Metalized-Polyester-Adhesive-Multiple-Available/dp/B07TXN8TD8, > but I have no idea if it's too stiff/thick/not sticky > enough/etc. I have some of this material on a roll.? It is "Scotch" brand 650 sensing markers "for magnetic computer tape used on digital transports".? I could send you some if you are in the US. Jon From elson at pico-systems.com Mon Apr 18 17:48:41 2022 From: elson at pico-systems.com (Jon Elson) Date: Mon, 18 Apr 2022 17:48:41 -0500 Subject: IMSAI SIO2 cable part number In-Reply-To: References: Message-ID: <2f6f91a7-ecf4-c58e-a7ef-5691717ef1c2@pico-systems.com> On 4/18/22 14:03, Bill Degnan via cctalk wrote: > Hi all... > What is the cable partnumber for the IMSAI SIO2? I need to order a > set of cables. I thought in all of my boxes and boxes of cables I > might have one...but nope. > > Here is a picture: > > https://deramp.com/downloads/mfe_archive/010-S100%20Computers%20and%20Boards/00-Imsai/10-Imsai%20S100%20Boards/Imsai%20SIO-2%20dual%20serial%20IO/SIO%20with%20cables.JPG > You can buy the DB-25 IDC connectors, and most likely you can buy the card edge connectors, too. Jon From bitwiz at 12bitsbest.com Mon Apr 18 18:04:35 2022 From: bitwiz at 12bitsbest.com (Mike Katz) Date: Mon, 18 Apr 2022 18:04:35 -0500 Subject: IMSAI SIO2 cable part number In-Reply-To: <2f6f91a7-ecf4-c58e-a7ef-5691717ef1c2@pico-systems.com> References: <2f6f91a7-ecf4-c58e-a7ef-5691717ef1c2@pico-systems.com> Message-ID: Standard 100mil (.1 inch center) edge connectors are still very common and available from most electronic parts distributors. For example: https://www.mouser.com/c/connectors/card-edge-connectors/ On 4/18/2022 5:48 PM, Jon Elson via cctalk wrote: > On 4/18/22 14:03, Bill Degnan via cctalk wrote: >> Hi all... >> What is the cable partnumber for the IMSAI SIO2?? I need to order a >> set of cables.?? I thought in all of my boxes and boxes of cables I >> might have one...but nope. >> >> Here is a picture: >> >> https://deramp.com/downloads/mfe_archive/010-S100%20Computers%20and%20Boards/00-Imsai/10-Imsai%20S100%20Boards/Imsai%20SIO-2%20dual%20serial%20IO/SIO%20with%20cables.JPG >> >> > You can buy the DB-25 IDC connectors, and most likely you can buy the > card edge connectors, too. > > Jon > From cz at alembic.crystel.com Mon Apr 18 19:49:34 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Mon, 18 Apr 2022 20:49:34 -0400 Subject: Felt pads for RX50 Message-ID: Anyone know of a source for the felt pads that go on the non-head side of an RX50? Missing at least one here. C From dj.taylor4 at comcast.net Mon Apr 18 17:09:40 2022 From: dj.taylor4 at comcast.net (Douglas Taylor) Date: Mon, 18 Apr 2022 18:09:40 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: Because of this I'm holding on to my DEC Qbus ESDI controllers!!!? You never know.... Doug On 4/17/2022 4:35 PM, Guy Sotomayor via cctech wrote: > I chose ESDI and SMD fundamentally because the interface is 100% > digital (e.g. the data/clock separator is in the drive itself). So I > don't need to do any oversampling. > > TTFN - Guy > > On 4/17/22 11:12, Paul Koning via cctalk wrote: >> >>> On Apr 17, 2022, at 1:28 PM, shadoooo via cctalk >>> wrote: >>> >>> hello, >>> there's much discussion about the right? method to transfer data in >>> and out. >>> Of course there are several methods, the right one must be carefully >>> chosen after some review of all the disk interfaces that must be >>> supported. The idea of having a copy of the whole disk in RAM is OK, >>> assuming that a maximum size of around 512MB is required, as the RAM >>> is also needed for the OS, and for Zynq maximum is 1GB. >> For reading a disk, an attractive approach is to do a high speed >> analog capture of the waveforms.? That way you don't need a priori >> knowledge of the encoding, and it also allows you to use >> sophisticated algorithms (DSP, digital filtering, etc.) to recover >> marginal media.? A number of old tape recovery projects have used >> this approach.? For disk you have to go faster if you use an existing >> drive, but the numbers are perfectly manageable with modern hardware. >> >> If you use this technique, you do generate a whole lot more data than >> the formatted capacity of the drive; 10x to 100x or so. Throw in >> another order of magnitude if you step across the surface in small >> increments to avoid having to identify the track centerline in >> advance -- again, somewhat like the tape recovery machines that use a >> 36 track head to read 7 or 9 or 10 track tapes. >> >> Fred mentioned how life gets hard if you don't have a drive. I'm >> wondering how difficult it would be to build a useable "spin table", >> basically an accurate spindle that will accept the pack to be >> recovered and that will rotate at a modest speed, with a head >> positioner that can accurately position a read head along the >> surface.? One head would suffice, RAMAC fashion.? For slow rotation >> you'd want an MR head, and perhaps supplied air to float the head off >> the surface.? Perhaps a scheme like this with slow rotation could >> allow for recovery much of the data on a platter that suffered a head >> crash, because you could spin it slowly enough that either the head >> doesn't touch the scratched areas, or touches it slowly enough that >> no further damage results. >> >> ????paul >> >> From bitwiz at 12bitsbest.com Mon Apr 18 17:44:12 2022 From: bitwiz at 12bitsbest.com (Mike Katz) Date: Mon, 18 Apr 2022 17:44:12 -0500 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: Which is more generic. ESDI, SMD or SCSI. In my opinion, SCSI is as close are you are going to get to a universal interface. As for reading raw data from a drive.? The newer the drive, the higher the bit density and lower the strength of the magnetic fields and hence the lower the flying height.? You have to deal with linear (or horizontal) recording, perpendicular recording, Heat assisted magnetic recording, microwave assisted magnetic recording.? The latest technologies are approaching 1TB (yes that's TB) per square inch. If you spin the platters too slowly you will not be able to distinguish individual magnetic fluctuations from noise.? What do you propose as your maximum data density (in BPI) and what is the minimum speed you will need to accurately decode it. Also once you get into newer drives the sectoring information may be stored in EEPROM or ROM and not on the disk at all, that would make decoding the data even more complicated as you don't know where a given sector starts. In addition to handling any number of encoding techniques (FM, MFM, GCR, RLL, MAMR, HAMR, PMR, etc.) news drives also do bad sector mapping so you would need to be able to handle that as well. Some kind of programmable data separator (possibly and external DSP) might be able to handle the high aerial densities. The GreaseWeazle does this for floppies.? That architecture might be a good starting point to ramp up for hard drives. Well, that's my 2 cents. On 4/18/2022 5:09 PM, Douglas Taylor via cctech wrote: > Because of this I'm holding on to my DEC Qbus ESDI controllers!!!? You > never know.... > Doug > > On 4/17/2022 4:35 PM, Guy Sotomayor via cctech wrote: >> I chose ESDI and SMD fundamentally because the interface is 100% >> digital (e.g. the data/clock separator is in the drive itself). So I >> don't need to do any oversampling. >> >> TTFN - Guy >> >> On 4/17/22 11:12, Paul Koning via cctalk wrote: >>> >>>> On Apr 17, 2022, at 1:28 PM, shadoooo via cctalk >>>> wrote: >>>> >>>> hello, >>>> there's much discussion about the right? method to transfer data in >>>> and out. >>>> Of course there are several methods, the right one must be >>>> carefully chosen after some review of all the disk interfaces that >>>> must be supported. The idea of having a copy of the whole disk in >>>> RAM is OK, assuming that a maximum size of around 512MB is >>>> required, as the RAM is also needed for the OS, and for Zynq >>>> maximum is 1GB. >>> For reading a disk, an attractive approach is to do a high speed >>> analog capture of the waveforms.? That way you don't need a priori >>> knowledge of the encoding, and it also allows you to use >>> sophisticated algorithms (DSP, digital filtering, etc.) to recover >>> marginal media.? A number of old tape recovery projects have used >>> this approach.? For disk you have to go faster if you use an >>> existing drive, but the numbers are perfectly manageable with modern >>> hardware. >>> >>> If you use this technique, you do generate a whole lot more data >>> than the formatted capacity of the drive; 10x to 100x or so. Throw >>> in another order of magnitude if you step across the surface in >>> small increments to avoid having to identify the track centerline in >>> advance -- again, somewhat like the tape recovery machines that use >>> a 36 track head to read 7 or 9 or 10 track tapes. >>> >>> Fred mentioned how life gets hard if you don't have a drive. I'm >>> wondering how difficult it would be to build a useable "spin table", >>> basically an accurate spindle that will accept the pack to be >>> recovered and that will rotate at a modest speed, with a head >>> positioner that can accurately position a read head along the >>> surface.? One head would suffice, RAMAC fashion.? For slow rotation >>> you'd want an MR head, and perhaps supplied air to float the head >>> off the surface.? Perhaps a scheme like this with slow rotation >>> could allow for recovery much of the data on a platter that suffered >>> a head crash, because you could spin it slowly enough that either >>> the head doesn't touch the scratched areas, or touches it slowly >>> enough that no further damage results. >>> >>> ????paul >>> >>> > From lists at glitchwrks.com Mon Apr 18 18:43:21 2022 From: lists at glitchwrks.com (Jonathan Chapman) Date: Mon, 18 Apr 2022 23:43:21 +0000 Subject: IMSAI SIO2 cable part number In-Reply-To: References: Message-ID: Bill, Let me know right quick if you'll be at VCF East and I'll make you a pair, I have both kinds of IDC ends. I'm heading out first thing tomorrow morning though as I have work in the northeast before VCF East. Thanks, Jonathan ------- Original Message ------- On Monday, April 18th, 2022 at 15:03, Bill Degnan via cctech wrote: > > > Hi all... > What is the cable partnumber for the IMSAI SIO2? I need to order a > set of cables. I thought in all of my boxes and boxes of cables I > might have one...but nope. > > Here is a picture: > > https://deramp.com/downloads/mfe_archive/010-S100 Computers and Boards/00-Imsai/10-Imsai S100 Boards/Imsai SIO-2 dual serial IO/SIO with cables.JPG > > Thanks in advance. > > BIll From cz at alembic.crystel.com Mon Apr 18 20:12:20 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Mon, 18 Apr 2022 21:12:20 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <21244280-7cd4-bec1-7144-439a4d5d0fdd@alembic.crystel.com> Interesting, what kind of ESDI controllers do you have? They got advanced features like cache, ordered seeks, and burst mode/block mode DMA? C On 4/18/2022 6:09 PM, Douglas Taylor via cctech wrote: > Because of this I'm holding on to my DEC Qbus ESDI controllers!!!? You > never know.... > Doug > > On 4/17/2022 4:35 PM, Guy Sotomayor via cctech wrote: >> I chose ESDI and SMD fundamentally because the interface is 100% >> digital (e.g. the data/clock separator is in the drive itself). So I >> don't need to do any oversampling. >> >> TTFN - Guy >> >> On 4/17/22 11:12, Paul Koning via cctalk wrote: >>> >>>> On Apr 17, 2022, at 1:28 PM, shadoooo via cctalk >>>> wrote: >>>> >>>> hello, >>>> there's much discussion about the right? method to transfer data in >>>> and out. >>>> Of course there are several methods, the right one must be carefully >>>> chosen after some review of all the disk interfaces that must be >>>> supported. The idea of having a copy of the whole disk in RAM is OK, >>>> assuming that a maximum size of around 512MB is required, as the RAM >>>> is also needed for the OS, and for Zynq maximum is 1GB. >>> For reading a disk, an attractive approach is to do a high speed >>> analog capture of the waveforms.? That way you don't need a priori >>> knowledge of the encoding, and it also allows you to use >>> sophisticated algorithms (DSP, digital filtering, etc.) to recover >>> marginal media.? A number of old tape recovery projects have used >>> this approach.? For disk you have to go faster if you use an existing >>> drive, but the numbers are perfectly manageable with modern hardware. >>> >>> If you use this technique, you do generate a whole lot more data than >>> the formatted capacity of the drive; 10x to 100x or so. Throw in >>> another order of magnitude if you step across the surface in small >>> increments to avoid having to identify the track centerline in >>> advance -- again, somewhat like the tape recovery machines that use a >>> 36 track head to read 7 or 9 or 10 track tapes. >>> >>> Fred mentioned how life gets hard if you don't have a drive. I'm >>> wondering how difficult it would be to build a useable "spin table", >>> basically an accurate spindle that will accept the pack to be >>> recovered and that will rotate at a modest speed, with a head >>> positioner that can accurately position a read head along the >>> surface.? One head would suffice, RAMAC fashion.? For slow rotation >>> you'd want an MR head, and perhaps supplied air to float the head off >>> the surface.? Perhaps a scheme like this with slow rotation could >>> allow for recovery much of the data on a platter that suffered a head >>> crash, because you could spin it slowly enough that either the head >>> doesn't touch the scratched areas, or touches it slowly enough that >>> no further damage results. >>> >>> ????paul >>> >>> > From rice43 at btinternet.com Tue Apr 19 04:28:44 2022 From: rice43 at btinternet.com (Joshua Rice) Date: Tue, 19 Apr 2022 10:28:44 +0100 (BST) Subject: Felt pads for RX50 In-Reply-To: References: Message-ID: <302b40e5.1b57.18041271f66.Webtop.84@btinternet.com> Never had to replace them, but from what i remember, from cleaning out an RX50 last year... they're thinner than cassette tape felt pads. I imagine sticky back craft felt would be an adequate replacement. Cutting it/stamping it out might be the tricky part. https://www.bakerross.co.uk/self-adhesive-felt-sheets-classpack - Craft felt https://www.amazon.co.uk/Cutters-Stainless-Indentation-Ceramics-Dotting/dp/B07VDNY82V/ref=asc_df_B07VDNY82V/ - Clay cutters, might work, might not. Might be better off with a stanley knife and some steady hands I'm really only hypothesising here... But if i was in your shoes, that's what i'd try. Cheers, Josh Rice ------ Original Message ------ From: "Chris Zach via cctech" To: "CCTalk mailing list" Sent: Tuesday, 19 Apr, 2022 At 01:49 Subject: Felt pads for RX50 Anyone know of a source for the felt pads that go on the non-head side of an RX50? Missing at least one here. C From couryhouse at aol.com Tue Apr 19 01:14:40 2022 From: couryhouse at aol.com (ED SHARPE) Date: Tue, 19 Apr 2022 06:14:40 +0000 (UTC) Subject: IMSAI SIO2 cable part number In-Reply-To: References: Message-ID: <1938130757.625471.1650348880807@mail.yahoo.com> probably others? out? there? ?that? can use? some of these cables? too... sad? but? true? I? wish? I had? ?bought up all the loose IMSAI? parts? Micro-age redistribution? had? way back? then in? the? early 1980s? ? they had? parts? and pieces? of leftovers and? half disassembled? IMSAI atuff stuff their techs? screwed up!?Ed#??In a message dated 4/18/2022 10:45:44 PM US Mountain Standard Time, cctech at classiccmp.org writes:? Bill,?Let me know right quick if you'll be at VCF East and I'll make you a pair, I have both kinds of IDC ends. I'm heading out first thing tomorrow morning though as I have work in the northeast before VCF East.?Thanks,Jonathan????------- Original Message -------On Monday, April 18th, 2022 at 15:03, Bill Degnan via cctech wrote:??>>> Hi all...> What is the cable partnumber for the IMSAI SIO2? I need to order a> set of cables. I thought in all of my boxes and boxes of cables I> might have one...but nope.>> Here is a picture:>> https://deramp.com/downloads/mfe_archive/010-S100 Computers and Boards/00-Imsai/10-Imsai S100 Boards/Imsai SIO-2 dual serial IO/SIO with cables.JPG>> Thanks in advance.>> BIll From phb.hfx at gmail.com Tue Apr 19 06:35:12 2022 From: phb.hfx at gmail.com (Paul Berger) Date: Tue, 19 Apr 2022 08:35:12 -0300 Subject: Felt pads for RX50 In-Reply-To: References: Message-ID: <30b913e7-e98b-6c95-ac43-a08d1fe69ca0@gmail.com> On 2022-04-18 21:49, Chris Zach via cctalk wrote: > Anyone know of a source for the felt pads that go on the non-head side > of an RX50? Missing at least one here. > > C I successfully made replacements from self-adhesive felt punched out using a leather punch like you would use to punch holes in a belt. Paul. From paulkoning at comcast.net Tue Apr 19 07:29:47 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 19 Apr 2022 08:29:47 -0400 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: > On Apr 18, 2022, at 6:44 PM, Mike Katz via cctalk wrote: > > Which is more generic. > > ESDI, SMD or SCSI. > > In my opinion, SCSI is as close are you are going to get to a universal interface. > > As for reading raw data from a drive. The newer the drive, the higher the bit density and lower the strength of the magnetic fields and hence the lower the flying height. You have to deal with linear (or horizontal) recording, perpendicular recording, Heat assisted magnetic recording, microwave assisted magnetic recording. The latest technologies are approaching 1TB (yes that's TB) per square inch. > > If you spin the platters too slowly you will not be able to distinguish individual magnetic fluctuations from noise. What do you propose as your maximum data density (in BPI) and what is the minimum speed you will need to accurately decode it. I know about some of the modern drive magic, but I wasn't talking about those at all. My comments about recovering raw signals from disk surfaces is for much earlier disks, especially removable packs. In more recent disks you always have the drive if you have the disk since they are the same thing. (I'm ignoring "data recovery" services here that deal with mechanically failed drives; that's a specialized business and as you said it's increasingly difficult with modern drives.) If you consider 1960s through 1980s you're likely to run into disk packs for which the drives may be hard to find. The mechanical tolerances of those devices require care but are not crazy difficult, as my RC11/RS64 example last week was meant to illustrate. The bit densities are not all that high, nor the track densities. Consider for example that the track positions on a 1311 drive are set by mechanical detents, and are low enough that no servo system is used at all. My mechanical skills and tools are perhaps a bit better than some of the readers here, undoubtedly worse than others. I could sketch a "spin table" that could handle, say, an RK05 pack. Without a milling machine I can't build it, but that could be fixed, and I could refine my skills to make it work. Do I plan to? No, but if an interesting enough pack showed up I could imagine doing it. The RA60 pack I have would be a bit more of a stretch -- more platters and higher densities, not to mention lack of documentation -- but it's still on the edge of possibilities. So I think there are two different possible projects here. One involves a generic controller/emulator for common disk to controller interfaces, like ESDI or SMD. (Or SCSI but those are off the shelf items, right?) I'd imagine there would be plenty of takers for that, just as there are for the MFM and floppy emulators. The other, more difficult and less needed, is the pack reader that I was discussing. There is a little overlap between the two but not much. paul From ibmsystem3 at hccnet.nl Tue Apr 19 09:15:47 2022 From: ibmsystem3 at hccnet.nl (IBM System/3) Date: Tue, 19 Apr 2022 16:15:47 +0200 Subject: Looking for Dennis Charles Komisky Message-ID: <5fa4bb43-1e62-2659-2317-35e3a607b1a8@hccnet.nl> Hi , I am trying to contact Dennis Charles Komisky. Cen anyone help me with his email address ? Thanks ! Henk From bitwiz at 12bitsbest.com Tue Apr 19 10:12:14 2022 From: bitwiz at 12bitsbest.com (Mike Katz) Date: Tue, 19 Apr 2022 10:12:14 -0500 Subject: Oracle Releases Solaris 11.4 "CBE" Free For Open-Source Developers / Non-Production Use In-Reply-To: <70215770-B6F1-41B8-A978-FAB74D0C4546@trick-1.net> References: <70215770-B6F1-41B8-A978-FAB74D0C4546@trick-1.net> Message-ID: I don't know if this has been posted already or not so I thought I would show it here. https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Solaris-11.4-CBE From cz at alembic.crystel.com Tue Apr 19 10:18:07 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 19 Apr 2022 11:18:07 -0400 Subject: Oracle Releases Solaris 11.4 "CBE" Free For Open-Source Developers / Non-Production Use In-Reply-To: References: <70215770-B6F1-41B8-A978-FAB74D0C4546@trick-1.net> Message-ID: <397bf1bc-a31a-892f-4fd1-1831076bccdd@alembic.crystel.com> Wonder if there is a SPARC build. Guess it's too much to ask if it will run on my Sun 386i's.... C On 4/19/2022 11:12 AM, Mike Katz via cctalk wrote: > I don't know if this has been posted already or not so I thought I would > show it here. > > https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Solaris-11.4-CBE > > From ggs at shiresoft.com Tue Apr 19 10:52:22 2022 From: ggs at shiresoft.com (Guy Sotomayor) Date: Tue, 19 Apr 2022 08:52:22 -0700 Subject: idea for a universal disk interface In-Reply-To: <7c3003ec-a0c4-4b96-a81f-f9ef580d79af@gmail.com> References: <7c3003ec-a0c4-4b96-a81f-f9ef580d79af@gmail.com> Message-ID: <3932a7f3-1f66-f818-509c-ecf923c57730@shiresoft.com> The problem is that you don't get the cylinder and head information in the same command (they are 2 different commands). So when you're doing a seek, you don't know which track(s) to prioritize.? That is why during a seek command I will transfer the entire cylinder so when the head command arrives, it can be handled quickly.? That's the only way I could think of to ensure maximum compatibility with the controllers (e.g. I can provide identical timings to an actual drive...you never really know what assumptions a particular controller might have). TTFN - Guy On 4/18/22 10:26, shadoooo via cctalk wrote: > Guy, > I agree on keeping Linux out of the loop, to allow fast access on head location, selection. > However, I'm not convinced on the fact that a whole cylinder must be on blockram to achieve this. Given that ram access is fast (on Zynq with PL working at 200MHz and HP port at 64bits I'm running at around 1200MB/s peak), logic can jump across the whole disk without the software intervention, it's just a matter of being able to calculate conversion from CHS to address and read with sufficient buffer. > Probably using Xilinx IP cores could be a severe limit, as these are really full of bugs and inefficient implementations... but are free, so you can't argue. > > On software side, given that you can go also slow, there's no need for very complex driver development, just an user level UIO driver could make do. > About language, I know very well VHDL, and it's a little bit at higher level than Verilog, so development with implementation parameters is maybe a little easier. > > About interfaces which doesn't have separated clock recovery: these need a sort of oversampling, but you don't need to store every sample, just the ones with state change. Leveraging on IOSERDES you can work at a multiple of internal clock. > > Please keep in consideration that the idea is to develop a single device that can work both as drive and as interface, so implementation should be reversible. > Probably this is not very difficult to obtain, as fast data paths for read and write are already in opposite directions. > > Andrea > >> I have proceeded as far as full block diagrams (still have to write all >> of the verilog) and basic SW architecture.? This is why I've had this >> discussion.? I've thought about this *a lot* and have gone through >> several iterations of what will or will not work given timing constraints. >> >> I have all of the components for putting a prototype together but I just >> haven't had the time yet to write the verilog, the Linux device driver >> and the "personality board".? That is, there is still a lot to do.? ;-) >> >> Some requirements that I've put on my design: >> >> ? * straight forward SW architecture >> ? * SW is *not* time critical (that is I didn't want SW in the critical >> ??? path of keeping the data stream) >> ? * Must be able to emulate any SMD/ESDI drive >> ? * Must be able to match performance of the drive (or better) >> ? * Must be able to work with any controller (ESDI or SMD...depending >> ??? upon interface) >> >> With those in mind, that's how I came up with my design. >> >> I found that the Zynq has sufficient Block RAM to contain a full >> cylinder of 512KB.? I'm keeping a full cylinder because that allows >> everything to be done in verilog except for seeks (see SW not being >> required to be in the critical path).? If I didn't do that, then SW >> would have to be involved in some aspects of head switch, etc and those >> can have tight (<< 100us) latencies and I just didn't want to try and >> get Linux to handle that.? Yes, I could use some form of RTOS (I'm >> actually in the middle of writing one...but that's still a ways away) >> but I don't see any that are really up to what I need/want to do for >> this project. >> >> BTW, I'm basing my initial implementation on the Zynq 7020 which has 1GB >> of DRAM.? However, I'm also planning on a "bigger/better" one based upon >> the Zynq Ultrascale+ which has 4GB of DRAM so that I can support >> multiple/larger drives. >> >> The amount required by Linux doesn't have to be large...I plan on having >> the KMD just allocate a really big buffer (e.g. sufficient for >> containing the entire drive image).? Linux will run happily in >> 128MB-256MB since there won't be any GUI.? It could be significantly >> less if I were to strip out everything that isn't needed by the kernel >> and only have a basic shell for booting/debug.? My plan is to have the >> emulated drive data and the configuration file on the SD card...so >> there's no real user interaction necessary (and Linux would not be on >> the SD card but on the embedded flash on the Zynq module). >> >> >> I chose ESDI and SMD fundamentally because the interface is 100% digital >> (e.g. the data/clock separator is in the drive itself). So I don't need >> to do any oversampling. -- TTFN - Guy From dj.taylor4 at comcast.net Tue Apr 19 10:56:36 2022 From: dj.taylor4 at comcast.net (Douglas Taylor) Date: Tue, 19 Apr 2022 11:56:36 -0400 Subject: idea for a universal disk interface In-Reply-To: <21244280-7cd4-bec1-7144-439a4d5d0fdd@alembic.crystel.com> References: <21244280-7cd4-bec1-7144-439a4d5d0fdd@alembic.crystel.com> Message-ID: <7e76f41e-622f-2c3c-649b-e985af2e64d6@comcast.net> Once upon a time I used an Emulex QD21, but I sold it because the actual ESDI disks I had were a pain in the butt.? Always crashing. I still have a Webster (quad board) SRQD something. I think I had a Dilog board also.? It's been a while, probably 20 years. Doug On 4/18/2022 9:12 PM, Chris Zach via cctech wrote: > Interesting, what kind of ESDI controllers do you have? They got > advanced features like cache, ordered seeks, and burst mode/block mode > DMA? > > C > > > On 4/18/2022 6:09 PM, Douglas Taylor via cctech wrote: >> Because of this I'm holding on to my DEC Qbus ESDI controllers!!!? >> You never know.... >> Doug >> >> On 4/17/2022 4:35 PM, Guy Sotomayor via cctech wrote: >>> I chose ESDI and SMD fundamentally because the interface is 100% >>> digital (e.g. the data/clock separator is in the drive itself). So I >>> don't need to do any oversampling. >>> >>> TTFN - Guy >>> >>> On 4/17/22 11:12, Paul Koning via cctalk wrote: >>>> >>>>> On Apr 17, 2022, at 1:28 PM, shadoooo via cctalk >>>>> wrote: >>>>> >>>>> hello, >>>>> there's much discussion about the right? method to transfer data >>>>> in and out. >>>>> Of course there are several methods, the right one must be >>>>> carefully chosen after some review of all the disk interfaces that >>>>> must be supported. The idea of having a copy of the whole disk in >>>>> RAM is OK, assuming that a maximum size of around 512MB is >>>>> required, as the RAM is also needed for the OS, and for Zynq >>>>> maximum is 1GB. >>>> For reading a disk, an attractive approach is to do a high speed >>>> analog capture of the waveforms.? That way you don't need a priori >>>> knowledge of the encoding, and it also allows you to use >>>> sophisticated algorithms (DSP, digital filtering, etc.) to recover >>>> marginal media.? A number of old tape recovery projects have used >>>> this approach.? For disk you have to go faster if you use an >>>> existing drive, but the numbers are perfectly manageable with >>>> modern hardware. >>>> >>>> If you use this technique, you do generate a whole lot more data >>>> than the formatted capacity of the drive; 10x to 100x or so. Throw >>>> in another order of magnitude if you step across the surface in >>>> small increments to avoid having to identify the track centerline >>>> in advance -- again, somewhat like the tape recovery machines that >>>> use a 36 track head to read 7 or 9 or 10 track tapes. >>>> >>>> Fred mentioned how life gets hard if you don't have a drive. I'm >>>> wondering how difficult it would be to build a useable "spin >>>> table", basically an accurate spindle that will accept the pack to >>>> be recovered and that will rotate at a modest speed, with a head >>>> positioner that can accurately position a read head along the >>>> surface.? One head would suffice, RAMAC fashion.? For slow rotation >>>> you'd want an MR head, and perhaps supplied air to float the head >>>> off the surface. Perhaps a scheme like this with slow rotation >>>> could allow for recovery much of the data on a platter that >>>> suffered a head crash, because you could spin it slowly enough that >>>> either the head doesn't touch the scratched areas, or touches it >>>> slowly enough that no further damage results. >>>> >>>> ????paul >>>> >>>> >> From glen.slick at gmail.com Tue Apr 19 12:03:37 2022 From: glen.slick at gmail.com (Glen Slick) Date: Tue, 19 Apr 2022 10:03:37 -0700 Subject: idea for a universal disk interface In-Reply-To: <7e76f41e-622f-2c3c-649b-e985af2e64d6@comcast.net> References: <21244280-7cd4-bec1-7144-439a4d5d0fdd@alembic.crystel.com> <7e76f41e-622f-2c3c-649b-e985af2e64d6@comcast.net> Message-ID: I also have multiple ESDI controllers, more than one these flavors: Dilog DQ686 http://www.bitsavers.org/pdf/dilog/2120-0137-1_DQ686_Nov89.pdf Emulex QD21 http://www.bitsavers.org/pdf/emulex/QD2151002-J_QD21_Jun90.pdf Sigma SCD-RQD11-EC (There seems to be multiple versions from different vendors of this same basic board). http://www.bitsavers.org/pdf/sigmaInformationSystems/400740-B_SDC-RQD11-EC_Disk_Ctrl_Man_Jul88.pdf They all support block mode DMA transfers, and command queuing with seek optimization. The Dilog DQ686 and Emulex QD21 are dual wide boards. The Sigma SCD-RQD11-EC is a quad wide board and has 1MB of cache memory (which takes up about a quarter of the board area). The examples I have might only be populated with 512KB of cache memory. I might have had close to a dozen working full height 5.25-inch ESDI drives at one point. Unfortunately most of them have failed while sitting idle over the last few years. Without checking now I don't know if any of them still work. So the dozen or so Q-Bus ESDI controllers don't have any use for me now. (Fortunately I also have more Q-Bus SCSI controllers than backplanes to put them in). I also have a single Andromeda ESDC ESDI controller. Never found a manual for that one. Did eventually figure out how to get into the on-board configuration utility. On Tue, Apr 19, 2022 at 8:56 AM Douglas Taylor via cctech wrote: > > Once upon a time I used an Emulex QD21, but I sold it because the actual > ESDI disks I had were a pain in the butt. Always crashing. > I still have a Webster (quad board) SRQD something. > I think I had a Dilog board also. It's been a while, probably 20 years. > Doug > > On 4/18/2022 9:12 PM, Chris Zach via cctech wrote: > > Interesting, what kind of ESDI controllers do you have? They got > > advanced features like cache, ordered seeks, and burst mode/block mode > > DMA? From bdweb at mindspring.com Tue Apr 19 13:40:20 2022 From: bdweb at mindspring.com (Bjoren Davis) Date: Tue, 19 Apr 2022 14:40:20 -0400 Subject: interesting DEC Pro stuff on eBay Message-ID: <611f86e8-6488-ca4f-adea-8ccd9db6b13b@mindspring.com> Hello Retronians, I just saw some interesting DEC Professional items on eBay from smhelectronics261 (https://www.ebay.com/sch/smhelectronics261/m.html): 1. Pro-350 (and presumably -325) video board https://www.ebay.com/itm/294933607768 2. RD (hard disk) controller https://www.ebay.com/itm/294933620853 3. CTI RAM board https://www.ebay.com/itm/294933515548 4. RAM daughtercards https://www.ebay.com/itm/294933505973.? The description says "This added 512MB or Ram" but I think it is mistaken. The boards are marked "5415084" which I believe is the 2-layer version of the board populated with 64 Kibit DRAMS, for a total of 128 KiByte/board or 256 KiByte for both boards (assuming that's actually what they're selling). 5. Something called a "DEC Digital Professional DMA tester diagnostic module Pro350" board https://www.ebay.com/itm/294933577848. I've bought from this seller before and they seem to have had access to DEC-internal development stuff.? I bought a prototype TMS board and a prototype never-released high speed serial board from them. #5 is especially interesting because, as far as I know, no production CTI board ever did DMA (not even the disk and Ethernet controllers, to everyone's disappointment).? Looking at the photo I see the name "Dave Iacobone".? I wonder if he is still around and remembers that board. Just FYI: I, too, might bid on some of these items, but I thought it'd only be fair to let everyone know. --Bjoren From shadoooo at gmail.com Tue Apr 19 13:49:12 2022 From: shadoooo at gmail.com (shadoooo) Date: Tue, 19 Apr 2022 18:49:12 +0000 (UTC) Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: Guy, I understand that cylinder command has no particular timing requirements, while head command must be effective within microseconds. My doubt is, RAM access on high performance port could be fast enough to satisfy also the latter. In case it couldn't or was not assured, I think the best strategy could be to preload only a small block of data for each head, for prompt start on head command; enough to manage safely RAM access latency. Each block also would work as buffer for data of subsequent RAM accesses, until whole cylinder had been processed. This strategy would remove the strict requirement of blockram capacity for the Zynq, and given that bigger models cost a lot, it would be a significant spare for anybody. Furthermore,? support for any hypotetical disk with bigger cylinder (not SMD) or for tape with very large blocks or "infinite" streams could not be feasible with the whole cylinder design. I would prefer to avoid any such limitation, in way to possibly reuse the same data transfer modules for any media. Andrea From Rice43 at btinternet.com Tue Apr 19 14:32:48 2022 From: Rice43 at btinternet.com (Joshua Rice) Date: Tue, 19 Apr 2022 20:32:48 +0100 Subject: RCA COSMAC MS2000 MicroDisk Development System In-Reply-To: References: Message-ID: On with the saga of the COSMAC MS2000? I powered it up a few days ago. The ROM boots, nothing smoked, the drives whirr. However, one of the RAM boards (the lower 32k) seems to have failed with a stuck bit. it outputs the rather humourous message of BAD RAM P00 (where P00 is memory page 00h). poking at various memory locations seem to reveal that they are populated with 40h instead of 00h. I tried reseating th card, and swapping backplane slots, to no avail. Now my first assumption was that the tc40h245p bus buffer might have an open short driving one of the lines high, but probing it with a multimeter hasn?t revealed anything enlightening, with all resistance values being practically identical. Sadly, this seems to be the only thing between the RAM chip?s data bus and the card edge connector. Continuity seems fine on all pins. Is it entirely possible that one of the RAM chips has an open short and is pulling the line high? How would i go about testing this without desoldering every chip off the board? I fear my soldering skills (and tools) aren?t up to the skill level required for such an endeavor, and i?m really paranoid about killing something that?s practically irreplaceable. One chip is probably fine, but a whole board is just asking for trouble. I hope someone here can shine some light on the matter. I?m really flying from the seat of my pants on this one, and thoroughly understand i?m way out of my depth! It?s entirely possible there?s something i?ve overlooked. For reference, this is the offending board: https://i.imgur.com/G2zMw7t.jpeg https://i.imgur.com/rrHvl4C.jpeg The data lines on the card edge connecter start from the 3rd finger from the top, and carry on down 8 fingers. It?s a dual sided board, no layers here. Thanks, Josh Rice From jfoust at threedee.com Tue Apr 19 14:38:19 2022 From: jfoust at threedee.com (John Foust) Date: Tue, 19 Apr 2022 14:38:19 -0500 Subject: interesting DEC Pro stuff on eBay In-Reply-To: <611f86e8-6488-ca4f-adea-8ccd9db6b13b@mindspring.com> References: <611f86e8-6488-ca4f-adea-8ccd9db6b13b@mindspring.com> Message-ID: <20220419193831.5924A4E6B1@mx2.ezwind.net> At 01:40 PM 4/19/2022, Bjoren Davis via cctalk wrote: >Looking at the photo I see the name "Dave Iacobone".? I wonder if he is still around and remembers that board. https://www.linkedin.com/in/dave-iacobone-0a11436/ At DEC from 1993 to 1996, now at iRobot. - John From tom94022 at comcast.net Tue Apr 19 15:07:20 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Tue, 19 Apr 2022 13:07:20 -0700 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <00b201d85429$146f7230$3d4e5690$@comcast.net> Agree that we are talking about two vastly different projects. Personally I think the universal disk reader is doable and interesting but expensive. Start with a clean bench having an air bearing variable speed motor and a universal mount to which various pack/cartridge adapters can be mounted. Add a laser controlled horizontal positioner with a Z height adjustable probe head station (manual Z height at first but maybe automated if volume dictates) Add some sort of head load/unload Pretty straight forward stuff A modern TMR should easily read the much wider track of old iron oxide but the issue is flying high and head crashes. So there needs to be some research here. Perhaps a surface (or track) mechanical buffering process would be sufficient or a ridiculously wide by current standards TMR head or such a head with an adjustable flying height read element or some combination should be workable. Track following may or may not be a requirement. If the read element is small enough maybe just positioning it in the center is enough. Or maybe just once around synthetic run out compensation would work given the very wide track/ very narrow reader. If you have to go full track following that's not much of a problem with the few embedded servo old iron but implies a second head reading the servo disk coupled to the reader head - doable but one more head to crash and a whole research project on the various track following systems and associated hardware. Probably doable with DSPs since the transition rate on the servo info is pretty low Finally you get to interpreting the raw data; this might be relatively straight forward since the data rate of old iron is fairly low so the analog signal could be highly oversampled, 10x maybe, which makes the decoding pretty straight forward if you know the format and recording code. I once built a disk pack servo writer, class 100 clean room, slit the concrete foundation, excavated and filled with sand, put an air bearing dc motor with a 3330 spindle mount in a granite slab and used a laser positioning micro stepping actuator to write the servo surface of 3336 class disk packs. Feels like a similar project Tom -----Original Message----- From: Paul Koning [mailto:paulkoning at comcast.net] Sent: Tuesday, April 19, 2022 5:30 AM To: Mike Katz; cctalk at classiccmp.org Subject: Re: idea for a universal disk interface > On Apr 18, 2022, at 6:44 PM, Mike Katz via cctalk < cctalk at classiccmp.org> wrote: > > Which is more generic. > > ESDI, SMD or SCSI. > > In my opinion, SCSI is as close are you are going to get to a universal interface. > > As for reading raw data from a drive. The newer the drive, the higher the bit density and lower the strength of the magnetic fields and hence the lower the flying height. You have to deal with linear (or horizontal) recording, perpendicular recording, Heat assisted magnetic recording, microwave assisted magnetic recording. The latest technologies are approaching 1TB (yes that's TB) per square inch. > > If you spin the platters too slowly you will not be able to distinguish individual magnetic fluctuations from noise. What do you propose as your maximum data density (in BPI) and what is the minimum speed you will need to accurately decode it. I know about some of the modern drive magic, but I wasn't talking about those at all. My comments about recovering raw signals from disk surfaces is for much earlier disks, especially removable packs. In more recent disks you always have the drive if you have the disk since they are the same thing. (I'm ignoring "data recovery" services here that deal with mechanically failed drives; that's a specialized business and as you said it's increasingly difficult with modern drives.) If you consider 1960s through 1980s you're likely to run into disk packs for which the drives may be hard to find. The mechanical tolerances of those devices require care but are not crazy difficult, as my RC11/RS64 example last week was meant to illustrate. The bit densities are not all that high, nor the track densities. Consider for example that the track positions on a 1311 drive are set by mechanical detents, and are low enough that no servo system is used at all. My mechanical skills and tools are perhaps a bit better than some of the readers here, undoubtedly worse than others. I could sketch a "spin table" that could handle, say, an RK05 pack. Without a milling machine I can't build it, but that could be fixed, and I could refine my skills to make it work. Do I plan to? No, but if an interesting enough pack showed up I could imagine doing it. The RA60 pack I have would be a bit more of a stretch -- more platters and higher densities, not to mention lack of documentation -- but it's still on the edge of possibilities. So I think there are two different possible projects here. One involves a generic controller/emulator for common disk to controller interfaces, like ESDI or SMD. (Or SCSI but those are off the shelf items, right?) I'd imagine there would be plenty of takers for that, just as there are for the MFM and floppy emulators. The other, more difficult and less needed, is the pack reader that I was discussing. There is a little overlap between the two but not much. paul From ggs at shiresoft.com Tue Apr 19 17:58:18 2022 From: ggs at shiresoft.com (Guy Sotomayor) Date: Tue, 19 Apr 2022 15:58:18 -0700 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: It's not really fast enough and you'll get into all sorts of complications once you start to think about trying to keep up with simulation rotations.? For example, if someone starts a read at half way through a rotation (e.g. after the index pulse) now you have to have logic/code that can start/stop the transfer in random places.? The way that I have it designed, it's all sequential so no random start / lengths and it's all done during a seek which the data isn't being clocked out. The Zynq-7020 (which is my low end design) has 4.9Mb of block RAM (in 140 36Kb blocks).? In the cylinders I actually use 9-bits per byte as I need an escape in order to encode some other data.? ;-) With that it can hold the 512KB needed with some to spare.? My high end design will use the Zynq-Ultrascale+ (ZU3CG) has 7.6Mb of block RAM (in 216 36Kb blocks).? If I go to the next higher version (ZU4CG)the block RAM goes down to 4.5Kb (in 128 36Kb blocks) but gains 13.5Mb in "UltraRAM" which should allow for any reasonable cylinder buffering. Of course, I'm just describing my design and design requirements.? First and foremost I wanted a simple HW & SW design that could provide accurate drive timings (e.g. I could faithfully reproduce the timings of any particular drive) so as to maximize the compatibility with any controller (and I have some weird ones). I've been pouring over ANSI specs, controller specs and drive specs for SMD/ESDI for a few years now and have thought about a number of different ways to do this and what I've described is what I've come up with. You may have different goals which may drive you to make different choices/decisions. TTFN - Guy On 4/19/22 11:49, shadoooo via cctalk wrote: > Guy, > I understand that cylinder command has no particular timing requirements, while head command must be effective within microseconds. My doubt is, RAM access on high performance port could be fast enough to satisfy also the latter. > In case it couldn't or was not assured, I think the best strategy could be to preload only a small block of data for each head, for prompt start on head command; enough to manage safely RAM access latency. > Each block also would work as buffer for data of subsequent RAM accesses, until whole cylinder had been processed. > This strategy would remove the strict requirement of blockram capacity for the Zynq, and given that bigger models cost a lot, it would be a significant spare for anybody. > Furthermore,? support for any hypotetical disk with bigger cylinder (not SMD) or for tape with very large blocks or "infinite" streams could not be feasible with the whole cylinder design. I would prefer to avoid any such limitation, in way to possibly reuse the same data transfer modules for any media. > > Andrea -- TTFN - Guy From mjd.bishop at emeritus-solutions.com Tue Apr 19 18:01:22 2022 From: mjd.bishop at emeritus-solutions.com (Martin Bishop) Date: Tue, 19 Apr 2022 23:01:22 +0000 Subject: Fanuc PPR - Paper Tape Punch, Printer and Reader Message-ID: <512fca2297b64715b41def6728752e25@WINHEXBEEU125.win.mail> An update on my fight with the PPR, also one of its cousins. https://www.cnczone.com/forums/general-cnc-machine-related-electronics/430874-cnc-engineering.html#post2505622 covers my RFI to the CNC community and provides a few pictures of a 19" rack reader integrated with a Zynq; load binary tape, run program on FPGA PDP-11. That was the cousin, which provided an education on Fanuc PTRs. The PPR's PTR turns out to have had a blown illuminator: the series (active) diode was o/c and the PNP which effects the constant current source had the wrong pin out - the Fanuc footprint is not industry standard. The PNP had obviously been replaced by hands unknown, the flux had not been cleaned off. My only, real, interest in the pathology is will it happen again. With that fixed: PPR in remote mode, load tape, send DC1, tape whizzes through, octets crawl out (4800 baud). My unanswered questions are now mostly those associated with the 19" rack reader. Specifically, what input A13 does and the semantics of the front panel switch positions. Martin From cisin at xenosoft.com Tue Apr 19 21:14:27 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Apr 2022 19:14:27 -0700 (PDT) Subject: TRS-80 Question In-Reply-To: References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> <25173.52943.965895.809836@dobie-old.ylee.org> Message-ID: >>>> There's a 2K hole in the Model I memory map above the ROM >>> Is this the hole that causes stock Model I to not run CP/M? >> NO. >> The problem with CP/M on TRS80 is that CP/M expects RAM from location 0 on >> up. On Tue, 19 Apr 2022, Charles Dickman wrote: > When I was a freshman at Purdue, I lugged my Model III to my dorm room and > connected to the ECN network with a 300 baud modem. I used a local editor > and wrote a Pascal program to upload my Pascal source to the dual processor > VAX-11/780 (Google George Goble), ea or eb, (I don't remember) that was > used by our introductory programming class. The terminal program I had was > something I found in Byte magazine in assembler and I modified it for the > TRS-80. I had BASIC, Assembler and Fortran on the TRS-80 M III, so it was > probably all in assembly. > > There was an article in Byte about CP/M for the TRS-80 Model III that > described a hack to swap the ROM for RAM. The idea was to invert bits A15 > and A14. That would move the ROM and keyboard from 0000 to C000. There was > a spare bit in some 4 bit register, so all you had to do was cut a couple > traces and insert some XOR gates. I remember doing the modification on a > Saturday while listening to the Purdue football game on the radio. I put it > all back together and it worked. WoHo! > > At that point though I had no access to CP/M or where I might get it legal > or otherwise, but I was good to go when I found it. > > I still have the computer and I still have the Byte copy. So 37 years later > I should try to complete the project. > > -chuck There were numerous hacks for TRS80 CP/M. FMG sold a relocated CP/M for stock TRS80 Mnay programs weren't compatible, but it WAS CP/M, and adequate for teaching CP/M basics to my class, such as creating a zero length file for program restarting, etc. Omikrom ("Mapper") Parasitic Engineering ("Shuffleboard"? Howard Fullmer's company) Both of those were one daughterboard in the Model 1 to remap memory, and a daughterboard in the Expansion Interface to add 8" capability There also some for model 3, including Montezma Micro (Ron Jones?) Hurrican Labs, FEC? Holmes? Micro Craft? When Radio Shack came out with the Model 4, which had built-in suitable memory map, they sold "CP/M Plus" (3.0?) That would probably be the best to work with, and likely the easiest to find. -- Grumpy Ol' Fred cisin at xenosoft.com From cz at alembic.crystel.com Tue Apr 19 17:29:44 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 19 Apr 2022 18:29:44 -0400 Subject: idea for a universal disk interface In-Reply-To: References: <21244280-7cd4-bec1-7144-439a4d5d0fdd@alembic.crystel.com> <7e76f41e-622f-2c3c-649b-e985af2e64d6@comcast.net> Message-ID: Good data, thanks! I kind of like the ESDI disks, they're more solid and reliable than the MFM ones, and to be honest the RQDX3 was not a super fast disk controller. I wonder if it could do block mode DMA. I'll keep an eye out for the Sigma, the only thing I wish I had on the MTI MQD13 would be some disk cache to speed things up. Granted 11/M+ does have disk caching in the OS, I should check to see how much quicker that makes things. Good used ESDI disks come up on Ebay from time to time. A nice 660mb CDC is enough for most general pdp usage... C On 4/19/2022 1:03 PM, Glen Slick via cctech wrote: > I also have multiple ESDI controllers, more than one these flavors: > > Dilog DQ686 > http://www.bitsavers.org/pdf/dilog/2120-0137-1_DQ686_Nov89.pdf > > Emulex QD21 > http://www.bitsavers.org/pdf/emulex/QD2151002-J_QD21_Jun90.pdf > > Sigma SCD-RQD11-EC (There seems to be multiple versions from different > vendors of this same basic board). > http://www.bitsavers.org/pdf/sigmaInformationSystems/400740-B_SDC-RQD11-EC_Disk_Ctrl_Man_Jul88.pdf > > They all support block mode DMA transfers, and command queuing with > seek optimization. The Dilog DQ686 and Emulex QD21 are dual wide > boards. The Sigma SCD-RQD11-EC is a quad wide board and has 1MB of > cache memory (which takes up about a quarter of the board area). The > examples I have might only be populated with 512KB of cache memory. > > I might have had close to a dozen working full height 5.25-inch ESDI > drives at one point. Unfortunately most of them have failed while > sitting idle over the last few years. Without checking now I don't > know if any of them still work. So the dozen or so Q-Bus ESDI > controllers don't have any use for me now. (Fortunately I also have > more Q-Bus SCSI controllers than backplanes to put them in). > > I also have a single Andromeda ESDC ESDI controller. Never found a > manual for that one. Did eventually figure out how to get into the > on-board configuration utility. > > > > On Tue, Apr 19, 2022 at 8:56 AM Douglas Taylor via cctech > wrote: >> >> Once upon a time I used an Emulex QD21, but I sold it because the actual >> ESDI disks I had were a pain in the butt. Always crashing. >> I still have a Webster (quad board) SRQD something. >> I think I had a Dilog board also. It's been a while, probably 20 years. >> Doug >> >> On 4/18/2022 9:12 PM, Chris Zach via cctech wrote: >>> Interesting, what kind of ESDI controllers do you have? They got >>> advanced features like cache, ordered seeks, and burst mode/block mode >>> DMA? From chd at chdickman.com Tue Apr 19 20:45:28 2022 From: chd at chdickman.com (Charles Dickman) Date: Tue, 19 Apr 2022 21:45:28 -0400 Subject: TRS-80 Question In-Reply-To: References: <9f39b7ed-5e42-01cc-1b0f-fe8a649fb379@dittman.net> <06846e61-bb55-feaf-b49d-81754ab0b47c@dittman.net> <25173.52943.965895.809836@dobie-old.ylee.org> Message-ID: On Tue, Apr 12, 2022 at 3:46 PM Fred Cisin via cctech wrote: > >> There's a 2K hole in the Model I memory map above the ROM > On Tue, 12 Apr 2022, Yeechang Lee via cctech wrote: > > Is this the hole that causes stock Model I to not run CP/M? > > NO. > The problem with CP/M on TRS80 is that CP/M expects RAM from location 0 on > up. When I was a freshman at Purdue, I lugged my Model III to my dorm room and connected to the ECN network with a 300 baud modem. I used a local editor and wrote a Pascal program to upload my Pascal source to the dual processor VAX-11/780 (Google George Goble), ea or eb, (I don't remember) that was used by our introductory programming class. The terminal program I had was something I found in Byte magazine in assembler and I modified it for the TRS-80. I had BASIC, Assembler and Fortran on the TRS-80 M III, so it was probably all in assembly. There was an article in Byte about CP/M for the TRS-80 Model III that described a hack to swap the ROM for RAM. The idea was to invert bits A15 and A14. That would move the ROM and keyboard from 0000 to C000. There was a spare bit in some 4 bit register, so all you had to do was cut a couple traces and insert some XOR gates. I remember doing the modification on a Saturday while listening to the Purdue football game on the radio. I put it all back together and it worked. WoHo! At that point though I had no access to CP/M or where I might get it legal or otherwise, but I was good to go when I found it. I still have the computer and I still have the Byte copy. So 37 years later I should try to complete the project. -chuck From mj at mjturner.net Wed Apr 20 03:35:30 2022 From: mj at mjturner.net (Michael-John Turner) Date: Wed, 20 Apr 2022 09:35:30 +0100 Subject: Oracle Releases Solaris 11.4 "CBE" Free For Open-Source Developers / Non-Production Use In-Reply-To: <397bf1bc-a31a-892f-4fd1-1831076bccdd@alembic.crystel.com> References: <70215770-B6F1-41B8-A978-FAB74D0C4546@trick-1.net> <397bf1bc-a31a-892f-4fd1-1831076bccdd@alembic.crystel.com> Message-ID: On Tue, Apr 19, 2022 at 11:18:07AM -0400, Chris Zach via cctalk wrote: >Wonder if there is a SPARC build. Guess it's too much to ask if it >will run on my Sun 386i's.... There is, but the hardware support does exclude a lot of "hobbyist" SPARC systems[1]: "Oracle Solaris 11.4 supports systems based on the Oracle SPARC T4 or later processors; the Fujitsu SPARC64 X, X+, or XII processors; or x64 CPUs supporting either the Intel EM64T or AMD AMD64 instruction sets." Download link: https://www.oracle.com/solaris/solaris11/downloads/solaris-downloads.html [1] https://docs.oracle.com/cd/E37838_01/html/E60973/glmru.html Cheers, MJ -- Michael-John Turner * mj at mjturner.net * http://mjturner.net/ From paulkoning at comcast.net Wed Apr 20 12:27:27 2022 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 20 Apr 2022 13:27:27 -0400 Subject: interesting DEC Pro stuff on eBay In-Reply-To: <20220419193831.5924A4E6B1@mx2.ezwind.net> References: <611f86e8-6488-ca4f-adea-8ccd9db6b13b@mindspring.com> <20220419193831.5924A4E6B1@mx2.ezwind.net> Message-ID: > On Apr 19, 2022, at 3:38 PM, John Foust via cctalk wrote: > > At 01:40 PM 4/19/2022, Bjoren Davis via cctalk wrote: >> Looking at the photo I see the name "Dave Iacobone".? I wonder if he is still around and remembers that board. > > https://www.linkedin.com/in/dave-iacobone-0a11436/ > > At DEC from 1993 to 1996, now at iRobot. > > - John Maybe a different guy, since Pro development was in the late 1970s to early 1980s. paul From cz at alembic.crystel.com Wed Apr 20 12:37:06 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Wed, 20 Apr 2022 13:37:06 -0400 Subject: interesting DEC Pro stuff on eBay In-Reply-To: References: <611f86e8-6488-ca4f-adea-8ccd9db6b13b@mindspring.com> <20220419193831.5924A4E6B1@mx2.ezwind.net> Message-ID: <5504d6d7-3f76-86ae-6f2a-24d8c3d6d9d2@alembic.crystel.com> > Maybe a different guy, since Pro development was in the late 1970s to early 1980s. > > paul > Probably. Still would be interesting to see what the board actually is/does, I wondered why they never did DMA transfers for the Pro, maybe being a single user system it was pretty much pointless or something. But the drives on the Pro are pure slugs compared to my 11/83+ESDI disks, they seem to be more the speed of an RL02. C From paulkoning at comcast.net Wed Apr 20 13:03:48 2022 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 20 Apr 2022 14:03:48 -0400 Subject: interesting DEC Pro stuff on eBay In-Reply-To: <5504d6d7-3f76-86ae-6f2a-24d8c3d6d9d2@alembic.crystel.com> References: <611f86e8-6488-ca4f-adea-8ccd9db6b13b@mindspring.com> <20220419193831.5924A4E6B1@mx2.ezwind.net> <5504d6d7-3f76-86ae-6f2a-24d8c3d6d9d2@alembic.crystel.com> Message-ID: <462670BB-97D5-47AE-8809-7BE973C104EB@comcast.net> > On Apr 20, 2022, at 1:37 PM, Chris Zach via cctalk wrote: > >> Maybe a different guy, since Pro development was in the late 1970s to early 1980s. >> paul > > Probably. Still would be interesting to see what the board actually is/does, I wondered why they never did DMA transfers for the Pro, maybe being a single user system it was pretty much pointless or something. But the drives on the Pro are pure slugs compared to my 11/83+ESDI disks, they seem to be more the speed of an RL02. The Pro drives are MFM drives, which are not necessarily all that bad. But the controller is really inefficient, and you can see this from the fact that Pro disks are formatted with 4:1 interleaving, so multi-sector I/Os run at 1/5th the speed they would with a good controller. Interestingly enough, that's the fault of the controller, not the host, even though you'd think the cost of doing programmed I/O to fill/empty the sector buffer is a big deal. At least that's my conclusion from the fact that less than 4:1 interleaving is efficient on both Pro 350 and 380, while 3:1 interleaving is much slower on both. If the buffer fill were a factor you'd think that the 380, with its much faster CPU, would allow the use of a smaller interleave factor. That said, you'd think that DMA would make a 1:1 interleave controller much more feasible. And Bjoren also mentioned Ethernet. The DECNA is not to horrible without DMA because you can use its on-board memory directly as host packet buffers, though CT bus based memory is as I recall slower than motherboard memory. Still, one wonders why they didn't use a correctly designed Ethernet chip like LANCE, either with local memory or with DMA. paul From jfoust at threedee.com Wed Apr 20 13:09:07 2022 From: jfoust at threedee.com (John Foust) Date: Wed, 20 Apr 2022 13:09:07 -0500 Subject: interesting DEC Pro stuff on eBay In-Reply-To: References: <611f86e8-6488-ca4f-adea-8ccd9db6b13b@mindspring.com> <20220419193831.5924A4E6B1@mx2.ezwind.net> Message-ID: <20220420181012.19B2427377@mx1.ezwind.net> At 12:27 PM 4/20/2022, Paul Koning wrote: >Maybe a different guy, since Pro development was in the late 1970s to early 1980s. Perhaps his son? Or the guy returned to DEC, or listed his career differently on LinkedIn for other reasons? It's not a common name. - John From tom94022 at comcast.net Wed Apr 20 13:24:18 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Wed, 20 Apr 2022 11:24:18 -0700 Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <008f01d854e3$dd5f4f70$981dee50$@comcast.net> I don't know it for certain, but I am pretty sure that it is true that virtually all controllers issue the commands in this sequence, Set Cylinder, Set Head and then Seek, or words to that effect. They then wait for Ready which can be 10's of milliseconds later. So there is plenty of time to load the whole track much less just the first few bytes after index sufficient to start a data transfer Likewise, I don't know it for certain, but I am pretty sure that it is true that virtually all controllers switch heads sequentially when transferring blocks beyond the end of the track, so again, if necessary, those first blocks of the next track could be preloaded, but I am pretty sure that this is unnecessary, since there is more than a sufficient amount of time from the set head command to access the first block of bytes of the next track, sequential or not, after which the sustained data rate from memory far exceeds the clock rate to the controller BTW, at the end of any real track is always a Gap4 for speed variation and truncation residue so there is a fair bit of time there for housekeeping too. In other words, IMHO, a buffer on the order of a few memory words is more than enough Tom -----Original Message----- From: shadoooo [mailto:shadoooo at gmail.com] Sent: Tuesday, April 19, 2022 11:49 AM To: cctalk at classiccmp.org Subject: RE: idea for a universal disk interface Guy, I understand that cylinder command has no particular timing requirements, while head command must be effective within microseconds. My doubt is, RAM access on high performance port could be fast enough to satisfy also the latter. In case it couldn't or was not assured, I think the best strategy could be to preload only a small block of data for each head, for prompt start on head command; enough to manage safely RAM access latency. Each block also would work as buffer for data of subsequent RAM accesses, until whole cylinder had been processed. This strategy would remove the strict requirement of blockram capacity for the Zynq, and given that bigger models cost a lot, it would be a significant spare for anybody. Furthermore,? support for any hypotetical disk with bigger cylinder (not SMD) or for tape with very large blocks or "infinite" streams could not be feasible with the whole cylinder design. I would prefer to avoid any such limitation, in way to possibly reuse the same data transfer modules for any media. Andrea From cisin at xenosoft.com Wed Apr 20 13:55:19 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 20 Apr 2022 11:55:19 -0700 (PDT) Subject: idea for a universal disk interface In-Reply-To: <008f01d854e3$dd5f4f70$981dee50$@comcast.net> References: <008f01d854e3$dd5f4f70$981dee50$@comcast.net> Message-ID: On Wed, 20 Apr 2022, Tom Gardner via cctalk wrote: > Likewise, I don't know it for certain, but I am pretty sure that it is > true that virtually all controllers switch heads sequentially when > transferring blocks beyond the end of the track, Are you implying that data/file that is more than one track long has its next data on a track that is a different head of the same cylinder? If that is, indeed what you are saying, . . . It would make sense, and is common. Since it is obvious that switching heads should take less time than stepping to the next cylinder. BUT, it is a choice by the file system, not by the controller. As a simple example, when floppy disks went from single sided to double sided, SOME OS programmers chose to switch heads before stepping to the next cylinder. (Cylinder 0 side A, cylinder 0 side B, Cylinder 1 side A, cylinder 1 side B, etc.) BUT, some chose to "keep what they had", and use the second side as an "extension" of the first side, and chose to not switch heads until all tracks on the first side were exhausted. (Cylinder 0 side A, Cylinder 1 side A, Cylinder 2 side A . . . ) Of those, most "recalibrated" (seek to zero) for the second side (cylinder 0 side A, Cylinder 1 side A . . . Cylinder 75 side A, Cylinder 76 side A, Cylinde 0 side B, Cylinder 1 side B) (that's for 77 track 8") while others started using the second side starting at the high end (to avoid the seek to zero delay). (cylinder 0 side A, Cylinder 1 side A . . . Cylinder 75 side A, Cylinder 76 side A, Cylinder 76 side B, cylinder 75 side B, . . .) There were a few more variations, because it was the programmer making the decision, not the controller, and we can come up with some amazing cockamamy ideas. -- Grumpy Ol' Fred cisin at xenosoft.com From shadoooo at gmail.com Wed Apr 20 13:22:57 2022 From: shadoooo at gmail.com (shadoooo) Date: Wed, 20 Apr 2022 18:22:57 +0000 (UTC) Subject: idea for a universal disk interface In-Reply-To: References: Message-ID: <70ccd663-540b-49d8-8efe-a6ddbf38dd31@gmail.com> Guy, I agree that accessing data in blockram (synchronous with fixed latency) is really easier than accessing it from RAM (asynchronous with variable latency). Anyway I'm weighting the "cost" of additional complexity, which in change would allow to spare on Zynq cost. In any case memory access is never sequential, but a sequence of bursts with shorter length (16 beats or less). Considering this, the fact of starting or ending a sequential transfer is just a matter of generating addresses multiple of burst length. For this however you have to forget about Xilinx's free IP cores, and work directly with AXI3 bus of HP ports. As I would have to invest a large amount of time and of money, it would be nice to have somebody interested in buying a working and assembled kit with moderate price gain, in way to repay part of the investment. This however drives to bottom end FPGAs, with very limited amount of internal memory... whence the memory-spare design. About documentation: you mentioned several documents about SMD/ESDI standards and related details. Would you mind sharing this collection? Many thanks. Andrea From ggs at shiresoft.com Wed Apr 20 14:35:05 2022 From: ggs at shiresoft.com (Guy Sotomayor) Date: Wed, 20 Apr 2022 12:35:05 -0700 Subject: idea for a universal disk interface In-Reply-To: <70ccd663-540b-49d8-8efe-a6ddbf38dd31@gmail.com> References: <70ccd663-540b-49d8-8efe-a6ddbf38dd31@gmail.com> Message-ID: <9b74c8e7-d061-f03e-cf42-f93901345feb@shiresoft.com> I'm using Zynq SOMs (System on a module) that will plug into a "base board" (with hilrose connectors).? It is the base board that will have the "personality" of the emulator.? The baseboard will be fairly simple (level shifters, a small bit of logic and the drive interface transceivers).? So the base board is fairly simple (I think I have an early version in KiCAD...but it needs updating). I'm trying to use as much as I can from the free libraries so I'm trying to keep stuff as simple as possible from a logic design perspective.? Since I already have everything (in multiples) except for the base board, the cost to me is time at this point (which I don't have a lot of at the moment). I also didn't want to get into doing any design with BGAs (at least where I need to worry about it) hence the decision to go with SOMs.? With those, the SOM has the Zynq FPGA, flash, DRAM, etc (including the critical VRs and clocks).? All I need to provide is 3.3v.? ;-) I should be able to dig up the docs.? Many are already on bitsavers.? Let me know what you can't find on Bitsavers. TTFN - Guy On 4/20/22 11:22, shadoooo via cctech wrote: > Guy, > I agree that accessing data in blockram (synchronous with fixed latency) is really easier than accessing it from RAM (asynchronous with variable latency). > Anyway I'm weighting the "cost" of additional complexity, which in change would allow to spare on Zynq cost. > In any case memory access is never sequential, but a sequence of bursts with shorter length (16 beats or less). > Considering this, the fact of starting or ending a sequential transfer is just a matter of generating addresses multiple of burst length. For this however you have to forget about Xilinx's free IP cores, and work directly with AXI3 bus of HP ports. > > As I would have to invest a large amount of time and of money, it would be nice to have somebody interested in buying a working and assembled kit with moderate price gain, in way to repay part of the investment. > This however drives to bottom end FPGAs, with very limited amount of internal memory... whence the memory-spare design. > > About documentation: you mentioned several documents about SMD/ESDI standards and related details. > Would you mind sharing this collection? > > Many thanks. > > Andrea -- TTFN - Guy From tom94022 at comcast.net Thu Apr 21 13:03:52 2022 From: tom94022 at comcast.net (Tom Gardner) Date: Thu, 21 Apr 2022 11:03:52 -0700 Subject: idea for a universal disk interface In-Reply-To: References: <008f01d854e3$dd5f4f70$981dee50$@comcast.net> Message-ID: <00a301d855aa$2ad800f0$808802d0$@comcast.net> Got me - I was thinking of HDDs which from the beginning had at least 2 heads so, given an appropriately sized Gap1, it was always faster to switch heads. And FWIW is some later SyQuest cartridge drives employing sectored servos it was faster to seek than to switch heads so they made a head switch into a seek, but they masked that all in the drive firmware In any event, it really doesn't matter for this device emulator if the end of a track is followed by a seek command; any time there is a seek command there is lots of time for the device's housekeeping to get ready for the next read. Tom -----Original Message----- From: Fred Cisin [mailto:cisin at xenosoft.com] Sent: Wednesday, April 20, 2022 11:55 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: RE: idea for a universal disk interface On Wed, 20 Apr 2022, Tom Gardner via cctalk wrote: > Likewise, I don't know it for certain, but I am pretty sure that it is > true that virtually all controllers switch heads sequentially when > transferring blocks beyond the end of the track, Are you implying that data/file that is more than one track long has its next data on a track that is a different head of the same cylinder? If that is, indeed what you are saying, . . . It would make sense, and is common. Since it is obvious that switching heads should take less time than stepping to the next cylinder. BUT, it is a choice by the file system, not by the controller. As a simple example, when floppy disks went from single sided to double sided, SOME OS programmers chose to switch heads before stepping to the next cylinder. (Cylinder 0 side A, cylinder 0 side B, Cylinder 1 side A, cylinder 1 side B, etc.) BUT, some chose to "keep what they had", and use the second side as an "extension" of the first side, and chose to not switch heads until all tracks on the first side were exhausted. (Cylinder 0 side A, Cylinder 1 side A, Cylinder 2 side A . . . ) Of those, most "recalibrated" (seek to zero) for the second side (cylinder 0 side A, Cylinder 1 side A . . . Cylinder 75 side A, Cylinder 76 side A, Cylinde 0 side B, Cylinder 1 side B) (that's for 77 track 8") while others started using the second side starting at the high end (to avoid the seek to zero delay). (cylinder 0 side A, Cylinder 1 side A . . . Cylinder 75 side A, Cylinder 76 side A, Cylinder 76 side B, cylinder 75 side B, . . .) There were a few more variations, because it was the programmer making the decision, not the controller, and we can come up with some amazing cockamamy ideas. -- Grumpy Ol' Fred cisin at xenosoft.com From dave at mitton.com Thu Apr 21 13:47:50 2022 From: dave at mitton.com (Dave Mitton) Date: Thu, 21 Apr 2022 14:47:50 -0400 Subject: interesting DEC Pro stuff on eBay In-Reply-To: References: Message-ID: <20220421184752.37C124E679@mx2.ezwind.net> Date: Wed, 20 Apr 2022 14:03:48 -0400 From: Paul Koning To: Chris Zach , "cctalk at classiccmp.org" Subject: Re: interesting DEC Pro stuff on eBay ?. ? That said, you'd think that DMA would make a 1:1 interleave controller much more feasible. And Bjoren also mentioned Ethernet. The DECNA is not to horrible without DMA because you can use its on-board memory directly as host packet buffers, though CT bus based memory is as I recall slower than motherboard memory. Still, one wonders why they didn't use a correctly designed Ethernet chip like LANCE, either with local memory or with DMA. paul You?d have to ask Bill Duane about that? He found several dynamic problems with the Intel Ethernet chipset. He was under NDA to them at one time. I suspect that the Pro team didn?t ask us and just went with that chip for some other reason. We obviously regretted that in the long run. Dave. Sent from Mail for Windows From paulkoning at comcast.net Thu Apr 21 13:51:10 2022 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 21 Apr 2022 14:51:10 -0400 Subject: interesting DEC Pro stuff on eBay In-Reply-To: <20220421184752.37C124E679@mx2.ezwind.net> References: <20220421184752.37C124E679@mx2.ezwind.net> Message-ID: <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> > On Apr 21, 2022, at 2:47 PM, Dave Mitton via cctech wrote: > > Date: Wed, 20 Apr 2022 14:03:48 -0400 > From: Paul Koning > To: Chris Zach , "cctalk at classiccmp.org" > > Subject: Re: interesting DEC Pro stuff on eBay > ?. > > ? That said, you'd think that DMA would make a 1:1 interleave controller much more feasible. And Bjoren also mentioned Ethernet. The DECNA is not to horrible without DMA because you can use its on-board memory directly as host packet buffers, though CT bus based memory is as I recall slower than motherboard memory. Still, one wonders why they didn't use a correctly designed Ethernet chip like LANCE, either with local memory or with DMA. > > paul > > You?d have to ask Bill Duane about that? He found several dynamic problems with the Intel Ethernet chipset. He was under NDA to them at one time. > I suspect that the Pro team didn?t ask us and just went with that chip for some other reason. We obviously regretted that in the long run. I sometimes get the feeling that the Pro team grabbed every Intel chip they could possibly use, even though every single one of them is badly designed and causes piles of problems. For example, the interrupt structure of the Pro is a nightmare, attributable directly to the fact that is what Intel came up with. And the 82586 implements bugs that were recognized and fixed 20 years earlier. paul From barry at csguy.org Thu Apr 21 13:58:03 2022 From: barry at csguy.org (Barry Hills) Date: Thu, 21 Apr 2022 11:58:03 -0700 Subject: Selling my 026/029 IBM punch card control drum ($150) Message-ID: Selling my 026/029 IBM punch card control drum ($150) Allows tabs, special characters, auto sequences, etc on IBM card punch systems Works fine. Good Condition. Contact me at cctech at gohills.com From bitwiz at 12bitsbest.com Thu Apr 21 16:40:49 2022 From: bitwiz at 12bitsbest.com (Mike Katz) Date: Thu, 21 Apr 2022 16:40:49 -0500 Subject: interesting DEC Pro stuff on eBay In-Reply-To: <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> References: <20220421184752.37C124E679@mx2.ezwind.net> <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> Message-ID: Intel has never understood interrupts or good cpu architecture. Look at the segment:offset architecture of the 8086 and of course it's single interrupt (without the separate interrupt controller chip) vs the 68000 somewhat orthogonal 32 bit architecture and 256 interrupts with 8 levels built into the chip. I could spend pages just describing how the 68K chip just blows away the 8086 considering they were both released at about the same time. For crying out loud the 6809 even though it only addresses 64K is a more powerful processor than the 8086.? Even with the 8086 clocking faster than the 6809. On 4/21/2022 1:51 PM, Paul Koning via cctalk wrote: > >> On Apr 21, 2022, at 2:47 PM, Dave Mitton via cctech wrote: >> >> Date: Wed, 20 Apr 2022 14:03:48 -0400 >> From: Paul Koning >> To: Chris Zach , "cctalk at classiccmp.org" >> >> Subject: Re: interesting DEC Pro stuff on eBay >> ?. >> >> ? That said, you'd think that DMA would make a 1:1 interleave controller much more feasible. And Bjoren also mentioned Ethernet. The DECNA is not to horrible without DMA because you can use its on-board memory directly as host packet buffers, though CT bus based memory is as I recall slower than motherboard memory. Still, one wonders why they didn't use a correctly designed Ethernet chip like LANCE, either with local memory or with DMA. >> >> paul >> >> You?d have to ask Bill Duane about that? He found several dynamic problems with the Intel Ethernet chipset. He was under NDA to them at one time. >> I suspect that the Pro team didn?t ask us and just went with that chip for some other reason. We obviously regretted that in the long run. > I sometimes get the feeling that the Pro team grabbed every Intel chip they could possibly use, even though every single one of them is badly designed and causes piles of problems. For example, the interrupt structure of the Pro is a nightmare, attributable directly to the fact that is what Intel came up with. And the 82586 implements bugs that were recognized and fixed 20 years earlier. > > paul > From bitwiz at 12bitsbest.com Thu Apr 21 16:40:49 2022 From: bitwiz at 12bitsbest.com (Mike Katz) Date: Thu, 21 Apr 2022 16:40:49 -0500 Subject: interesting DEC Pro stuff on eBay In-Reply-To: <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> References: <20220421184752.37C124E679@mx2.ezwind.net> <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> Message-ID: Intel has never understood interrupts or good cpu architecture. Look at the segment:offset architecture of the 8086 and of course it's single interrupt (without the separate interrupt controller chip) vs the 68000 somewhat orthogonal 32 bit architecture and 256 interrupts with 8 levels built into the chip. I could spend pages just describing how the 68K chip just blows away the 8086 considering they were both released at about the same time. For crying out loud the 6809 even though it only addresses 64K is a more powerful processor than the 8086.? Even with the 8086 clocking faster than the 6809. On 4/21/2022 1:51 PM, Paul Koning via cctalk wrote: > >> On Apr 21, 2022, at 2:47 PM, Dave Mitton via cctech wrote: >> >> Date: Wed, 20 Apr 2022 14:03:48 -0400 >> From: Paul Koning >> To: Chris Zach , "cctalk at classiccmp.org" >> >> Subject: Re: interesting DEC Pro stuff on eBay >> ?. >> >> ? That said, you'd think that DMA would make a 1:1 interleave controller much more feasible. And Bjoren also mentioned Ethernet. The DECNA is not to horrible without DMA because you can use its on-board memory directly as host packet buffers, though CT bus based memory is as I recall slower than motherboard memory. Still, one wonders why they didn't use a correctly designed Ethernet chip like LANCE, either with local memory or with DMA. >> >> paul >> >> You?d have to ask Bill Duane about that? He found several dynamic problems with the Intel Ethernet chipset. He was under NDA to them at one time. >> I suspect that the Pro team didn?t ask us and just went with that chip for some other reason. We obviously regretted that in the long run. > I sometimes get the feeling that the Pro team grabbed every Intel chip they could possibly use, even though every single one of them is badly designed and causes piles of problems. For example, the interrupt structure of the Pro is a nightmare, attributable directly to the fact that is what Intel came up with. And the 82586 implements bugs that were recognized and fixed 20 years earlier. > > paul > From cisin at xenosoft.com Thu Apr 21 17:14:26 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 21 Apr 2022 15:14:26 -0700 (PDT) Subject: Intel VS Motorola (Was: interesting DEC Pro stuff on eBay In-Reply-To: References: <20220421184752.37C124E679@mx2.ezwind.net> <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> Message-ID: On Thu, 21 Apr 2022, Mike Katz via cctalk wrote: > Intel has never understood interrupts or good cpu architecture. > Look at the segment:offset architecture of the 8086 and of course it's single > interrupt (without the separate interrupt controller chip) vs the 68000 > somewhat orthogonal 32 bit architecture and 256 interrupts with 8 levels > built into the chip. > I could spend pages just describing how the 68K chip just blows away the 8086 > considering they were both released at about the same time. > For crying out loud the 6809 even though it only addresses 64K is a more > powerful processor than the 8086.? Even with the 8086 clocking faster than > the 6809. The over-simplification that I gave my beginning students: Intel's chip design technique was to add features to the currect chip to make the next one. So, starting with the 8008?, they added kludges to kludges. Some of which made some things very awkward, such as the segment:offset method to add more memory to a 64K architecture. BUT, whenever they releaased a new chip, the software from the previous chip needed only trivial modifications to work. MS-DOS was based on CP/M (although NOT "plagiarized"). When the 5150(PC) shipped, major third part software packages became available right away. For example, when the 5150 (PC) came out in August 1981, Micropro immediately got Wordstar working on it. 'course it took them much longer to modify the documentation; we kidded them that that could have been done faster with certain word processors. IBM had Visicalc and Easy-writer; Wordstar (MicroPro) and Supercalc (Sorcim) were announced and demonstated immediately. On the other hand, Motorola did not modify their chips for the next major one. Instead, they redesigned from scratch. It took a little longer, and all software had to be rewritten, but they consistently ended up with THE BEST chip ("ichiban"). The 6809 was THE BEST 8 bit processor. But, marketing?? They handed it to Radio Shack who decided it would be a cartridge based home games machine, with chiclet keyboard, RF [ONLY] video, and minimal expansion capability. Users hacked around those limitations. When Apple made the Lisa, they had to write ALL software from scratch. Other than some algorithms from the source code, none of their 6502 software could be simply "ported" to the 68000. I have heard an anecdeote [from an Apple senior programmer] that during development of the Mac, it was mandated that it would ship with FOUR major software packages; but, with slipping deadlines, the four consisted of Mac-Write, Mac-Paint, Mac-Write, and Mac-Paint. Apocriphal? but amusing. When the Mac shipped, there was a frustratingly long delay for third party software. -- Grumpy Ol' Fred cisin at xenosoft.com From cclist at sydex.com Thu Apr 21 18:11:13 2022 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 21 Apr 2022 16:11:13 -0700 Subject: Intel VS Motorola (Was: interesting DEC Pro stuff on eBay In-Reply-To: References: <20220421184752.37C124E679@mx2.ezwind.net> <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> Message-ID: <04f279ee-738b-b4c3-875b-22f8855ea13c@sydex.com> On 4/21/22 15:14, Fred Cisin via cctalk wrote: > On Thu, 21 Apr 2022, Mike Katz via cctalk wrote:>> Intel has never understood interrupts or good cpu architecture. >> Look at the segment:offset architecture of the 8086 and of course it's >> single interrupt (without the separate interrupt controller chip) vs >> the 68000 somewhat orthogonal 32 bit architecture and 256 interrupts >> with 8 levels built into the chip. >> I could spend pages just describing how the 68K chip just blows away >> the 8086 considering they were both released at about the same time. >> For crying out loud the 6809 even though it only addresses 64K is a >> more powerful processor than the 8086.? Even with the 8086 clocking >> faster than the 6809. A lot of it was a matter of "Vass you dere, Shollie?" To be fair, how to do 8-level interrupts with the 8080 and 8008 was detailed in several application notes and provided initially by the 8214 PICU; before that, schematics were published on how to use the 74148 priority encoder. It's noteworthy that the 8085 included an on-chip priority encoder, as did the 80186. Initially, the 8086 was never really intended to be in the same target market as the 68K. Intel had the iAPX 432 plans for that--the so-called "micro mainframe". One thing that Intel did offer was a rich range of support chips--something that was a concern for early potential adopters of the 68K. What Intel did realize is that, like it or not, backward compatibility is very important. Much of the early IBM PC software was converted 8080 assembly language--Intel even provided a conversion tool. Given the expense of developing new software back then, that was a big concern. Heck, even PC-DOS was a loose rehash of CP/M-80 with a different filesystem stapled on. The compatibility lesson came back to haunt Intel recently with the IA64 (Itanium) architecture. It should be noted that I really, really liked the architecture of the 68000; in the same vein, I really, really liked that of the NSC 32000 chips. I really liked the PowerPC chips and use ARM MCUs in my embedded stuff. But my desktops still use Intel-compatible CPUs. I'm reminded that almost every car on the road still has a dashboard fixture called a "glove compartment" to keep your driving gloves safe. --Chuck From spc at conman.org Thu Apr 21 18:12:07 2022 From: spc at conman.org (Sean Conner) Date: Thu, 21 Apr 2022 19:12:07 -0400 Subject: interesting DEC Pro stuff on eBay In-Reply-To: References: <20220421184752.37C124E679@mx2.ezwind.net> <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> Message-ID: <20220421231207.GK30207@brevard.conman.org> It was thus said that the Great Mike Katz via cctalk once stated: > > I could spend pages just describing how the 68K chip just blows away the > 8086 considering they were both released at about the same time. Agree here. I loved the 68K and have fond memories of writing programs in it. But while the x86 has been Frankensteined into 64 bits, I don't think I can see the 68K ever being a 64-bit architecture. I don't think there are enough unused bits in the instruction formatting for that. > For crying out loud the 6809 even though it only addresses 64K is a more > powerful processor than the 8086.? Even with the 8086 clocking faster > than the 6809. As much as I like the 6809 [1] I think you are overselling it vs. the Intel 8086. Both only support a single IRQ [2], but the 8086 has more registers, and with the segmentation, you can have split code and data of 64K each. On the flip side, the 6809 does have some sweet addressing modes (especially indirect indexed) and easy position independent code (love that). -spc (And I've written assembly for all three architectures) [1] I even wrote an emulator: https://github.com/spc476/mc6809 [2] Okay, technically, the 6809 also has a "fast" interrupt, which only saves the PC and CC registers. From chd at chdickman.com Thu Apr 21 18:47:46 2022 From: chd at chdickman.com (Charles Dickman) Date: Thu, 21 Apr 2022 19:47:46 -0400 Subject: PCI floppy controller Message-ID: Were there ever any floppy controllers for the (parallel) PCI bus? I Googled a bunch and haven't found any. I am trying to outfit a computer for the long haul that can run a bunch of older software in virtual machines and do things like duplicate floppies in different formats. The motherboard I have supports all the formats I have tried, but only supports one drive. It also only has PCI and PCIe slots. -chuck From healyzh at avanthar.com Thu Apr 21 18:57:44 2022 From: healyzh at avanthar.com (Zane Healy) Date: Thu, 21 Apr 2022 16:57:44 -0700 Subject: PCI floppy controller In-Reply-To: References: Message-ID: <4E7A16BA-2EA2-40A5-B0BF-B6B3AE25E533@avanthar.com> > On Apr 21, 2022, at 4:47 PM, Charles Dickman via cctalk wrote: > > Were there ever any floppy controllers for the (parallel) PCI bus? I > Googled a bunch and haven't found any. > > I am trying to outfit a computer for the long haul that can run a bunch of > older software in virtual machines and do things like duplicate floppies in > different formats. The motherboard I have supports all the formats I have > tried, but only supports one drive. It also only has PCI and PCIe slots. > > -chuck Catweasel? http://wiki.icomp.de/wiki/Catweasel Zane From cclist at sydex.com Thu Apr 21 19:02:44 2022 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 21 Apr 2022 17:02:44 -0700 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On 4/21/22 16:47, Charles Dickman via cctalk wrote: > Were there ever any floppy controllers for the (parallel) PCI bus? I > Googled a bunch and haven't found any. > > I am trying to outfit a computer for the long haul that can run a bunch of > older software in virtual machines and do things like duplicate floppies in > different formats. The motherboard I have supports all the formats I have > tried, but only supports one drive. It also only has PCI and PCIe slots. None that I'm aware of--PC floppy driver software depends very heavily on the ISA bus DMA and interrupt setup. Even with no ISA slots, the typical PC chipset provided the southbridge ISA hooks for a floppy controller. Gradually it has disappeared, along with the legacy serial and parallel ports. On one of my Socket 939 motherboards, I fashioned a bracket with a DC37F connector and a switch, so I could switch the single floppy to an external one. Works a treat--recall that you need only switch the drive select and motor enable lines, so a DPDT switch suffices. I like the motherboard because it can handle MFM and FM encodings, as well as the 128 byte MFM sectors. I suppose it might be possible to fashion a legacy floppy controller on a PCI card with enough supporting logic to make it compatible with existing software, but I'm not aware of such an effort. --Chuck From mloewen at cpumagic.scol.pa.us Thu Apr 21 19:30:47 2022 From: mloewen at cpumagic.scol.pa.us (Mike Loewen) Date: Thu, 21 Apr 2022 20:30:47 -0400 (EDT) Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022, Charles Dickman via cctalk wrote: > Were there ever any floppy controllers for the (parallel) PCI bus? I > Googled a bunch and haven't found any. > > I am trying to outfit a computer for the long haul that can run a bunch of > older software in virtual machines and do things like duplicate floppies in > different formats. The motherboard I have supports all the formats I have > tried, but only supports one drive. It also only has PCI and PCIe slots. You might consider going with a different (older) motherboard with a floppy controller that supports two drives and single-density (FM). I'm using an Abit KV8PRO with a 1.8GHz Athlon CPU, onboard 10/100/1000 ethernet, 1 AGP 8X/4X slot, 5 PCI slots, SATA and IDE drive support, and 4 USB ports. The floppy controller passes all of Dave Dunfield's TESTFDC tests except the double-density 128-byte sector tests. I haven't yet found a need for that format. I use this system to image and create 3-1/2", 5-1/4" and 8" diskettes, single and double-density. Mike Loewen mloewen at cpumagic.scol.pa.us Old Technology http://q7.neurotica.com/Oldtech/ From cz at alembic.crystel.com Thu Apr 21 19:49:55 2022 From: cz at alembic.crystel.com (Chris Zach) Date: Thu, 21 Apr 2022 20:49:55 -0400 Subject: RX50 checkouts, different firmware? Message-ID: <991372ae-7b47-213d-e3eb-24b0ca345ef6@alembic.crystel.com> I've been working through my old RX50 drives figuring out what works, what needs cleaning, and what destroys disks. Using some scratch floppies I have found a couple of them were dirty, one had a head with something embedded (that I managed to get out), and one RX50 drive totally flunks the diagnostics on my Pro/380 (but does sort of work on the Rainbow). However I have noticed something: As part of my tests I am creating two floppies with two 350 block files on them. At first I was testing each floppy by writing the files, then doing a diff to compare them with the disk. Then I realized I can just have one floppy read and another write at the same time with a copy dz1:(file) dz2: and doing a diff both ways. Two of the RX50's do the Diff silently and quickly. The third however clicks the head pad load each track, each disk. I was wondering if this is because of firmware differences. When I do a compare to disk there is one smooth read from the floppy, but when going from floppy to floppy it seems to want to do the head pad each time it switches floppy disks. Thoughts? Good news is after cleaning and testing I have three RX50's which can read from each other, write the disks, and don't leave any track marks in the disk oxide. Now I can do a bit of reading of some old disks and go from there... Chris From chd at chdickman.com Thu Apr 21 20:01:01 2022 From: chd at chdickman.com (Charles Dickman) Date: Thu, 21 Apr 2022 21:01:01 -0400 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Thu, Apr 21, 2022 at 8:02 PM Chuck Guzis via cctalk < cctalk at classiccmp.org> wrote: > On 4/21/22 16:47, Charles Dickman via cctalk wrote: > > Were there ever any floppy controllers for the (parallel) PCI bus? I > > Googled a bunch and haven't found any. > > external one. Works a treat--recall that you need only switch the > drive select and motor enable lines, so a DPDT switch suffices. I like > I was at that point and looking at DP3T switches to have an external connection as well. DP3T switches are mess. > --Chuck > -chuck From chd at chdickman.com Thu Apr 21 20:23:26 2022 From: chd at chdickman.com (Charles Dickman) Date: Thu, 21 Apr 2022 21:23:26 -0400 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Thu, Apr 21, 2022 at 8:30 PM Mike Loewen via cctalk < cctalk at classiccmp.org> wrote: > On Thu, 21 Apr 2022, Charles Dickman via cctalk wrote: > > I am trying to outfit a computer for the long haul that can run a bunch > of > > older software in virtual machines and do things like duplicate floppies > in > > different formats. The motherboard I have supports all the formats I have > > tried, but only supports one drive. It also only has PCI and PCIe slots. > > You might consider going with a different (older) motherboard with a > floppy > controller that supports > I thought about that too, but I'm trying to stick with the hardware that I have. It is an ASUS board and an AMD Phenom II X955 processor. I have found a sweet spot between the Ubuntu version, kernel version and VMWARE version that run my virtual machines. > Mike Loewen mloewen at cpumagic.scol.pa.us > Old Technology http://q7.neurotica.com/Oldtech/ -chuck From cisin at xenosoft.com Thu Apr 21 20:36:23 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 21 Apr 2022 18:36:23 -0700 (PDT) Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022, Charles Dickman via cctalk wrote: > Were there ever any floppy controllers for the (parallel) PCI bus? I > Googled a bunch and haven't found any. > I am trying to outfit a computer for the long haul that can run a bunch of > older software in virtual machines and do things like duplicate floppies in > different formats. The motherboard I have supports all the formats I have > tried, but only supports one drive. It also only has PCI and PCIe slots. If you have floppy support already, couldn't you intercept the floppy cable and switch the drive selects? OK, ideal would be software controlled switching, but even a physical toggle switch in the cable would let you change to another drive, including a DC37 connector for externals. Didn't some of the Giga-Byte Technology GA series (GA-108) of PCI SCSI controllers have floppy support? https://arvutimuuseum.ee/th99/c/E-H/20876.htm Tyan S1363? Tyan S1366? 'course FINDING one might not be possible I've heard of a PCI to ISA bridge, but I've never seen one. Did any such thing ever exist? Wouldn't something like that be necessary to get adequate compatability? From cctalk at gtaylor.tnetconsulting.net Thu Apr 21 20:55:07 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Thu, 21 Apr 2022 19:55:07 -0600 Subject: PCI floppy controller In-Reply-To: References: Message-ID: <9d6f4542-8e3a-1b87-7bce-e8ef76c76dc0@spamtrap.tnetconsulting.net> On 4/21/22 5:47 PM, Charles Dickman via cctalk wrote: > Were there ever any floppy controllers for the (parallel) PCI bus? Didn't some of the Adaptec SCSI cards have a floppy controller on them? Could that be made to work? -- Grant. . . . unix || die From cclist at sydex.com Thu Apr 21 21:34:07 2022 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 21 Apr 2022 19:34:07 -0700 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On 4/21/22 18:01, Charles Dickman wrote: > On Thu, Apr 21, 2022 at 8:02 PM Chuck Guzis via cctalk > I was at that point and looking at DP3T switches to have an external > connection as well. DP3T switches are mess. You could also bring the floppy cable out to a standard DC-37 connector on a bracket, then use a ABCD switchbox to select whatever external DC-37-cabled floppy drive you wanted. They appear to still be offered in 2-way and 4-way varieties. --Chuck From cc at informatik.uni-stuttgart.de Fri Apr 22 02:41:00 2022 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Fri, 22 Apr 2022 09:41:00 +0200 (CEST) Subject: Selling my 026/029 IBM punch card control drum ($150) In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022, Barry Hills wrote: > Selling my 026/029 IBM punch card control drum ($150) Thanks, I had a good lough :-D Christian From abuse at cabal.org.uk Fri Apr 22 05:22:02 2022 From: abuse at cabal.org.uk (Peter Corlett) Date: Fri, 22 Apr 2022 12:22:02 +0200 Subject: interesting DEC Pro stuff on eBay In-Reply-To: <20220421231207.GK30207@brevard.conman.org> References: <20220421184752.37C124E679@mx2.ezwind.net> <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> <20220421231207.GK30207@brevard.conman.org> Message-ID: On Thu, Apr 21, 2022 at 07:12:07PM -0400, Sean Conner via cctalk wrote: [...] > Agree here. I loved the 68K and have fond memories of writing programs in > it. But while the x86 has been Frankensteined into 64 bits, I don't think > I can see the 68K ever being a 64-bit architecture. I don't think there > are enough unused bits in the instruction formatting for that. The Apollo 68080 core claims to have 64 bit registers, but the whole thing is woefully underdocumented. If there's documentation of its instruction encodings beyond the vasm source code, I can't find it. From lproven at gmail.com Fri Apr 22 06:44:34 2022 From: lproven at gmail.com (Liam Proven) Date: Fri, 22 Apr 2022 13:44:34 +0200 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 at 01:48, Charles Dickman via cctalk wrote: > > Were there ever any floppy controllers for the (parallel) PCI bus? Floppy *controllers*, no. Floppy *drives*, yes. The Backpack range were the most well-known, I'd say. e.g. 5?": https://www.amazon.com/MICRO-SOLUTION-1-44MB-Backpack-Parallel/dp/B0000512MS 3?": https://www.ebay.com/itm/384823809302 The company did a range of parallel-port storage drives: CDs, tape drives and so on. Most were slow but worked, but the floppy drives were quite a good option at the time for things like laptops which couldn't accept another drive or controller, or for adding drives unsupported by the built-in controller. I used them for emergency backups, data transfer, data recovery and so on. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From lproven at gmail.com Fri Apr 22 06:47:05 2022 From: lproven at gmail.com (Liam Proven) Date: Fri, 22 Apr 2022 13:47:05 +0200 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 at 13:44, Liam Proven wrote: > 5?": > https://www.amazon.com/MICRO-SOLUTION-1-44MB-Backpack-Parallel/dp/B0000512MS Oops, sorry, badly-chosen link. Both of those are, of course, 3? drives. The company *did* also offer 5?" units, though, as did others... https://www.vogons.org/viewtopic.php?t=72333 https://picclick.com/MicroSolutions-BackPack-525-Parallel-Port-Floppy-Drive-Rare-283066058252.html Here's the manual: http://minuszerodegrees.net/manuals/MicroSolutions/Micro%20Solutions%20-%20Backpack%20Diskette%20Drive%20-%20Users%20Guide%20-%201997.pdf -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From cclist at sydex.com Fri Apr 22 12:11:13 2022 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 22 Apr 2022 10:11:13 -0700 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On 4/22/22 04:44, Liam Proven via cctalk wrote: > The company did a range of parallel-port storage drives: CDs, tape > drives and so on. Most were slow but worked, but the floppy drives > were quite a good option at the time for things like laptops which > couldn't accept another drive or controller, or for adding drives > unsupported by the built-in controller. I used them for emergency > backups, data transfer, data recovery and so on. Back in the 90s, we bought these things by the carton, modified them to work with Japanese DOS 2.0 format (PC98) 3.5" floppies, rewrote the drivers, added a VxD for Win3.1 compatibility and sold a bunch of them. Popular with some segments of the CNC and other crowds. If you check (very) old posts on VCFed, you may find the code I published that provides a complete set of BIOS functions. It illustrates how the parallel link works, among other things. Internals were pretty simple--a floppy drive (usually Newtronics/Mitsumi), either an NSC 8374 FDC or later NSC 8477 FDC, an 8051-family MCU and about 16KB of SRAM and a small NVRAM chip to store configuration information. A not well-known fact is that the thing supports up to 4 drives and that the configuration NVRAM stores not only the "ID" of the unit but also the types of the 4 drives connected. It's rare (and perhaps impossible) to find a real parallel port on a modern system--usb parallel dongles don't work and neither do the PCIe parallel port cards. Along with the legacy floppy interface, the legacy serial and parallel ports may have been the last vestiges of the ISA architecture to be discarded. --Chuck From imp at bsdimp.com Fri Apr 22 12:46:42 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 22 Apr 2022 11:46:42 -0600 Subject: PCI floppy controller In-Reply-To: <9d6f4542-8e3a-1b87-7bce-e8ef76c76dc0@spamtrap.tnetconsulting.net> References: <9d6f4542-8e3a-1b87-7bce-e8ef76c76dc0@spamtrap.tnetconsulting.net> Message-ID: On Thu, Apr 21, 2022 at 7:54 PM Grant Taylor via cctalk < cctalk at classiccmp.org> wrote: > On 4/21/22 5:47 PM, Charles Dickman via cctalk wrote: > > Were there ever any floppy controllers for the (parallel) PCI bus? > > Didn't some of the Adaptec SCSI cards have a floppy controller on them? > > Could that be made to work? > The AHA 15x2 cards had a floppy controller. It was a nothing special floppy controller that you'd otherwise find bundled on a multi-function card. These cards were ISA. The details of which controller varied over time, IIRC, but I had one of these since I didn't have a multi-function card in my 486 DX2-66 that I started my PC journey with (it took me a while to give up on the Rainbow). The AHA 1742 cards had a floppy controller on them as well. Same deal: but this was a EISA card. I'm told the AHA1642 was similar, but I've not seen a microchannel version of the card. By the time there were PCI Adaptec cards, there was no longer a floppy controller on them that I ever saw. As others have pointed out, though, it would need special drivers and/or BIOS support because PCI devices mixed poorly with ISA DMA that the floppy was built on. Warner From robert.jarratt at ntlworld.com Fri Apr 22 13:03:35 2022 From: robert.jarratt at ntlworld.com (Rob Jarratt) Date: Fri, 22 Apr 2022 19:03:35 +0100 Subject: Advice on Desoldering an IC In-Reply-To: References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> Message-ID: <000001d85673$4969fc20$dc3df460$@ntlworld.com> I decided to invest in a Hakko FR-301. It worked almost immediately. Hours of trying before, I did it in 10 minutes! Regards Rob > -----Original Message----- > From: cctalk On Behalf Of dwight via cctalk > Sent: 16 April 2022 14:00 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: Advice on Desoldering an IC > > Sometimes the IC has been installed with the pins under tension. This is > typical of machine inserted ICs. When the solder is loose, bend the pin away > from the side it is pressed against. Do this carefully, don't over bend. You > want it to center in the hole. I recommend doing this with a separate iron > than the desoldering tool, so you can see what you are doing. Once the pin is > nicely centered in the hole use the desoldering tool to suck the solder out. > Make sure to always use a clean tip. An oxidixed tip will require excess > pressure to transfer heatand damage the trace. Keep the solder shinny with > a spung or soft metal wool. Do mot use a hard metal to clean an iron clad tip > or it will damage the iron and rot it from the inside ? > When not using the iron but leaving it hot, always leave a blob of solder so > that it won't have a thin oxide coating that is hard to remove. KEEP A CLEAN > TIP! > After sucking the solder with the tool, with a small screw driver, give the pin a > slight sideways pressure and let the screw driver slip off the pin. It should > make a plink sound or a momentary ring. This is something that you'll just > have to learn the sound of. If it doesn't sound right it means it isn't free of > the sides. Add solder and try to bend the pin. > Often the body side of the IC will have a tiny film of solder right where the IC > sits on the trace. If this is just the tiny amount to solder, one can break it > loose with a pair of short needle nose pliers, By squeezing the two sides of > the IC together. Don't expect to break loose a large blob. > Of course, if you expect to throw the IC away, use sharp pointed dikes to cut > the pins at the package and pull each pin individually while the solder is hot. > Use a small vice to hold the board so you can work from both sides. Tweezers > are best but heat the solder first and when hot grab the pin from the top. > Work quickly while the solder is hot. > You may need to refill the pin with fresh clean solder. Old oxidized solder > does not remove easily. Use separate rosin flux if you have it ( not plumber > flux!! ). > Like I said earlier, use a really clean tip. It should be shinny before trying to > heat the board. It is hard to do with the higher temperature solders. There is > some low temperature stuff you can use to remove solder more quickly. > I like using a large manual plastic solderpulit. Some like to use solder wick. > The solder removal suckers are often hard to keep the tip clean. If you have > to press hard on the tip to the work, the tip is not clean. It does help to have > some really tiny flux core solder to touch right at the junction of the iron and > work to start the heat transfer. Never use force to get the heat to start to > transfer! Clean tip and a quick touch with solder is all that is needed. > When you are not using the iron for some time, but leaving it on, add a > thicker blob of solder on it so it doesn't get a thin hard to clean oxide on it. > KEEP YOUR TIP FREE OF THIN OXIDE! > Dwight > > > > ________________________________ > From: cctalk on behalf of Rob Jarratt via > cctalk > Sent: Friday, April 15, 2022 10:49 AM > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Advice on Desoldering an IC > > I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am really > struggling to desolder it. I am using the technique of applying fresh solder > and then removing it. But after multiple cycles of this I think I am starting to > damage the PCB. > > > > I am using a fairly cheap desoldering station (this one > https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu- > plug/dp/SD > 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure is > equivalent to that of the professional Hakko ones though. I am also trying a > hand desoldering pump. None of these are able to clear many of the holes of > solder, although some are doing better than others. Nevertheless, the IC > remains stubbornly unmoving. > > > > Are there any tips for removing ICs? > > > > Thanks > > > > Rob From cctalk at gtaylor.tnetconsulting.net Fri Apr 22 13:25:29 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 22 Apr 2022 12:25:29 -0600 Subject: PCI floppy controller In-Reply-To: References: <9d6f4542-8e3a-1b87-7bce-e8ef76c76dc0@spamtrap.tnetconsulting.net> Message-ID: <0f81e2f2-901f-589e-f527-7a22efaa364f@spamtrap.tnetconsulting.net> On 4/22/22 11:46 AM, Warner Losh via cctalk wrote: > By the time there were PCI Adaptec cards, there was no longer a floppy > controller on them that I ever saw. As others have pointed out, > though, it would need special drivers and/or BIOS support because > PCI devices mixed poorly with ISA DMA that the floppy was built on. I'd swear that I've used a PCI Adaptec card with a floppy controller. 2942 comes to mind. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Fri Apr 22 13:26:22 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 22 Apr 2022 12:26:22 -0600 Subject: Advice on Desoldering an IC In-Reply-To: <000001d85673$4969fc20$dc3df460$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <000001d85673$4969fc20$dc3df460$@ntlworld.com> Message-ID: <9bbbed11-eedf-4e30-99a8-07e35c876e97@spamtrap.tnetconsulting.net> On 4/22/22 12:03 PM, Rob Jarratt via cctalk wrote: > I decided to invest in a Hakko FR-301. It worked almost > immediately. Hours of trying before, I did it in 10 minutes! Thank you for the feedback and the comparison of without and with it. -- Grant. . . . unix || die From lproven at gmail.com Fri Apr 22 13:37:51 2022 From: lproven at gmail.com (Liam Proven) Date: Fri, 22 Apr 2022 20:37:51 +0200 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 at 19:11, Chuck Guzis via cctalk wrote: > > Back in the 90s, we bought these things by the carton, modified them to > work with Japanese DOS 2.0 format (PC98) 3.5" floppies, rewrote the > drivers, added a VxD for Win3.1 compatibility and sold a bunch of them. > Popular with some segments of the CNC and other crowds. Huh! Nice work if you can get it. > A not well-known fact is that the thing supports up to 4 drives and that > the configuration NVRAM stores not only the "ID" of the unit but also > the types of the 4 drives connected. You mean, in principle 1 interface could control 4 drives? Wow! > It's rare (and perhaps impossible) to find a real parallel port on a > modern system--usb parallel dongles don't work No, I wouldn't expect 'em to. > and neither do the PCIe > parallel port cards. OK, now that surprised me. But on consideration, I suppose that they appear at different locations. 0x378 for I/O and IRQ 7, wasn't it? :-) 0x3BC and 0x278 for LPT2 and LPT3. I guess PCI[e] ones appear elsewhere and DOS doesn't know about the addresses. A Linux driver might have a shot. Any Windows driver old enough to drive a parallel port won't work on any currently-supported version of Windows. > Along with the legacy floppy interface, the > legacy serial and parallel ports may have been the last vestiges of the > ISA architecture to be discarded. Yup. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From imp at bsdimp.com Fri Apr 22 13:58:51 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 22 Apr 2022 12:58:51 -0600 Subject: PCI floppy controller In-Reply-To: <0f81e2f2-901f-589e-f527-7a22efaa364f@spamtrap.tnetconsulting.net> References: <9d6f4542-8e3a-1b87-7bce-e8ef76c76dc0@spamtrap.tnetconsulting.net> <0f81e2f2-901f-589e-f527-7a22efaa364f@spamtrap.tnetconsulting.net> Message-ID: On Fri, Apr 22, 2022, 12:25 PM Grant Taylor via cctalk < cctalk at classiccmp.org> wrote: > On 4/22/22 11:46 AM, Warner Losh via cctalk wrote: > > By the time there were PCI Adaptec cards, there was no longer a floppy > > controller on them that I ever saw. As others have pointed out, > > though, it would need special drivers and/or BIOS support because > > PCI devices mixed poorly with ISA DMA that the floppy was built on. > > I'd swear that I've used a PCI Adaptec card with a floppy controller. > 2942 comes to mind. > I thought the 2942 had 2 SCSI channels, I thought. Google can't find a definitive answer but all the 2940 cards on eBay didn't have obviously unstuck parts for a floppy. The aha 1540 did... Warner -- > Grant. . . . > unix || die > From glen.slick at gmail.com Fri Apr 22 14:26:29 2022 From: glen.slick at gmail.com (Glen Slick) Date: Fri, 22 Apr 2022 12:26:29 -0700 Subject: PCI floppy controller In-Reply-To: <0f81e2f2-901f-589e-f527-7a22efaa364f@spamtrap.tnetconsulting.net> References: <9d6f4542-8e3a-1b87-7bce-e8ef76c76dc0@spamtrap.tnetconsulting.net> <0f81e2f2-901f-589e-f527-7a22efaa364f@spamtrap.tnetconsulting.net> Message-ID: On Fri, Apr 22, 2022 at 11:25 AM Grant Taylor via cctalk wrote: > > I'd swear that I've used a PCI Adaptec card with a floppy controller. > 2942 comes to mind. Swearing about it doesn't make it so. Are there any Adaptec SCSI controllers other than the various flavors of these models which have floppy controllers? AHA-1522 (ISA) AHA-1542 (ISA) AHA-1742 (EISA) AHA-2742 (EISA) AHA-2842 (VLB) From cctalk at gtaylor.tnetconsulting.net Fri Apr 22 15:19:52 2022 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 22 Apr 2022 14:19:52 -0600 Subject: PCI floppy controller In-Reply-To: References: <9d6f4542-8e3a-1b87-7bce-e8ef76c76dc0@spamtrap.tnetconsulting.net> <0f81e2f2-901f-589e-f527-7a22efaa364f@spamtrap.tnetconsulting.net> Message-ID: On 4/22/22 1:26 PM, Glen Slick via cctalk wrote: > Swearing about it doesn't make it so. Agreed. Though swearing about it does speak to how strongly I /thought/ it was the case. Clearly I was wrong. It's only been about two decades since I would have messed with this. Maybe my grey matter is suffering bit rot faster than I realized. -- Grant. . . . unix || die From leec2124 at gmail.com Fri Apr 22 16:37:02 2022 From: leec2124 at gmail.com (Lee Courtney) Date: Fri, 22 Apr 2022 14:37:02 -0700 Subject: Selling my 026/029 IBM punch card control drum ($150) In-Reply-To: References: Message-ID: > Works fine. Good Condition. Doesn't say whether it includes power cord or not? ? Lee Courtney On Fri, Apr 22, 2022 at 12:41 AM Christian Corti via cctalk < cctalk at classiccmp.org> wrote: > On Thu, 21 Apr 2022, Barry Hills wrote: > > Selling my 026/029 IBM punch card control drum ($150) > > Thanks, I had a good lough :-D > > Christian > -- Lee Courtney +1-650-704-3934 cell From cisin at xenosoft.com Fri Apr 22 16:47:35 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Fri, 22 Apr 2022 14:47:35 -0700 (PDT) Subject: Selling my 026/029 IBM punch card control drum ($150) In-Reply-To: References: Message-ID: >> Works fine. Good Condition. On Fri, 22 Apr 2022, Lee Courtney via cctalk wrote: > Doesn't say whether it includes power cord or not? > ? Wouldn't matter. There aren't any Windows 10 drivers for its PCI card. From cclist at sydex.com Fri Apr 22 17:16:44 2022 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 22 Apr 2022 15:16:44 -0700 Subject: Selling my 026/029 IBM punch card control drum ($150) In-Reply-To: References: Message-ID: <51867776-dcf5-841b-46ee-7f3aa6f90610@sydex.com> On 4/22/22 14:37, Lee Courtney via cctalk wrote: >> Works fine. Good Condition. > > Doesn't say whether it includes power cord or not? You'd figure that there would be buckets of these things around. Many keypunch pools would have several of them for each keypunch, preloaded with cards for appropriate forms. They were also commonly "appropriate" by various individuals. Still, I guess if any technology is old enough, it gets scarce. --Chuck From macro at orcam.me.uk Fri Apr 22 17:47:50 2022 From: macro at orcam.me.uk (Maciej W. Rozycki) Date: Fri, 22 Apr 2022 23:47:50 +0100 (BST) Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022, Chuck Guzis via cctalk wrote: > I suppose it might be possible to fashion a legacy floppy controller on > a PCI card with enough supporting logic to make it compatible with > existing software, but I'm not aware of such an effort. You can of course build a PCI FDD interface around the NEC uPD765 or an equivalent controller, but you can't make it compatible with existing PC software, because too much PC specifics has been embedded there around the 8237 DMA controller and DMA page registers at fixed port I/O locations, which is inherently incompatible with the PCI decoding model. A feasible solution is a SCSI FDD option, such as the DEC RX23 device (which is actually a whole embedded microcomputer built around an 8080 CPU and using an 8237 DMA controller, an 8259 interrupt controller, a uPD765 floppy drive controller and a 5380 SCSI interface), which works as a removable drive with any single-ended parallel SCSI host adapter, e.g.: scsi 2:0:4:0: Direct-Access DEC RX23 (C) DEC 0054 PQ: 0 ANSI: 1 CCS Such SCSI host adapters remain widely available as PCI and PCIe options. HTH, Maciej From cclist at sydex.com Fri Apr 22 17:58:57 2022 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 22 Apr 2022 15:58:57 -0700 Subject: PCI floppy controller In-Reply-To: References: Message-ID: <4776ebcc-dead-a9a2-28cf-a2104e662278@sydex.com> On 4/22/22 15:47, Maciej W. Rozycki wrote: > On Thu, 21 Apr 2022, Chuck Guzis via cctalk wrote: > >> I suppose it might be possible to fashion a legacy floppy controller on >> a PCI card with enough supporting logic to make it compatible with >> existing software, but I'm not aware of such an effort. > A feasible solution is a SCSI FDD option, such as the DEC RX23 device > (which is actually a whole embedded microcomputer built around an 8080 CPU > and using an 8237 DMA controller, an 8259 interrupt controller, a uPD765 > floppy drive controller and a 5380 SCSI interface), which works as a > removable drive with any single-ended parallel SCSI host adapter, e.g.: However--the SCSI floppy is treated as a normal relative-block device (like a hard disk). AFAIK, provisions aren't made for alternate addressing schemes (e.g. first sector not being C0 H0 S1), FM encoding or interesting formats, such XDF. One might as well buy a cheap USB floppy drive. It's a pretty safe bet that you won't be able to read, much less format, an entire IBM System/3 floppy using one. --Chuck From jwsmail at jwsss.com Fri Apr 22 18:03:51 2022 From: jwsmail at jwsss.com (jim stephens) Date: Fri, 22 Apr 2022 16:03:51 -0700 Subject: Selling my 026/029 IBM punch card control drum ($150) In-Reply-To: <51867776-dcf5-841b-46ee-7f3aa6f90610@sydex.com> References: <51867776-dcf5-841b-46ee-7f3aa6f90610@sydex.com> Message-ID: <82ad09f9-4fdc-714d-d9bb-435c906eaf51@jwsss.com> I picked one up several years ago for my 029.? maybe 25 or 30 bucks. I also grabbed a couple of the cylinders that were used to put legends on cards, which were around.? Never knew exactly what process used them, but the look cool. On 4/22/2022 3:16 PM, Chuck Guzis via cctalk wrote: > On 4/22/22 14:37, Lee Courtney via cctalk wrote: >>> Works fine. Good Condition. >> Doesn't say whether it includes power cord or not? > You'd figure that there would be buckets of these things around. Many > keypunch pools would have several of them for each keypunch, preloaded > with cards for appropriate forms. They were also commonly > "appropriate" by various individuals. > > Still, I guess if any technology is old enough, it gets scarce. > > --Chuck > From cisin at xenosoft.com Fri Apr 22 18:17:49 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Fri, 22 Apr 2022 16:17:49 -0700 (PDT) Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022, Maciej W. Rozycki via cctalk wrote: > You can of course build a PCI FDD interface around the NEC uPD765 or an > equivalent controller, but you can't make it compatible with existing PC > software, because too much PC specifics has been embedded there around the > 8237 DMA controller and DMA page registers at fixed port I/O locations, > which is inherently incompatible with the PCI decoding model. While the lack of DMA would make it impossible to have complete compatability, it could still be partially compatible and have its own version of INT13h that would work for most? floppy utility software. Consider the PCJr. It did not have DMA, and wasn't compatible with everything for many MORE reasons, but some/most INT13h access to floppies did work. There were, however OTHER problems; IBM made the mistake of thinking that the PCJr could compete on its own as a home computer, failing to realize that everybody who used PCs at work expected to be able to use the PCJr as a PC, and to be able to expand it the same as a PC. As a further example of IBM's error in perception of the PCJr, they supplied it with a chiclets keyboard (just like the Coco), and then later had to give away FREE "real" keyboard replacements for the chiclets (just like the Coco). Don't expect access BELOW INT13h, talking to the DMA and FDC chips directly. For example, reading side B of a Kaypro disk, where the head number field in the sector headers doesn't match the number of which head it is on, and isn't the expected '1'. Fortunately, most computers with WD FDCs that used invalid head number fields in the sector headers didn't CARE what was there, and would work with disks formatted with correct head number fields. From bill.gunshannon at hotmail.com Fri Apr 22 20:07:25 2022 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Fri, 22 Apr 2022 21:07:25 -0400 Subject: PCI floppy controller In-Reply-To: References: Message-ID: As another person with a desire to be able to read/write/create disks of different sizes and formats I have found this interesting. So the question, then.... How hard would it be to make a floppy disk interface using an Arduino or even RasberryPi? If you could do that the choices of interface to a PC opens up quite a bit. It would never be like having a floppy hanging off the PC, but then none of the formats I am interested in are grounded in the PC anyway and utilities would need to be written to access them. comments? bill From w2hx at w2hx.com Fri Apr 22 20:12:54 2022 From: w2hx at w2hx.com (W2HX) Date: Sat, 23 Apr 2022 01:12:54 +0000 Subject: Advice on Desoldering an IC In-Reply-To: <000001d85673$4969fc20$dc3df460$@ntlworld.com> References: <001e01d850f1$2a520b70$7ef62250$@ntlworld.com> <000001d85673$4969fc20$dc3df460$@ntlworld.com> Message-ID: <6a4ddaec31274ea2913a0a76f763de57@EXBE015SV3.NA02.MSEXCHANGEOUTLOOK.COM> Indeed! Great investment. 73 Eugene W2HX Subscribe to my Youtube Channel:?https://www.youtube.com/c/w2hx-channel/videos -----Original Message----- From: cctalk On Behalf Of Rob Jarratt via cctalk Sent: Friday, April 22, 2022 2:04 PM To: 'General Discussion: On-Topic and Off-Topic Posts' Subject: RE: Advice on Desoldering an IC I decided to invest in a Hakko FR-301. It worked almost immediately. Hours of trying before, I did it in 10 minutes! Regards Rob > -----Original Message----- > From: cctalk On Behalf Of dwight via > cctalk > Sent: 16 April 2022 14:00 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: Advice on Desoldering an IC > > Sometimes the IC has been installed with the pins under tension. This > is typical of machine inserted ICs. When the solder is loose, bend the > pin away from the side it is pressed against. Do this carefully, don't > over bend. You want it to center in the hole. I recommend doing this > with a separate iron than the desoldering tool, so you can see what > you are doing. Once the pin is nicely centered in the hole use the desoldering tool to suck the solder out. > Make sure to always use a clean tip. An oxidixed tip will require > excess pressure to transfer heatand damage the trace. Keep the solder > shinny with a spung or soft metal wool. Do mot use a hard metal to > clean an iron clad tip or it will damage the iron and rot it from the > inside ? > When not using the iron but leaving it hot, always leave a blob of > solder so that it won't have a thin oxide coating that is hard to > remove. KEEP A CLEAN TIP! > After sucking the solder with the tool, with a small screw driver, > give the pin a slight sideways pressure and let the screw driver slip > off the pin. It should make a plink sound or a momentary ring. This is > something that you'll just have to learn the sound of. If it doesn't > sound right it means it isn't free of the sides. Add solder and try to bend the pin. > Often the body side of the IC will have a tiny film of solder right > where the IC sits on the trace. If this is just the tiny amount to > solder, one can break it loose with a pair of short needle nose > pliers, By squeezing the two sides of the IC together. Don't expect to break loose a large blob. > Of course, if you expect to throw the IC away, use sharp pointed dikes > to cut the pins at the package and pull each pin individually while the solder is hot. > Use a small vice to hold the board so you can work from both sides. > Tweezers are best but heat the solder first and when hot grab the pin from the top. > Work quickly while the solder is hot. > You may need to refill the pin with fresh clean solder. Old oxidized > solder does not remove easily. Use separate rosin flux if you have it > ( not plumber flux!! ). > Like I said earlier, use a really clean tip. It should be shinny > before trying to heat the board. It is hard to do with the higher > temperature solders. There is some low temperature stuff you can use to remove solder more quickly. > I like using a large manual plastic solderpulit. Some like to use solder wick. > The solder removal suckers are often hard to keep the tip clean. If > you have to press hard on the tip to the work, the tip is not clean. > It does help to have some really tiny flux core solder to touch right > at the junction of the iron and work to start the heat transfer. Never > use force to get the heat to start to transfer! Clean tip and a quick touch with solder is all that is needed. > When you are not using the iron for some time, but leaving it on, add > a thicker blob of solder on it so it doesn't get a thin hard to clean oxide on it. > KEEP YOUR TIP FREE OF THIN OXIDE! > Dwight > > > > ________________________________ > From: cctalk on behalf of Rob Jarratt > via cctalk > Sent: Friday, April 15, 2022 10:49 AM > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Advice on Desoldering an IC > > I am trying to remove an IC from my PDP 11/24 CPU, a DS8641. I am > really struggling to desolder it. I am using the technique of applying > fresh solder and then removing it. But after multiple cycles of this I > think I am starting to damage the PCB. > > > > I am using a fairly cheap desoldering station (this one > https://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu- > plug/dp/SD > 01384?st=duratool%20desoldering). Its spec in terms of vacuum pressure > is equivalent to that of the professional Hakko ones though. I am also > trying a hand desoldering pump. None of these are able to clear many > of the holes of solder, although some are doing better than others. > Nevertheless, the IC remains stubbornly unmoving. > > > > Are there any tips for removing ICs? > > > > Thanks > > > > Rob From imp at bsdimp.com Fri Apr 22 20:19:16 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 22 Apr 2022 19:19:16 -0600 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Fri, Apr 22, 2022 at 7:07 PM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: > > As another person with a desire to be able to read/write/create > disks of different sizes and formats I have found this interesting. > > So the question, then.... > > How hard would it be to make a floppy disk interface using an Arduino > or even RasberryPi? If you could do that the choices of interface > to a PC opens up quite a bit. It would never be like having a floppy > hanging off the PC, but then none of the formats I am interested in > are grounded in the PC anyway and utilities would need to be written > to access them. > > comments? > Isn't that what Greaseweasel and similar do? I have a kyroflux that I use to read floppies on my macbook. It can write as well and understands a ton of formats. Greaseweasel is more available and supported (I got my kyroflux before things went south, so wouldn't recommend others get one these days). Warner From bill.gunshannon at hotmail.com Fri Apr 22 20:43:26 2022 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Fri, 22 Apr 2022 21:43:26 -0400 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On 4/22/22 21:19, Warner Losh wrote: > > > On Fri, Apr 22, 2022 at 7:07 PM Bill Gunshannon via cctalk > > wrote: > > > As another person with a desire to be able to read/write/create > disks of different sizes and formats I have found this interesting. > > So the question, then.... > > How hard would it be to make a floppy disk interface using an Arduino > or even RasberryPi?? If you could do that the choices of interface > to a PC opens up quite a bit.? It would never be like having a floppy > hanging off the PC, but then none of the formats I am interested in > are grounded in the PC anyway and utilities would need to be written > to access them. > > comments? > > > Isn't that what Greaseweasel? and similar do? I have a kyroflux that I use > to read floppies on my macbook. It can write as well and understands a ton > of formats. Greaseweasel?is more available and supported (I got my kyroflux > before things went south, so wouldn't recommend others get one these > days). > > Warner I guess I'll find out. I just ordered one. Shipping is almost as much as the device. :-( Still think I will look into what it would take to access floppies from an Arduino. They're fun to play with, too. bill bill From cisin at xenosoft.com Fri Apr 22 20:48:12 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Fri, 22 Apr 2022 18:48:12 -0700 (PDT) Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022, Bill Gunshannon via cctalk wrote: > As another person with a desire to be able to read/write/create > disks of different sizes and formats I have found this interesting. > So the question, then.... > How hard would it be to make a floppy disk interface using an Arduino > or even RasberryPi? If you could do that the choices of interface > to a PC opens up quite a bit. It would never be like having a floppy > hanging off the PC, but then none of the formats I am interested in > are grounded in the PC anyway and utilities would need to be written > to access them. > comments? There are a LOT of possibilities. At one point, one of my associates was playing around with various "PC on a board" motherboards that were 5.25" floppy drive size. ("Quark" 80186 equivalent of an Ampro Little Board) He mounted it with spacers on a 5.25" drive, in an external case. It was a complete PC, that looked like an externala drive. His primary purpose was to build dedicated PC industrial data acquisition units. (Elcompco made several data acquisition systems that interfaced directly with banks of elevators) With trivial some software on it, it could connect to a "real" PC and do disk I/O. I once saw an extremely similar commercial product being marketed for Macintosh that was an "external 5.25" floppy drive that can read PC diskettes". It was an Ampro Little Board on a drive, with software for letting the Macintosh access files on its disks. They avoided mentioning what was inside the box, and presented it as a Macintosh special external drive. (similar to the Macintosh version of Video Toaster having an Amiga in the box) They added software to it to handle some CP/M formats. I was amused that among the formats that they supported were a format where I had misspeled the format name (due to customer handwriting), and they copied my mispelling, and they had a format that I had put into XenoCopy for a friend to handle his on-off prototype machine that never went to market. (a non-deliberate Mountweazel poach flag copyright trap) You could build a small box with a drive and either a from scratch controller, or a 765 (or better yet, a WD 179x), that connects to PC. In that box, you could put almost anything that could work with the FDC and communicate. But, as a first step, and "proof of concept" for an external box, why not just start with a 5160 or 5170, running software and communicating with your host PC? Then, later, you could replace the 5160/5170 with a more compact dedicated bespoke device. (OK, I'm still thinking in terms of the days when people were upgrading PCs and throwing out the old ones, so that an XT cost NOTHING) -- Grumpy Ol' Fred cisin at xenosoft.com From cisin at xenosoft.com Fri Apr 22 20:55:56 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Fri, 22 Apr 2022 18:55:56 -0700 (PDT) Subject: PCI floppy controller In-Reply-To: References: Message-ID: >> Isn't that what Greaseweasel? and similar do? I have a kyroflux that I use >> to read floppies on my macbook. It can write as well and understands a ton >> of formats. Greaseweasel?is more available and supported (I got my >> kyroflux >> before things went south, so wouldn't recommend others get one these >> days). On Fri, 22 Apr 2022, Bill Gunshannon via cctalk wrote: > I guess I'll find out. I just ordered one. Shipping is almost as much > as the device. :-( > Still think I will look into what it would take to access floppies > from an Arduino. They're fun to play with, too. In the early days of some of those devices, the primary users of them were interested in saving the raw track images for later recreation/copying of disks, and many didn't see any reason to want to even convert to sectors, much less parse the DIRectory and implement fucnctions of the file system to get FILES as output. It would be interesting to hear about the current state of the art of software for them to use as sector readers and for which file systems there is now software to extract FILES. (as opposed to raw image archiving for recreation/copying only) -- Grumpy Ol' Fred cisin at xenosoft.com From cclist at sydex.com Fri Apr 22 21:52:26 2022 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 22 Apr 2022 19:52:26 -0700 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On 4/22/22 18:43, Bill Gunshannon via cctalk wrote: > I guess I'll find out.? I just ordered one.? Shipping is almost as much > as the device. :-( > > Still think I will look into what it would take to access floppies > from an Arduino.? They're fun to play with, too. As far as I am aware, none of the "sampling" (basically use an internal timer to "capture" the interval between flux transitions) solutions have BIOS Int 13 access nor Windows NT sector-level access. If I'm wrong please feel free to correct me. The principle is quite simple and is the same one used by the old Catweasel board. You have a free-running timer at some rate, say 24 Mhz. Every time the magnetic flux on the floppy track reverses, you grab the current counter value and store it away. Some implementations reset the counter at that point; others just let it run and correct the counts at end-of-track. Then you go over the track data and derive the content, using software to simulate a data separator. For writing, you employ a similar counter idea, except the the counter is programmed as a pulse width modulator fed by a stream of values. Very simple--I can recall coaxing people into this on VCFed back around 2005 or so--I recall doing a very simple implementation employing a (now long-EOLed) ATMega162 and an external SRAM. It's not rocket science--a $3 "Blue Pill" stm32f103 board MCU needs little other than a connector to a floppy and some firmware. It runs at 72MHz, which is more than sufficient. Data is streamed to the host via the integral USB connection. However, it needs to be stated that everything from the Catweasel on depends on post- or pre-processing. As far as I know, none enjoys an Int 13h interface, like a standard floppy controller would. Now external drives like the Backpack did enjoy an Int 13h connection because they use a standard FDC inside. I suppose one could do the same with a USB setup. Mostly a matter of software. --Chuck From ccth6600 at gmail.com Sat Apr 23 01:03:35 2022 From: ccth6600 at gmail.com (Tom Hunter) Date: Sat, 23 Apr 2022 14:03:35 +0800 Subject: PCI floppy controller In-Reply-To: References: Message-ID: I am curious about your comment about "kryoflux going south". I did not hear about any problems. Could you please elaborate? I got mine about 2 or 3 years ago and it did everything I needed at the time, but haven't used it since. Thanks Tom On Sat, Apr 23, 2022 at 9:19 AM Warner Losh via cctalk < cctalk at classiccmp.org> wrote: > On Fri, Apr 22, 2022 at 7:07 PM Bill Gunshannon via cctalk < > cctalk at classiccmp.org> wrote: > > > > > As another person with a desire to be able to read/write/create > > disks of different sizes and formats I have found this interesting. > > > > So the question, then.... > > > > How hard would it be to make a floppy disk interface using an Arduino > > or even RasberryPi? If you could do that the choices of interface > > to a PC opens up quite a bit. It would never be like having a floppy > > hanging off the PC, but then none of the formats I am interested in > > are grounded in the PC anyway and utilities would need to be written > > to access them. > > > > comments? > > > > Isn't that what Greaseweasel and similar do? I have a kyroflux that I use > to read floppies on my macbook. It can write as well and understands a ton > of formats. Greaseweasel is more available and supported (I got my kyroflux > before things went south, so wouldn't recommend others get one these > days). > > Warner > From cc at informatik.uni-stuttgart.de Sat Apr 23 02:21:34 2022 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Sat, 23 Apr 2022 09:21:34 +0200 (CEST) Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022, "Maciej W. Rozycki" wrote: > You can of course build a PCI FDD interface around the NEC uPD765 or an > equivalent controller, but you can't make it compatible with existing PC > software, because too much PC specifics has been embedded there around the > 8237 DMA controller and DMA page registers at fixed port I/O locations, > which is inherently incompatible with the PCI decoding model. Yes, but I have never understood why you would need BIOS compatibility. Current operating systems have their own drivers. I mean, what would be the problem to write a, say, Linux driver for such a thing? And you don't even need DMA for the FDC if you want to make it cheap. OTOH a small dedicated SRAM and supporting microcontroller on the PCI board would make up a great PCI floppy controller. > A feasible solution is a SCSI FDD option, such as the DEC RX23 device > (which is actually a whole embedded microcomputer built around an 8080 CPU > and using an 8237 DMA controller, an 8259 interrupt controller, a uPD765 > floppy drive controller and a 5380 SCSI interface), which works as a > removable drive with any single-ended parallel SCSI host adapter, e.g.: I have a DaynaFile II, it was once an external SCSI 5.25" FDD with proprietary protocol, designed for crappy Apple computers. I had disassembled the firmware and documented the command set. And I think that I have redrawn the schematics at that time. It is much more capable of what the Apple driver might have supported. The hardware itself is just a small board with a DP5380, 80C31, a 32kB SRAM and 2793 FDC. So everyone shouting for a solution, I recommend looking for existing ones and eventually (re)build one from scratch. I mean, today you just need the FDC and a microcontroller with integrated USB or whatever to communicate with the host. (Note: of course this applies only to standard IBM formats) Christian From rodsmallwood52 at btinternet.com Sat Apr 23 03:41:10 2022 From: rodsmallwood52 at btinternet.com (Rod Smallwood) Date: Sat, 23 Apr 2022 09:41:10 +0100 Subject: pdp-8/i lamp board Message-ID: <17e63f1d-5a2b-235d-1978-79e8f6fe5ba8@btinternet.com> Hi ????? I have a running stripboard prototype of a full size 8i lamp board to go with my 8i front panels. ???? It uses the PiDP-8 software with Oscars agreement and encouragement. ??? There are no mods needed just plug in a Raspberry Pi running Oscars version of SimH and it runs. ???? PCB layout nearly complete and yes I know about the need for switches. ????? It runs from a terminal just fine for now. ??? YouTube Link here https://www.youtube.com/watch?v=3HM0kjZ7_NA Rod (panelman) From bill.gunshannon at hotmail.com Sat Apr 23 07:16:18 2022 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sat, 23 Apr 2022 08:16:18 -0400 Subject: PCI floppy controller In-Reply-To: References: Message-ID: On 4/22/22 21:48, Fred Cisin via cctalk wrote: > On Fri, 22 Apr 2022, Bill Gunshannon via cctalk wrote: >> As another person with a desire to be able to read/write/create >> disks of different sizes and formats I have found this interesting. >> So the question, then.... >> How hard would it be to make a floppy disk interface using an Arduino >> or even RasberryPi?? If you could do that the choices of interface >> to a PC opens up quite a bit.? It would never be like having a floppy >> hanging off the PC, but then none of the formats I am interested in >> are grounded in the PC anyway and utilities would need to be written >> to access them. >> comments? > > There are a LOT of possibilities. > > At one point, one of my associates was playing around with various "PC > on a board" motherboards that were 5.25" floppy drive size. ("Quark" > 80186 equivalent of an Ampro Little Board)? He mounted it with spacers > on a 5.25" drive, in an external case.? It was a complete PC, that > looked like an externala drive. > His primary purpose was to build dedicated PC industrial data > acquisition units.? (Elcompco made several data acquisition systems that > interfaced directly with banks of elevators) With trivial some software > on it, it could connect to a "real" PC and do disk I/O. > > > I once saw an extremely similar commercial product being marketed for > Macintosh that was an "external 5.25" floppy drive that can read PC > diskettes".? It was an Ampro Little Board on a drive, with software for > letting the Macintosh access files on its disks.? They avoided > mentioning what was inside the box, and presented it as a Macintosh > special external drive.?? (similar to the Macintosh version of Video > Toaster having an Amiga in the box) > They added software to it to handle some CP/M formats.? I was amused > that among the formats that they supported were a format where I had > misspeled the format name (due to customer handwriting), and they copied > my mispelling, and they had a format that I had put into XenoCopy for a > friend to handle his on-off prototype machine that never went to market. > (a non-deliberate Mountweazel poach flag copyright trap) > > > You could build a small box with a drive and either a from scratch > controller, or a 765 (or better yet, a WD 179x), that connects to PC. > In that box, you could put almost anything that could work with the FDC > and communicate. > > > But, as a first step, and "proof of concept" for an external box, why > not just start with a 5160 or 5170, running software and communicating > with your host PC?? Then, later, you could replace the 5160/5170 with a > more compact dedicated bespoke device. > > > (OK, I'm still thinking in terms of the days when people were upgrading > PCs and throwing out the old ones, so that an XT cost NOTHING) > Your right about all the available options. Somewhere around here I have a couple of P112 SBC's. I wonder what the floppy controller in that can do? I am pretty sure it claimed compatibility with CP/M 8" disks. If so it can probably handle all various 5.25" formats as well. Looks like I may have a number of things to play with while I spend my summer stuck in the house. bill From cclist at sydex.com Sat Apr 23 12:04:33 2022 From: cclist at sydex.com (Chuck Guzis) Date: Sat, 23 Apr 2022 10:04:33 -0700 Subject: PCI floppy controller In-Reply-To: References: <153b056d-a10e-f341-dd23-237a2be91852@sydex.com> Message-ID: On 4/23/22 07:16, Liam Proven wrote: > On Fri, 22 Apr 2022 at 23:41, Chuck Guzis wrote: >> >> Take a look at the chip (DP8473) datasheet. It boasts direct (no >> buffer needed) support of up to 4 drives. The rest is software; the >> protocol is pretty much write some registers before/after >> writing/reading to the buffer memory. In other words, it's a low-level >> interface protocol; there's really no intelligence in the unit. > > TBH, I wouldn't know. I'm a software type at best. Interesting info, though! An interesting aside is that on Adaptec and Future Domain SCSI ISA cards with the NS chip, it's quite possible to run an additional wire between the chip and the floppy header and get 3 floppies on a single cable. DTC and Ultrastor used the "twisty twisty" cable on their cards to do the same. There also was a DTC (ESDI or SCSI, I don't recall) ISA card that, with a jumper allowed one to run 4 floppies on single "flat" ribbon cable. Each drive had its own drive select (0,1,2,3) and all drive motors ran at the same time, but it worked. --Chuck From cisin at xenosoft.com Sat Apr 23 14:56:15 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Sat, 23 Apr 2022 12:56:15 -0700 (PDT) Subject: PCI floppy controller In-Reply-To: References: Message-ID: On Sat, 23 Apr 2022, Bill Gunshannon via cctalk wrote: > Your right about all the available options. Somewhere around here I > have a couple of P112 SBC's. I wonder what the floppy controller in > that can do? I am pretty sure it claimed compatibility with CP/M 8" > disks. If so it can probably handle all various 5.25" formats as well. > Looks like I may have a number of things to play with while I spend > my summer stuck in the house. Standard CP/M (8" SSSD) was FM at 250K data transfer rate Most designers of such made an effort to keep it versatile. Let's hope that they included MFM and data transfer rates of: 125K (5.25" single density (TRS80 model I and Early Osborne)) 250K 500K (8" double density and 3.5"/5.25" 'High' density) maybe even: 300K (5.25" 360K double density in a 360RPM 1.2M drive) 1000K (2.8M) From imp at bsdimp.com Sat Apr 23 16:12:59 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 23 Apr 2022 15:12:59 -0600 Subject: PCI floppy controller In-Reply-To: References: Message-ID: I'd gotten the impression that there was some angst in its community of users over something. I can't find now where I'd gotten that impression, though. Mine works great, and I've had no issues with it. They've been helpful when I've reported trouble I had using it, but it was pilot error on my part and they helped me understand what the reports and output of the tools were actually telling me. Warner On Sat, Apr 23, 2022 at 12:04 AM Tom Hunter wrote: > I am curious about your comment about "kryoflux going south". > I did not hear about any problems. Could you please elaborate? > I got mine about 2 or 3 years ago and it did everything I needed at the > time, but haven't used it since. > > Thanks > Tom > > > On Sat, Apr 23, 2022 at 9:19 AM Warner Losh via cctalk < > cctalk at classiccmp.org> wrote: > >> On Fri, Apr 22, 2022 at 7:07 PM Bill Gunshannon via cctalk < >> cctalk at classiccmp.org> wrote: >> >> > >> > As another person with a desire to be able to read/write/create >> > disks of different sizes and formats I have found this interesting. >> > >> > So the question, then.... >> > >> > How hard would it be to make a floppy disk interface using an Arduino >> > or even RasberryPi? If you could do that the choices of interface >> > to a PC opens up quite a bit. It would never be like having a floppy >> > hanging off the PC, but then none of the formats I am interested in >> > are grounded in the PC anyway and utilities would need to be written >> > to access them. >> > >> > comments? >> > >> >> Isn't that what Greaseweasel and similar do? I have a kyroflux that I use >> to read floppies on my macbook. It can write as well and understands a ton >> of formats. Greaseweasel is more available and supported (I got my >> kyroflux >> before things went south, so wouldn't recommend others get one these >> days). >> >> Warner >> > From bdweb at mindspring.com Sat Apr 23 23:11:28 2022 From: bdweb at mindspring.com (Bjoren Davis) Date: Sun, 24 Apr 2022 00:11:28 -0400 Subject: DEC RX50 mysterious 81st cylinder Message-ID: Hello Retroovers, Here's something interesting that Oleksii in Ukraine discovered. While playing with a Fluxengine, he found that some RX50s have data, stored in FM format, in a single sector the 81st track of the diskette. For fun I went through my collection of original DEC distribution diskettes for the DEC Professional, read the single sector and compared them. Here is what I found: Common data (locations with variations marked with __): 00:?? 46 4d 54 20 4d 46 4d 20 4e 4f 2f 46 43 20 31 2a?? |FMT MFM NO/FC 1*| 10:?? 31 30 2a 35 31 32 20 38 30 54 20 2d 44 45 43 20?? |10*512 80T -DEC | 20:?? 52 58 35 30 00 20 20 20 32 32 32 36 34 2d 32 33?? |RX50. 22264-23| 30:?? 20 20 __ __ 84 __ __ __ 20 46 01 f5 30 30 __ 30?? | __.___ F..00_0| 40:?? __ __ __ 20 20 20 20 20 20 20 20 20 20 20 20 20 |___???????????? | 50:?? 20 20 20 20 82 f1 c8 54 9a fd ce 57 9b 7d 0e b7?? | ...T...W.}..| 60:?? 6b 05 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |k.????????????? | 70:?? 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |??????????????? | Variations: ???????????????????????????? offset ?????????????? 32 33??? 35 36 37??? 3e??? 40 41 42 file?????????? ----------------------------------- BL-AI19C-BH??? 04 02??? 10 34 19??? 30??? 31 35 30 BL-CF74C-BH??? 03 26??? 00 01 36??? 30??? 30 39 30 BL-CF74C-BH??? 03 26??? 00 03 45??? 30??? 30 39 30 BL-CL73B-BH??? 11 10??? 00 53 44??? 30??? 30 37 31 BL-HC42A-BH??? 04 09??? 19 59 54??? 30??? 31 33 30 BL-HD04A-BH??? 01 21??? 17 26 09??? 30??? 31 34 30 BL-HD04B-BH??? 01 07??? 11 34 01??? 30??? 30 f3 31 BL-HD04B-BH??? 06 18??? 02 24 01??? 30??? 30 31 30 BL-HD05A-BH??? 01 22??? 02 33 40??? 30??? 32 30 31 BL-HD05B-BH??? 02 11??? 19 59 51??? 30??? 30 30 31 BL-HD05B-BH??? 02 11??? 20 00 55??? 30??? 30 30 31 BL-HD06A-BH??? 01 03??? 13 31 10??? 30??? 30 34 30 BL-HD06B-BH??? 06 18??? 05 08 58??? 30??? 30 35 31 BL-HD06B-BH??? 06 18??? 05 07 54??? 30??? 30 35 31 BL-HD07B-BH??? 06 18??? 01 42 23??? 30??? 31 38 30 BL-HD07B-BH??? 06 18??? 01 43 28??? 30??? 31 38 30 BL-HD07B-BH??? 01 07??? 12 22 22??? 30??? 30 f3 31 BL-HD08B-BH??? 01 07??? 13 51 38??? 30??? 30 f3 30 BL-HD08B-BH??? 01 19??? 12 45 32??? 30??? 31 38 30 BL-HD08B-BH??? 01 07??? 13 52 42??? 30??? 30 f3 30 BL-HD09B-BH??? 01 07??? 13 05 38??? 30??? 30 f3 31 BL-HD09B-BH??? 01 17??? 05 34 48??? 30??? 31 39 30 BL-HD09B-BH??? 01 07??? 13 04 33??? 30??? 30 f3 31 BL-HD10B-BH??? 06 18??? 09 43 45??? 30??? 30 35 30 BL-HD10B-BH??? 06 18??? 05 45 16??? 30??? 31 39 30 BL-HD10B-BH??? 01 20??? 19 22 06??? 30??? 30 30 31 BL-HD11B-BH??? 01 17??? 06 05 36??? 30??? 30 31 31 BL-HD11B-BH??? 01 17??? 06 06 41??? 30??? 30 31 31 BL-JB90B-BH??? 06 17??? 14 45 00??? 30??? 31 31 30 BL-JB90B-BH??? 06 18??? 12 29 42??? 30??? 32 30 30 BL-JB90B-BH??? 06 17??? 14 46 03??? 30??? 31 31 30 BL-JB91B-BH??? 06 18??? 12 43 59??? 30??? 30 39 30 BL-JB91B-BH??? 01 13??? 12 01 21??? 30??? 30 30 30 BL-JB92B-BH??? 01 15??? 16 03 31??? 30??? 30 36 30 BL-KS73A-BH??? 06 04??? 09 36 40??? 30??? 30 30 30 BL-N596F-BH??? 01 03??? 10 09 00??? 30??? 31 31 30 BL-N596G-BH??? 07 03??? 18 02 08??? 34??? 39 36 31 BL-N605G-BH??? 02 13??? 01 12 58??? 30??? 32 30 31 BL-N631H-BH??? 12 16??? 15 41 36??? 30??? 31 33 30 BL-N631I-BH??? 01 19??? 10 28 32??? 30??? 30 35 30 BL-N633G-BH??? 12 11??? 03 48 40??? 30??? 30 32 30 BL-N633H-BH??? 03 05??? 14 21 50??? 30??? 30 33 30 BL-N634G-BH??? 07 03??? 17 00 26??? 30??? 30 31 30 BL-N638F-BH??? 12 05??? 19 13 38??? 30??? 31 32 31 BL-N639H-BH??? 03 26??? 02 32 50??? 30??? 30 39 30 BL-N640G-BH??? 03 26??? 00 59 57??? 30??? 30 31 30 BL-N640G-BH??? 03 26??? 04 41 36??? 30??? 30 34 30 BL-V444B-BH??? 12 13??? 02 51 00??? 30??? 31 34 30 BL-Y472B-BH??? 03 20??? 08 21 38??? 30??? 31 32 31 BL-Y982D-BH??? 03 05??? 20 02 57??? 30??? 31 39 30 BL-Y982D-BH??? 07 03??? 15 48 31??? 30??? 30 37 31 BL-Z934D-BH??? 04 10??? 04 16 13??? 30??? 30 33 30 ----------- ??????? MIN??? 01 02??? 00 00 00??? 30??? 30 30 30 ??????? MAX??? 12 26??? 20 59 59??? 34??? 39 f3 31 ????? NVALS??? 08 12??? 14 22 21??? 02??? 04 0b 02 ???????? OR??? 17 3f??? 3f 7f 7f??? 34??? 3b ff 31 ??????? AND??? 00 00??? 00 00 00??? 30??? 30 30 30 Key MIN?? is the minimum value seen MAX?? is the maximum value seen NVALS is the count of unique values seen OR??? values have a 1 for every bit that is ever 1 AND?? values have a 1 for every bit that is always 1 ---- Some interesting things to note: * only some diskettes have 81st cylinder data.? They tend to be the later releases (1985 and later).? (My table simply omits those diskettes I have without 81st cylinder data). * different copies of the same diskette (e.g., BL-HD11B-BH) have slightly different values, so it doesn't appear that these value encode some kind of master ID. * the values at offsets 0x32, 0x33, 0x35, 0x36, 0x37 appear to be BCD-encoded month, day-of-month, hour (0..23), minute, and second.? Logically, this would mean that the value at 0x34 should be the BCD-encoded year, but it's always 0x84, and most of these diskettes were released well after 1984. * the values at 0x30, 0x40, 0x41, 0x42 are ASCII decimal digits to complete the string "00_0___", except the value at 0x41 is sometimes 0xf3. * the textual data at the beginning seem obvious enough: "FMT MFM" means MFM-encoded data; "1*10*512" is 1 head, 10 sectors/track, 512 bytes/sector; "80T" means 80 tracks; "DEC RX50" means what it says.? But what does "NO/FC" mean?? And what about "22264-23"? Does anyone know anything about this?? Is it also present on VAX/PDP-11/Rainbow RX50 diskettes?? I'd be very curious to know. Oh, and before anyone asks: yes, I'm planning on putting up images of these diskettes onto archive.org.? An interesting corollary question: should those images somehow include this information, and, if so, how (because as far as I know the DEC Professional floppy controller is incapable of reading these data)? Thanks. --Bjoren From imp at bsdimp.com Sat Apr 23 23:18:59 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 23 Apr 2022 22:18:59 -0600 Subject: DEC RX50 mysterious 81st cylinder In-Reply-To: References: Message-ID: On Sat, Apr 23, 2022, 10:11 PM Bjoren Davis via cctalk < cctalk at classiccmp.org> wrote: > Hello Retroovers, > > Here's something interesting that Oleksii in Ukraine discovered. > > While playing with a Fluxengine, he found that some RX50s have data, > stored in FM format, in a single sector the 81st track of the diskette. > > For fun I went through my collection of original DEC distribution > diskettes for the DEC Professional, read the single sector and compared > them. > > Here is what I found: > > Common data (locations with variations marked with __): > 00: 46 4d 54 20 4d 46 4d 20 4e 4f 2f 46 43 20 31 2a |FMT MFM NO/FC 1*| > 10: 31 30 2a 35 31 32 20 38 30 54 20 2d 44 45 43 20 |10*512 80T -DEC | > 20: 52 58 35 30 00 20 20 20 32 32 32 36 34 2d 32 33 |RX50. 22264-23| > 30: 20 20 __ __ 84 __ __ __ 20 46 01 f5 30 30 __ 30 | __.___ F..00_0| > 40: __ __ __ 20 20 20 20 20 20 20 20 20 20 20 20 20 |___ | > 50: 20 20 20 20 82 f1 c8 54 9a fd ce 57 9b 7d 0e b7 | ...T...W.}..| > 60: 6b 05 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |k. | > 70: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | > > Variations: > offset > 32 33 35 36 37 3e 40 41 42 > file ----------------------------------- > BL-AI19C-BH 04 02 10 34 19 30 31 35 30 > BL-CF74C-BH 03 26 00 01 36 30 30 39 30 > BL-CF74C-BH 03 26 00 03 45 30 30 39 30 > BL-CL73B-BH 11 10 00 53 44 30 30 37 31 > BL-HC42A-BH 04 09 19 59 54 30 31 33 30 > BL-HD04A-BH 01 21 17 26 09 30 31 34 30 > BL-HD04B-BH 01 07 11 34 01 30 30 f3 31 > BL-HD04B-BH 06 18 02 24 01 30 30 31 30 > BL-HD05A-BH 01 22 02 33 40 30 32 30 31 > BL-HD05B-BH 02 11 19 59 51 30 30 30 31 > BL-HD05B-BH 02 11 20 00 55 30 30 30 31 > BL-HD06A-BH 01 03 13 31 10 30 30 34 30 > BL-HD06B-BH 06 18 05 08 58 30 30 35 31 > BL-HD06B-BH 06 18 05 07 54 30 30 35 31 > BL-HD07B-BH 06 18 01 42 23 30 31 38 30 > BL-HD07B-BH 06 18 01 43 28 30 31 38 30 > BL-HD07B-BH 01 07 12 22 22 30 30 f3 31 > BL-HD08B-BH 01 07 13 51 38 30 30 f3 30 > BL-HD08B-BH 01 19 12 45 32 30 31 38 30 > BL-HD08B-BH 01 07 13 52 42 30 30 f3 30 > BL-HD09B-BH 01 07 13 05 38 30 30 f3 31 > BL-HD09B-BH 01 17 05 34 48 30 31 39 30 > BL-HD09B-BH 01 07 13 04 33 30 30 f3 31 > BL-HD10B-BH 06 18 09 43 45 30 30 35 30 > BL-HD10B-BH 06 18 05 45 16 30 31 39 30 > BL-HD10B-BH 01 20 19 22 06 30 30 30 31 > BL-HD11B-BH 01 17 06 05 36 30 30 31 31 > BL-HD11B-BH 01 17 06 06 41 30 30 31 31 > BL-JB90B-BH 06 17 14 45 00 30 31 31 30 > BL-JB90B-BH 06 18 12 29 42 30 32 30 30 > BL-JB90B-BH 06 17 14 46 03 30 31 31 30 > BL-JB91B-BH 06 18 12 43 59 30 30 39 30 > BL-JB91B-BH 01 13 12 01 21 30 30 30 30 > BL-JB92B-BH 01 15 16 03 31 30 30 36 30 > BL-KS73A-BH 06 04 09 36 40 30 30 30 30 > BL-N596F-BH 01 03 10 09 00 30 31 31 30 > BL-N596G-BH 07 03 18 02 08 34 39 36 31 > BL-N605G-BH 02 13 01 12 58 30 32 30 31 > BL-N631H-BH 12 16 15 41 36 30 31 33 30 > BL-N631I-BH 01 19 10 28 32 30 30 35 30 > BL-N633G-BH 12 11 03 48 40 30 30 32 30 > BL-N633H-BH 03 05 14 21 50 30 30 33 30 > BL-N634G-BH 07 03 17 00 26 30 30 31 30 > BL-N638F-BH 12 05 19 13 38 30 31 32 31 > BL-N639H-BH 03 26 02 32 50 30 30 39 30 > BL-N640G-BH 03 26 00 59 57 30 30 31 30 > BL-N640G-BH 03 26 04 41 36 30 30 34 30 > BL-V444B-BH 12 13 02 51 00 30 31 34 30 > BL-Y472B-BH 03 20 08 21 38 30 31 32 31 > BL-Y982D-BH 03 05 20 02 57 30 31 39 30 > BL-Y982D-BH 07 03 15 48 31 30 30 37 31 > BL-Z934D-BH 04 10 04 16 13 30 30 33 30 > ----------- > MIN 01 02 00 00 00 30 30 30 30 > MAX 12 26 20 59 59 34 39 f3 31 > NVALS 08 12 14 22 21 02 04 0b 02 > OR 17 3f 3f 7f 7f 34 3b ff 31 > AND 00 00 00 00 00 30 30 30 30 > > > Key > MIN is the minimum value seen > MAX is the maximum value seen > NVALS is the count of unique values seen > OR values have a 1 for every bit that is ever 1 > AND values have a 1 for every bit that is always 1 > > ---- > > Some interesting things to note: > > * only some diskettes have 81st cylinder data. They tend to be the > later releases (1985 and later). (My table simply omits those > diskettes I have without 81st cylinder data). > * different copies of the same diskette (e.g., BL-HD11B-BH) have > slightly different values, so it doesn't appear that these value > encode some kind of master ID. > * the values at offsets 0x32, 0x33, 0x35, 0x36, 0x37 appear to be > BCD-encoded month, day-of-month, hour (0..23), minute, and second. > Logically, this would mean that the value at 0x34 should be the > BCD-encoded year, but it's always 0x84, and most of these diskettes > were released well after 1984. > * the values at 0x30, 0x40, 0x41, 0x42 are ASCII decimal digits to > complete the string "00_0___", except the value at 0x41 is sometimes > 0xf3. > * the textual data at the beginning seem obvious enough: "FMT MFM" > means MFM-encoded data; "1*10*512" is 1 head, 10 sectors/track, 512 > bytes/sector; "80T" means 80 tracks; "DEC RX50" means what it says. > But what does "NO/FC" mean? And what about "22264-23"? > This doesn't match the Rainbow's hard disk partition tables, fwiw. Does anyone know anything about this? Is it also present on > VAX/PDP-11/Rainbow RX50 diskettes? I'd be very curious to know. > I'll have to check next time I image my Rainbow disks.. I don't recall seeing this in previous runs though... Warner Oh, and before anyone asks: yes, I'm planning on putting up images of > these diskettes onto archive.org. An interesting corollary question: > should those images somehow include this information, and, if so, how > (because as far as I know the DEC Professional floppy controller is > incapable of reading these data)? > > Thanks. > > --Bjoren > > From ard.p850ug1 at gmail.com Sat Apr 23 23:57:34 2022 From: ard.p850ug1 at gmail.com (Tony Duell) Date: Sun, 24 Apr 2022 05:57:34 +0100 Subject: Intel VS Motorola (Was: interesting DEC Pro stuff on eBay In-Reply-To: References: <20220421184752.37C124E679@mx2.ezwind.net> <9DFB5BC6-CC37-46EC-8C9F-07ACD715CC09@comcast.net> Message-ID: On Thu, Apr 21, 2022 at 11:14 PM Fred Cisin via cctalk wrote: > > On Thu, 21 Apr 2022, Mike Katz via cctalk wrote: > > Intel has never understood interrupts or good cpu architecture. > > Look at the segment:offset architecture of the 8086 and of course it's single > > interrupt (without the separate interrupt controller chip) vs the 68000 > > somewhat orthogonal 32 bit architecture and 256 interrupts with 8 levels > > built into the chip. > > I could spend pages just describing how the 68K chip just blows away the 8086 > > considering they were both released at about the same time. > > For crying out loud the 6809 even though it only addresses 64K is a more > > powerful processor than the 8086. Even with the 8086 clocking faster than > > the 6809. > > The over-simplification that I gave my beginning students: > > Intel's chip design technique was to add features to the currect chip to IMHO Intel never designed a chip that did not have bugs/misfeatures! They must be the only company that mangled the design of a parallel port chip -- the 8255 has the interesting 'feature' that writing to the mode control register will clear all output lines to 0. Think about that. After a reset all ports are set to be inputs. That makes sense, if they were outputs a port line could contend with something that expects it to be an input and is trying to drive it. So the port lines are effecrively floating. A TTL input connected to one (which will be driven by that port line used as an output) will float high, And of course it's a lot easier to pull a TTL input high than to pull it low if you want to do things properly. You write to the mode register to make some ports outputs. Those lines now all go low, pulling any TTL inputs driven by them low. You now write to the apporpriate port lines to make them high again, perhaps. But there's still that little glitch when the line has gone low. Better to either leave the port lines unaffected by a write to the mode register (so you can pre-set them to 1's if you want to) or at least force them high on such a write. ARGH!!! > > > On the other hand, Motorola did not modify their chips for the next major > one. Instead, they redesigned from scratch. It took a little longer, and > all software had to be rewritten, but they consistently ended up with THE > BEST chip ("ichiban"). > > The 6809 was THE BEST 8 bit processor. But, marketing?? > They handed it to Radio Shack who decided it would be a cartridge based > home games machine, with chiclet keyboard, RF [ONLY] video, and minimal > expansion capability. Users hacked around those limitations. That is a very unfair comment. The design of the CoCo owes a lot to the 6883 SAM chip, or perhaps the 6809E/6883/6847 'chipset'. There is a Motorola application note showing how to use those 3 chips together (along with ROM, RAM, etc) and both the CoCo and the Dragon were based on that. Radio Shack did get one thing right. They chose OS-9 rather than Flex. OS-9 is a very elegant multi-tasking system. Flex is much the same as CP/M and wastes the 6809. I often wish that the BBC Micro has been 6809-based, the 6502 is the only let-down in the design of that machine. Acorn did make a 6809 CPU board for their Eurocard rack systems, I have no idea if it pre-dated the BBC micro though. And Acorn, for some unknown reason, used Flex. IMHO what killed the 6809 was that it came out rather too late and there was no 'normal' application software for it. No word processor or spreadsheet. As a result desktop computers using it were uncommon. But it turns up all over the place in embedded systems. Those HP disk and tape units, both the HPIB ones like the 9133 and the HPIL one, 9114. Almost all have a 6809 inside (the exception is the 9145 tape drive which has a 68000). The HP1630 logic analyser, again there's a 6809 in there, along with the 6829 MMU chip. I've just repaired a bit of lab equipment with a 6809 in it. Got a monochrome graphics terminal here made by Pericom. Graphics use a 7220 chip, but overall there's a 6809 to control it. -tony From cruff at ruffspot.net Sat Apr 23 14:06:09 2022 From: cruff at ruffspot.net (Craig Ruff) Date: Sat, 23 Apr 2022 13:06:09 -0600 Subject: P112 Floppy Controller In-Reply-To: References: Message-ID: The P112's floppy controller is the one in the SMSC FDC37C665IR SuperIO chip. The data sheet states it is a 2.88 MB "Licensed CMOS 765B Floppy Disk Controller" and claims 100% IBM compatibility (for what that's worth). From cisin at xenosoft.com Sat Apr 23 15:12:20 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Sat, 23 Apr 2022 13:12:20 -0700 (PDT) Subject: P112 Floppy Controller In-Reply-To: References: Message-ID: On Sat, 23 Apr 2022, Craig Ruff via cctech wrote: > The P112's floppy controller is the one in the SMSC FDC37C665IR SuperIO > chip. The data sheet states it is a 2.88 MB "Licensed CMOS 765B Floppy > Disk Controller" and claims 100% IBM compatibility (for what that's > worth). 2.8M (it is not "2.88" unless MB is 1024,000) means that it includes a 1000K data transfer rate 765B means essentially the same FDC as PC (NEC 765 based) Does it also support FM? 125K data transfer rate (TRS80, Early Osborne) From cclist at sydex.com Sun Apr 24 01:29:13 2022 From: cclist at sydex.com (Chuck Guzis) Date: Sat, 23 Apr 2022 23:29:13 -0700 Subject: P112 Floppy Controller In-Reply-To: References: Message-ID: On 4/23/22 13:12, Fred Cisin via cctalk wrote: > On Sat, 23 Apr 2022, Craig Ruff via cctech wrote: >> The P112's floppy controller is the one in the SMSC FDC37C665IR >> SuperIO chip. The data sheet states it is a 2.88 MB "Licensed CMOS >> 765B Floppy Disk Controller" and claims 100% IBM compatibility (for >> what that's worth). > > 2.8M (it is not "2.88" unless MB is 1024,000) means that it includes a > 1000K data transfer rate > > 765B means essentially the same FDC as PC (NEC 765 based) > I think I've got the SMSC Super I/O in one of my systems. Recollection is that it does FM just fine. From bill.gunshannon at hotmail.com Mon Apr 25 19:31:43 2022 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 25 Apr 2022 20:31:43 -0400 Subject: Yet another TRS-80 question Message-ID: Has anyone ever seen a TRSDOS equivalent of the CP/M LOAD command? I have the PL/M-80 compiler running but it's output is an Intel HEX File. Works great for CP/M but I would really like to try some programs under TRSDOS. The only other option at this point would be to dis-assemble the HEX File and then re-assemble the program after a little massaging to make it match one of the TRSDOS assembler programs. bill From jules.richardson99 at gmail.com Mon Apr 25 20:08:03 2022 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 25 Apr 2022 20:08:03 -0500 Subject: BASIC environment ending with "run complete", and slashed 'O' characters? Message-ID: Perhaps a long shot, but I've got an old piece of paper here showing a BASIC listing followed by a program run where the BASIC environment terminates with "run complete" - does that behavior ring any bells with anyone? I'm mildly curious what machine it may have come from. The other interesting thing is that the output is from a teletype and the zero characters appear with no slash, while the uppercase 'O' characters do have a diagonal slash through them (e.g. the 'run complete' mentioned above comes out as 'RUN C0MPLETE') - certainly not unheard of, but I think doing the opposite had become typical practice by what, very early 1970s? At the top of the page there is a paragraph as follows (all in uppercase on the printout, obviously, and with slashed 'O' characters): "The following output is an example of BASIC language and the resulting run of a program. A punched paper tape of the program is included in the kit. This output was produced on a teletype." I don't know if that means anything to anyone? I have no idea what "the kit" was but am guessing that the printout I have was once part of some kind of educational material. I do have another printout from the MECC timeshare system (dated 78/9/1) which may have originated with the same teletype - it's different paper stock, but has the same slashed 'O' characters. The welcome message on that says 'Kronos 2.12-439', if that's meaningful... cheers Jules From c.murray.mccullough at gmail.com Mon Apr 25 21:08:28 2022 From: c.murray.mccullough at gmail.com (Murray McCullough) Date: Mon, 25 Apr 2022 22:08:28 -0400 Subject: Classic computer from Britain(Europe) Message-ID: For British microcomputer fans the famous SInclair ZX Spectrum came into existence 40 years ago this month: A worthy successor to the Sinclair ZX81. It was the Apple II of Europe. Happy computing! Murray ? From raymond.wiker at icloud.com Tue Apr 26 02:05:50 2022 From: raymond.wiker at icloud.com (Raymond Wiker) Date: Tue, 26 Apr 2022 09:05:50 +0200 Subject: BASIC environment ending with "run complete", and slashed 'O' characters? In-Reply-To: References: Message-ID: <73C1A9DF-519F-4418-8066-B7D4AF734E97@icloud.com> https://en.wikipedia.org/wiki/CDC_Kronos , perhaps? > On 26 Apr 2022, at 03:08, Jules Richardson via cctalk wrote: > > > Perhaps a long shot, but I've got an old piece of paper here showing a BASIC listing followed by a program run where the BASIC environment terminates with "run complete" - does that behavior ring any bells with anyone? I'm mildly curious what machine it may have come from. > > The other interesting thing is that the output is from a teletype and the zero characters appear with no slash, while the uppercase 'O' characters do have a diagonal slash through them (e.g. the 'run complete' mentioned above comes out as 'RUN C0MPLETE') - certainly not unheard of, but I think doing the opposite had become typical practice by what, very early 1970s? > > At the top of the page there is a paragraph as follows (all in uppercase on the printout, obviously, and with slashed 'O' characters): > > "The following output is an example of BASIC language and the resulting run of a program. A punched paper tape of the program is included in the kit. This output was produced on a teletype." > > I don't know if that means anything to anyone? I have no idea what "the kit" was but am guessing that the printout I have was once part of some kind of educational material. > > I do have another printout from the MECC timeshare system (dated 78/9/1) which may have originated with the same teletype - it's different paper stock, but has the same slashed 'O' characters. The welcome message on that says 'Kronos 2.12-439', if that's meaningful... > > cheers > > Jules > From jules.richardson99 at gmail.com Tue Apr 26 06:29:42 2022 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Tue, 26 Apr 2022 06:29:42 -0500 Subject: BASIC environment ending with "run complete", and slashed 'O' characters? In-Reply-To: <73C1A9DF-519F-4418-8066-B7D4AF734E97@icloud.com> References: <73C1A9DF-519F-4418-8066-B7D4AF734E97@icloud.com> Message-ID: <818e967f-bee0-7d96-7057-38ce96b381a2@gmail.com> On 4/26/22 02:05, Raymond Wiker wrote: > https://en.wikipedia.org/wiki/CDC_Kronos > , perhaps? Could well be, given the MECC / Minnesota / Cray connections. Question then is whether the CDC 6000 series (or later) machines had a BASIC environment that terminated runs with the 'run complete' message. (oddly I never saw my post make it to the list, so assumed it was down or the message had got caught somewhere. Evidently it did make it though and for some reason my 'list copy' of it never made it back to me) Jules From pat at vax11.net Tue Apr 26 08:51:27 2022 From: pat at vax11.net (Patrick Finnegan) Date: Tue, 26 Apr 2022 09:51:27 -0400 Subject: BASIC environment ending with "run complete", and slashed 'O' characters? In-Reply-To: <818e967f-bee0-7d96-7057-38ce96b381a2@gmail.com> References: <73C1A9DF-519F-4418-8066-B7D4AF734E97@icloud.com> <818e967f-bee0-7d96-7057-38ce96b381a2@gmail.com> Message-ID: On Tue, Apr 26, 2022, 07:29 Jules Richardson via cctalk < cctalk at classiccmp.org> wrote: > > (oddly I never saw my post make it to the list, so assumed it was down or > the message had got caught somewhere. Evidently it did make it though and > for some reason my 'list copy' of it never made it back to me) > Gmail filters out "duplicate" messages, which is why you didn't see a copy. Pat > From ccth6600 at gmail.com Tue Apr 26 09:19:01 2022 From: ccth6600 at gmail.com (Tom Hunter) Date: Tue, 26 Apr 2022 22:19:01 +0800 Subject: BASIC environment ending with "run complete", and slashed 'O' characters? In-Reply-To: <818e967f-bee0-7d96-7057-38ce96b381a2@gmail.com> References: <73C1A9DF-519F-4418-8066-B7D4AF734E97@icloud.com> <818e967f-bee0-7d96-7057-38ce96b381a2@gmail.com> Message-ID: Yes - CDC 6000 and CYBER series machines running BASIC 2.1 (and all later versions) under KRONOS and NOS output "RUN COMPLETE." when the user program finished. Tom On Tue, Apr 26, 2022 at 7:29 PM Jules Richardson via cctalk < cctalk at classiccmp.org> wrote: > On 4/26/22 02:05, Raymond Wiker wrote: > > https://en.wikipedia.org/wiki/CDC_Kronos > > , perhaps? > > Could well be, given the MECC / Minnesota / Cray connections. Question > then > is whether the CDC 6000 series (or later) machines had a BASIC environment > that terminated runs with the 'run complete' message. > > (oddly I never saw my post make it to the list, so assumed it was down or > the message had got caught somewhere. Evidently it did make it though and > for some reason my 'list copy' of it never made it back to me) > > Jules > From paulkoning at comcast.net Tue Apr 26 09:24:15 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 26 Apr 2022 10:24:15 -0400 Subject: BASIC environment ending with "run complete", and slashed 'O' characters? In-Reply-To: <73C1A9DF-519F-4418-8066-B7D4AF734E97@icloud.com> References: <73C1A9DF-519F-4418-8066-B7D4AF734E97@icloud.com> Message-ID: <0EA5E93C-F670-4BDC-A751-3388753E85AD@comcast.net> Apparently so. The word from a CDC experts list is that the "run complete" message is not from BASIC itself (which is indeed a CDC product) but rather from the time sharing executive, called TELEX in KRONOS and early NOS, and IAF in later versions of NOS. As for the slashed letter O, that's strange. Certainly it is not CDC practice; the only place I ever ran into this is with IBM, I always considered it an example of IBM doing things the weird way. So it sounds like whoever bought those Teletype machines had them configured in that non-standard way for some reason. Normal, as far as I know, was slashed digit zero. MECC is a U. Minnesota KRONOS/NOS system with a bunch of local mods, but BASIC and TELEX are both part of the base system as supplied by CDC. paul > On Apr 26, 2022, at 3:05 AM, Raymond Wiker via cctalk wrote: > > https://en.wikipedia.org/wiki/CDC_Kronos , perhaps? > >> On 26 Apr 2022, at 03:08, Jules Richardson via cctalk wrote: >> >> >> Perhaps a long shot, but I've got an old piece of paper here showing a BASIC listing followed by a program run where the BASIC environment terminates with "run complete" - does that behavior ring any bells with anyone? I'm mildly curious what machine it may have come from. >> >> The other interesting thing is that the output is from a teletype and the zero characters appear with no slash, while the uppercase 'O' characters do have a diagonal slash through them (e.g. the 'run complete' mentioned above comes out as 'RUN C0MPLETE') - certainly not unheard of, but I think doing the opposite had become typical practice by what, very early 1970s? >> >> At the top of the page there is a paragraph as follows (all in uppercase on the printout, obviously, and with slashed 'O' characters): >> >> "The following output is an example of BASIC language and the resulting run of a program. A punched paper tape of the program is included in the kit. This output was produced on a teletype." >> >> I don't know if that means anything to anyone? I have no idea what "the kit" was but am guessing that the printout I have was once part of some kind of educational material. >> >> I do have another printout from the MECC timeshare system (dated 78/9/1) which may have originated with the same teletype - it's different paper stock, but has the same slashed 'O' characters. The welcome message on that says 'Kronos 2.12-439', if that's meaningful... >> >> cheers >> >> Jules >> > From bbrown314 at comcast.net Tue Apr 26 09:43:02 2022 From: bbrown314 at comcast.net (Bob4schoolboard94) Date: Tue, 26 Apr 2022 09:43:02 -0500 Subject: BASIC environment ending with "run complete", and slashed 'O' characters? In-Reply-To: <0EA5E93C-F670-4BDC-A751-3388753E85AD@comcast.net> References: <0EA5E93C-F670-4BDC-A751-3388753E85AD@comcast.net> Message-ID: I used to use some tty33?s in the 70s which were used to connect to an hp2000 timeshared system. Those tty?s had the slash O and non-slash zero that you describe. It may have been a common tty33 configuration. -Bob > On Apr 26, 2022, at 9:24 AM, Paul Koning via cctalk wrote: > > ?Apparently so. The word from a CDC experts list is that the "run complete" message is not from BASIC itself (which is indeed a CDC product) but rather from the time sharing executive, called TELEX in KRONOS and early NOS, and IAF in later versions of NOS. > > As for the slashed letter O, that's strange. Certainly it is not CDC practice; the only place I ever ran into this is with IBM, I always considered it an example of IBM doing things the weird way. So it sounds like whoever bought those Teletype machines had them configured in that non-standard way for some reason. Normal, as far as I know, was slashed digit zero. > > MECC is a U. Minnesota KRONOS/NOS system with a bunch of local mods, but BASIC and TELEX are both part of the base system as supplied by CDC. > > paul > >> On Apr 26, 2022, at 3:05 AM, Raymond Wiker via cctalk wrote: >> >> https://en.wikipedia.org/wiki/CDC_Kronos , perhaps? >> >>>> On 26 Apr 2022, at 03:08, Jules Richardson via cctalk wrote: >>> >>> >>> Perhaps a long shot, but I've got an old piece of paper here showing a BASIC listing followed by a program run where the BASIC environment terminates with "run complete" - does that behavior ring any bells with anyone? I'm mildly curious what machine it may have come from. >>> >>> The other interesting thing is that the output is from a teletype and the zero characters appear with no slash, while the uppercase 'O' characters do have a diagonal slash through them (e.g. the 'run complete' mentioned above comes out as 'RUN C0MPLETE') - certainly not unheard of, but I think doing the opposite had become typical practice by what, very early 1970s? >>> >>> At the top of the page there is a paragraph as follows (all in uppercase on the printout, obviously, and with slashed 'O' characters): >>> >>> "The following output is an example of BASIC language and the resulting run of a program. A punched paper tape of the program is included in the kit. This output was produced on a teletype." >>> >>> I don't know if that means anything to anyone? I have no idea what "the kit" was but am guessing that the printout I have was once part of some kind of educational material. >>> >>> I do have another printout from the MECC timeshare system (dated 78/9/1) which may have originated with the same teletype - it's different paper stock, but has the same slashed 'O' characters. The welcome message on that says 'Kronos 2.12-439', if that's meaningful... >>> >>> cheers >>> >>> Jules >>> >> > From tshoppa at wmata.com Tue Apr 26 12:25:16 2022 From: tshoppa at wmata.com (Shoppa, Tim) Date: Tue, 26 Apr 2022 17:25:16 +0000 Subject: Slashed letter O, unslashed letter zero Message-ID: Paul writes: > As for the slashed letter O, that's strange. Certainly it is not CDC practice; the only place I ever ran into this is with IBM, I always considered it an example of IBM doing > things the weird way. So it sounds like whoever bought those Teletype machines had them configured in that non-standard way for some reason. Normal, as far as I know, was slashed digit zero. Slashed letter O, unslashed zero was by far the most common configuration for Model 33 Teletypes sold/leased through Telex / Dataphone providers. My surplus TTY experience from the early 1980's heavily turned up Model 33's with slashed letter O's. If you bought a Model 33 through DEC, it almost certainly would've come with a slashed zero and unslashed letter O. I'm 99% sure I've seen a listing of various Model 33 type-cylinder choices on some greenkeys site. Maybe it's in one of my paper Teletype manuals. Most are at least related to ASCII but there were a handful that were really "out there" (weather symbols, etc.) and seemed to have nothing to do with ASCII except they skipped the first 32 characters as unprintables. This website has a history of slashing the letter O (and also ticked, center-dotted, etc.) oriented around computing: https://circuitousroot.com/artifice/letters/characters/slashed-o/index.html Tim N3QE From imp at bsdimp.com Tue Apr 26 12:48:23 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 26 Apr 2022 11:48:23 -0600 Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: Message-ID: On Tue, Apr 26, 2022 at 11:25 AM Shoppa, Tim via cctalk < cctalk at classiccmp.org> wrote: > This website has a history of slashing the letter O (and also ticked, > center-dotted, etc.) oriented around computing: > https://circuitousroot.com/artifice/letters/characters/slashed-o/index.html Now I understand... For me, who started coding in the late 70s, it was always the number 0 that was slashed, dotted, or otherwise made to look 'odd', never the letter o. Warner From cclist at sydex.com Tue Apr 26 13:18:21 2022 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 26 Apr 2022 11:18:21 -0700 Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: Message-ID: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> On 4/26/22 10:48, Warner Losh via cctalk wrote: > On Tue, Apr 26, 2022 at 11:25 AM Shoppa, Tim via cctalk < > cctalk at classiccmp.org> wrote: > >> This website has a history of slashing the letter O (and also ticked, >> center-dotted, etc.) oriented around computing: >> https://circuitousroot.com/artifice/letters/characters/slashed-o/index.html > > > Now I understand... > > For me, who started coding in the late 70s, it was always the number 0 that > was slashed, dotted, or otherwise made to look 'odd', never the letter o. I recall getting a job back from keypunch with a note attached: "I wasn't sure if you meant zero or oh (I always slashed my zeroes; the keypunch form specifically called that out), so I did some of both". Card deck into trash; go find a keypunch and do the stuff myself. Management had this diktat that programmers were permitted to punch only a few cards at a time; the time to punch a full deck cost the company too much and so should be sent to keypunch. Obviously, management never had to work with the output of the keypunch pool... --Chuck From cisin at xenosoft.com Tue Apr 26 14:44:30 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 26 Apr 2022 12:44:30 -0700 (PDT) Subject: Slashed letter O, unslashed letter zero In-Reply-To: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> Message-ID: On Tue, 26 Apr 2022, Chuck Guzis via cctalk wrote: > I recall getting a job back from keypunch with a note attached: "I > wasn't sure if you meant zero or oh (I always slashed my zeroes; the > keypunch form specifically called that out), so I did some of both". > > Card deck into trash; go find a keypunch and do the stuff myself. > > Management had this diktat that programmers were permitted to punch only > a few cards at a time; the time to punch a full deck cost the company > too much and so should be sent to keypunch. Obviously, management > never had to work with the output of the keypunch pool... "You can make a few corrections, but no punching whole jobs." One of my cow-orkers, a programmer, insisted that it was much faster for him to type as he composed, even on a 026, than it was to write on coding sheets, and then hand it off. Management responded, "POLICY." He held up a single blank card, and asked, "Is it OK for me to type the corrections, of a few dozen cards to be inserted in this deck?" Management responded, "ANYBODY WHO KEYPUNCHES WILL BE PAID KEYPUNCHER PAY!" So, he handed me the card, and said, "Here, you could use a raise." (I was a "Data Technician", which was a euphemism for Go-fer entry level job) It was a truly trivial FORTRAN task that was well within my capabilities at the time. (Prior to that job, I had been doing temp work around town keypunching.) While they were still giving him a hard time, I went to the next room, punched a dozen cards and brought them back. "Would it be OK if we just did a printout of the deck and handed in THAT, instead of coding sheets?" We did have one old-timer who slashed letter O. We talked to the keypunchers, and solved it by a discussion, and having him put his name in red LARGE on every sheet. -- Grumpy Ol' Fred cisin at xenosoft.com From fjkraan at electrickery.nl Tue Apr 26 14:25:15 2022 From: fjkraan at electrickery.nl (Fred Jan Kraan) Date: Tue, 26 Apr 2022 21:25:15 +0200 Subject: Yet another TRS-80 question In-Reply-To: References: Message-ID: <0e6ddaab-09a8-c38a-a3c2-4a711dbe9b2a@electrickery.nl> On 4/26/22 7:00 PM, Bill Gunshannon wrote: > Has anyone ever seen a TRSDOS equivalent of the CP/M LOAD > command?? I have the PL/M-80 compiler running but it's > output is an Intel HEX File. Works great for CP/M but I > would really like to try some programs under TRSDOS.? The > only other option at this point would be to dis-assemble > the HEX File and then re-assemble the program after a > little massaging to make it match one of the TRSDOS > assembler programs. For my Model 4p serial boot demo, I wrote just that program in Python. https://github.com/electrickery/SerialBoot. It converts from hex-intel to an intermediate ASCII presentation of an LMF-file. This is somewhat useful, as you have to provide the entry address manually. The conversion to a real binary file is trival, but not yet there (had no need for it myself). > > bill Greetings, Fred Jan From gavin at learn.bio Tue Apr 26 15:01:21 2022 From: gavin at learn.bio (Gavin Scott) Date: Tue, 26 Apr 2022 15:01:21 -0500 Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> Message-ID: On Tue, Apr 26, 2022 at 2:44 PM Fred Cisin via cctalk wrote: > We did have one old-timer who slashed letter O. We talked to the > keypunchers, and solved it by a discussion, and having him put his name in > red LARGE on every sheet. Forgive me, but is this not why we had a place on the coding forms explicitly for this purpose, as seen in: https://upload.wikimedia.org/wikipedia/commons/1/18/FortranCodingForm.png where "Punching Instructions" consisted of example pairs of a writer's hand lettered graphic and how it should actually be punched? I would have thought this was a fully solved problem from really early on. G. From wh.sudbrink at verizon.net Tue Apr 26 15:16:49 2022 From: wh.sudbrink at verizon.net (William Sudbrink) Date: Tue, 26 Apr 2022 16:16:49 -0400 Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> Message-ID: <056001d859aa$906e26c0$b14a7440$@verizon.net> At the University Of Maryland, in the Computer Science building (in the basement) there were about a dozen punches. A few (two I think?) were labeled "EXPRESS PUNCH 10 CARDS OR LESS". One evening, there was a line of 15 people waiting for a regular punch and a line of about 5 people waiting for the express punches. After noting who was at the end of the regular punch line, I got in the express line. I punched ten cards and went to the back of the line (it stayed between 5 and 10 people long). I think I punched about eighty cards. I expected to get yelled at (or dirty looks at least) but nobody seemed to notice. I finished before the guy who was at the end of the regular punch line when I entered got to a punch. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From cclist at sydex.com Tue Apr 26 15:29:46 2022 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 26 Apr 2022 13:29:46 -0700 Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> Message-ID: <66a21896-08ee-aa88-1787-300871089c53@sydex.com> On 4/26/22 12:44, Fred Cisin wrote: > One of my cow-orkers, a programmer, insisted that it was much faster for > him to type as he composed, even on a 026, than it was to write on > coding sheets, and then hand it off. There is something to that. Many was the time that I'd be punching late at night (just go to the keypunch pool area and pull up an 029), where I'd stop and say "nope--that's not going to work" and then revise my code on the fly. Management got so evangelical about the "programmers don't keypunch" that they moved the single keypunch (that serviced several systems) outside of the machine room into the hallway and put it on a 10 minute timer. So those of us with block time on the machines just brought up o26 and typed our stuff in on the DD60 and punched it on the 415. Later, we'd have to take the deck and interpret it, but it was good enough for on-the-spot work. Nighttime at CDC was a great time for bootlegging. The guards knew better than to fool with programmers. Occasionally, we'd get a CE who took umbrage at those guys (not me) who smoked, and drank coffee at the console. Whole operating systems got written at night, I suspect. --Chuck From bfranchuk at jetnet.ab.ca Tue Apr 26 15:41:02 2022 From: bfranchuk at jetnet.ab.ca (ben) Date: Tue, 26 Apr 2022 14:41:02 -0600 Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> Message-ID: <3e8b6924-c661-8992-1719-0a57848d70a4@jetnet.ab.ca> On 2022-04-26 2:01 p.m., Gavin Scott via cctalk wrote: > On Tue, Apr 26, 2022 at 2:44 PM Fred Cisin via cctalk > wrote: >> We did have one old-timer who slashed letter O. We talked to the >> keypunchers, and solved it by a discussion, and having him put his name in >> red LARGE on every sheet. > > Forgive me, but is this not why we had a place on the coding forms > explicitly for this purpose, as seen in: > > https://upload.wikimedia.org/wikipedia/commons/1/18/FortranCodingForm.png > > where "Punching Instructions" consisted of example pairs of a writer's > hand lettered graphic and how it should actually be punched? > > I would have thought this was a fully solved problem from really early on. > > G. In Many cases the monkeys can't read. :) Ben. PS: Did any common I/O devices have the ALGOL symbols Less than or Equals, Greater than or equals , not , arrows and other misc symbols? From paulkoning at comcast.net Tue Apr 26 16:14:30 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 26 Apr 2022 17:14:30 -0400 Subject: Slashed letter O, unslashed letter zero In-Reply-To: <3e8b6924-c661-8992-1719-0a57848d70a4@jetnet.ab.ca> References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> <3e8b6924-c661-8992-1719-0a57848d70a4@jetnet.ab.ca> Message-ID: <967FC636-357F-4F59-B3D8-21F82E35D1FF@comcast.net> > On Apr 26, 2022, at 4:41 PM, ben via cctalk wrote: > > ... > PS: Did any common I/O devices have the ALGOL symbols Less than or Equals, Greater than or equals , not , arrows and other misc symbols? Yes, the Flexowriters at TU Eindhoven used to punch ALGOL programs for the Electrologica X8 machine there (late 1960s through early 1970s). As I recall, Dijkstra made some comment somewhere about the usefulness of being able to specify your own character set. Those machines had upper/lower case letters, several special character such as the logic symbols not, or, and, the subscript 10 for exponential notation numbers, plus non-escaping underline and vertical bar. The underline was used for keywords, so the ALGOL keyword "begin" was keyed as _b_e_g_i_n. It would also make several other special characters, for example _= (underlined equal) is the Boolean equivalence operator, and _ followed by the not symbol gives you the "implies" operator, and _< is less-or-equal. The vertical bar would also make several overstruck symbols, for example |= becomes not-equal, | followed by the and symbol is uparrow (for exponentiation). The local inventions |< and |> were used for string quotes. Here's a sample of what it would look like printed on the Flexowriter. The line printers were upper-case only; they'd print lower case letters as upper case, upper case letters overprinted with a period. Ugh... paul From paulkoning at comcast.net Tue Apr 26 16:15:47 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 26 Apr 2022 17:15:47 -0400 Subject: Slashed letter O, unslashed letter zero In-Reply-To: <967FC636-357F-4F59-B3D8-21F82E35D1FF@comcast.net> References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> <3e8b6924-c661-8992-1719-0a57848d70a4@jetnet.ab.ca> <967FC636-357F-4F59-B3D8-21F82E35D1FF@comcast.net> Message-ID: <55A8FDF3-E453-4A8F-BFC6-7723315DC433@comcast.net> Bummer, no attachments... paul > On Apr 26, 2022, at 5:14 PM, Paul Koning via cctalk wrote: > > > >> On Apr 26, 2022, at 4:41 PM, ben via cctalk wrote: >> >> ... >> PS: Did any common I/O devices have the ALGOL symbols Less than or Equals, Greater than or equals , not , arrows and other misc symbols? > > Yes, the Flexowriters at TU Eindhoven used to punch ALGOL programs for the Electrologica X8 machine there (late 1960s through early 1970s). As I recall, Dijkstra made some comment somewhere about the usefulness of being able to specify your own character set. > > Those machines had upper/lower case letters, several special character such as the logic symbols not, or, and, the subscript 10 for exponential notation numbers, plus non-escaping underline and vertical bar. The underline was used for keywords, so the ALGOL keyword "begin" was keyed as _b_e_g_i_n. It would also make several other special characters, for example _= (underlined equal) is the Boolean equivalence operator, and _ followed by the not symbol gives you the "implies" operator, and _< is less-or-equal. The vertical bar would also make several overstruck symbols, for example |= becomes not-equal, | followed by the and symbol is uparrow (for exponentiation). The local inventions |< and |> were used for string quotes. > > Here's a sample of what it would look like printed on the Flexowriter. The line printers were upper-case only; they'd print lower case letters as upper case, upper case letters overprinted with a period. Ugh... > > paul > From cclist at sydex.com Tue Apr 26 17:17:57 2022 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 26 Apr 2022 15:17:57 -0700 Subject: Slashed letter O, unslashed letter zero In-Reply-To: <3e8b6924-c661-8992-1719-0a57848d70a4@jetnet.ab.ca> References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> <3e8b6924-c661-8992-1719-0a57848d70a4@jetnet.ab.ca> Message-ID: On 4/26/22 13:41, ben via cctalk wrote: > PS: Did any common I/O devices have the ALGOL symbols Less than or > Equals, Greater than or equals , not , arrows and other misc symbols? > CDC Display code certainly started out that way. See https://en.wikipedia.org/wiki/CDC_display_code. If you wanted ASCII graphics, you changed the print train on the 512 printer. If you had a 501 drum printer, you learned to translate. e.g. " = ? And so on... --Chuck From cisin at xenosoft.com Tue Apr 26 17:28:39 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 26 Apr 2022 15:28:39 -0700 (PDT) Subject: Slashed letter O, unslashed letter zero In-Reply-To: <66a21896-08ee-aa88-1787-300871089c53@sydex.com> References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> <66a21896-08ee-aa88-1787-300871089c53@sydex.com> Message-ID: On Tue, 26 Apr 2022, Chuck Guzis wrote: > Whole operating systems got written at night, I suspect. I suspect that Windoze was written during business hours. From cisin at xenosoft.com Tue Apr 26 17:36:20 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 26 Apr 2022 15:36:20 -0700 (PDT) Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> Message-ID: On Tue, 26 Apr 2022, Gavin Scott wrote: > Forgive me, but is this not why we had a place on the coding forms > explicitly for this purpose, as seen in: > https://upload.wikimedia.org/wikipedia/commons/1/18/FortranCodingForm.png > where "Punching Instructions" consisted of example pairs of a writer's > hand lettered graphic and how it should actually be punched? > I would have thought this was a fully solved problem from really early on. WHY did there ever exist any FORTRAN coding sheets WITHOUT that? (and, YES, there were.) From bfranchuk at jetnet.ab.ca Tue Apr 26 17:53:47 2022 From: bfranchuk at jetnet.ab.ca (ben) Date: Tue, 26 Apr 2022 16:53:47 -0600 Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> <66a21896-08ee-aa88-1787-300871089c53@sydex.com> Message-ID: On 2022-04-26 4:28 p.m., Fred Cisin via cctalk wrote: > On Tue, 26 Apr 2022, Chuck Guzis wrote: >> Whole operating systems got written at night, I suspect. > > I suspect that Windoze was written during business hours. > if you change that to "Whole operating systems got written/DEBUGGED at night, I suspect." that would explain many things today. I also suspect, you did not have wide range of mostly compatible hardware of today, but only a few I/O devices and simple MMU's. Ben. From cctalk at beyondthepale.ie Tue Apr 26 17:57:56 2022 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Tue, 26 Apr 2022 23:57:56 +0100 (WET-DST) Subject: H7816-BA power supply (Was Re: H7821 power supply in MicroVAX 3100, SCSI disk enclosures and others) In-Reply-To: <01S8BJOYKEQ48WW0VA@beyondthepale.ie> References: <01RGTSDYQHTW8X6K5E@beyondthepale.ie> Message-ID: <01SCICHQ3UWC8WYB2W@beyondthepale.ie> A few months ago, I mentioned a faulty H7816-BA power supply in a rackmount DEC 3000/600 Alphaserver. I finally got around to looking at it again recently. I hoped I had an identical working power supply to compare it to but I didn't. It turns out what I had is two working H7816-AA power supplies in tabletop models of DEC 3000/600 Alphaservers. These are very similar but not identical to the H7816-BA. The case layouts are different and the -AA has four integral fans while the -BA has a extra board mounted under the lid to power a large external fan instead. There may be differences on the main circuit boards, or there may not be. The faulty H7816-BA was emitting an audiable click just after power on as if it was trying to start and tripping out. If I put a meter on the +3.3V (orange), +5V (red) or +12V (brown) outputs, there was a very brief voltage kick visible coincident with the click. However, there didn't seem to be any activity visible on the -12V (blue) output. This was the first good clue to where the fault lay. With them switched off, I tried comparing resistance readings between the -12V outputs of the -AA and -BA power supplies and 0V (in both directions, in both diode mode and non-diode mode). There were visible differences. However, when I did the same for the +3.3V, +5V and +12V outputs, the results were pretty much identical between the -AA and the -BA. So, I looked where the blue wire is soldered to the main PCB. It is very difficult to trace where it comes from but there is a 7912 voltage regulator IC (E10) mounted on a heatsink close by and continuity tests show that this is it's source. Further continuity tests show that the other two terminals of E10 seemed to be shorted together. Aha! This is it I thought. It wasn't. After I unsoldered the 7912, the short was still on the board. Suspicion then fell on a 1000uF capacitor C45 connected across the same two points. After unsoldering this, it was found to be innocent too. Following the PCB traces further back turned out to be nearly impossible put poking around randomly with the continuity tester brought me to D21 (FEP16DT), a double rectifer in a TO-220 case mounted on a heatsink. This item seemed to have all three terminals shorted. After it was unsoldered, I found it to be shorted on one side only, the other side giving reasonable readings for a diode. After refitting E10 and C45 and throwing everything back together (because it is pretty much impossible to operate the power supply without it being fully assembled) I found that it didn't click at power on any more and it now stayed operating long enough to light my headlamp bulb dummy load on the +5V output for a few seconds before cutting out, presumably when the control circuitry noticed the lack of the -12V output due to D21 being missing. The green LED didn't come on. I didn't have anything like an FEP16DT to hand. I tried looking in a H7821 which I have already been scavanging parts from and all I could see was a UTG5346 (I think) which might be similar but I couldn't find any information about it anywhere so I decided not to risk trying it and breaking it. Instead, I tried refitting the faulty FEP16DT with the lead going to the shorted side bent up out of the way. I thought that maybe if it was being fed from a centre tapped winding on the chopper transformer, it might work with only one rectifier provided the loading was not heavy. On test, there was some negative voltage on the -12V output but the power supply still cut out after a few seconds and the green LED still didn't come on. On further reflection, the double rectifier is not being fed from a centre tapped winding because I can't find the centre tap anywhere on the transformer so having both rectifiers present is probably essential after all, depending on how the circuit is supposed to work, which I can't quite figure out. I had some used MR760 high current fast recovery rectifiers left over after repairing a battery charger so I decided to try bodging in one of them in place of the faulty half of the FEP16DT. I guess the worst that would happen is the power supply would trip out. However, this time the power supply continued working, my dummy load lamp glowed gently and the green LED came on. Yay! I even got 5V on the white wire which I am guessing by a process of elimination is probably the "power good" output. Looks like I need to put an FEP16DT on my next component order. Regards, Peter Coghlan. Previously I wrote: > Flushed with success, I moved on to look at a H7816 from a DEC 3000/600 > Alphaserver. This one shows little or no signs of life except for a barely > audible click at switch on. The fuse is not blown and there are no obvious > signs of distress anywhere. > > This one is a real pig to work on. Firstly, the incoming earth connection is > made to the lid of the power supply so when the lid is removed to work on it, > there is no longer any earth connection to the rest of the unit. A sticker is > thoughtfully placed on the underside of the lid to warn about this situation. > There are also two sub-boards attached to the underside of the lid. One is a > fan controller circuit (partially obscuring the sticker) which is easily > removed and put out of the way. The other sub-board contains the mains input > fuse, bridge rectifier, a 110V/220V autosense circuit and what seems to be > either a soft start circuit or less likely, a circuit to cut the power under > computer control. It is connected to the main board via a plug and socket and > five leads which are only barely long enough to reach. The plug has to be > removed in order to take the lid off and then 300V DC is no longer fed to > the main board meaning that measurements cannot be taken on the main board > to investigate what might be wrong. The real doozie is that the sub-board > has a heatsink on it which is directly connected to the live side of the > incoming mains for no good reason that I can see other than to make it > difficult to work on. Trying to plug the sub-board back in without the lid > in place would leave this live heatsink flopping onto the components mounted > on the main board below. As well as all this grief, a whole bunch of low > power components are mounted on another board which clipped under the main > board about 10mm away from it and connected to it using three multipin > plug/socket combinations denying access to the print side of the main board > and the component side of the low power board whenever the unit is able to > operate. There seem to be 20 Ohm load resistors across all of the outputs, > making it difficult to check the output rectifiers and smoothers without > desoldering stuff, in the event that the power supply turns out to be > tripping due to overcurrent. > > On a positive note, there are component references on the boards, the > minor boards are single sided, the unit is clean inside and one side > is completely open allowing some access with the lid on (while keeping > away from the live heatsink...) > > I took on this machine knowing it had a power supply fault. How hard > could it be to fix it, I thought :-) I'm hoping I have an identical > power supply in another machine which I can use to make comparisons to. > > Regards, > Peter Coghlan. From jules.richardson99 at gmail.com Tue Apr 26 18:55:08 2022 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Tue, 26 Apr 2022 18:55:08 -0500 Subject: BASIC environment ending with "run complete", and slashed 'O' characters? In-Reply-To: <0EA5E93C-F670-4BDC-A751-3388753E85AD@comcast.net> References: <73C1A9DF-519F-4418-8066-B7D4AF734E97@icloud.com> <0EA5E93C-F670-4BDC-A751-3388753E85AD@comcast.net> Message-ID: Hi Paul, Thanks for that! I'd mentioned this over on Facebook, where I'd also been able to post a photo of the transcript, and someone there pointed out that the BASIC listing uses single quotes around strings (what I'd expect to be ASCII 27h) rather than the double quotes that BASIC typically uses (expected ASCII 22h). Is that at all "meaningful" in any way? Did CDC BASIC use (or at least allow) single quotes instead of double? Or was the teletype maybe configured to print a single quote when encountering ASCII 22h, normally a double? Obviously I don't know why anyone would actually want that behavior. The only other thing I can think of is that the listing I have is a "fake" - i.e. not a true dump of a program run at all, but something that someone typed by hand, and they used the wrong quotes. That's a surprising error if so, but if this was educational material I suppose it's possible that it was simply a text file containing the listing followed by the supposed output, subsequently dumped to a teletype. Jules On 4/26/22 09:24, Paul Koning wrote: > Apparently so. The word from a CDC experts list is that the "run complete" message is not from BASIC itself (which is indeed a CDC product) but rather from the time sharing executive, called TELEX in KRONOS and early NOS, and IAF in later versions of NOS. > > As for the slashed letter O, that's strange. Certainly it is not CDC practice; the only place I ever ran into this is with IBM, I always considered it an example of IBM doing things the weird way. So it sounds like whoever bought those Teletype machines had them configured in that non-standard way for some reason. Normal, as far as I know, was slashed digit zero. > > MECC is a U. Minnesota KRONOS/NOS system with a bunch of local mods, but BASIC and TELEX are both part of the base system as supplied by CDC. > > paul > >> On Apr 26, 2022, at 3:05 AM, Raymond Wiker via cctalk wrote: >> >> https://en.wikipedia.org/wiki/CDC_Kronos , perhaps? >> >>> On 26 Apr 2022, at 03:08, Jules Richardson via cctalk wrote: >>> >>> >>> Perhaps a long shot, but I've got an old piece of paper here showing a BASIC listing followed by a program run where the BASIC environment terminates with "run complete" - does that behavior ring any bells with anyone? I'm mildly curious what machine it may have come from. >>> >>> The other interesting thing is that the output is from a teletype and the zero characters appear with no slash, while the uppercase 'O' characters do have a diagonal slash through them (e.g. the 'run complete' mentioned above comes out as 'RUN C0MPLETE') - certainly not unheard of, but I think doing the opposite had become typical practice by what, very early 1970s? >>> >>> At the top of the page there is a paragraph as follows (all in uppercase on the printout, obviously, and with slashed 'O' characters): >>> >>> "The following output is an example of BASIC language and the resulting run of a program. A punched paper tape of the program is included in the kit. This output was produced on a teletype." >>> >>> I don't know if that means anything to anyone? I have no idea what "the kit" was but am guessing that the printout I have was once part of some kind of educational material. >>> >>> I do have another printout from the MECC timeshare system (dated 78/9/1) which may have originated with the same teletype - it's different paper stock, but has the same slashed 'O' characters. The welcome message on that says 'Kronos 2.12-439', if that's meaningful... >>> >>> cheers >>> >>> Jules >>> >> > From paulkoning at comcast.net Tue Apr 26 19:14:41 2022 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 26 Apr 2022 20:14:41 -0400 Subject: BASIC environment ending with "run complete", and slashed 'O' characters? In-Reply-To: References: <73C1A9DF-519F-4418-8066-B7D4AF734E97@icloud.com> <0EA5E93C-F670-4BDC-A751-3388753E85AD@comcast.net> Message-ID: > On Apr 26, 2022, at 7:55 PM, Jules Richardson wrote: > > Hi Paul, > > Thanks for that! I'd mentioned this over on Facebook, where I'd also been able to post a photo of the transcript, and someone there pointed out that the BASIC listing uses single quotes around strings (what I'd expect to be ASCII 27h) rather than the double quotes that BASIC typically uses (expected ASCII 22h). I don't know CDC BASIC at all, and the only BASIC dialect I know at all well is BASIC-PLUS (from DEC). There, strings may be enclosed in either kind of quotes so long as they match. And as far as I remember that's not a BASIC-PLUS extension. > Is that at all "meaningful" in any way? Did CDC BASIC use (or at least allow) single quotes instead of double? Or was the teletype maybe configured to print a single quote when encountering ASCII 22h, normally a double? Obviously I don't know why anyone would actually want that behavior. An obvious reason to use one vs. the other is to enclose the other kind of quote, exactly as Python does it. It may be that on the CDC system in question there was some reason for picking one over the other, though I don't know what that might be; the CDC internal standard character set has both quotes in it, though as alternate "newer" glyphs replacing not-equal and uparrow from the original form of the "display code" set. paul From cisin at xenosoft.com Tue Apr 26 21:05:57 2022 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 26 Apr 2022 19:05:57 -0700 (PDT) Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> <66a21896-08ee-aa88-1787-300871089c53@sydex.com> Message-ID: I remember about 30 years ago, a registration card for a Microsoft product had specific forms that they wanted for certain letters, for the sake of a slightly inadequate handwriting recognition program. Among those was "ticked letter O". A round 'O", with an extra mark on the upper right. Like a slashed zero, with the slash going from upper right, but stopping before the center of the character. Or like an inverted 'Q' At the time, I thought that that surely would increase confusion between zero, letter 'O' and letter 'Q'. Yes, we were getting used to Palm's "Graffiti" stylized letters. Yes, the confusion between slashing zero VS slashing letter 'O' DID resolve itself, as such things will do, as soon as everybody who slashed letter 'O' had died off. I understand that some European countries had more orless problems with it than we did, particularly those who already had "altered" characters included in their languages. -- Grumpy Ol' Fred cisin at xenosoft.com From cclist at sydex.com Tue Apr 26 21:48:36 2022 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 26 Apr 2022 19:48:36 -0700 Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> <66a21896-08ee-aa88-1787-300871089c53@sydex.com> Message-ID: <65b5191e-7749-b51b-a55c-df6abee78c3a@sydex.com> On 4/26/22 19:05, Fred Cisin via cctalk wrote: > I remember about 30 years ago, a registration card for a Microsoft > product had specific forms that they wanted for certain letters, for the > sake of a slightly inadequate handwriting recognition program.? Among > those was "ticked letter O".? A round 'O", with an extra mark on the > upper right. Like a slashed zero, with the slash going from upper right, > but stopping before the center of the character.? Or like an inverted 'Q' > At the time, I thought that that surely would increase confusion between > zero, letter 'O' and letter 'Q'. All of that could have been avoided had we all adopted OCR-A (https://en.wikipedia.org/wiki/OCR-A) CDC actually adopted OCR-A as their official internal font. My office typewriter (Olivetti) had such a font. I hated it. Finally, I managed to snag an IBM Model D Executive when one of the departments shuffled off to Minnesota. ("Appropriating" equipment when departments moved or projects shut down was a favorite hobby. All such equipment never left the facility, so I wasn't really doing anything wrong, but confusing the bean counters). I had the best-looking office memos bar none. OCR-B was a bit less offensive, but the difference between capital oh and zero was less apparent. --Chuck From bfranchuk at jetnet.ab.ca Tue Apr 26 22:10:50 2022 From: bfranchuk at jetnet.ab.ca (ben) Date: Tue, 26 Apr 2022 21:10:50 -0600 Subject: Slashed letter O, unslashed letter zero In-Reply-To: <65b5191e-7749-b51b-a55c-df6abee78c3a@sydex.com> References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> <66a21896-08ee-aa88-1787-300871089c53@sydex.com> <65b5191e-7749-b51b-a55c-df6abee78c3a@sydex.com> Message-ID: <8f2e9879-5464-0700-20eb-7438a3dbf22d@jetnet.ab.ca> On 2022-04-26 8:48 p.m., Chuck Guzis via cctalk wrote: > CDC actually adopted OCR-A as their official internal font. My office > typewriter (Olivetti) had such a font. I hated it. > Well you can't have them use IBM equipment. Looking at some IBM DOC's from the 60's they had boxed tables for computer formats but using real box characters. +----+----+ | xxx| xxx| +----+----+ How did they print that? > OCR-B was a bit less offensive, but the difference between capital oh > and zero was less apparent. > > --Chuck > IFWEALLSPOKEGREE KSTILLWEWOULDHAV ENOPROBLEMATALLL OWERCASEISTHEHAN DWRITINGFONT BEN From ard.p850ug1 at gmail.com Tue Apr 26 22:45:11 2022 From: ard.p850ug1 at gmail.com (Tony Duell) Date: Wed, 27 Apr 2022 04:45:11 +0100 Subject: Slashed letter O, unslashed letter zero In-Reply-To: References: Message-ID: On Tue, Apr 26, 2022 at 6:25 PM Shoppa, Tim via cctalk wrote: > I'm 99% sure I've seen a listing of various Model 33 type-cylinder choices on some greenkeys site. Maybe it's in one of my paper Teletype manuals. Most are at least related to ASCII but there were a handful that were really "out there" (weather symbols, etc.) and seemed to have nothing to do with ASCII except they skipped the first 32 characters as unprintables. Volume 3 of the Model 33 technical manual -- the parts lists -- has tables of the type cylinder characters. It starts on page 46 of the .pdf I downloard, I suspect from the Australian HP museum site. -tony From spacewar at gmail.com Tue Apr 26 22:59:54 2022 From: spacewar at gmail.com (Eric Smith) Date: Tue, 26 Apr 2022 21:59:54 -0600 Subject: new Z80 monitor ROM works with no RAM Message-ID: I wrote a new monitor ROM for the Z80, called umonz, which can provide some basic monitor functionality even if there is no working RAM. In other words, it doesn't use a stack or store any variables in RAM. It supports reading and writing memory, I/O ports, and loading and dumping Intel hex format. https://github.com/brouhaha/umonz It's tricky to write any non-trivial Z80 code without a stack. I used IX and IY as subroutine return address registers, allowing two levels of subroutines, though a subroutine that uses IX can't call another subroutine using IX, and similarly for IY. The background is that John Doran built a custom Z80 (equivalent) computer system which he calls the Z80/M. It doesn't use an actual Z80 CPU; there is an Altera (now Intel) MAX 10 FPGA on the control panel board, and a Z80-equivalent core, along with the front panel logic, is in the FPGA. There is a 16-slot expansion bus using 96-pin DIN 41612 connectors. The cards are Eurocard 3U x 220mm. https://www.flickr.com/photos/_brouhaha_/52032832163/in/album-72177720298429134/ There's an expansion card that provides 512K of flash, 512K of SRAM, page mapping, a Z80 SIO for two serial ports, and a CF card, all compatible with the equivalent RC2014 cards. He expected that ROMWBW and CP/M or ZSystem would "just work". However we had to track down several minor hardware design issues to get it to work. After writing a few simple one-off test programs, I got tired of the assemble, sneakernet, program flash chip, test in target loop, so I decided to write a monitor. That definitely sped up the debug process. From cclist at sydex.com Wed Apr 27 00:22:24 2022 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 26 Apr 2022 22:22:24 -0700 Subject: Slashed letter O, unslashed letter zero In-Reply-To: <8f2e9879-5464-0700-20eb-7438a3dbf22d@jetnet.ab.ca> References: <5c3e3d4f-192f-86a5-254e-eb7c9bd66843@sydex.com> <66a21896-08ee-aa88-1787-300871089c53@sydex.com> <65b5191e-7749-b51b-a55c-df6abee78c3a@sydex.com> <8f2e9879-5464-0700-20eb-7438a3dbf22d@jetnet.ab.ca> Message-ID: <293a1f61-9591-023e-a7d0-2ccae47230d5@sydex.com> On 4/26/22 20:10, ben via cctalk wrote: > On 2022-04-26 8:48 p.m., Chuck Guzis via cctalk wrote: > >> CDC actually adopted OCR-A as their official internal font.? My office >> typewriter (Olivetti) had such a font.?? I hated it. >> > > Well you can't have them use IBM equipment. > Looking at some IBM DOC's from the 60's > they had boxed tables for computer formats > but using real box characters. > > +----+----+ > | xxx| xxx| > +----+----+ > > How did they print that? Cut and paste. Consider the S/360 Assembler (F) manual: http://bitsavers.org/pdf/ibm/360/asm/C26-3756-2_Assembler_F_Programmers_Guide_196711.pdf Look at PDF page 10. Note the box at the bottom of the page and how it's not even perfectly horizontal at the borders. In fact, it looks to be hand-drawn. I suspect that things were put together the old way--with scissors and rubber cement. I recall that in a real professional publications operation, several typewriters with various fonts (and sizes) were used. And then there were the T-square and ink graphics people... --Chuck