From fritzm at fritzm.org Mon Feb 1 00:03:09 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Sun, 31 Jan 2021 22:03:09 -0800 Subject: PDP-11/70 debugging advice In-Reply-To: References: <7cf71ced-86dd-a099-897e-9f9c945360f6@shiresoft.com> <80C7C186-38CB-4CD7-90B7-967AB7CFCFC1@fritzm.org> <37001320-0D80-43BE-9C3E-F703D1D914CB@fritzm.org> Message-ID: <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> > On Jan 31, 2021, at 8:19 PM, Josh Dersch wrote: > Well, what's interesting here is that on my system, switch S4 (MAINT STPR) steps the processor with switches S1 and S2 set to *any* configuration. Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1 S1:1 step by clock phase. The other two settings should free run the microcode. So yeah, sounds like something fishy there... The TIG card has more than a few analog components, and its not too unusual for these to get hung up on the adjacent card and have a leg pulled or sheared from the board. > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and clears the Timing Generator and the Cache timing." Yup, that's one of the signals coming in to RAC E106. Probing there should indicate which of possible sources for ZAP is actually occurring (UBCE ROM INIT H on pins 2 and 3 there). DCLO is a classic... Make sure to 'scope it, because it sometimes has troublesome spikes that don't show on a multimeter. If you have H742s, there are some wet tantalums on the control board that sometimes leak and cause trouble with this. I'm sure you are raring to go -- hope those fans show up for you tomorrow, and will be interested to hear what you find! --FritzM. From kspt.tor at gmail.com Mon Feb 1 03:33:48 2021 From: kspt.tor at gmail.com (Tor Arntsen) Date: Mon, 1 Feb 2021 10:33:48 +0100 Subject: APL\360 In-Reply-To: References: <964617146.374839285.1610677712174.JavaMail.zimbra@shaw.ca> <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> <846c6567-83e4-1d22-c059-8356306e9d63@sydex.com> Message-ID: On Sat, 30 Jan 2021 at 03:27, dwight via cctalk wrote: > If we'd thought about it we could count to 1023 on our fingers. > Dwight Some sheep herders in (IIRC) the Caucasus do, or did at least. I learned about that some decades ago. Counting sheep on their fingers. I use the system sometimes. -Tor From lproven at gmail.com Mon Feb 1 07:04:03 2021 From: lproven at gmail.com (Liam Proven) Date: Mon, 1 Feb 2021 14:04:03 +0100 Subject: Epson QX-10 hard drive In-Reply-To: References: Message-ID: On Sun, 31 Jan 2021 at 19:36, Warner Losh via cctalk wrote: > > Greetings > > I recently purchased a QCS external hard disk on ebay. This was one of the > companies that was selling DEC Rainbow hard drives. I had hoped it was an > old Rainbow drive with interesting to me bits... Turns out it is an Epson > QX-10 hard drive, full of interesting to bits for the QX-10 CP/M > enthusiast. I've had trouble finding a suitable community to note this in > should there be people around that care... so I thought I'd ask here is > people know of good CP/M groups and/or QX-10/16 groups, mailing lists, irc > channels, discord servers, etc I could find. I'm not in it, but https://www.facebook.com/groups/cpmusers ...? There's some interest in the GEM-DEV group on simpits.com -- GeneB is your man there. www.deltasoft.com is a starting point. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From abuse at cabal.org.uk Mon Feb 1 07:07:01 2021 From: abuse at cabal.org.uk (Peter Corlett) Date: Mon, 1 Feb 2021 14:07:01 +0100 Subject: APL\360 In-Reply-To: <3246ff52-751e-14f1-a464-fd9288aba256@jetnet.ab.ca> References: <69a83b09-b765-077f-d336-b03e55fa771c@gmail.com> <0bca4061-e671-4613-47c7-572b202ef8ab@telegraphics.com.au> <3246ff52-751e-14f1-a464-fd9288aba256@jetnet.ab.ca> Message-ID: On Wed, Jan 20, 2021 at 02:05:37PM -0700, ben via cctalk wrote: [...] > I don't see languages in general have improved since the the mid > 1960's. Hardware and language models don't reflect each other, > and don't have extendable data sizes and types. > PL/I seems to have been the best,but too tied to IBM. > C standard 2131 complex numbers > C standard 2143 dubble complex numbers > Every machine I can think of had a carry flag of some type > yet no language uses that to extend it self. You're describing a failing in C and similar languages stuck in the 1960s. Here's a Rust method that does add-exposing-carry: https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.overflowing_add The documentation doesn't explicitly say "carry" because Rust is architecture-neutral and it's down to LLVM to decide how to express it in machine code, but on x86 (and probably ARM) the boolean return value comes directly from the carry flag. > I don't believe in objects because data structures don't have classes, but > are more similar to each other. A window A structure is like window B but > details are different. That makes things look portable when they are not. > Constants still > seem to be embedded in data structures, rather than abstract. > -- zero array > define LIMIT abc > blah array[LIMIT] > ... > i = 0 while i< LIMIT array[i] = 0 i = i + 1 endw > I would like say > let LIMIT = abc > blah array[LIMIT] > i = 0 while i< array:LIMIT array[i] = 0 i = i + 1 endw You "don't believe in objects" yet then describe a problem which only exists due to the lack of them and then present OO pseudocode to solve it. A lot of OO languages suck of course, but the fundamental idea of encapsulation is not the bit that sucks. Here's it in Rust, where it takes in an arbitrary array (pedantically, "slice", a (pointer, element count)-tuple) and determines its length at runtime: pub fn clear_indexed(array: &mut [usize]) { for index in 0 .. array.len() { array[index] = 0; } } (The code for C-style fixed-length arrays looks broadly similar but has a bit more boilerplate because they're less useful.) Iterating over indices is generally discouraged for a number of reasons, not least being that the index may be out-of-bounds, but also because it can inhibit vectorisation or parallelisation. You have no choice in broken languages such as C, but many languages provide some notion of iteration which guarantees to not go out-of-bounds: pub fn clear_iterator(array: &mut [usize]) { for elem in array { *elem = 0; } } Both code fragments generate equivalent assembly in this trivial example because the Rust compiler could prove at compile time that the index variable can't go out-of-bounds. In more complex real-world code it cannot reliably do so and will insert a run-time check which aborts if the index is out-of-bounds. Or if it's C, trundle on and corrupt things. Oddly enough, the state of the art has moved on a bit in the half-century since C was invented. It's just that quite a lot of programmers haven't yet noticed. From lproven at gmail.com Mon Feb 1 07:15:33 2021 From: lproven at gmail.com (Liam Proven) Date: Mon, 1 Feb 2021 14:15:33 +0100 Subject: APL\360 In-Reply-To: References: <964617146.374839285.1610677712174.JavaMail.zimbra@shaw.ca> <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> <846c6567-83e4-1d22-c059-8356306e9d63@sydex.com> Message-ID: On Mon, 1 Feb 2021 at 10:34, Tor Arntsen via cctalk wrote: > > Some sheep herders in (IIRC) the Caucasus do, or did at least. I > learned about that some decades ago. Counting sheep on their fingers. > I use the system sometimes. Fred Pohl's short story "Digits and Dastards" explains it well. I used to use it at my fencing club. Matches are normally first to 15 points -- first to 10 if we were busy. I'd keep score on my fingers in binary, left for one player, right for the other.. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From abuse at cabal.org.uk Mon Feb 1 07:26:16 2021 From: abuse at cabal.org.uk (Peter Corlett) Date: Mon, 1 Feb 2021 14:26:16 +0100 Subject: APL\360 In-Reply-To: <3cf81260-0d4c-8ade-97f5-5d8dfe31cca1@sydex.com> References: <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <6B737D18-5F3E-470F-8299-CD473FE2EEB6@comcast.net> <601464BB.8010705@gmail.com> <3cf81260-0d4c-8ade-97f5-5d8dfe31cca1@sydex.com> Message-ID: On Fri, Jan 29, 2021 at 01:12:55PM -0800, Chuck Guzis via cctalk wrote: [...] > Most old (pre S/360) digit/character-addressable architectures were > big-endian (i.e. higher-order characters occupied lower addresses) > Even PDP-11 isn't strictly little-endian, though Intel X86 definitely is. I note that modern x86 and ARM have big-endian load and store operations, so while both architectures are little-endian by default, there is no extra overhead for handling big-endian data. Little-endian tends to be more useful when doing multi-word arithmetic. Big-endian is handy for text and human-readable numbers. That there are heated arguments over which endianness is best mainly tells us that there's bugger all in it either way. After all, the word "endian" is a satirical device in Gulliver's Travels. > Numbering of bits in a word is also interesting. Is the high order bit in > a 64 bit word, bit 0 or bit 63? Both conventions have been employed. On every CPU I've used, LSB has always been bit 0. Unlike endianness, this is clearly better than the other way round since the value is 2**bit_number and the bit number doesn't change if the value is converted into a different word width. When it comes to I/O devices which don't do arithmetic, either convention may appear. Hardware people rarely pick names or conventions that make sense to software people. From jules.richardson99 at gmail.com Mon Feb 1 08:14:54 2021 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 1 Feb 2021 08:14:54 -0600 Subject: Epson QX-10 hard drive In-Reply-To: References: Message-ID: On 1/31/21 12:35 PM, Warner Losh via cctalk wrote: > Greetings > > I recently purchased a QCS external hard disk on ebay. This was one of the > companies that was selling DEC Rainbow hard drives. I had hoped it was an > old Rainbow drive with interesting to me bits... Turns out it is an Epson > QX-10 hard drive, full of interesting to bits for the QX-10 CP/M > enthusiast. I've had trouble finding a suitable community to note this in > should there be people around that care... so I thought I'd ask here is > people know of good CP/M groups and/or QX-10/16 groups, mailing lists, irc > channels, discord servers, etc I could find. I'm not aware of anything, unfortunately. I've got a QX-10 that was originally one of Epson's sales demo machines, and got taken around to prospective customers by one of their sales reps - which does mean that it was well looked after and came with a *lot* of documentation (and media, but nothing "exciting" beyond the usual OS, Valdocs etc.). Did you happen to take an image of the drive contents? (hanging a hard disk off mine would be fun, but I think they were SASI to the external enclosure, and there was a SASI interface which plugged into the expansion slots - I'm not sure if the latter is documented anywhere) cheers Jules From lproven at gmail.com Mon Feb 1 09:45:38 2021 From: lproven at gmail.com (Liam Proven) Date: Mon, 1 Feb 2021 16:45:38 +0100 Subject: APL\360 In-Reply-To: References: <8d04617f-94cc-ab8b-f694-4342020bd2b2@sydex.com> <964617146.374839285.1610677712174.JavaMail.zimbra@shaw.ca> <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <3a8401b9-2bff-4335-a88d-09dc12d3d3c4@sydex.com> Message-ID: On Fri, 29 Jan 2021 at 22:14, Fred Cisin via cctalk wrote: > such as 42 > WHATDOYOUGETWHENYOUMULTIPLYSIXBYNINE ? -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From lproven at gmail.com Mon Feb 1 09:59:16 2021 From: lproven at gmail.com (Liam Proven) Date: Mon, 1 Feb 2021 16:59:16 +0100 Subject: APL\360 In-Reply-To: References: <8d04617f-94cc-ab8b-f694-4342020bd2b2@sydex.com> <964617146.374839285.1610677712174.JavaMail.zimbra@shaw.ca> <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: On Sat, 30 Jan 2021 at 02:56, dwight via cctalk wrote: > I constantly see people claiming how much better decimal is than the English system of meassurment. Um. I am a native English speaker, as well as an English citizen, and I count in decimal. Do you mean metric (SI / Systeme Internationale) versus Imperial measurements? If so, I 100% aver that metric is far better. I am 53 years old. I did not learn Imperial at school, in any of the 3 countries where I went to school (UK, Nigeria, Isle of Man.) I know some of the units; I think of a few things, such as human beings, computer screens, and pizzas, in Imperial units. People's height in feet & inches is more meaningful to me than in metres, but I can cope. People's weight in stones. Beer in pints. Speeds in MPH. But that's about all. I have never managed to learn how many ounces in a pound, or pounds in an stone, or stones in a hundredweight. I do not know what a fluid ounce is, or how many are in a pint. I do not know how many yards in a mile. They're all arbitrary numbers and it makes no sense. SI units are 100% easier by any metric. Yes, that is intentional. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From emu at e-bbes.com Mon Feb 1 10:10:07 2021 From: emu at e-bbes.com (emanuel stiebler) Date: Mon, 1 Feb 2021 11:10:07 -0500 Subject: APL\360 In-Reply-To: References: <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: On 2021-02-01 10:59, Liam Proven via cctalk wrote: > I do not know what a fluid ounce is, or how many are in a pint. not enough? ;-) From cclist at sydex.com Mon Feb 1 10:40:43 2021 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 1 Feb 2021 08:40:43 -0800 Subject: APL\360 In-Reply-To: References: <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: <8c4ae006-e517-3398-6650-547ab53a84ca@sydex.com> On 2/1/21 8:10 AM, emanuel stiebler via cctalk wrote: > On 2021-02-01 10:59, Liam Proven via cctalk wrote: >> I do not know what a fluid ounce is, or how many are in a pint. > > not enough? > ;-) > Whose pint? UK Imperial pint = 568 ml. US liquid pint = 473 ml. Both are one-eighth of a gallon, but US and UK gallons differ. Trivia for today. --Chuck From nw.johnson at ieee.org Mon Feb 1 11:44:01 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Mon, 1 Feb 2021 12:44:01 -0500 Subject: APL\360 In-Reply-To: <8c4ae006-e517-3398-6650-547ab53a84ca@sydex.com> References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> <8c4ae006-e517-3398-6650-547ab53a84ca@sydex.com> Message-ID: <76864ee3-258f-2b80-b312-790e44b0b2f4@ieee.org> It's actually 568.26.? Easy to work out, in Canada the gallon is defined as being 454609 ten millionths of a cubic metre, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-01 11:40 a.m., Chuck Guzis via cctalk wrote: > On 2/1/21 8:10 AM, emanuel stiebler via cctalk wrote: >> On 2021-02-01 10:59, Liam Proven via cctalk wrote: >>> I do not know what a fluid ounce is, or how many are in a pint. >> not enough? >> ;-) >> > Whose pint? UK Imperial pint = 568 ml. US liquid pint = 473 ml. > > Both are one-eighth of a gallon, but US and UK gallons differ. > > Trivia for today. > > --Chuck From cclist at sydex.com Mon Feb 1 10:36:40 2021 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 1 Feb 2021 08:36:40 -0800 Subject: APL\360 In-Reply-To: References: <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <6B737D18-5F3E-470F-8299-CD473FE2EEB6@comcast.net> <601464BB.8010705@gmail.com> <3cf81260-0d4c-8ade-97f5-5d8dfe31cca1@sydex.com> Message-ID: On 2/1/21 5:26 AM, Peter Corlett via cctalk wrote: > On every CPU I've used, LSB has always been bit 0. Unlike endianness, this > is clearly better than the other way round since the value is 2**bit_number > and the bit number doesn't change if the value is converted into a different > word width. I take it then, that you've never programmed a S/360 CPU? --Chuck From paulkoning at comcast.net Mon Feb 1 11:54:15 2021 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 1 Feb 2021 12:54:15 -0500 Subject: RD51 reduced write current signal? Message-ID: <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> Looking at the DEC Pro documentation there's some ambiguity I'm trying to figure out. The hard drive documentation talks about the "reduced write current" signal. In one place it's explicitly described as relevant to the RD50 only. But later on in the RD50/RD51 chapter the signal is described generally, without any indication that RD51 ignores it. Does anyone know which is correct? If RD51 also uses it, how does the right value get set? What IS the right value, anyway? paul From emu at e-bbes.com Mon Feb 1 11:55:59 2021 From: emu at e-bbes.com (emanuel stiebler) Date: Mon, 1 Feb 2021 12:55:59 -0500 Subject: APL\360 In-Reply-To: <8c4ae006-e517-3398-6650-547ab53a84ca@sydex.com> References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> <8c4ae006-e517-3398-6650-547ab53a84ca@sydex.com> Message-ID: On 2021-02-01 11:40, Chuck Guzis via cctalk wrote: > Whose pint? UK Imperial pint = 568 ml. US liquid pint = 473 ml. That explains some conversations I had with people there ;-) From couryhouse at aol.com Mon Feb 1 12:17:07 2021 From: couryhouse at aol.com (ED SHARPE) Date: Mon, 1 Feb 2021 18:17:07 +0000 (UTC) Subject: Just curious how many Hewlett-Packard Integral computers were sold. We have one here at the SMECC Museum that we are building a display around it for. References: <184464266.1171556.1612203427477.ref@mail.yahoo.com> Message-ID: <184464266.1171556.1612203427477@mail.yahoo.com> Australian HP museum site... yes kudos to them!? What wonderful work they have done and some of the friendliest? peple around! Even though I pull a copy down from there. If it is,for something we have in the collection? I also try to get original manuals too.. On Sunday, January 31, 2021 Tony Duell wrote: On Sun, Jan 31, 2021 at 6:25 AM Frank McConnell via cctalk wrote: > > On Jan 30, 2021, at 10:09, ED SHARPE via cctalk wrote: > > Hi Doug! No, we do not have a copy of this HP JOURNAL.? We do not have manuals? either.? We,are lucky to have the unit wonder if you can still order ink for the printer. I do have an unopened ink cartrige. You can get scans of the manuals from the Australian HP museum site Do you have any expansion boards in it? Extra memory is very useful (and you can turn any of the boards into a 1MByte one by adding the chips and changing links). As is an RS232 interface (something that IMHO should have been built-in) Do NOT leave the ink cartridge in the machine. The ink is somewhat corrosive and if it leaks onto the flexiprint that connects the cartridge to the logic PCB it will damage it. Due to the layout of the machine the flexiprint is longer than the one in a normal Thinkjet so you can't just raid one of those for spares. Yes there is a way to kludge it with ribbon cable and connectors but it's best not to have the problem in the first place. > > HP 51604A.? I was surprised a few months ago to find that Staples claims to be able to sell new HP cartridges.? Looking earlier today, HP can too! > > Seriously, we?re talking about ink cartridges including replacement print heads for printers manufactured in 1983. I was equally surprised to find that ink ribbons for the Epson HX20 laptop (M160 printer mechanism) along with the ones for the narrower M150 mechanism are still being made. But as I've said before, I'd rather find parts for a machine made 30 years ago than one made 5 years ago. -tony From cisin at xenosoft.com Mon Feb 1 12:34:53 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 1 Feb 2021 10:34:53 -0800 (PST) Subject: APL\360 In-Reply-To: References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> <846c6567-83e4-1d22-c059-8356306e9d63@sydex.com> Message-ID: > On Sat, 30 Jan 2021 at 03:27, dwight via cctalk wrote: >> If we'd thought about it we could count to 1023 on our fingers. On Mon, 1 Feb 2021, Tor Arntsen via cctalk wrote: > Some sheep herders in (IIRC) the Caucasus do, or did at least. I > learned about that some decades ago. Counting sheep on their fingers. > I use the system sometimes. counting sheep, . . . My ex asked me whether I was playing piano in my sleep. From imp at bsdimp.com Mon Feb 1 12:36:58 2021 From: imp at bsdimp.com (Warner Losh) Date: Mon, 1 Feb 2021 11:36:58 -0700 Subject: RD51 reduced write current signal? In-Reply-To: <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> References: <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> Message-ID: On Mon, Feb 1, 2021 at 10:54 AM Paul Koning via cctalk < cctalk at classiccmp.org> wrote: > Looking at the DEC Pro documentation there's some ambiguity I'm trying to > figure out. > > The hard drive documentation talks about the "reduced write current" > signal. In one place it's explicitly described as relevant to the RD50 > only. But later on in the RD50/RD51 chapter the signal is described > generally, without any indication that RD51 ignores it. > > Does anyone know which is correct? If RD51 also uses it, how does the > right value get set? What IS the right value, anyway? > The RD51 was the ST-412 while the RD50 was the ST-506. There's a combined OEM manual for these drives. http://www.bitsavers.org/pdf/seagate/ST412_OEMmanual_Apr82.pdf which has the answer. It's used in the ST406, but ignored in the ST-412. See Page 16 for the notes. Based on that, I think it's pretty safe to say the RD50 needed it, but the RD51 and newer did not. Warner From cisin at xenosoft.com Mon Feb 1 12:51:27 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 1 Feb 2021 10:51:27 -0800 (PST) Subject: APL\360 In-Reply-To: References: <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <6B737D18-5F3E-470F-8299-CD473FE2EEB6@comcast.net> <601464BB.8010705@gmail.com> <3cf81260-0d4c-8ade-97f5-5d8dfe31cca1@sydex.com> Message-ID: >>>>>We don't need another big-endian/little-endian battle On Mon, 1 Feb 2021, Peter Corlett via cctalk wrote: > Little-endian tends to be more useful when doing multi-word arithmetic. > Big-endian is handy for text and human-readable numbers. That there are > heated arguments over which endianness is best mainly tells us that there's > bugger all in it either way. After all, the word "endian" is a satirical > device in Gulliver's Travels. But, since computers weren't common among his readers in 1726, they wouldn't have understood the competing computer architectures of Lilliput and Blefescu, so he had to rewrite the issue in terms of opening eggs. https://www.ling.upenn.edu/courses/Spring_2003/ling538/Lecnotes/ADfn1.htm From cisin at xenosoft.com Mon Feb 1 13:00:37 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 1 Feb 2021 11:00:37 -0800 (PST) Subject: APL\360 In-Reply-To: References: <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: > On 2021-02-01 10:59, Liam Proven via cctalk wrote: >> I do not know what a fluid ounce is, or how many are in a pint. On Mon, 1 Feb 2021, emanuel stiebler via cctalk wrote: > not enough? > ;-) I had always been told, "A pint is a pound, the world around." I had already assumed that pub prices had inflated to higher than a pound. And more recently, through tangents on this list, I realized that a pint wasn't even the same size, the world around. Such worries call for having a few pints. From dkelvey at hotmail.com Mon Feb 1 13:03:00 2021 From: dkelvey at hotmail.com (dwight) Date: Mon, 1 Feb 2021 19:03:00 +0000 Subject: APL\360 In-Reply-To: References: <8d04617f-94cc-ab8b-f694-4342020bd2b2@sydex.com> <964617146.374839285.1610677712174.JavaMail.zimbra@shaw.ca> <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> , Message-ID: My point was that the metric system is easier because we chose to use a decimal number system. Things like using fractional measurements as in the Imperial system are actually better for designing with. Fractional numbers work better with things like cross sectional areas and strength. Look at typical metric bolt sizes. I agree things like ounces per pound are broken thinking. Giving up fractional dimensions to make it easer to match our decimal number system is also broken. Dwight ________________________________ From: cctalk on behalf of Liam Proven via cctalk Sent: Monday, February 1, 2021 7:59 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: APL\360 On Sat, 30 Jan 2021 at 02:56, dwight via cctalk wrote: > I constantly see people claiming how much better decimal is than the English system of meassurment. Um. I am a native English speaker, as well as an English citizen, and I count in decimal. Do you mean metric (SI / Systeme Internationale) versus Imperial measurements? If so, I 100% aver that metric is far better. I am 53 years old. I did not learn Imperial at school, in any of the 3 countries where I went to school (UK, Nigeria, Isle of Man.) I know some of the units; I think of a few things, such as human beings, computer screens, and pizzas, in Imperial units. People's height in feet & inches is more meaningful to me than in metres, but I can cope. People's weight in stones. Beer in pints. Speeds in MPH. But that's about all. I have never managed to learn how many ounces in a pound, or pounds in an stone, or stones in a hundredweight. I do not know what a fluid ounce is, or how many are in a pint. I do not know how many yards in a mile. They're all arbitrary numbers and it makes no sense. SI units are 100% easier by any metric. Yes, that is intentional. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From paulkoning at comcast.net Mon Feb 1 13:14:09 2021 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 1 Feb 2021 14:14:09 -0500 Subject: RD51 reduced write current signal? In-Reply-To: References: <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> Message-ID: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> > On Feb 1, 2021, at 1:36 PM, Warner Losh wrote: > > > > On Mon, Feb 1, 2021 at 10:54 AM Paul Koning via cctalk wrote: > Looking at the DEC Pro documentation there's some ambiguity I'm trying to figure out. > > The hard drive documentation talks about the "reduced write current" signal. In one place it's explicitly described as relevant to the RD50 only. But later on in the RD50/RD51 chapter the signal is described generally, without any indication that RD51 ignores it. > > Does anyone know which is correct? If RD51 also uses it, how does the right value get set? What IS the right value, anyway? > > The RD51 was the ST-412 while the RD50 was the ST-506. There's a combined OEM manual for these drives. http://www.bitsavers.org/pdf/seagate/ST412_OEMmanual_Apr82.pdf which has the answer. It's used in the ST406, but ignored in the ST-412. See Page 16 for the notes. > > Based on that, I think it's pretty safe to say the RD50 needed it, but the RD51 and newer did not. Great information, thanks! I've now tracked down analogous manuals for all Pro drives except for the RD53, I don't know what kind of drive that is. Learned some other interesting things. The Pro technical manual says the write precomp register should be set to do precomp starting at cylinder 256 for the RD52. That's correct for the Quantum model (8 head). It's wrong for the Atasi, which is the other "RD52" variant mentioned in the manual; its documentation says it should be cylinder 320. And the CDC RD52, mentioned in internal documents (I don't know if it shipped) is a CDC Wren, which has a strange rule: precomp "recommended for all cylinders, required for cylinder > 128". paul From lproven at gmail.com Mon Feb 1 13:15:25 2021 From: lproven at gmail.com (Liam Proven) Date: Mon, 1 Feb 2021 20:15:25 +0100 Subject: APL\360 In-Reply-To: References: <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk wrote: > > I had always been told, "A pint is a pound, the world around." Aha! Does that mean a pint of water weighs 1lb? Interesting. I did not know. > I had already assumed that pub prices had inflated to higher than a pound. It was under ?1 for ?litre of beer when I got here. In fact it was under US$1/ US 1pt. Now it's a bit more. Cheapest I had was CzK 17 for half a litre. At the time that was about 50?. > Such worries call for having a few pints. It is one of the things I miss most in lockdown. And there's no electricity supply in my man-cave/basement so I can't even go down there and play with my old computers. :-( -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From drb at msu.edu Mon Feb 1 13:17:30 2021 From: drb at msu.edu (Dennis Boone) Date: Mon, 01 Feb 2021 14:17:30 -0500 Subject: RD51 reduced write current signal? In-Reply-To: (Your message of Mon, 01 Feb 2021 14:14:09 -0500.) <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> Message-ID: <20210201191730.F2280CDBD@yagi.h-net.msu.edu> > I've now tracked down analogous manuals for all Pro drives except for > the RD53, I don't know what kind of drive that is. I believe: RD53 Micropolis 1325 71 MB RD54 Maxtor XT2190 159 MB De From paulkoning at comcast.net Mon Feb 1 13:24:01 2021 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 1 Feb 2021 14:24:01 -0500 Subject: RD51 reduced write current signal? In-Reply-To: <20210201191730.F2280CDBD@yagi.h-net.msu.edu> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> Message-ID: > On Feb 1, 2021, at 2:17 PM, Dennis Boone via cctalk wrote: > >> I've now tracked down analogous manuals for all Pro drives except for >> the RD53, I don't know what kind of drive that is. > > I believe: > > RD53 Micropolis 1325 71 MB > RD54 Maxtor XT2190 159 MB Thanks. RD54 isn't supported on the Pro as far as I know, too many cylinders. RD53 is at the exact upper limit of what the Pro controller can address. I realized I also don't know the RD31 and RD32. paul From cclist at sydex.com Mon Feb 1 13:25:34 2021 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 1 Feb 2021 11:25:34 -0800 Subject: APL\360 In-Reply-To: References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: <8ece0692-492f-8010-732c-039679fec177@sydex.com> On 2/1/21 11:00 AM, Fred Cisin via cctalk wrote: >> On 2021-02-01 10:59, Liam Proven via cctalk wrote: >>> I do not know what a fluid ounce is, or how many are in a pint. > On Mon, 1 Feb 2021, emanuel stiebler via cctalk wrote: >> not enough? >> ;-) > > I had always been told, "A pint is a pound, the world around." > I had already assumed that pub prices had inflated to higher than a pound. Or for that matter, fluid ounces, of which there are 20 UK ounces to a UK pint, but only 16 US ounces to a US pint. It all derives from the 1824 Weights and Measures Act in the UK. By that time, the US had elected to stay with the Elizabethan Exchequer standard (ca. 1588). It might be argued that, as far as measurement goes, the US is more authentically English than the UK. Three barleycorns, dry and round... --Chuck From drb at msu.edu Mon Feb 1 13:32:10 2021 From: drb at msu.edu (Dennis Boone) Date: Mon, 01 Feb 2021 14:32:10 -0500 Subject: RD51 reduced write current signal? In-Reply-To: (Your message of Mon, 01 Feb 2021 14:24:01 -0500.) References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> Message-ID: <20210201193210.85F83CE06@yagi.h-net.msu.edu> > I realized I also don't know the RD31 and RD32. The rest of the list I found long ago is: RD31 Seagate ST-225 20 MB RD32 Seagate ST-251 42 MB RD51 Seagate ST-412 10 MB RD52 Quantum Q540 31 MB It's clearly incomplete, as you found there were two different devices used for one of th RD models. De From commodorejohn at gmail.com Mon Feb 1 12:59:26 2021 From: commodorejohn at gmail.com (John Ames) Date: Mon, 1 Feb 2021 10:59:26 -0800 Subject: APL\360 Message-ID: > From: Chuck Guzis > Numbering of bits in a word is also interesting. Is the high order bit > in a 64 bit word, bit 0 or bit 63? Both conventions have been employed. This one has always boggled me, because it's the one aspect of the Endian Wars where there's a simple, straightforward answer grounded in basic mathematics - base ^ digit-number only gives the correct place-value when the lowest-order bit is numbered zero. It's beyond my ken how anybody thought the reverse was *valid,* let alone a good idea. From dab at froghouse.org Mon Feb 1 13:13:14 2021 From: dab at froghouse.org (David Bridgham) Date: Mon, 1 Feb 2021 14:13:14 -0500 Subject: APL\360 In-Reply-To: References: Message-ID: <82ae7791-9b1d-17b8-0d31-19a677576845@froghouse.org> On 2/1/21 1:59 PM, John Ames via cctech wrote: > This one has always boggled me, because it's the one aspect of the > Endian Wars where there's a simple, straightforward answer grounded in > basic mathematics - base ^ digit-number only gives the correct > place-value when the lowest-order bit is numbered zero. It's beyond my > ken how anybody thought the reverse was *valid,* let alone a good > idea. For all that I agree with you that little-endian is clearly the right answer and for exactly the reason you state, it's pretty easy to see where big-endian representation came from.? That's how we write numbers in English, we write them big-endian.? There ya go, it's as simple as that. Sure, one can get into the story that our numbers come from Arabic and Arabic is written right-to-left so in fact they were originally little-endian and just didn't get flipped around when incorporated into left-to-right languages but that's all lost in the past.? Today, we write numbers, in English, big-endian so it's no surprise at all that some computers followed that common practice. Dave From dave.g4ugm at gmail.com Mon Feb 1 13:34:39 2021 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Mon, 1 Feb 2021 19:34:39 -0000 Subject: APL\360 In-Reply-To: References: <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> < CAMTenCHmjEHPW5GqiPfyapPO7UmQYXJomEjxYxTL+FAf4=wS8g@mail.gmail.com> Message-ID: <571801d6f8d1$483fc380$d8bf4a80$@gmail.com> > -----Original Message----- > From: cctalk On Behalf Of Liam Proven via > cctalk > Sent: 01 February 2021 19:15 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: APL\360 > > On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk > wrote: > > > > I had always been told, "A pint is a pound, the world around." > > Aha! Does that mean a pint of water weighs 1lb? > > Interesting. I did not know. Typical American statement, where "world" means "United States". Its only a pound in the USA. In the UK it?s 1.25 lbs and even in Canada, before metrication, it was 20floz same as UK. In many metric countries the old word for a pound, so in German for example "pfund" informally refers to 500 grams, a little more than an American pint and rather less than UK pint... It gets worse because I understand that in the Caribbean (which as an English man I pronounce differently to the rest of the world) you will find both size pint in use .... > > > I had already assumed that pub prices had inflated to higher than a pound. > > It was under ?1 for ?litre of beer when I got here. In fact it was under US$1/ > US 1pt. Now it's a bit more. > > Cheapest I had was CzK 17 for half a litre. At the time that was about 50?. > > > Such worries call for having a few pints. > > It is one of the things I miss most in lockdown. And there's no electricity > supply in my man-cave/basement so I can't even go down there and play > with my old computers. :-( > > > > -- > Liam Proven ? Profile: https://about.me/liamproven > Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com > Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven > UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 Dave G4UGM Still stresssed after talking about mail routing at a USA Microsoft Exchange Conference.... From paulkoning at comcast.net Mon Feb 1 13:36:12 2021 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 1 Feb 2021 14:36:12 -0500 Subject: RD51 reduced write current signal? In-Reply-To: <20210201193210.85F83CE06@yagi.h-net.msu.edu> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> Message-ID: > On Feb 1, 2021, at 2:32 PM, Dennis Boone via cctalk wrote: > >> I realized I also don't know the RD31 and RD32. > > The rest of the list I found long ago is: > > RD31 Seagate ST-225 20 MB > RD32 Seagate ST-251 42 MB > RD51 Seagate ST-412 10 MB > RD52 Quantum Q540 31 MB > > It's clearly incomplete, as you found there were two different devices > used for one of th RD models. > > De Excellent. The Pro technical manual clearly mentions two RD52 variants, the other one is an Atasi 3046. And the rumored CDC RD52 is a 9415-36 ("Wren I"). paul From paulkoning at comcast.net Mon Feb 1 13:40:07 2021 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 1 Feb 2021 14:40:07 -0500 Subject: APL\360 In-Reply-To: <82ae7791-9b1d-17b8-0d31-19a677576845@froghouse.org> References: <82ae7791-9b1d-17b8-0d31-19a677576845@froghouse.org> Message-ID: <4D04E3F0-F078-4846-B001-4489BF351FE6@comcast.net> > On Feb 1, 2021, at 2:13 PM, David Bridgham via cctalk wrote: > > ... > Sure, one can get into the story that our numbers come from Arabic and > Arabic is written right-to-left so in fact they were originally > little-endian and just didn't get flipped around when incorporated into > left-to-right languages but that's all lost in the past. Today, we > write numbers, in English, big-endian so it's no surprise at all that > some computers followed that common practice. In Hebrew at least, numbers are written left to right. Also, as I understand it, in Arabic our numbers are called "Indian numbers" in recognition of the fact that they originated in India. They came to Europe via Arabia, but that's not their point of origin apparently. paul From paulkoning at comcast.net Mon Feb 1 13:47:38 2021 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 1 Feb 2021 14:47:38 -0500 Subject: APL\360 In-Reply-To: <571801d6f8d1$483fc380$d8bf4a80$@gmail.com> References: <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> < CAMTenCHmjEHPW5GqiPfyapPO7UmQYXJomEjxYxTL+FAf4=wS8g@mail.gmail.com> <571801d6f8d1$483fc380$d8bf4a80$@gmail.com> Message-ID: > On Feb 1, 2021, at 2:34 PM, Dave Wade G4UGM via cctalk wrote: > >>> ... >>> I had always been told, "A pint is a pound, the world around." >> >> Aha! Does that mean a pint of water weighs 1lb? >> >> Interesting. I did not know. > > Typical American statement, where "world" means "United States". Its only a pound in the USA. In the UK it?s 1.25 lbs and even in Canada, before metrication, it was 20floz same as UK. > In many metric countries the old word for a pound, so in German for example "pfund" informally refers to 500 grams, a little more than an American pint and rather less than UK pint... > It gets worse because I understand that in the Caribbean (which as an English man I pronounce differently to the rest of the world) you will find both size pint in use .... That would fit tradition. A lot of the Imperial unit names were at one time also used in the rest of Europe. But their definition varied randomly, often from town to town. I have a book about sailing ships that gives the dimensions in "Amsterdam feet", which by the way have 11 inches per foot, not 12. My father, a metrologist, had a history book discussing the pre-metric systems of units of Europe. The units were often set by the ruler of the day (e.g., the "ell" might match the arm of the prince in charge at that time). Sometimes not, though. The book had a lovely picture showing the way the standard "foot" was estabished in one German principality: officials gathered outside the town church in some town, stopped the first 12 adult males leaving Mass, and had them line up their feet. They captured that measurement, divided by 12, presto, the standard foot. For that place and time, anyway. So don't be surprised that there are lots of pounds, ounces, etc. -- that's just how it's always been done. Much later, there were three different inches: the UK one, the US one, and the Canadian one. At least in theory. In reality they were so close that it's unlikely any instrument could tell the difference. And precision calibration was done with Johansson blocks, which followed the Canadian definition (25.4 mm exactly). paul From cisin at xenosoft.com Mon Feb 1 14:07:44 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 1 Feb 2021 12:07:44 -0800 (PST) Subject: OT: pints, pounds (Was: APL\360 In-Reply-To: References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: >> I had always been told, "A pint is a pound, the world around." On Mon, 1 Feb 2021, Liam Proven via cctalk wrote: > Aha! Does that mean a pint of water weighs 1lb? > Interesting. I did not know. That is what it MEANS. But, it's not quite right. It's off by about 4%. A US pint of water weighs 1.043 pounds. One "fluid ounce" (volume) of water weighs 1.043 ounces (weight)! How much do you suppose a "pint" of ice cream weighs? And, not all beer has the same specific gravity. Alcohol is less dense than water. And, of course, further variation with temperature and atmospheric pressure. And, if you are in England, "A pint of water weighs a pound and a quarter." Fortunately, that is NOT a difference in the force of gravity! Or, at least MOSTLY not. THAT heavy thought would be difficult to work around. Despite very minor variances in gravity, Earth is MOSTLY HARMLESS. Instead, it just means that British pubs are not as stingy with their beer. And, it doesn't need to be chilled to almost frozen to make it drinkable. I wish that there were a pub open. But, "The Albatross" (pub in Berkeley) has closed down. forever. Can't stay in business with a lockdown. I can get beer delivered! Coincidentally, it is Corona beer! -- Grumpy Ol' Fred From cisin at xenosoft.com Mon Feb 1 14:15:43 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 1 Feb 2021 12:15:43 -0800 (PST) Subject: bit numbering (Was: APL\360 In-Reply-To: References: Message-ID: >> From: Chuck Guzis >> Numbering of bits in a word is also interesting. Is the high order bit >> in a 64 bit word, bit 0 or bit 63? Both conventions have been employed. On Mon, 1 Feb 2021, John Ames via cctalk wrote: > This one has always boggled me, because it's the one aspect of the > Endian Wars where there's a simple, straightforward answer grounded in > basic mathematics - base ^ digit-number only gives the correct > place-value when the lowest-order bit is numbered zero. It's beyond my > ken how anybody thought the reverse was *valid,* let alone a good > idea. It probably originated from our system of writing numbers with most significant on the left, least significant on the right. Then combined with somebody not even thinking in terms of "one's place"/"ten's place", or "one's place"/"two's place"/"four's place" etc. and simply numbering from left to right. It is unfortunate that they were permitted to do so. From cclist at sydex.com Mon Feb 1 14:24:42 2021 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 1 Feb 2021 12:24:42 -0800 Subject: OT: pints, pounds (Was: APL\360 In-Reply-To: References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: <2808cf82-8a70-af9e-47fd-904f3b81bbbf@sydex.com> On 2/1/21 12:07 PM, Fred Cisin via cctalk wrote: > Instead, it just means that British pubs are not as stingy with their > beer.? And, it doesn't need to be chilled to almost frozen to make it > drinkable. No, as I said, it's that Americans (of the US variety) are authentically English, using the 1588 standard, than their overseas cousins, who use the Imperial 1824 one. Simple, that. Importing the IBM PC 5150 into Europe must have caused a bit of a kerfuffle. All of those SAE fasteners--e.g. 6-32 bolt used extensively. #6 bolt size with 32 threads per inch. It wasn't really until the clone makers got into the picture with their metric hardware. The result is that most recent PCs employ a macaronic assortment of fasteners. Thank heavens that the Brits didn't come out with the 5150--we might have had to deal with Whitworth (BSW) fasteners. --Chuck From pete at dunnington.plus.com Mon Feb 1 14:18:24 2021 From: pete at dunnington.plus.com (Pete Turnbull) Date: Mon, 1 Feb 2021 20:18:24 +0000 Subject: OT: pints, pounds (Was: APL\360 In-Reply-To: References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: On 01/02/2021 20:07, Fred Cisin via cctalk wrote: > A US pint of water weighs 1.043 pounds. > One "fluid ounce" (volume) of water weighs 1.043 ounces (weight)! That's also a US measure. An imperial fluid ounce is 28.4ml and a floz of water weighs 28.4g, same as an avoirdupois ounce. In fact it's defined (or was) as the volume of water that weighs one ounce. -- Pete Pete Turnbull From imp at bsdimp.com Mon Feb 1 14:39:39 2021 From: imp at bsdimp.com (Warner Losh) Date: Mon, 1 Feb 2021 13:39:39 -0700 Subject: Epson QX-10 hard drive In-Reply-To: References: Message-ID: On Mon, Feb 1, 2021 at 7:15 AM Jules Richardson via cctalk < cctalk at classiccmp.org> wrote: > On 1/31/21 12:35 PM, Warner Losh via cctalk wrote: > > Greetings > > > > I recently purchased a QCS external hard disk on ebay. This was one of > the > > companies that was selling DEC Rainbow hard drives. I had hoped it was an > > old Rainbow drive with interesting to me bits... Turns out it is an Epson > > QX-10 hard drive, full of interesting to bits for the QX-10 CP/M > > enthusiast. I've had trouble finding a suitable community to note this in > > should there be people around that care... so I thought I'd ask here is > > people know of good CP/M groups and/or QX-10/16 groups, mailing lists, > irc > > channels, discord servers, etc I could find. > > I'm not aware of anything, unfortunately. I've got a QX-10 that was > originally one of Epson's sales demo machines, and got taken around to > prospective customers by one of their sales reps - which does mean that it > was well looked after and came with a *lot* of documentation (and media, > but nothing "exciting" beyond the usual OS, Valdocs etc.). > > Did you happen to take an image of the drive contents? > Yes. I do. It looks to be CP/M format, with 3 maybe 4 partitions. I've had a couple of requests, so I uploaded it to https://people.freebsd.org/~imp/qx-10-disk.img Raw sector dump, in physical order, of all the tracks. 4 heads, 16 sectors per track, 480 cylinders. Cylinder 480 and higher could be read, but were in a different format, so all bets are off as to what's there in this dump. The SASI to MFM adapter is a WD1002, but it wasn't in the loop when I imaged things. Can't talk SASI at the moment anyway, so there's no extra data I could glean from that, at least in a quick pass over the WD1002 docs. > (hanging a hard disk off mine would be fun, but I think they were SASI to > the external enclosure, and there was a SASI interface which plugged into > the expansion slots - I'm not sure if the latter is documented anywhere) > Yes, the unit I got was an external unit sold by QCS, which sold units for Apple, TRS-80, IBM PC, DEC Rainbow, Expson QX-10 and a few others I'm sure I've forgotten. It has the SASI to MFM adapter card connected to the mini-scribe disk. I got it mostly for playing with Rainbow stuff, but it doesn't have to wind up there... Warner From w2hx at w2hx.com Mon Feb 1 16:03:05 2021 From: w2hx at w2hx.com (W2HX) Date: Mon, 1 Feb 2021 22:03:05 +0000 Subject: cctalk Digest, Vol 76, Issue 29 In-Reply-To: <591E93343A104CD3ADBAC9C21262B870@Daedalus> References: <591E93343A104CD3ADBAC9C21262B870@Daedalus> Message-ID: > I can still count quite rapidly up to 31 on one hand (either one). That is a neat trick. I have a hard time counting to 21 unless I take off my pants. 73 Eugene W2HX -----Original Message----- From: cctalk On Behalf Of Mark Moulding via cctalk Sent: Saturday, January 30, 2021 3:45 PM To: cctalk at classiccmp.org Subject: Re: cctalk Digest, Vol 76, Issue 29 From: dwight > If we'd thought about it we could count to 1023 on our fingers. I used to play string bass in a symphony, and there were many times that there would be long periods of rest, where it was important to count the bars (measures) going by so as to come back in at the right time. To this day (that was 40+ years ago) I can still count quite rapidly up to 31 on one hand (either one). Higher numbers slow me down a bit... Old bass joke: During the last movement of Beethoven's 9th symphony, there is a very long tacit (rest) for the basses. So the bass section all went over to the bar across the street for a drink or three. To keep the conductor from passing by their entry, they put a rubber band around his music. So the situation was... Bottom of the ninth, basses loaded, score tied. (sorry...) ~~ Mark Moulding From jfoust at threedee.com Mon Feb 1 16:35:31 2021 From: jfoust at threedee.com (John Foust) Date: Mon, 01 Feb 2021 16:35:31 -0600 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> Message-ID: <20210201224140.5052C273A4@mx1.ezwind.net> https://github.com/keirf/Greaseweazle I heard about this today and I'm surprised I hadn't heard about it on this list before. Flux reading and writing from all sizes of floppy? Anyone here using one? I'd love to get it working for 8 inch, 5 1/4, 3 1/2 drives here in my shop. - John From mooreericnyc at gmail.com Mon Feb 1 16:51:46 2021 From: mooreericnyc at gmail.com (Eric Moore) Date: Mon, 1 Feb 2021 16:51:46 -0600 Subject: Greaseweazle In-Reply-To: <20210201224140.5052C273A4@mx1.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> Message-ID: I have one, been trying to get it going for a bit now with an 8" shugart SA801. I am now just struggling to get power to the shugart, need a few commercial AMP mate-n-lok connectors and some new caps for the shugart supply I have that gave up the ghost. Seems neat, but I am very much learning disk archival still. I did get HT-11 online, my RX01/02 imaging pipeline is great :) -Eric On Mon, Feb 1, 2021, 4:41 PM John Foust via cctalk wrote: > > https://github.com/keirf/Greaseweazle > > Anyone here using one? I'd love to get it working for 8 inch, > 5 1/4, 3 1/2 drives here in my shop. > > From geneb at deltasoft.com Mon Feb 1 16:58:22 2021 From: geneb at deltasoft.com (geneb) Date: Mon, 1 Feb 2021 14:58:22 -0800 (PST) Subject: Greaseweazle In-Reply-To: <20210201224140.5052C273A4@mx1.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> Message-ID: On Mon, 1 Feb 2021, John Foust via cctalk wrote: > > https://github.com/keirf/Greaseweazle > > I heard about this today and I'm surprised I hadn't heard about it > on this list before. > > Flux reading and writing from all sizes of floppy? > > Anyone here using one? I'd love to get it working for 8 inch, > 5 1/4, 3 1/2 drives here in my shop. > I've got one (F7+ Lightning version) and I've used it with 5.25" and 8" disks. I've got plans to use it with 8" disks, but I've not done it yet. You'll need to get the FDADAP from here: http://www.dbit.com/fdadap.html in order to use it with the GW. 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 aek at bitsavers.org Mon Feb 1 17:24:07 2021 From: aek at bitsavers.org (Al Kossow) Date: Mon, 1 Feb 2021 15:24:07 -0800 Subject: Greaseweazle In-Reply-To: <20210201224140.5052C273A4@mx1.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> Message-ID: <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> On 2/1/21 2:35 PM, John Foust via cctalk wrote: > > https://github.com/keirf/Greaseweazle > > I heard about this today and I'm surprised I hadn't heard about it > on this list before. > > Flux reading and writing from all sizes of floppy? > > Anyone here using one? I'd love to get it working for 8 inch, > 5 1/4, 3 1/2 drives here in my shop. > > - John > Eric Schlaepfer built a version with buffering and 5" and 8" connectors. There is a fair amount of churn as what they want the hardware to be and the project is siloed because of their insistence on using farcebook for communications. From cisin at xenosoft.com Mon Feb 1 17:28:21 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 1 Feb 2021 15:28:21 -0800 (PST) Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> Message-ID: > On Mon, 1 Feb 2021, John Foust via cctalk wrote: >> >> https://github.com/keirf/Greaseweazle >> >> I heard about this today and I'm surprised I hadn't heard about it >> on this list before. >> >> Flux reading and writing from all sizes of floppy? >> >> Anyone here using one? I'd love to get it working for 8 inch, >> 5 1/4, 3 1/2 drives here in my shop. >> On Mon, 1 Feb 2021, geneb via cctalk wrote: > I've got one (F7+ Lightning version) and I've used it with 5.25" and 8" > disks. I've got plans to use it with 8" disks, but I've not done it yet. > You'll need to get the FDADAP from here: http://www.dbit.com/fdadap.html in > order to use it with the GW. If you are READing 8" disks, and ONLY READing, then you can get away with a simpler caable. The main time that you might need the fdadap is for TG43 for writing. But, the fdadap is a convenient way to not have to make a cable. It looks promising. The docs on the website are a little thin. It could use some instructions written for somebody who has never seen it before. For example, " type gw -h to see available commands" could certainly stand to be expanded to list the commands, and provide discussion of what each one does. Even if it is "obvious". The examples for Specifying Tracks were not bad, but could use some beginner support, such as explaining that heads are 0,1 and a 40 track drive numbers from 0-39, not 1-40, etc. Documentation should also always include a list of EVERY error code, with a more detailed explanation of what each one actually means. And, some explanations of how to tell whether you need to do double stepping, including what the incorrect results will look like if you get it wrong. Including what the resulting file will look like for trying to read an unformatted track. Explanation of FM, MFM, and GCR encoding, or at least pointers to places where those are discussed. But, it is not the worst example that I have ever seen of: "It doesn't need any documentation. Just run the program. The menus in the program tell you everything that you could need to know." With XenoCopy, I found that I needed to include a Quick Start A Tutorial A Reference Even with that, an enormous amount of handholding was needed. Including, of course, answers to questions of HOW-TO do thing that the program clearly stated it could not do, such as reading Apple 5.25" disks without additional hardware. From jfoust at threedee.com Mon Feb 1 17:29:36 2021 From: jfoust at threedee.com (John Foust) Date: Mon, 01 Feb 2021 17:29:36 -0600 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> Message-ID: <20210201232957.114F64E6A8@mx2.ezwind.net> At 04:58 PM 2/1/2021, geneb wrote: >I've got one (F7+ Lightning version) and I've used it with 5.25" and 8" disks. I've got plans to use it with 8" disks, but I've not done it yet. You'll need to get the FDADAP from here: http://www.dbit.com/fdadap.html in order to use it with the GW. Already have one of those. Did you say you have it working with eight inch? - John From geneb at deltasoft.com Mon Feb 1 17:33:01 2021 From: geneb at deltasoft.com (geneb) Date: Mon, 1 Feb 2021 15:33:01 -0800 (PST) Subject: Greaseweazle In-Reply-To: <20210201232957.114F64E6A8@mx2.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <20210201232957.114F64E6A8@mx2.ezwind.net> Message-ID: On Mon, 1 Feb 2021, John Foust via cctalk wrote: > At 04:58 PM 2/1/2021, geneb wrote: >> I've got one (F7+ Lightning version) and I've used it with 5.25" and 8" disks. I've got plans to use it with 8" disks, but I've not done it yet. You'll need to get the FDADAP from here: http://www.dbit.com/fdadap.html in order to use it with the GW. > > Already have one of those. Did you say you have it working with eight inch? > Not yet. It's on my TODO list. 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 cclist at sydex.com Mon Feb 1 18:13:13 2021 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 1 Feb 2021 16:13:13 -0800 Subject: Greaseweazle In-Reply-To: <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> Message-ID: <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> On 2/1/21 3:24 PM, Al Kossow via cctalk wrote: > Eric Schlaepfer built a version with buffering and 5" and 8" connectors. > There is a fair amount of churn as what they want the hardware to be > and the project is siloed because of their insistence on using farcebook > for communications. Early on, I built one with buffering and played with it (I already had the parts in my hellbox), but I prefer to use a more capable MCU to to my work (i.e. not an STM32F1, but STM32F407). More memory, faster clocks; I could probably do hard disks with it, by just adding the differential buffers and writing some firmware. Not a whole lot of difference in cost, either--$10 for a 407 board with clock/calendar, SDHC SDIO,etc. There's also a similar implementation using a very inexpensive Cypress PSOC 6 ARM card that mounts on a 3.5" floppy connector (no cable). It's what I've been saying for years--just about any moderately capable modern MCU can do the job. After all the Gotek emulator uses a nearly obsolescent STM32F107 or 105 MCU. The "blue pill" STM32F103 is quite a bit more capable. Glad people finally tumbled to this. --Chuck From aek at bitsavers.org Mon Feb 1 18:15:28 2021 From: aek at bitsavers.org (Al Kossow) Date: Mon, 1 Feb 2021 16:15:28 -0800 Subject: Greaseweazle In-Reply-To: <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> Message-ID: On 2/1/21 4:13 PM, Chuck Guzis via cctalk wrote: > any moderately capable > modern MCU can do the job. and it is the software and the knowledge of what you need to do when recovering media in volume these guys have no clue about From pete at dunnington.plus.com Mon Feb 1 18:38:11 2021 From: pete at dunnington.plus.com (Pete Turnbull) Date: Tue, 2 Feb 2021 00:38:11 +0000 Subject: OT: pints, pounds (Was: APL\360 In-Reply-To: <2808cf82-8a70-af9e-47fd-904f3b81bbbf@sydex.com> References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> <2808cf82-8a70-af9e-47fd-904f3b81bbbf@sydex.com> Message-ID: <283e694f-aff2-88f3-d9c4-9418a5e23273@dunnington.plus.com> On 01/02/2021 20:24, Chuck Guzis via cctalk wrote: > Thank heavens that the Brits didn't come out with the 5150--we might > have had to deal with Whitworth (BSW) fasteners. Nah, too many of them are similar to UNC/UNF, which would have just caused confusion. We'd have used BA sizes. -- Pete Pete Turnbull From a.carlini at ntlworld.com Mon Feb 1 19:07:51 2021 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Tue, 2 Feb 2021 01:07:51 +0000 Subject: Greaseweazle In-Reply-To: <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> Message-ID: <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> On 02/02/2021 00:13, Chuck Guzis via cctalk wrote: > > There's also a similar implementation using a very inexpensive Cypress > PSOC 6 ARM card that mounts on a 3.5" floppy connector (no cable). That would presumably be the FluxEngine (http://cowlark.com/fluxengine/index.html). I have the PSOC and I've loaded up the firmware. Now I just need to wire some parts together (PSU+floppy) and I can give it a quick whirl. > It's what I've been saying for years--just about any moderately capable > modern MCU can do the job. After all the Gotek emulator uses a nearly > obsolescent STM32F107 or 105 MCU. The "blue pill" STM32F103 is quite a > bit more capable. > > Glad people finally tumbled to this. Indeed. The important part is that someone's written some firmware. Oh, and it's cheap too, of course. Antonio -- Antonio Carlini antonio at acarlini.com From cmhanson at eschatologist.net Mon Feb 1 19:18:29 2021 From: cmhanson at eschatologist.net (Chris Hanson) Date: Mon, 1 Feb 2021 17:18:29 -0800 Subject: Greaseweazle In-Reply-To: <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> Message-ID: On Feb 1, 2021, at 5:07 PM, Antonio Carlini via cctalk wrote: > > Indeed. The important part is that someone's written some firmware. Oh, and it's cheap too, of course. And that it's something available for the community to work with and improve, rather than something where people are hoping to profit off archival ventures. -- Chris From jfoust at threedee.com Mon Feb 1 19:24:29 2021 From: jfoust at threedee.com (John Foust) Date: Mon, 01 Feb 2021 19:24:29 -0600 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> Message-ID: <20210202013739.8C18A2737F@mx1.ezwind.net> At 06:15 PM 2/1/2021, Al Kossow via cctalk wrote: >On 2/1/21 4:13 PM, Chuck Guzis via cctalk wrote: >>any moderately capable >>modern MCU can do the job. > >and it is the software and the knowledge of what you need to do when >recovering media in volume these guys have no clue about What aspects are they missing? - John From aek at bitsavers.org Mon Feb 1 19:54:19 2021 From: aek at bitsavers.org (Al Kossow) Date: Mon, 1 Feb 2021 17:54:19 -0800 Subject: Greaseweazle In-Reply-To: <20210202013739.8C18A2737F@mx1.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> Message-ID: <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> On 2/1/21 5:24 PM, John Foust via cctalk wrote: > What aspects are they missing? The workflow of 'squirt across a bitstream from the whole disk, let the PC chew on it and maybe it's right' is fundamentally wrong It may work on clean media but you are guaranteed of getting garbage after the head clogs at some point during the march across the disk. From jfoust at threedee.com Mon Feb 1 20:17:22 2021 From: jfoust at threedee.com (John Foust) Date: Mon, 01 Feb 2021 20:17:22 -0600 Subject: Greaseweazle In-Reply-To: <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> Message-ID: <20210202021740.10D384E6C4@mx2.ezwind.net> At 07:54 PM 2/1/2021, Al Kossow via cctalk wrote: >The workflow of 'squirt across a bitstream from the whole disk, let the PC >chew on it and maybe it's right' is fundamentally wrong >It may work on clean media but you are guaranteed of getting garbage after the >head clogs at some point during the march across the disk. Hmm, OK... So a dirty media problem eventually goops the head... Are you saying a flux recorder should have a better way of detecting that problem? And stop earlier? - John From aek at bitsavers.org Mon Feb 1 20:22:50 2021 From: aek at bitsavers.org (Al Kossow) Date: Mon, 1 Feb 2021 18:22:50 -0800 Subject: Greaseweazle In-Reply-To: <20210202021740.10D384E6C4@mx2.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> Message-ID: <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> On 2/1/21 6:17 PM, John Foust via cctalk wrote: > Are you saying a flux recorder should have a better way of detecting that problem? Yes, the way they do it now if you have one shot at recovering a disk you are sure to fail. Imagedisk, even though it spends way too much time with the heads spinning on the media at least does real-time retries. the problem is you also need to be able to stop and assemble a complete image by splicing together multiple partial attempts. From ccth6600 at gmail.com Tue Feb 2 00:02:16 2021 From: ccth6600 at gmail.com (Tom Hunter) Date: Tue, 2 Feb 2021 14:02:16 +0800 Subject: Greaseweazle In-Reply-To: <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> Message-ID: There is also Kryoflux: https://kryoflux.com/ It works well for me even with the copy protected disks ImageDisk can't copy with. Tom Hunter On Tue, Feb 2, 2021 at 10:23 AM Al Kossow via cctalk wrote: > On 2/1/21 6:17 PM, John Foust via cctalk wrote: > > > Are you saying a flux recorder should have a better way of detecting > that problem? > > Yes, the way they do it now if you have one shot at recovering a disk you > are sure to fail. > > Imagedisk, even though it spends way too much time with the heads spinning > on the media at > least does real-time retries. the problem is you also need to be able to > stop and > assemble a complete image by splicing together multiple partial attempts. > From jwsmail at jwsss.com Tue Feb 2 00:57:01 2021 From: jwsmail at jwsss.com (jim stephens) Date: Mon, 1 Feb 2021 22:57:01 -0800 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> Message-ID: <92d19cb9-d55f-7b75-331e-b328f711b62e@jwsss.com> On 2/1/2021 10:02 PM, Tom Hunter via cctalk wrote: > It works well for me even with the copy protected disks ImageDisk can't > copy with. The biggest problem imaging programs had trouble with was how to duplicate whatever errors were on the disk (as in abnormal patterns) when making a copy. I had the best luck with nearly everything with a package called copywright (I think).? Big claim to fame was preserving the bit count on the track and spacing when writing. Simple software rarely bothered to do that.? They could stretch the image to fit each track. Unless the copy "protector" looked at a way to fit to a generic disk with little variability in the manufacturing, the copy schemes didn't have a lot of other tricks once many of the weird crap was tried and defeated. I work for a company which sold a database program which actually was defeated by that after they fooled a lot of other programs. good to hear that Greasweazle works for that.? I have one from Keir Fraser who does a good job of supporting it. Also FWIW, Facebook sucks etc. blah blah, but you can make a fairly low information account and join.? FB works happily with adblock plus, and anti tracking for cookies turned up high, and I have a lot of utility machines, one can be rigged to allow FB use w/o any of the pain.? At this writing there are 1192 members there. Of course all the questions that any media backup, archival, copy, etc. are generating is there, but there is no embargo on the information.? The group is private mainly to keep out the rif raf who spam. I have several groups I manage and do the same.? Better to block the membership being ad hoc than having to watch it if you want to keep it spam and bullshit free. thanks Jim From kspt.tor at gmail.com Tue Feb 2 02:03:15 2021 From: kspt.tor at gmail.com (Tor Arntsen) Date: Tue, 2 Feb 2021 09:03:15 +0100 Subject: Greaseweazle In-Reply-To: <92d19cb9-d55f-7b75-331e-b328f711b62e@jwsss.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <92d19cb9-d55f-7b75-331e-b328f711b62e@jwsss.com> Message-ID: I have a Greaseweazle F7+, and I have an fdadap as well (and a Shugart 8" drive), a 5 1/4" drive (my main target, the 8" follows), and 3.5" drives (not really a target - the 3.5" HD floppies are mostly unreadable anyway). So, I'm ready to go.. except that due to sleep deprivation I managed to dump my 5 1/4" floppy cable (the one with an edge connector), in a "what's this?" moment late at night (had to move, sort, pack, dump a lot of stuff). I had spent time to get that cable.. argh. So, edge connectors etc. have arrived on a slow boat, I've got all the parts but I have yet to connect it all and start testing the thing. And yes that FB thing is annoying. There's no way I will go there (it's blocked anyway, on the network level here). Fortunately there is some documentation floating around elsewhere too. From derschjo at gmail.com Tue Feb 2 02:30:19 2021 From: derschjo at gmail.com (Josh Dersch) Date: Tue, 2 Feb 2021 00:30:19 -0800 Subject: PDP-11/70 debugging advice In-Reply-To: <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> References: <7cf71ced-86dd-a099-897e-9f9c945360f6@shiresoft.com> <80C7C186-38CB-4CD7-90B7-967AB7CFCFC1@fritzm.org> <37001320-0D80-43BE-9C3E-F703D1D914CB@fritzm.org> <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> Message-ID: On Sun, Jan 31, 2021 at 10:03 PM Fritz Mueller wrote: > > > > On Jan 31, 2021, at 8:19 PM, Josh Dersch wrote: > > Well, what's interesting here is that on my system, switch S4 (MAINT > STPR) steps the processor with switches S1 and S2 set to *any* > configuration. > > Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1 S1:1 > step by clock phase. The other two settings should free run the > microcode. So yeah, sounds like something fishy there... The TIG card has > more than a few analog components, and its not too unusual for these to get > hung up on the adjacent card and have a leg pulled or sheared from the > board. > > > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it > asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and > clears the Timing Generator and the Cache timing." > > Yup, that's one of the signals coming in to RAC E106. Probing there > should indicate which of possible sources for ZAP is actually occurring > (UBCE ROM INIT H on pins 2 and 3 there). > > DCLO is a classic... Make sure to 'scope it, because it sometimes has > troublesome spikes that don't show on a multimeter. If you have H742s, > there are some wet tantalums on the control board that sometimes leak and > cause trouble with this. > > I'm sure you are raring to go -- hope those fans show up for you tomorrow, > and will be interested to hear what you find! > Small update; fans arrived today and they are now installed. Voltages tested on the backplane at the points called out in the service docs, and all voltages dialed in to 5.05V. Ripple is within tolerances -- about 200mV with some very short spikes that barely show up on my 'scope that go to 300mV or so. Not sure if this is abnormal, I also saw these while burning the supplies in on the bench. Checked the AC LO and DC LO signals at all the points called out in figure 6-12 (p. II-6-22 of http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf) and appear to be correct. Looked at most of them under the scope and no spikes (other than those in the ripple from the power supply.) Tomorrow I'll get some boards out on extenders and take a look at what's going on at the logic level. - Josh > > --FritzM. > > From cc at informatik.uni-stuttgart.de Tue Feb 2 02:44:53 2021 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Tue, 2 Feb 2021 09:44:53 +0100 (CET) Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> Message-ID: On Mon, 1 Feb 2021, Fred Cisin wrote: > If you are READing 8" disks, and ONLY READing, then you can get away with a > simpler caable. The main time that you might need the fdadap is for TG43 for > writing. But, the fdadap is a convenient way to not have to make a cable. You only need the TG43 signal for old drives. All the 8" drives that I use with a PC or BeagleBone (with a modified mfmreader software) don't need this signal. Christian From cc at informatik.uni-stuttgart.de Tue Feb 2 02:55:33 2021 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Tue, 2 Feb 2021 09:55:33 +0100 (CET) Subject: Greaseweazle In-Reply-To: <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> Message-ID: On Mon, 1 Feb 2021, Al Kossow wrote: > Imagedisk, even though it spends way too much time with the heads > spinning on the media at least does real-time retries. the problem is > you also need to be able to stop and assemble a complete image by > splicing together multiple partial attempts. Well, isn't that logical? ;-) I do this with my Linux implementation of IMD, and I do this with my floppy version of the mfmreader: immediately abort an operation when there are noises coming from the media, clean, restart at one/two cylinders before the forced abort, etc. and then "splice" together the individual read attempts. You can't do real-time retries when reading at the flux level if you have no idea of the format. So often, it's better to sample a disk several times in case that the later processing reveals bad sectors. So often enough you can get an error free image produced from several samples. The toughest part of course is the "PLL" that you need in software to lock to the bit rate. Christian From abuse at cabal.org.uk Tue Feb 2 04:13:07 2021 From: abuse at cabal.org.uk (Peter Corlett) Date: Tue, 2 Feb 2021 11:13:07 +0100 Subject: APL\360 In-Reply-To: References: <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: On Mon, Feb 01, 2021 at 08:15:25PM +0100, Liam Proven via cctalk wrote: > On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk > wrote: >> I had always been told, "A pint is a pound, the world around." "The world" meaning "the USA", of course. > Aha! Does that mean a pint of water weighs 1lb? Yes, to within the massive margins of error involved in prehistoric units. A fluid ounce of fluid weighs an ounce, oddly enough. This equivalence applies to both British and American units. Although it seems obvious that this is how it's defined, it turns out that it's actually derived from the gallon, because rationality goes out of the window when it comes to this trainwreck of a system. There are 16floz to an American pint and 16oz to a pound, which lines up nicely and gives that rhyme. A British pint is 20floz whereas the pound remains 16oz, hence the alternative rhyme "a pint of water weighs a pound and a quarter". As a bonus, different reference fluids are used, so the floz also differs by roughly 4% as it crosses the Pond. The Dutch haven't quite let go of "ons", "pond" and "pijnt". The latter two have been fudged to 500g and 500ml. I think "ons" might just be used in stock phrases now. Some products ae also dual-labelled and include a floz conversion; I did the maths because the number looked a bit off and it turned out to be American floz. > Interesting. I did not know. >> I had already assumed that pub prices had inflated to higher than a pound. The rhyme refers to weight, not currency... The last pint of Real Ale I had before using my one-way Eurostar ticket the hell out of the place was ?4.20. Or four guineas if we're harking back to the era of that rhyme. > It was under ?1 for ?litre of beer when I got here. In fact it was under > US$1/ US 1pt. Now it's a bit more. I did enjoy lining them up at ?1.40/500ml in Bratislava, and in a tourist trap at that. At some point I should spend more than six hours in Eastern Europe, and a smaller proportion in a pub. Slovakia looked worth a visit outside of the touristy bits, but my companion was being grumpy. > Cheapest I had was CzK 17 for half a litre. At the time that was about 50?. It was ?4.40 for a Happy Hour pijnt when I was last in one of my favourite Amsterdam boozers, which was rather a long time ago now thanks to Rutte's general incompetence at running the country. At today's exchange rate, the ?9.49 crate of beer from my local supermarket works out at ?0.60/500ml. >> Such worries call for having a few pints. > It is one of the things I miss most in lockdown. And there's no > electricity supply in my man-cave/basement so I can't even go down there > and play with my old computers. :-( Eh, at least the beer will be at cellar temperature. From aek at bitsavers.org Tue Feb 2 04:25:07 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 02:25:07 -0800 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> Message-ID: On 2/2/21 12:44 AM, Christian Corti via cctalk wrote: > You only need the TG43 signal for old drives. A VERY small subset of 8" drives, actually. It can also control the read channel filter on some, with a jumper. From aek at bitsavers.org Tue Feb 2 04:28:20 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 02:28:20 -0800 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> Message-ID: <242c44be-3938-f1ea-4815-ec2b50d7d14b@bitsavers.org> On 2/2/21 12:55 AM, Christian Corti via cctalk wrote: > I do this with my Linux implementation of IMD, and I do this with my floppy version of the mfmreader Good for you Most software doesn't work that way. From aek at bitsavers.org Tue Feb 2 04:32:32 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 02:32:32 -0800 Subject: Greaseweazle In-Reply-To: <92d19cb9-d55f-7b75-331e-b328f711b62e@jwsss.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <92d19cb9-d55f-7b75-331e-b328f711b62e@jwsss.com> Message-ID: <5af35bcf-b866-1a42-7faa-ef0a177237b6@bitsavers.org> On 2/1/21 10:57 PM, jim stephens via cctalk wrote: > Of course all the questions that any media backup, archival, copy, etc. are generating is there, but there is no embargo on the information. > The group is private So someone should mirror it. I'm not having anything to do with Facebook. From aek at bitsavers.org Tue Feb 2 04:52:16 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 02:52:16 -0800 Subject: Greaseweazle In-Reply-To: <242c44be-3938-f1ea-4815-ec2b50d7d14b@bitsavers.org> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <242c44be-3938-f1ea-4815-ec2b50d7d14b@bitsavers.org> Message-ID: <83edd3fd-250c-6783-d81a-6001af81b144@bitsavers.org> On 2/2/21 2:28 AM, Al Kossow via cctalk wrote: > On 2/2/21 12:55 AM, Christian Corti via cctalk wrote: > >> I do this with my Linux implementation of IMD, and I do this with my floppy version of the mfmreader Do you make these available online? I found your version of IMD here ftp://computermuseum.informatik.uni-stuttgart.de/utils not under source control. I hate the fact that there are dozens of siloed projects in this problem space. From aek at bitsavers.org Tue Feb 2 04:54:57 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 02:54:57 -0800 Subject: Greaseweazle In-Reply-To: <83edd3fd-250c-6783-d81a-6001af81b144@bitsavers.org> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <242c44be-3938-f1ea-4815-ec2b50d7d14b@bitsavers.org> <83edd3fd-250c-6783-d81a-6001af81b144@bitsavers.org> Message-ID: <3a005769-cb8f-34f9-d9ef-e3e6bae34d42@bitsavers.org> On 2/2/21 2:52 AM, Al Kossow via cctalk wrote: > I hate the fact that there are dozens of siloed projects in this problem space. Including cctlk. There is actually a medialab channel on the cctlk discord From aek at bitsavers.org Tue Feb 2 05:03:02 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 03:03:02 -0800 Subject: Greaseweazle In-Reply-To: <3a005769-cb8f-34f9-d9ef-e3e6bae34d42@bitsavers.org> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <242c44be-3938-f1ea-4815-ec2b50d7d14b@bitsavers.org> <83edd3fd-250c-6783-d81a-6001af81b144@bitsavers.org> <3a005769-cb8f-34f9-d9ef-e3e6bae34d42@bitsavers.org> Message-ID: <070d2d5b-2254-cb2a-f4c1-b1bf16294014@bitsavers.org> On 2/2/21 2:54 AM, Al Kossow via cctalk wrote: > On 2/2/21 2:52 AM, Al Kossow via cctalk wrote: > >> I hate the fact that there are dozens of siloed projects in this problem space. > > Including cctlk. There is actually a medialab channel on the cctlk discord > and before IMD there was Eric's DMK imager, which is what I used before Dave's program http://dmklib.brouhaha.com/ which was compatible with Catweasel DMKs From aek at bitsavers.org Tue Feb 2 05:08:21 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 03:08:21 -0800 Subject: Greaseweazle In-Reply-To: <070d2d5b-2254-cb2a-f4c1-b1bf16294014@bitsavers.org> References: <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <242c44be-3938-f1ea-4815-ec2b50d7d14b@bitsavers.org> <83edd3fd-250c-6783-d81a-6001af81b144@bitsavers.org> <3a005769-cb8f-34f9-d9ef-e3e6bae34d42@bitsavers.org> <070d2d5b-2254-cb2a-f4c1-b1bf16294014@bitsavers.org> Message-ID: <804846dc-d391-5ece-0e5e-d9dbaea489f2@bitsavers.org> On 2/2/21 3:03 AM, Al Kossow via cctalk wrote: > On 2/2/21 2:54 AM, Al Kossow via cctalk wrote: >> On 2/2/21 2:52 AM, Al Kossow via cctalk wrote: >> >>> I hate the fact that there are dozens of siloed projects in this problem space. >> >> Including cctlk. There is actually a medialab channel on the cctlk discord >> > > and before IMD there was Eric's DMK imager, which is what I used before Dave's program > http://dmklib.brouhaha.com/ > > which was compatible with Catweasel DMKs > great.. the DMK spec link there is 404 a version appears to be in here https://github.com/lutris/openmsx/blob/master/doc/DMK-Format-Details.txt From aek at bitsavers.org Tue Feb 2 05:12:36 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 03:12:36 -0800 Subject: Greaseweazle In-Reply-To: <92d19cb9-d55f-7b75-331e-b328f711b62e@jwsss.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <92d19cb9-d55f-7b75-331e-b328f711b62e@jwsss.com> Message-ID: On 2/1/21 10:57 PM, jim stephens via cctalk wrote: > The biggest problem imaging programs had trouble with was how to duplicate whatever errors were on the disk (as in abnormal patterns) when > making a copy. Copy protection is just a pain in the ass. A tiny, tiny fraction of what I work with has any and I'm very happy it is mostly used on consumer computers which are being archived by others so I don't have to. From aek at bitsavers.org Tue Feb 2 05:17:11 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 03:17:11 -0800 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <92d19cb9-d55f-7b75-331e-b328f711b62e@jwsss.com> Message-ID: <36bf3fa4-7f13-8b27-e8ae-b20e4ec3417e@bitsavers.org> On 2/2/21 3:12 AM, Al Kossow via cctalk wrote: > A tiny, tiny fraction of what I work with has any and > I'm very happy it is mostly used on consumer computers > which are being archived by others so I don't have to. > > A great example is this little Apple II nightmare https://twitter.com/bitsavers/status/1353909647833358337 From geneb at deltasoft.com Tue Feb 2 08:32:26 2021 From: geneb at deltasoft.com (geneb) Date: Tue, 2 Feb 2021 06:32:26 -0800 (PST) Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> Message-ID: On Mon, 1 Feb 2021, Al Kossow via cctalk wrote: > On 2/1/21 4:13 PM, Chuck Guzis via cctalk wrote: >> any moderately capable >> modern MCU can do the job. > > and it is the software and the knowledge of what you need to do when > recovering media in volume these guys have no clue about How about helping out instead of bitching from the sidelines? 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 geneb at deltasoft.com Tue Feb 2 08:36:42 2021 From: geneb at deltasoft.com (geneb) Date: Tue, 2 Feb 2021 06:36:42 -0800 (PST) Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> Message-ID: On Mon, 1 Feb 2021, Chris Hanson via cctalk wrote: > On Feb 1, 2021, at 5:07 PM, Antonio Carlini via cctalk wrote: >> >> Indeed. The important part is that someone's written some firmware. Oh, and it's cheap too, of course. > > And that it's something available for the community to work with and improve, rather than something where people are hoping to profit off archival ventures. > *cough*kryoflux*cough* 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 jfoust at threedee.com Tue Feb 2 08:51:35 2021 From: jfoust at threedee.com (John Foust) Date: Tue, 02 Feb 2021 08:51:35 -0600 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> Message-ID: <20210202145358.EF98E273F4@mx1.ezwind.net> At 08:32 AM 2/2/2021, geneb via cctalk wrote: >On Mon, 1 Feb 2021, Al Kossow via cctalk wrote: >>and it is the software and the knowledge of what you need to do when >>recovering media in volume these guys have no clue about > >How about helping out instead of bitching from the sidelines? I was quite eager to hear Kossow's insights. Any engineer or programmer (or both) worth their salt eagerly seeks and accepts the "but it would be really handy if it did X, Y and Z" insights, especially if they're coming from someone with decades of experience in the field in question. How else will products improve? - John From dseagrav at lunar-tokyo.net Tue Feb 2 09:01:01 2021 From: dseagrav at lunar-tokyo.net (Daniel Seagraves) Date: Tue, 2 Feb 2021 09:01:01 -0600 Subject: Greaseweazle In-Reply-To: <20210202145358.EF98E273F4@mx1.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> Message-ID: <24ACBCBF-4482-4C45-862B-7C1C5F7B80B1@lunar-tokyo.net> > On Feb 2, 2021, at 8:51 AM, John Foust via cctalk wrote: > > How else will products improve? I don?t know what planet you?re from but here on modern-day Earth we don?t improve anything anymore. We just bitch and scream on the internet and find reasons to drive people out so nobody contributes. Contributing things is egotistical anyway. You?re not making yourself look good, you?re making everyone else look bad. Anyway, whoever bitches longest and loudest wins because they?ve drove away all the people dragging things down. This is indisputable fact! Perfection is achieved when there is nothing left to take away, so if we take away everything by destroying a project the project has achieved peak perfection. This is technically correct, which is the only kind of correct that matters, which means I cannot be proven wrong and I win forever. (It should not need to be pointed out that the preceding was in highest sarcasm, yet here we are) From aek at bitsavers.org Tue Feb 2 09:18:25 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 07:18:25 -0800 Subject: Greaseweazle In-Reply-To: <20210202145358.EF98E273F4@mx1.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> Message-ID: On 2/2/21 6:51 AM, John Foust via cctalk wrote: > I was quite eager to hear Kossow's insights. And I'd like to hear what Chuck's workflow and software look like. He's had decades more experience than me, but no one complains when he just says "throw a microcontroller at it" and walks away. From geneb at deltasoft.com Tue Feb 2 09:58:20 2021 From: geneb at deltasoft.com (geneb) Date: Tue, 2 Feb 2021 07:58:20 -0800 (PST) Subject: Greaseweazle In-Reply-To: <20210202145358.EF98E273F4@mx1.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> Message-ID: On Tue, 2 Feb 2021, John Foust via cctalk wrote: > At 08:32 AM 2/2/2021, geneb via cctalk wrote: >> On Mon, 1 Feb 2021, Al Kossow via cctalk wrote: >>> and it is the software and the knowledge of what you need to do when >>> recovering media in volume these guys have no clue about >> >> How about helping out instead of bitching from the sidelines? > > I was quite eager to hear Kossow's insights. Any engineer or programmer > (or both) worth their salt eagerly seeks and accepts the "but it would be really > handy if it did X, Y and Z" insights, especially if they're coming from > someone with decades of experience in the field in question. > > How else will products improve? > You're absolutely correct, however the only thing Al contributes (for the purposes of this particular discussion) are complaints about how other people are doing it wrong. He complains about "siloed" projects, but the silos are of his own construction. There's two fully open source projects that do flux-level disk imaging, but he's apparently not interested in helping either one because of how they choose to interact with their user base. Frankly, as far as I'm concerned, he needs to cut loose his belt-onions and quit shouting at clouds. 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 aek at bitsavers.org Tue Feb 2 11:19:08 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Feb 2021 09:19:08 -0800 Subject: Flip-Chip selloff Message-ID: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> I don't have any equipment that uses them any more, so I'll be ebaying off my A-W series flip chips over the next few days. The W's and PT08 boards are up now https://www.ebay.com/itm/184647476832 https://www.ebay.com/itm/184647420812 From cclist at sydex.com Tue Feb 2 11:20:01 2021 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 2 Feb 2021 09:20:01 -0800 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> Message-ID: <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> On 2/2/21 7:18 AM, Al Kossow via cctalk wrote: > On 2/2/21 6:51 AM, John Foust via cctalk wrote: > >> I was quite eager to hear Kossow's insights. > > And I'd like to hear what Chuck's workflow and software look like. > He's had decades more experience than me, but no one complains when > he just says "throw a microcontroller at it" and walks away. Uh, I think over the decades, I've contributed a bit, no? I recently made my own Catweasel source code public, for example. I've helped out the guy with the fluxengine puzzle out a couple of formats, including the Brother 240K one that few seem to have sussed out. When I last proposed the STM32F407, I was met with "Oh, but the Blue Pill is cheaper". Okay, use the Blue Pill, but my code won't work with it. Not once has anyone contacted me and said "I'd like to try my hand at doing this, what can you tell me?". I've described the methodology of using an MCU elsewhere several times. And then there are 22Disk, Anadisk, Teledisk and specialized drivers of PC Yore that apparently nobody thinks that I originated. Anyone want to know why we sold off Anadisk and Teledisk 20 years ago, along with our specialized forensics software? Because we were getting bombarded with support questions (Sample: "I have game xxxx, why won't Teledisk make copies?" and later "Anadisk doesn't run on my USB drive".) while we'd maybe get a registration every one or two months. When offered money for the product rights, we jumped at it. We held onto 22Disk because there was the most public support for it--and we could sell it into the industrial PLC community. If someone really would like to help out, give me some hints on repairing a Matsushita LF-5010 WORM drive that won't mount a disc. --Chuck From healyzh at avanthar.com Tue Feb 2 12:22:47 2021 From: healyzh at avanthar.com (Zane Healy) Date: Tue, 2 Feb 2021 10:22:47 -0800 Subject: Flip-Chip selloff In-Reply-To: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> Message-ID: <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk wrote: > > I don't have any equipment that uses them any more, so I'll be ebaying off my > A-W series flip chips over the next few days. The W's and PT08 boards are up now > > https://www.ebay.com/itm/184647476832 > https://www.ebay.com/itm/184647420812 That makes me wonder if I shouldn?t do the same. That would be part of a camera lens, which may, or may not take up less space. :-) Then again I?ve been saying I need to downsize my collection for the better part of 20 years. Zane From cz at alembic.crystel.com Tue Feb 2 12:48:08 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 2 Feb 2021 13:48:08 -0500 Subject: Flip-Chip selloff In-Reply-To: <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> Message-ID: <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> Might be a good time: I remember my dad saying I should encase each one in lucite plastic and sell them as paperweights. That was 30 years ago but it would have preserved them well :-) C (Went from 3 8/I's to 2 8/L's so progress?) On 2/2/2021 1:22 PM, Zane Healy via cctalk wrote: > On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk wrote: >> >> I don't have any equipment that uses them any more, so I'll be ebaying off my >> A-W series flip chips over the next few days. The W's and PT08 boards are up now >> >> https://www.ebay.com/itm/184647476832 >> https://www.ebay.com/itm/184647420812 > > That makes me wonder if I shouldn?t do the same. That would be part of a camera lens, which may, or may not take up less space. :-) > > Then again I?ve been saying I need to downsize my collection for the better part of 20 years. > > Zane > > > From rsmilward at frontier.com Tue Feb 2 12:56:12 2021 From: rsmilward at frontier.com (Richard Milward) Date: Tue, 2 Feb 2021 13:56:12 -0500 Subject: HP Journal back issues References: <45c1f586-5325-3136-3d59-7f200c0de079.ref@frontier.com> Message-ID: <45c1f586-5325-3136-3d59-7f200c0de079@frontier.com> You can find HP Journal issues at https://worldradiohistory.com/HP-Journal.htm The World Radio History site is a fantastic resource in general, I use it regularly. **Richard From emu at e-bbes.com Tue Feb 2 12:56:44 2021 From: emu at e-bbes.com (emanuel stiebler) Date: Tue, 2 Feb 2021 13:56:44 -0500 Subject: Greaseweazle In-Reply-To: <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: <1ecae771-599d-f662-c4cb-50d3f79321ab@e-bbes.com> On 2021-02-02 12:20, Chuck Guzis via cctalk wrote: > When I last proposed the STM32F407, I was met with "Oh, but the Blue > Pill is cheaper". Okay, use the Blue Pill, but my code won't work with > it. Not once has anyone contacted me and said "I'd like to try my hand > at doing this, what can you tell me?". I've described the methodology > of using an MCU elsewhere several times. > --Chuck Not true ;-) You told me how to use it, and I got some boards, and played with the stm32f407. Then went the ESP32 route, and now trying RbPi-CM4, which looks promising, as it is dirt cheap and powerful. So, some people listen ;-) From sieler at allegro.com Tue Feb 2 13:35:40 2021 From: sieler at allegro.com (Stan Sieler) Date: Tue, 2 Feb 2021 11:35:40 -0800 Subject: NOT "Re: APL\360" In-Reply-To: References: Message-ID: TL;DR: getting tired of separating the wheat from the chaff I have an odd but potentially useful idea for the list server ... Until we have an AI that can properly read a message and re-write the subject line, perhaps the list server would *auto generate* a new subject line after, say, the 29th reply with the same "Re:". After 29 "Re: APL\360", the next such msg would have subject line rewritten to "New topic 1", and the next (up to) 28 "Re: APL\360" would be similarly re-written (the '28' is decremented for every "Re: APL\360" and every "Re: New topic 1"). At that point, the next "Re: APL\360" or next "Re: New topic 1" gets rewritten as "New topic 2". (After a reuse counter for a subject has been 0 for two weeks, it could be reset to 20, to allow much later legitimate replies.) Yeah, tired of getting hopeful seeing "Re: APL\360" and seeing instead a discussion of pints, or endianness (big rules, for a number of reasons ... *even the creator of Intels's memory chip admitted that*), or bit numbering, or counting sheep! :) (And I'm not even complaining about the needless copying of the entire prior post :) From mattislind at gmail.com Tue Feb 2 13:53:21 2021 From: mattislind at gmail.com (Mattis Lind) Date: Tue, 2 Feb 2021 20:53:21 +0100 Subject: Greaseweazle In-Reply-To: <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: > Uh, I think over the decades, I've contributed a bit, no? I recently > made my own Catweasel source code public, for example. I've helped out > the guy with the fluxengine puzzle out a couple of formats, including > the Brother 240K one that few seem to have sussed out. > I am still using a Cateweasel mk 1 and would be very interested in studying your source code. Do you have a URL? From jnc at mercury.lcs.mit.edu Tue Feb 2 15:12:40 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 2 Feb 2021 16:12:40 -0500 (EST) Subject: DEC backplane power connectors Message-ID: <20210202211240.9740718C086@mercury.lcs.mit.edu> > I'm too burned out to look at the engineering drawings and get the part > number to confirm; I'll do that 'soon'. The BA11-K FMPS gives the male shell part numbers as 12-09350-06 and -15; the DD11-C lists the female shell numbers as 12-09351-06 and -15. Those look like they are DEC numbers: https://gunkies.org/wiki/DEC_part_numbers So I'm not sure those are much use. (I'm not going to bother trying to look up what they translate too; we already have the AMP numbers needed to order them; so not much to be gained.) > I took a picture of the male shells, and added it to the CHWiki page > (I'll add the females tomorrow). Done. Noel From bobsmithofd at gmail.com Tue Feb 2 15:13:18 2021 From: bobsmithofd at gmail.com (Bob Smith) Date: Tue, 2 Feb 2021 16:13:18 -0500 Subject: Flip-Chip selloff In-Reply-To: <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> Message-ID: I am down to 2 vaxes and an 11, along with 10 Alphas, a pro380 and two DECMante II boxes. bb On Tue, Feb 2, 2021 at 1:48 PM Chris Zach via cctalk wrote: > > Might be a good time: I remember my dad saying I should encase each one > in lucite plastic and sell them as paperweights. That was 30 years ago > but it would have preserved them well :-) > > C > (Went from 3 8/I's to 2 8/L's so progress?) > > On 2/2/2021 1:22 PM, Zane Healy via cctalk wrote: > > On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk wrote: > >> > >> I don't have any equipment that uses them any more, so I'll be ebaying off my > >> A-W series flip chips over the next few days. The W's and PT08 boards are up now > >> > >> https://www.ebay.com/itm/184647476832 > >> https://www.ebay.com/itm/184647420812 > > > > That makes me wonder if I shouldn?t do the same. That would be part of a camera lens, which may, or may not take up less space. :-) > > > > Then again I?ve been saying I need to downsize my collection for the better part of 20 years. > > > > Zane > > > > > > From bobsmithofd at gmail.com Tue Feb 2 15:14:26 2021 From: bobsmithofd at gmail.com (Bob Smith) Date: Tue, 2 Feb 2021 16:14:26 -0500 Subject: Flip-Chip selloff In-Reply-To: References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> Message-ID: Oh, and 2 8/a boxes, but i did move out 15 Vaxes of various times and an 8e that someone refuse to admit I gave them. bb On Tue, Feb 2, 2021 at 4:13 PM Bob Smith wrote: > > I am down to 2 vaxes and an 11, along with 10 Alphas, a pro380 and two > DECMante II boxes. > bb > > On Tue, Feb 2, 2021 at 1:48 PM Chris Zach via cctalk > wrote: > > > > Might be a good time: I remember my dad saying I should encase each one > > in lucite plastic and sell them as paperweights. That was 30 years ago > > but it would have preserved them well :-) > > > > C > > (Went from 3 8/I's to 2 8/L's so progress?) > > > > On 2/2/2021 1:22 PM, Zane Healy via cctalk wrote: > > > On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk wrote: > > >> > > >> I don't have any equipment that uses them any more, so I'll be ebaying off my > > >> A-W series flip chips over the next few days. The W's and PT08 boards are up now > > >> > > >> https://www.ebay.com/itm/184647476832 > > >> https://www.ebay.com/itm/184647420812 > > > > > > That makes me wonder if I shouldn?t do the same. That would be part of a camera lens, which may, or may not take up less space. :-) > > > > > > Then again I?ve been saying I need to downsize my collection for the better part of 20 years. > > > > > > Zane > > > > > > > > > From cz at alembic.crystel.com Tue Feb 2 16:57:27 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 2 Feb 2021 17:57:27 -0500 Subject: Flip-Chip selloff In-Reply-To: References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> Message-ID: <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> What do I have... Decsystem/20 CPU box+supply (blt.ai.mit.edu), pdp11/05/83/24/23+/150, 2 8L's, an 8/e, 3 RL02, RM80, RX02,TK50,2 Professional 380's. And a Minc-11/MiniMINC. Several Perqs, that HP 1000e thing, and a few dozen MFM disks. A pair of Sun 386i's, Nextstation, NS Turbo, Turbo Color Probably a lot more. On 2/2/2021 4:13 PM, Bob Smith wrote: > I am down to 2 vaxes and an 11, along with 10 Alphas, a pro380 and two > DECMante II boxes. > bb > > On Tue, Feb 2, 2021 at 1:48 PM Chris Zach via cctalk > wrote: >> >> Might be a good time: I remember my dad saying I should encase each one >> in lucite plastic and sell them as paperweights. That was 30 years ago >> but it would have preserved them well :-) >> >> C >> (Went from 3 8/I's to 2 8/L's so progress?) >> >> On 2/2/2021 1:22 PM, Zane Healy via cctalk wrote: >>> On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk wrote: >>>> >>>> I don't have any equipment that uses them any more, so I'll be ebaying off my >>>> A-W series flip chips over the next few days. The W's and PT08 boards are up now >>>> >>>> https://www.ebay.com/itm/184647476832 >>>> https://www.ebay.com/itm/184647420812 >>> >>> That makes me wonder if I shouldn?t do the same. That would be part of a camera lens, which may, or may not take up less space. :-) >>> >>> Then again I?ve been saying I need to downsize my collection for the better part of 20 years. >>> >>> Zane >>> >>> >>> From billdegnan at gmail.com Tue Feb 2 17:12:15 2021 From: billdegnan at gmail.com (Bill Degnan) Date: Tue, 2 Feb 2021 18:12:15 -0500 Subject: Flip-Chip selloff In-Reply-To: <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> Message-ID: I think it's good to hold onto that which is realistic to support, no point in holding hardware hostage in a rodent and moisture-vulnerable old garage. We don't live forever. b On Tue, Feb 2, 2021 at 5:57 PM Chris Zach via cctalk wrote: > What do I have... > > Decsystem/20 CPU box+supply (blt.ai.mit.edu), pdp11/05/83/24/23+/150, 2 > 8L's, an 8/e, 3 RL02, RM80, RX02,TK50,2 Professional 380's. And a > Minc-11/MiniMINC. > > Several Perqs, that HP 1000e thing, and a few dozen MFM disks. > > A pair of Sun 386i's, Nextstation, NS Turbo, Turbo Color > > Probably a lot more. > > On 2/2/2021 4:13 PM, Bob Smith wrote: > > I am down to 2 vaxes and an 11, along with 10 Alphas, a pro380 and two > > DECMante II boxes. > > bb > > > > On Tue, Feb 2, 2021 at 1:48 PM Chris Zach via cctalk > > wrote: > >> > >> Might be a good time: I remember my dad saying I should encase each one > >> in lucite plastic and sell them as paperweights. That was 30 years ago > >> but it would have preserved them well :-) > >> > >> C > >> (Went from 3 8/I's to 2 8/L's so progress?) > >> > >> On 2/2/2021 1:22 PM, Zane Healy via cctalk wrote: > >>> On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk < > cctalk at classiccmp.org> wrote: > >>>> > >>>> I don't have any equipment that uses them any more, so I'll be > ebaying off my > >>>> A-W series flip chips over the next few days. The W's and PT08 boards > are up now > >>>> > >>>> https://www.ebay.com/itm/184647476832 > >>>> https://www.ebay.com/itm/184647420812 > >>> > >>> That makes me wonder if I shouldn?t do the same. That would be part > of a camera lens, which may, or may not take up less space. :-) > >>> > >>> Then again I?ve been saying I need to downsize my collection for the > better part of 20 years. > >>> > >>> Zane > >>> > >>> > >>> > From derschjo at gmail.com Tue Feb 2 17:28:38 2021 From: derschjo at gmail.com (Josh Dersch) Date: Tue, 2 Feb 2021 15:28:38 -0800 Subject: Flip-Chip selloff In-Reply-To: References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> Message-ID: Since we're talkin' sell-off... on the off chance that anyone has a TC11 or TC01/08 gathering dust (for something less than eBay prices), I, uh... could use one. Along with many other people, I suppose. - Josh On Tue, Feb 2, 2021 at 3:12 PM Bill Degnan via cctalk wrote: > I think it's good to hold onto that which is realistic to support, no point > in holding hardware hostage in a rodent and moisture-vulnerable old > garage. We don't live forever. > b > > On Tue, Feb 2, 2021 at 5:57 PM Chris Zach via cctalk < > cctalk at classiccmp.org> > wrote: > > > What do I have... > > > > Decsystem/20 CPU box+supply (blt.ai.mit.edu), pdp11/05/83/24/23+/150, 2 > > 8L's, an 8/e, 3 RL02, RM80, RX02,TK50,2 Professional 380's. And a > > Minc-11/MiniMINC. > > > > Several Perqs, that HP 1000e thing, and a few dozen MFM disks. > > > > A pair of Sun 386i's, Nextstation, NS Turbo, Turbo Color > > > > Probably a lot more. > > > > On 2/2/2021 4:13 PM, Bob Smith wrote: > > > I am down to 2 vaxes and an 11, along with 10 Alphas, a pro380 and two > > > DECMante II boxes. > > > bb > > > > > > On Tue, Feb 2, 2021 at 1:48 PM Chris Zach via cctalk > > > wrote: > > >> > > >> Might be a good time: I remember my dad saying I should encase each > one > > >> in lucite plastic and sell them as paperweights. That was 30 years ago > > >> but it would have preserved them well :-) > > >> > > >> C > > >> (Went from 3 8/I's to 2 8/L's so progress?) > > >> > > >> On 2/2/2021 1:22 PM, Zane Healy via cctalk wrote: > > >>> On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk < > > cctalk at classiccmp.org> wrote: > > >>>> > > >>>> I don't have any equipment that uses them any more, so I'll be > > ebaying off my > > >>>> A-W series flip chips over the next few days. The W's and PT08 > boards > > are up now > > >>>> > > >>>> https://www.ebay.com/itm/184647476832 > > >>>> https://www.ebay.com/itm/184647420812 > > >>> > > >>> That makes me wonder if I shouldn?t do the same. That would be part > > of a camera lens, which may, or may not take up less space. :-) > > >>> > > >>> Then again I?ve been saying I need to downsize my collection for the > > better part of 20 years. > > >>> > > >>> Zane > > >>> > > >>> > > >>> > > > From cz at alembic.crystel.com Tue Feb 2 18:08:39 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 2 Feb 2021 19:08:39 -0500 Subject: Flip-Chip selloff In-Reply-To: References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> Message-ID: I can pretty much support any of the Dec stuff, with all of the pdp11's running now the next step is to get the 8/L working, then the 20. The Perqs and other stuff will be re-homed or sold. But I'm not giving things to "museums". At this point between museums blowing up, being shut down, selling "donations" on Ebay and literally stealing stuff I have a bit of a bad taste in my mouth from so called "museums". CZ From tingox at gmail.com Tue Feb 2 18:11:58 2021 From: tingox at gmail.com (Torfinn Ingolfsen) Date: Wed, 3 Feb 2021 01:11:58 +0100 Subject: Greaseweazle In-Reply-To: <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> Message-ID: On Tue, Feb 2, 2021 at 2:08 AM Antonio Carlini via cctalk wrote: > > On 02/02/2021 00:13, Chuck Guzis via cctalk wrote: > > > > There's also a similar implementation using a very inexpensive Cypress > > PSOC 6 ARM card that mounts on a 3.5" floppy connector (no cable). > > That would presumably be the FluxEngine > (http://cowlark.com/fluxengine/index.html). > I've used the FluxEngine to read 3.5 inch, 5.25 inch and 8 inch floppies. I've used the GreasleWeazle to read 5.25 inch floppies so far. I haven't tried either of them to write floppies yet. The main difference in workflow is that the gw software only writes one type of format - SCP, so you will need another tool to convert to raw or a different format, if you can't use scp directly. Currently, the thing I find most interesting right now is that the FluxEngine software can use GreaseWeazle hardware (supposedly for most things) - I haven't tested that yet. -- Regards, Torfinn Ingolfsen From linimon at lonesome.com Tue Feb 2 18:38:54 2021 From: linimon at lonesome.com (Mark Linimon) Date: Wed, 3 Feb 2021 00:38:54 +0000 Subject: Flip-Chip selloff In-Reply-To: <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> Message-ID: <20210203003854.GA25965@lonesome.com> On Tue, Feb 02, 2021 at 05:57:27PM -0500, Chris Zach via cctalk wrote: > Probably a lot more. "Probably" ??? Sheesh. I thought *I* had too many projects. mcl From steven at malikoff.com Tue Feb 2 18:55:06 2021 From: steven at malikoff.com (steven at malikoff.com) Date: Wed, 3 Feb 2021 10:55:06 +1000 Subject: Flip-Chip selloff In-Reply-To: References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> Message-ID: <8114ce37114daf51ba2e1ebf548f2d9f.squirrel@webmail04.register.com> Chris said > I can pretty much support any of the Dec stuff, with all of the pdp11's > running now the next step is to get the 8/L working, then the 20. The > Perqs and other stuff will be re-homed or sold. > > But I'm not giving things to "museums". At this point between museums > blowing up, being shut down, selling "donations" on Ebay and literally > stealing stuff I have a bit of a bad taste in my mouth from so called > "museums". > > CZ Fair points... I've got about 80 or so R, W, S, A flip-chips and some 18" Negibus(?) cables perhaps I should do something about. And enough DEC workstation and DEC-compatible mice that I just weighed them in kg. Cataloging them would be a good start I guess. Also some other old flip-chip backplanes with more modules, and a 1968(?) DEC A/D converter and so on. I've traded some stuff for PDP-11-related items last year, and I would prefer to swap but I've found that notion does not sit well with some museums, to my surprise. Offers to claim as US tax write-offs isn't of any use to me here in Oz. Steve. From bfranchuk at jetnet.ab.ca Tue Feb 2 20:19:11 2021 From: bfranchuk at jetnet.ab.ca (ben) Date: Tue, 2 Feb 2021 19:19:11 -0700 Subject: APL\360 In-Reply-To: References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: <6ce88b55-5311-a44e-1ed4-9100a876863d@jetnet.ab.ca> On 2/1/2021 12:15 PM, Liam Proven via cctalk wrote: > On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk > wrote: >> >> I had always been told, "A pint is a pound, the world around." > > Aha! Does that mean a pint of water weighs 1lb? > > Interesting. I did not know. Who Knows? It just works of beer or ale. :) > Ben. From cz at alembic.crystel.com Tue Feb 2 21:10:14 2021 From: cz at alembic.crystel.com (Christopher Zach) Date: Tue, 2 Feb 2021 19:10:14 -0800 Subject: Flip-Chip selloff In-Reply-To: <20210203003854.GA25965@lonesome.com> References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> <20210203003854.GA25965@lonesome.com> Message-ID: I've had 30+ years to acquire this "stuff". :-) On 2/2/2021 4:38 PM, Mark Linimon wrote: > On Tue, Feb 02, 2021 at 05:57:27PM -0500, Chris Zach via cctalk wrote: >> Probably a lot more. > "Probably" ??? > > Sheesh. I thought *I* had too many projects. > > mcl From bfranchuk at jetnet.ab.ca Tue Feb 2 21:50:56 2021 From: bfranchuk at jetnet.ab.ca (ben) Date: Tue, 2 Feb 2021 20:50:56 -0700 Subject: APL\360 In-Reply-To: References: <69a83b09-b765-077f-d336-b03e55fa771c@gmail.com> <0bca4061-e671-4613-47c7-572b202ef8ab@telegraphics.com.au> <3246ff52-751e-14f1-a464-fd9288aba256@jetnet.ab.ca> Message-ID: <5f9ee15a-0406-1a3b-0106-4dfde62872a6@jetnet.ab.ca> On 2/1/2021 6:07 AM, Peter Corlett via cctalk wrote: > On Wed, Jan 20, 2021 at 02:05:37PM -0700, ben via cctalk wrote: > [...] >> I don't see languages in general have improved since the the mid >> 1960's. Hardware and language models don't reflect each other, >> and don't have extendable data sizes and types. >> PL/I seems to have been the best,but too tied to IBM. >> C standard 2131 complex numbers >> C standard 2143 dubble complex numbers >> Every machine I can think of had a carry flag of some type >> yet no language uses that to extend it self. > > You're describing a failing in C and similar languages stuck in the 1960s. > Here's a Rust method that does add-exposing-carry: > > https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.overflowing_add > So why could this not have been done 30 earlier? > The documentation doesn't explicitly say "carry" because Rust is > architecture-neutral and it's down to LLVM to decide how to express it in > machine code, but on x86 (and probably ARM) the boolean return value comes > directly from the carry flag. mincing words, sigh. >> I don't believe in objects because data structures don't have classes, but >> are more similar to each other. A window A structure is like window B but >> details are different. That makes things look portable when they are not. > >> Constants still >> seem to be embedded in data structures, rather than abstract. >> -- zero array >> define LIMIT abc >> blah array[LIMIT] >> ... >> i = 0 while i< LIMIT array[i] = 0 i = i + 1 endw >> I would like say >> let LIMIT = abc >> blah array[LIMIT] >> i = 0 while i< array:LIMIT array[i] = 0 i = i + 1 endw > > You "don't believe in objects" yet then describe a problem which only exists > due to the lack of them and then present OO pseudocode to solve it. A lot of > OO languages suck of course, but the fundamental idea of encapsulation is > not the bit that sucks. Are objects? they only way to solve this problem. I see a object as data structure tied to some code. What I would like to see data structures having fixed constants like array start and end of a structure for a array as variables when called into use. Here's it in Rust, where it takes in an arbitrary > array (pedantically, "slice", a (pointer, element count)-tuple) and > determines its length at runtime: > > pub fn clear_indexed(array: &mut [usize]) { > for index in 0 .. array.len() { > array[index] = 0; > } > } I don't want Information hiding, I want to know what it does clearly. If I can't figure it out how can a computer program do it. Where does ".len()" find the size? > (The code for C-style fixed-length arrays looks broadly similar but has a > bit more boilerplate because they're less useful.) > > Iterating over indices is generally discouraged for a number of reasons, not > least being that the index may be out-of-bounds, but also because it can > inhibit vectorisation or parallelisation. You have no choice in broken > languages such as C, but many languages provide some notion of iteration > which guarantees to not go out-of-bounds: I say the 0 index in C is broken. ... for array size is better. > pub fn clear_iterator(array: &mut [usize]) { > for elem in array { > *elem = 0; > } > } > Both code fragments generate equivalent assembly in this trivial example > because the Rust compiler could prove at compile time that the index > variable can't go out-of-bounds. In more complex real-world code it cannot > reliably do so and will insert a run-time check which aborts if the index is > out-of-bounds. Or if it's C, trundle on and corrupt things. > Why prove it? Just test it at runtime. C was quick and dirty language that had to shoe horn into UNIX, with structures tacked on at the last minute. It was up to the programmer not the language to check things, and I still see that valid. > Oddly enough, the state of the art has moved on a bit in the half-century > since C was invented. It's just that quite a lot of programmers haven't yet > noticed. > More like SEARCH programming languages USE JAVA USE C SPONSORED BY SEARCH RUST PROGRAM not many items with 'program' ignoring keyword "Ford truck 5K miles for sale, some rust on the fender" I have not done programming since about 1990, so modern stuff don't have clue,nor do I have large powerful machine. Ben. From abuse at cabal.org.uk Wed Feb 3 01:51:45 2021 From: abuse at cabal.org.uk (Peter Corlett) Date: Wed, 3 Feb 2021 08:51:45 +0100 Subject: Greaseweazle In-Reply-To: <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: On Tue, Feb 02, 2021 at 09:20:01AM -0800, Chuck Guzis via cctalk wrote: [...] > When I last proposed the STM32F407, I was met with "Oh, but the Blue Pill > is cheaper". Okay, use the Blue Pill, but my code won't work with it. Not > once has anyone contacted me and said "I'd like to try my hand at doing > this, what can you tell me?". I've described the methodology of using an > MCU elsewhere several times. I have a pile of Blue Pill boards, and using it to read floppies was an obvious application. However after running the numbers, it turned out there isn't enough RAM to buffer an entire track from a HD floppy. It also has a broken USB implementation just to liven things up a bit. The Raspberry Pi Pico has a similar price to the Blue Pill and seems a much better machine for this task, although I haven't combed through its reference manual yet. From jwsmail at jwsss.com Wed Feb 3 03:09:50 2021 From: jwsmail at jwsss.com (jim stephens) Date: Wed, 3 Feb 2021 01:09:50 -0800 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: On 2/2/2021 11:51 PM, Peter Corlett via cctalk wrote: > The Raspberry Pi Pico has a similar price to the Blue Pill and seems a much > better machine for this task, although I haven't combed through its > reference manual yet. For capture and writing (if that's part of the design) I heard there's a dedicated coprocessor for the GPIO pins.? It might be useful for offloading some of the proccessing from some external circuitry to do the capture or output. I don't know what's included for the capabilities.? And apparently since the chip is new, there's only assembler programming for it now. There's a video comparing the Pico, ESP32, ESP32-S and Blue Pill. The latter was a bit low in resources compared to the others. I'll try to find it and post it if anyone's interested. thanks Jim From couryhouse at aol.com Wed Feb 3 03:25:17 2021 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 3 Feb 2021 09:25:17 +0000 (UTC) Subject: HP Journal back issues References: <721961577.1933451.1612344317479.ref@mail.yahoo.com> Message-ID: <721961577.1933451.1612344317479@mail.yahoo.com> Indeed this site is great for reference but alas are too lo-res for good museum display images. I do use this as a reference source? but need paper copies sometimes? to hi res scan some times! Ed# On Tuesday, February 2, 2021 Richard Milward via cctalk wrote: You can find HP Journal issues at https://worldradiohistory.com/HP-Journal.htm The World Radio History site is a fantastic resource in general, I use it regularly. **Richard From enrico.lazzerini at email.it Wed Feb 3 03:43:48 2021 From: enrico.lazzerini at email.it (Enrico email.it) Date: Wed, 3 Feb 2021 10:43:48 +0100 Subject: Winchester SA1004 file recovering In-Reply-To: <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> Message-ID: <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> Hello everyone, in Italy in 1981 there was an explosion in creating new machines following the introduction of microprocessors. I have several "General Processor T-Model" machines that used CP / M 2.2 operating system. Here you can see the photos of the 1st acquisition https://www.vintagesbc.it/wp-content/uploads/2012/10/Foto3775.jpg (this is a master machine with modified CP/M system that provides shared resources via rs232 to two slave machines) and the 2nd acquisition https://www.vintagesbc.it/wp-content/uploads/2012/10/Foto3430.jpg (these are two compositions: a machine with CP/M system with a pair of BASF 6104 drives and a second machine with an HD + FD 8" box and a further box with a pair of REMEX RFD4000 8" drives). The machines of the second acquisition were in a better condition. A very dear friend first read in raw mode a 10MB Winchester hard disk model Shugard SA1004 from which the files were correctly extracted and then set up a test bench from which you can see in this video the complete system operating with the HD ed il controller Shugart SASI SA1403: https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov a.mp4?dl=0 The problem arose later when we tried to extract the raw file from the 10MB Winchester hard disk model Shugard SA1004 of the 1st acquisition in the same way. Visually, the hard disk had certainly suffered atmospheric damage, but the electronic boards were functioning correctly. Despite we having attempted different readings (even using cards from the first hard disk), using the same FLUXengine card (http://cowlark.com/fluxengine/doc/building.html) the raw file still does not present the Hard Disk directory, instead we read the information of the files present but there may be bad bytes in these files and in the rest of the disk as well. Unfortunately this content is unique in its kind and we would like at least to extract the operating system and/or the files of its initialization in order to be able to correctly reproduce the functioning of this system. The last option would be to take the hard drive to a clean room hoping that the hard drive platters are not scratched. Any suggestion? Enrico - Pisa (ITALY) From enrico.lazzerini at email.it Wed Feb 3 04:04:10 2021 From: enrico.lazzerini at email.it (Enrico email.it) Date: Wed, 3 Feb 2021 11:04:10 +0100 Subject: R: Winchester SA1004 file recovering In-Reply-To: <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> Message-ID: <9F3658C7629A4FD0BA98E493D709396C@Enrico> Correct addess of the video test: https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov a.mp4?dl=0 The email cuts the link address to the video file. please join the first with the second piece and paste it in your browser. Enrico From cc at informatik.uni-stuttgart.de Wed Feb 3 05:00:52 2021 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Wed, 3 Feb 2021 12:00:52 +0100 (CET) Subject: Greaseweazle In-Reply-To: <83edd3fd-250c-6783-d81a-6001af81b144@bitsavers.org> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <242c44be-3938-f1ea-4815-ec2b50d7d14b@bitsavers.org> <83edd3fd-250c-6783-d81a-6001af81b144@bitsavers.org> Message-ID: On Tue, 2 Feb 2021, Al Kossow wrote: > Do you make these available online? > > I found your version of IMD here > ftp://computermuseum.informatik.uni-stuttgart.de/utils > not under source control. Ups, I see that this is a very old version. I'll update this with my current version and I'll write some notes on the usage etc. But it will need some time, the source is on my PC at work and currently doing home office. > I hate the fact that there are dozens of siloed projects in this problem > space. Yes, me too. It started several years ago as a "quick" way of imaging floppys on my PC that obviously is Linux only. But now, I think I could just publish it and have everyone play with it :-) Christian From cc at informatik.uni-stuttgart.de Wed Feb 3 05:03:27 2021 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Wed, 3 Feb 2021 12:03:27 +0100 (CET) Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202013739.8C18A2737F@mx1.ezwind.net> <85ea1ece-7d48-b7dc-f205-491481123126@bitsavers.org> <20210202021740.10D384E6C4@mx2.ezwind.net> <2ca2961f-b7cd-99ba-e5e3-cb5bfd062632@bitsavers.org> <92d19cb9-d55f-7b75-331e-b328f711b62e@jwsss.com> Message-ID: On Tue, 2 Feb 2021, Al Kossow wrote: > Copy protection is just a pain in the ass. > > A tiny, tiny fraction of what I work with has any and > I'm very happy it is mostly used on consumer computers > which are being archived by others so I don't have to. :-)) This is also my attitude. I just don't care about fancy copy protection schemes, it is not my domain. Christian From jwsmail at jwsss.com Wed Feb 3 05:17:31 2021 From: jwsmail at jwsss.com (jim stephens) Date: Wed, 3 Feb 2021 03:17:31 -0800 Subject: Winchester SA1004 file recovering In-Reply-To: <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> Message-ID: <8f048068-4ac8-9486-3247-c053db27be4a@jwsss.com> On 2/3/2021 1:43 AM, Enrico email.it via cctalk wrote: > Any suggestion? I believe Dave G's MFM emulator has an option to support the SA1000. I have one in stock for a future project to try to extract data from SA-1000's in DSD floppy / 8" drive subsystems. https://www.pdp8.net/mfm/mfm.shtml info is there about the SA-1000. If you are having problems because the drives are dead, this won't help.? It will inhale the contents and with luck you can extract data. I know with the ST-506 configuration of his hardware, you can then use the emulator to replace the SA-1000. If you need to recover the data, you may be out of luck, but if you need a "working" SA-1000 and can format it from utilities, then this may help. thanks Jim From aek at bitsavers.org Wed Feb 3 06:25:27 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 04:25:27 -0800 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: On 2/2/21 11:51 PM, Peter Corlett via cctalk wrote: > I have a pile of Blue Pill boards, and using it to read floppies was an > obvious application. However after running the numbers, it turned out there > isn't enough RAM to buffer an entire track from a HD floppy. It also has a > broken USB implementation just to liven things up a bit. a small performance list of STM32 parts and where they are used STM32F103C8T6 72MHz M3 64K Flash 20K RAM FS Original blue pill STM32F411CEV6 100MHz M4 512K Flash 128K RAM FS Latest WeAct black pill STM32F407VET6 168MHz M4 512K Flash 196K RAM HS Board Chuck likes STM32F730x8T6 216MHz M7 64K Flash 176K RAM HS Eric's GW / GW Lightning From mattislind at gmail.com Wed Feb 3 07:01:34 2021 From: mattislind at gmail.com (Mattis Lind) Date: Wed, 3 Feb 2021 14:01:34 +0100 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: Den ons 3 feb. 2021 kl 13:25 skrev Al Kossow via cctalk < cctalk at classiccmp.org>: > On 2/2/21 11:51 PM, Peter Corlett via cctalk wrote: > > > I have a pile of Blue Pill boards, and using it to read floppies was an > > obvious application. However after running the numbers, it turned out > there > > isn't enough RAM to buffer an entire track from a HD floppy. It also has > a > > broken USB implementation just to liven things up a bit. > > a small performance list of STM32 parts and where they are used > > STM32F103C8T6 72MHz M3 64K Flash 20K RAM FS Original blue pill > STM32F411CEV6 100MHz M4 512K Flash 128K RAM FS Latest WeAct black pill > STM32F407VET6 168MHz M4 512K Flash 196K RAM HS Board Chuck likes > STM32F730x8T6 216MHz M7 64K Flash 176K RAM HS Eric's GW / GW > Lightning > The performance difference between the STM32F103 and any of the M4 (and M7) chips is even bigger (than what the MHz tell) since there is a small cache in the M4 (and M7) called ART which is intended to give close to zero wait states when reading from flash. The STM32F103 has 2 wait states on flash reads when running at 72 MHz. Unless you put code the code in RAM there will be a performance hit on the 103. Unfortunately RAM is a scarce resource on the 103 as well so you have to plan well to do that. If one wants more buffer memory there is also the STM32F407ZET board which uses the bigger 144 pin chip. On the back of those boards are pads for a ISSI IS62WV51216 chip 512k x 16 chip. What I think is kind of strange with the WeAct board is that they are not identical in pinout to the blue pills. On one side all the pins are shifted on step. I have no idea why they designed it that way. From paulkoning at comcast.net Wed Feb 3 08:06:30 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 3 Feb 2021 09:06:30 -0500 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: > On Feb 3, 2021, at 2:51 AM, Peter Corlett via cctalk wrote: > > On Tue, Feb 02, 2021 at 09:20:01AM -0800, Chuck Guzis via cctalk wrote: > [...] >> When I last proposed the STM32F407, I was met with "Oh, but the Blue Pill >> is cheaper". Okay, use the Blue Pill, but my code won't work with it. Not >> once has anyone contacted me and said "I'd like to try my hand at doing >> this, what can you tell me?". I've described the methodology of using an >> MCU elsewhere several times. > > I have a pile of Blue Pill boards, and using it to read floppies was an > obvious application. However after running the numbers, it turned out there > isn't enough RAM to buffer an entire track from a HD floppy. It also has a > broken USB implementation just to liven things up a bit. > > The Raspberry Pi Pico has a similar price to the Blue Pill and seems a much > better machine for this task, although I haven't combed through its > reference manual yet. I haven't used RPi at all, since when I looked at it some years ago the SOC technical information was secret. Contrast the BeagleBone, for which there is a 5000 page manual. In any case, for work like this an Ardiuno might be sufficient and quite possibly easier to use. I've used the ARM based Arduinos, they have quite a lot more memory, faster execution, and native USB. In fact (if you should need it for something else) host side USB, not just device side. The Adafruit "Trinket" is great for cases where not much I/O is needed; there are a variety of others that have a dozen or so I/O connections, all for $10 or thereabouts. paul From enrico.lazzerini at email.it Wed Feb 3 07:36:55 2021 From: enrico.lazzerini at email.it (Enrico email.it) Date: Wed, 3 Feb 2021 14:36:55 +0100 Subject: R: Winchester SA1004 file recovering In-Reply-To: <8f048068-4ac8-9486-3247-c053db27be4a@jwsss.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> <8f048068-4ac8-9486-3247-c053db27be4a@jwsss.com> Message-ID: <2C72C619A3824859BF01C03552664CB0@Enrico> It's a bit very expensive to shipping a SA-1000 from U.S. to Italy.... almost over than 200 USD -----Messaggio originale----- Da: cctech [mailto:cctech-bounces at classiccmp.org] Per conto di jim stephens via cctech Inviato: mercoled? 3 febbraio 2021 12:18 A: Enrico email.it via cctalk Oggetto: Re: Winchester SA1004 file recovering On 2/3/2021 1:43 AM, Enrico email.it via cctalk wrote: > Any suggestion? I believe Dave G's MFM emulator has an option to support the SA1000. I have one in stock for a future project to try to extract data from SA-1000's in DSD floppy / 8" drive subsystems. https://www.pdp8.net/mfm/mfm.shtml info is there about the SA-1000. If you are having problems because the drives are dead, this won't help.? It will inhale the contents and with luck you can extract data. I know with the ST-506 configuration of his hardware, you can then use the emulator to replace the SA-1000. If you need to recover the data, you may be out of luck, but if you need a "working" SA-1000 and can format it from utilities, then this may help. thanks Jim From mattislind at gmail.com Wed Feb 3 08:53:31 2021 From: mattislind at gmail.com (Mattis Lind) Date: Wed, 3 Feb 2021 15:53:31 +0100 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: Den ons 3 feb. 2021 kl 15:07 skrev Paul Koning via cctalk < cctalk at classiccmp.org>: > > > > On Feb 3, 2021, at 2:51 AM, Peter Corlett via cctalk < > cctalk at classiccmp.org> wrote: > > > > On Tue, Feb 02, 2021 at 09:20:01AM -0800, Chuck Guzis via cctalk wrote: > > [...] > >> When I last proposed the STM32F407, I was met with "Oh, but the Blue > Pill > >> is cheaper". Okay, use the Blue Pill, but my code won't work with it. > Not > >> once has anyone contacted me and said "I'd like to try my hand at doing > >> this, what can you tell me?". I've described the methodology of using an > >> MCU elsewhere several times. > > > > I have a pile of Blue Pill boards, and using it to read floppies was an > > obvious application. However after running the numbers, it turned out > there > > isn't enough RAM to buffer an entire track from a HD floppy. It also has > a > > broken USB implementation just to liven things up a bit. > > > > The Raspberry Pi Pico has a similar price to the Blue Pill and seems a > much > > better machine for this task, although I haven't combed through its > > reference manual yet. > > I haven't used RPi at all, since when I looked at it some years ago the > SOC technical information was secret. Contrast the BeagleBone, for which > there is a 5000 page manual. > The Pico is quite different. They use their own chip for the Pico, the RP2040. There is a 637 page manual https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf Unlike the other Rpi this is more like the STM32 chips where you develop C/C++ or Python to run directly on the bare metal. No Linux involved. The early Rpi used Broadcom chips. And like most Broadcom stuff you almost needed signing a NDA to get a glance of the pinout of the chip. > > In any case, for work like this an Ardiuno might be sufficient and quite > possibly easier to use. I've used the ARM based Arduinos, they have quite > a lot more memory, faster execution, and native USB. In fact (if you > should need it for something else) host side USB, not just device side. > The Adafruit "Trinket" is great for cases where not much I/O is needed; > there are a variety of others that have a dozen or so I/O connections, all > for $10 or thereabouts. > > paul > > From paulkoning at comcast.net Wed Feb 3 08:58:11 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 3 Feb 2021 09:58:11 -0500 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: > On Feb 3, 2021, at 9:53 AM, Mattis Lind wrote: > > Den ons 3 feb. 2021 kl 15:07 skrev Paul Koning via cctalk : > > ... >> I haven't used RPi at all, since when I looked at it some years ago the SOC technical information was secret. Contrast the BeagleBone, for which there is a 5000 page manual. >> > The Pico is quite different. They use their own chip for the Pico, the RP2040. There is a 637 page manual https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf Nice to know. Thanks! > Unlike the other Rpi this is more like the STM32 chips where you develop C/C++ or Python to run directly on the bare metal. No Linux involved. That makes it like Arduino. Time for some more studying... > The early Rpi used Broadcom chips. And like most Broadcom stuff you almost needed signing a NDA to get a glance of the pinout of the chip. Exactly. Broadcom had all sorts of strange notions. The BBB uses a TI chip, which was always fully documented. paul From tom at figureeightbrewing.com Wed Feb 3 08:14:44 2021 From: tom at figureeightbrewing.com (Tom Uban) Date: Wed, 3 Feb 2021 08:14:44 -0600 Subject: Flip-Chip selloff In-Reply-To: References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> Message-ID: I suspect many of us are in similar situations. I have been collecting and storing my treasures for about 35 years. I even recently moved it all into one nice climate controlled space. (It has mostly all been in climate controlled space, but now it is all in the same space with room to work on it.) At this point in my life, reviewing how much time I have been able to find in the previous years to play with my hoard, I am realizing that I have way more than I will ever be able to enjoy. Then I consider that the others like me are also coming to a similar conclusion and as a result there is likely lots of equipment looking for homes other than the scrap heap. With museums that seemed like they were funded and safe for the foreseeable future closing with uncertain ends, I worry (just as others) that we are the only ones who will be the custodians of these wondrous marvels of human genius. As those who understand and care for such marvels pass, the number of people who care also dwindle. I've come to realize that perhaps it isn't just the theory that I might one day be able to retire and enjoy keeping my mind engaged with tasks of restoring old PDP-11s to their former glory, but that the 35 years of collecting and storing might lead to a younger generation's wonder in seeing what led to the technology they have at present. Perhaps they don't care and all is for not... On 2/2/21 5:28 PM, Josh Dersch via cctalk wrote: > Since we're talkin' sell-off... on the off chance that anyone has a TC11 or > TC01/08 gathering dust (for something less than eBay prices), I, uh... > could use one. Along with many other people, I suppose. > > - Josh > > > On Tue, Feb 2, 2021 at 3:12 PM Bill Degnan via cctalk > wrote: > >> I think it's good to hold onto that which is realistic to support, no point >> in holding hardware hostage in a rodent and moisture-vulnerable old >> garage. We don't live forever. >> b >> >> On Tue, Feb 2, 2021 at 5:57 PM Chris Zach via cctalk < >> cctalk at classiccmp.org> >> wrote: >> >>> What do I have... >>> >>> Decsystem/20 CPU box+supply (blt.ai.mit.edu), pdp11/05/83/24/23+/150, 2 >>> 8L's, an 8/e, 3 RL02, RM80, RX02,TK50,2 Professional 380's. And a >>> Minc-11/MiniMINC. >>> >>> Several Perqs, that HP 1000e thing, and a few dozen MFM disks. >>> >>> A pair of Sun 386i's, Nextstation, NS Turbo, Turbo Color >>> >>> Probably a lot more. >>> >>> On 2/2/2021 4:13 PM, Bob Smith wrote: >>>> I am down to 2 vaxes and an 11, along with 10 Alphas, a pro380 and two >>>> DECMante II boxes. >>>> bb >>>> >>>> On Tue, Feb 2, 2021 at 1:48 PM Chris Zach via cctalk >>>> wrote: >>>>> Might be a good time: I remember my dad saying I should encase each >> one >>>>> in lucite plastic and sell them as paperweights. That was 30 years ago >>>>> but it would have preserved them well :-) >>>>> >>>>> C >>>>> (Went from 3 8/I's to 2 8/L's so progress?) >>>>> >>>>> On 2/2/2021 1:22 PM, Zane Healy via cctalk wrote: >>>>>> On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk < >>> cctalk at classiccmp.org> wrote: >>>>>>> I don't have any equipment that uses them any more, so I'll be >>> ebaying off my >>>>>>> A-W series flip chips over the next few days. The W's and PT08 >> boards >>> are up now >>>>>>> https://www.ebay.com/itm/184647476832 >>>>>>> https://www.ebay.com/itm/184647420812 >>>>>> That makes me wonder if I shouldn?t do the same. That would be part >>> of a camera lens, which may, or may not take up less space. :-) >>>>>> Then again I?ve been saying I need to downsize my collection for the >>> better part of 20 years. >>>>>> Zane >>>>>> >>>>>> >>>>>> From linimon at lonesome.com Wed Feb 3 09:14:26 2021 From: linimon at lonesome.com (Mark Linimon) Date: Wed, 3 Feb 2021 15:14:26 +0000 Subject: Flip-Chip selloff In-Reply-To: References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> <27440E6D-1CC3-4752-BCB4-004F83728CB4@avanthar.com> <1ef3661f-3390-bd09-93f2-8b2e5f528cd1@alembic.crystel.com> <8a0bd7a7-a168-0846-8a41-60e6c6a1c430@alembic.crystel.com> <20210203003854.GA25965@lonesome.com> Message-ID: <20210203151423.GA25591@lonesome.com> On Tue, Feb 02, 2021 at 07:10:14PM -0800, Christopher Zach wrote: > I've had 30+ years to acquire this "stuff". :-) I turned 65 last year ... mcl From dkelvey at hotmail.com Wed Feb 3 09:14:52 2021 From: dkelvey at hotmail.com (dwight) Date: Wed, 3 Feb 2021 15:14:52 +0000 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> , Message-ID: I'm curious as to how the sampling code looks. Do you use the timers? Dwight ________________________________ From: cctalk on behalf of Mattis Lind via cctalk Sent: Wednesday, February 3, 2021 5:01 AM To: Al Kossow ; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Greaseweazle Den ons 3 feb. 2021 kl 13:25 skrev Al Kossow via cctalk < cctalk at classiccmp.org>: > On 2/2/21 11:51 PM, Peter Corlett via cctalk wrote: > > > I have a pile of Blue Pill boards, and using it to read floppies was an > > obvious application. However after running the numbers, it turned out > there > > isn't enough RAM to buffer an entire track from a HD floppy. It also has > a > > broken USB implementation just to liven things up a bit. > > a small performance list of STM32 parts and where they are used > > STM32F103C8T6 72MHz M3 64K Flash 20K RAM FS Original blue pill > STM32F411CEV6 100MHz M4 512K Flash 128K RAM FS Latest WeAct black pill > STM32F407VET6 168MHz M4 512K Flash 196K RAM HS Board Chuck likes > STM32F730x8T6 216MHz M7 64K Flash 176K RAM HS Eric's GW / GW > Lightning > The performance difference between the STM32F103 and any of the M4 (and M7) chips is even bigger (than what the MHz tell) since there is a small cache in the M4 (and M7) called ART which is intended to give close to zero wait states when reading from flash. The STM32F103 has 2 wait states on flash reads when running at 72 MHz. Unless you put code the code in RAM there will be a performance hit on the 103. Unfortunately RAM is a scarce resource on the 103 as well so you have to plan well to do that. If one wants more buffer memory there is also the STM32F407ZET board which uses the bigger 144 pin chip. On the back of those boards are pads for a ISSI IS62WV51216 chip 512k x 16 chip. What I think is kind of strange with the WeAct board is that they are not identical in pinout to the blue pills. On one side all the pins are shifted on step. I have no idea why they designed it that way. From ethan.dicks at gmail.com Wed Feb 3 10:33:50 2021 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Wed, 3 Feb 2021 11:33:50 -0500 Subject: Flip-Chip selloff In-Reply-To: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> References: <8a22b389-6d97-d51e-5ad4-4384b8dcdc5a@bitsavers.org> Message-ID: On Tue, Feb 2, 2021 at 12:19 PM Al Kossow via cctalk wrote: > I don't have any equipment that uses them any more, so I'll be ebaying off my > A-W series flip chips over the next few days. The W's and PT08 boards are up now > > https://www.ebay.com/itm/184647476832 > https://www.ebay.com/itm/184647420812 The PT08 board set is intriguing (I have an -8/S with no TTY interface) -ethan From cclist at sydex.com Wed Feb 3 11:00:28 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 3 Feb 2021 09:00:28 -0800 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: On 2/3/21 7:14 AM, dwight via cctalk wrote: > I'm curious as to how the sampling code looks. Do you use the timers? > Dwight Exactly. You run the sample timer in "capture" mode using DMA. There's a little trick in this when handling high-denisty fisks in thatthe DMA counter is limited to 65K "items" (bytes, words, doublewords), so there's a small amount of trickery to get more than 64K samples (grab the DMA TC interrupt and restart the transfer 64K down the line). Other than handling the interrupts, the MCU is sitting around staring at navel lint. The reason for using the faster F4 MCUs is the higher clock rate (I clock the sampling timer at 14, 28, 33 or 56 MHz) and the memory. Data is stored to SD card (the F4 has full-speed 4 bit SDIO). The F407 is perfect for the job (and lots of others, in that it has somewhere around 40 pins of 5V tolerant GPIO). A half-meg of program flash lets you do pretty much whatever you want. The same MCU that I use for my tape work. So long as there's support for USB ACM on the host (could be changed to serial or WiFi), the software on the PC that eventually reads the data off of SD can be anything. I reserve the F103 "blue pill" cheapies for more mundane tasks. You'll find one such published on Github by me for using the often-on-sale-for-less-than-$3 IBM IR keyboards as standard PS2-interface keyboards. In, fact, the interface to the host could be anything--USB, serial, parallel. The keyboards are all NIB, decent-quality rubber-dome models. We live in today's world where MCUs are in everything, in toys, light bulbs--you name it. The low-end OTP ones from China can be literally had for pennies. We are surrounded by computers to an extent never imagined by my old EE Prof whom I asked what he thought about the potential of a monolithic computer-on-a-chip. (He couldn't see any). Well, to his credit, I still can't find one that makes up my bed or washes my windows. I suspect that those too, are mostly a matter of time. --Chuck From mattislind at gmail.com Wed Feb 3 11:36:36 2021 From: mattislind at gmail.com (Mattis Lind) Date: Wed, 3 Feb 2021 18:36:36 +0100 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: Den ons 3 feb. 2021 kl 18:00 skrev Chuck Guzis via cctalk < cctalk at classiccmp.org>: > On 2/3/21 7:14 AM, dwight via cctalk wrote: > > I'm curious as to how the sampling code looks. Do you use the timers? > > Dwight > > Exactly. You run the sample timer in "capture" mode using DMA. There's > a little trick in this when handling high-denisty fisks in thatthe DMA > counter is limited to 65K "items" (bytes, words, doublewords), so > there's a small amount of trickery to get more than 64K samples (grab > the DMA TC interrupt and restart the transfer 64K down the line). Other > than handling the interrupts, the MCU is sitting around staring at navel > lint. > So you store a full track worth of data and then write it to the SD-card. Then move the flux-length data over to a PC and do post processing there, right? Isn't there performance in the CPU to do the actual decoding as well? FM, MFM, GCR or whatever into data. Find marks, check CRC and all that stuff? /Mattis From paulkoning at comcast.net Wed Feb 3 11:43:32 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 3 Feb 2021 12:43:32 -0500 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> > On Feb 3, 2021, at 12:36 PM, Mattis Lind via cctalk wrote: > >> ... > > So you store a full track worth of data and then write it to the SD-card. > Then move the flux-length data over to a PC and do post processing there, > right? > > Isn't there performance in the CPU to do the actual decoding as well? FM, > MFM, GCR or whatever into data. Find marks, check CRC and all that stuff? A nice benefit of capturing the raw waveforms and post-processing them is that you can do all sorts of very complex processing. If the media are nice and clean then simple processing is sufficient. If they are badly damaged, you may need more. If you do the processing in real time you may not know what all is needed. But if you do post-processing, you can add to the algorithms after data capture has been done, if what you have so far isn't yet good enough. I can imagine techniques like digital filtering, adaptive filters, maximum likelihood decoders, etc. In recovering data from tapes, with multiple tracks, people have often done this same sort of thing, full high bandwidth analog signal capture. You don't even need to know at the time what the data format is. If you think you know but you don't have it quite right, no matter, you just change the software and run another pass through the captured waveforms. No need to run the (possibly fragile) media through the machine again. paul From aek at bitsavers.org Wed Feb 3 11:55:28 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 09:55:28 -0800 Subject: Greaseweazle In-Reply-To: <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> Message-ID: On 2/3/21 9:43 AM, Paul Koning via cctalk wrote: > A nice benefit of capturing the raw waveforms and post-processing them is that you can do all sorts of very complex processing. If the media are nice and clean then simple processing is sufficient. If they are badly damaged, you may need more. If you do the processing in real time you may not know what all is needed. But if you do post-processing, you can add to the algorithms after data capture has been done, if what you have so far isn't yet good enough. > > I can imagine techniques like digital filtering, adaptive filters, maximum likelihood decoders, etc. > > In recovering data from tapes, with multiple tracks, people have often done this same sort of thing, full high bandwidth analog signal capture. You don't even need to know at the time what the data format is. If you think you know but you don't have it quite right, no matter, you just change the software and run another pass through the captured waveforms. No need to run the (possibly fragile) media through the machine again. > > paul > In the real world, this is fundamentally wrong. You need to know you haven't captured garbage while the disk is still in the drive and you want to minimize the time you spend dwelling on an individual track. Magtape is a completely different issue where you attempt to get as much information as you can before the tape sticks, tears off all of its oxide, or the head clogs. Even if it doesn't stall, the motor can drag and goofs up the tape speed. This is an issue for NRZI media. We (CHM) have had amazing luck recovering 50+ year old 7, 9 and Whirlwind tapes with analog recovery. See Len Shustek's talk at VCFW 2001 about the recovery software. There is some hardware work going on to recover double-sided floppies using A/D channels digitizing both sides of the disk simultainiously, and recovering 4-track pre-QIC cartridge tapes the same way. From aek at bitsavers.org Wed Feb 3 12:15:12 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 10:15:12 -0800 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> Message-ID: On 2/3/21 9:55 AM, Al Kossow via cctalk wrote: > In the real world, this is fundamentally wrong. > > You need to know you haven't captured garbage while the disk is still in the drive > and you want to minimize the time you spend dwelling on an individual track. > When you are recovering a batch of hundreds of disks, you want to know before you start the next disk that either it completely read OK, or had problems. Out of the thousands of disks I've read, I'd guess maybe 100 were problem children and of those either they were copy protected, shed themselves, or weren't MFM or FM. I have cartons of hard-sectored or funny format soft-sectored disks to do that are of high historical value but were too time-consuming to do anything with while I've been trying to work down the backlog. From cclist at sydex.com Wed Feb 3 12:15:49 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 3 Feb 2021 10:15:49 -0800 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: <43bb890e-a886-b6d3-b54c-96d94f6608de@sydex.com> On 2/3/21 9:36 AM, Mattis Lind wrote: > So you store a full track worth of data and then write it to the > SD-card. Then move the flux-length data over to a PC and do post > processing there, right? > > Isn't there performance in the CPU to do the actual decoding as well? > FM, MFM, GCR or whatever into data. Find marks, check?CRC and all that > stuff? Sure, more than enough. But the MCU has to be programmed to do these things; when dealing with an unfamiliar or problematical sample, it's easier to move the data to the Big Machine and play with things there--and there's a "permanent record" of the sampling data. Were I dealing with lots of known samples, I'd probably include the deciphering routines. But in the end, the recovered data has to go back to the customer, so it's going to wind up on the Big Machine anyway. I incorporate a function on the MCU that attempts to find the "peaks" in the spectral information, just as a way to tell if I'm doing things right. Same for verifying the drive spindle RPM. --Chuck From mattislind at gmail.com Wed Feb 3 12:17:18 2021 From: mattislind at gmail.com (Mattis Lind) Date: Wed, 3 Feb 2021 19:17:18 +0100 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> Message-ID: Den ons 3 feb. 2021 kl 18:55 skrev Al Kossow via cctalk < cctalk at classiccmp.org>: > On 2/3/21 9:43 AM, Paul Koning via cctalk wrote: > > > A nice benefit of capturing the raw waveforms and post-processing them > is that you can do all sorts of very complex processing. If the media are > nice and clean then simple processing is sufficient. If they are badly > damaged, you may need more. If you do the processing in real time you may > not know what all is needed. But if you do post-processing, you can add to > the algorithms after data capture has been done, if what you have so far > isn't yet good enough. > > > > I can imagine techniques like digital filtering, adaptive filters, > maximum likelihood decoders, etc. > > > > In recovering data from tapes, with multiple tracks, people have often > done this same sort of thing, full high bandwidth analog signal capture. > You don't even need to know at the time what the data format is. If you > think you know but you don't have it quite right, no matter, you just > change the software and run another pass through the captured waveforms. > No need to run the (possibly fragile) media through the machine again. > > > > paul > > > > In the real world, this is fundamentally wrong. > > You need to know you haven't captured garbage while the disk is still in > the drive > and you want to minimize the time you spend dwelling on an individual > track. > > Magtape is a completely different issue where you attempt to get as much > information as you can > before the tape sticks, tears off all of its oxide, or the head clogs. > > Even if it doesn't stall, the motor can drag and goofs up the tape speed. > This is an issue > for NRZI media. > > We (CHM) have had amazing luck recovering 50+ year old 7, 9 and Whirlwind > tapes with analog > recovery. See Len Shustek's talk at VCFW 2001 about the recovery software. > > There is some hardware work going on to recover double-sided floppies > using A/D channels > digitizing both sides of the disk simultainiously, and recovering 4-track > pre-QIC cartridge > tapes the same way. > I have been looking into designing a 12 bit A/D with a differential amplifier in front which would sample at 6, 12 or 24 Mhz delivering the raw samples to the host over USB (FX2LP chips are good at pumping USB data). In this way I have all the info I can get and then applying various algorithms to the signal is the task of the host. If the host is quick it might even be able to do processing in real-time? ( https://github.com/MattisLind/AnalogFluxReader) Need to work on the layout now. From paulkoning at comcast.net Wed Feb 3 12:18:43 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 3 Feb 2021 13:18:43 -0500 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> Message-ID: <625766BD-2B60-42FE-8B31-61D12E3CB1AD@comcast.net> > On Feb 3, 2021, at 12:55 PM, Al Kossow via cctalk wrote: > > On 2/3/21 9:43 AM, Paul Koning via cctalk wrote: > >> A nice benefit of capturing the raw waveforms and post-processing them is that you can do all sorts of very complex processing. If the media are nice and clean then simple processing is sufficient. If they are badly damaged, you may need more. If you do the processing in real time you may not know what all is needed. But if you do post-processing, you can add to the algorithms after data capture has been done, if what you have so far isn't yet good enough. >> I can imagine techniques like digital filtering, adaptive filters, maximum likelihood decoders, etc. >> In recovering data from tapes, with multiple tracks, people have often done this same sort of thing, full high bandwidth analog signal capture. You don't even need to know at the time what the data format is. If you think you know but you don't have it quite right, no matter, you just change the software and run another pass through the captured waveforms. No need to run the (possibly fragile) media through the machine again. >> paul > > In the real world, this is fundamentally wrong. > > You need to know you haven't captured garbage while the disk is still in the drive > and you want to minimize the time you spend dwelling on an individual track. Fair enough, but that means your real time processing needs to be sufficient to know where the tracks are. And if the media are in bad shape, you may in fact want to capture each track N times at slight offsets from the nominal position, then do signal processing to recover the data as best you can. Come to think of it, the techique of reading 1/2 inch tape with 36 track MR heads is somewhat similar: you get multiple readings of the same nominal data track and can use the additional data to help with recovery. > Magtape is a completely different issue where you attempt to get as much information as you can > before the tape sticks, tears off all of its oxide, or the head clogs. > > Even if it doesn't stall, the motor can drag and goofs up the tape speed. This is an issue > for NRZI media. > > We (CHM) have had amazing luck recovering 50+ year old 7, 9 and Whirlwind tapes with analog > recovery. See Len Shustek's talk at VCFW 2001 about the recovery software. I will, thanks for the pointer. I expect to need this in the not too distant future (for reading 1/2 inch 10 track tapes). paul From aek at bitsavers.org Wed Feb 3 12:22:16 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 10:22:16 -0800 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> Message-ID: <948762eb-21cc-a7c5-d1fa-e0b8daba2677@bitsavers.org> On 2/3/21 10:17 AM, Mattis Lind wrote: > I have been looking into designing?a 12 bit A/D with a differential amplifier in front which would sample at 6, 12 or 24 Mhz delivering the > raw samples to the host over USB (FX2LP chips are good at pumping USB data). In this way I have all the info I can get and then applying > various algorithms to the signal is the task of the host. If the host is quick it might even be able to do processing in > real-time??(https://github.com/MattisLind/AnalogFluxReader ) Need to work on the layout now. There is a prudaq cape for beaglebone that gives you two coherent a/d channels Before i was locked out of my lab, I had my analog streaming usb setup from magtape hooked up to a floppy with a fluxengine to compare the output of the read channel with the analog signal out of the preamp There are a couple of pictures of it on my twitter feed, but twitter doesn't make it easy to find old tweets From aek at bitsavers.org Wed Feb 3 12:27:43 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 10:27:43 -0800 Subject: Greaseweazle In-Reply-To: <625766BD-2B60-42FE-8B31-61D12E3CB1AD@comcast.net> References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> <625766BD-2B60-42FE-8B31-61D12E3CB1AD@comcast.net> Message-ID: On 2/3/21 10:18 AM, Paul Koning wrote: > Fair enough, but that means your real time processing needs to be sufficient to know where the tracks are. And if the media are in bad shape, you may in fact want to capture each track N times at slight offsets from the nominal position, then do signal processing to recover the data as best you can. > That is in conflict with the requirement you spend as little time as you can on shedding media ideally, you'd use a 96tpi drive on 48tpi and microstep the head positioner. you still have the problem of head clog. And, AFAIK, no existing software does any of this. > Come to think of it, the techique of reading 1/2 inch tape with 36 track MR heads is somewhat similar: you get multiple readings of the same nominal data track and can use the additional data to help with recovery. In practice, the channels smear together, that's why John Bordynuik went to 36 tk 3490 heads from 18 tk 3480 heads on his 1/2" tape setups. We saw this as well on the 6-track Whirlwind tapes using a 9-track head. Fortunately 6 of the heads lined up cleanly. From paulkoning at comcast.net Wed Feb 3 12:34:57 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 3 Feb 2021 13:34:57 -0500 Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> <625766BD-2B60-42FE-8B31-61D12E3CB1AD@comcast.net> Message-ID: <26022343-6807-4399-8743-F1E97535238B@comcast.net> > On Feb 3, 2021, at 1:27 PM, Al Kossow wrote: > > On 2/3/21 10:18 AM, Paul Koning wrote: > >> Fair enough, but that means your real time processing needs to be sufficient to know where the tracks are. And if the media are in bad shape, you may in fact want to capture each track N times at slight offsets from the nominal position, then do signal processing to recover the data as best you can. > > That is in conflict with the requirement you spend as little time as you can on shedding media > ideally, you'd use a 96tpi drive on 48tpi and microstep the head positioner. you still have the > problem of head clog. > > And, AFAIK, no existing software does any of this. Which might mean either (a) what I suggested is in practice not needed, or (b) existing software treats as unrecoverable disks that could be recovered with more sophisticated tools. I have no idea which is correct. > >> Come to think of it, the techique of reading 1/2 inch tape with 36 track MR heads is somewhat similar: you get multiple readings of the same nominal data track and can use the additional data to help with recovery. > > In practice, the channels smear together, that's why John Bordynuik went to 36 tk 3490 heads from 18 tk 3480 heads on his 1/2" tape setups. > > We saw this as well on the 6-track Whirlwind tapes using a 9-track head. Fortunately 6 of the heads lined up cleanly. Yes, I was thinking of that issue while looking into how a 10 track tape would look to, say, a 16 track instrumentation recorder head. The picture looked marginal at best. paul From aek at bitsavers.org Wed Feb 3 12:46:20 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 10:46:20 -0800 Subject: Greaseweazle In-Reply-To: <26022343-6807-4399-8743-F1E97535238B@comcast.net> References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> <625766BD-2B60-42FE-8B31-61D12E3CB1AD@comcast.net> <26022343-6807-4399-8743-F1E97535238B@comcast.net> Message-ID: <4d8662dc-58c6-746e-7082-9bbc51d58654@bitsavers.org> On 2/3/21 10:34 AM, Paul Koning wrote: > Which might mean either (a) what I suggested is in practice not needed, or (b) existing software treats as unrecoverable disks that could be recovered with more sophisticated tools. I have no idea which is correct. More sophisticated tools aren't needed, until they are. For the majority of people and applications none of this is necessary. People have been using Imagedisk happily for a long time. Then you have a one of a kind floppy eaten and you wish you hadn't used it. And this happens in the middle of a batch of disks that had been reading fine. From cclist at sydex.com Wed Feb 3 14:00:50 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 3 Feb 2021 12:00:50 -0800 Subject: Greaseweazle In-Reply-To: <43bb890e-a886-b6d3-b54c-96d94f6608de@sydex.com> References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <43bb890e-a886-b6d3-b54c-96d94f6608de@sydex.com> Message-ID: I'll add just a bit with respect to floppy disks on an MCU. One reason to put histogram and peak-detection in the MCU firmware is that for a disk you never know how far out of alignment the original (recording) drive might be. A drive used to record something out of alignment can yield garbage on a blind capture. A drive that allows for adjustment means that you can sample a track, and adjust until you see nice clean peaks. Blind-on-the-fly recovery makes this a lot more difficult. You can certainly add some primitive decoding for FM, MFM, MMFM and a few varieties of GCR as a sanity check, but looking at spectral peaks is a first-line diagnostic. --Chuck From cclist at sydex.com Wed Feb 3 14:13:04 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 3 Feb 2021 12:13:04 -0800 Subject: QIC 3M "Magnus 1.2" carts Message-ID: I have received a few of the above-mentioned DC300-sized QIC carts for recovery. The usual stuff about tension bands applies, but I'm a bit stymied. The official specs for these tapes say that they're SLR 3. I've tried Tandberg SLR 3, 4 and 5 drives (any of which should be able to read these) with no luck. I've even tried an SLR2 QIC525, though why someone would pay for more tape than they need is a mystery. These would be ca. 1990 and most likely on a Mac, although the latter is pure conjecture. Before I unspool some of this tape and have a look with developer, am I missing something? --Chuck From athornton at gmail.com Wed Feb 3 14:29:51 2021 From: athornton at gmail.com (Adam Thornton) Date: Wed, 3 Feb 2021 13:29:51 -0700 Subject: cctalk Digest, Vol 77, Issue 3 In-Reply-To: References: Message-ID: <4361407C-C790-4E45-9B6D-A908750C3BB2@gmail.com> As long as we?re talking about divesting: if anyone has a VaxStation that they?d sell me for substantially less than eBay prices, I?d be interested. I have a 3100M38, but it doesn?t POST; indeed, a replacement mainboard would be a place I could start. (I did try burning new ROMs and replacing them, but that wasn?t the problem). I?d even consider swapping an 11/730 in unknown condition (this is from the Kaur collection) for a working VaxStation, on two conditions: you have to pick it up, and you have to take an RM80 drive with it and dump it far enough away from my house that no one thinks it was me what done it. Adam From cmhanson at eschatologist.net Wed Feb 3 14:31:08 2021 From: cmhanson at eschatologist.net (Chris Hanson) Date: Wed, 3 Feb 2021 12:31:08 -0800 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> Message-ID: <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> On Feb 2, 2021, at 7:58 AM, geneb via cctalk wrote: > > You're absolutely correct, however the only thing Al contributes (for the purposes of this particular discussion) are complaints about how other people are doing it wrong. I think Al has contributed enormously to the archival and preservation of our industry history, which is exactly why I pretty much always want to hear more from him on anything related?and why my ears perk up when he says there's a better way to do something. Also, I'm 100% with Al about not siloing projects _on social media sites like Facebook_. They're terrible for technical projects because they're specifically designed to surface "engaging" social information and push further engagement, rather than to actually preserve chronology, or to make it easy to refer back to or link to anything at all in the past. There is only forward, and only at the whim of The Algorithm. Mailing lists are by far the best choice when it comes to collaboration on technical projects, with tools from project hosting sites like SourceForge, Bitbucket, GitLab, and Github a close second. -- Chris From emu at e-bbes.com Wed Feb 3 14:52:42 2021 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 3 Feb 2021 15:52:42 -0500 Subject: cctalk Digest, Vol 77, Issue 3 In-Reply-To: <4361407C-C790-4E45-9B6D-A908750C3BB2@gmail.com> References: <4361407C-C790-4E45-9B6D-A908750C3BB2@gmail.com> Message-ID: On 2021-02-03 15:29, Adam Thornton via cctalk wrote: > As long as we?re talking about divesting: if anyone has a VaxStation that they?d sell me for substantially less than eBay prices, I?d be interested. I have a 3100M38, but it doesn?t POST; indeed, a replacement mainboard would be a place I could start. (I did try burning new ROMs and replacing them, but that wasn?t the problem). I?d even consider swapping an 11/730 in unknown condition (this is from the Kaur collection) for a working VaxStation, on two conditions: you have to pick it up, and you have to take an RM80 drive with it and dump it far enough away from my house that no one thinks it was me what done it. Where are you? From jfoust at threedee.com Wed Feb 3 15:00:50 2021 From: jfoust at threedee.com (John Foust) Date: Wed, 03 Feb 2021 15:00:50 -0600 Subject: Greaseweazle In-Reply-To: <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> Message-ID: <20210203210630.BEDB94E672@mx2.ezwind.net> What I'm hearing is that these microcontroller standalone devices don't give any feedback on the reading process. Couldn't they be more tightly coupled to a PC so the raw data could be displayed immediately and analyzed reasonably quickly? Certainly they could send all the samples over USB quite quickly? - John From rlloken at telus.net Wed Feb 3 15:20:05 2021 From: rlloken at telus.net (Richard Loken) Date: Wed, 3 Feb 2021 14:20:05 -0700 (MST) Subject: VAXstation 3100 Message-ID: Adam, I have a VAXstation sitting about three metres from me. As is usually the case, "it worked when I turned it off 20 years ago" I don't remember how many years ago I turned it off. I think it is a model 30 but casually looking at the box does not show me what model it is. I pulled out the nicad battery pack many years ago and it is sitting by my left hand and it does not leak. I have the system box, the expansion box with its little SCSI disk drive, the RRD40 and its wierd disc caddies, and the VR--- monochrome monitor, and probably the keyboard and mouse and documentation if I look around for half an hour. I have no idea where you are but I can send it to you for the price of shipping which would be astronomical I expect. I hesitate to ship the monitor - that would be had work - but the other components can be managed. -- Richard Loken VE6BSV : "...underneath those tuques we wear, Athabasca, Alberta Canada : our heads are naked!" ** rlloken at telus.net ** : - Arthur Black From aek at bitsavers.org Wed Feb 3 15:22:13 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 13:22:13 -0800 Subject: Greaseweazle In-Reply-To: <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> Message-ID: On 2/3/21 12:31 PM, Chris Hanson wrote: > tools from project hosting sites like SourceForge, Bitbucket, GitLab, and Github a close second. > Some people tried to get a technical Greaseweasel discussion going on their github, and it is slowly being adopted after a whole lot of nothing initially. https://github.com/keirf/Greaseweazle/discussions From cclist at sydex.com Wed Feb 3 15:37:12 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 3 Feb 2021 13:37:12 -0800 Subject: Greaseweazle In-Reply-To: <20210203210630.BEDB94E672@mx2.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> <20210203210630.BEDB94E672@mx2.ezwind.net> Message-ID: <2ba235af-8790-b977-6c4a-a9150fdfba41@sydex.com> On 2/3/21 1:00 PM, John Foust via cctalk wrote: > > What I'm hearing is that these microcontroller standalone devices > don't give any feedback on the reading process. Couldn't they be more > tightly coupled to a PC so the raw data could be displayed immediately > and analyzed reasonably quickly? Certainly they could send all > the samples over USB quite quickly? "Reasonably quickly" is a relative term. I've got samples here that I had to cogitate over for a year. Admittedly, these were items that were sui generis, but "quickly" was not in the picture. Perhaps with some choice pharmaceuticals, my thinking speed could be improved, but I haven't explored that yet. You know--you get a disk that's thought to contain some information, the identity of the originating system is unknown; no Rosetta stones to be seen. For my purposes, clearly defined spectral peaks are the critical thing--and that's done on my MCU implementation. --Chuck From abuse at cabal.org.uk Wed Feb 3 16:10:02 2021 From: abuse at cabal.org.uk (Peter Corlett) Date: Wed, 3 Feb 2021 23:10:02 +0100 Subject: APL\360 In-Reply-To: <5f9ee15a-0406-1a3b-0106-4dfde62872a6@jetnet.ab.ca> References: <69a83b09-b765-077f-d336-b03e55fa771c@gmail.com> <0bca4061-e671-4613-47c7-572b202ef8ab@telegraphics.com.au> <3246ff52-751e-14f1-a464-fd9288aba256@jetnet.ab.ca> <5f9ee15a-0406-1a3b-0106-4dfde62872a6@jetnet.ab.ca> Message-ID: On Tue, Feb 02, 2021 at 08:50:56PM -0700, ben via cctalk wrote: > On 2/1/2021 6:07 AM, Peter Corlett via cctalk wrote: [...] >> You're describing a failing in C and similar languages stuck in the >> 1960s. Here's a Rust method that does add-exposing-carry: >> https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.overflowing_add > So why could this not have been done 30 earlier? (I assume you mean "30 years earlier" here.) Two reasons, one of which I was already aware of back then in 1991, and one which is only obvious in hindsight. The first is simple toxic masculinity. It's more manly to write stuff in machine code (then) or C (now), apparently. The second is a combination of Moore's Law and computer science. To handwave wildly, Rust is what you get when you look at C++'s mistakes of the last forty years and start again. If you've used a C++ compiler from the 1980s or early 1990s, you'll have found the experience harrowing: computers were still too slow and too small to do a good job, and various important language design and code-generation techniques were not yet known and/or were too impractical to implement. It all improved rapidly in the 1990s and 2000s, bringing us more or less to the top of the sigmoid curve. u32::overflowing_add() returns a (u32, bool), i.e. a two-member struct. Those early compilers cannot return structs directly, so the caller would have to reserve space (on the stack, probably) and pass the address for the function to fill in. That simple add-producing-carry has just become a function with a half-dozen instructions, several of which are needed to check the carry flag and convert it into a integer, plus many memory accesses, just to provide a C wrapper around a simple add instruction. At that point it does make sense to toss the compiler and write assembly language. Modern compilers do a lot of heavy inlining as a matter of course, will split structs and perform dataflow analysis on individual elements, and generally avoid memory access unless they absolutely have to. u32::overflowing_add() should turn into a single add instruction and the carry flag will probably be tested directly by a branch instruction and never get converted to a boolean variable. It'll be as good as if not better than hand-written assembler. This is a particularly trivial function as well. Rust just wouldn't be viable with 30 year old compiler technology. >> The documentation doesn't explicitly say "carry" because Rust is >> architecture-neutral and it's down to LLVM to decide how to express it in >> machine code, but on x86 (and probably ARM) the boolean return value >> comes directly from the carry flag. > mincing words, sigh. RISC-V doesn't have a carry flag. It handles overflow by e.g. using the BLT instruction to branch if the result is smaller than the number being added to. So documentation which assumes the world is x86 will not make sense here. [...] >> You "don't believe in objects" yet then describe a problem which only >> exists due to the lack of them and then present OO pseudocode to solve >> it. A lot of OO languages suck of course, but the fundamental idea of >> encapsulation is not the bit that sucks. > Are objects? they only way to solve this problem. I see a object as data > structure tied to some code. What I would like to see data structures > having fixed constants like array start and end of a structure for a array > as variables when called into use. There's no real difference between a "constant ... when called into use" and a pure function which returns a value based on the structure elements. >> Here's it in Rust, where it takes in an arbitrary >> array (pedantically, "slice", a (pointer, element count)-tuple) and >> determines its length at runtime: >> >> pub fn clear_indexed(array: &mut [usize]) { >> for index in 0 .. array.len() { >> array[index] = 0; >> } >> } > I don't want Information hiding, I want to know what it does clearly. If I > can't figure it out how can a computer program do it. Where does ".len()" > find the size? That is an implementation detail which you don't need to know to be able to write Rust code. However, the len() method actually just returns the element count from the (pointer, element count)-tuple. The function is so trivial that it is guaranteed to be inlined so it's exactly the same as if you had accessed the field directly. Before you ask, no, you can't access the field directly for all of the excellent reasons explained by every "introduction to OOP" tutorial which I don't need to repeat. [...] >> pub fn clear_iterator(array: &mut [usize]) { >> for elem in array { >> *elem = 0; >> } >> } >> Both code fragments generate equivalent assembly in this trivial example >> because the Rust compiler could prove at compile time that the index >> variable can't go out-of-bounds. In more complex real-world code it >> cannot reliably do so and will insert a run-time check which aborts if >> the index is out-of-bounds. Or if it's C, trundle on and corrupt things. > Why prove it? Just test it at runtime. Runtime bounds-checking can get rather expensive -- it tends to add an extra compare-and-branch to tight inner loops and may also foil automatic vectorisation -- so it makes code much faster if the compiler can prove the check is unnecessary and eliminate it, or at least hoist it out of loops. An ordinary Rust programmer doesn't actually need to know any of this. They write code and it goes as fast as is safe. If it's not fast enough for them, they can ask an expert who knows this sort of intimate low-level detail and optimisation tricks to poke at their code, much as with any other language. What decades of toxic-masculinity C programmers have taught us is that they'll eliminate the bounds-check without proving it was unnecessary, assuming they ever bothered to perform the test in the first place, and ship code which will be trivially compromised. But it'll be really fast right up until your credit card details are leaked! From jfoust at threedee.com Wed Feb 3 16:19:06 2021 From: jfoust at threedee.com (John Foust) Date: Wed, 03 Feb 2021 16:19:06 -0600 Subject: Greaseweazle In-Reply-To: <2ba235af-8790-b977-6c4a-a9150fdfba41@sydex.com> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> <20210203210630.BEDB94E672@mx2.ezwind.net> <2ba235af-8790-b977-6c4a-a9150fdfba41@sydex.com> Message-ID: <20210203222003.3E64A4E6EE@mx2.ezwind.net> At 03:37 PM 2/3/2021, Chuck Guzis via cctalk wrote: >"Reasonably quickly" is a relative term. I've got samples here that I >had to cogitate over for a year. >Admittedly, these were items that were sui generis, but "quickly" was >not in the picture. Well, there's the balance between novice normal mode and expert mode. I heard people asking for a way to see the reults quickly so you could adjust the reading, abort if problems were spotted, or change tactics if weird data arose. We want smart software for the novices and adjustable software for the experts. - John From jfoust at threedee.com Wed Feb 3 16:22:09 2021 From: jfoust at threedee.com (John Foust) Date: Wed, 03 Feb 2021 16:22:09 -0600 Subject: Flip-Chip selloff (Al Kossow) In-Reply-To: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> References: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> Message-ID: <20210203222324.2D24A273AE@mx1.ezwind.net> At 04:01 PM 2/3/2021, you wrote: >and I won't go into how disgusted I am with eBay's new seller payment system >they forced everyone into on the first of the month. A few months ago I sold on eBay some servers and NAS stuff for a client. I thought it would be easy to see the detailed financial breakdown... what it sold for, what came in, what was their cut, how much was shipping, what went to PayPal, etc. I couldn't find it for the life of me. - John From imp at bsdimp.com Wed Feb 3 16:32:51 2021 From: imp at bsdimp.com (Warner Losh) Date: Wed, 3 Feb 2021 15:32:51 -0700 Subject: Greaseweazle In-Reply-To: <20210203222003.3E64A4E6EE@mx2.ezwind.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> <20210203210630.BEDB94E672@mx2.ezwind.net> <2ba235af-8790-b977-6c4a-a9150fdfba41@sydex.com> <20210203222003.3E64A4E6EE@mx2.ezwind.net> Message-ID: On Wed, Feb 3, 2021 at 3:20 PM John Foust via cctalk wrote: > At 03:37 PM 2/3/2021, Chuck Guzis via cctalk wrote: > >"Reasonably quickly" is a relative term. I've got samples here that I > >had to cogitate over for a year. > >Admittedly, these were items that were sui generis, but "quickly" was > >not in the picture. > > Well, there's the balance between novice normal mode and expert mode. > > I heard people asking for a way to see the reults quickly so you could > adjust the reading, abort if problems were spotted, or change tactics > if weird data arose. We want smart software for the novices and > adjustable software for the experts. > My one big complaint about the kyroflux command line thing is that it doesn't give a list of 'bad' tracks at the end so you have to scan the logs to make sure the reading worked. Of course, that's in 'sector mode' not in flux capture mode... I wouldn't think to do the latter unless I could also say "I expect this disk to be X format, please abort if that's not plausibly true" and also to use that to inform retries maybe, but I haven't thought through all the implications of the latter... Warner Warner From abuse at cabal.org.uk Wed Feb 3 16:37:54 2021 From: abuse at cabal.org.uk (Peter Corlett) Date: Wed, 3 Feb 2021 23:37:54 +0100 Subject: Greaseweazle In-Reply-To: References: <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: On Wed, Feb 03, 2021 at 01:09:50AM -0800, jim stephens via cctalk wrote: > On 2/2/2021 11:51 PM, Peter Corlett via cctalk wrote: >> The Raspberry Pi Pico has a similar price to the Blue Pill and seems a >> much better machine for this task, although I haven't combed through its >> reference manual yet. > For capture and writing (if that's part of the design) I heard there's a > dedicated coprocessor for the GPIO pins. It might be useful for offloading > some of the proccessing from some external circuitry to do the capture or > output. I have now pulled the reference manual to look at the GPIO stuff, and it is indeed very shiny. There's only space for 32 coprocessor instructions per GPIO bank, but that's possibly all you need: it is apparently possible to implement a full UART with handshaking in that. Controlling a floppy is broadly the same level of complexity as a UART, so it seems that the Pico would be he perfect tool for the job. Now if only I could actually lay my hands on one... > I don't know what's included for the capabilities. And apparently since > the chip is new, there's only assembler programming for it now. It's a Cortex M0, so any compiler which can produce freestanding ARM code can generate code for it. So that's gcc, clang, rustc, etc. I suspect I can just use my existing embedded tooling after telling it to use a different subarchitecture. > There's a video comparing the Pico, ESP32, ESP32-S and Blue Pill. The latter > was a bit low in resources compared to the others. OTOH, I can actually buy a Blue Pill today from reasonably reputable local suppliers such as Amazon or AZ-Delivery, and they only cost ?15 for five including delivery. The Pico will be a game-changer if/when there's actual stock here on the Continent. Importing directly from the UK is no longer a sensible proposition. > I'll try to find it and post it if anyone's interested. No rush, especially as I only suffer video as a last resort when information is unavailable in any other form. From a.carlini at ntlworld.com Wed Feb 3 17:08:20 2021 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Wed, 3 Feb 2021 23:08:20 +0000 Subject: Flip-Chip selloff (Al Kossow) In-Reply-To: <20210203222324.2D24A273AE@mx1.ezwind.net> References: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> <20210203222324.2D24A273AE@mx1.ezwind.net> Message-ID: <5e2277aa-8e6d-38ef-afee-af46d22239e4@ntlworld.com> On 03/02/2021 22:22, John Foust via cctalk wrote: > At 04:01 PM 2/3/2021, you wrote: >> and I won't go into how disgusted I am with eBay's new seller payment system >> they forced everyone into on the first of the month. > A few months ago I sold on eBay some servers and NAS stuff for a client. > I thought it would be easy to see the detailed financial breakdown... > what it sold for, what came in, what was their cut, how much was shipping, > what went to PayPal, etc. I couldn't find it for the life of me. > The paypal bit is easy: look at your paypal account! The ebay part is OK too: ? My Ebay->Summary. Account. Seller Account. All Account Activity. At least, in the UK, that works for me. Currently if I sell something the buyer pays with Paypal and I then send the stuff. It can still be reversed and I've not tried to empty my PayPal balance to see if it will let me ... Shipping you need to track yourself (although if you use ebay for that too then it might list it). Antonio -- Antonio Carlini antonio at acarlini.com From steven at malikoff.com Wed Feb 3 18:21:53 2021 From: steven at malikoff.com (steven at malikoff.com) Date: Thu, 4 Feb 2021 10:21:53 +1000 Subject: Flip-Chip selloff (Al Kossow) In-Reply-To: <5e2277aa-8e6d-38ef-afee-af46d22239e4@ntlworld.com> References: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> <20210203222324.2D24A273AE@mx1.ezwind.net> <5e2277aa-8e6d-38ef-afee-af46d22239e4@ntlworld.com> Message-ID: <69a74f42bb2ee0761ab1ce0169d0a769.squirrel@webmail04.register.com> Antonio said > On 03/02/2021 22:22, John Foust via cctalk wrote: >> At 04:01 PM 2/3/2021, you wrote: >>> and I won't go into how disgusted I am with eBay's new seller payment system >>> they forced everyone into on the first of the month. >> A few months ago I sold on eBay some servers and NAS stuff for a client. >> I thought it would be easy to see the detailed financial breakdown... >> what it sold for, what came in, what was their cut, how much was shipping, >> what went to PayPal, etc. I couldn't find it for the life of me. >> > > The paypal bit is easy: look at your paypal account! The ebay part is OK > too: > > My Ebay->Summary. Account. Seller Account. All Account Activity. > > At least, in the UK, that works for me. Currently if I sell something > the buyer pays with Paypal and I then send the stuff. It can still be > reversed and I've not tried to empty my PayPal balance to see if it will > let me ... > > Shipping you need to track yourself (although if you use ebay for that > too then it might list it). In the case of the items OP's thread is pertaining to, perhaps it's a bit of a moot point for you in the UK and others on this international mailing list. They are clearly listed there (but not mentioned here AFAIK) with "Note, NO international shipping." From jwsmail at jwsss.com Wed Feb 3 18:41:56 2021 From: jwsmail at jwsss.com (jim stephens) Date: Wed, 3 Feb 2021 16:41:56 -0800 Subject: R: Winchester SA1004 file recovering In-Reply-To: <2C72C619A3824859BF01C03552664CB0@Enrico> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <2f6765b0-0f4c-2c8c-91cc-d0c88c6812c2@ntlworld.com> <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> <8f048068-4ac8-9486-3247-c053db27be4a@jwsss.com> <2C72C619A3824859BF01C03552664CB0@Enrico> Message-ID: <1a180706-d2ce-d5eb-2f9b-686ed4333c37@jwsss.com> He offers everything from the $15 bare board up.? Next step up is doing the surface mount chips for you at $3.50, etc. I'd do the bare board.? I can attest that the mfm emulator will work.? I've not one the SA-1000 might have to work with him to do it yourself.?? I recall he offered a kit option on that, and I had him build it up. thanks Jim On 2/3/2021 5:36 AM, Enrico email.it via cctalk wrote: > It's a bit very expensive to shipping a SA-1000 from U.S. to Italy.... > almost over than 200 USD > > > > -----Messaggio originale----- > Da: cctech [mailto:cctech-bounces at classiccmp.org] Per conto di jim stephens > via cctech > Inviato: mercoled? 3 febbraio 2021 12:18 > A: Enrico email.it via cctalk > Oggetto: Re: Winchester SA1004 file recovering > > > > On 2/3/2021 1:43 AM, Enrico email.it via cctalk wrote: >> Any suggestion? > I believe Dave G's MFM emulator has an option to support the SA1000. > > I have one in stock for a future project to try to extract data from > SA-1000's in DSD floppy / 8" drive subsystems. > > https://www.pdp8.net/mfm/mfm.shtml > > info is there about the SA-1000. > > If you are having problems because the drives are dead, this won't > help.? It will inhale the contents and with > luck you can extract data. > > I know with the ST-506 configuration of his hardware, you can then use > the emulator to replace the SA-1000. > > If you need to recover the data, you may be out of luck, but if you need > a "working" SA-1000 and can format > it from utilities, then this may help. > > thanks > Jim > > From paulkoning at comcast.net Wed Feb 3 18:54:11 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 3 Feb 2021 19:54:11 -0500 Subject: Greaseweazle In-Reply-To: References: <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> Message-ID: <3E7929F9-C434-4A44-BB48-15DD27225CC5@comcast.net> > On Feb 3, 2021, at 5:37 PM, Peter Corlett via cctalk wrote: > > On Wed, Feb 03, 2021 at 01:09:50AM -0800, jim stephens via cctalk wrote: >> On 2/2/2021 11:51 PM, Peter Corlett via cctalk wrote: >>> The Raspberry Pi Pico has a similar price to the Blue Pill and seems a >>> much better machine for this task, although I haven't combed through its >>> reference manual yet. >> For capture and writing (if that's part of the design) I heard there's a >> dedicated coprocessor for the GPIO pins. It might be useful for offloading >> some of the proccessing from some external circuitry to do the capture or >> output. > > I have now pulled the reference manual to look at the GPIO stuff, and it is > indeed very shiny. There's only space for 32 coprocessor instructions per > GPIO bank, but that's possibly all you need: it is apparently possible to > implement a full UART with handshaking in that. > > Controlling a floppy is broadly the same level of complexity as a UART, so > it seems that the Pico would be he perfect tool for the job. Now if only I > could actually lay my hands on one... Yes, I noticed the usual suspects are out of stock. Need to look further. My reaction was similar. I like the dual CPUs, that means one could do hard real time stuff like wiggling I/O lines (for example DDCMP at a megabit per second) while the other does buffer management and talks USB protocol. I didn't even realize there's a small I/O coprocessor, that's neat. The TI engine in the BeagleBone Black has that sort of thing (a much larger one) which seems very useful if the job is particularly hard. David Gesswein made great use of that for hard drive emulation. But that's a much larger and more expensive solution. paul From aek at bitsavers.org Wed Feb 3 19:05:25 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 17:05:25 -0800 Subject: Greaseweazle In-Reply-To: <3E7929F9-C434-4A44-BB48-15DD27225CC5@comcast.net> References: <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <3E7929F9-C434-4A44-BB48-15DD27225CC5@comcast.net> Message-ID: <33aac3ee-199f-e361-aadc-c8635c8b6d83@bitsavers.org> > a much larger and more expensive solution. Does it matter? Do you buy Chinese junk tools as well? It isn't like you're going to buy 100 or even 10 of the things. If you are just starting out at this, and didn't collect a stash of old floppy drives you're going to spend a lot more on the drives and power supply than the imaging board. The same goes for an ISA PC and floppy controller that supports FM if you want to use Imagedisk. We're moving out the end of the long tail where even 3.5" floppies were free for the taking. Ewaste laws haven't helped the situation any. From cisin at xenosoft.com Wed Feb 3 19:09:21 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 3 Feb 2021 17:09:21 -0800 (PST) Subject: Greaseweazle In-Reply-To: <26022343-6807-4399-8743-F1E97535238B@comcast.net> References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> <625766BD-2B60-42FE-8B31-61D12E3CB1AD@comcast.net> <26022343-6807-4399-8743-F1E97535238B@comcast.net> Message-ID: > ideally, you'd use a 96tpi drive on 48tpi and microstep the head > positioner. you still have the problem of head clog. Some "stupid ideas": In line with trying to minimize possible damage during analysis of the format, try: Use a 96tpi drive. Try to read cylinder 72. MOST OS's are aware of the lower reliability of inner tracks, and will try to write the data to the outer (lower numbered tracks) Therefore, if the oxide comes off on your head, then it is less likely to be what you needed. See if you got a valid read. USUALLY (not always), that cylinder will have the same number of bytes per sector, sectors per track, and heads per cylinder as the other tracks. If the track read identifies itself as track 36 (look at the CHRN fields if there is an IBM/WD style sector header) then it was presumably written on a 48tpi drive. If it identifies itself as track 75, then it was probably written on a 100tpi drive. Switch to a 100tpi drive (MicropolisII, Tandon TM400-4M, etc.) Then try cylinder 36. If the disk had been written on a 48tpi 35 track drive (SA400/SA390 used on TRS80 and Apple), then cylinder 72 of a 96tpi/cylinder 36 of 48tpi would not have been used. If cylinder 72 does not read, but 36 gives a valid read that identifies itself as track 18, then it is most likely from a 35 track 48tpi drive, such as SA400. Watch out for re-used disks. If a formatted 5150 disk was reformatted by a single-sided machine, then you will have the single sided format on side A, and PC format on side B! Similarly, a used 40/80 track disk reformatted by a 35 track machine will have different formats from the residual formatting on the high tracks. Every even numbered cylinder of a 96tpi drive corresponds to a cylinder of a 48tpi drive. Every multiple of 24 cylinders of a 96 tpi drive corresponds with a multiple of 25 cylinders of a 100tpi drive. If you succeed in reading the track identification (CHRN in sector header in IBM/WD formats), then you have a clue of the tpi of the source drive. If you managed a successful track read, then knowing the tpi, number of heads, bytes per sector, sectors per track, will let you avoid some of the otherwise unsuccessful read attempts (such as unnecessary revolutions of the media trying to read between tracks on 48tpi) Is it worth the effort to modify the drive? Reading both heads at the same time would halve the number of revolutions needed of deteriorating media. I had some 8" diskettes for which I could get a successful read IFF I pushed gently on the side of the head with my finger. I always intended to try to add a micrometer lead screw to the head positioning, but never got around to it. Presumably, if the amount of offset from "correct" position is determined, it would probably be the same for most/all disks written with the same source drive. Howzbout analog positioning? Amlyn claimed to use "analog positioning with phase locked loop feedback" to find the tracks. Did they? If you have some semi-skilled assistants (interns, grad students, etc.) then some of the catch up of the backlog could be handed off to them for disks that aren't as likely to be damaged by a read attempt disks with a known/presumed/likely format If you have a group of workstations (and a swivel chair), you could then step-in only when the assistant(s) encounters a problem. From cisin at xenosoft.com Wed Feb 3 19:47:16 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 3 Feb 2021 17:47:16 -0800 (PST) Subject: Greaseweazle In-Reply-To: References: <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210202145358.EF98E273F4@mx1.ezwind.net> <9dc4c053-ec63-04d2-d0b2-a66902a3e6d4@sydex.com> <02FFF921-7A97-4B30-B273-D7DDA13AE16E@comcast.net> <625766BD-2B60-42FE-8B31-61D12E3CB1AD@comcast.net> <26022343-6807-4399-8743-F1E97535238B@comcast.net> Message-ID: On Wed, 3 Feb 2021, Fred Cisin via cctalk wrote: . . . > Then try cylinder 36. > If the disk had been written on a 48tpi 35 track drive (SA400/SA390 used on > TRS80 and Apple), then cylinder 72 of a 96tpi/cylinder 36 of 48tpi would not > have been used. If cylinder 72 does not read, but 36 gives a valid read that > identifies itself as track 18, then it is most likely from a 35 track 48tpi > drive, such as SA400. That second attempt should have read cylinder 54/27, not 36/18 Again, to try to do most of the analysis on the less likely to be in use tracks. THIRD attempt should be 36/18 Then, if you are feeling bold, cylinder 0 Cylinder 0 may be a different format than other parts of the disk, such as the continuation of FM for system tracks of CP/M even after the rest of the disk went to MFM. Watch for what looks like it might be a DIRectory in the low tracks, OR for some formats the MIDDLE tracks (17,20, etc) for variants of TRSDOS, Microsoft Stand-Alone BASIC, etc. From cisin at xenosoft.com Wed Feb 3 19:59:46 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 3 Feb 2021 17:59:46 -0800 (PST) Subject: Greaseweazle In-Reply-To: <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> Message-ID: >> You're absolutely correct, however the only thing Al contributes (for >> the purposes of this particular discussion) are complaints about how >> other people are doing it wrong. On Wed, 3 Feb 2021, Chris Hanson via cctalk wrote: > I think Al has contributed enormously to the archival and preservation > of our industry history, which is exactly why I pretty much always want > to hear more from him on anything related?and why my ears perk up when > he says there's a better way to do something. I agree. Al, Chuck, ARD, (and many others). may not have the time, nor inclination, to do a full handholding tutorial or troubleshoot somebody else's problems. They have provided a wealth of information. I always learn something. Within any gripes they make are gems of indentification of problems and things that may need to be addressed. Such as the specific suggestions to try to check read validity as soon and quickly as possible to avoid unnecessary read attempts that further damage deteriorating disks. My gripes about the Greaseweazle documentation should be construed as "suggestions for improvement" :-) I thought that the Fluxengine documentation was a really quite good start. He humbly acknowledged things that he didn't know, actively solicited comments and suggestions, and compiled a really nice collection of some of the weird formats. (including a link to Chuck's F85 page) From derschjo at gmail.com Wed Feb 3 22:07:58 2021 From: derschjo at gmail.com (Josh Dersch) Date: Wed, 3 Feb 2021 20:07:58 -0800 Subject: PDP-11/70 debugging advice In-Reply-To: References: <7cf71ced-86dd-a099-897e-9f9c945360f6@shiresoft.com> <80C7C186-38CB-4CD7-90B7-967AB7CFCFC1@fritzm.org> <37001320-0D80-43BE-9C3E-F703D1D914CB@fritzm.org> <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> Message-ID: On Tue, Feb 2, 2021 at 12:30 AM Josh Dersch wrote: > > > On Sun, Jan 31, 2021 at 10:03 PM Fritz Mueller wrote: > >> >> >> > On Jan 31, 2021, at 8:19 PM, Josh Dersch wrote: >> > Well, what's interesting here is that on my system, switch S4 (MAINT >> STPR) steps the processor with switches S1 and S2 set to *any* >> configuration. >> >> Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1 >> S1:1 step by clock phase. The other two settings should free run the >> microcode. So yeah, sounds like something fishy there... The TIG card has >> more than a few analog components, and its not too unusual for these to get >> hung up on the adjacent card and have a leg pulled or sheared from the >> board. >> >> > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it >> asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and >> clears the Timing Generator and the Cache timing." >> >> Yup, that's one of the signals coming in to RAC E106. Probing there >> should indicate which of possible sources for ZAP is actually occurring >> (UBCE ROM INIT H on pins 2 and 3 there). >> >> DCLO is a classic... Make sure to 'scope it, because it sometimes has >> troublesome spikes that don't show on a multimeter. If you have H742s, >> there are some wet tantalums on the control board that sometimes leak and >> cause trouble with this. >> >> I'm sure you are raring to go -- hope those fans show up for you >> tomorrow, and will be interested to hear what you find! >> > > > Small update; fans arrived today and they are now installed. Voltages > tested on the backplane at the points called out in the service docs, and > all voltages dialed in to 5.05V. Ripple is within tolerances -- about > 200mV with some very short spikes that barely show up on my 'scope that go > to 300mV or so. Not sure if this is abnormal, I also saw these while > burning the supplies in on the bench. > > Checked the AC LO and DC LO signals at all the points called out in figure > 6-12 (p. II-6-22 of > http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf) > and appear to be correct. Looked at most of them under the scope and no > spikes (other than those in the ripple from the power supply.) > > Tomorrow I'll get some boards out on extenders and take a look at what's > going on at the logic level. > Another quick update: Had some time last night to poke at things. I started with the TIG, since I wanted to see if the crystal clock was running at all and if the right clock source was being selected. Sure enough, TIGB XTAL H was a flat line. Nothing happening at the crystal itself either. The crystal's casing was fairly corroded (which is interesting, since nothing else on the board is) and after a tiny bit of prodding one of the legs fell off, so I'm hoping that's the culprit. New crystal ordered and when it arrives we'll see... - Josh From michael.99.thompson at gmail.com Wed Feb 3 15:29:30 2021 From: michael.99.thompson at gmail.com (Michael Thompson) Date: Wed, 3 Feb 2021 16:29:30 -0500 Subject: Flip-Chip selloff (Al Kossow) In-Reply-To: References: Message-ID: > > > Date: Tue, 2 Feb 2021 09:19:08 -0800 > From: Al Kossow > Subject: Flip-Chip selloff > > I don't have any equipment that uses them any more, so I'll be ebaying off > my > A-W series flip chips over the next few days. The W's and PT08 boards are > up now > > https://www.ebay.com/itm/184647476832 > https://www.ebay.com/itm/184647420812 > I am still maintaining a PDP-8/I & TC01, PDP-8/L, PDP-8/S, PDP-9 & TC02, and PDP-12 for the Rhode Island Computer Museum. The RICM would happily accept any donated FlipChips, especially the go-fast B versions and anything else for the PDP-9. You can even get a charitable tax deduction for the donation. -- Michael Thompson From aek at bitsavers.org Wed Feb 3 15:57:47 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 13:57:47 -0800 Subject: Flip-Chip selloff (Al Kossow) In-Reply-To: References: Message-ID: On 2/3/21 1:29 PM, Michael Thompson via cctech wrote: > The RICM would happily accept any donated FlipChips Almost everything sold yesterday. From aek at bitsavers.org Wed Feb 3 16:01:33 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Feb 2021 14:01:33 -0800 Subject: Flip-Chip selloff (Al Kossow) In-Reply-To: References: Message-ID: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> On 2/3/21 1:57 PM, Al Kossow via cctech wrote: > On 2/3/21 1:29 PM, Michael Thompson via cctech wrote: > >> The RICM would happily accept any donated FlipChips > > Almost everything sold yesterday. > and I won't go into how disgusted I am with eBay's new seller payment system they forced everyone into on the first of the month. What used to appear in my Paypal account instantly when a buyer paid will now take a minimum of several days to appear in my bank account and eBay takes their cut up front, rather than once a month. From cz at alembic.crystel.com Wed Feb 3 16:36:04 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Wed, 3 Feb 2021 17:36:04 -0500 Subject: Flip-Chip selloff (Al Kossow) In-Reply-To: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> References: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> Message-ID: <22678c5c-a0c3-c8c6-fddb-7b852d5d51e8@alembic.crystel.com> I remember how annoying it was when Ebay required all payments through paypal. I preferred checks and getting all the money. With Ebay's cut plus I am sure the new payment cut will be above Paypal's it becomes less and less interesting to sell things there. But that's what happens when you have 100% of the market. Why don't we just use bitcoin? CZ On 2/3/2021 5:01 PM, Al Kossow via cctech wrote: > On 2/3/21 1:57 PM, Al Kossow via cctech wrote: >> On 2/3/21 1:29 PM, Michael Thompson via cctech wrote: >> >>> The RICM would happily accept any donated FlipChips >> >> Almost everything sold yesterday. >> > > and I won't go into how disgusted I am with eBay's new seller payment > system > they forced everyone into on the first of the month. > > What used to appear in my Paypal account instantly when a buyer paid > will now take a minimum of several days to appear in my bank account > and eBay takes their cut up front, rather than once a month. > From jdbryan at acm.org Wed Feb 3 18:35:01 2021 From: jdbryan at acm.org (J. David Bryan) Date: Wed, 03 Feb 2021 19:35:01 -0500 Subject: HP Journal back issues In-Reply-To: <721961577.1933451.1612344317479@mail.yahoo.com> References: <721961577.1933451.1612344317479.ref@mail.yahoo.com>, <721961577.1933451.1612344317479@mail.yahoo.com> Message-ID: On Wednesday, February 3, 2021 at 9:25, ED SHARPE via cctech wrote: > Indeed this site is great for reference but alas are too lo-res for good > museum display images. They appear to be scanned at 150 dpi. The ones here are scanned at 300 dpi: http://hparchive.com/hp_journals -- Dave From djg at pdp8online.com Wed Feb 3 18:44:32 2021 From: djg at pdp8online.com (David Gesswein) Date: Wed, 3 Feb 2021 19:44:32 -0500 Subject: Winchester SA1004 file recovering In-Reply-To: <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> References: <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> Message-ID: <20210204004432.GA328911@hugin3> On Wed, Feb 03, 2021 at 10:43:48AM +0100, Enrico email.it wrote: > > > A very dear friend first read in raw mode a 10MB Winchester hard disk model > Shugard SA1004 from which the files were correctly extracted and then set up > a test bench from which you can see in this video the complete system > operating with the HD ed il controller Shugart SASI SA1403: > https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov > a.mp4?dl=0 > > Despite we having attempted different readings (even using cards from the > first hard disk), using the same FLUXengine card > (http://cowlark.com/fluxengine/doc/building.html) the raw file still does > not present the Hard Disk directory, instead we read the information of the > files present but there may be bad bytes in these files and in the rest of > the disk as well. > I have only heard of FLUXengine being used for floppies. Can it handle hard drives? I hadn't heard of other boards that can read MFM hard drives other than mine http://www.pdp8online.com/mfm/. Other than the drive being faulty the biggest reason reading fails is the heads are no longer on track. You can tell that by looking at a histogram of the flux transition timing for a track. If they show peaks with good nulls between them the data is likely recoverable. If they don't you have to do something to shift the head position. Example histogram from by unit for ST506 type drive. https://groups.google.com/g/mfm-discuss/c/kjKez8vfapU/m/4XamyQJgCAAJ The SA1004 is a stepper drive. Some people have had success on other stepper drives with putting some rotation force or drag on the stepper to shift the heads. Creating a microstepper driver would give better control. May be able to say more if you provide more information on what you have done and checked to try to recover the contents. From cclist at sydex.com Thu Feb 4 01:17:22 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 3 Feb 2021 23:17:22 -0800 Subject: Greaseweazle In-Reply-To: References: <65A8BDDF-531E-45E3-9266-240B28E7CAE8@comcast.net> <5130CD62-B21B-43B4-A5C0-40A866C58EFE@comcast.net> <20210201191730.F2280CDBD@yagi.h-net.msu.edu> <20210201193210.85F83CE06@yagi.h-net.msu.edu> <20210201224140.5052C273A4@mx1.ezwind.net> <47ee082e-d610-f124-aecf-d714d0fcf57f@bitsavers.org> <5c716373-ac6f-836a-fc01-5c5c66e5c71d@sydex.com> <20210202145358.EF98E273F4@mx1.ezwind.net> <772277CF-4FE4-4CDB-85AC-DDF4DC325A24@eschatologist.net> Message-ID: <98a9dc9f-02f8-d2ab-daed-397a3b74f1f5@sydex.com> On 2/3/21 5:59 PM, Fred Cisin via cctalk wrote: > He humbly acknowledged things that he didn't know, actively solicited > comments and suggestions, and compiled a really nice collection of some > of the weird formats.? (including a link to Chuck's F85 page) I didn't ever send him an F85 diskette, just a sampling file from a Catweasel. One thing about those 5.25" 100 tpi diskettes is that data is clocked at about 350 KHz, as opposed to 250 KHz for a standard drive. The upshot is that even you find a 100 tpi drive, the drive electronics probably will require a bit of "tweaking" to give a bit more headroom in the bandpass. When I tried a stock MPI 52 100 tpi model, I had to modify it slightly to get it to work reliably; same for a Tandon TM-100-4M. I think Micropolis drives worked without modification, but the ones I have are single-sided and so haven't been used in some time. One of the things that I meant to get around to doing, but never did, was to take one of my Drivetech 5.25" drives and add my own PCB to do the micropositioning. (Those drives have two positioning steppers on a sort of lever arrangement--one for coarse and the other for fine). Nominally, the drives are 192 tpi and use an embedded servo for the high-capacity capability (which is why the drive couldn't format its own high-capacity floppies). --Chuck From cclist at sydex.com Thu Feb 4 01:25:11 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 3 Feb 2021 23:25:11 -0800 Subject: Winchester SA1004 file recovering In-Reply-To: <20210204004432.GA328911@hugin3> References: <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> <20210204004432.GA328911@hugin3> Message-ID: <5c5b37a7-eb1f-c4db-e901-d0d2d52bf5e6@sydex.com> The simplest thing, if you can locate one, is to find a WD1000/WD1001 controller board and hook it to a PC. Chances are overwhelming that it was used to write the SA100x in the first place. My first 5150 hard drive used such a setup--an SA1002, a WD1001 and a very small hand-wired ISA card for interface. I think I still have the interface card somewhere. --Chuck From toby at telegraphics.com.au Thu Feb 4 05:23:59 2021 From: toby at telegraphics.com.au (Toby Thain) Date: Thu, 4 Feb 2021 06:23:59 -0500 Subject: Flip-Chip selloff (Al Kossow) In-Reply-To: <22678c5c-a0c3-c8c6-fddb-7b852d5d51e8@alembic.crystel.com> References: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> <22678c5c-a0c3-c8c6-fddb-7b852d5d51e8@alembic.crystel.com> Message-ID: On 2021-02-03 5:36 p.m., Chris Zach via cctalk wrote: > Why don't we just use bitcoin? Thanks for the belly laugh From toby at telegraphics.com.au Thu Feb 4 05:23:59 2021 From: toby at telegraphics.com.au (Toby Thain) Date: Thu, 4 Feb 2021 06:23:59 -0500 Subject: Flip-Chip selloff (Al Kossow) In-Reply-To: <22678c5c-a0c3-c8c6-fddb-7b852d5d51e8@alembic.crystel.com> References: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> <22678c5c-a0c3-c8c6-fddb-7b852d5d51e8@alembic.crystel.com> Message-ID: On 2021-02-03 5:36 p.m., Chris Zach via cctalk wrote: > Why don't we just use bitcoin? Thanks for the belly laugh From lproven at gmail.com Thu Feb 4 09:07:58 2021 From: lproven at gmail.com (Liam Proven) Date: Thu, 4 Feb 2021 16:07:58 +0100 Subject: OT: pints, pounds (Was: APL\360 In-Reply-To: References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: On Mon, 1 Feb 2021 at 21:07, Fred Cisin via cctalk wrote: > > That is what it MEANS. > But, it's not quite right. It's off by about 4%. > A US pint of water weighs 1.043 pounds. > One "fluid ounce" (volume) of water weighs 1.043 ounces (weight)! Close enough for government work. With all the off-hand mental approximations people use to convert units, including some I think mentioned here, 4% is pretty good. I may use metric when I am measuring things myself, but I got my motorbike licence in 1991 and my car licence in 2005. I was solely taught and tested in MPH. For estimating stopping distances by eye, a metre is a yard, near enough -- and of course "car lengths" and seconds aren't affected. Keep 2 car lengths back under 30mph, and over that, maintain 2 seconds' braking distance, is metric-independent. > How much do you suppose a "pint" of ice cream weighs? Wouldn't know. I have never in my life seen such a unit on sale, I think. > And, not all beer has the same specific gravity. Alcohol is less dense > than water. > And, of course, further variation with temperature and atmospheric > pressure. Indeed so. It does get worse. When I emigrated, I had no problem adapting to buying half litres of beer -- or even, just once in a brewery in Slovakia, a litre of beer. But the strengths...! Czech beer comes in 10?, 11?, or 12?, and very occasionally 13?, 14? or even 17?-18?. I have almost never seen anything stronger. But what the heck is a ten-degree beer?! I'd never heard of degrees in beer before. Degrees proof, yes, but just halve that for %ABV, which is far more meaningful for me. But while a 10? beer being 5% alcohol by volume was just about believable, a 15% ABV beer seems unlikely. Well, it is. The system is "degrees Plato", a system so obscure there isn't even a Wikipedia page for it. And all I knew about Plato's drinking habits was: ? Plato, they say, could stick it away Half a crate of whiskey every day ? It's horribly complicated in use: http://8degreesplato.com/2017/05/31/so-what-is-degrees-plato/ No wonder nobody much outside Central Europe uses it. But this country is the world capital of beer -- they consume more per capita than anyone else. There are good reasons I like it here, and it's not the language. https://news.expats.cz/czech-food-drink/the-czech-republic-leads-all-nations-in-beer-consumption-per-capita-by-a-whopping-78/ The USA drinks 12x as much in total -- but has nearly 40x as many people. > And, if you are in England, > "A pint of water weighs a pound and a quarter." I believe I have heard that. Maybe this is why it is meaningless to me -- it doesn't work with UK Imperial units, only with American Imperial units. Yet more reason to burn imperial measurements in a fire and throw the ashes in the sea. > Despite very minor variances in gravity, Earth is MOSTLY HARMLESS. ;-) Did you know that the Central African Republic covers one of the largest magnetic anomalies in the world? It's so big it's named after the capital of the CAR, which will of course make it trivial for you all to look it up. > Instead, it just means that British pubs are not as stingy with their > beer. And, it doesn't need to be chilled to almost frozen to make it > drinkable. Very true. British beer is often served with very little foam on top, so the capacity of the glass is measured to the brim. A Czech beer without at least a few centimetres of foam is considered defective and most drinkers would send it back -- so Czech beer glasses are lined instead, to leave plenty of space for the froth on top. > I wish that there were a pub open. Oh gods, me too. > But, "The Albatross" (pub in Berkeley) > has closed down. forever. Can't stay in business with a lockdown. Sorry to hear that. > I can get beer delivered! Coincidentally, it is Corona beer! Oh my word. My deepest condolences. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From fritzm at fritzm.org Thu Feb 4 12:19:00 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Thu, 4 Feb 2021 10:19:00 -0800 Subject: PDP-11/70 debugging advice In-Reply-To: References: <7cf71ced-86dd-a099-897e-9f9c945360f6@shiresoft.com> <80C7C186-38CB-4CD7-90B7-967AB7CFCFC1@fritzm.org> <37001320-0D80-43BE-9C3E-F703D1D914CB@fritzm.org> <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> Message-ID: <10E7A741-1E56-4F6F-AAA5-93D828FFEF88@fritzm.org> > On Feb 3, 2021, at 8:07 PM, Josh Dersch wrote: > Sure enough, TIGB XTAL H was a flat line. Nothing happening at the crystal itself either. The crystal's casing was fairly corroded (which is interesting, since nothing else on the board is) and after a tiny bit of prodding one of the legs fell off, so I'm hoping that's the culprit. Ah. One of the switches on the KM11 should enable the machine to run off the separate RC maintenance clock on the TIG, if you want to keep going before your new crystal shows up. From cctalk at ibm51xx.net Thu Feb 4 11:50:33 2021 From: cctalk at ibm51xx.net (Ali) Date: Thu, 4 Feb 2021 09:50:33 -0800 Subject: ebay Payments WAS RE: Flip-Chip selloff (Al Kossow) In-Reply-To: <22678c5c-a0c3-c8c6-fddb-7b852d5d51e8@alembic.crystel.com> References: <58cc2d3c-86cd-e93d-b650-67f7905660b0@bitsavers.org> <22678c5c-a0c3-c8c6-fddb-7b852d5d51e8@alembic.crystel.com> Message-ID: <008701d6fb1e$3d8782d0$b8968870$@net> > I remember how annoying it was when Ebay required all payments through > paypal. I preferred checks and getting all the money. I am sure as a seller you liked it. As a buyer I wasn't about to send you a check for more than a couple of bucks without assurances (and no the FB system did not provide that). Let's be honest more stuff is selling, and for higher amounts, because of the ebay changes (CC only, money back guarantee, etc.). You can still get paid in cash or check by selling locally if you really prefer that. > Why don't we just use bitcoin? Because then inflation would go through the roof. Imagine you had paid one bitcoin ten years ago for a system. That would have been $2 (11/2011 price) Now with the change in price of bitcoin that coin is worth $37,046. Are you willing to sell your system to another buyer for $2 or even a $100? After all that system just cost you $37,044. Some people will not see it that way but most people will and want their money back plus interest.... -Ali From couryhouse at aol.com Thu Feb 4 11:50:41 2021 From: couryhouse at aol.com (ED SHARPE) Date: Thu, 4 Feb 2021 17:50:41 +0000 (UTC) Subject: HP Journal back issues References: <1334611751.2552040.1612461041807.ref@mail.yahoo.com> Message-ID: <1334611751.2552040.1612461041807@mail.yahoo.com> Thanks!?? The radio site aside? from? using low bit rate scan also I think compresses the pdf files. Ed# On Wednesday, February 3, 2021 J. David Bryan via cctech wrote: On Wednesday, February 3, 2021 at 9:25, ED SHARPE via cctech wrote: > Indeed this site is great for reference but alas are too lo-res for good > museum display images. They appear to be scanned at 150 dpi. The ones here are scanned at 300 dpi: ? http://hparchive.com/hp_journals ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- Dave From enrico.lazzerini at email.it Thu Feb 4 12:30:24 2021 From: enrico.lazzerini at email.it (Enrico email.it) Date: Thu, 4 Feb 2021 19:30:24 +0100 Subject: R: Winchester SA1004 file recovering In-Reply-To: <20210204004432.GA328911@hugin3> References: <428DCA86911E4810ADE3F61EDBC7F77F@Enrico> <20210204004432.GA328911@hugin3> Message-ID: <86D646239B1A4FBCBA90A22C2E291791@Enrico> I wish apologize me. the work was done by a dear friend and I had mistakenly understood that he had used the Fluxengine card instead he used this card http://www.pdp8online.com/mfm/ with add-on daughter card interfacing with the SASI controller SA-1403. Since, despite repeated readings, we are not able to correctly extract the data from the second Winchester Hard Disk, we will probably operate by trying to rely on someone able to intervene on the platters of the SA-1004 Hard Disk, hoping to be able to recover as much as possible. Enrico -----Messaggio originale----- Da: cctech [mailto:cctech-bounces at classiccmp.org] Per conto di David Gesswein via cctech Inviato: gioved? 4 febbraio 2021 01:45 A: cctech at classiccmp.org Oggetto: Re: Winchester SA1004 file recovering On Wed, Feb 03, 2021 at 10:43:48AM +0100, Enrico email.it wrote: > > > A very dear friend first read in raw mode a 10MB Winchester hard disk model > Shugard SA1004 from which the files were correctly extracted and then set up > a test bench from which you can see in this video the complete system > operating with the HD ed il controller Shugart SASI SA1403: > https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov > a.mp4?dl=0 > > Despite we having attempted different readings (even using cards from the > first hard disk), using the same FLUXengine card > (http://cowlark.com/fluxengine/doc/building.html) the raw file still does > not present the Hard Disk directory, instead we read the information of the > files present but there may be bad bytes in these files and in the rest of > the disk as well. > I have only heard of FLUXengine being used for floppies. Can it handle hard drives? I hadn't heard of other boards that can read MFM hard drives other than mine http://www.pdp8online.com/mfm/. Other than the drive being faulty the biggest reason reading fails is the heads are no longer on track. You can tell that by looking at a histogram of the flux transition timing for a track. If they show peaks with good nulls between them the data is likely recoverable. If they don't you have to do something to shift the head position. Example histogram from by unit for ST506 type drive. https://groups.google.com/g/mfm-discuss/c/kjKez8vfapU/m/4XamyQJgCAAJ The SA1004 is a stepper drive. Some people have had success on other stepper drives with putting some rotation force or drag on the stepper to shift the heads. Creating a microstepper driver would give better control. May be able to say more if you provide more information on what you have done and checked to try to recover the contents. From derschjo at gmail.com Thu Feb 4 15:51:20 2021 From: derschjo at gmail.com (Josh Dersch) Date: Thu, 4 Feb 2021 13:51:20 -0800 Subject: PDP-11/70 debugging advice In-Reply-To: <10E7A741-1E56-4F6F-AAA5-93D828FFEF88@fritzm.org> References: <7cf71ced-86dd-a099-897e-9f9c945360f6@shiresoft.com> <80C7C186-38CB-4CD7-90B7-967AB7CFCFC1@fritzm.org> <37001320-0D80-43BE-9C3E-F703D1D914CB@fritzm.org> <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> <10E7A741-1E56-4F6F-AAA5-93D828FFEF88@fritzm.org> Message-ID: On Thu, Feb 4, 2021 at 10:19 AM Fritz Mueller via cctalk < cctalk at classiccmp.org> wrote: > > > > On Feb 3, 2021, at 8:07 PM, Josh Dersch wrote: > > Sure enough, TIGB XTAL H was a flat line. Nothing happening at the > crystal itself either. The crystal's casing was fairly corroded (which is > interesting, since nothing else on the board is) and after a tiny bit of > prodding one of the legs fell off, so I'm hoping that's the culprit. > > Ah. One of the switches on the KM11 should enable the machine to run off > the separate RC maintenance clock on the TIG, if you want to keep going > before your new crystal shows up. Yeah, you'd think... but it doesn't work :). I mentioned earlier in this thread that it's stuck in single-step mode. From the schematics it looks like the crystal clock needs to be running to clock some of the flip flops used in the "Source Synchronizer" to select the proper clock source. My guess is that since the clock isn't running, the flip flops are left in a weird state. Or there's another problem here unrelated to the crystal clock. I guess I'll see in a day or so. - Josh From fritzm at fritzm.org Thu Feb 4 16:42:19 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Thu, 4 Feb 2021 14:42:19 -0800 Subject: PDP-11/70 debugging advice In-Reply-To: References: <7cf71ced-86dd-a099-897e-9f9c945360f6@shiresoft.com> <80C7C186-38CB-4CD7-90B7-967AB7CFCFC1@fritzm.org> <37001320-0D80-43BE-9C3E-F703D1D914CB@fritzm.org> <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> <10E7A741-1E56-4F6F-AAA5-93D828FFEF88@fritzm.org> Message-ID: <902FC6D5-197D-4741-A302-B552D348EB5C@fritzm.org> > On Feb 4, 2021, at 1:51 PM, Josh Dersch wrote: > [RC maintenance clock] Yeah, you'd think... but it doesn't work :). I mentioned earlier in this thread that it's stuck in single-step mode. From the schematics it looks like the crystal clock needs to be running to clock some of the flip flops used in the "Source Synchronizer" to select the proper clock source. My guess is that since the clock isn't running, the flip flops are left in a weird state. Oh, interesting! Noted for future reference. The TIG is not exactly straightforward... From cisin at xenosoft.com Thu Feb 4 18:33:03 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 4 Feb 2021 16:33:03 -0800 (PST) Subject: PRIVATE: OT: pints, pounds (Was: APL\360 In-Reply-To: References: <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: > I may use metric when I am measuring things myself, but I got my > motorbike licence in 1991 and my car licence in 2005. I was solely > taught and tested in MPH. For estimating stopping distances by eye, a > metre is a yard, near enough -- and of course "car lengths" and > seconds aren't affected. Keep 2 car lengths back under 30mph, and over > that, maintain 2 seconds' braking distance, is metric-independent. But, none of those are accurate for the physics. Can an Isetta follow much closer than a Cadillac? I don't have an Isetta. I'd like one. I'd love to get the Micro-Lino (a current Swiss electric replica of an Isetta), but they don't plan to export to USA. Stopping distance is also certainly not a constant of 2 seconds, even if talking about both vehicles making a panic stop. My current car (a Prius "Prime") can stop in significantly less distance than my early VWs did. In a panic stop, a VW 2 seconds behind me would plow right into me. >> How much do you suppose a "pint" of ice cream weighs? > Wouldn't know. I have never in my life seen such a unit on sale, I think. Ice Cream used to be sold in 1/2 gallon. The half gallon container has been reduced to "1.5 quarts/1.41L". "The reduction in size is to avoid raising the price" (which went up ALSO) Half gallon carton of milk (64 fluid oz) is now a 54 oz carton. Tiny cartons of ice cream exit, and used to be called "Pints": 16 fluid oz/473ml DELIVERY of ice cream is pretty risky; good if you are one of the first stops of the delivery, . . . > Yet more reason to burn imperial measurements in a fire and throw the > ashes in the sea. YES >> Despite very minor variances in gravity, Earth is MOSTLY HARMLESS. > ;-) DNA once told aspiring writers, "Never blow up the planet in the first chapter; you are likely to find that you need it later." > Did you know that the Central African Republic covers one of the > largest magnetic anomalies in the world? It's so big it's named after > the capital of the CAR, which will of course make it trivial for you > all to look it up. Interesting. And never noticed until 1950? >> I can get beer delivered! Coincidentally, it is Corona beer! > Oh my word. My deepest condolences. It's a Mexican American beer. I drink very little. If I were a drnker, I'd have to find something else. -- Grumpy Ol' Fred cisin at xenosoft.com From cisin at xenosoft.com Thu Feb 4 18:50:09 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 4 Feb 2021 16:50:09 -0800 (PST) Subject: APOLOGIES; was not meant to be to the list (Was: PRIVATE: OT: pints, pounds (Was: APL\360 In-Reply-To: References: <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: Sorry about that. I didn't pay close enough attention to my outgoing header. From shumaker at att.net Thu Feb 4 22:22:32 2021 From: shumaker at att.net (s shumaker) Date: Thu, 4 Feb 2021 20:22:32 -0800 Subject: UDS EIA module for ASR33 References: <971565db-e43b-1582-99b3-875cee1d8dd6.ref@att.net> Message-ID: <971565db-e43b-1582-99b3-875cee1d8dd6@att.net> Recently acquired an ASR33 with an old EIA (RS-232) Interface convertor module. ? It came with a two page spec and cable pinout sheet that is more hole than it is paper. Manufacturer is United Data Services (UDS) in Phoenix.? Model seems to be 312 A 0568? (might be 0563)? Google hasn't been much help and Bitsavers is silent as well..? Herb Johnson of Retrocomputing.com has 312 A 0567 which appears similar but not close enough to be useful. Anyone familiar with this unit who could share docs??? (willing to scan and share if desired) Steve From derschjo at gmail.com Thu Feb 4 23:45:39 2021 From: derschjo at gmail.com (Josh Dersch) Date: Thu, 4 Feb 2021 21:45:39 -0800 Subject: PDP-11/70 debugging advice In-Reply-To: <902FC6D5-197D-4741-A302-B552D348EB5C@fritzm.org> References: <7cf71ced-86dd-a099-897e-9f9c945360f6@shiresoft.com> <80C7C186-38CB-4CD7-90B7-967AB7CFCFC1@fritzm.org> <37001320-0D80-43BE-9C3E-F703D1D914CB@fritzm.org> <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> <10E7A741-1E56-4F6F-AAA5-93D828FFEF88@fritzm.org> <902FC6D5-197D-4741-A302-B552D348EB5C@fritzm.org> Message-ID: On Thu, Feb 4, 2021 at 2:42 PM Fritz Mueller via cctalk < cctalk at classiccmp.org> wrote: > > > On Feb 4, 2021, at 1:51 PM, Josh Dersch wrote: > > [RC maintenance clock] Yeah, you'd think... but it doesn't work :). I > mentioned earlier in this thread that it's stuck in single-step mode. From > the schematics it looks like the crystal clock needs to be running to clock > some of the flip flops used in the "Source Synchronizer" to select the > proper clock source. My guess is that since the clock isn't running, the > flip flops are left in a weird state. > > Oh, interesting! Noted for future reference. The TIG is not exactly > straightforward... So I realized today that, hey, I have a burned-out 11/45 in the garage, and it has a TIG (albeit an M8109), and it also has a 33.33Mhz crystal on it. And because I'm impatient and can't wait for my Digi-Key order to come in, I went out and borrowed the crystal from the 11/45's TIG and installed it in the 11/70's. The 11/70 is now somewhat operable. I can examine and deposit memory, at least for a short while -- after the system warms up for 30 seconds or so the Load Address switch stops functioning. (Happens gradually, too... for 10 seconds or so it works every other time you toggle it, then it stops entirely.) Everything else seems to work properly after this happens, so I'm kind of curious if there's an IC on the front panel that's gone bad, though I suppose it's still completely possible it's something on the CPU end. I'll have to do some debugging, but it'll have to wait until this weekend. As an aside... The M8109 is very similar looking to the M8139... any ideas what the functional differences are? There seems to be an extra IC and some ECO wiring on the M8139. I'll have to take a closer look someday. - Josh From fritzm at fritzm.org Fri Feb 5 02:29:11 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Fri, 5 Feb 2021 00:29:11 -0800 Subject: PDP-11/70 debugging advice In-Reply-To: References: <7cf71ced-86dd-a099-897e-9f9c945360f6@shiresoft.com> <80C7C186-38CB-4CD7-90B7-967AB7CFCFC1@fritzm.org> <37001320-0D80-43BE-9C3E-F703D1D914CB@fritzm.org> <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> <10E7A741-1E56-4F6F-AAA5-93D828FFEF88@fritzm.org> <902FC6D5-197D-4741-A302-B552D348EB5C@fritzm.org> Message-ID: <96E25710-4FAB-47D7-8F15-D5CA11C87825@fritzm.org> > On Feb 4, 2021, at 9:45 PM, Josh Dersch wrote: > The 11/70 is now somewhat operable. I can examine and deposit memory, at least for a short while -- after the system warms up for 30 seconds or so the Load Address switch stops functioning. Nice!! One handy test on '45 is to put the data display knob to bus address; if the microcode is still running in the control panel idle loop (halt switch down or fault) the data lights will follow along with the toggles. This is a super quick way to tell if the microcode is still running or if it is wedged. (The '45 and '70 microcode seem quite similar, so your '70 might have the same feature? I haven't looked at the flow diagrams yet to know for sure.) --FritzM. From derschjo at gmail.com Fri Feb 5 12:02:05 2021 From: derschjo at gmail.com (Josh Dersch) Date: Fri, 5 Feb 2021 10:02:05 -0800 Subject: PDP-11/70 debugging advice In-Reply-To: <96E25710-4FAB-47D7-8F15-D5CA11C87825@fritzm.org> References: <7cf71ced-86dd-a099-897e-9f9c945360f6@shiresoft.com> <80C7C186-38CB-4CD7-90B7-967AB7CFCFC1@fritzm.org> <37001320-0D80-43BE-9C3E-F703D1D914CB@fritzm.org> <68F666AE-C3A7-4797-B190-D1785B60A376@fritzm.org> <10E7A741-1E56-4F6F-AAA5-93D828FFEF88@fritzm.org> <902FC6D5-197D-4741-A302-B552D348EB5C@fritzm.org> <96E25710-4FAB-47D7-8F15-D5CA11C87825@fritzm.org> Message-ID: On Fri, Feb 5, 2021 at 12:29 AM Fritz Mueller via cctalk < cctalk at classiccmp.org> wrote: > > > > On Feb 4, 2021, at 9:45 PM, Josh Dersch wrote: > > The 11/70 is now somewhat operable. I can examine and deposit memory, > at least for a short while -- after the system warms up for 30 seconds or > so the Load Address switch stops functioning. > > Nice!! > > One handy test on '45 is to put the data display knob to bus address; if > the microcode is still running in the control panel idle loop (halt switch > down or fault) the data lights will follow along with the toggles. This is > a super quick way to tell if the microcode is still running or if it is > wedged. > > (The '45 and '70 microcode seem quite similar, so your '70 might have the > same feature? I haven't looked at the flow diagrams yet to know for sure.) > Thanks for the tip, I'll check that out. Before I went to bed I did a bit more poking. Upon closer examination, the Load Address switch is still being recognized: the Data lights get reset to 0 after it's toggled. So the microcode is taking a jump to ADR.00 when the switch is toggled. It looks like what isn't happening is the PCA <- BR in T5. So I have a couple of places to look -- it's possible that the T5 clock signal is going wrong after warming up (note that ADR.00 is the only step in the console flow that does anything in T5, except maybe RDP.00 -- I'm not sure if that's a "5" or a 3"). (See flow 14, p. 18 of http://bitsavers.org/pdf/dec/pdp11/1170/MP0KB11-C0_1170engDrw_Nov75.pdf) Or something's going wrong with the PCA <- BR operation. I put the KM11 back in, and while single-stepping or running under the RC clock (which is currently set to a really low clock rate, like 7Mhz, for some reason) Load Address works fine. Seems like some component has slowed down a bit and stops operating correctly at full speed. Something to poke at this weekend... - Josh > --FritzM. > > From nw.johnson at ieee.org Sat Feb 6 15:25:48 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Sat, 6 Feb 2021 16:25:48 -0500 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 Message-ID: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> Hi all, I wonder if anybody has one with the terminators installed that can read off the p/n for these SIPs The manual says they are 8-pin 7 resistor 220/330 ones, but that is not possible! To put 7 resistor pairs to 220 and 330 you need a 9-pin, unless you have one resistor SIP for 220 and another for 330!? But there are 2 so that leaves an odd number! The sockets are 9-pin.? I have yet to find any 9-pin ones on digikey cheers, Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org From elson at pico-systems.com Sat Feb 6 16:44:53 2021 From: elson at pico-systems.com (Jon Elson) Date: Sat, 06 Feb 2021 16:44:53 -0600 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> Message-ID: <601F1BE5.40204@pico-systems.com> On 02/06/2021 03:25 PM, Nigel Johnson via cctalk wrote: > Hi all, I wonder if anybody has one with the terminators installed that > can read off the p/n for these SIPs > > The manual says they are 8-pin 7 resistor 220/330 ones, but that is not > possible! To put 7 resistor pairs to 220 and 330 you need a 9-pin, > unless you have one resistor SIP for 220 and another for 330! But there > are 2 so that leaves an odd number! The sockets are 9-pin. I have yet > to find any 9-pin ones on digikey > > I have a differential 8200 here, it does not appear to have any internal terminators, or anything pluggable on the SCSI interface board. Jon From glen.slick at gmail.com Sat Feb 6 16:48:29 2021 From: glen.slick at gmail.com (Glen Slick) Date: Sat, 6 Feb 2021 14:48:29 -0800 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> Message-ID: On Sat, Feb 6, 2021 at 1:26 PM Nigel Johnson via cctalk wrote: > > Hi all, I wonder if anybody has one with the terminators installed that > can read off the p/n for these SIPs > > The manual says they are 8-pin 7 resistor 220/330 ones, but that is not > possible! To put 7 resistor pairs to 220 and 330 you need a 9-pin, > unless you have one resistor SIP for 220 and another for 330! But there > are 2 so that leaves an odd number! The sockets are 9-pin. I have yet > to find any 9-pin ones on digikey > I just took a look at one of my EXB-8200 tape drives. Unfortunately it wasn't set up for internal termination and the resistor packs were removed. It has (3x) 8-pin SIP sockets. Bourns 4608X-104-221/331L / 4608X-104-221/331LF and 4308R-104-221/331L parts are in stock at Mouser and Digi-Key. Those are 8-pin, 12-resistor dual termination networks. (3x) 4608X-104-221/331 parts would have the necessary number for terminations for single-ended SCSI: https://www.bourns.com/pdfs/scsi.pdf From cclist at sydex.com Sat Feb 6 17:25:17 2021 From: cclist at sydex.com (Chuck Guzis) Date: Sat, 6 Feb 2021 15:25:17 -0800 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> Message-ID: <7b6161f4-8e8b-6e01-759b-97127b46f8bc@sydex.com> I've got an 8200 here, but I'll have to open the enclosure to see. But if it's a 7 pin device, the part number would be a Bourns 4607X-104-221/331L. Digikey claims to have them in stock. --Chuck From cclist at sydex.com Sat Feb 6 17:28:36 2021 From: cclist at sydex.com (Chuck Guzis) Date: Sat, 6 Feb 2021 15:28:36 -0800 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> Message-ID: <7062715b-5afa-8869-a551-e249f3f4ea59@sydex.com> ...and if a 9 pin SIP, the part number would be 4609X-104-221/331L. They're a bit harder to find. --Chuck From nw.johnson at ieee.org Sat Feb 6 17:55:24 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Sat, 6 Feb 2021 18:55:24 -0500 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: <7062715b-5afa-8869-a551-e249f3f4ea59@sydex.com> References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> <7062715b-5afa-8869-a551-e249f3f4ea59@sydex.com> Message-ID: <5bbb69ab-af60-a8c6-d53f-fdd388665091@ieee.org> I agree.? None on Digikey.? The manual says 7-resistor 8 pin, which is impossible if one resistor on each pin goes to 5V and the other to Vss, but the sockets are actually 9-pin! If Chuck can give me a definite part number I will be on the way.? The controller says it specifically supports an EXB 8200 so should be able to make it work with a terminator! cheers, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU ?Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-06 6:28 p.m., Chuck Guzis via cctalk wrote: > ...and if a 9 pin SIP, the part number would be 4609X-104-221/331L. > > They're a bit harder to find. > > --Chuck > From nw.johnson at ieee.org Sat Feb 6 17:59:18 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Sat, 6 Feb 2021 18:59:18 -0500 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> Message-ID: <944e9895-6ac9-a2ca-7d39-43fd19a2964d@ieee.org> I stand corrected, my 8200 has 3x 8-pin sip sockets! Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-06 5:48 p.m., Glen Slick via cctalk wrote: > On Sat, Feb 6, 2021 at 1:26 PM Nigel Johnson via cctalk > wrote: >> Hi all, I wonder if anybody has one with the terminators installed that >> can read off the p/n for these SIPs >> >> The manual says they are 8-pin 7 resistor 220/330 ones, but that is not >> possible! To put 7 resistor pairs to 220 and 330 you need a 9-pin, >> unless you have one resistor SIP for 220 and another for 330! But there >> are 2 so that leaves an odd number! The sockets are 9-pin. I have yet >> to find any 9-pin ones on digikey >> > I just took a look at one of my EXB-8200 tape drives. Unfortunately it > wasn't set up for internal termination and the resistor packs were > removed. It has (3x) 8-pin SIP sockets. > > Bourns 4608X-104-221/331L / 4608X-104-221/331LF and 4308R-104-221/331L > parts are in stock at Mouser and Digi-Key. Those are 8-pin, > 12-resistor dual termination networks. > > (3x) 4608X-104-221/331 parts would have the necessary number for > terminations for single-ended SCSI: > > https://www.bourns.com/pdfs/scsi.pdf From glen.slick at gmail.com Sat Feb 6 18:23:47 2021 From: glen.slick at gmail.com (Glen Slick) Date: Sat, 6 Feb 2021 16:23:47 -0800 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: <944e9895-6ac9-a2ca-7d39-43fd19a2964d@ieee.org> References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> <944e9895-6ac9-a2ca-7d39-43fd19a2964d@ieee.org> Message-ID: On Sat, Feb 6, 2021 at 3:59 PM Nigel Johnson via cctalk wrote: > > I stand corrected, my 8200 has 3x 8-pin sip sockets! > > Nigel OK, that matches my two EXB-8200 that I just looked at, and also these images from eBay listings: https://i.ebayimg.com/images/g/rh0AAOSwSdFe3p7v/s-l1600.jpg https://i.ebayimg.com/images/g/Cq4AAOSwFNFf8B9i/s-l1600.jpg https://i.ebayimg.com/images/g/Cr8AAOSwPbBf0Ajm/s-l1600.jpg https://i.ebayimg.com/images/g/pkkAAOSwjylaob~P/s-l1600.jpg https://i.ebayimg.com/images/g/C20AAOSwq4VaOqBm/s-l1600.jpg The first image above shows (3x) 8-pin SIP parts installed, which appear visually similar to the parts that are installed in the second EXB-8200 I have. I don't recognize the part number. It appears to be something like "WT04 9020", where "WT" could possibly be Walsin Technology. I can find some datasheets for Walsin Technology WT04 surface mount resistor arrays, but not SIP parts. Maybe the "9020" is a date code, and these are obsolete parts from that vendor and datasheets are no longer available, or at least not easy to find. In any case, current Bourns 4608X-104-221/331L / 4608X-104-221/331LF or 4308R-104-221/331L parts might do the trick. (Or just cable it up for external termination). From nw.johnson at ieee.org Sat Feb 6 18:33:24 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Sat, 6 Feb 2021 19:33:24 -0500 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> <944e9895-6ac9-a2ca-7d39-43fd19a2964d@ieee.org> Message-ID: <9e9d5cad-6bd9-cc81-3fa5-2590de070ac0@ieee.org> Thanks for that. Pity the people who post on ebay don't give close-ups of the resistor arrays! My serial is 530573 so it should be a later rev that will work with the cleaning cartridge. I have some 4608X-104-221/331L currently in my digikey shopping basket - I will place order on Monday after I confirm that the two outside pins go to Vcc and Fss and the six others go to signal pins on the bus. External not an option really - tight fit inside rack and more parts to buy than three resistor packs! Now off to browse ebay pictures :-) Thanks again, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-06 7:23 p.m., Glen Slick via cctalk wrote: > On Sat, Feb 6, 2021 at 3:59 PM Nigel Johnson via cctalk > wrote: >> I stand corrected, my 8200 has 3x 8-pin sip sockets! >> >> Nigel > OK, that matches my two EXB-8200 that I just looked at, and also these > images from eBay listings: > > https://i.ebayimg.com/images/g/rh0AAOSwSdFe3p7v/s-l1600.jpg > https://i.ebayimg.com/images/g/Cq4AAOSwFNFf8B9i/s-l1600.jpg > https://i.ebayimg.com/images/g/Cr8AAOSwPbBf0Ajm/s-l1600.jpg > https://i.ebayimg.com/images/g/pkkAAOSwjylaob~P/s-l1600.jpg > https://i.ebayimg.com/images/g/C20AAOSwq4VaOqBm/s-l1600.jpg > > The first image above shows (3x) 8-pin SIP parts installed, which > appear visually similar to the parts that are installed in the second > EXB-8200 I have. I don't recognize the part number. It appears to be > something like "WT04 9020", where "WT" could possibly be Walsin > Technology. I can find some datasheets for Walsin Technology WT04 > surface mount resistor arrays, but not SIP parts. Maybe the "9020" is > a date code, and these are obsolete parts from that vendor and > datasheets are no longer available, or at least not easy to find. > > In any case, current Bourns 4608X-104-221/331L / 4608X-104-221/331LF > or 4308R-104-221/331L parts might do the trick. (Or just cable it up > for external termination). From glen.slick at gmail.com Sat Feb 6 19:51:44 2021 From: glen.slick at gmail.com (Glen Slick) Date: Sat, 6 Feb 2021 17:51:44 -0800 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: <9e9d5cad-6bd9-cc81-3fa5-2590de070ac0@ieee.org> References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> <944e9895-6ac9-a2ca-7d39-43fd19a2964d@ieee.org> <9e9d5cad-6bd9-cc81-3fa5-2590de070ac0@ieee.org> Message-ID: On Sat, Feb 6, 2021 at 4:33 PM Nigel Johnson via cctalk wrote: > > I have some 4608X-104-221/331L currently in my digikey shopping basket - > I will place order on Monday after I confirm that the two outside pins > go to Vcc and Fss and the six others go to signal pins on the bus. > I pulled the SIP packs out of my EXB-8200 because it is mounted in an external case and the next time I go to use it I would probably attach an external terminator to it without thinking that it was terminated internally. I measured ~91-Ohm between pin 1 and pin 8, which is the expected value for (6x) (220-Ohm + 330-Ohm) in parallel. I measured ~163-Ohm between pin 1 and each of pin 2, 3, 4, 5, 6, 7. That is the expected value for 330-Ohm in parallel with (220-Ohm in series with 110-Ohm ((5x) (220-Ohm + 330-Ohm) in parallel). I measured ~145-Ohm between pin 8 and each of 2, 3, 4, 5, 6, 7. That is the expected value for 220-Ohm in parallel with (330-Ohm in series with 110-Ohm ((5x) (220-Ohm + 330-Ohm) in parallel). So a 4608X-104-221/331L should be a functional equivalent (220-Ohm in common to pin 8, 330-Ohm in common to pin 1). From nw.johnson at ieee.org Sat Feb 6 20:08:08 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Sat, 6 Feb 2021 21:08:08 -0500 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> <944e9895-6ac9-a2ca-7d39-43fd19a2964d@ieee.org> <9e9d5cad-6bd9-cc81-3fa5-2590de070ac0@ieee.org> Message-ID: <079ba638-18c5-8c39-6fb9-4d18e5cae9b9@ieee.org> On 2021-02-06 8:51 p.m., Glen Slick via cctalk wrote: > On Sat, Feb 6, 2021 at 4:33 PM Nigel Johnson via cctalk > wrote: >> I have some 4608X-104-221/331L currently in my digikey shopping basket - >> I will place order on Monday after I confirm that the two outside pins >> go to Vcc and Fss and the six others go to signal pins on the bus. >> > I pulled the SIP packs out of my EXB-8200 because it is mounted in an > external case and the next time I go to use it I would probably attach > an external terminator to it without thinking that it was terminated > internally. > > I measured ~91-Ohm between pin 1 and pin 8, which is the expected > value for (6x) (220-Ohm + 330-Ohm) in parallel. > > I measured ~163-Ohm between pin 1 and each of pin 2, 3, 4, 5, 6, 7. > That is the expected value for 330-Ohm in parallel with (220-Ohm in > series with 110-Ohm ((5x) (220-Ohm + 330-Ohm) in parallel). > > I measured ~145-Ohm between pin 8 and each of 2, 3, 4, 5, 6, 7. That > is the expected value for 220-Ohm in parallel with (330-Ohm in series > with 110-Ohm ((5x) (220-Ohm + 330-Ohm) in parallel). > > So a 4608X-104-221/331L should be a functional equivalent (220-Ohm in > common to pin 8, 330-Ohm in common to pin 1). Thank you, Glen.? I will order some from Digikey on Monday.? So it seems that the manual is lying when it says it has seven resistors - I didn't think that was likely - in that case you would need a a separate pack for the other side of the pull and there are 3 - not an even number. I also powered up the unit and checked that I have 5V on on eend and ground on the other, so all looks good. Thanks to all for your help, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org From mattislind at gmail.com Sun Feb 7 15:12:03 2021 From: mattislind at gmail.com (Mattis Lind) Date: Sun, 7 Feb 2021 22:12:03 +0100 Subject: RX02 DMK image to raw tool? Message-ID: This is highly annoying. Back in 2015 I did exactly this and now I have forgotten how. I dumped a set of RX02 disks with catweasel into .DMK and now I want a raw sector image to be able to test them with SimH. What is a good tool to use? I have some faint memory of glancing through hexdumps of .dmk files. Perhaps I did something myself using dmklib by Eric Smith? Don't really remember, unfortunately. But surely someone else has already done this, right? /Mattis From spectre at floodgap.com Sun Feb 7 19:14:27 2021 From: spectre at floodgap.com (Cameron Kaiser) Date: Sun, 7 Feb 2021 17:14:27 -0800 (PST) Subject: looking for egcs for PowerPC BeOS R4 Message-ID: <202102080114.1181ERW711468968@floodgap.com> I know it exists, or existed, as there are references all over to it from the skeletal remains of various BeWare mirrors. However, the package itself has disappeared. The Intel version is marginally easier to find but if anyone knows where the *PowerPC* one is (I'll take R3 or R4) please advise. I guess, since I've got mwcc on it, I could try to reconstruct it, but I don't know if I would have all the BeOS-specific changes. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- My opinions may have changed, but not the fact that I'm still right. ------- From curiousmarc3 at gmail.com Sun Feb 7 19:59:52 2021 From: curiousmarc3 at gmail.com (Curious Marc) Date: Sun, 7 Feb 2021 17:59:52 -0800 Subject: looking for egcs for PowerPC BeOS R4 In-Reply-To: <202102080114.1181ERW711468968@floodgap.com> References: <202102080114.1181ERW711468968@floodgap.com> Message-ID: <5270012C-39B4-43BE-8B9A-50A39D37FD0E@gmail.com> I can ask Jean-Louis Gass?e if that helps. Let me know if you want me to try. Marc > On Feb 7, 2021, at 5:14 PM, Cameron Kaiser via cctalk wrote: > > ?I know it exists, or existed, as there are references all over to it from > the skeletal remains of various BeWare mirrors. However, the package itself > has disappeared. The Intel version is marginally easier to find but if anyone > knows where the *PowerPC* one is (I'll take R3 or R4) please advise. > > I guess, since I've got mwcc on it, I could try to reconstruct it, but I > don't know if I would have all the BeOS-specific changes. > > -- > ------------------------------------ personal: http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com > -- My opinions may have changed, but not the fact that I'm still right. ------- From jfoust at threedee.com Mon Feb 8 12:02:46 2021 From: jfoust at threedee.com (John Foust) Date: Mon, 08 Feb 2021 12:02:46 -0600 Subject: Fwd: [GreenKeys] Teletype 33 KSR free in Knoxville, TN, USA Message-ID: <20210208180449.AA64E2754F@mx1.ezwind.net> The guy posted today, saying they're still available... - John >From: >To: >Date: Sun, 27 Dec 2020 18:23:31 -0500 >Subject: [GreenKeys] Equipment Available > >I have the following available for pickup in the Knoxville TN area, it from >the estate of an old ham buddy that's now in the nursing home with >Alzheimer's. All was salvaged from his property which was sold to help >defer his nursing home expenses, and was going to go in the dumpster. >Really just wanted to save this stuff from the dumpster, and its free to a >good home, BUT if it works for you (whomever comes and get this stuff) a >donation that I could forward to his Nephew to help cover his nursing home >costs would be greatly appreciated. > >There are two Teletype Model 35 KSRs and at least one 33 KSR. Also there is >an model 14 Printing Reperf FRXD (very similar to frxd-1311-04.jpg (800?600) >(navy-radio.com) on >Nick England's site. There may be some other in the future and possibly >some 11/16 paper tape, but this may be spoken for. > >All was stored in a dry outbuilding, but was in the building for well over >twenty years. It took the best part of a day to dig it out, salvage and >carry it out of said storage building. > > > > >I can provide additional more detailed photos if required, but please don't >ask unless your really interested and serious. The empty brass nor the gun >they were fired in are no longer available I'm keeping it.....Ha Ha. > >PS this stuff will not be available indefinitely, I don't have the space to >store it for another twenty years, it will probably go onto the dump or be >dismantle for parts before the end of February. > >Steve >KM4V From david4602 at gmail.com Mon Feb 8 13:39:05 2021 From: david4602 at gmail.com (David Schmidt) Date: Mon, 8 Feb 2021 14:39:05 -0500 Subject: RX02 DMK image to raw tool? In-Reply-To: References: Message-ID: <0928d97b-d92d-d007-2214-73a9e2891514@gmail.com> On 2/8/21 1:00 PM, Mattis Lind wrote: > This is highly annoying. Back in 2015 I did exactly this and now I have > forgotten how. > > I dumped a set of RX02 disks with catweasel into .DMK and now I want a raw > sector image to be able to test them with SimH. > > What is a good tool to use? I have some faint memory of glancing through > hexdumps of .dmk files. Perhaps I did something myself using dmklib by Eric > Smith? Don't really remember, unfortunately. > > But surely someone else has already done this, right? > > /Mattis I wrote my own, not knowing where another one lived. I happen to think in Java, so that's what it's implemented in. Description is here: https://github.com/RetroFloppy/transformenator/wiki/Utility-Functions#dmk2raw Code is here: https://github.com/RetroFloppy/transformenator/blob/master/src/org/transformenator/util/Dmk2Raw.java The only thing of interest is the cw2dmk tool would read RX01 disks and "double" the data - so my tool will make an attempt to detect that and halve the data back out the other end. - David From billdegnan at gmail.com Mon Feb 8 16:53:21 2021 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 8 Feb 2021 17:53:21 -0500 Subject: DEC RK11-C Disk Controller - on ebay...or is it? Message-ID: If you search ebay for "DEC RK11-C Disk Controller", you'll find a listing of a backplane of flipchip cards, but it's not like any RK11-C I have ever seen. Am I right, this is a mis-labeled auction? Bill From ggs at shiresoft.com Mon Feb 8 17:14:20 2021 From: ggs at shiresoft.com (Guy Sotomayor) Date: Mon, 8 Feb 2021 15:14:20 -0800 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: References: Message-ID: <87e47251-0582-bf4a-6efd-62908d27da34@shiresoft.com> It looks like it could be an RK11-C.? Are you possibly thinking of the RK11-D which fits in a BA11 chassis? TTFN - Guy On 2/8/21 2:53 PM, Bill Degnan via cctalk wrote: > If you search ebay for "DEC RK11-C Disk Controller", you'll find a listing > of a backplane of flipchip cards, but it's not like any RK11-C I have ever > seen. Am I right, this is a mis-labeled auction? > Bill -- TTFN - Guy From ethan.dicks at gmail.com Mon Feb 8 17:16:51 2021 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 8 Feb 2021 18:16:51 -0500 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: References: Message-ID: On Mon, Feb 8, 2021 at 5:53 PM Bill Degnan via cctalk wrote: > If you search ebay for "DEC RK11-C Disk Controller", you'll find a listing > of a backplane of flipchip cards, but it's not like any RK11-C I have ever > seen. Am I right, this is a mis-labeled auction? It seems to match fairly well with the module layout for the standard (non-double-buffered) RK11-C at http://gunkies.org/wiki/RK11-C_disk_controller (slot 1 on the right) I can't recall mine to a high amount of detail, but that looks about right. The ribbon cables are a bit out of place... perhaps they were just stuffed into empty slots to keep them from being damaged. -ethan From billdegnan at gmail.com Mon Feb 8 17:17:09 2021 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 8 Feb 2021 18:17:09 -0500 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: <87e47251-0582-bf4a-6efd-62908d27da34@shiresoft.com> References: <87e47251-0582-bf4a-6efd-62908d27da34@shiresoft.com> Message-ID: I suppose I am... On Mon, Feb 8, 2021, 6:14 PM Guy Sotomayor via cctalk wrote: > It looks like it could be an RK11-C. Are you possibly thinking of the > RK11-D which fits in a BA11 chassis? > > TTFN - Guy > > On 2/8/21 2:53 PM, Bill Degnan via cctalk wrote: > > If you search ebay for "DEC RK11-C Disk Controller", you'll find a > listing > > of a backplane of flipchip cards, but it's not like any RK11-C I have > ever > > seen. Am I right, this is a mis-labeled auction? > > Bill > > -- > TTFN - Guy > > From ce.murillosanchez at gmail.com Mon Feb 8 17:38:20 2021 From: ce.murillosanchez at gmail.com (Carlos E Murillo-Sanchez) Date: Mon, 8 Feb 2021 18:38:20 -0500 Subject: Request: Octave for VAX Message-ID: Hello, everyone... I may have asked here many years ago about this:? Does anybody? have a binary distribution of Octave for VAX/VMS?? The sources for some early versions were distributed in the SIG tapes, but I never managed to complete a VMS build using them.? I tried tracking old octave archives with binary builds, but they're all gone (it used to be at ftp.chem.wisc.edu).? I even tried to contact John Eaton about this but got no response. Regards, Carlos. From healyzh at avanthar.com Mon Feb 8 17:58:06 2021 From: healyzh at avanthar.com (Zane Healy) Date: Mon, 8 Feb 2021 15:58:06 -0800 Subject: Request: Octave for VAX In-Reply-To: References: Message-ID: <826E94DD-096A-4C12-AC4D-98AAE02DDA85@avanthar.com> This is a DECwindows application, isn?t it? I seem to recall that it?s a midi tracker? Or is it something else? I thought it would be here: http://decwarch.free.fr/audio.html However, it doesn?t appear to be. OTOH, I?m happy to see the DECwindows Freeware archive still online, I thought it was gone. Zane > On Feb 8, 2021, at 3:38 PM, Carlos E Murillo-Sanchez via cctalk wrote: > > Hello, everyone... > > I may have asked here many years ago about this: Does anybody have a binary distribution of Octave for VAX/VMS? The sources for some early versions were distributed in the SIG tapes, but I never managed to complete a VMS build using them. I tried tracking old octave archives with binary builds, but they're all gone (it used to be at ftp.chem.wisc.edu). I even tried to contact John Eaton about this but got no response. > > Regards, > > Carlos. > From cz at alembic.crystel.com Mon Feb 8 20:14:05 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Mon, 8 Feb 2021 21:14:05 -0500 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: References: Message-ID: <911ac7f6-cfc4-9176-019f-dd7cbc23e9a6@alembic.crystel.com> Interesting. It looks to have about half of the modules my old RK8 controller had, I wonder how they managed to shrink it down for a pdp11. Was the data-break interface for the 8 that complicated? C On 2/8/2021 6:16 PM, Ethan Dicks via cctalk wrote: > On Mon, Feb 8, 2021 at 5:53 PM Bill Degnan via cctalk > wrote: >> If you search ebay for "DEC RK11-C Disk Controller", you'll find a listing >> of a backplane of flipchip cards, but it's not like any RK11-C I have ever >> seen. Am I right, this is a mis-labeled auction? > > It seems to match fairly well with the module layout for the standard > (non-double-buffered) RK11-C at > http://gunkies.org/wiki/RK11-C_disk_controller > (slot 1 on the right) > > I can't recall mine to a high amount of detail, but that looks about right. > > The ribbon cables are a bit out of place... perhaps they were just > stuffed into empty slots to keep them from being damaged. > > -ethan > From fritzm at fritzm.org Mon Feb 8 21:21:48 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Mon, 8 Feb 2021 19:21:48 -0800 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: References: Message-ID: Yup, RK11-C, and it seems complete (modulo drive cables and terminators.) I have one debugged and running in my '11/45, so I know it well. > On Feb 8, 2021, at 3:16 PM, Ethan Dicks via cctalk wrote: > The ribbon cables are a bit out of place... perhaps they were just > stuffed into empty slots to keep them from being damaged. The cables are actually in the correct slots -- they connect A30 and B30 to the pass-through connectors to support plugging in a pair of KM11s from the outside of the rack for debug. On nice thing about this controller is that it supports "Read/Write All" mode, which lets you read or write the raw bitstream including block headers. This can be useful for disk recovery if you have a corrupted block header, or for reading/writing "foreign" disks (within limits). This is controlled by bit 9 in the CSR, which is unimplemented on the later controllers. --FritzM. From spectre at floodgap.com Mon Feb 8 22:42:21 2021 From: spectre at floodgap.com (Cameron Kaiser) Date: Mon, 8 Feb 2021 20:42:21 -0800 (PST) Subject: classic Mac GUSI compiler issue Message-ID: <202102090442.1194gLNr7995572@floodgap.com> I think we have some old Mac programmers here. I've dusted off some code that allegedly compiles with CodeWarrior Pro 2, and it needs CWGUSI, so I installed 1.8.0 (which was on the CW Pro2 Tools CD). A bit of hacking and everything compiles, but it won't link; it's missing a symbol _Stdout that CWGUSI apparently requires (I traced it back to a couple fflush(stdout); calls). I've got SIOUX, the Metrowerks Standard Library and everything else I can think of, and while everything else builds, I can't seem to find the lib with this mysterious _Stdout symbol. Any guesses? Does this sound familiar? -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Do I look like I just fell off the turnip truck?! -- Ryoga, "Ranma 1/2" ---- From ethan.dicks at gmail.com Mon Feb 8 23:37:36 2021 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Tue, 9 Feb 2021 00:37:36 -0500 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: References: Message-ID: On Mon, Feb 8, 2021 at 10:22 PM Fritz Mueller via cctalk wrote: > Yup, RK11-C, and it seems complete (modulo drive cables and terminators.) I have > one debugged and running in my '11/45, so I know it well. I've had one for years but I haven't tried working on it yet. > > On Feb 8, 2021, at 3:16 PM, Ethan Dicks via cctalk wrote: > > The ribbon cables are a bit out of place... perhaps they were just > > stuffed into empty slots to keep them from being damaged. > > The cables are actually in the correct slots -- they connect A30 and B30 to the > pass-through connectors to support plugging in a pair of KM11s from the > outside of the rack for debug. Ah... handy. I don't recall if mine has those or not. I do have a replica KM-11 set that I need to construct. It will definitely come in handy. > On nice thing about this controller is that it supports "Read/Write All" mode, which > lets you read or write the raw bitstream including block headers. This can be useful > for disk recovery if you have a corrupted block header, or for reading/writing "foreign" > disks (within limits). This is controlled by bit 9 in the CSR, which is unimplemented on > the later controllers. Interesting. Did not know that. I don't know that I've ever had a corrupt disk that I needed to read, but it's good to know that feature exists. -ethan From useddec at gmail.com Tue Feb 9 03:46:45 2021 From: useddec at gmail.com (Paul Anderson) Date: Tue, 9 Feb 2021 03:46:45 -0600 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: References: Message-ID: I have two backplanes and a diablo drive if anyone is interested. Paul On Mon, Feb 8, 2021 at 11:38 PM Ethan Dicks via cctalk < cctalk at classiccmp.org> wrote: > On Mon, Feb 8, 2021 at 10:22 PM Fritz Mueller via cctalk > wrote: > > Yup, RK11-C, and it seems complete (modulo drive cables and > terminators.) I have > > one debugged and running in my '11/45, so I know it well. > > I've had one for years but I haven't tried working on it yet. > > > > On Feb 8, 2021, at 3:16 PM, Ethan Dicks via cctalk < > cctalk at classiccmp.org> wrote: > > > The ribbon cables are a bit out of place... perhaps they were just > > > stuffed into empty slots to keep them from being damaged. > > > > The cables are actually in the correct slots -- they connect A30 and B30 > to the > > pass-through connectors to support plugging in a pair of KM11s from the > > outside of the rack for debug. > > Ah... handy. I don't recall if mine has those or not. I do have a > replica KM-11 set that I need to construct. It will definitely come > in handy. > > > On nice thing about this controller is that it supports "Read/Write All" > mode, which > > lets you read or write the raw bitstream including block headers. This > can be useful > > for disk recovery if you have a corrupted block header, or for > reading/writing "foreign" > > disks (within limits). This is controlled by bit 9 in the CSR, which is > unimplemented on > > the later controllers. > > Interesting. Did not know that. I don't know that I've ever had a > corrupt disk that I needed to read, but it's good to know that feature > exists. > > -ethan > From pbirkel at gmail.com Tue Feb 9 04:27:39 2021 From: pbirkel at gmail.com (Paul Birkel) Date: Tue, 9 Feb 2021 05:27:39 -0500 Subject: Sovier/Russian 132-pin PGA Ceramic IC Packaging Message-ID: <004401d6fece$318ab3e0$94a01ba0$@gmail.com> In item https://www.ebay.com/itm/265045229011 I am curious as to whether the gold islands on the top-side are functional test-points giving electrical access to the underside pins? Was there a clip designed to attach to the top-side of these chips for use in circuit analysis? Was this design unique to Russian manufacture (I don't recall ever seeing this design previously)? paul From jnc at mercury.lcs.mit.edu Tue Feb 9 08:36:42 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 9 Feb 2021 09:36:42 -0500 (EST) Subject: DEC RK11-C Disk Controller - on ebay...or is it? Message-ID: <20210209143642.B75C918C09A@mercury.lcs.mit.edu> > From: Ethan Dicks > I do have a replica KM-11 set that I need to construct. You'll need the RK11-C overlays (shown on pg 6-2 of the RK11-c Manual). (My set of overlays from Guy with his KM11 replica included them; thanks Guy :-). > From: Fritz Mueller > The cables are actually in the correct slots -- they connect A30 and > B30 to the pass-through connectors to support plugging in a pair of > KM11s from the outside of the rack for debug. Ah. The Double-Buffered RK11-C doesn't have those; the slots used (looks like C08 and D08) are used for logic. Noel From elson at pico-systems.com Tue Feb 9 09:50:08 2021 From: elson at pico-systems.com (Jon Elson) Date: Tue, 09 Feb 2021 09:50:08 -0600 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: References: Message-ID: <6022AF30.7090201@pico-systems.com> On 02/08/2021 11:37 PM, Ethan Dicks via cctalk wrote: > On Mon, Feb 8, 2021 at 10:22 PM Fritz Mueller via cctalk > wrote: > >> On nice thing about this controller is that it supports "Read/Write All" mode, which >> lets you read or write the raw bitstream including block headers. This can be useful >> for disk recovery if you have a corrupted block header, or for reading/writing "foreign" >> disks (within limits). This is controlled by bit 9 in the CSR, which is unimplemented on >> the later controllers. > Interesting. Did not know that. I don't know that I've ever had a > corrupt disk that I needed to read, but it's good to know that feature > exists. > > -ethan > The write all function is likely how you format a blank pack. Jon From jnc at mercury.lcs.mit.edu Tue Feb 9 11:27:04 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 9 Feb 2021 12:27:04 -0500 (EST) Subject: DEC RK11-C Disk Controller - on ebay...or is it? Message-ID: <20210209172704.DA50C18C0A5@mercury.lcs.mit.edu> > Fron: Jon Elson > The write all function is likely how you format a blank pack. No, 'Format' is a separate bit in the CSR from 'Read/Write-All', and they do different things. The RK11 always re-writes the header word of each sector when it writes a sector in normal operation; when 'Format' is set on a Write operation, it merely supresses the 'read header word and check/compare' function (which normally precedes any disk operation, to make sure the head's at the right place). Format/Write then goes ahead and writes the header word of the sector, just as in normal operation. (It is possible to set 'Format' on a Read operation; that just reads in the sector header words into memory.) Although in theory one could use 'Read/Write-All/Write' to format packs, the Unix V6 RK pack formatter: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/mdec/rkf.s sets _both_ 'Format' and 'Read/Write-All', and _doesn't_ set up the sector header words in the memory buffer, arguing that even with 'Read/Write-All' on, the hardware is still generating the sector header word contents. (I'm too lazy to check the RK11-C and RK11-D engineering drawings to confirm that.) Noel From Rice43 at btinternet.com Tue Feb 9 11:45:58 2021 From: Rice43 at btinternet.com (Joshua Rice) Date: Tue, 9 Feb 2021 17:45:58 +0000 Subject: Sovier/Russian 132-pin PGA Ceramic IC Packaging In-Reply-To: <004401d6fece$318ab3e0$94a01ba0$@gmail.com> References: <004401d6fece$318ab3e0$94a01ba0$@gmail.com> Message-ID: <80945282-CCB8-4DA4-AF46-7704983A4DA5@btinternet.com> Though i?m no expert, it looks like those are more an artefact of production, rather than usable test points. It seems like those pins extend throughout the ceramic substrate, and were most likely produced by pushing the pins through holes in the substrate and then soldering them. This may have been a solution used when the factory making them had limited tooling, or the chip was particularly low volume and more dedicated tooling was uneconomical. > On Feb 9, 2021, at 10:27 AM, Paul Birkel via cctalk wrote: > > In item https://www.ebay.com/itm/265045229011 I am curious as to whether the > gold islands on the top-side are functional test-points giving electrical > access to the underside pins? Was there a clip designed to attach to the > top-side of these chips for use in circuit analysis? Was this design unique > to Russian manufacture (I don't recall ever seeing this design previously)? > > > > paul > From fritzm at fritzm.org Tue Feb 9 13:04:26 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 9 Feb 2021 11:04:26 -0800 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: <20210209172704.DA50C18C0A5@mercury.lcs.mit.edu> References: <20210209172704.DA50C18C0A5@mercury.lcs.mit.edu> Message-ID: <7A79DB4B-7990-4E96-B2D1-E4AD6BBAF5D1@fritzm.org> > On Feb 9, 2021, at 9:27 AM, Noel Chiappa via cctalk wrote: > ... the Unix V6 RK pack formatter ... > sets _both_ 'Format' and 'Read/Write-All', and _doesn't_ set up the sector > header words in the memory buffer, arguing that even with 'Read/Write-All' on, > the hardware is still generating the sector header word contents. That's quite interesting! I have experimented with Read/Write-All, but just for reads. Basically, you set up the read and after the index pulse you get the bitstream from one surface of an entire cylinder in memory, repeating, inter-sector gaps, sync bits, header bits, etc, until the word counter expires. Bit alignment of the stream wrt. memory buffer is in effect arbitrary. To use the resulting data, you have to detect the sync bits, align the data, parse off the sector headers, etc. In at least one case of attempting to recover a pack, I had some sectors that would consistently return read errors and no data; by reading entire cylinders in "all" mode and fiddling with the data alignment I was in fact able to recover the greater portion of the data in some otherwise inaccessible sectors. --FritzM. From philip at axeside.co.uk Tue Feb 9 12:07:04 2021 From: philip at axeside.co.uk (Philip Belben) Date: Tue, 9 Feb 2021 18:07:04 +0000 Subject: OT: pints, pounds (Was: APL\360 In-Reply-To: References: <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> Message-ID: <9b820f76-940f-1ef5-c69b-0b340b639798@axeside.co.uk> > On 01/02/2021 20:07, Fred Cisin via cctalk wrote: > >> A US pint of water weighs 1.043 pounds. >> One "fluid ounce" (volume) of water weighs 1.043 ounces (weight)! The nit-picker in me would say "you mean mass", except that there's an even bigger nit to pick - the density of water is not constant but varies with temperature! > That's also a US measure.? An imperial fluid ounce is 28.4ml and > a floz of water weighs 28.4g, same as an avoirdupois ounce.? In fact > it's defined (or was) as the volume of water that weighs one ounce. The volume that weighs one ounce at what temperature? I think it may be 4?C - the temperature of maximum density. I often wondered why the US fluid ounce wasn't the same size as ours. I always assumed that it was measured at a different temperature, until someone said it was from a different definition of the ounce - not avoirdupois, but one of the other systems. The other day I looked up to see whether the density (assuming one ounce avdp) corresponded to a temperature that made sense, and it turns out it corresponds to water at 100?C. Not that my data tables gave a density for water at 100 degrees - but you can extend the line and there it is. I have no idea whether that is how the unit is derived. The definition is in terms of cubic inches, which doesn't help settle the question. Philip. From jnc at mercury.lcs.mit.edu Tue Feb 9 13:50:33 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 9 Feb 2021 14:50:33 -0500 (EST) Subject: DEC RK11-C Disk Controller - on ebay...or is it? Message-ID: <20210209195033.BA4E618C0A9@mercury.lcs.mit.edu> > the Unix V6 RK pack formatter ... sets _both_ 'Format' and > 'Read/Write-All Oooops; my bad; I mis-read the register description. It's setting 'Inhibit Bus Address Increment' and 'Format', not 'Format' and 'Read/Write-All'. So ignore my speculation about 'Read/Write-All' not getting the sector header word from memory. My bad! Noel From jnc at mercury.lcs.mit.edu Tue Feb 9 19:24:29 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 9 Feb 2021 20:24:29 -0500 (EST) Subject: DEC RK11-C Disk Controller - on ebay...or is it? Message-ID: <20210210012429.C29DF18C0AB@mercury.lcs.mit.edu> > From: Fritz Mueller > In at least one case of attempting to recover a pac BTW, your neat hack to do that only works on the RK11-C, and not the RK11-D: the latter doesn't implement 'Read/Write-All'. Noel From cz at alembic.crystel.com Tue Feb 9 20:01:54 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 9 Feb 2021 21:01:54 -0500 Subject: Part# request: TK70 eject switch Message-ID: Working on fixing a pair of TK70's here to speed up my backups. The TK50 is fine on a TQK70 controller (it streams perfectly) but I am coming close to filling a tape. I've managed to assemble a working TK70 out of two unhappy ones, but to fix the other I need to replace the eject button switch. The plastic/rubber on it has turned to the usual goo. Does anyone know the part number for that switch? Taller than a usual SMD button switch, so a stock one won't work. I could take it apart but that would be a kludge. Thanks! From fritzm at fritzm.org Tue Feb 9 20:02:45 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 9 Feb 2021 18:02:45 -0800 Subject: DEC RK11-C Disk Controller - on ebay...or is it? In-Reply-To: <20210210012429.C29DF18C0AB@mercury.lcs.mit.edu> References: <20210210012429.C29DF18C0AB@mercury.lcs.mit.edu> Message-ID: <8B153124-47AA-4E77-82E4-F74EBD233042@fritzm.org> > On Feb 9, 2021, at 5:24 PM, Noel Chiappa via cctalk wrote: > BTW, your neat hack to do that only works on the RK11-C, and not the RK11-D: > the latter doesn't implement 'Read/Write-All'. Yup -- this is one of the lesser-known advantages of the RK11-C over the later controllers. Another being the theoretical ability to hook up a blinkenlights panel to slots 31 and 32 rows A and B :-) Also missing from that eBay listing, BTW: the usually accompanying H720-E to power the thing. I wonder if that will be or has been listed separately? --FritzM. From brain at jbrain.com Tue Feb 9 22:02:20 2021 From: brain at jbrain.com (Jim Brain) Date: Tue, 9 Feb 2021 22:02:20 -0600 Subject: Digitalker 54104 IC Message-ID: <41b7d045-cd74-ac75-ef22-9973fa2a17f5@jbrain.com> I suspect the answer to question #1 is no, but thought I would ask. 1) Anyone happen to have a known working Digitalker 54104 IC they are looking to trade for some cash that does not involve me selling an arm or a leg :-)? 2) Barring that, anyone have a known working Digitalker-based unit that might be able to pop in a suspected non working Digitalker IC and test? I have a Jameco (yep, the parts firm) manufactured Digitalker unit here called the JE-520 that is my original unit.? It suffered some ROM bit rot long ago and was not working, but I acquired the ROMs a while back to repair the unit. Now, though, as I pull it out for another project, it seems to be misbehaving.? It's like "address bit 1" on the input commands is acting up.? For instance, word 48 is "zero", and 49 is "one", but zero will be followed by "three" and then "zero" and then "three" as one sends values 48,49,50,51 to the unit.? I'm working to confirm the bit 1 on the cable to the PC is not bad, but initial efforts point to it being the IC. Jim -- Jim Brain brain at jbrain.com www.jbrain.com From ccth6600 at gmail.com Wed Feb 10 02:35:01 2021 From: ccth6600 at gmail.com (Tom Hunter) Date: Wed, 10 Feb 2021 16:35:01 +0800 Subject: APL\360 In-Reply-To: References: <964617146.374839285.1610677712174.JavaMail.zimbra@shaw.ca> <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> <846c6567-83e4-1d22-c059-8356306e9d63@sydex.com> Message-ID: I too count sheep with my fingers, but I never get past zero due to the lack of sheep. :-) Tom Hunter On Mon, Feb 1, 2021 at 5:34 PM Tor Arntsen via cctalk wrote: > On Sat, 30 Jan 2021 at 03:27, dwight via cctalk > wrote: > > If we'd thought about it we could count to 1023 on our fingers. > > Dwight > > Some sheep herders in (IIRC) the Caucasus do, or did at least. I > learned about that some decades ago. Counting sheep on their fingers. > I use the system sometimes. > > -Tor > From enrico.lazzerini at email.it Wed Feb 10 06:34:36 2021 From: enrico.lazzerini at email.it (Enrico email.it) Date: Wed, 10 Feb 2021 13:34:36 +0100 Subject: 8 "disc geometry In-Reply-To: <80945282-CCB8-4DA4-AF46-7704983A4DA5@btinternet.com> References: <004401d6fece$318ab3e0$94a01ba0$@gmail.com> <80945282-CCB8-4DA4-AF46-7704983A4DA5@btinternet.com> Message-ID: Hi at all. I have few questions on how the geometry is calculated. 1) I would like to understand. this table represents an 3740 IBM standard disk D: Drive Characteristics 1944: 128 Byte Record Capacity 243: Kilobyte Drive Capacity 64: 32 Byte Directory Entries 64: Checked Directory Entries 128: Records / Extent 8: Records / Block 26: Sectors / Track 2: Reserved Tracks Its DPT is: 1A00 03 07 00 F200 3F00 C000 1000 0200 Or: SPT = 001A = The number of 128 byte records per track. BSH = 03 = The block shift count. BLM = 07 = The block mask. EXM = 00 = The extent mask. DSM = 00F2 = Disk storage maximum (the largest block number). DRM = 003F = Directory maximum (the largest directory entry). DAB = 00C0 = Directory Allocation Block AL1: = 00 & AL0: = C0 [0C0H] CKS = 0010 = Directory check size. OFF = 0002 = Track offset (number of reserved tracks). I already know there are 26x128x77 = 256256 bytes But how does this table represent them? 1944 sectors x 128 bytes = 248832 bytes = 243x1024 is the capacity actually available for the files The system takes 26 sects/track x128 bytes/sect x2 sects= 6656 bytes So 256256 - 248832 = 768 bytes They are for the directory but how does this number come out? 2) I have instead this table of a BASF 6104 Floppy Disk Drive managed through a Shugart SA-1403 SASI Controller: B: Drive Characteristics 9216: 128 Byte Record Capacity 1152: Kilobyte Drive Capacity 64: 32 Byte Directory Entries 64: Checked Directory Entries 2048: Records / Extent 128: Records / Block 512: Sectors / Track 1: Reserved Tracks Its DPT is: 0002 07 7F 0F 4700 3F00 8000 1000 0100 SPT = 0200 = The number of 128 byte records per track. BSH = 07 = The block shift count. BLM = 7F = The block mask. EXM = 0F = The extent mask. DSM = 0047 = Disk storage maximum (the largest block number). DRM = 003F = Directory maximum (the largest directory entry). DAB = 0080 = Directory Allocation Block AL1: = 00 & AL0: = C0 [0C0H] CKS = 0010 = Directory check size. OFF = 0001 = Track offset (number of reserved tracks). Oddly, the controller seems to manage the drive as 32 sect/tracks x256 bytes/setc x77 trakcs x2 heads In this case I don't know exactly the parameters of the diskette 9216 sectors x 128 bytes = 1.179.648 bytes = 1.152x1024 is the capacity actually available for the files The system takes 512 setcs/track x32 bytes/sect x1 tracks = 16.384 bytes In case 1 the gross capacity is 256256 while in case 2 which is it? 3) what could be the correct parameters to insert in 22disk in order to transfer files between a type 2 disk and msdos? Thanks a lot at all who will wish to answer to me. Enrico From john at yoyodyne-propulsion.net Wed Feb 10 11:07:18 2021 From: john at yoyodyne-propulsion.net (John Many Jars) Date: Wed, 10 Feb 2021 17:07:18 +0000 Subject: Apple ][+ ic In-Reply-To: References: Message-ID: So, I have an Apple ][+. It is missing an IC at location a3 on the motherboard. I don't know why. it used to work... I think my mind is going. I have no memory or removing it. Anyway, I need another one. The board is marked 74166. Can I put any shift register IC with a similar part no, like this one: 74166PC | FAIRCHILD | IC DIP-16 Shift Register (icompplus.com) in there, or ? Thanks, mark aka john -- Yoyodyne Propulsion Systems: "The Future Begins Tomorrow" Visit us at: http://www.yoyodyne-propulsion.net -------- "When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him." -- Jonathan Swift From pat at vax11.net Wed Feb 10 14:52:28 2021 From: pat at vax11.net (Patrick Finnegan) Date: Wed, 10 Feb 2021 15:52:28 -0500 Subject: 8 "disc geometry In-Reply-To: References: <004401d6fece$318ab3e0$94a01ba0$@gmail.com> <80945282-CCB8-4DA4-AF46-7704983A4DA5@btinternet.com> Message-ID: I've spent a fair bit of time staring at DPT's so we'll see if I can help.. On Wed, Feb 10, 2021 at 7:35 AM Enrico email.it via cctalk < cctalk at classiccmp.org> wrote: > Hi at all. I have few questions on how the geometry is calculated. > > > 1) I would like to understand. this table represents an 3740 IBM standard > disk > > D: Drive Characteristics > 1944: 128 Byte Record Capacity > 243: Kilobyte Drive Capacity > 64: 32 Byte Directory Entries > 64: Checked Directory Entries > 128: Records / Extent > 8: Records / Block > 26: Sectors / Track > 2: Reserved Tracks > > Its DPT is: > > 1A00 03 07 00 F200 3F00 C000 1000 0200 > > Or: > SPT = 001A = The number of 128 byte records per track. > BSH = 03 = The block shift count. > BLM = 07 = The block mask. > EXM = 00 = The extent mask. > DSM = 00F2 = Disk storage maximum (the largest block number). > DRM = 003F = Directory maximum (the largest directory entry). > DAB = 00C0 = Directory Allocation Block AL1: = 00 & AL0: = C0 [0C0H] > CKS = 0010 = Directory check size. > OFF = 0002 = Track offset (number of reserved tracks). > > I already know there are 26x128x77 = 256256 bytes > But how does this table represent them? > The disk is blocked into 1K blocks (8*128 bytes), and there are 243 blocks, starting after the reserved tracks (2). So there is 256256 total capacity -- 2*128*26 bytes on the reserved tracks, 243*8*128 bytes usable, and 768 bytes of stranded capacity, since you can't have a partial block. The directory starts on block 0 and occupies 2 blocks. For AL0 and AL1, the word is 0C000h, which has two 1 bits, marking the first two blocks as directory blocks. This matches up with DRM, which says there are 40h directory entries (32 bytes each), for a total of 2048 bytes. > 1944 sectors x 128 bytes = 248832 bytes = 243x1024 is the capacity actually > available for the files > The system takes 26 sects/track x128 bytes/sect x2 sects= 6656 bytes > > So 256256 - 248832 = 768 bytes > They are for the directory > but how does this number come out? > > No, that 768 bytes is just unusable space. > 2) I have instead this table of a BASF 6104 Floppy Disk Drive managed > through a Shugart SA-1403 SASI Controller: > > B: Drive Characteristics > 9216: 128 Byte Record Capacity > 1152: Kilobyte Drive Capacity > 64: 32 Byte Directory Entries > 64: Checked Directory Entries > 2048: Records / Extent > 128: Records / Block > 512: Sectors / Track > 1: Reserved Tracks > > Its DPT is: > > 0002 07 7F 0F 4700 3F00 8000 1000 0100 > > SPT = 0200 = The number of 128 byte records per track. > BSH = 07 = The block shift count. > BLM = 7F = The block mask. > EXM = 0F = The extent mask. > DSM = 0047 = Disk storage maximum (the largest block number). > DRM = 003F = Directory maximum (the largest directory entry). > DAB = 0080 = Directory Allocation Block AL1: = 00 & AL0: = C0 [0C0H] > CKS = 0010 = Directory check size. > OFF = 0001 = Track offset (number of reserved tracks). > > Oddly, the controller seems to manage the drive as 32 sect/tracks x256 > bytes/setc x77 trakcs x2 heads > > In this case I don't know exactly the parameters of the diskette > > 9216 sectors x 128 bytes = 1.179.648 bytes = 1.152x1024 is the capacity > actually available for the files > The system takes 512 setcs/track x32 bytes/sect x1 tracks = 16.384 bytes > > In case 1 the gross capacity is 256256 while in case 2 which is it? > You have a total of 512*128 bytes per track - 64K. I assume the SASI controller is remapping things around, and the disk doesn't physically have tracks this big. Each block is 128*128 bytes, or 16k And there's a total of one reserved track (64K) plus 72 blocks (1152K), for a total disk size of 1245184 bytes (1216K). The directory is all in the first block (16KB), with a maximum of 64 entries. I'd guess that the floppy was meant to hold backup or install sets or something, and not lots of small files, as this sorta layout lets you minimize disk overhead if you do that. > 3) what could be the correct parameters to insert in 22disk in order to > transfer files between a type 2 disk and msdos? > > You will probably have some issues directly using the floppy disk on a PC with those parameters, since I suspect the controller is remapping things and they don't line up on track boundaries. If you can dump a raw image with eg imagedisk, you can probably get that to work with 22disk. I don't know enough about 22disk to help you, but its author is on the list and may be able to help. Pat From enrico.lazzerini at email.it Wed Feb 10 15:40:03 2021 From: enrico.lazzerini at email.it (Enrico email.it) Date: Wed, 10 Feb 2021 22:40:03 +0100 Subject: R: 8 "disc geometry In-Reply-To: References: <004401d6fece$318ab3e0$94a01ba0$@gmail.com> <80945282-CCB8-4DA4-AF46-7704983A4DA5@btinternet.com> Message-ID: <135FDD19D5BD465B87C826A063709E6D@Enrico> So in the case of IBM 3740 Standard Disk Support the 768 bytes are an unusable remnant due to the choice of the 1024byte block size. Yes, the second case disk is a backup disk !!! The machine has a SASI card that interfaces to an old Shugard SA-1403 SASI Controller that manages a 10MB winchester SA-1004 hard disk with 32 sectors of 256byte / track (with 256 tracks and 4 heads for a total of 32 * 256 * 256 * 4 = 8MB) and a disk drive with 32 256byte / track sectors yet (with 77 tracks and 2 heads for a total of 32 * 256 * 77 * 2 = 1.2MB) Physically the directory starts at 10000H and ends at 13FFFH since the first data on the disk image is stored starting at location 14000H. I sincerely thank you for your kind and perfect response. In fact from the specifications of the DPT I could not understand. Experience in this case counts a lot. THANK YOU -----Messaggio originale----- Da: cctalk [mailto:cctalk-bounces at classiccmp.org] Per conto di Patrick Finnegan via cctalk Inviato: mercoled? 10 febbraio 2021 21:52 A: Enrico email.it; General Discussion: On-Topic and Off-Topic Posts Oggetto: Re: 8 "disc geometry I've spent a fair bit of time staring at DPT's so we'll see if I can help.. On Wed, Feb 10, 2021 at 7:35 AM Enrico email.it via cctalk < cctalk at classiccmp.org> wrote: > Hi at all. I have few questions on how the geometry is calculated. > > > 1) I would like to understand. this table represents an 3740 IBM standard > disk > > D: Drive Characteristics > 1944: 128 Byte Record Capacity > 243: Kilobyte Drive Capacity > 64: 32 Byte Directory Entries > 64: Checked Directory Entries > 128: Records / Extent > 8: Records / Block > 26: Sectors / Track > 2: Reserved Tracks > > Its DPT is: > > 1A00 03 07 00 F200 3F00 C000 1000 0200 > > Or: > SPT = 001A = The number of 128 byte records per track. > BSH = 03 = The block shift count. > BLM = 07 = The block mask. > EXM = 00 = The extent mask. > DSM = 00F2 = Disk storage maximum (the largest block number). > DRM = 003F = Directory maximum (the largest directory entry). > DAB = 00C0 = Directory Allocation Block AL1: = 00 & AL0: = C0 [0C0H] > CKS = 0010 = Directory check size. > OFF = 0002 = Track offset (number of reserved tracks). > > I already know there are 26x128x77 = 256256 bytes > But how does this table represent them? > The disk is blocked into 1K blocks (8*128 bytes), and there are 243 blocks, starting after the reserved tracks (2). So there is 256256 total capacity -- 2*128*26 bytes on the reserved tracks, 243*8*128 bytes usable, and 768 bytes of stranded capacity, since you can't have a partial block. The directory starts on block 0 and occupies 2 blocks. For AL0 and AL1, the word is 0C000h, which has two 1 bits, marking the first two blocks as directory blocks. This matches up with DRM, which says there are 40h directory entries (32 bytes each), for a total of 2048 bytes. > 1944 sectors x 128 bytes = 248832 bytes = 243x1024 is the capacity actually > available for the files > The system takes 26 sects/track x128 bytes/sect x2 sects= 6656 bytes > > So 256256 - 248832 = 768 bytes > They are for the directory > but how does this number come out? > > No, that 768 bytes is just unusable space. > 2) I have instead this table of a BASF 6104 Floppy Disk Drive managed > through a Shugart SA-1403 SASI Controller: > > B: Drive Characteristics > 9216: 128 Byte Record Capacity > 1152: Kilobyte Drive Capacity > 64: 32 Byte Directory Entries > 64: Checked Directory Entries > 2048: Records / Extent > 128: Records / Block > 512: Sectors / Track > 1: Reserved Tracks > > Its DPT is: > > 0002 07 7F 0F 4700 3F00 8000 1000 0100 > > SPT = 0200 = The number of 128 byte records per track. > BSH = 07 = The block shift count. > BLM = 7F = The block mask. > EXM = 0F = The extent mask. > DSM = 0047 = Disk storage maximum (the largest block number). > DRM = 003F = Directory maximum (the largest directory entry). > DAB = 0080 = Directory Allocation Block AL1: = 00 & AL0: = C0 [0C0H] > CKS = 0010 = Directory check size. > OFF = 0001 = Track offset (number of reserved tracks). > > Oddly, the controller seems to manage the drive as 32 sect/tracks x256 > bytes/setc x77 trakcs x2 heads > > In this case I don't know exactly the parameters of the diskette > > 9216 sectors x 128 bytes = 1.179.648 bytes = 1.152x1024 is the capacity > actually available for the files > The system takes 512 setcs/track x32 bytes/sect x1 tracks = 16.384 bytes > > In case 1 the gross capacity is 256256 while in case 2 which is it? > You have a total of 512*128 bytes per track - 64K. I assume the SASI controller is remapping things around, and the disk doesn't physically have tracks this big. Each block is 128*128 bytes, or 16k And there's a total of one reserved track (64K) plus 72 blocks (1152K), for a total disk size of 1245184 bytes (1216K). The directory is all in the first block (16KB), with a maximum of 64 entries. I'd guess that the floppy was meant to hold backup or install sets or something, and not lots of small files, as this sorta layout lets you minimize disk overhead if you do that. > 3) what could be the correct parameters to insert in 22disk in order to > transfer files between a type 2 disk and msdos? > > You will probably have some issues directly using the floppy disk on a PC with those parameters, since I suspect the controller is remapping things and they don't line up on track boundaries. If you can dump a raw image with eg imagedisk, you can probably get that to work with 22disk. I don't know enough about 22disk to help you, but its author is on the list and may be able to help. Pat From nw.johnson at ieee.org Wed Feb 10 17:07:59 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Wed, 10 Feb 2021 18:07:59 -0500 Subject: resistor packs for terminating SCSI bus inside Exabyte 8020 In-Reply-To: References: <9dc4f495-3c7f-57f6-4e05-964773c36793@ieee.org> <944e9895-6ac9-a2ca-7d39-43fd19a2964d@ieee.org> <9e9d5cad-6bd9-cc81-3fa5-2590de070ac0@ieee.org> Message-ID: All suppositions correct - (or was it suppositories ?) I got the SIP resistor packs today from Digikey.? I ordered 4608X-4-221/331L but what came was marked just 8x-4-221-331L Works fine, now Diloq SQ703 recognises the drive and built-in diags print a response. NetBSD recogised it as a TK50. Now I am waiting for a shipment of cassettes to try it out! Thanks to all who had useful suggestions. Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-06 8:51 p.m., Glen Slick via cctalk wrote: > On Sat, Feb 6, 2021 at 4:33 PM Nigel Johnson via cctalk > wrote: >> I have some 4608X-104-221/331L currently in my digikey shopping basket - >> I will place order on Monday after I confirm that the two outside pins >> go to Vcc and Fss and the six others go to signal pins on the bus. >> > I pulled the SIP packs out of my EXB-8200 because it is mounted in an > external case and the next time I go to use it I would probably attach > an external terminator to it without thinking that it was terminated > internally. > > I measured ~91-Ohm between pin 1 and pin 8, which is the expected > value for (6x) (220-Ohm + 330-Ohm) in parallel. > > I measured ~163-Ohm between pin 1 and each of pin 2, 3, 4, 5, 6, 7. > That is the expected value for 330-Ohm in parallel with (220-Ohm in > series with 110-Ohm ((5x) (220-Ohm + 330-Ohm) in parallel). > > I measured ~145-Ohm between pin 8 and each of 2, 3, 4, 5, 6, 7. That > is the expected value for 220-Ohm in parallel with (330-Ohm in series > with 110-Ohm ((5x) (220-Ohm + 330-Ohm) in parallel). > > So a 4608X-104-221/331L should be a functional equivalent (220-Ohm in > common to pin 8, 330-Ohm in common to pin 1). From david4602 at gmail.com Wed Feb 10 13:43:18 2021 From: david4602 at gmail.com (David Schmidt) Date: Wed, 10 Feb 2021 14:43:18 -0500 Subject: Apple ][+ ic In-Reply-To: References: Message-ID: <827a2c42-65c3-fd65-d8d6-0906550d5700@gmail.com> On 2/10/21 1:00 PM, John Many Jars wrote: > So, I have an Apple ][+. It is missing an IC at location a3 on the > motherboard. > > I don't know why. it used to work... I think my mind is going. I have no > memory or removing it. Anyway, I need another one. The board is marked > 74166. > > Can I put any shift register IC with a similar part no, like this one: > > 74166PC | FAIRCHILD | IC DIP-16 Shift Register (icompplus.com) > > > in there, or ? > > Thanks, > > mark aka john I have a mobo that has that very part (Fairchild 74166PC), so it's a good bet it'll work. - David From nw.johnson at ieee.org Wed Feb 10 14:25:13 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Wed, 10 Feb 2021 15:25:13 -0500 Subject: Apple ][+ ic In-Reply-To: <827a2c42-65c3-fd65-d8d6-0906550d5700@gmail.com> References: <827a2c42-65c3-fd65-d8d6-0906550d5700@gmail.com> Message-ID: The 'PC' just means plastic, commercial heat rating Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-10 2:43 p.m., David Schmidt via cctech wrote: > On 2/10/21 1:00 PM, John Many Jars wrote: >> So, I have an Apple ][+.? It is missing an IC at location a3 on the >> motherboard. >> >> I don't know why.? it used to work... I think my mind is going.? I >> have no >> memory or removing it.? Anyway, I need another one.? The board is marked >> 74166. >> >> Can I put any shift register IC with a similar part no, like this one: >> >> 74166PC | FAIRCHILD | IC DIP-16 Shift Register (icompplus.com) >> >> >> in there, or ? >> >> Thanks, >> >> mark aka john > > I have a mobo that has that very part (Fairchild 74166PC), so it's a > good bet it'll work. > > - David From p.gebhardt at ymail.com Thu Feb 11 01:46:53 2021 From: p.gebhardt at ymail.com (P Gebhardt) Date: Thu, 11 Feb 2021 07:46:53 +0000 (UTC) Subject: Mystery NCR disk pack References: <1163458113.425648.1613029613494.ref@mail.yahoo.com> Message-ID: <1163458113.425648.1613029613494@mail.yahoo.com> Hello list, there is an NCR-labelled disk pack offered in the bay with a geometry that I've never come across before: https://www.ebay.com/itm/353379280282 It seems to be a 14" pack with three platter and six recordable surfaces. The platters themselves are quite thick and the distance between the platters is quite wide compared to the IBM 1316 and 2316 type standards. Does anybody know if this is really an NCR development or if it is a rebadged pack from another manufacturer? Any hints to solve this mystery is much appreciated :) Best regards, Pierre PS: I wonder if the seller describing the party dog is describing himself, but partying seemed to be an important part of his life ;) ----------------------------------------------------------------------------- http://www.digitalheritage.de From mattislind at gmail.com Thu Feb 11 07:56:19 2021 From: mattislind at gmail.com (Mattis Lind) Date: Thu, 11 Feb 2021 14:56:19 +0100 Subject: RX02 DMK image to raw tool? In-Reply-To: <0928d97b-d92d-d007-2214-73a9e2891514@gmail.com> References: <0928d97b-d92d-d007-2214-73a9e2891514@gmail.com> Message-ID: Den m?n 8 feb. 2021 kl 20:39 skrev David Schmidt via cctech < cctech at classiccmp.org>: > On 2/8/21 1:00 PM, Mattis Lind wrote: > > I wrote my own, not knowing where another one lived. I happen to think > in Java, so that's what it's implemented in. > > Description is here: > > https://github.com/RetroFloppy/transformenator/wiki/Utility-Functions#dmk2raw > > Code is here: > > https://github.com/RetroFloppy/transformenator/blob/master/src/org/transformenator/util/Dmk2Raw.java Thanks! I will have a look. > > > The only thing of interest is the cw2dmk tool would read RX01 disks and > "double" the data - so my tool will make an attempt to detect that and > halve the data back out the other end. > After sending my message I did some hard drive archeology and found the dmklib I downloaded five years ago. There were some adaptations to handle RX02 format and it worked quite well. At least when the disk has been read error free. However the version of cw2dmk (4.5) I used had a feature that joined sectors from multiple reads. That should be quite useful to try to stitch together many reads worth of data into one full error free track. But for some odd reason cw2dmk v 4.5 joined sectors which were FM encoded, even though I explicitly stated I wanted only RX02 encoding, resulting in a track with both FM and RX02 (mixed FM and MFM) sectors. I cannot really understand how that could result in a good read and a matching CRC? Now I see that there is a version 4.6 of these tools that I probably should try instead. Perhaps the join feature works better in that version? So cw2dmk reads FM disks and doubles every byte? Resulting in 256 bytes sectors in FM mode, right? /Mattis > > - David > From geneb at deltasoft.com Thu Feb 11 09:22:10 2021 From: geneb at deltasoft.com (geneb) Date: Thu, 11 Feb 2021 07:22:10 -0800 (PST) Subject: New pinion gears for plotters... Message-ID: For those of you with the Atari & Commodore pen plotters that have broken pinion gears, there's now a guy making new ones in brass: https://www.soigeneris.com/alps-printer-plotter-mechanism-pinion-gears 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 mattislind at gmail.com Thu Feb 11 11:25:39 2021 From: mattislind at gmail.com (Mattis Lind) Date: Thu, 11 Feb 2021 18:25:39 +0100 Subject: Reading ESDI disks Message-ID: What is the best way of dumping the contents of an ESDI disk? I have an original IBM Enhanced ESDI ISA controller board. Could that be used under Linux? Or NetBSD/FreeNSD? I googled but didn't find much. Is there any other way of dumping the disk contents? In theory it should be just a matter of clocking the raw data and finding the marks and extracting the data. Has anyone done something similar? /Mattis From cclist at sydex.com Thu Feb 11 11:31:38 2021 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 11 Feb 2021 09:31:38 -0800 Subject: Wanted: Info on Optisys/Optidisk WORM file system Message-ID: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> I have a bunch of Panasonic/Matsushita 470/940 MB phase-change WORM discs here--and the appropriate drive (Panasonic LF-5010 SCSI-2) to read them. Unlike CD-R media, however, the format of these discs is not anything standard--they were essentially treated as hard disks. So, adding a file involves copying the directory and then adding the file information to the copy. The same applies, of course, for file deletion. If the drive tries to read a (1,024 byte) sector that hasn't been written to, it will get an error after a number of retries. I should emphasize that this drive is *not* fast--throughput seems to be on the order of a floppy disk. I can probably (with a bit of head-scratching) figure out the methodology behind this system, but I'm giving a shout-out to see if this rings any bells. Phase-change WORM did not enjoy a long life in the world, being superseded by rewritable media (both CD-RW and MO). As a point of reference, here's the data from sector 1 of a sample disc (Sector 0 is not used): > 00000400 04 0d 04 16 00 0f 0a fe 02 00 20 03 00 03 48 47 |.......... ...HG| > 00000410 49 42 32 2e 31 31 2d 30 33 2e 30 30 43 72 65 61 |IB2.11-03.00Crea| > 00000420 74 65 64 3a 20 54 68 72 20 32 32 20 41 70 72 20 |ted: Thr 22 Apr | > 00000430 31 39 39 33 20 20 20 20 20 31 35 3a 20 32 2e 32 |1993 15: 2.2| > 00000440 38 3a 35 31 20 20 20 20 4f 70 74 69 73 79 73 20 |8:51 Optisys | > 00000450 4f 70 74 69 44 69 73 6b 20 28 43 29 20 43 6f 70 |OptiDisk (C) Cop| > 00000460 79 72 69 67 68 74 20 31 39 38 37 20 2d 20 31 39 |yright 1987 - 19| > 00000470 39 31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |91 | > 00000480 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | If nothing turns up in the community, I'll work out the format and make details available (as I understand them). TIA --Chuck From nw.johnson at ieee.org Thu Feb 11 11:33:50 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Thu, 11 Feb 2021 12:33:50 -0500 Subject: Reading ESDI disks In-Reply-To: References: Message-ID: <04b000fc-ddde-ee25-47ba-ea16ae79f3b1@ieee.org> I'm about to try the very same thing. I have a MicroVAX II with a sigma MSCP ESDI controller.? It can be set for soft-secoring or various numbers of hard sectors.? That is what I see is the big issue with these drives. A friend gave me two drives that had been written on a PC under *nix. I do have some cable problems which I have to work on, but my first power-up revealed one of the drives and said it recognised the fact that it had 36 sectors. However when I tried to read it, it hung.? More experimentation needed, but I am sure if the controller will read the blocks I will be able to extract an image to send to my friend to decode :-) let's exchange notes as we proceed.? My effort is inter-twined with various other actoivities so I can't say when. cheers, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-11 12:25 p.m., Mattis Lind via cctalk wrote: > What is the best way of dumping the contents of an ESDI disk? > > I have an original IBM Enhanced ESDI ISA controller board. Could that be > used under Linux? Or NetBSD/FreeNSD? I googled but didn't find much. > > Is there any other way of dumping the disk contents? > > In theory it should be just a matter of clocking the raw data and finding > the marks and extracting the data. Has anyone done something similar? > > /Mattis From cclist at sydex.com Thu Feb 11 11:36:38 2021 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 11 Feb 2021 09:36:38 -0800 Subject: Reading ESDI disks In-Reply-To: References: Message-ID: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> On 2/11/21 9:25 AM, Mattis Lind via cctalk wrote: > What is the best way of dumping the contents of an ESDI disk? > > I have an original IBM Enhanced ESDI ISA controller board. Could that be > used under Linux? Or NetBSD/FreeNSD? I googled but didn't find much. > > Is there any other way of dumping the disk contents? > > In theory it should be just a matter of clocking the raw data and finding > the marks and extracting the data. Has anyone done something similar? I'm a little confused on this. An ESDI drive, in my experience, behaves exactly like an ATA one, right down to the command set. ESDI drives can be soft-or-hard sectored. What am I missing? --Chuck From aek at bitsavers.org Thu Feb 11 11:40:26 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 09:40:26 -0800 Subject: Reading ESDI disks In-Reply-To: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> Message-ID: On 2/11/21 9:36 AM, Chuck Guzis via cctalk wrote: > An ESDI drive, in my experience, behaves > exactly like an ATA one, right down to the command set. ESDI drives > can be soft-or-hard sectored. > > What am I missing? What do you do if the controller and drive don't match? ESDI and RLL versions of Dave's MFM reader are on my list of things to do. From nw.johnson at ieee.org Thu Feb 11 11:40:56 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Thu, 11 Feb 2021 12:40:56 -0500 Subject: Reading ESDI disks In-Reply-To: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> Message-ID: Doesn't ATA transfer the data in parallel?? ESDI uses the same two connectors as MFM (20/36 IIRC) , and transfers the data serially.? The difference between MFM and ESDI is that MFM transfers the raw analogue data over the cable but ESDI transfers digital serial data. Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-11 12:36 p.m., Chuck Guzis via cctalk wrote: > On 2/11/21 9:25 AM, Mattis Lind via cctalk wrote: >> What is the best way of dumping the contents of an ESDI disk? >> >> I have an original IBM Enhanced ESDI ISA controller board. Could that be >> used under Linux? Or NetBSD/FreeNSD? I googled but didn't find much. >> >> Is there any other way of dumping the disk contents? >> >> In theory it should be just a matter of clocking the raw data and finding >> the marks and extracting the data. Has anyone done something similar? > I'm a little confused on this. An ESDI drive, in my experience, behaves > exactly like an ATA one, right down to the command set. ESDI drives > can be soft-or-hard sectored. > > What am I missing? > > --Chuck From aek at bitsavers.org Thu Feb 11 11:41:30 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 09:41:30 -0800 Subject: Reading ESDI disks In-Reply-To: <04b000fc-ddde-ee25-47ba-ea16ae79f3b1@ieee.org> References: <04b000fc-ddde-ee25-47ba-ea16ae79f3b1@ieee.org> Message-ID: On 2/11/21 9:33 AM, Nigel Johnson via cctalk wrote: > I'm about to try the very same thing. > > I have a MicroVAX II with a sigma MSCP ESDI controller.? It can be set > for soft-secoring or various numbers of hard sectors.? That is what I > see is the big issue with these drives. > > A friend gave me two drives that had been written on a PC under *nix. There is little chance this will work for the same reason you can't use an arbitrary disk/controller combination for PC recovery. From nw.johnson at ieee.org Thu Feb 11 11:45:11 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Thu, 11 Feb 2021 12:45:11 -0500 Subject: Reading ESDI disks In-Reply-To: References: <04b000fc-ddde-ee25-47ba-ea16ae79f3b1@ieee.org> Message-ID: On 2021-02-11 12:41 p.m., Al Kossow via cctalk wrote: > On 2/11/21 9:33 AM, Nigel Johnson via cctalk wrote: >> I'm about to try the very same thing. >> >> I have a MicroVAX II with a sigma MSCP ESDI controller.? It can be set >> for soft-secoring or various numbers of hard sectors.? That is what I >> see is the big issue with these drives. >> >> A friend gave me two drives that had been written on a PC under *nix. > > There is little chance this will work for the same reason you can't use > an arbitrary disk/controller combination for PC recovery. > > Doesn't stop me trying, Al. Lots of things were achieved by people who didn't know they couldn't do it! My controller has settings for different sector sizes.? I owe it to my friend to try! Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org From blstuart at bellsouth.net Thu Feb 11 12:00:05 2021 From: blstuart at bellsouth.net (Brian L. Stuart) Date: Thu, 11 Feb 2021 18:00:05 +0000 (UTC) Subject: ENIAC 75th Anniversary Celebration References: <936244320.581061.1613066405539.ref@mail.yahoo.com> Message-ID: <936244320.581061.1613066405539@mail.yahoo.com> This evening begins a series of events celebrating the 75th anniversary of the unveiling of the ENIAC at the University of Pennsylvania.? On the 11th and 18th, the Philadelphia Venture Cafe will be hosting virtual round tables with a number of us who have some connection to the ENIAC and Philadelphia technology.? Included among the people present will be: - Bill Mauchly and Chris Eckert, sons of the ENIAC creators - Bill Mensch, part of the 6502 engineering team - Kathy Kleiman, producer of the ENIAC programmers documentary (And yes, I'll be there for anyone who wants to get nerdy and talk about the technical aspects of the machine and its programming.) Monday, the 15th is the day of the anniversary, and there will be a full day of webcasting.? Starting at 10:30 EST, UPenn will be holding a mini-symposium in recognition of the ENIAC.? Then at 3:30 EST, Unisys will be webcasting an ENIAC celebration video that includes a number of panel discussions, as well as clips from early newsreels, and happy birthday wishes from the various locations housing ENIAC artifacts. More details and links to all the events can be found here: http://www.eniacday.org/events/ BLS From cclist at sydex.com Thu Feb 11 12:03:30 2021 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 11 Feb 2021 10:03:30 -0800 Subject: Reading ESDI disks In-Reply-To: References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> Message-ID: On 2/11/21 9:40 AM, Nigel Johnson via cctalk wrote: > Doesn't ATA transfer the data in parallel?? ESDI uses the same two > connectors as MFM (20/36 IIRC) , and transfers the data serially.? The > difference between MFM and ESDI is that MFM transfers the raw analogue > data over the cable but ESDI transfers digital serial data. > I was speaking about the interface to the controller. Of course, if you don't have the right controller, all bets are off. --Chuck From derschjo at gmail.com Thu Feb 11 12:03:56 2021 From: derschjo at gmail.com (Josh Dersch) Date: Thu, 11 Feb 2021 10:03:56 -0800 Subject: Reading ESDI disks In-Reply-To: References: <04b000fc-ddde-ee25-47ba-ea16ae79f3b1@ieee.org> Message-ID: On Thu, Feb 11, 2021 at 9:45 AM Nigel Johnson via cctalk < cctalk at classiccmp.org> wrote: > > On 2021-02-11 12:41 p.m., Al Kossow via cctalk wrote: > > On 2/11/21 9:33 AM, Nigel Johnson via cctalk wrote: > >> I'm about to try the very same thing. > >> > >> I have a MicroVAX II with a sigma MSCP ESDI controller. It can be set > >> for soft-secoring or various numbers of hard sectors. That is what I > >> see is the big issue with these drives. > >> > >> A friend gave me two drives that had been written on a PC under *nix. > > > > There is little chance this will work for the same reason you can't use > > an arbitrary disk/controller combination for PC recovery. > > > > > Doesn't stop me trying, Al. Lots of things were achieved by people who > didn't know they couldn't do it! > > My controller has settings for different sector sizes. I owe it to my > friend to try! > Al's right in this case. In addition to the controller almost certainly using a different low-level format than whatever your friend's disk was written with, you're doubly screwed because you're using an MSCP controller -- the Sigma's going to expect RCT and FCT blocks somewhere on the unit for block remapping and since they're not there (and are in fact likely unreadable due to the difference in low-level format) it will fail. - Josh > > > Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU > Amateur Radio, the origin of the open-source concept! > Skype: TILBURY2591 nw.johnson at ieee.org > > > > > From nw.johnson at ieee.org Thu Feb 11 12:05:04 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Thu, 11 Feb 2021 13:05:04 -0500 Subject: Reading ESDI disks In-Reply-To: References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> Message-ID: <046dcdb2-52e9-4ceb-f0fc-472b56d1e23c@ieee.org> I'm talking about the DEC Q-BUS DSA world where there never was any ATA :-) Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-11 1:03 p.m., Chuck Guzis via cctalk wrote: > On 2/11/21 9:40 AM, Nigel Johnson via cctalk wrote: >> Doesn't ATA transfer the data in parallel?? ESDI uses the same two >> connectors as MFM (20/36 IIRC) , and transfers the data serially.? The >> difference between MFM and ESDI is that MFM transfers the raw analogue >> data over the cable but ESDI transfers digital serial data. >> > I was speaking about the interface to the controller. Of course, if you > don't have the right controller, all bets are off. > > --Chuck > From aek at bitsavers.org Thu Feb 11 12:05:21 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 10:05:21 -0800 Subject: Reading ESDI disks In-Reply-To: References: Message-ID: On 2/11/21 9:25 AM, Mattis Lind via cctalk wrote: > I have an original IBM Enhanced ESDI ISA controller board. Could that be > used under Linux? It's unlikely anyone ever implemented a driver for it. Is this the one used in the PC/RT with on-board DMA mastering? From mail at schnitz.com Thu Feb 11 12:09:28 2021 From: mail at schnitz.com (Tom Owad) Date: Thu, 11 Feb 2021 13:09:28 -0500 Subject: ENIAC 75th Anniversary Celebration In-Reply-To: <936244320.581061.1613066405539@mail.yahoo.com> References: <936244320.581061.1613066405539.ref@mail.yahoo.com> <936244320.581061.1613066405539@mail.yahoo.com> Message-ID: <8DF87767-4F81-4981-B5E1-7DA005761538@schnitz.com> > On Feb 11, 2021, at 1:00 PM, Brian L. Stuart via cctalk wrote: > > - Bill Mauchly and Chris Eckert, sons of the ENIAC > creators > - Bill Mensch, part of the 6502 engineering team > - Kathy Kleiman, producer of the ENIAC programmers > documentary Is there a connection between the ENIAC and the 6502? Tom From aek at bitsavers.org Thu Feb 11 12:09:39 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 10:09:39 -0800 Subject: Reading ESDI disks In-Reply-To: References: <04b000fc-ddde-ee25-47ba-ea16ae79f3b1@ieee.org> Message-ID: <12560724-a8ac-7cc8-9584-ffbdde56807d@bitsavers.org> On 2/11/21 10:03 AM, Josh Dersch via cctalk wrote: > Al's right in this case. In addition to the controller almost certainly > using a different low-level format than whatever your friend's disk was > written with Another issue with ESDI is the drive has the data separator on it and the data rates off of the drive were anywhere from 10 to 2x megabits/sec. The higher density drives just upped the data rates and packed the sectors tighter. From billdegnan at gmail.com Thu Feb 11 12:16:32 2021 From: billdegnan at gmail.com (Bill Degnan) Date: Thu, 11 Feb 2021 13:16:32 -0500 Subject: ENIAC 75th Anniversary Celebration In-Reply-To: <8DF87767-4F81-4981-B5E1-7DA005761538@schnitz.com> References: <936244320.581061.1613066405539.ref@mail.yahoo.com> <936244320.581061.1613066405539@mail.yahoo.com> <8DF87767-4F81-4981-B5E1-7DA005761538@schnitz.com> Message-ID: ...and the mysterious Compuseam running the event. On Thu, Feb 11, 2021 at 1:09 PM Tom Owad via cctalk wrote: > > On Feb 11, 2021, at 1:00 PM, Brian L. Stuart via cctalk < > cctalk at classiccmp.org> wrote: > > > > - Bill Mauchly and Chris Eckert, sons of the ENIAC > > creators > > - Bill Mensch, part of the 6502 engineering team > > - Kathy Kleiman, producer of the ENIAC programmers > > documentary > > Is there a connection between the ENIAC and the 6502? > > > Tom > > From elson at pico-systems.com Thu Feb 11 12:22:29 2021 From: elson at pico-systems.com (Jon Elson) Date: Thu, 11 Feb 2021 12:22:29 -0600 Subject: Reading ESDI disks In-Reply-To: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> Message-ID: <602575E5.40400@pico-systems.com> On 02/11/2021 11:36 AM, Chuck Guzis via cctalk wrote: > > I'm a little confused on this. An ESDI drive, in my experience, behaves > exactly like an ATA one, right down to the command set. ESDI drives > can be soft-or-hard sectored. > > No. ESDI is similar to MFM, there is a differential read data pair on the 20-pin connector, but the data rate is much higher, 10, 15 or 20 MBit/sec, and used a different encoding scheme that gave more data bits/flux transition. I think the 34-pin connector also allowed an additional head select bit, so you could have up to 16 heads. ATA has a single 40-pin connector with a 16-bit parallel data bus for all command and data transfers. Jon From aek at bitsavers.org Thu Feb 11 12:40:30 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 10:40:30 -0800 Subject: Reading ESDI disks In-Reply-To: <602575E5.40400@pico-systems.com> References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> <602575E5.40400@pico-systems.com> Message-ID: <2fd34dbf-e9b6-6638-f615-7cd924f6943e@bitsavers.org> On 2/11/21 10:22 AM, Jon Elson via cctalk wrote: > I think the 34-pin connector also allowed an > additional head select bit, > so you could have up to 16 heads. It also uses higher level serial command encoding http://bitsavers.org/pdf/cdc/discs/wren/77738076D2_CDC_ESDI_Specification_Nov84.pdf starting at page 27 later versions of the interface are in the various OEM drive manuals on bitsavers. From cclist at sydex.com Thu Feb 11 12:46:56 2021 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 11 Feb 2021 10:46:56 -0800 Subject: Reading ESDI disks In-Reply-To: <602575E5.40400@pico-systems.com> References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> <602575E5.40400@pico-systems.com> Message-ID: <87bea032-222f-1d93-4053-33331769990b@sydex.com> On 2/11/21 10:22 AM, Jon Elson wrote: > No.? ESDI is similar to MFM, there is a differential read data pair on > the 20-pin connector, but the data rate is much higher, 10, 15 or 20 > MBit/sec, and used a different encoding scheme that gave more data > bits/flux transition.? I think the 34-pin connector also allowed an > additional head select bit, > so you could have up to 16 heads. > > ATA has a single 40-pin connector with a 16-bit parallel data bus for > all command and data transfers. Brevis esse laboro, obscurus fio. Let me be more concise. On an x86 PC, *most* ESDI controllers present an interface exactly like ATA, right down to the IDENTIFY command. If you're talking about the naked drive, it isn't ATA, nor is it similar to MFM. ESDI drives are "smart" in the sense that they do have a command set (not ATA, however) and perform tasks such as data separation and seeking (one issues a SEEK command to the drive, not a STEP IN/OUT). ST506, in contrast, is a glorified floppy drive with differential data interface--it has no smarts. In addition, ESDI also pertains to certain early optical drives, which ST506 does not. I believe that there was also a possibility for a tape interface. --Chuck From paulkoning at comcast.net Thu Feb 11 12:57:19 2021 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 11 Feb 2021 13:57:19 -0500 Subject: Reading ESDI disks In-Reply-To: <87bea032-222f-1d93-4053-33331769990b@sydex.com> References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> <602575E5.40400@pico-systems.com> <87bea032-222f-1d93-4053-33331769990b@sydex.com> Message-ID: > On Feb 11, 2021, at 1:46 PM, Chuck Guzis via cctalk wrote: > > On 2/11/21 10:22 AM, Jon Elson wrote: > >> No. ESDI is similar to MFM, there is a differential read data pair on >> the 20-pin connector, but the data rate is much higher, 10, 15 or 20 >> MBit/sec, and used a different encoding scheme that gave more data >> bits/flux transition. I think the 34-pin connector also allowed an >> additional head select bit, >> so you could have up to 16 heads. >> >> ATA has a single 40-pin connector with a 16-bit parallel data bus for >> all command and data transfers. > > Brevis esse laboro, obscurus fio. > > Let me be more concise. On an x86 PC, *most* ESDI controllers present > an interface exactly like ATA, right down to the IDENTIFY command. > > If you're talking about the naked drive, it isn't ATA, nor is it similar > to MFM. ESDI drives are "smart" in the sense that they do have a > command set (not ATA, however) and perform tasks such as data separation > and seeking (one issues a SEEK command to the drive, not a STEP IN/OUT). > ST506, in contrast, is a glorified floppy drive with differential data > interface--it has no smarts. ... Then again, ST412 with its buffered seek is vaguely like having a real SEEK command, it's just less elegant because the cylinder number is encoded in base 1. paul From david4602 at gmail.com Thu Feb 11 12:00:58 2021 From: david4602 at gmail.com (David Schmidt) Date: Thu, 11 Feb 2021 13:00:58 -0500 Subject: RX02 DMK image to raw tool? In-Reply-To: References: <0928d97b-d92d-d007-2214-73a9e2891514@gmail.com> Message-ID: On 2/11/21 8:56 AM, Mattis Lind wrote: > After sending my message I did some hard drive archeology and found the > dmklib?I downloaded five years ago. There were some adaptations?to > handle RX02 format and it worked quite well. At least when the disk has > been read error free. > > However the version of cw2dmk (4.5)? I used had a feature that joined > sectors from multiple reads. That should be quite useful to try to > stitch together many reads worth of data into one full error free track. > But for some odd reason cw2dmk v 4.5? joined sectors which were FM > encoded, even though I explicitly stated I wanted only RX02 encoding, > resulting in a track with both FM and RX02 (mixed FM and MFM) sectors. I > cannot really understand how that could result in a good read and a > matching CRC? I wonder if this is an artifact of RX02 disks having sector headers in FM, but data in MFM? > Now I see that there is a version 4.6 of these tools that I probably > should try instead. Perhaps the join feature works better in that version? > > So cw2dmk reads FM disks and doubles every byte? Resulting in 256 bytes > sectors in FM mode, right? That's right, for disks detected as RX01 (which are of course fully FM, 128 bytes per sector). Sector data that is actually 0xDEADBEEF will show up in the .dmk as 0xDDEEAADDBBEEEEFF. - David From aek at bitsavers.org Thu Feb 11 12:03:20 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 10:03:20 -0800 Subject: RX02 DMK image to raw tool? In-Reply-To: References: <0928d97b-d92d-d007-2214-73a9e2891514@gmail.com> Message-ID: <5e8c22b0-1d76-0fa9-4a6a-45382565673a@bitsavers.org> On 2/11/21 10:00 AM, David Schmidt via cctech wrote: > That's right, for disks detected as RX01 (which are of course fully FM, 128 bytes per sector).? Sector data that is actually 0xDEADBEEF will > show up in the .dmk as 0xDDEEAADDBBEEEEFF. I've wondered why .dmk did that. From spectre at floodgap.com Thu Feb 11 12:06:43 2021 From: spectre at floodgap.com (Cameron Kaiser) Date: Thu, 11 Feb 2021 10:06:43 -0800 (PST) Subject: RX02 DMK image to raw tool? In-Reply-To: <5e8c22b0-1d76-0fa9-4a6a-45382565673a@bitsavers.org> from Al Kossow via cctech at "Feb 11, 21 10:03:20 am" Message-ID: <202102111806.11BI6hAT14876730@floodgap.com> > > That's right, for disks detected as RX01 (which are of course fully FM, 128 bytes per sector).__ Sector data that is actually 0xDEADBEEF will > > show up in the .dmk as 0xDDEEAADDBBEEEEFF. > > I've wondered why .dmk did that. Redunredundancydancy? -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Think right and you can fly. -- George Clinton, Funkadelic ----------------- From cisin at xenosoft.com Thu Feb 11 13:36:21 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 11 Feb 2021 11:36:21 -0800 (PST) Subject: Reading ESDI disks In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021, Mattis Lind via cctalk wrote: > What is the best way of dumping the contents of an ESDI disk? Same as for ST506/412 > I have an original IBM Enhanced ESDI ISA controller board. Could that be > used under Linux? Or NetBSD/FreeNSD? I googled but didn't find much. Do you have suitable drivers? Yes, ESDI has been used with Linux. In some cases, probably including the IBM ESDI controller, it looks similar to the computer as an ST506/412 setup. Start with another drive, and get your controller, drive, and OS working with each other as ordinary drive, BEFORE trying to read an alien disk using them. It is generally important to isolate variables, so that you can determine whether problems are your setup or are problems with the alien drive. > Is there any other way of dumping the disk contents? IS IT THE SAME controller that the drive was written with?? If so, no problem. If not, PROBLEMS. From mattislind at gmail.com Thu Feb 11 14:19:02 2021 From: mattislind at gmail.com (Mattis Lind) Date: Thu, 11 Feb 2021 21:19:02 +0100 Subject: Reading ESDI disks In-Reply-To: References: Message-ID: Den tors 11 feb. 2021 kl 19:05 skrev Al Kossow via cctalk < cctalk at classiccmp.org>: > On 2/11/21 9:25 AM, Mattis Lind via cctalk wrote: > > > I have an original IBM Enhanced ESDI ISA controller board. Could that be > > used under Linux? > > It's unlikely anyone ever implemented a driver for it. > Is this the one used in the PC/RT with on-board DMA mastering? > It came from an RT that had a severe case of battery explosion in it. Lots of casualties. The ESDI controller might have survived. It looks like this: https://vintagecomputer.ca/wp-content/uploads/2017/04/IBM-6150-RT-Slot-1-Enhanced-ESDI-front.jpg From mattislind at gmail.com Thu Feb 11 14:31:48 2021 From: mattislind at gmail.com (Mattis Lind) Date: Thu, 11 Feb 2021 21:31:48 +0100 Subject: Reading ESDI disks In-Reply-To: References: Message-ID: Den tors 11 feb. 2021 kl 20:36 skrev Fred Cisin via cctalk < cctalk at classiccmp.org>: > On Thu, 11 Feb 2021, Mattis Lind via cctalk wrote: > > What is the best way of dumping the contents of an ESDI disk? > > Same as for ST506/412 > I usually use David Gessweins MFM emulator for dumping unknown MFM disks. It works perfectly! > > > I have an original IBM Enhanced ESDI ISA controller board. Could that be > > used under Linux? Or NetBSD/FreeNSD? I googled but didn't find much. > > Do you have suitable drivers? > Yes, ESDI has been used with Linux. > In some cases, probably including the IBM ESDI controller, it looks > similar to the computer as an ST506/412 setup. > > Start with another drive, and get your controller, drive, and OS working > with each other as ordinary drive, BEFORE trying to read an alien disk > using them. It is generally important to isolate variables, so that you > can determine whether problems are your setup or are problems with the > alien drive. > > > Is there any other way of dumping the disk contents? > > IS IT THE SAME controller that the drive was written with?? > If so, no problem. > If not, PROBLEMS. > The drive was written by the very same controller, yes. The controller was in a IBM RT PC that had a battery explosion. The ESDI controller may have survived along with the disk. So the question is there drivers for this board in anything else then a RT PC? Chuck is saying that the ESDI command set on the controller level is identical to ST506 controllers. Anyone with experience of the "IBM Enhanced ESDI controller"? https://vintagecomputer.ca/wp-content/uploads/2017/04/IBM-6150-RT-Slot-1-Enhanced-ESDI-front.jpg I did a fair bit of googling but it didn't turn up much when it came to Linux support. Of course, if it is the same as the ST506 AT controller then it should work out of the box. But then I thought, perhaps this is a more generic problem. People having ESDI drives (well, SMD as well I guess) that there is no controller available for or could be made running due to drivers or whatever. So what if those drives could be read anyway. Interfacewise it shouldn't be that complex. One benefit of ESDI is that the clock extraction has already been done, so it is mostly a question on finding marks calculating CRC. /Mattis From alsilisk at icloud.com Thu Feb 11 14:35:25 2021 From: alsilisk at icloud.com (Al) Date: Thu, 11 Feb 2021 20:35:25 +0000 Subject: IBM AS/400 and HP scope for sale in the UK Message-ID: Dear all, I have been looking to downsize a bit in recent times and am looking to get rid of an IBM AS/400 9404 F10 and an HP 175a oscilloscope. As these things are large they are pickup only in the Petersfield area. I cannot guarantee either work. Although the scope comes with spares and does show some signs of life. It is not my area of expertise and it is probably going to need a full rework, it being from the 60s. The AS/400 is a similar story although will probably be a much simpler task. Send me an email if you are interested in either one of them or want pictures or have questions. I also realise it is lockdown, but if you send me a line now I can hold them for you rather than them being scrapped. Thanks, Al From cisin at xenosoft.com Thu Feb 11 14:36:07 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 11 Feb 2021 12:36:07 -0800 (PST) Subject: Reading ESDI disks In-Reply-To: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> Message-ID: On Thu, 11 Feb 2021, Chuck Guzis via cctalk wrote: > I'm a little confused on this. An ESDI drive, in my experience, behaves > exactly like an ATA one, right down to the command set. ESDI drives > can be soft-or-hard sectored. > What am I missing? I'm more than a LITTLE confused by parts of this discussion. To what extent are ESDI controllers interchangeable with already written drives? Remember that XT/5160 ST506/412 controllers were often NOT interchangeable, although AT/5170 ones usually were. Mattis says that he has the controller that that drive was written with. Some folks are talking about how the controller talks to the drive. If using OS or BIOS (mine had a ROM), unless changing THAT, such as trying to use a flux-transition device, controller to drive communication seems largely irrelevant. At least in the case of ISA, for the sake of compatibility, and transition, the controller and drive COMBINATION looks the same to the computer/OS as an ST506/412. Similarly, on PCs, IDE typically, for the sake of compatibility, and transition, the controller and drive COMBINATION looks the same to the computer/OS as an ST506/412. Similarly, on PCs, ATA typically, for the sake of compatibility, and transition, the controller and drive COMBINATION looks the same to the computer/OS as an ST506/412. All followed the ST506/412, and strived for transparent compatibility, but did not necessarily derive from each other. From aek at bitsavers.org Thu Feb 11 14:47:26 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 12:47:26 -0800 Subject: Reading ESDI disks In-Reply-To: References: Message-ID: <7de3bdf5-9f1d-9b41-c1ab-189376fc4048@bitsavers.org> On 2/11/21 12:31 PM, Mattis Lind via cctalk wrote: > But then I thought, perhaps this is a more generic problem. People having > ESDI drives (well, SMD as well I guess) that there is no controller > available for or could be made running due to drivers or whatever. So what > if those drives could be read anyway. > > Interfacewise it shouldn't be that complex. One benefit of ESDI is that the > clock extraction has already been done, so it is mostly a question on > finding marks calculating CRC. > > /Mattis > I have a bunch of RT drives that I need to archive, and I have the same problem. It should be possible to disable write gate and use a generic PC ESDI controller to position the heads, then extract the data with a logic analyzer or something else capable of running at that data rate. If you look at the spec, there is a byte strobe along with the clock and data. From aek at bitsavers.org Thu Feb 11 14:51:01 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 12:51:01 -0800 Subject: Reading ESDI disks In-Reply-To: References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> Message-ID: <5b74236c-8ac9-024e-5853-124222a7a86c@bitsavers.org> On 2/11/21 12:36 PM, Fred Cisin via cctalk wrote: > To what extent are ESDI controllers interchangeable with already written drives? That is completely unknown, since no one ever published any data about it. It is likely that anything using the same chipsets will be similar, but beyond that no information is known. The IBM controller in the RT did use a commercial chipset and they just added a bus mastering DMA controller. From aek at bitsavers.org Thu Feb 11 14:59:19 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 12:59:19 -0800 Subject: Reading ESDI disks In-Reply-To: <5b74236c-8ac9-024e-5853-124222a7a86c@bitsavers.org> References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> <5b74236c-8ac9-024e-5853-124222a7a86c@bitsavers.org> Message-ID: On 2/11/21 12:51 PM, Al Kossow via cctalk wrote: > On 2/11/21 12:36 PM, Fred Cisin via cctalk wrote: > >> To what extent are ESDI controllers interchangeable with already written drives? > > That is completely unknown, since no one ever published any data about it. > > It is likely that anything using the same chipsets will be similar, but beyond that > no information is known. > > The IBM controller in the RT did use a commercial chipset and they just added a bus > mastering DMA controller. > Another possibility is looking at the driver in the AIS sources. That's been on my list to do, next to disassembling the controller code. I don't know if it's possible to pull data out of the sector buffer without DMA That would simplify hacking something together to try to use the board in a PC From aek at bitsavers.org Thu Feb 11 15:00:22 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 11 Feb 2021 13:00:22 -0800 Subject: Reading ESDI disks In-Reply-To: References: <5fc59941-0e45-1efd-f245-8fc91f214c9f@sydex.com> <5b74236c-8ac9-024e-5853-124222a7a86c@bitsavers.org> Message-ID: <7a31d8fd-56a7-0fef-24f7-4273597d88a3@bitsavers.org> On 2/11/21 12:59 PM, Al Kossow via cctalk wrote: > On 2/11/21 12:51 PM, Al Kossow via cctalk wrote: >> On 2/11/21 12:36 PM, Fred Cisin via cctalk wrote: >> >>> To what extent are ESDI controllers interchangeable with already written drives? >> >> That is completely unknown, since no one ever published any data about it. >> >> It is likely that anything using the same chipsets will be similar, but beyond that >> no information is known. >> >> The IBM controller in the RT did use a commercial chipset and they just added a bus >> mastering DMA controller. >> > > Another possibility is looking at the driver in the AIS sources. That's been > on my list to do, next to disassembling the controller code. > > I don't know if it's possible to pull data out of the sector buffer without DMA > > That would simplify hacking something together to try to use the board in a PC > > and there is a data sheet for the AIC-010 controller on bitsavers From phb.hfx at gmail.com Thu Feb 11 15:43:48 2021 From: phb.hfx at gmail.com (Paul Berger) Date: Thu, 11 Feb 2021 17:43:48 -0400 Subject: Reading ESDI disks In-Reply-To: References: Message-ID: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> On 2021-02-11 4:31 p.m., Mattis Lind via cctalk wrote: > Den tors 11 feb. 2021 kl 20:36 skrev Fred Cisin via cctalk < > cctalk at classiccmp.org>: > >> On Thu, 11 Feb 2021, Mattis Lind via cctalk wrote: >>> What is the best way of dumping the contents of an ESDI disk? >> Same as for ST506/412 >> > I usually use David Gessweins MFM emulator for dumping unknown MFM disks. > It works perfectly! > >>> I have an original IBM Enhanced ESDI ISA controller board. Could that be >>> used under Linux? Or NetBSD/FreeNSD? I googled but didn't find much. >> Do you have suitable drivers? >> Yes, ESDI has been used with Linux. >> In some cases, probably including the IBM ESDI controller, it looks >> similar to the computer as an ST506/412 setup. >> >> Start with another drive, and get your controller, drive, and OS working >> with each other as ordinary drive, BEFORE trying to read an alien disk >> using them. It is generally important to isolate variables, so that you >> can determine whether problems are your setup or are problems with the >> alien drive. >> >>> Is there any other way of dumping the disk contents? >> IS IT THE SAME controller that the drive was written with?? >> If so, no problem. >> If not, PROBLEMS. >> > The drive was written by the very same controller, yes. The controller was > in a IBM RT PC that had a battery explosion. The ESDI controller may have > survived along with the disk. So the question is there drivers for this > board in anything else then a RT PC? > > Chuck is saying that the ESDI command set on the controller level is > identical to ST506 controllers. Anyone with experience of the "IBM > Enhanced ESDI controller"? > > https://vintagecomputer.ca/wp-content/uploads/2017/04/IBM-6150-RT-Slot-1-Enhanced-ESDI-front.jpg > > I did a fair bit of googling but it didn't turn up much when it came to > Linux support. Of course, if it is the same as the ST506 AT controller > then it should work out of the box. > > > But then I thought, perhaps this is a more generic problem. People having > ESDI drives (well, SMD as well I guess) that there is no controller > available for or could be made running due to drivers or whatever. So what > if those drives could be read anyway. > > Interfacewise it shouldn't be that complex. One benefit of ESDI is that the > clock extraction has already been done, so it is mostly a question on > finding marks calculating CRC. > > /Mattis I do seem recall using ESDI drives in a PC with 16 bit ISA slots but it is a long time ago but I am not sure if the controller used was the RT controller you have pictured, it seems to me the one used was a Western Digital controller.? I do know for sure PS/2 had a microchannel ESDI controller.? I suspect teh ESDI controller is at least similar to the AT ST-506 controller as some RTs had the AT ST-506 controller in them, in a former job I upgraded several 6150s that had the original NMOS processor to the newer CMOS enhanced processor and also changed disks from ST-506 to to the huge 70MB ESDI drives. Paul. From cisin at xenosoft.com Thu Feb 11 16:35:27 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 11 Feb 2021 14:35:27 -0800 (PST) Subject: Reading ESDI disks In-Reply-To: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> References: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> Message-ID: On Thu, 11 Feb 2021, Paul Berger via cctalk wrote: > I do seem recall using ESDI drives in a PC with 16 bit ISA slots but it is a > long time ago but I am not sure if the controller used was the RT controller > you have pictured, it seems to me the one used was a Western Digital > controller.? The most likely ISA ESDI would be the WD1007 controller. There were a few variant submodels of that, such as with/without floppy support, w/wo BIOS ROM. http://www.minuszerodegrees.net/manuals/Western%20Digital/WD1007A-WAH%20and%20WA2%20-%20Users%20Guide.pdf Mine had the ROM. On one machine, I had a 200M 3.5" drive. My first drive of that size of both capacity and physical size. I think that I know where it is. From ethan.dicks at gmail.com Thu Feb 11 17:25:47 2021 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Thu, 11 Feb 2021 18:25:47 -0500 Subject: Apple 1 and memorabilia up for auction in Boston (NOT on Epay) In-Reply-To: References: <5FCAC9EC.8050204@pico-systems.com> <004101d6cbfc$53da7070$fb8f5150$@com> <007901d6cca6$e2bb4710$a831d530$@classiccmp.org> <000701d6ccf6$887cf500$9976df00$@classiccmp.org> <000601d6ccfc$5d309c20$1791d460$@classiccmp.org> <5FCEF037.8040101@pico-systems.com> <5FCFAF86.7010902@pico-systems.com> <00f8d0ca-6cca-ba4d-d6d2-2e87fd0e0e6d@jwsss.com> <001601d6cf6d$fa0b2e70$ee218b50$@net> <1bba04cca5c44f9ea560628a1b3a2d4e@EXBE014SV3.NA02.MSEXCHANGEOUTLOOK.COM> Message-ID: On Fri, Dec 11, 2020 at 10:05 PM Jim Manley via cctalk wrote: > It's been estimated by experts that a third to half of the "original > artwork", previously valued at a total in the tens of billions in museums > and collectors' places, are counterfeits. 35 years ago I was in Anaheim for DECUS and my work buddy and I met up with his family and we went to the Getty Museum. I had previously spent multiple seasons in Greece doing archeological fieldwork, and my degree is a BA in History with a Classics specialty. We walked into one large chamber and there was this Koros (youth/Apollo statue) from at least the 7th C BC. I looked at it and said aloud that it had to be a fake - it was too good compared to the many I'd seen in museums and at sites around Greece. Several years later it was revealed to be a very expensive, but well executed, forgery. -ethan From couryhouse at aol.com Thu Feb 11 18:02:48 2021 From: couryhouse at aol.com (ED SHARPE) Date: Fri, 12 Feb 2021 00:02:48 +0000 (UTC) Subject: Digitalker 54104 IC References: <9187259.879986.1613088168916.ref@mail.yahoo.com> Message-ID: <9187259.879986.1613088168916@mail.yahoo.com> Most challanging was to figure out to make it say naughty things... and once you did? how it almost caused havoc in AZ On Tuesday, February 9, 2021 Jim Brain via cctalk wrote: I suspect the answer to question #1 is no, but thought I would ask. 1) Anyone happen to have a known working Digitalker 54104 IC they are looking to trade for some cash that does not involve me selling an arm or a leg :-)? 2) Barring that, anyone have a known working Digitalker-based unit that might be able to pop in a suspected non working Digitalker IC and test? I have a Jameco (yep, the parts firm) manufactured Digitalker unit here called the JE-520 that is my original unit.? It suffered some ROM bit rot long ago and was not working, but I acquired the ROMs a while back to repair the unit. Now, though, as I pull it out for another project, it seems to be misbehaving.? It's like "address bit 1" on the input commands is acting up.? For instance, word 48 is "zero", and 49 is "one", but zero will be followed by "three" and then "zero" and then "three" as one sends values 48,49,50,51 to the unit.? I'm working to confirm the bit 1 on the cable to the PC is not bad, but initial efforts point to it being the IC. Jim -- Jim Brain brain at jbrain.com www.jbrain.com From cclist at sydex.com Thu Feb 11 18:38:25 2021 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 11 Feb 2021 16:38:25 -0800 Subject: Reading ESDI disks In-Reply-To: References: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> Message-ID: On 2/11/21 2:35 PM, Fred Cisin via cctalk wrote: > The most likely ISA ESDI would be the WD1007 controller. > There were a few variant submodels of that, such as with/without floppy > support, w/wo BIOS ROM. > > http://www.minuszerodegrees.net/manuals/Western%20Digital/WD1007A-WAH%20and%20WA2%20-%20Users%20Guide.pdf I mostly used DTC ISA controllers. One side benefit is that they offered 3 and 4-floppy support on their cards (jumperable). I think I still have a 760MB Maxtor around here somewhere that started life as a Miniscribe. (Interesting story there). --Chuck From billdegnan at gmail.com Thu Feb 11 18:49:21 2021 From: billdegnan at gmail.com (Bill Degnan) Date: Thu, 11 Feb 2021 19:49:21 -0500 Subject: Apple 1 and memorabilia up for auction in Boston (NOT on Epay) In-Reply-To: References: <5FCAC9EC.8050204@pico-systems.com> <004101d6cbfc$53da7070$fb8f5150$@com> <007901d6cca6$e2bb4710$a831d530$@classiccmp.org> <000701d6ccf6$887cf500$9976df00$@classiccmp.org> <000601d6ccfc$5d309c20$1791d460$@classiccmp.org> <5FCEF037.8040101@pico-systems.com> <5FCFAF86.7010902@pico-systems.com> <00f8d0ca-6cca-ba4d-d6d2-2e87fd0e0e6d@jwsss.com> <001601d6cf6d$fa0b2e70$ee218b50$@net> <1bba04cca5c44f9ea560628a1b3a2d4e@EXBE014SV3.NA02.MSEXCHANGEOUTLOOK.COM> Message-ID: A person would have to be pretty good to fool a lot of us here on this mailing list when presented with a fake Apple I. There are certain things that would give it away. Not saying it would be impossible but it would be eventually exposed. I can't imagine someone who knows art and appraisals would not know a fake Renoir when he/she saw it, but maybe it's harder to spot a fake painting or sculpture than a fake Apple I. Bill On Thu, Feb 11, 2021 at 7:05 PM Ethan Dicks via cctalk < cctalk at classiccmp.org> wrote: > On Fri, Dec 11, 2020 at 10:05 PM Jim Manley via cctalk > wrote: > > It's been estimated by experts that a third to half of the "original > > artwork", previously valued at a total in the tens of billions in museums > > and collectors' places, are counterfeits. > > 35 years ago I was in Anaheim for DECUS and my work buddy and I met up > with his family and we went to the Getty Museum. I had previously > spent multiple seasons in Greece doing archeological fieldwork, and my > degree is a BA in History with a Classics specialty. We walked into > one large chamber and there was this Koros (youth/Apollo statue) from > at least the 7th C BC. I looked at it and said aloud that it had to > be a fake - it was too good compared to the many I'd seen in museums > and at sites around Greece. > > Several years later it was revealed to be a very expensive, but well > executed, forgery. > > -ethan > From boris at summitclinic.com Thu Feb 11 19:01:21 2021 From: boris at summitclinic.com (Boris Gimbarzevsky) Date: Thu, 11 Feb 2021 17:01:21 -0800 Subject: APL\360 In-Reply-To: References: <964617146.374839285.1610677712174.JavaMail.zimbra@shaw.ca> <57ba2738-0a27-db74-8dc4-9e8544d098ba@sydex.com> <3729db87-4b74-66e8-7085-66162f3117a2@sydex.com> <8563550b-e16c-f988-b9ff-af795825c052@jetnet.ab.ca> <2101315486.100375.1611954736901@email.ionos.com> <59e3e963-80ea-1bd5-c426-337f89cf2651@shiresoft.com> <846c6567-83e4-1d22-c059-8356306e9d63@sydex.com> Message-ID: <20210212010128.E16304E770@mx2.ezwind.net> Counting in binary on ones fingers was something I first ran into at age 11 when found a book on Military Electronics in a surplus store. Everything simplified, but in computer section found binary system explained with using fingers to represent bits. That was something that I used immediately as used to count steps to various places but after 1000+ steps would often forget where I was so would increment my binary digital counter every 100 steps. At that age 1 mile was probably about 2500 steps so I my counter would have overflowed at about 40.9 miles. Also LSB was my left small finger which seems weird now but suspect that's what illustration in book showed of how to count in binary on your fingers. Found manual method easier to use than a pedometer. >I too count sheep with my fingers, but I never get past zero due to the >lack of sheep. :-) > >Tom Hunter > >On Mon, Feb 1, 2021 at 5:34 PM Tor Arntsen via cctalk >wrote: > > > On Sat, 30 Jan 2021 at 03:27, dwight via cctalk > > wrote: > > > If we'd thought about it we could count to 1023 on our fingers. > > > Dwight > > > > Some sheep herders in (IIRC) the Caucasus do, or did at least. I > > learned about that some decades ago. Counting sheep on their fingers. > > I use the system sometimes. > > > > -Tor > > From phb.hfx at gmail.com Thu Feb 11 19:40:25 2021 From: phb.hfx at gmail.com (Paul Berger) Date: Thu, 11 Feb 2021 21:40:25 -0400 Subject: Reading ESDI disks In-Reply-To: References: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> Message-ID: On 2021-02-11 6:35 p.m., Fred Cisin via cctalk wrote: > On Thu, 11 Feb 2021, Paul Berger via cctalk wrote: >> I do seem recall using ESDI drives in a PC with 16 bit ISA slots but >> it is a long time ago but I am not sure if the controller used was >> the RT controller you have pictured, it seems to me the one used was >> a Western Digital controller. > > The most likely ISA ESDI would be the WD1007 controller. > There were a few variant submodels of that, such as with/without > floppy support, w/wo BIOS ROM. > > http://www.minuszerodegrees.net/manuals/Western%20Digital/WD1007A-WAH%20and%20WA2%20-%20Users%20Guide.pdf > > > Mine had the ROM.? On one machine, I had a 200M 3.5" drive.? My first > drive of that size of both capacity and physical size. > I think that I know where it is. No that is not it the one I used was a full length controller, but unlike the RT controller that was pictured it did not have an IBM square aluminum can chip on it, but it was probably at least 30 years ago so I don't recall any more.? By the time I left the Toronto Lab where I had almost all my exposure to RTs I was already using SCSI disks in my PC. Paul. From cisin at xenosoft.com Thu Feb 11 20:29:53 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 11 Feb 2021 18:29:53 -0800 (PST) Subject: Reading ESDI disks In-Reply-To: References: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> Message-ID: >> On Thu, 11 Feb 2021, Paul Berger via cctalk wrote: >>> I do seem recall using ESDI drives in a PC with 16 bit ISA slots but it is >>> a long time ago but I am not sure if the controller used was the RT >>> controller you have pictured, it seems to me the one used was a Western >>> Digital controller. > On 2021-02-11 6:35 p.m., Fred Cisin via cctalk wrote: >> The most likely ISA ESDI would be the WD1007 controller. >> There were a few variant submodels of that, such as with/without floppy >> support, w/wo BIOS ROM. >> >> http://www.minuszerodegrees.net/manuals/Western%20Digital/WD1007A-WAH%20and%20WA2%20-%20Users%20Guide.pdf >> >> Mine had the ROM.? On one machine, I had a 200M 3.5" drive.? My first >> drive of that size of both capacity and physical size. >> I think that I know where it is. On Thu, 11 Feb 2021, Paul Berger via cctalk wrote: > No that is not it the one I used was a full length controller, but unlike the > RT controller that was pictured it did not have an IBM square aluminum can > chip on it, but it was probably at least 30 years ago so I don't recall any > more.? By the time I left the Toronto Lab where I had almost all my exposure > to RTs I was already using SCSI disks in my PC. There certainly were many others. The WD1007 that I was using (also about 30 years ago, and certainly well over 20 years since I turned any of that group of machines on) was a full length ISA board. Some later WD1007 [sub]models were physically a lot smaller. I think that Western Digital assigned some variant of "WD1007" with various suffixes as the name for all of the ISA ESDI controllers that they made. A controller sold by IBM would be rebadged with IBM's own model number, and maybe even their own ROM, etc. For example, IBM's HD controller for XT/5160 was a rebadged Xebec; I think that IBM's HD controller for AT/5170 was a rebadged WD1002. -- Grumpy Ol' Fred cisin at xenosoft.com From ce.murillosanchez at gmail.com Thu Feb 11 20:55:15 2021 From: ce.murillosanchez at gmail.com (Carlos E Murillo-Sanchez) Date: Thu, 11 Feb 2021 21:55:15 -0500 Subject: One more thing to fix... HP9000/380 power supply Message-ID: <894df8cd-1393-d3ec-cca1-a569c14a717a@gmail.com> This decade seems to have increased the number of failing things in such a way that the "to be repaired" backlog is growing much faster than I can get to diminish it. Argh.? A month ago my trusty HP9000/380 ran just fine and I booted the different OS's in the SCSI and HPIB drives connected to it (this particular machine is interesting because the 9000/300 port of NetBSD was partly developed in it: it was Mike Wolfson's). Yesterday, it failed to turn on; the power supply is dead.? So I unracked the pile of drives and the computer, checked for obvious things (the fuse is fine, and nothing in the power supply is swelled up or leaking, or browned by heat; visually, it looks new; the HV caps seem to hold a charge).? I need the schematics for the power supply (at least the output connector; I can work my way back from that)? and also those for the backplane in this hp9000/380.? A preliminary search at bitsavers and elsewhere did not help.? Does anybody have these? In the meantime, I finally improved the mainboard (had the parts for a long while) from a 380 to a 385 by changing the clock generator, and replacing the 68040RC25 with an RC33. I ran this machine as a web server continuously for ten years in the 2000's, totally exposed.? Many tried to hack it... and failed. Another personal connection to this architecture is that I used Apollos and hp9000/300 at UW-Madison back in 1989-91.? Boy, did I crunch numbers... carlos. From davidkcollins2 at gmail.com Thu Feb 11 21:22:10 2021 From: davidkcollins2 at gmail.com (davidkcollins2 at gmail.com) Date: Fri, 12 Feb 2021 14:22:10 +1100 Subject: One more thing to fix... HP9000/380 power supply In-Reply-To: <894df8cd-1393-d3ec-cca1-a569c14a717a@gmail.com> References: <894df8cd-1393-d3ec-cca1-a569c14a717a@gmail.com> Message-ID: <00c201d700ee$41d3b950$c57b2bf0$@gmail.com> Carlos, from my experience in fixing a number of switch mode supplies in HP gear, if the supply is dead but you have full voltage across the big filter caps (~340v DC), it's typically a problem with the power supply to the regulator that drives the primary switching transistor. That 'power supply' can be as simple as a high value resistor (maybe 470K), usually 1 watt or so, that has just gone open circuit with no external signs of failure. Assuming you are aware of the risks inherent in opening these supplies up and applying power, you might want to check if you have the high voltage DC and if so, do some basic checks of components on the mains side of the main transformer. All the usual suggestions around checking for leaky/failed filtering caps on the low voltage DC outputs also apply of course. David Collins -----Original Message----- From: cctalk On Behalf Of Carlos E Murillo-Sanchez via cctalk Sent: Friday, 12 February 2021 1:55 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: One more thing to fix... HP9000/380 power supply This decade seems to have increased the number of failing things in such a way that the "to be repaired" backlog is growing much faster than I can get to diminish it. Argh. A month ago my trusty HP9000/380 ran just fine and I booted the different OS's in the SCSI and HPIB drives connected to it (this particular machine is interesting because the 9000/300 port of NetBSD was partly developed in it: it was Mike Wolfson's). Yesterday, it failed to turn on; the power supply is dead. So I unracked the pile of drives and the computer, checked for obvious things (the fuse is fine, and nothing in the power supply is swelled up or leaking, or browned by heat; visually, it looks new; the HV caps seem to hold a charge). I need the schematics for the power supply (at least the output connector; I can work my way back from that) and also those for the backplane in this hp9000/380. A preliminary search at bitsavers and elsewhere did not help. Does anybody have these? In the meantime, I finally improved the mainboard (had the parts for a long while) from a 380 to a 385 by changing the clock generator, and replacing the 68040RC25 with an RC33. I ran this machine as a web server continuously for ten years in the 2000's, totally exposed. Many tried to hack it... and failed. Another personal connection to this architecture is that I used Apollos and hp9000/300 at UW-Madison back in 1989-91. Boy, did I crunch numbers... carlos. From phb.hfx at gmail.com Thu Feb 11 22:12:44 2021 From: phb.hfx at gmail.com (Paul Berger) Date: Fri, 12 Feb 2021 00:12:44 -0400 Subject: One more thing to fix... HP9000/380 power supply In-Reply-To: <894df8cd-1393-d3ec-cca1-a569c14a717a@gmail.com> References: <894df8cd-1393-d3ec-cca1-a569c14a717a@gmail.com> Message-ID: On 2021-02-11 10:55 p.m., Carlos E Murillo-Sanchez via cctalk wrote: > > This decade seems to have increased the number of failing things in > such a way that the "to be repaired" backlog is growing much faster > than I can get to diminish it. Argh.? A month ago my trusty HP9000/380 > ran just fine and I booted the different OS's in the SCSI and HPIB > drives connected to it (this particular machine is interesting because > the 9000/300 port of NetBSD was partly developed in it: it was Mike > Wolfson's). Yesterday, it failed to turn on; the power supply is > dead.? So I unracked the pile of drives and the computer, checked for > obvious things (the fuse is fine, and nothing in the power supply is > swelled up or leaking, or browned by heat; visually, it looks new; the > HV caps seem to hold a charge).? I need the schematics for the power > supply (at least the output connector; I can work my way back from > that)? and also those for the backplane in this hp9000/380.? A > preliminary search at bitsavers and elsewhere did not help.? Does > anybody have these? > > In the meantime, I finally improved the mainboard (had the parts for a > long while) from a 380 to a 385 by changing the clock generator, and > replacing the 68040RC25 with an RC33. > > I ran this machine as a web server continuously for ten years in the > 2000's, totally exposed.? Many tried to hack it... and failed. Another > personal connection to this architecture is that I used Apollos and > hp9000/300 at UW-Madison back in 1989-91.? Boy, did I crunch numbers... > > carlos. > > I have never seen any schematics for this power supply however on bitsavers there is a document related to the expander that shows the power supply pinout. http://www.bitsavers.org/pdf/hp/9000_300/specs/A-98568-66501-4_98568A_Schematic_Notes_Jun85.pdf This would be the same power supply as the processor box. Also http://www.bitsavers.org/pdf/hp/9000_300/specs/A-98561-66501-4_98561AB_Schematic_Notes_Jun85.pdf Paul. From cc at informatik.uni-stuttgart.de Fri Feb 12 02:40:54 2021 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Fri, 12 Feb 2021 09:40:54 +0100 (CET) Subject: One more thing to fix... HP9000/380 power supply In-Reply-To: <894df8cd-1393-d3ec-cca1-a569c14a717a@gmail.com> References: <894df8cd-1393-d3ec-cca1-a569c14a717a@gmail.com> Message-ID: On Thu, 11 Feb 2021, carlos_murillo at ieee.org wrote: > to diminish it. Argh.? A month ago my trusty HP9000/380 ran just fine and I [...] > on; the power supply is dead.? So I unracked the pile of drives and the > computer, checked for obvious things (the fuse is fine, and nothing in the > power supply is swelled up or leaking, or browned by heat; visually, it looks > new; the HV caps seem to hold a charge).? I need the schematics for the power I recently repaired a 9000/310 power supply. The fault was very obvious if you are experienced with the components used. My machine was built in Germany (B?blingen) and has a German power supply that uses electrolytics from Frako (the golden caps). They tend to simply short from one moment to another. In this case one of them shorted the +12V rail and thus the power supply shut down. No other blown parts or fuses. Just find the shorted cap and replace it :-) Christian From jules.richardson99 at gmail.com Fri Feb 12 06:50:05 2021 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Fri, 12 Feb 2021 06:50:05 -0600 Subject: Mystery (unusual) 1973 terminal Message-ID: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> Hi all, Hopefully the following link works, but someone over on one of the Facebook vintage groups has this oddball terminal from 1973 that they've been looking for any information on: https://drive.google.com/drive/folders/1-2uEFbi3OKBYr06y6yHnygDiLMtw2Qkj ... it's somewhat unconventional in that half the CRT is hidden from view within the machine, i.e. it only actually displays the top half of the display to the user - I've no idea if that's because it had a specific application where space was limited, or if it was simply that memory at the time was horribly expensive and so it was designed to only use a few lines (I know some vendors did that, although I think they typically presented the whole CRT and at least had the option of RAM upgrade to more lines). The blower assembly seems a little on the homebrew side, but on the other hand the PCBs and case construction make it seem like a professional product. The owner says the only label anywhere on the thing is the one on the CRT saying "Mfd in Japan for Conrac", but that's presumably just the CRT itself and not the entire machine. I don't believe there's anything resembling a microprocessor in the system, it's all just TTL logic (the large white ceramic IC is an ACIA). Oh, I believe the owner's in Canada, so it may be it was made there and never exported to other parts of the world. cheers Jules From paulkoning at comcast.net Fri Feb 12 08:08:54 2021 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 12 Feb 2021 09:08:54 -0500 Subject: Mystery (unusual) 1973 terminal In-Reply-To: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> References: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> Message-ID: <49C76CA7-1440-4CB3-A539-A380CD483430@comcast.net> > On Feb 12, 2021, at 7:50 AM, Jules Richardson via cctalk wrote: > > > Hi all, > > Hopefully the following link works, but someone over on one of the Facebook vintage groups has this oddball terminal from 1973 that they've been looking for any information on: > > https://drive.google.com/drive/folders/1-2uEFbi3OKBYr06y6yHnygDiLMtw2Qkj > > ... it's somewhat unconventional in that half the CRT is hidden from view within the machine, i.e. it only actually displays the top half of the display to the user - I've no idea if that's because it had a specific application where space was limited, or if it was simply that memory at the time was horribly expensive and so it was designed to only use a few lines (I know some vendors did that, although I think they typically presented the whole CRT and at least had the option of RAM upgrade to more lines). > > The blower assembly seems a little on the homebrew side, but on the other hand the PCBs and case construction make it seem like a professional product. > > The owner says the only label anywhere on the thing is the one on the CRT saying "Mfd in Japan for Conrac", but that's presumably just the CRT itself and not the entire machine. I remember Conrac as a well known CRT maker from that time. I think they were used in PLATO III terminals (mid 1960s). > I don't believe there's anything resembling a microprocessor in the system, it's all just TTL logic (the large white ceramic IC is an ACIA). > > Oh, I believe the owner's in Canada, so it may be it was made there and never exported to other parts of the world. > > cheers > > Jules The photos are not particularly helpful; they show parts of the device but not close enough to tell the details, while much of the case is not shown. Is there any manufacturer label or serial number tag on the case? One of those boards is full of rather sloppy ECO wires, which makes it feel like a home made job, but the rest look like decent quality commercial pieces. And yes, the blower is rather curious, it's hard to see how a device like this might dissipate enough power to need that kind of air mover. paul From mattislind at gmail.com Fri Feb 12 09:04:32 2021 From: mattislind at gmail.com (Mattis Lind) Date: Fri, 12 Feb 2021 16:04:32 +0100 Subject: Reading ESDI disks In-Reply-To: References: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> Message-ID: I am pretty sure that my controller is the IBM Enhanced ESDI board and having support for it in Linux is probably unlikely. But perhaps it is the WD1007, I am not sure until I checked and it is 100 km away right now. Anyway I did some reading of the ESDI spec. There are things that I really like to have clarified. ESDI has a hard sector and soft sector mode, much like floppy disks. But in contrast to floppy disks which are hard set to a certain number of sectors per track the hard sectoring in ESDI (and SMD) is just a counter derived from the bit clock / byte clock, right? As far as I can understand you can set any number you like for this divider both in ESDI and SMD. So you can select a big variety of sector sizes using hard sectoring. This would then be in contrast to a hard sector floppy disk where only one format can be handled. The latter would then lead to a soft sector format for floppies where one could select the number of sectors arbitrarily. But what sense makes a soft sector ESDI drive. Isn't it just add overhead by having address marks? Wouldn't it just be simpler with hard sectoring? Less overhead? Then another issue in ESDI is that it seems to be quite elaborate protocol between the drive and the controller. Not just for sending commands which are done serially 16 bits plus parity but also the reading process. I am a bit confused about the READ GATE. It has to be deasserted in the PLO SYNC interval. Why is that? I am clearly missing something. A ST506 can be read raw and then decoded in software if you like. But it seems that just enabling READ GATE and reading the track of the drive (perhaps with SECTOR PULSE for hard sector configured drives) wouldn't work. You have to fiddle with the READ GATE at the correct bit point in time. It seems that this fiddling with the READ GATE controls how the VCO in the data separator behaves. In any case this exact timing of the READ GATE makes things a bit more complex on how to read a disk without the proper controller. One needs some logic with counters to handle this. Why didn't they put that logic in the drive? The PLO SYNC stuff is drive specific anyhow as I understand it. http://bitsavers.informatik.uni-stuttgart.de/pdf/maxtor/1011004B_XT-4000E_Product_Specification_and_OEM_Manual_Sep88.pdf http://www.bitsavers.org/pdf/micropolis/ESDI_spec_X3.170-90.pdf /Mattis From aek at bitsavers.org Fri Feb 12 10:04:35 2021 From: aek at bitsavers.org (Al Kossow) Date: Fri, 12 Feb 2021 08:04:35 -0800 Subject: Mystery (unusual) 1973 terminal In-Reply-To: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> References: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> Message-ID: On 2/12/21 4:50 AM, Jules Richardson via cctalk wrote: > https://drive.google.com/drive/folders/1-2uEFbi3OKBYr06y6yHnygDiLMtw2Qkj > Bumping up a level and looking at the other computers in the collection should give you a good idea who it is, in particular the Tek board bucket and the build of an exact replica tv typewriter From wh.sudbrink at verizon.net Fri Feb 12 10:05:08 2021 From: wh.sudbrink at verizon.net (William Sudbrink) Date: Fri, 12 Feb 2021 11:05:08 -0500 Subject: Mystery (unusual) 1973 terminal In-Reply-To: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> References: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> Message-ID: <00fc01d70158$d6d1ea30$8475be90$@verizon.net> Sort of reminds me of a DataPoint 2200. Clone maybe? -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Jules Richardson via cctalk Sent: Friday, February 12, 2021 7:50 AM To: xx Classiccmp mailing list Subject: Mystery (unusual) 1973 terminal Hi all, Hopefully the following link works, but someone over on one of the Facebook vintage groups has this oddball terminal from 1973 that they've been looking for any information on: https://drive.google.com/drive/folders/1-2uEFbi3OKBYr06y6yHnygDiLMtw2Qkj .. it's somewhat unconventional in that half the CRT is hidden from view within the machine, i.e. it only actually displays the top half of the display to the user - I've no idea if that's because it had a specific application where space was limited, or if it was simply that memory at the time was horribly expensive and so it was designed to only use a few lines (I know some vendors did that, although I think they typically presented the whole CRT and at least had the option of RAM upgrade to more lines). The blower assembly seems a little on the homebrew side, but on the other hand the PCBs and case construction make it seem like a professional product. The owner says the only label anywhere on the thing is the one on the CRT saying "Mfd in Japan for Conrac", but that's presumably just the CRT itself and not the entire machine. I don't believe there's anything resembling a microprocessor in the system, it's all just TTL logic (the large white ceramic IC is an ACIA). Oh, I believe the owner's in Canada, so it may be it was made there and never exported to other parts of the world. cheers Jules -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From aek at bitsavers.org Fri Feb 12 10:12:58 2021 From: aek at bitsavers.org (Al Kossow) Date: Fri, 12 Feb 2021 08:12:58 -0800 Subject: Reading ESDI disks In-Reply-To: References: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> Message-ID: <72bbce20-087b-304f-46da-218029b8a1af@bitsavers.org> On 2/12/21 7:04 AM, Mattis Lind via cctalk wrote: > I am pretty sure that my controller is the IBM Enhanced ESDI board and > having support for it in Linux is probably unlikely. But perhaps it is the > WD1007 It is not WD. It is IBM's own design using an Adaptec controller and a 8031 microcontroller. You can find a technical description starting on page 413 of http://bitsavers.org/pdf/ibm/pc/rt/75x0235_RT_PC_Technical_Reference_Volume_2_Jun87.pdf From elson at pico-systems.com Fri Feb 12 10:14:31 2021 From: elson at pico-systems.com (Jon Elson) Date: Fri, 12 Feb 2021 10:14:31 -0600 Subject: Reading ESDI disks In-Reply-To: References: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> Message-ID: <6026A967.6000800@pico-systems.com> On 02/12/2021 09:04 AM, Mattis Lind via cctalk wrote: > I am a bit confused about the READ GATE. It has to be deasserted > in the PLO SYNC interval. Why is that? I am clearly missing something. > > ESDI has a clock separator built into the drive, with logic to decode the data format and convert to a standard protocol. Many of the higher-end drives used some form of RLL encoding internally. I'm just guessing here, but I suspect that the sector headers were written during a drive format, and then never written again, as some recently discussed DEC drives did. So, there'd be a synch discontinuity between every sector header and the data block. I'm guessing a drop and then re-assertion of read gate would prepare the PLO to resynch quickly at the beginning of the data packet. The controller would know when to do this, as it would read every sector header looking for the desired sector, and as soon as the header data ended, it could wiggle read gate. Jon From aek at bitsavers.org Fri Feb 12 10:15:08 2021 From: aek at bitsavers.org (Al Kossow) Date: Fri, 12 Feb 2021 08:15:08 -0800 Subject: Reading ESDI disks In-Reply-To: <72bbce20-087b-304f-46da-218029b8a1af@bitsavers.org> References: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> <72bbce20-087b-304f-46da-218029b8a1af@bitsavers.org> Message-ID: <6734586b-16de-5396-c002-457eaf1575cc@bitsavers.org> On 2/12/21 8:12 AM, Al Kossow via cctalk wrote: > On 2/12/21 7:04 AM, Mattis Lind via cctalk wrote: >> I am pretty sure that my controller is the IBM Enhanced ESDI board and >> having support for it in Linux is probably unlikely. But perhaps it is the >> WD1007 > > It is not WD. It is IBM's own design using an Adaptec controller > and a 8031 microcontroller. > > You can find a technical description starting on page 413 of > http://bitsavers.org/pdf/ibm/pc/rt/75x0235_RT_PC_Technical_Reference_Volume_2_Jun87.pdf > oops, page 445 and it describes how to program the dma From aek at bitsavers.org Fri Feb 12 10:19:53 2021 From: aek at bitsavers.org (Al Kossow) Date: Fri, 12 Feb 2021 08:19:53 -0800 Subject: Mystery DEC cartridge tape drive Message-ID: This is a mystery. What DEC system used a CDC Sentinel DC300 cartridge tape drive? https://www.ebay.com/itm/Vintage-Computer-DEC-BY5A5-E-Tape-Drive-77-014320/313416738022 From nw.johnson at ieee.org Fri Feb 12 10:24:57 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Fri, 12 Feb 2021 11:24:57 -0500 Subject: Mystery DEC cartridge tape drive In-Reply-To: References: Message-ID: <82909936-939b-d38f-f8b3-aa4034f8f7a6@ieee.org> The TK25 IIRC Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 2021-02-12 11:19 a.m., Al Kossow via cctalk wrote: > > This is a mystery. > What DEC system used a CDC Sentinel DC300 cartridge tape drive? > > https://www.ebay.com/itm/Vintage-Computer-DEC-BY5A5-E-Tape-Drive-77-014320/313416738022 > > From aek at bitsavers.org Fri Feb 12 10:43:08 2021 From: aek at bitsavers.org (Al Kossow) Date: Fri, 12 Feb 2021 08:43:08 -0800 Subject: Reading ESDI disks In-Reply-To: <6734586b-16de-5396-c002-457eaf1575cc@bitsavers.org> References: <5d464323-3db8-2fba-ae69-289864d0fc5b@gmail.com> <72bbce20-087b-304f-46da-218029b8a1af@bitsavers.org> <6734586b-16de-5396-c002-457eaf1575cc@bitsavers.org> Message-ID: <9d7d9056-0a0a-6ffd-b47c-0b9a461173cb@bitsavers.org> there is a nice table in this to show the differences between ST506 and ESDI https://www.ardent-tool.com/misc/Evolution_of_ESDI.html From ce.murillosanchez at gmail.com Fri Feb 12 11:07:13 2021 From: ce.murillosanchez at gmail.com (Carlos E Murillo-Sanchez) Date: Fri, 12 Feb 2021 12:07:13 -0500 Subject: One more thing to fix... HP9000/380 power supply In-Reply-To: References: <894df8cd-1393-d3ec-cca1-a569c14a717a@gmail.com> Message-ID: <35fbc98a-ab5a-6241-f145-9bad6f4ff71a@gmail.com> Paul Berger via cctalk wrote: > On 2021-02-11 10:55 p.m., Carlos E Murillo-Sanchez via cctalk wrote: >> This decade seems to have increased the number of failing things in >> such a way that the "to be repaired" backlog is growing much faster >> than I can get to diminish it. Argh.? A month ago my trusty >> HP9000/380 ran just fine and I booted the different OS's in the SCSI >> and HPIB drives connected to it (this particular machine is >> interesting because the 9000/300 port of NetBSD was partly developed >> in it: it was Mike Wolfson's). Yesterday, it failed to turn on; the >> power supply is dead.? So I unracked the pile of drives and the >> computer, checked for obvious things (the fuse is fine, and nothing >> in the power supply is swelled up or leaking, or browned by heat; >> visually, it looks new; the HV caps seem to hold a charge).? I need >> the schematics for the power supply (at least the output connector; I >> can work my way back from that)? and also those for the backplane in >> this hp9000/380.? A preliminary search at bitsavers and elsewhere did >> not help.? Does anybody have these? snip > I have never seen any schematics for this power supply however on > bitsavers there is a document related to the expander that shows the > power supply pinout. > http://www.bitsavers.org/pdf/hp/9000_300/specs/A-98568-66501-4_98568A_Schematic_Notes_Jun85.pdf > This would be the same power supply as the processor box. Also > http://www.bitsavers.org/pdf/hp/9000_300/specs/A-98561-66501-4_98561AB_Schematic_Notes_Jun85.pdf > > Paul. Thank you!? these will be very helpful. Carlos. From jules.richardson99 at gmail.com Fri Feb 12 12:50:01 2021 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Fri, 12 Feb 2021 12:50:01 -0600 Subject: Mystery (unusual) 1973 terminal In-Reply-To: <00fc01d70158$d6d1ea30$8475be90$@verizon.net> References: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> <00fc01d70158$d6d1ea30$8475be90$@verizon.net> Message-ID: <02ede814-a4ee-b21a-baf2-2946b819f315@gmail.com> On 2/12/21 10:05 AM, William Sudbrink wrote: > Sort of reminds me of a DataPoint 2200. Clone maybe? I see what you're saying, but I don't think there's much in the way of brains to this thing, though (unlike the 2200, which I believe was an "actual computer") - it's just a terminal. From what I've seen of Datapoint/CTC's other offerings it looks like the 2200 system was the only one with a short vertical display - their plain terminals all appear to have a more conventional aspect ratio. From jules.richardson99 at gmail.com Fri Feb 12 13:02:16 2021 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Fri, 12 Feb 2021 13:02:16 -0600 Subject: Mystery (unusual) 1973 terminal In-Reply-To: <49C76CA7-1440-4CB3-A539-A380CD483430@comcast.net> References: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> <49C76CA7-1440-4CB3-A539-A380CD483430@comcast.net> Message-ID: <6a4da7b6-231e-7ba1-772b-6875d3e7b822@gmail.com> On 2/12/21 8:08 AM, Paul Koning wrote: > The photos are not particularly helpful; they show parts of the device > but not close enough to tell the details, while much of the case is not > shown. Is there any manufacturer label or serial number tag on the > case? I'll see if I can get him to share more photos - I know he'd posted some of the complete system a few months ago when he picked it up, so maybe he can add them to the Google folder. Unfortunately it seems that the Conrac on the tube is the only kind of branding on the whole thing. I wonder if it had a decal / emblem on the keyboard originally and that's fallen off. > One of those boards is full of rather sloppy ECO wires, which makes it > feel like a home made job, but the rest look like decent quality > commercial pieces. Yes, the general board quality (and other things, etc. the cage around the cards) just seems too nice for something that might have been a homebrew or prototype - it feels to me more like a commercial product, but one in its very early days before they'd got all the kinks worked out. > And yes, the blower is rather curious, it's hard to > see how a device like this might dissipate enough power to need that > kind of air mover. That aspect of it seems like a case of "just use what we have" to me, i.e. they wanted to duct warm air out the back without much clearance, and just happened to have a source of those blower assemblies. It's a bit odd that they're dumping air from around the PSU but there's no airflow through the card cage at all. Jules From cz at alembic.crystel.com Fri Feb 12 13:06:24 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Fri, 12 Feb 2021 14:06:24 -0500 Subject: Mystery DEC cartridge tape drive In-Reply-To: References: Message-ID: <725aa7c2-5be8-647a-de71-3264cd36b4ff@alembic.crystel.com> I have the controller for this if anyone needs one. C On 2/12/2021 11:19 AM, Al Kossow via cctalk wrote: > > This is a mystery. > What DEC system used a CDC Sentinel DC300 cartridge tape drive? > > https://www.ebay.com/itm/Vintage-Computer-DEC-BY5A5-E-Tape-Drive-77-014320/313416738022 > > From bhilpert at shaw.ca Fri Feb 12 13:08:48 2021 From: bhilpert at shaw.ca (Brent Hilpert) Date: Fri, 12 Feb 2021 11:08:48 -0800 Subject: Mystery (unusual) 1973 terminal In-Reply-To: <49C76CA7-1440-4CB3-A539-A380CD483430@comcast.net> References: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> <49C76CA7-1440-4CB3-A539-A380CD483430@comcast.net> Message-ID: On 2021-Feb-12, at 6:08 AM, Paul Koning via cctalk wrote: >> On Feb 12, 2021, at 7:50 AM, Jules Richardson via cctalk wrote: >> >> Hopefully the following link works, but someone over on one of the Facebook vintage groups has this oddball terminal from 1973 that they've been looking for any information on: >> >> https://drive.google.com/drive/folders/1-2uEFbi3OKBYr06y6yHnygDiLMtw2Qkj >> >> ... it's somewhat unconventional in that half the CRT is hidden from view within the machine, i.e. it only actually displays the top half of the display to the user - I've no idea if that's because it had a specific application where space was limited, or if it was simply that memory at the time was horribly expensive and so it was designed to only use a few lines (I know some vendors did that, although I think they typically presented the whole CRT and at least had the option of RAM upgrade to more lines). >> >> The blower assembly seems a little on the homebrew side, but on the other hand the PCBs and case construction make it seem like a professional product. >> >> The owner says the only label anywhere on the thing is the one on the CRT saying "Mfd in Japan for Conrac", but that's presumably just the CRT itself and not the entire machine. > > I remember Conrac as a well known CRT maker from that time. I think they were used in PLATO III terminals (mid 1960s). > >> I don't believe there's anything resembling a microprocessor in the system, it's all just TTL logic (the large white ceramic IC is an ACIA). >> >> Oh, I believe the owner's in Canada, so it may be it was made there and never exported to other parts of the world. >> >> Jules > > The photos are not particularly helpful; they show parts of the device but not close enough to tell the details, while much of the case is not shown. Is there any manufacturer label or serial number tag on the case? > > One of those boards is full of rather sloppy ECO wires, which makes it feel like a home made job, but the rest look like decent quality commercial pieces. And yes, the blower is rather curious, it's hard to see how a device like this might dissipate enough power to need that kind of air mover. Between google and the browser I'm using, the photos didn't display properly, so I downloaded them (upper right corner), which unzipped to high-res versions. From those: The board with the white ECOs is the memory, it has 5 1402's (256*4 shift register), 3 of them from Intel and 2 replacements from MIL (Microsystems International Limited) which is the only place Canada appears to come into it. Not clear how they would be organised for the screen . The main board has a Fairchild 3258 64*7*5 character generator, along with the 1602 UART/ACIA. The blower is probably targeting the pass transistors for the linear power supply, to avoid requiring a giant heat sink. Most/many terminals from that period had a large heat sink for the pass trans. I don't think the CRT is half-hidden, rather just a high-aspect-ratio CRT (very wide rel to height). Interesting that aside from the Intel/MIL memory chips, a couple of specialised clock drivers for those, and a couple of other chips, it's entirely Fairchild 9xxx series stuff. In terms of design & construction it looks pretty typical for its period; nonetheless a cool unit to be working on. From cclist at sydex.com Fri Feb 12 13:17:11 2021 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 12 Feb 2021 11:17:11 -0800 Subject: Mystery (unusual) 1973 terminal In-Reply-To: References: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> <49C76CA7-1440-4CB3-A539-A380CD483430@comcast.net> Message-ID: About all I can contribute is that Conrac made TV monitors--I rigged one up to a system for classroom instruction in the 1970s. I remember that it was a B&W 21" model. --Chuck From billdegnan at gmail.com Fri Feb 12 13:42:32 2021 From: billdegnan at gmail.com (Bill Degnan) Date: Fri, 12 Feb 2021 14:42:32 -0500 Subject: Mystery DEC cartridge tape drive In-Reply-To: <725aa7c2-5be8-647a-de71-3264cd36b4ff@alembic.crystel.com> References: <725aa7c2-5be8-647a-de71-3264cd36b4ff@alembic.crystel.com> Message-ID: and I probably have spare carts. On Fri, Feb 12, 2021 at 2:06 PM Chris Zach via cctalk wrote: > I have the controller for this if anyone needs one. > > C > > On 2/12/2021 11:19 AM, Al Kossow via cctalk wrote: > > > > This is a mystery. > > What DEC system used a CDC Sentinel DC300 cartridge tape drive? > > > > > https://www.ebay.com/itm/Vintage-Computer-DEC-BY5A5-E-Tape-Drive-77-014320/313416738022 > > > > > From cclist at sydex.com Fri Feb 12 13:46:28 2021 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 12 Feb 2021 11:46:28 -0800 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> Message-ID: <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> On 2/11/21 9:31 AM, Chuck Guzis via cctalk wrote: > I have a bunch of Panasonic/Matsushita 470/940 MB phase-change WORM > discs here--and the appropriate drive (Panasonic LF-5010 SCSI-2) to read > them. After some digging, I did find that Optisys offered a driver for DOS as late as 2008, called Optidriver 2000: https://web.archive.org/web/19980624194233/http://www.optisys.com/ Here's an ad from 1987 that shows an offering: https://books.google.com/books?id=x1yigTsvZxsC&lpg=RA1-PA475&ots=5n4IGUBIIU&dq=Optisys%20%22Phoenix%22&pg=RA1-PA475#v=onepage Is anyone familiar with this stuff? --Chuck From jules.richardson99 at gmail.com Fri Feb 12 13:50:34 2021 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Fri, 12 Feb 2021 13:50:34 -0600 Subject: Mystery (unusual) 1973 terminal In-Reply-To: References: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> <49C76CA7-1440-4CB3-A539-A380CD483430@comcast.net> Message-ID: On 2/12/21 1:08 PM, Brent Hilpert via cctalk wrote: > Between google and the browser I'm using, the photos didn't display > properly, so I downloaded them (upper right corner), which unzipped to > high-res versions. I had issues myself, zoom would work, but there seemed to be no obvious method for "just show me the thing at native resolution without a bunch of UI nonsense around it". > The board with the white ECOs is the memory, it has 5 1402's (256*4 > shift register), 3 of them from Intel and 2 replacements from MIL > (Microsystems International Limited) which is the only place Canada > appears to come into it. Yes, I believe the owner lives in Canada, but it's entirely possible that it was built in the US (or anywhere). > I don't think the CRT is half-hidden, rather just a high-aspect-ratio > CRT (very wide rel to height). If I remember right, the CRT sits partially recessed in the case behind the front bezel, with the keyboard obscuring it. But maybe I don't remember right :-) As mentioned to Paul, I'll see if I can get the owner to share some more photos of the complete unit. > In terms of design & construction it looks pretty typical for its > period; nonetheless a cool unit to be working on. Logic-wise for sure, although the physical construction is a little odd. Personally I like seeing terminals like this though because it seems that so few have survived - people will preserve the DEC / HP / Tektronix hardware and much of everything else from that very late '60s to mid-70's period is long gone. cheers Jules From jwsmail at jwsss.com Fri Feb 12 14:12:03 2021 From: jwsmail at jwsss.com (jim stephens) Date: Fri, 12 Feb 2021 12:12:03 -0800 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> Message-ID: <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> On 2/12/2021 11:46 AM, Chuck Guzis via cctalk wrote: > On 2/11/21 9:31 AM, Chuck Guzis via cctalk wrote: >> I have a bunch of Panasonic/Matsushita 470/940 MB phase-change WORM >> discs here--and the appropriate drive (Panasonic LF-5010 SCSI-2) to read >> them. > After some digging, I did find that Optisys offered a driver for DOS as > late as 2008, called Optidriver 2000: > > https://web.archive.org/web/19980624194233/http://www.optisys.com/ > > Here's an ad from 1987 that shows an offering: > > https://books.google.com/books?id=x1yigTsvZxsC&lpg=RA1-PA475&ots=5n4IGUBIIU&dq=Optisys%20%22Phoenix%22&pg=RA1-PA475#v=onepage > > Is anyone familiar with this stuff? > > --Chuck > > > There was a company who made a drive with glass media that a friend of ours repped for. It used a repurposed CD head which was driven hard enough to write their media.? it was sold as being able to be written and locked such that it couldn't be further modified if need be.? The nuclear security people were interested, but ultimately passed due to the size off the player, and the need for very long term access to the technology. The floppies you hear about (off topic) containing security information are written with a process that makes it very hard if not impossible to alter them w/o destruction of the data at the remote end. The worm drives had a way to write, then alter by putting in an update marker on the media.? You had to work your way to the last version of the directory and work your way back to find all the files.? Versioning was used to allow updates.? The software package could go back thru the data and allow you to see all the updates if need be. Once you got to full, the media would be marked locked with a special area at the inner tracks and from there on would not be updateable. Mot sure if this is the same operation or not. They used an regular ESDI interface on the drives they gave us for eval.? IIRC basic read and writes could happen on the media, but special drivers could be used to make it look more like a flat FAT type file from to such as Dos or Windows at the time. FAT from the standpoint of the software api, file name and the like.? The structure on the disk was not necessarily physically compatible. We got an eval unit because I had bought the necessry ESDI controller, and we could use the drive.? ESDI was not common at the time and was not widely available at that time.? IIRC we had 386 systems AT bus type systems. I had a sample disk at some point, not sure where it went.? I sent a big pile of manuals and specs to Al last year, might have had the stuff from whoever we had the drive from in that pile if I still had it. My partner passed away about 2 weeks ago and would possibly have recalled who it was, but can't ask now.? I'll try a scan of our contact files and see if "opti" anything shows up. thanks Jim From paulkoning at comcast.net Fri Feb 12 14:21:28 2021 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 12 Feb 2021 15:21:28 -0500 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> Message-ID: <6E01E79B-8B4A-4E7F-9256-1EDBD7199401@comcast.net> > On Feb 12, 2021, at 3:12 PM, jim stephens via cctalk wrote: > > > There was a company who made a drive with glass media that a friend of ours repped for. > > It used a repurposed CD head which was driven hard enough to write their media. it was sold as being able to be written and locked such that it couldn't be further modified if need be. The nuclear security people were interested, but ultimately passed due to the size off the player, and the need for very long term access to the technology. DEC had an optical WORM drive, I think it had rather large media. Not sure if that's the one you're thinking about. I believe it shipped but it doesn't feel like a particularly successful product. (Then again, the worst I remember was a networking device that sold a total of 3 units over its lifetime -- the DESNC...) paul From lproven at gmail.com Fri Feb 12 15:30:10 2021 From: lproven at gmail.com (Liam Proven) Date: Fri, 12 Feb 2021 22:30:10 +0100 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> Message-ID: On Fri, 12 Feb 2021 at 21:12, jim stephens via cctalk wrote: > > My partner passed away about 2 weeks ago and would possibly have > recalled who it was, but can't ask now. I'll try a scan of our contact > files and see if "opti" anything shows up. Oh, I am sorry to hear that. My condolences. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From cclist at sydex.com Fri Feb 12 15:30:44 2021 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 12 Feb 2021 13:30:44 -0800 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: <6E01E79B-8B4A-4E7F-9256-1EDBD7199401@comcast.net> References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> <6E01E79B-8B4A-4E7F-9256-1EDBD7199401@comcast.net> Message-ID: On 2/12/21 12:21 PM, Paul Koning via cctalk wrote: > > >> On Feb 12, 2021, at 3:12 PM, jim stephens via cctalk wrote: >> >> >> There was a company who made a drive with glass media that a friend of ours repped for. >> >> It used a repurposed CD head which was driven hard enough to write their media. it was sold as being able to be written and locked such that it couldn't be further modified if need be. The nuclear security people were interested, but ultimately passed due to the size off the player, and the need for very long term access to the technology. > > DEC had an optical WORM drive, I think it had rather large media. Not sure if that's the one you're thinking about. I believe it shipped but it doesn't feel like a particularly successful product. (Then again, the worst I remember was a networking device that sold a total of 3 units over its lifetime -- the DESNC...) WORM appeared in the 8" and 12" disc format as well, IIRC. --Chuck From jwsmail at jwsss.com Fri Feb 12 16:10:39 2021 From: jwsmail at jwsss.com (jim stephens) Date: Fri, 12 Feb 2021 14:10:39 -0800 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> <6E01E79B-8B4A-4E7F-9256-1EDBD7199401@comcast.net> Message-ID: <6771a2e5-30d5-4518-25c9-f2b1bede5682@jwsss.com> On 2/12/2021 1:30 PM, Chuck Guzis via cctalk wrote: > On 2/12/21 12:21 PM, Paul Koning via cctalk wrote: >> >>> On Feb 12, 2021, at 3:12 PM, jim stephens via cctalk wrote: >>> >>> >>> There was a company who made a drive with glass media that a friend of ours repped for. >>> >>> It used a repurposed CD head which was driven hard enough to write their media. it was sold as being able to be written and locked such that it couldn't be further modified if need be. The nuclear security people were interested, but ultimately passed due to the size off the player, and the need for very long term access to the technology. >> DEC had an optical WORM drive, I think it had rather large media. Not sure if that's the one you're thinking about. I believe it shipped but it doesn't feel like a particularly successful product. (Then again, the worst I remember was a networking device that sold a total of 3 units over its lifetime -- the DESNC...) > WORM appeared in the 8" and 12" disc format as well, IIRC. > > --Chuck > The company I'm thinking of had 5 1/4" drive, and appropriate media size.? I think your 400 or 500mb size rings familiar. Dec didn't pick this product up, and I lost track of them and where they sold their product. Fun story, may be a repeat.? The rep I mentioned was a retired Chief Petty Officer in the US Navy.? He was the one elected to send to make a Pentagon presentation about the media.? The presentation was to originally be to one or two officers, but once the possibility of something to replace the nuclear security mission was in play, it turned into a 30 person presentation. He normally would have had no problem with a crowd, and was a really great guy.? But when he went into the conference room, there were about 90% Admiral Flag officers, General officers, and the like there. The CPO reaction kicked in a bit, and he said his asshole puckered about so many times, and he finally calmed down. One thing an on duty CPO doesn't like is to have any officers around, as the job of that rank in the Navy is to run things.? A lot of times on board ship the reason they see officers is because something is wrong, so there's a learned reaction to seeing officers. He did great, but as I said, they weren't ready to trust a startup even though it was 100% of what they wanted. thanks Jim From steven at malikoff.com Fri Feb 12 16:17:07 2021 From: steven at malikoff.com (steven at malikoff.com) Date: Sat, 13 Feb 2021 08:17:07 +1000 Subject: Mystery (unusual) 1973 terminal In-Reply-To: References: <0aa0a26c-18f0-647c-b198-8783e71f9a8a@gmail.com> <49C76CA7-1440-4CB3-A539-A380CD483430@comcast.net> Message-ID: <374f7aa553d85d9388680a9c1c2b83e5.squirrel@webmail04.register.com> Jules said > Personally I like seeing terminals like this though because it seems that > so few have survived - people will preserve the DEC / HP / Tektronix > hardware and much of everything else from that very late '60s to mid-70's > period is long gone. I can't help either, but one place where pictures and descriptions of long-dead peripherals can be found are in the 'New Products' pages of DATAMATION. Every time I look through these I am amazed by the variety, type and number of manufacturers of gear eg. key-to-tape, high-speed line printers and other mundane yet expensive 1970s business equipment that was rarely advertised in later more consumer-oriented journals such as BYTE. Steve. From cclist at sydex.com Fri Feb 12 16:24:48 2021 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 12 Feb 2021 14:24:48 -0800 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: <6771a2e5-30d5-4518-25c9-f2b1bede5682@jwsss.com> References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> <6E01E79B-8B4A-4E7F-9256-1EDBD7199401@comcast.net> <6771a2e5-30d5-4518-25c9-f2b1bede5682@jwsss.com> Message-ID: <99dcbac9-3f93-932f-45ad-5f34bc738a37@sydex.com> On 2/12/21 2:10 PM, jim stephens via cctalk wrote: > The company I'm thinking of had 5 1/4" drive, and appropriate media > size.? I think your 400 or 500mb size rings familiar. There were several; the one I'm working with is 470/470MB double-sided 5.25" Very similar in size and looks to a PMC MO 5.25" cartridge. --Chuck From cz at alembic.crystel.com Fri Feb 12 16:32:18 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Fri, 12 Feb 2021 17:32:18 -0500 Subject: TK70 maintenance--swapping capstans Message-ID: <13273fa7-f84a-3334-de30-abedb1c1dc52@alembic.crystel.com> Well my little TK70 here has been squeaking and it looks like the capstans are frozen/bad. They don't move up and down and they don't spin well. Fortunately I have a dead TK70 with good capstans so I figured I would swap them. Unfortunately I don't have a maintenance manual (does anyone have one?) so I had to figure out alignment myself. Capstan alignment seems to be critical, if they are off the unit don't work... Anyway here is my procedure so far to get the unit to load and unload tapes on the bench. Not perfect, but a start.... Pulling the capstans requires you to remove the two lock nuts on top first. I recommend you count the turns from all the way tight if possible as alignment is critical, and the front and rear ones can be at different relative heights. Anyway if you didn't do this you need to adjust the rear height to trip the optical sensors and the front one to handle tape slew. Note: All the below is done with the unit on a bench, with a PC power supply. The first step is to adjust the rear capstan so the leader tape's wide hole for the end of tape-stop marker allows light from both LEDs/sensors to pass through. You do this by tightening the bolt down till snug, then back off 1/2 turn. Turn on unit, see if it unlatches. It probably will try to turn the tape 4 times then error out. Fine. Power down, back off the bolt 1/4 turn and try again. At some point it will open the latch. Note the # of turns of the bolt then keep going 1/4 turn at a time till it doesn't work again (too high). The proper value for your unit in turns is halfway between too low and too high. Reset the bolt and verify it works several times. For my unit the right height was about 1.5 turns out. Then you need to adjust the front capstan. The problem is if the front is higher or lower than the back you have tape slew errors. Start at the level of the rear one based on the # of turns minus a bit (1/2 turn). Then load a tape. It will load, but when you try to unload things will go bad, the tape will just move forward onto the take up reel 4 times, and the unit will error out. The reason is it has to read the tape as it turns to know a tape is loaded (as opposed to the leader where it looks for the end of leader light). If the capstans are not holding the tape level against the head it can't read. Each time it moves forward a bit, try bringing the front up 1/8 turn at a time. Eventually it will speed up, that means it can read the tape on one of those moves. It should then unload. Now you have the front basically set. It will unload the tape, cycle it a few times to make sure it's working. That's where I am now. Next step is to see if it will read the tape in the computer. I'll work on that tomorrow. Note if you ever shine an led flashlight into a running TK50 or 70 all hell will break loose as the system will see the light on the tape sensor and think it has hit BOT. Even worse is if both LED sensors trigger, then it thinks it is at end of leader and it will throw tape everywhere. Ask me how I know.... From brain at jbrain.com Fri Feb 12 17:01:11 2021 From: brain at jbrain.com (Jim Brain) Date: Fri, 12 Feb 2021 17:01:11 -0600 Subject: Digitalker 54104 IC In-Reply-To: <9187259.879986.1613088168916@mail.yahoo.com> References: <9187259.879986.1613088168916.ref@mail.yahoo.com> <9187259.879986.1613088168916@mail.yahoo.com> Message-ID: <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> On 2/11/2021 6:02 PM, ED SHARPE via cctalk wrote: > Most challanging was to figure out to make it say naughty things... and once you did? how it almost caused havoc in AZ Sounds like a story to add detail around... But, I'm sad because no one either has one nor can help me test this one.? So, I cannot enjoy the thrill of making it say inappropriate stuff :-( From ethan.dicks at gmail.com Fri Feb 12 17:09:01 2021 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Fri, 12 Feb 2021 18:09:01 -0500 Subject: Digitalker 54104 IC In-Reply-To: <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> References: <9187259.879986.1613088168916.ref@mail.yahoo.com> <9187259.879986.1613088168916@mail.yahoo.com> <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> Message-ID: On Fri, Feb 12, 2021 at 6:01 PM Jim Brain via cctalk wrote: > But, I'm sad because no one either has one nor can help me test this > one. So, I cannot enjoy the thrill of making it say inappropriate stuff :-( I have several vintage speech ICs, but not that one. -ethan From useddec at gmail.com Sat Feb 13 03:03:19 2021 From: useddec at gmail.com (Paul Anderson) Date: Sat, 13 Feb 2021 03:03:19 -0600 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> Message-ID: I think the DEC one was the RX20 or RZ20. It will take a while to find it, but I'll check the model number.. Paul On Fri, Feb 12, 2021 at 2:12 PM jim stephens via cctalk < cctalk at classiccmp.org> wrote: > > > On 2/12/2021 11:46 AM, Chuck Guzis via cctalk wrote: > > On 2/11/21 9:31 AM, Chuck Guzis via cctalk wrote: > >> I have a bunch of Panasonic/Matsushita 470/940 MB phase-change WORM > >> discs here--and the appropriate drive (Panasonic LF-5010 SCSI-2) to read > >> them. > > After some digging, I did find that Optisys offered a driver for DOS as > > late as 2008, called Optidriver 2000: > > > > https://web.archive.org/web/19980624194233/http://www.optisys.com/ > > > > Here's an ad from 1987 that shows an offering: > > > > > https://books.google.com/books?id=x1yigTsvZxsC&lpg=RA1-PA475&ots=5n4IGUBIIU&dq=Optisys%20%22Phoenix%22&pg=RA1-PA475#v=onepage > > > > Is anyone familiar with this stuff? > > > > --Chuck > > > > > > > > There was a company who made a drive with glass media that a friend of > ours repped for. > > It used a repurposed CD head which was driven hard enough to write their > media. it was sold as being able to be written and locked such that it > couldn't be further modified if need be. The nuclear security people > were interested, but ultimately passed due to the size off the player, > and the need for very long term access to the technology. > > The floppies you hear about (off topic) containing security information > are written with a process that makes it very hard if not impossible to > alter them w/o destruction of the data at the remote end. > > The worm drives had a way to write, then alter by putting in an update > marker on the media. You had to work your way to the last version of > the directory and work your way back to find all the files. Versioning > was used to allow updates. The software package could go back thru the > data and allow you to see all the updates if need be. > > Once you got to full, the media would be marked locked with a special > area at the inner tracks and from there on would not be updateable. > > Mot sure if this is the same operation or not. > > They used an regular ESDI interface on the drives they gave us for > eval. IIRC basic read and writes could happen on the media, but special > drivers could be used to make it look more like a flat FAT type file > from to such as Dos or Windows at the time. > > FAT from the standpoint of the software api, file name and the like. > The structure on the disk was not necessarily physically compatible. > > We got an eval unit because I had bought the necessry ESDI controller, > and we could use the drive. ESDI was not common at the time and was not > widely available at that time. IIRC we had 386 systems AT bus type > systems. > > I had a sample disk at some point, not sure where it went. I sent a big > pile of manuals and specs to Al last year, might have had the stuff from > whoever we had the drive from in that pile if I still had it. > > My partner passed away about 2 weeks ago and would possibly have > recalled who it was, but can't ask now. I'll try a scan of our contact > files and see if "opti" anything shows up. > > thanks > Jim > From couryhouse at aol.com Sat Feb 13 03:13:42 2021 From: couryhouse at aol.com (ED SHARPE) Date: Sat, 13 Feb 2021 09:13:42 +0000 (UTC) Subject: Digitalker 54104 IC In-Reply-To: <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> References: <9187259.879986.1613088168916.ref@mail.yahoo.com> <9187259.879986.1613088168916@mail.yahoo.com> <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> Message-ID: <263288494.1329864.1613207622266@mail.yahoo.com> oddly... I still have the? prototype? unit? we? built? ?to plug into? HP 2000 series processors and? ?21mx? processors.? it? sits in my den...I? was? looking? at? it the other day!? and? then? your message popped? up/?What are looking? ?for? I? am not? sure? I? got? all the prior? emails? on? this....?Ed#?????In a message dated 2/12/2021 4:01:25 PM US Mountain Standard Time, cctalk at classiccmp.org writes:? On 2/11/2021 6:02 PM, ED SHARPE via cctalk wrote: > Most challanging was to figure out to make it say naughty things... and once you did? how it almost caused havoc in AZ Sounds like a story to add detail around... But, I'm sad because no one either has one nor can help me test this one.? So, I cannot enjoy the thrill of making it say inappropriate stuff :-( From couryhouse at aol.com Sat Feb 13 03:13:42 2021 From: couryhouse at aol.com (ED SHARPE) Date: Sat, 13 Feb 2021 09:13:42 +0000 (UTC) Subject: Digitalker 54104 IC In-Reply-To: <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> References: <9187259.879986.1613088168916.ref@mail.yahoo.com> <9187259.879986.1613088168916@mail.yahoo.com> <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> Message-ID: <263288494.1329864.1613207622266@mail.yahoo.com> oddly... I still have the? prototype? unit? we? built? ?to plug into? HP 2000 series processors and? ?21mx? processors.? it? sits in my den...I? was? looking? at? it the other day!? and? then? your message popped? up/?What are looking? ?for? I? am not? sure? I? got? all the prior? emails? on? this....?Ed#?????In a message dated 2/12/2021 4:01:25 PM US Mountain Standard Time, cctalk at classiccmp.org writes:? On 2/11/2021 6:02 PM, ED SHARPE via cctalk wrote: > Most challanging was to figure out to make it say naughty things... and once you did? how it almost caused havoc in AZ Sounds like a story to add detail around... But, I'm sad because no one either has one nor can help me test this one.? So, I cannot enjoy the thrill of making it say inappropriate stuff :-( From brain at jbrain.com Sat Feb 13 04:11:55 2021 From: brain at jbrain.com (Jim Brain) Date: Sat, 13 Feb 2021 04:11:55 -0600 Subject: Digitalker 54104 IC In-Reply-To: <263288494.1329864.1613207622266@mail.yahoo.com> References: <9187259.879986.1613088168916.ref@mail.yahoo.com> <9187259.879986.1613088168916@mail.yahoo.com> <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> <263288494.1329864.1613207622266@mail.yahoo.com> Message-ID: <77bdde01-0ef4-e95f-78db-1b78184b8b73@jbrain.com> On 2/13/2021 3:13 AM, ED SHARPE via cctalk wrote: > oddly... I still have the? prototype? unit? we? built? ?to plug into? HP 2000 series processors and? ?21mx? processors.? it? sits in my den...I? was? looking? at? it the other day!? and? then? your message popped? up/?What are looking? ?for? I? am not? sure? I? got? all the prior? emails? on? this....?Ed#?????In a message dated 2/12/2021 4:01:25 PM US Mountain Standard Time, cctalk at classiccmp.org writes: > On 2/11/2021 6:02 PM, ED SHARPE via cctalk wrote: >> Most challanging was to figure out to make it say naughty things... and once you did? how it almost caused havoc in AZ > Sounds like a story to add detail around... > > But, I'm sad because no one either has one nor can help me test this > one.? So, I cannot enjoy the thrill of making it say inappropriate stuff :-( > > -------- Forwarded Message -------- Subject: Digitalker 54104 IC Date: Tue, 9 Feb 2021 22:02:20 -0600 From: Jim Brain To: General Discussion: On-Topic and Off-Topic Posts I suspect the answer to question #1 is no, but thought I would ask. 1) Anyone happen to have a known working Digitalker 54104 IC they are looking to trade for some cash that does not involve me selling an arm or a leg :-)? 2) Barring that, anyone have a known working Digitalker-based unit that might be able to pop in a suspected non working Digitalker IC and test? I have a Jameco (yep, the parts firm) manufactured Digitalker unit here called the JE-520 that is my original unit.? It suffered some ROM bit rot long ago and was not working, but I acquired the ROMs a while back to repair the unit. Now, though, as I pull it out for another project, it seems to be misbehaving.? It's like "address bit 1" on the input commands is acting up.? For instance, word 48 is "zero", and 49 is "one", but zero will be followed by "three" and then "zero" and then "three" as one sends values 48,49,50,51 to the unit.? I'm working to confirm the bit 1 on the cable to the PC is not bad, but initial efforts point to it being the IC. Jim -- Jim Brain brain at jbrain.com www.jbrain.com -- Jim Brain brain at jbrain.com www.jbrain.com From a.carlini at ntlworld.com Sat Feb 13 07:58:02 2021 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Sat, 13 Feb 2021 13:58:02 +0000 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> Message-ID: On 13/02/2021 09:03, Paul Anderson via cctalk wrote: > I think the DEC one was the RX20 or RZ20. It will take a while to find it, > but I'll check the model number.. > > Paul > The DEC RV20 was announced in 1988. Those were quite large as I recall (bigger than an LP). ~2GB write-once. There was the RWZ01 (replaced by the RWZ52), which was 1.2GB per disk. This was re-writeable. Antonio -- Antonio Carlini antonio at acarlini.com From bill.gunshannon at hotmail.com Sat Feb 13 08:15:39 2021 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sat, 13 Feb 2021 09:15:39 -0500 Subject: Digitalker 54104 IC In-Reply-To: References: <9187259.879986.1613088168916.ref@mail.yahoo.com> <9187259.879986.1613088168916@mail.yahoo.com> <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> Message-ID: On 2/12/21 6:09 PM, Ethan Dicks via cctalk wrote: > On Fri, Feb 12, 2021 at 6:01 PM Jim Brain via cctalk > wrote: >> But, I'm sad because no one either has one nor can help me test this >> one. So, I cannot enjoy the thrill of making it say inappropriate stuff :-( > > I have several vintage speech ICs, but not that one. > I do as well. I have the Radio Shack "Voice Synthesizer IC Set" sitting on the desk in front of me right now. bill From couryhouse at aol.com Sat Feb 13 10:44:54 2021 From: couryhouse at aol.com (ED SHARPE) Date: Sat, 13 Feb 2021 16:44:54 +0000 (UTC) Subject: Digitalker 54104 IC References: <713551601.1411891.1613234694943.ref@mail.yahoo.com> Message-ID: <713551601.1411891.1613234694943@mail.yahoo.com> Bill...this just? struck a memory I think I have a Radioshack Digitalker in a packaging? but recall it being just one large chip...? Ed #??? SMECC On Saturday, February 13, 2021 Bill Gunshannon via cctalk wrote: On 2/12/21 6:09 PM, Ethan Dicks via cctalk wrote: > On Fri, Feb 12, 2021 at 6:01 PM Jim Brain via cctalk > wrote: >> But, I'm sad because no one either has one nor can help me test this >> one.? So, I cannot enjoy the thrill of making it say inappropriate stuff :-( > > I have several vintage speech ICs, but not that one. > I do as well.? I have the Radio Shack "Voice Synthesizer IC Set" sitting on the desk in front of me right now. bill From bill.gunshannon at hotmail.com Sat Feb 13 11:05:22 2021 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sat, 13 Feb 2021 12:05:22 -0500 Subject: Digitalker 54104 IC In-Reply-To: <713551601.1411891.1613234694943@mail.yahoo.com> References: <713551601.1411891.1613234694943.ref@mail.yahoo.com> <713551601.1411891.1613234694943@mail.yahoo.com> Message-ID: On 2/13/21 11:44 AM, ED SHARPE via cctalk wrote: > > Bill...this just? struck a memory I think I have a Radioshack Digitalker in a packaging? but recall it being just one large chip...? Ed #??? SMECC The one I have in front of me is the SPO256-AL2 (actual chip is labeled SPO256-017) and the package includes an SPR016-117 which is listed as an External Serial Speech ROM. Would probably be fun to hook it up to an Arduino and see what it has to say. :-) bill From mattislind at gmail.com Sat Feb 13 11:18:28 2021 From: mattislind at gmail.com (Mattis Lind) Date: Sat, 13 Feb 2021 18:18:28 +0100 Subject: Deciphering an odd floppy disk format. Message-ID: I have a few 8 inch floppy disks coming from a Q1 Lite computer. I tried reading them on a PC with a Adaptec 1522A floppy controller but it failed completely. Then I tried my Catweasel and dumped the raw flux data. The format differs from what I have seen before. I did a quick histogram of the flux lengths and it appears that there are four groups of sample lengths evenly spaced. Peaks at 30, 48, 66 och 84 samples flux lengths. The longest flux lengths are interspersed in between more normal flux lengths in the actual data and I get the same type of result regardless of reads of the same track and between different tracks. But the relative frequency is much much lower for the longer flux lengths than the shorter ones. An RX02 (MFM ish) had 26, 41, 55 samples as the peaks in the histogram. As far as I understand cw2dmk software uses 14 MHz setting in the catweasel so each sample length is around 70ns. Anyone that has seen this kind of format before? Or is it just a reading error? I have the same result from several discs though and they look to be in quite good shape physically. Link contains histogram files and a raw track flux file. https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing From elson at pico-systems.com Sat Feb 13 11:40:29 2021 From: elson at pico-systems.com (Jon Elson) Date: Sat, 13 Feb 2021 11:40:29 -0600 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: Message-ID: <60280F0D.300@pico-systems.com> On 02/13/2021 11:18 AM, Mattis Lind via cctalk wrote: > The longest flux lengths are interspersed in between more normal flux > lengths in the actual data and I get the same type of result regardless of > reads of the same track and between different tracks. But the relative > frequency is much much lower for the longer flux lengths than the shorter > ones. The low-frequency of occurrence flux changes may be head switching when the write and erase current is turned on and off at the beginning and end of data blocks. So, those should be ignored. Jon From Mark at Misty.com Sat Feb 13 11:44:11 2021 From: Mark at Misty.com (Mark G Thomas) Date: Sat, 13 Feb 2021 12:44:11 -0500 Subject: Digitalker 54104 IC In-Reply-To: References: <9187259.879986.1613088168916.ref@mail.yahoo.com> <9187259.879986.1613088168916@mail.yahoo.com> <792000f1-08da-54f3-51af-b50e3d370b0d@jbrain.com> Message-ID: <713cabfa-b5b8-8df9-acd0-21cb542ef981@Misty.com> Hi, On 2/13/21 9:15 AM, Bill Gunshannon via cctalk wrote: > On 2/12/21 6:09 PM, Ethan Dicks via cctalk wrote: >> On Fri, Feb 12, 2021 at 6:01 PM Jim Brain via cctalk >> wrote: >>> But, I'm sad because no one either has one nor can help me test this >>> one.? So, I cannot enjoy the thrill of making it say inappropriate >>> stuff :-( >> >> I have several vintage speech ICs, but not that one. >> > > I do as well.? I have the Radio Shack "Voice Synthesizer IC Set" > sitting on the desk in front of me right now. > > bill > BG Micro sold a board called I believe the CompuTalker, with the SP0256A-AL2 and CTS256AL2/P pair, like the ICs Radio Shack sold. I have one of these boards sitting in front of me that I recently mounted in a nice case with power supply. Mine had some leaky electrolytic caps, but fortunately the damage was minimal and easily fixed. I found reference to it in this posting here: https://groups.google.com/u/1/g/comp.sys.tandy/c/X_6fSse6As4 I've temporarily (please? save these if you want them) copied what I could find in terms of documentation and schematics for these ICs here: http://files.markgthomas.com/dl/SP0256-speech-IC-board/ Photos of mine are included. Mark -- Mark G Thomas , KC3DRE From cclist at sydex.com Sat Feb 13 12:44:59 2021 From: cclist at sydex.com (Chuck Guzis) Date: Sat, 13 Feb 2021 10:44:59 -0800 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: Message-ID: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> On 2/13/21 9:18 AM, Mattis Lind via cctalk wrote: > Link contains histogram files and a raw track flux file. > > https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing > A quick glance shows the typical t 1.5t and 2t MFM pattern, so I'd start with that. As to the 8x/5xH intervals, they appear to be part of the preamble to address marks. --Chuck From phb.hfx at gmail.com Sat Feb 13 12:45:45 2021 From: phb.hfx at gmail.com (Paul Berger) Date: Sat, 13 Feb 2021 14:45:45 -0400 Subject: Digitalker 54104 IC In-Reply-To: References: <713551601.1411891.1613234694943.ref@mail.yahoo.com> <713551601.1411891.1613234694943@mail.yahoo.com> Message-ID: <1d3af3ca-16ee-d8ca-03a5-d67ec0c4dc00@gmail.com> On 2021-02-13 1:05 p.m., Bill Gunshannon via cctalk wrote: > On 2/13/21 11:44 AM, ED SHARPE via cctalk wrote: >> >> Bill...this just? struck a memory I think I have a Radioshack >> Digitalker in a packaging? but recall it being just one large >> chip...? Ed #??? SMECC > > The one I have in front of me is the SPO256-AL2 (actual chip is labeled > SPO256-017) and the package includes an SPR016-117 which is listed as an > External Serial Speech ROM.? Would probably be fun to hook it up to an > Arduino and see what it has to say.? :-) > > bill > I can help with documentation for SPO256 if needed I have one that is working connected to the GI CTS256A-AL2 which does a mediocre job of converting ASCII text to speech. Paul. From cclist at sydex.com Sat Feb 13 12:58:58 2021 From: cclist at sydex.com (Chuck Guzis) Date: Sat, 13 Feb 2021 10:58:58 -0800 Subject: Wanted: Info on Optisys/Optidisk WORM file system In-Reply-To: <6771a2e5-30d5-4518-25c9-f2b1bede5682@jwsss.com> References: <691742c2-fbe1-4f50-f510-89c8445c980b@sydex.com> <365c4602-19d5-9989-c1d7-85ad1ea1ba5a@sydex.com> <43eef079-ae2a-49c1-7f99-ae1a834316a6@jwsss.com> <6E01E79B-8B4A-4E7F-9256-1EDBD7199401@comcast.net> <6771a2e5-30d5-4518-25c9-f2b1bede5682@jwsss.com> Message-ID: I'm discovering that WORM is a world in itself. After taking forever to try to image a 470MB disc and taking forever to do it because of automatic retries on unwritten sectors, I've discovered that WORM has a SCSI2 command that's unique to it--38H, "Medium Scan" which can be used to identify groups of written or blank blocks. There are, of course, other optional WORM-specific commands, but I thought that I'd pass this one along, as it doesn't occur in any other medium type, as far as I'm aware. --Chuck From mattislind at gmail.com Sat Feb 13 13:05:30 2021 From: mattislind at gmail.com (Mattis Lind) Date: Sat, 13 Feb 2021 20:05:30 +0100 Subject: Deciphering an odd floppy disk format. In-Reply-To: <60280F0D.300@pico-systems.com> References: <60280F0D.300@pico-systems.com> Message-ID: Den l?r 13 feb. 2021 kl 18:40 skrev Jon Elson : > On 02/13/2021 11:18 AM, Mattis Lind via cctalk wrote: > > The longest flux lengths are interspersed in between more normal flux > > lengths in the actual data and I get the same type of result regardless > of > > reads of the same track and between different tracks. But the relative > > frequency is much much lower for the longer flux lengths than the shorter > > ones. > The low-frequency of occurrence flux changes may be head > switching when the write and erase current is turned on and > off at the beginning and end of data blocks. So, those > should be ignored. > Yes. I am aware of write splicing. I would imagine that the number of these longer fluxes should be somewhere around two times the number of sectors, right? I see much more than what I would I would guess is the sector count. Wouldn't these write splicing fluxes distribute quite evenly in terms of length, creating a noise of weird fluxes? In this case there are quite some fluxes centered around 84. If this would be a result of write splicing I would think the same would happen on the RX02 disk. I cannot see any of these long type fluxes there. How can that be explained? /Mattis > Jon > From mattislind at gmail.com Sat Feb 13 13:15:57 2021 From: mattislind at gmail.com (Mattis Lind) Date: Sat, 13 Feb 2021 20:15:57 +0100 Subject: Deciphering an odd floppy disk format. In-Reply-To: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> Message-ID: Den l?r 13 feb. 2021 kl 19:45 skrev Chuck Guzis via cctalk < cctalk at classiccmp.org>: > On 2/13/21 9:18 AM, Mattis Lind via cctalk wrote: > > > > Link contains histogram files and a raw track flux file. > > > > > https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing > > > A quick glance shows the typical t 1.5t and 2t MFM pattern, so I'd start > with that. I'll try that. > As to the 8x/5xH intervals, they appear to be part of the > preamble to address marks. > > Can you please elaborate! What do you mean by 8x/5xH intervals? You think that these fluxes are part of some address mark or data mark, right? > --Chuck > From cclist at sydex.com Sat Feb 13 14:06:05 2021 From: cclist at sydex.com (Chuck Guzis) Date: Sat, 13 Feb 2021 12:06:05 -0800 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> Message-ID: <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> On 2/13/21 11:15 AM, Mattis Lind wrote: > As to the 8x/5xH intervals, they appear to be part of the > preamble to address marks. > > > Can you please elaborate!? What do you mean by 8x/5xH intervals? > > You think that these fluxes are part of some address mark or data mark, > right? By 8x/5xh I mean the intervals that you noted were 84 clocks. Consider a part of your sample: > 00003f0 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 20 1e 20 1d 20 1e | ......... . . .| > 00000400 20 1e 20 1e 1f 1d 20 1d 20 1e 1f 1e 1f 1e 1f 1e | . ... . .......| > 00000410 1f 1e 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e |.. .............| > 00000420 22 20 39 30 1f 2e 1f 1d 20 1e 20 1d 1f 1e 20 1d |" 90.... . ... .| > 00000430 20 1e 20 1e 20 1d 1f 1e 1f 1e 1f 1e 20 1e 1f 1e | . . ....... ...| > 00000440 1f 1e 1f 1e 20 1d 20 1e 1f 1e 1f 1d 20 1e 1f 1e |.... . ..... ...| > 00000450 20 1d 1f 1c 54 2d 30 2e 1f 1d 1f 2f 1f 1d 1f 1d | ...T-0..../....| > 00000460 30 40 2f 2e 1e 1c 43 1b 44 2d 1e 1e 1f 1e 1f 1e |0@/...C.D-......| > 00000470 1f 2f 31 1d 1f 1e 1f 1e 1f 1e 1f 1c 21 1e 1f 1f |./1.........!...| > 00000480 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1e 1f 1e |................| > 00000490 1f 1e 1f 1f 1e 1e 1f 1e 1f 1e 1f 1e 1f 1e 1e 1f |................| > 000004a0 1f 1e 1f 1f 1f 1d 1d 53 2d 2f 2d 1d 42 1d 2e 30 |.......S-/-.B..0| > 000004b0 2f 1e 1e 1f 1e 1e 30 30 1e 1e 1e 1e 1e 30 2f 1e |/.....00.....0/.| Note that the 54 at 0454 appears to be the preamble to an address mark. Similarly, we can see the same here: > 00000740 20 1e 20 1d 20 1e 20 1e 20 1d 20 1e 20 1d 20 1d | . . . . . . . .| > 00000750 1f 1e 20 1e 1e 1c 54 2c 30 2e 1f 1d 20 2f 1e 1e |.. ...T,0... /..| > 00000760 1f 1d 30 40 2f 2e 1f 1d 1f 30 1e 2f 30 1d 1f 1d |..0@/....0./0...| > 00000770 31 2e 1e 2f 30 1d 1f 1e 20 1e 1f 1e 1f 1f 27 1e |1../0... .....'.| > 00000780 30 2f 1d 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f |0/..............| > 00000790 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f 1e 1f |................| > 000007a0 1e 1f 1e 1f 1f 1e 1d 53 2d 2f 2e 1d 42 1c 40 42 |.......S-/..B. at B| > 000007b0 2e 2e 1c 43 2c 2e 41 1c 40 42 2c 2f 2f 1e 30 1e |...C,.A. at B,//.0.| > 000007c0 30 1d 30 30 2e 1d 31 1e 1e 1f 1e 31 1d 1d 43 2e |0.00..1....1..C.| > 000007d0 1d 30 30 1e 1e 1f 1e 1e 30 30 1d 1f 1f 1e 1e 31 |.00.....00.....1| Note the 54 at 0756 at the start of what appears to be an ID address mark and the 53 at 07a7 at the start of what appears to be a data address mark. --Chuck From henk.gooijen at hotmail.com Sat Feb 13 14:43:20 2021 From: henk.gooijen at hotmail.com (Henk Gooijen) Date: Sat, 13 Feb 2021 20:43:20 +0000 Subject: Digitalker 54104 IC In-Reply-To: References: <713551601.1411891.1613234694943.ref@mail.yahoo.com> <713551601.1411891.1613234694943@mail.yahoo.com>, Message-ID: I know the SP0256-AL2 (it is a zero not an ?ooo?). That chip is a phoneme generator and it was described in a BYTE issue. It has (IIRC) 6 ?data? inputs to select one of the 64 stored phonemes, and a strobe signal. Depending on the suffix (here ?-AL2?) it contains certain phonemes and can co-operate with external premanufactured Speech ROMs. You can google for more info on the SP0256-AL2. The ?-AL2? was the generic phoneme chip, I used it in my StarShip back In theearly ?90-ties. *very* robotic speech ? Note that the chips needs an external Xtal of somewhat odd frequency, but I think it will work with an Xtal of (again IIRC) 3.2 MHz. Van: Bill Gunshannon via cctalk Verzonden: zaterdag 13 februari 2021 18:05 Aan: cctalk at classiccmp.org Onderwerp: Re: Digitalker 54104 IC On 2/13/21 11:44 AM, ED SHARPE via cctalk wrote: > > Bill...this just struck a memory I think I have a Radioshack Digitalker in a packaging but recall it being just one large chip... Ed # SMECC The one I have in front of me is the SPO256-AL2 (actual chip is labeled SPO256-017) and the package includes an SPR016-117 which is listed as an External Serial Speech ROM. Would probably be fun to hook it up to an Arduino and see what it has to say. :-) bill From mattislind at gmail.com Sat Feb 13 14:51:01 2021 From: mattislind at gmail.com (Mattis Lind) Date: Sat, 13 Feb 2021 21:51:01 +0100 Subject: Deciphering an odd floppy disk format. In-Reply-To: <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: Den l?r 13 feb. 2021 kl 21:06 skrev Chuck Guzis : > On 2/13/21 11:15 AM, Mattis Lind wrote: > > > As to the 8x/5xH intervals, they appear to be part of the > > preamble to address marks. > > > > > > Can you please elaborate! What do you mean by 8x/5xH intervals? > > > > You think that these fluxes are part of some address mark or data mark, > > right? > > By 8x/5xh I mean the intervals that you noted were 84 clocks. Consider > a part of your sample: > > > 00003f0 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 20 1e 20 1d 20 1e | ......... . > . .| > > 00000400 20 1e 20 1e 1f 1d 20 1d 20 1e 1f 1e 1f 1e 1f 1e | . ... . > .......| > > 00000410 1f 1e 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e |.. > .............| > > 00000420 22 20 39 30 1f 2e 1f 1d 20 1e 20 1d 1f 1e 20 1d |" 90.... . > ... .| > > 00000430 20 1e 20 1e 20 1d 1f 1e 1f 1e 1f 1e 20 1e 1f 1e | . . > ....... ...| > > 00000440 1f 1e 1f 1e 20 1d 20 1e 1f 1e 1f 1d 20 1e 1f 1e |.... . > ..... ...| > > 00000450 20 1d 1f 1c 54 2d 30 2e 1f 1d 1f 2f 1f 1d 1f 1d | > ...T-0..../....| > > 00000460 30 40 2f 2e 1e 1c 43 1b 44 2d 1e 1e 1f 1e 1f 1e |0@ > /...C.D-......| > > 00000470 1f 2f 31 1d 1f 1e 1f 1e 1f 1e 1f 1c 21 1e 1f 1f > |./1.........!...| > > 00000480 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1e 1f 1e > |................| > > 00000490 1f 1e 1f 1f 1e 1e 1f 1e 1f 1e 1f 1e 1f 1e 1e 1f > |................| > > 000004a0 1f 1e 1f 1f 1f 1d 1d 53 2d 2f 2d 1d 42 1d 2e 30 > |.......S-/-.B..0| > > 000004b0 2f 1e 1e 1f 1e 1e 30 30 1e 1e 1e 1e 1e 30 2f 1e > |/.....00.....0/.| > > Note that the 54 at 0454 appears to be the preamble to an address mark. > Similarly, we can see the same here: > > > 00000740 20 1e 20 1d 20 1e 20 1e 20 1d 20 1e 20 1d 20 1d | . . . . . > . . .| > > 00000750 1f 1e 20 1e 1e 1c 54 2c 30 2e 1f 1d 20 2f 1e 1e |.. > ...T,0... /..| > > 00000760 1f 1d 30 40 2f 2e 1f 1d 1f 30 1e 2f 30 1d 1f 1d |..0@ > /....0./0...| > > 00000770 31 2e 1e 2f 30 1d 1f 1e 20 1e 1f 1e 1f 1f 27 1e |1../0... > .....'.| > > 00000780 30 2f 1d 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f > |0/..............| > > 00000790 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f 1e 1f > |................| > > 000007a0 1e 1f 1e 1f 1f 1e 1d 53 2d 2f 2e 1d 42 1c 40 42 > |.......S-/..B. at B| > > 000007b0 2e 2e 1c 43 2c 2e 41 1c 40 42 2c 2f 2f 1e 30 1e |...C,.A. at B > ,//.0.| > > 000007c0 30 1d 30 30 2e 1d 31 1e 1e 1f 1e 31 1d 1d 43 2e > |0.00..1....1..C.| > > 000007d0 1d 30 30 1e 1e 1f 1e 1e 30 30 1d 1f 1f 1e 1e 31 > |.00.....00.....1| > > Note the 54 at 0756 at the start of what appears to be an ID address > mark and the 53 at 07a7 at the start of what appears to be a data > address mark. > That makes sense. I tried to hand decode the section directly after 0756 and it decoded fine as mfm. No violations. And I could see something that could possibly be the value 5 which would then correspond to track 5. Now I can try to write a piece of software that handles it and see if this gives something useful. I have a directory listing so somewhere I think I could match up what I get with that printout. /Mattis > --Chuck > > > > From bill.gunshannon at hotmail.com Sat Feb 13 14:52:10 2021 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sat, 13 Feb 2021 15:52:10 -0500 Subject: Digitalker 54104 IC In-Reply-To: References: <713551601.1411891.1613234694943.ref@mail.yahoo.com> <713551601.1411891.1613234694943@mail.yahoo.com> Message-ID: On 2/13/21 3:43 PM, Henk Gooijen wrote: > I know the SP0256-AL2 (it is a zero not an ?ooo?). Yes, the Wiki points that out. > > That chip is a phoneme generator and it was described in a BYTE issue. Do you remember which issue? > > It has (IIRC) 6 ?data? inputs to select one of the 64 stored phonemes, > and a strobe signal. Depending on the suffix (here ?-AL2?) it contains > certain phonemes and can co-operate with external premanufactured > Speech ROMs. You can google for more info on the SP0256-AL2. > > The ?-AL2? was the generic phoneme chip, I used it in my StarShip back > > In theearly ?90-ties. **very** robotic speech ? Just so it doesn't sound like Hawking. > > Note that the chips needs an external Xtal of somewhat odd frequency, > but I think it will work with an Xtal of (again IIRC) 3.2 MHz. Diagrams that come with it show 3.12mhz. Not much off of 3.2 which could probably be trimmed if needed, I may never get around to playing with it but one never knows. I have a couple of rasPivoice which I never got a chance to pla with and they are a lot easier to handle. :-) bill From ethan.dicks at gmail.com Sat Feb 13 16:34:29 2021 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Sat, 13 Feb 2021 17:34:29 -0500 Subject: Digitalker 54104 IC In-Reply-To: References: <713551601.1411891.1613234694943.ref@mail.yahoo.com> <713551601.1411891.1613234694943@mail.yahoo.com> Message-ID: On Sat, Feb 13, 2021 at 12:05 PM Bill Gunshannon via cctalk wrote: > The one I have in front of me is the SPO256-AL2 (actual chip is labeled > SPO256-017) and the package includes an SPR016-117 which is listed as an > External Serial Speech ROM. Would probably be fun to hook it up to an > Arduino and see what it has to say. :-) That's one of the ones I have. I also have a couple SC-01/SC-02 (Gorf, RB5X...), a CBM Magic Voice, and at least 1-2 others. But not the one that Jim wants. -ethan From cz at alembic.crystel.com Sat Feb 13 21:10:59 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Sat, 13 Feb 2021 22:10:59 -0500 Subject: TK70 maintenance--swapping capstans In-Reply-To: <13273fa7-f84a-3334-de30-abedb1c1dc52@alembic.crystel.com> References: <13273fa7-f84a-3334-de30-abedb1c1dc52@alembic.crystel.com> Message-ID: <255f42ea-c4f3-95c4-df49-4c531439256c@alembic.crystel.com> So.... TK70 is working again, and the solution was not what I thought. Yesterday I spent the afternoon adjusting the capstan bolts, first one, then the other to see if the height adjustment worked. I found that the rear one (also known as the encoder) was the most sensitive to bolt tension. Then I watched it run and realized something: When the TK70 starts up without a tape in the unit it moves the leader a tiny bit. I thought it was looking for the end of leader hole and was missing it due to alignment, but that's not what happens as there is only a single LED transceiver watching the tape. Thus it had to be something else, and the only thing it could be is the velocity sensor. The velocity sensor is a part of the rear capstan, I took it apart to see what the heck was going on and figured out the problem: The top bearing has an imperfection and is not allowing the capstan to spin on the bearing. Instead it spins under the bolt, which causes it to drag and read speed improperly. That little jog of the leader during loading moves the capstan a bit and allows the unit to verify it works. Thus different tensions on the bolt were allowing it to move (somewhat) but not well enough for the tape drive to work. So..... I swapped in the capstan from the broken TK70. Swapping it is a *job* and while there I took the old one apart and saw that it's pretty complex inside but if the bolt is not tight enough the sensor disc in there rubs against the diffraction grating below the LED. Put in the other capstan, put the drive together, and it works. Adjusted the bolts so they ride the tape with a minimum of edge touching and it still works (the head does adjust for the capstan height. The bad news is the tachometer capstan is in pretty bad shape, the chrome flaked off the top and the bottom and it's not perfectly smooth. I may try to sand the flanges with 2,000 grit sandpaper to smooth it out but unlike the front one it doesn't have to deal with tapes that have varying heights so as long as it is aligned with the take up reel (which doesn't go up and down) it might be ok. Very interesting little project. I guess my last question is this: Is there a difference between the tachometer capstan of a TK50 and a TK70? Maybe I can swap one from a broken TK50 I have (I have one good one too) and get the second 70 running as a spare. Or maybe I should just troubleshoot the broken TK50 now that I am smarter... Chris From nw.johnson at ieee.org Sun Feb 14 14:30:25 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Sun, 14 Feb 2021 15:30:25 -0500 Subject: Plessey/Dilog DCV54 Message-ID: <0744c54d-2c69-657e-3950-a037c37dca97@ieee.org> Has anybody got a DCV54 that they are using? I am trying to get one working with David Gasswein's mfm board and having no luck. The controller is working fine with a standard floppy as an RX33, even boots the MicroVAX from it.? But on-board diagnostics cannot format or even recognise the mfm board as a winchester. Just got the scope out today and found that the drive select lines are being terminated OK on the mfm board, bit the controller is not even dropping drive select. (Yes I have tried new cables) Problem is I don't have anything old enough to test the mfm boards with other than the Plessey controlelr! I'm thinking there must be some on-board config that I am missing on the controller. - It has never had a real mfm drive connected to it. Any help appreciated, Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org From paulkoning at comcast.net Sun Feb 14 14:36:51 2021 From: paulkoning at comcast.net (Paul Koning) Date: Sun, 14 Feb 2021 15:36:51 -0500 Subject: Plessey/Dilog DCV54 In-Reply-To: <0744c54d-2c69-657e-3950-a037c37dca97@ieee.org> References: <0744c54d-2c69-657e-3950-a037c37dca97@ieee.org> Message-ID: > On Feb 14, 2021, at 3:30 PM, Nigel Johnson via cctalk wrote: > > Has anybody got a DCV54 that they are using? > > I am trying to get one working with David Gasswein's mfm board and > having no luck. > > The controller is working fine with a standard floppy as an RX33, even > boots the MicroVAX from it. But on-board diagnostics cannot format or > even recognise the mfm board as a winchester. > > Just got the scope out today and found that the drive select lines are > being terminated OK on the mfm board, bit the controller is not even > dropping drive select. (Yes I have tried new cables) > > Problem is I don't have anything old enough to test the mfm boards with > other than the Plessey controlelr! > > I'm thinking there must be some on-board config that I am missing on the > controller. - It has never had a real mfm drive connected to it. > > Any help appreciated, > > Nigel I had good luck with mine, though admittedly I have the advantage of having real drives to compare with (that's on a DEC Pro). Do you have the matching drive select jumper in place? Can you see the "selected" signal being asserted by the board? Just to be sure... remember that floppy cables and hard drive cables look similar but are different and not interchangeable. paul From imp at bsdimp.com Sun Feb 14 16:39:14 2021 From: imp at bsdimp.com (Warner Losh) Date: Sun, 14 Feb 2021 15:39:14 -0700 Subject: Plessey/Dilog DCV54 In-Reply-To: References: <0744c54d-2c69-657e-3950-a037c37dca97@ieee.org> Message-ID: On Sun, Feb 14, 2021 at 1:36 PM Paul Koning via cctalk < cctalk at classiccmp.org> wrote: > > > > On Feb 14, 2021, at 3:30 PM, Nigel Johnson via cctalk < > cctalk at classiccmp.org> wrote: > > > > Has anybody got a DCV54 that they are using? > > > > I am trying to get one working with David Gasswein's mfm board and > > having no luck. > > > > The controller is working fine with a standard floppy as an RX33, even > > boots the MicroVAX from it. But on-board diagnostics cannot format or > > even recognise the mfm board as a winchester. > > > > Just got the scope out today and found that the drive select lines are > > being terminated OK on the mfm board, bit the controller is not even > > dropping drive select. (Yes I have tried new cables) > > > > Problem is I don't have anything old enough to test the mfm boards with > > other than the Plessey controlelr! > > > > I'm thinking there must be some on-board config that I am missing on the > > controller. - It has never had a real mfm drive connected to it. > > > > Any help appreciated, > > > > Nigel > > I had good luck with mine, though admittedly I have the advantage of > having real drives to compare with (that's on a DEC Pro). > > Do you have the matching drive select jumper in place? Can you see the > "selected" signal being asserted by the board? > > Just to be sure... remember that floppy cables and hard drive cables look > similar but are different and not interchangeable. > The two things I've been bitten by are making sure that dual cables have the drive before the extra bit with the twist. The other thing I've been bitten by isn't relevant here: I had the 20-pin cable plugged into the wrong socket a few times when trying to image disks... Warner From lars at nocrew.org Mon Feb 15 04:46:59 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 15 Feb 2021 10:46:59 +0000 Subject: Systems Concepts SC-4 computer Message-ID: <7wblcla9r0.fsf@junk.nocrew.org> Anyone ever heard of the Systems Concepts SC-4 computer? "This is an two's-complement 18-bit machine, with 16 general registers and a 16 level priority interrupt system. Its programming ascpects are explained in great detail in the SC-4 Reference Manual, of which a draft is enclosed. Below are times for some typical instructions. Add word on stack (not top word) to general register 1.5 us Multiply general register by memory word 6.2 us Jump 750 ns Push and Jump 1.5 us Compare Immediate 750 ns" >From page 6 here: http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF From osi.superboard at gmail.com Mon Feb 15 06:23:02 2021 From: osi.superboard at gmail.com (osi.superboard) Date: Mon, 15 Feb 2021 12:23:02 +0000 Subject: Programming in 1946 - ENIAC's Birthday In-Reply-To: References: <925261638.1473385.1608145644755.ref@mail.yahoo.com> <925261638.1473385.1608145644755@mail.yahoo.com> Message-ID: <75425832-33fe-d323-3221-7b5497974d3f@gmail.com> 75 years ago, February 15, 1946 The ENIAC, presented to the public in 1946, is - depending on the definition - the first programmable digital computer in the world. Its first programmers were primarily women: so-called refrigerator ladies (seen here: Gloria Ruth Gordon and Ester Gerston) spent hours flipping switches and swapping cable connections - the first computer input devices - to tell the programmable digital computer what it has to do next. https://cdn1.vogel.de/unsafe/fit-in/1000x0/images.vogel.de/vogelonline/bdb/1796600/1796642/original.jpg From dave.g4ugm at gmail.com Mon Feb 15 07:35:05 2021 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Mon, 15 Feb 2021 13:35:05 -0000 Subject: Programming in 1946 - ENIAC's Birthday In-Reply-To: <75425832-33fe-d323-3221-7b5497974d3f@gmail.com> References: <925261638.1473385.1608145644755.ref@mail.yahoo.com> <925261638.1473385.1608145644755@mail.yahoo.com> <75425832-33fe-d323-3221-7b5497974d3f@gmail.com> Message-ID: <083601d7039f$5f044e00$1d0cea00$@gmail.com> > -----Original Message----- > From: cctalk On Behalf Of osi.superboard > via cctalk > Sent: 15 February 2021 12:23 > To: cctalk at classiccmp.org > Subject: Programming in 1946 - ENIAC's Birthday > > 75 years ago, February 15, 1946 > The ENIAC, presented to the public in 1946, is - depending on the definition - > the first programmable digital computer in the world. Its first programmers > were primarily women: so-called refrigerator ladies (seen here: Gloria Ruth > Gordon and Ester Gerston) spent hours flipping switches and swapping cable > connections - the first computer input devices - to tell the programmable > digital computer what it has to do next. If believe that Tom Haigh, Mark Priestley, and Crispin Rope showed that in June? 1948 ENIAC ran the first "Modern" electronic computer program.... They used the banks of switches originally intended to store variable parameters to store the instructions so in effect the program was stored in a "prom" or "rom".. .. I would say the first "electronic programme". About a month later the "Baby" in Manchester ran a program from RAM... Once the machine was, I suppose "micro-coded" they seldom re-plugged it, but simply put the program into the switches. > > https://cdn1.vogel.de/unsafe/fit- > in/1000x0/images.vogel.de/vogelonline/bdb/1796600/1796642/original.jpg Dave G4UGM From mooreericnyc at gmail.com Mon Feb 15 09:07:52 2021 From: mooreericnyc at gmail.com (Eric Moore) Date: Mon, 15 Feb 2021 09:07:52 -0600 Subject: Systems Concepts SC-4 computer In-Reply-To: <7wblcla9r0.fsf@junk.nocrew.org> References: <7wblcla9r0.fsf@junk.nocrew.org> Message-ID: http://mnembler.com/ragooman/computers_mini_products.html You can see some info on the systems (gould SEL) concept line here, but looking at that PDF, systems concepts was something different. -Eric On Mon, Feb 15, 2021, 4:47 AM Lars Brinkhoff via cctalk < cctalk at classiccmp.org> wrote: > Anyone ever heard of the Systems Concepts SC-4 computer? > > "This is an two's-complement 18-bit machine, with 16 general registers > and a 16 level priority interrupt system. Its programming ascpects > are explained in great detail in the SC-4 Reference Manual, of which a > draft is enclosed. Below are times for some typical instructions. > > Add word on stack (not top word) to general register 1.5 us > Multiply general register by memory word 6.2 us > Jump 750 ns > Push and Jump 1.5 us > Compare Immediate 750 ns" > > From page 6 here: > > http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF > From paulkoning at comcast.net Mon Feb 15 09:13:20 2021 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 15 Feb 2021 10:13:20 -0500 Subject: Programming in 1946 - ENIAC's Birthday In-Reply-To: <75425832-33fe-d323-3221-7b5497974d3f@gmail.com> References: <925261638.1473385.1608145644755.ref@mail.yahoo.com> <925261638.1473385.1608145644755@mail.yahoo.com> <75425832-33fe-d323-3221-7b5497974d3f@gmail.com> Message-ID: <415FA8BF-8D67-46B4-AB67-7D7BBD8610D9@comcast.net> > On Feb 15, 2021, at 7:23 AM, osi.superboard via cctalk wrote: > > 75 years ago, February 15, 1946 > The ENIAC, presented to the public in 1946, is - depending on the definition - the first programmable digital computer in the world. Its first programmers were primarily women: so-called refrigerator ladies (seen here: Gloria Ruth Gordon and Ester Gerston) spent hours flipping switches and swapping cable connections - the first computer input devices - Not so much input devices as rather program storage devices. ENIAC wasn't a stored-program machine. And of course read-only program memories have a long history, going back to the Atanasoff-Berry digital computer years earlier, through the ROM of the Electrologica X1 and the Apollo Guidance Computer, to the deadstart panel toggle switch boot ROM of the CDC mainframes. paul From billdegnan at gmail.com Mon Feb 15 09:16:27 2021 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 15 Feb 2021 10:16:27 -0500 Subject: Systems Concepts SC-4 computer In-Reply-To: References: <7wblcla9r0.fsf@junk.nocrew.org> Message-ID: A clue from Dan Roganti's web page or did "they" used to refer to SEL as "Systems" back then and are you saying that the SC=4 is an SEL product? (Systems [engineering labs] - Concept [4] ? Bill On Mon, Feb 15, 2021 at 10:08 AM Eric Moore via cctalk < cctalk at classiccmp.org> wrote: > http://mnembler.com/ragooman/computers_mini_products.html > > You can see some info on the systems (gould SEL) concept line here, but > looking at that PDF, systems concepts was something different. > > -Eric > > > On Mon, Feb 15, 2021, 4:47 AM Lars Brinkhoff via cctalk < > cctalk at classiccmp.org> wrote: > > > Anyone ever heard of the Systems Concepts SC-4 computer? > > > > "This is an two's-complement 18-bit machine, with 16 general registers > > and a 16 level priority interrupt system. Its programming ascpects > > are explained in great detail in the SC-4 Reference Manual, of which a > > draft is enclosed. Below are times for some typical instructions. > > > > Add word on stack (not top word) to general register 1.5 us > > Multiply general register by memory word 6.2 us > > Jump 750 ns > > Push and Jump 1.5 us > > Compare Immediate 750 ns" > > > > From page 6 here: > > > > > http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF > > > From paulkoning at comcast.net Mon Feb 15 09:16:52 2021 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 15 Feb 2021 10:16:52 -0500 Subject: Programming in 1946 - ENIAC's Birthday In-Reply-To: <415FA8BF-8D67-46B4-AB67-7D7BBD8610D9@comcast.net> References: <925261638.1473385.1608145644755.ref@mail.yahoo.com> <925261638.1473385.1608145644755@mail.yahoo.com> <75425832-33fe-d323-3221-7b5497974d3f@gmail.com> <415FA8BF-8D67-46B4-AB67-7D7BBD8610D9@comcast.net> Message-ID: <984E7717-54F7-40C7-8FE1-EAA88BE871AF@comcast.net> > On Feb 15, 2021, at 10:13 AM, Paul Koning via cctalk wrote: > > > >> On Feb 15, 2021, at 7:23 AM, osi.superboard via cctalk wrote: >> >> 75 years ago, February 15, 1946 >> The ENIAC, presented to the public in 1946, is - depending on the definition - the first programmable digital computer in the world. Its first programmers were primarily women: so-called refrigerator ladies (seen here: Gloria Ruth Gordon and Ester Gerston) spent hours flipping switches and swapping cable connections - the first computer input devices - > > Not so much input devices as rather program storage devices. ENIAC wasn't a stored-program machine. That was confusing. I meant that ENIAC wasn't a Von Neumann machine -- the program isn't stored in its data read/write memory. paul From mooreericnyc at gmail.com Mon Feb 15 09:25:10 2021 From: mooreericnyc at gmail.com (Eric Moore) Date: Mon, 15 Feb 2021 09:25:10 -0600 Subject: Systems Concepts SC-4 computer In-Reply-To: References: <7wblcla9r0.fsf@junk.nocrew.org> Message-ID: Yes, SEL was referred to as systems, but like I said that PDF does not seem to be referring to an SEL product. Probably just a coincidence, but maybe not. -Eric On Mon, Feb 15, 2021, 9:16 AM Bill Degnan wrote: > A clue from Dan Roganti's web page or did "they" used to refer to SEL as > "Systems" back then and are you saying that the SC=4 is an SEL product? > (Systems [engineering labs] - Concept [4] ? > > Bill > > On Mon, Feb 15, 2021 at 10:08 AM Eric Moore via cctalk < > cctalk at classiccmp.org> wrote: > >> http://mnembler.com/ragooman/computers_mini_products.html >> >> You can see some info on the systems (gould SEL) concept line here, but >> looking at that PDF, systems concepts was something different. >> >> -Eric >> >> >> On Mon, Feb 15, 2021, 4:47 AM Lars Brinkhoff via cctalk < >> cctalk at classiccmp.org> wrote: >> >> > Anyone ever heard of the Systems Concepts SC-4 computer? >> > >> > "This is an two's-complement 18-bit machine, with 16 general registers >> > and a 16 level priority interrupt system. Its programming ascpects >> > are explained in great detail in the SC-4 Reference Manual, of which a >> > draft is enclosed. Below are times for some typical instructions. >> > >> > Add word on stack (not top word) to general register 1.5 us >> > Multiply general register by memory word 6.2 us >> > Jump 750 ns >> > Push and Jump 1.5 us >> > Compare Immediate 750 ns" >> > >> > From page 6 here: >> > >> > >> http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF >> > >> > From dave.g4ugm at gmail.com Mon Feb 15 09:32:13 2021 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Mon, 15 Feb 2021 15:32:13 -0000 Subject: Programming in 1946 - ENIAC's Birthday In-Reply-To: <984E7717-54F7-40C7-8FE1-EAA88BE871AF@comcast.net> References: <925261638.1473385.1608145644755.ref@mail.yahoo.com> <925261638.1473385.1608145644755@mail.yahoo.com> <75425832-33fe-d323-3221-7b5497974d3f@gmail.com> <415FA8BF-8D67-46B4-AB67-7D7BBD8610D9@comcast.net> <984E7717-54F7-40C7-8FE1-EAA88BE871AF@comcast.net> Message-ID: <096b01d703af$bc47c820$34d75860$@gmail.com> > -----Original Message----- > From: cctalk On Behalf Of Paul Koning via > cctalk > Sent: 15 February 2021 15:17 > To: Paul Koning ; cctalk at classiccmp.org > Subject: Re: Programming in 1946 - ENIAC's Birthday > > > > > On Feb 15, 2021, at 10:13 AM, Paul Koning via cctalk > wrote: > > > > > > > >> On Feb 15, 2021, at 7:23 AM, osi.superboard via cctalk > wrote: > >> > >> 75 years ago, February 15, 1946 > >> The ENIAC, presented to the public in 1946, is - depending on the > definition - the first programmable digital computer in the world. Its first > programmers were primarily women: so-called refrigerator ladies (seen > here: Gloria Ruth Gordon and Ester Gerston) spent hours flipping switches > and swapping cable connections - the first computer input devices - > > > > Not so much input devices as rather program storage devices. ENIAC > wasn't a stored-program machine. > > That was confusing. I meant that ENIAC wasn't a Von Neumann machine -- > the program isn't stored in its data read/write memory. > I think it corresponds more to the "Havard" architecture, but for a machine with "unlimited" memory the two architectures can be shown to be equivalent, in terms of computing capability. > paul > Dave G4UGM From lars at nocrew.org Mon Feb 15 11:01:39 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 15 Feb 2021 17:01:39 +0000 Subject: Systems Concepts SC-4 computer In-Reply-To: (Eric Moore's message of "Mon, 15 Feb 2021 09:07:52 -0600") References: <7wblcla9r0.fsf@junk.nocrew.org> Message-ID: <7wsg5x8du4.fsf@junk.nocrew.org> Lars Brinkhoff wrote: > > Anyone ever heard of the Systems Concepts SC-4 computer? > > "This is an two's-complement 18-bit machine, with 16 general registers > and a 16 level priority interrupt system. Its programming ascpects > are explained in great detail in the SC-4 Reference Manual, of which a > draft is enclosed." > > From page 6 here: > http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF Eric Moore wrote: > http://mnembler.com/ragooman/computers_mini_products.html > You can see some info on the systems (gould SEL) concept line here, but > looking at that PDF, systems concepts was something different. Yes, something different. Systems Concepts was formed by Stewart Nelson and Mike Levitt, made some early equipment for the MIT AI lab PDP-10 computer, and later the successful SA-10 disk controller compatible with IBM disks. In the 80s they went on to make the SC-30M and SC-40 computers which where compatible with DEC's KL10. But this SC-4 computer was apparently something else. From jnc at mercury.lcs.mit.edu Mon Feb 15 11:03:47 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 15 Feb 2021 12:03:47 -0500 (EST) Subject: Systems Concepts SC-4 computer Message-ID: <20210215170347.572E418C097@mercury.lcs.mit.edu> > From: Lars Brinkhoff > Anyone ever heard of the Systems Concepts SC-4 computer? Given the SF address, and Peter Samson's signature, this is the _the_ Systems Concepts. Never heard of the SC-4, though. One oddity: the cover letter is dated 1972, but it talks of "the main G.E. computer". GE's computer business was sold to Honeywell in 1970, though? Noel From mattislind at gmail.com Mon Feb 15 11:08:45 2021 From: mattislind at gmail.com (Mattis Lind) Date: Mon, 15 Feb 2021 18:08:45 +0100 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: I did some more research into this and found that a pattern 0x55509255 for Address mark and 0x55509251 for Data mark could be used to match against the incoming synchronized data stream (pre MFM decoding). These patterns contain the longer flux. I decoded the MFM data after the address mark and both track and sector is visible as what it seems to be valid bit patterns. What is interesting though is that the number of sectors appear to vary among tracks. Track 0 had 128 address marks, while quite many had 81 sectors. Still others had 66 and a few had 121. I studied track 18 more in detail and there were no gaps in the sector count so I guess nothing is missing. Address marks are spaced over the full number of samples (around 65k per revolution). My guess is that the data that follows the sector ID is some kind of checksum. I tried to understand the data field but wasn't very successful. Tried backwards and forwards and with varying bit offsets for both ASCII and EBCDIC. But not a single valid string. Perhaps my decoder had some fault. Will do a deeper study on the data field. I have put some files here if anyone has some insights: https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing Looking a bit further on the *.addressAndData files I see that it seems that the marks should probably contain the first bit of the decoded data that follows, since when MFM decoded data fields always starts with a 1 and address fields always starts with a 0. Including these also makes sense because then the Track and sector will end up on proper 8 bit boundaries. /Mattis Den l?r 13 feb. 2021 kl 21:51 skrev Mattis Lind : > > > Den l?r 13 feb. 2021 kl 21:06 skrev Chuck Guzis : > >> On 2/13/21 11:15 AM, Mattis Lind wrote: >> >> > As to the 8x/5xH intervals, they appear to be part of the >> > preamble to address marks. >> > >> > >> > Can you please elaborate! What do you mean by 8x/5xH intervals? >> > >> > You think that these fluxes are part of some address mark or data mark, >> > right? >> >> By 8x/5xh I mean the intervals that you noted were 84 clocks. Consider >> a part of your sample: >> >> > 00003f0 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 20 1e 20 1d 20 1e | ......... >> . . .| >> > 00000400 20 1e 20 1e 1f 1d 20 1d 20 1e 1f 1e 1f 1e 1f 1e | . ... . >> .......| >> > 00000410 1f 1e 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e |.. >> .............| >> > 00000420 22 20 39 30 1f 2e 1f 1d 20 1e 20 1d 1f 1e 20 1d |" 90.... . >> ... .| >> > 00000430 20 1e 20 1e 20 1d 1f 1e 1f 1e 1f 1e 20 1e 1f 1e | . . >> ....... ...| >> > 00000440 1f 1e 1f 1e 20 1d 20 1e 1f 1e 1f 1d 20 1e 1f 1e |.... . >> ..... ...| >> > 00000450 20 1d 1f 1c 54 2d 30 2e 1f 1d 1f 2f 1f 1d 1f 1d | >> ...T-0..../....| >> > 00000460 30 40 2f 2e 1e 1c 43 1b 44 2d 1e 1e 1f 1e 1f 1e |0@ >> /...C.D-......| >> > 00000470 1f 2f 31 1d 1f 1e 1f 1e 1f 1e 1f 1c 21 1e 1f 1f >> |./1.........!...| >> > 00000480 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1e 1f 1e >> |................| >> > 00000490 1f 1e 1f 1f 1e 1e 1f 1e 1f 1e 1f 1e 1f 1e 1e 1f >> |................| >> > 000004a0 1f 1e 1f 1f 1f 1d 1d 53 2d 2f 2d 1d 42 1d 2e 30 >> |.......S-/-.B..0| >> > 000004b0 2f 1e 1e 1f 1e 1e 30 30 1e 1e 1e 1e 1e 30 2f 1e >> |/.....00.....0/.| >> >> Note that the 54 at 0454 appears to be the preamble to an address mark. >> Similarly, we can see the same here: >> >> > 00000740 20 1e 20 1d 20 1e 20 1e 20 1d 20 1e 20 1d 20 1d | . . . . . >> . . .| >> > 00000750 1f 1e 20 1e 1e 1c 54 2c 30 2e 1f 1d 20 2f 1e 1e |.. >> ...T,0... /..| >> > 00000760 1f 1d 30 40 2f 2e 1f 1d 1f 30 1e 2f 30 1d 1f 1d |..0@ >> /....0./0...| >> > 00000770 31 2e 1e 2f 30 1d 1f 1e 20 1e 1f 1e 1f 1f 27 1e |1../0... >> .....'.| >> > 00000780 30 2f 1d 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f >> |0/..............| >> > 00000790 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f 1e 1f >> |................| >> > 000007a0 1e 1f 1e 1f 1f 1e 1d 53 2d 2f 2e 1d 42 1c 40 42 >> |.......S-/..B. at B| >> > 000007b0 2e 2e 1c 43 2c 2e 41 1c 40 42 2c 2f 2f 1e 30 1e |...C,.A. at B >> ,//.0.| >> > 000007c0 30 1d 30 30 2e 1d 31 1e 1e 1f 1e 31 1d 1d 43 2e >> |0.00..1....1..C.| >> > 000007d0 1d 30 30 1e 1e 1f 1e 1e 30 30 1d 1f 1f 1e 1e 31 >> |.00.....00.....1| >> >> Note the 54 at 0756 at the start of what appears to be an ID address >> mark and the 53 at 07a7 at the start of what appears to be a data >> address mark. >> > > That makes sense. I tried to hand decode the section directly after 0756 > and it decoded fine as mfm. No violations. And I could see something that > could possibly be the value 5 which would then correspond to track 5. Now I > can try to write a piece of software that handles it and see if this gives > something useful. I have a directory listing so somewhere I think I could > match up what I get with that printout. > > /Mattis > > >> --Chuck >> >> >> >> From lars at nocrew.org Mon Feb 15 11:11:46 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 15 Feb 2021 17:11:46 +0000 Subject: Systems Concepts SC-4 computer In-Reply-To: <20210215170347.572E418C097@mercury.lcs.mit.edu> (Noel Chiappa via cctalk's message of "Mon, 15 Feb 2021 12:03:47 -0500 (EST)") References: <20210215170347.572E418C097@mercury.lcs.mit.edu> Message-ID: <7wo8gl8dd9.fsf@junk.nocrew.org> Noel Chiappa wrote: > One oddity: the cover letter is dated 1972, but it talks of "the main > G.E. computer". GE's computer business was sold to Honeywell in 1970, > though? The letter was directed to Project MAC. I suppose that main computer could be the GE-645 on which Multics was developed? And they would still refer to it as G.E. From billdegnan at gmail.com Mon Feb 15 11:26:50 2021 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 15 Feb 2021 12:26:50 -0500 Subject: Systems Concepts SC-4 computer In-Reply-To: <7wo8gl8dd9.fsf@junk.nocrew.org> References: <20210215170347.572E418C097@mercury.lcs.mit.edu> <7wo8gl8dd9.fsf@junk.nocrew.org> Message-ID: On Mon, Feb 15, 2021 at 12:11 PM Lars Brinkhoff via cctalk < cctalk at classiccmp.org> wrote: > Noel Chiappa wrote: > > One oddity: the cover letter is dated 1972, but it talks of "the main > > G.E. computer". GE's computer business was sold to Honeywell in 1970, > > though? > > The letter was directed to Project MAC. I suppose that main computer > could be the GE-645 on which Multics was developed? And they would > still refer to it as G.E. > That's what I was thinking. Bill From jnc at mercury.lcs.mit.edu Mon Feb 15 11:32:13 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 15 Feb 2021 12:32:13 -0500 (EST) Subject: Systems Concepts SC-4 computer Message-ID: <20210215173213.EA0D918C095@mercury.lcs.mit.edu> > From: Lars Brinkhoff > I suppose that main computer could be the GE-645 on which Multics was > developed? And they would still refer to it as G.E. Oh, it was clearly referring to the Multics machine. I assumed that with the GE sale being 1970, by '72 it was not a GE machine anymore. But the MIT Multics site page: https://multicians.org/site-mit.html says the H-6180 was installed in November, 1972; shortly after the letter. Noel From cclist at sydex.com Mon Feb 15 11:41:14 2021 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 15 Feb 2021 09:41:14 -0800 Subject: Systems Concepts SC-4 computer In-Reply-To: <20210215170347.572E418C097@mercury.lcs.mit.edu> References: <20210215170347.572E418C097@mercury.lcs.mit.edu> Message-ID: On 2/15/21 9:03 AM, Noel Chiappa via cctalk wrote: > > From: Lars Brinkhoff > > > Anyone ever heard of the Systems Concepts SC-4 computer? > > Given the SF address, and Peter Samson's signature, this is the _the_ Systems > Concepts. Never heard of the SC-4, though. > > One oddity: the cover letter is dated 1972, but it talks of "the main G.E. > computer". GE's computer business was sold to Honeywell in 1970, though? Honeywell was still servicing old GE mainframes well into the 1970s. When a friend who worked at the plant in Phoenix invited me for a tour ca. 1974, there were still GE systems stashed here and there. --Chuck From mattislind at gmail.com Mon Feb 15 13:33:14 2021 From: mattislind at gmail.com (Mattis Lind) Date: Mon, 15 Feb 2021 20:33:14 +0100 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: Spent some time. Adjusted the MARK sequences to use 55424954 for address mark and 55424945 for data mark. That along with a stupid error in the decoder-code that I fixed now result in some kind of output: CNT: 003BF ADDRESS MARK: 55424954 CNT: 0040F DATA MARK: 55424945 OKEY CHAR (1), V CNT: 006B5 ADDRESS MARK: 55424954 CNT: 00705 DATA MARK: 55424945 P POINTER, VV V CNT: 009B7 ADDRESS MARK: 55424954 CNT: 00A07 DATA MARK: 55424945 D CHAR(6) BASED(P), p V V O CNT: 00CA1 ADDRESS MARK: 55424954 CNT: 00CF2 DATA MARK: 55424945 DATUM CHAR(6), ' V V CNT: 00F87 ADDRESS MARK: 55424954 CNT: 00FD9 DATA MARK: 55424945 PP POINTER, ( V CNT: 01277 ADDRESS MARK: 55424954 CNT: 012C8 DATA MARK: 55424945 1 STR BASED(PP), a V V CNT: 01569 ADDRESS MARK: 55424954 CNT: 015BC DATA MARK: 55424945 2 X CHAR(2), V V$ CNT: 01868 ADDRESS MARK: 55424954 CNT: 018BA DATA MARK: 55424945 2 Y CHAR(2), /* 6 = UKTO, 7 = IKSLAG */ V V V CNT: 01B46 ADDRESS MARK: 55424954 CNT: 01B99 DATA MARK: 55424945 2 FIRMA CHAR (1), ( V CNT: 01E34 ADDRESS MARK: 55424954 CNT: 01E86 DATA MARK: 55424945 2 OP_KOD BINARY, V V CNT: 02120 ADDRESS MARK: 55424954 CNT: 02172 DATA MARK: 55424945 2 RADANT BINARY, V CNT: 02415 ADDRESS MARK: 55424954 CNT: 02466 DATA MARK: 55424945 T4 CHAR(4), V VH CNT: 02713 ADDRESS MARK: 55424954 CNT: 02765 DATA MARK: 55424945 ANTAL_KONT BINARY INIT(0), , V VH CNT: 029FD ADDRESS MARK: 55424954 CNT: 02A4D DATA MARK: 55424945 TOT_ANTAL_KONT BINARY INIT(0), V CNT: 02CD1 ADDRESS MARK: 55424954 CNT: 02D23 DATA MARK: 55424945 VERSION CHAR(47) INIT(' TR10KOLJA Version 1.1 830603'); @ V What is the programming language? Is it PL/1? It seems like a record on the disk is a line! Den m?n 15 feb. 2021 kl 18:08 skrev Mattis Lind : > I did some more research into this and found that a pattern 0x55509255 for > Address mark and 0x55509251 for Data mark could be used to match against > the incoming synchronized data stream (pre MFM decoding). These patterns > contain the longer flux. > > I decoded the MFM data after the address mark and both track and sector is > visible as what it seems to be valid bit patterns. What is interesting > though is that the number of sectors appear to vary among tracks. Track 0 > had 128 address marks, while quite many had 81 sectors. Still others had 66 > and a few had 121. I studied track 18 more in detail and there were no gaps > in the sector count so I guess nothing is missing. Address marks are spaced > over the full number of samples (around 65k per revolution). > > My guess is that the data that follows the sector ID is some kind of > checksum. > > I tried to understand the data field but wasn't very successful. Tried > backwards and forwards and with varying bit offsets for both ASCII and > EBCDIC. But not a single valid string. Perhaps my decoder had some fault. > Will do a deeper study on the data field. > > I have put some files here if anyone has some insights: > https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing > > Looking a bit further on the *.addressAndData files I see that it seems > that the marks should probably contain the first bit of the decoded data > that follows, since when MFM decoded data fields always starts with a 1 and > address fields always starts with a 0. Including these also makes sense > because then the Track and sector will end up on proper 8 bit boundaries. > > > /Mattis > > Den l?r 13 feb. 2021 kl 21:51 skrev Mattis Lind : > >> >> >> Den l?r 13 feb. 2021 kl 21:06 skrev Chuck Guzis : >> >>> On 2/13/21 11:15 AM, Mattis Lind wrote: >>> >>> > As to the 8x/5xH intervals, they appear to be part of the >>> > preamble to address marks. >>> > >>> > >>> > Can you please elaborate! What do you mean by 8x/5xH intervals? >>> > >>> > You think that these fluxes are part of some address mark or data mark, >>> > right? >>> >>> By 8x/5xh I mean the intervals that you noted were 84 clocks. Consider >>> a part of your sample: >>> >>> > 00003f0 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 20 1e 20 1d 20 1e | ......... >>> . . .| >>> > 00000400 20 1e 20 1e 1f 1d 20 1d 20 1e 1f 1e 1f 1e 1f 1e | . ... . >>> .......| >>> > 00000410 1f 1e 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e |.. >>> .............| >>> > 00000420 22 20 39 30 1f 2e 1f 1d 20 1e 20 1d 1f 1e 20 1d |" 90.... >>> . ... .| >>> > 00000430 20 1e 20 1e 20 1d 1f 1e 1f 1e 1f 1e 20 1e 1f 1e | . . >>> ....... ...| >>> > 00000440 1f 1e 1f 1e 20 1d 20 1e 1f 1e 1f 1d 20 1e 1f 1e |.... . >>> ..... ...| >>> > 00000450 20 1d 1f 1c 54 2d 30 2e 1f 1d 1f 2f 1f 1d 1f 1d | >>> ...T-0..../....| >>> > 00000460 30 40 2f 2e 1e 1c 43 1b 44 2d 1e 1e 1f 1e 1f 1e |0@ >>> /...C.D-......| >>> > 00000470 1f 2f 31 1d 1f 1e 1f 1e 1f 1e 1f 1c 21 1e 1f 1f >>> |./1.........!...| >>> > 00000480 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1e 1f 1e >>> |................| >>> > 00000490 1f 1e 1f 1f 1e 1e 1f 1e 1f 1e 1f 1e 1f 1e 1e 1f >>> |................| >>> > 000004a0 1f 1e 1f 1f 1f 1d 1d 53 2d 2f 2d 1d 42 1d 2e 30 >>> |.......S-/-.B..0| >>> > 000004b0 2f 1e 1e 1f 1e 1e 30 30 1e 1e 1e 1e 1e 30 2f 1e >>> |/.....00.....0/.| >>> >>> Note that the 54 at 0454 appears to be the preamble to an address mark. >>> Similarly, we can see the same here: >>> >>> > 00000740 20 1e 20 1d 20 1e 20 1e 20 1d 20 1e 20 1d 20 1d | . . . . >>> . . . .| >>> > 00000750 1f 1e 20 1e 1e 1c 54 2c 30 2e 1f 1d 20 2f 1e 1e |.. >>> ...T,0... /..| >>> > 00000760 1f 1d 30 40 2f 2e 1f 1d 1f 30 1e 2f 30 1d 1f 1d |..0@ >>> /....0./0...| >>> > 00000770 31 2e 1e 2f 30 1d 1f 1e 20 1e 1f 1e 1f 1f 27 1e |1../0... >>> .....'.| >>> > 00000780 30 2f 1d 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f >>> |0/..............| >>> > 00000790 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f 1e 1f >>> |................| >>> > 000007a0 1e 1f 1e 1f 1f 1e 1d 53 2d 2f 2e 1d 42 1c 40 42 >>> |.......S-/..B. at B| >>> > 000007b0 2e 2e 1c 43 2c 2e 41 1c 40 42 2c 2f 2f 1e 30 1e |...C,.A. at B >>> ,//.0.| >>> > 000007c0 30 1d 30 30 2e 1d 31 1e 1e 1f 1e 31 1d 1d 43 2e >>> |0.00..1....1..C.| >>> > 000007d0 1d 30 30 1e 1e 1f 1e 1e 30 30 1d 1f 1f 1e 1e 31 >>> |.00.....00.....1| >>> >>> Note the 54 at 0756 at the start of what appears to be an ID address >>> mark and the 53 at 07a7 at the start of what appears to be a data >>> address mark. >>> >> >> That makes sense. I tried to hand decode the section directly after 0756 >> and it decoded fine as mfm. No violations. And I could see something that >> could possibly be the value 5 which would then correspond to track 5. Now I >> can try to write a piece of software that handles it and see if this gives >> something useful. I have a directory listing so somewhere I think I could >> match up what I get with that printout. >> >> /Mattis >> >> >>> --Chuck >>> >>> >>> >>> From david at kdbarto.org Mon Feb 15 13:39:58 2021 From: david at kdbarto.org (David Barto) Date: Mon, 15 Feb 2021 11:39:58 -0800 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: Yes, that looks very much like PL/1. David > On Feb 15, 2021, at 11:33 AM, Mattis Lind via cctalk wrote: > > Spent some time. Adjusted the MARK sequences to use 55424954 for address > mark and 55424945 for data mark. > > That along with a stupid error in the decoder-code that I fixed now result > in some kind of output: > > CNT: 003BF ADDRESS MARK: 55424954 > > CNT: 0040F DATA MARK: 55424945 OKEY CHAR (1), > V > > CNT: 006B5 ADDRESS MARK: 55424954 > > CNT: 00705 DATA MARK: 55424945 P POINTER, > VV V > > CNT: 009B7 ADDRESS MARK: 55424954 > > CNT: 00A07 DATA MARK: 55424945 D CHAR(6) BASED(P), > p V V O > > CNT: 00CA1 ADDRESS MARK: 55424954 > > CNT: 00CF2 DATA MARK: 55424945 DATUM CHAR(6), > ' V V > > CNT: 00F87 ADDRESS MARK: 55424954 > > CNT: 00FD9 DATA MARK: 55424945 PP POINTER, > ( V > > CNT: 01277 ADDRESS MARK: 55424954 > > CNT: 012C8 DATA MARK: 55424945 1 STR BASED(PP), > a V V > > CNT: 01569 ADDRESS MARK: 55424954 > > CNT: 015BC DATA MARK: 55424945 2 X CHAR(2), > V V$ > > CNT: 01868 ADDRESS MARK: 55424954 > > CNT: 018BA DATA MARK: 55424945 2 Y CHAR(2), /* 6 > = UKTO, 7 = IKSLAG */ V V V > > CNT: 01B46 ADDRESS MARK: 55424954 > > CNT: 01B99 DATA MARK: 55424945 2 FIRMA CHAR (1), > ( V > > CNT: 01E34 ADDRESS MARK: 55424954 > > CNT: 01E86 DATA MARK: 55424945 2 OP_KOD BINARY, > V V > > CNT: 02120 ADDRESS MARK: 55424954 > > CNT: 02172 DATA MARK: 55424945 2 RADANT BINARY, > V > > CNT: 02415 ADDRESS MARK: 55424954 > > CNT: 02466 DATA MARK: 55424945 T4 CHAR(4), > V VH > > CNT: 02713 ADDRESS MARK: 55424954 > > CNT: 02765 DATA MARK: 55424945 ANTAL_KONT BINARY INIT(0), > , V VH > > CNT: 029FD ADDRESS MARK: 55424954 > > CNT: 02A4D DATA MARK: 55424945 TOT_ANTAL_KONT BINARY INIT(0), > V > > CNT: 02CD1 ADDRESS MARK: 55424954 > > CNT: 02D23 DATA MARK: 55424945 VERSION CHAR(47) INIT(' > TR10KOLJA Version > 1.1 830603'); @ V > > > What is the programming language? Is it PL/1? > It seems like a record on the disk is a line! > > > Den m?n 15 feb. 2021 kl 18:08 skrev Mattis Lind : > >> I did some more research into this and found that a pattern 0x55509255 for >> Address mark and 0x55509251 for Data mark could be used to match against >> the incoming synchronized data stream (pre MFM decoding). These patterns >> contain the longer flux. >> >> I decoded the MFM data after the address mark and both track and sector is >> visible as what it seems to be valid bit patterns. What is interesting >> though is that the number of sectors appear to vary among tracks. Track 0 >> had 128 address marks, while quite many had 81 sectors. Still others had 66 >> and a few had 121. I studied track 18 more in detail and there were no gaps >> in the sector count so I guess nothing is missing. Address marks are spaced >> over the full number of samples (around 65k per revolution). >> >> My guess is that the data that follows the sector ID is some kind of >> checksum. >> >> I tried to understand the data field but wasn't very successful. Tried >> backwards and forwards and with varying bit offsets for both ASCII and >> EBCDIC. But not a single valid string. Perhaps my decoder had some fault. >> Will do a deeper study on the data field. >> >> I have put some files here if anyone has some insights: >> https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing >> >> Looking a bit further on the *.addressAndData files I see that it seems >> that the marks should probably contain the first bit of the decoded data >> that follows, since when MFM decoded data fields always starts with a 1 and >> address fields always starts with a 0. Including these also makes sense >> because then the Track and sector will end up on proper 8 bit boundaries. >> >> >> /Mattis >> >> Den l?r 13 feb. 2021 kl 21:51 skrev Mattis Lind : >> >>> >>> >>> Den l?r 13 feb. 2021 kl 21:06 skrev Chuck Guzis : >>> >>>> On 2/13/21 11:15 AM, Mattis Lind wrote: >>>> >>>>> As to the 8x/5xH intervals, they appear to be part of the >>>>> preamble to address marks. >>>>> >>>>> >>>>> Can you please elaborate! What do you mean by 8x/5xH intervals? >>>>> >>>>> You think that these fluxes are part of some address mark or data mark, >>>>> right? >>>> >>>> By 8x/5xh I mean the intervals that you noted were 84 clocks. Consider >>>> a part of your sample: >>>> >>>>> 00003f0 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 20 1e 20 1d 20 1e | ......... >>>> . . .| >>>>> 00000400 20 1e 20 1e 1f 1d 20 1d 20 1e 1f 1e 1f 1e 1f 1e | . ... . >>>> .......| >>>>> 00000410 1f 1e 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e |.. >>>> .............| >>>>> 00000420 22 20 39 30 1f 2e 1f 1d 20 1e 20 1d 1f 1e 20 1d |" 90.... >>>> . ... .| >>>>> 00000430 20 1e 20 1e 20 1d 1f 1e 1f 1e 1f 1e 20 1e 1f 1e | . . >>>> ....... ...| >>>>> 00000440 1f 1e 1f 1e 20 1d 20 1e 1f 1e 1f 1d 20 1e 1f 1e |.... . >>>> ..... ...| >>>>> 00000450 20 1d 1f 1c 54 2d 30 2e 1f 1d 1f 2f 1f 1d 1f 1d | >>>> ...T-0..../....| >>>>> 00000460 30 40 2f 2e 1e 1c 43 1b 44 2d 1e 1e 1f 1e 1f 1e |0@ >>>> /...C.D-......| >>>>> 00000470 1f 2f 31 1d 1f 1e 1f 1e 1f 1e 1f 1c 21 1e 1f 1f >>>> |./1.........!...| >>>>> 00000480 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1e 1f 1e >>>> |................| >>>>> 00000490 1f 1e 1f 1f 1e 1e 1f 1e 1f 1e 1f 1e 1f 1e 1e 1f >>>> |................| >>>>> 000004a0 1f 1e 1f 1f 1f 1d 1d 53 2d 2f 2d 1d 42 1d 2e 30 >>>> |.......S-/-.B..0| >>>>> 000004b0 2f 1e 1e 1f 1e 1e 30 30 1e 1e 1e 1e 1e 30 2f 1e >>>> |/.....00.....0/.| >>>> >>>> Note that the 54 at 0454 appears to be the preamble to an address mark. >>>> Similarly, we can see the same here: >>>> >>>>> 00000740 20 1e 20 1d 20 1e 20 1e 20 1d 20 1e 20 1d 20 1d | . . . . >>>> . . . .| >>>>> 00000750 1f 1e 20 1e 1e 1c 54 2c 30 2e 1f 1d 20 2f 1e 1e |.. >>>> ...T,0... /..| >>>>> 00000760 1f 1d 30 40 2f 2e 1f 1d 1f 30 1e 2f 30 1d 1f 1d |..0@ >>>> /....0./0...| >>>>> 00000770 31 2e 1e 2f 30 1d 1f 1e 20 1e 1f 1e 1f 1f 27 1e |1../0... >>>> .....'.| >>>>> 00000780 30 2f 1d 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f >>>> |0/..............| >>>>> 00000790 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f 1e 1f >>>> |................| >>>>> 000007a0 1e 1f 1e 1f 1f 1e 1d 53 2d 2f 2e 1d 42 1c 40 42 >>>> |.......S-/..B. at B| >>>>> 000007b0 2e 2e 1c 43 2c 2e 41 1c 40 42 2c 2f 2f 1e 30 1e |...C,.A. at B >>>> ,//.0.| >>>>> 000007c0 30 1d 30 30 2e 1d 31 1e 1e 1f 1e 31 1d 1d 43 2e >>>> |0.00..1....1..C.| >>>>> 000007d0 1d 30 30 1e 1e 1f 1e 1e 30 30 1d 1f 1f 1e 1e 31 >>>> |.00.....00.....1| >>>> >>>> Note the 54 at 0756 at the start of what appears to be an ID address >>>> mark and the 53 at 07a7 at the start of what appears to be a data >>>> address mark. >>>> >>> >>> That makes sense. I tried to hand decode the section directly after 0756 >>> and it decoded fine as mfm. No violations. And I could see something that >>> could possibly be the value 5 which would then correspond to track 5. Now I >>> can try to write a piece of software that handles it and see if this gives >>> something useful. I have a directory listing so somewhere I think I could >>> match up what I get with that printout. >>> >>> /Mattis >>> >>> >>>> --Chuck >>>> >>>> >>>> >>>> From cisin at xenosoft.com Mon Feb 15 13:51:18 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 15 Feb 2021 11:51:18 -0800 (PST) Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: On Mon, 15 Feb 2021, Mattis Lind via cctalk wrote: > My guess is that the data that follows the sector ID is some kind of > checksum. yes. well, sorta. 16 bit CRC A typical IBM/WD style format has: a gap Index Address Mark a gap (note that WD can use a shorter post index gap than NEC can) and then, repeated for each sector: { a gap ID Address Mark, C Cylinder number H Head number (0,1) R Sector number N Sector Length (0:128, 1:256, 2:512, 3:1024) 16 bit CRC of the sector header a gap Data Address Mark Sector data (128, 256, 512, or 1024 bytes. Larger is possible, but unlikely) 16 bit CRC of the data a gap } (This is from memory (error prone?). The WD1791 datasheet should have more detail, including CRC algorithm?, the specific requirements for the address marks, and gap contents (write splice, synchronization, etc.)) -- Grumpy Ol' Fred cisin at xenosoft.com From cclist at sydex.com Mon Feb 15 14:13:54 2021 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 15 Feb 2021 12:13:54 -0800 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: <8beb17c2-460f-001f-d5e5-8f2d63cfde5f@sydex.com> On 2/15/21 11:51 AM, Fred Cisin via cctalk wrote: > (This is from memory (error prone?).? The WD1791 datasheet should have > more detail, including CRC algorithm?, the specific requirements for the > address marks, and gap contents (write splice, synchronization, etc.)) The thing to note is that the mark (data or address) is almost always included in the CRC calculation. Also, some early representations could have non-powers of 2 sector lengths. (the WD1781 for example, encoded the length in multiples of 16 bytes; the Zilog MCZ used 132 byte sectors). But they are the exceptions. --Chuck From mattislind at gmail.com Mon Feb 15 14:36:09 2021 From: mattislind at gmail.com (Mattis Lind) Date: Mon, 15 Feb 2021 21:36:09 +0100 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: Den m?n 15 feb. 2021 kl 20:51 skrev Fred Cisin via cctalk < cctalk at classiccmp.org>: > On Mon, 15 Feb 2021, Mattis Lind via cctalk wrote: > > My guess is that the data that follows the sector ID is some kind of > > checksum. > > yes. well, sorta. 16 bit CRC > > > A typical IBM/WD style format has: > > a gap > Index Address Mark > a gap (note that WD can use a shorter post index gap than NEC can) > > and then, repeated for each sector: > { > a gap > ID Address Mark, > C Cylinder number > H Head number (0,1) > R Sector number > N Sector Length (0:128, 1:256, 2:512, 3:1024) > 16 bit CRC of the sector header > a gap > Data Address Mark > Sector data (128, 256, 512, or 1024 bytes. Larger is possible, but > unlikely) > 16 bit CRC of the data > a gap > } > > Well. Now this is NOT a standard 179x that has written this. As I mentioned early on in this thread it was not at all possible to read the disks with a standard controller. The bit rate was off by quite a bit and the general format is different. So this is not necessarily a CRC at all. The machine that has written these is the Q1 Lite computer. A very odd mid-seventies system. http://bitsavers.trailing-edge.com/pdf/q1/Q1_Sales_Brochure.pdf. Here is an example header: CNT: 021D5 ADDRESS MARK: 55424954 00000001 01000101 01000110 00010000 000000V00 00000000 00000000 00000000 00000000 00000000 0V0100100 0V00 "V" is for MFM violation, most likely due to write splicing after the header when enabling writing. This means that the header is at most 4 bytes. First bytes is track, second byte is sector. The third byte appears to be the sum of the track and sector byte. The fourth byte is unknown. In all the tracks it seems to have the same value. /Mattis > (This is from memory (error prone?). The WD1791 datasheet should have > more detail, including CRC algorithm?, the specific requirements for the > address marks, and gap contents (write splice, synchronization, etc.)) > > > -- > Grumpy Ol' Fred cisin at xenosoft.com > From lbickley at bickleywest.com Mon Feb 15 19:18:46 2021 From: lbickley at bickleywest.com (Lyle Bickley) Date: Mon, 15 Feb 2021 17:18:46 -0800 Subject: Systems Concepts SC-4 computer In-Reply-To: <20210215170347.572E418C097@mercury.lcs.mit.edu> References: <20210215170347.572E418C097@mercury.lcs.mit.edu> Message-ID: <20210215171846.4cf5c38f@asrock> On Mon, 15 Feb 2021 12:03:47 -0500 (EST) Noel Chiappa via cctalk wrote: > > From: Lars Brinkhoff > > > Anyone ever heard of the Systems Concepts SC-4 computer? > > Given the SF address, and Peter Samson's signature, this is the _the_ Systems > Concepts. Never heard of the SC-4, though. > > One oddity: the cover letter is dated 1972, but it talks of "the main G.E. > computer". GE's computer business was sold to Honeywell in 1970, though? I contacted Peter Samson regarding a "SC-4" and this was his response: "There was an SC-40 (made after my time there) which was a fast PDP-10-compatible system. I don?t know of any SC-4 though." Cheers, Lyle -- 73 NM6Y Bickley Consulting West https://bickleywest.com "Black holes are where God is dividing by zero" From derschjo at gmail.com Mon Feb 15 19:55:58 2021 From: derschjo at gmail.com (Josh Dersch) Date: Mon, 15 Feb 2021 17:55:58 -0800 Subject: PDP-11/70 progress (and a cry for help) Message-ID: Hi all -- Thought you all might be interested in an update, and I'm also looking for advice in debugging the current issue I'm hitting. After replacing the clock crystal on the TIG, the system started showing signs of life, but the Load Address switch would stop working after being powered on for 10-30 seconds, but would work fine single-stepping via the KM11. Brought the DAP board out onto the extender for debugging and the problem went away. Reinstalled the board after cleaning the slot (again) and the problem hasn't recurred since. First bad backplane connection, I'm sure it won't be the last. After this, addresses could be loaded, data could be toggled into memory. But instructions wouldn't execute; Tracing through the microcode with the KM11 indicated that the microcode flow was aborting early and returning to the main console loop (via BRK.90) before the instruction fetch at FET.00; this was due to the TMCB BRQ TRUE H signal being stuck high. Probing of the TMC board revealed a bad 74H30 at E70, which had its output stuck at 1.65V or so, just high enough to confuse things. Now instructions would execute but the PC would contain garbage after execution of an instruction, after tracing the microcode and staring at the flow diagrams all signs pointed to the PCB register (twin to the PCA register that is used for storing PC data) having trouble. Garbage in the PC after execution was always in bits 6-11, everything else was fine, which pointed to a 74S174 at H47 on the DAP board. Replaced and now instructions execute! Mostly. They seem to execute properly when single-stepping instructions, or running off the RC clock at a clock rate of about 16-20Mhz, any faster than that and things stop working correctly. This is what I'm currently banging my head against -- if anyone has any experience with the 11/70 or wants to stare at the manuals for a bit (and who doesn't?), I'd appreciate any extra input. There are a number of different issues, I'm currently focusing on two-operand instructions that take an immediate argument (MOV #10, R0, or ADD #42, R5) for example. The behavior here is a bit befuddling and I can't quite figure out how it ends up happening, given the microcode. I'll use ADD as a representative example. An ADD #10, R0 instruction (followed by HALT) poked in at address 1000 executes properly -- R0 gets 10 -- but afterwards the PC is corrupted: it contains 2, rather than 1004. In the general case, "ADD #X, R0" ends with PC containing 2 + . (MOV shows the exact same behavior, except that there's no addition, obviously.) This value of PC is shown in the Address lights, as well as when examining the register from the front panel (at 17777707). When single-instruction-stepping the processor this instruction executes perfectly: R0 gets R0+10, PC is 1004 afterwards (both in the Address lights and when examining from the front panel). I have verified with my logic analyzer that when running normally (i.e. not single-stepping) the microcode executes the proper sequence of instructions -- which is the same as executed when single-stepping except at the very end: In FLOWS 4, after the D00.90 instruction executes, a branch is taken to BRK.90, which exits back to the console loop. I don't believe there should be any other differences in execution between the two paths -- other than the branch at the end there are no conditional branches or conditional operations based on whether the CPU is single-stepping or not. There's a signal somewhere in there that has just gone a little bit slow... the trick is finding it. For reference, the microcode sequence (starting at FET.03, see pg. 5 of http://bitsavers.org/pdf/dec/pdp11/1170/MP0KB11-C0_1170engDrw_Nov75.pdf) is: 334 (FET.03) 260 (FET.10) 343 (IRD.00) 022 (S13.01) 027 (S13.10) 205 (D00.90) 260 (FET.10) 343 (IRD.00) 010 (HLT.00) 316 (HLT.10) 164 (FET.04) 240 (BRK.90) 352 (BRK.00) 170 (CON.00) You can see it fetching and executing the ADD instruction, then returning back to FET.10 and executing the next instruction, which is a HALT instruction (because all other memory contains 0 at this point). I believe this is what causes the "+2" portion of the final (incorrect) PC value. (What's extra odd -- literally -- here is that if you start with a "1" in R0, the final PC is 3... seemingly indicating a fetch/execution of an instruction at an odd address, which you'd think would cause a trap instead...) I've been staring at this awhile and I'm puzzled; everything seems to execute properly, the instruction is fetched and decoded, and the immediate value is fetched, the ALU does the right thing and the result is properly stored in R0. And then the PC gets screwed up, and I'm not quite sure how that's possible from looking at the microcode, so I'm not quite sure where to start looking. I sort of suspect the PCB register again, as this is related to the difference in behavior between single-stepping and normal execution: the branch back to the console loop *doesn't* update PCA from PCB, whereas the branch back to the fetch / decode loop does. Anyone have any bright ideas as far as what to poke at? Thanks as always, - Josh From cisin at xenosoft.com Mon Feb 15 20:16:48 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 15 Feb 2021 18:16:48 -0800 (PST) Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: Thanks for the brochure. That looks like a fascinating project! Computerworld mentioned it occasionally in 1980. I love that "Pl/1 will soon emerge as the dominant language of microcomputers" If you haven't already exhausted such leads (apologies if you already have), some trivial GOOGLE'ing turned up the name (and autobiography) of a guy who designed one of their disk controllers: https://onedrive.live.com/?authkey=%21AFZhXO9UdDh2wbg&cid=5982EE6D20F4C106&id=5982EE6D20F4C106%2111901&parId=root&o=OneUp https://www.old-computers.com/museum/forum.asp?c=1286&st=1 https://philosophycentral.org/technology/ Sorry, NO technical details of the controller that he designed. On Mon, 15 Feb 2021, Mattis Lind wrote: > Well. Now this is NOT a standard 179x that has written this. As I mentioned > early on in this thread it was not at all possible to read the disks with a > standard controller. The bit rate was off by quite a bit and the general > format is different. So this is not necessarily a CRC at all. The machine > that has written these is the Q1 Lite computer. A very odd mid-seventies > system. http://bitsavers.trailing-edge.com/pdf/q1/Q1_Sales_Brochure.pdf. From cmhanson at eschatologist.net Mon Feb 15 21:07:30 2021 From: cmhanson at eschatologist.net (Chris Hanson) Date: Mon, 15 Feb 2021 19:07:30 -0800 Subject: WTB: HP 9000-340 memory (HP 98268A), AUI (HP 98235A), SCSI (HP 98658A) Message-ID: <85D8B4D9-B490-456D-A63D-38FA598BBD9D@eschatologist.net> I've acquired an HP 9000-340C+ and I'd like to kit it out with the maximum RAM, SCSI, and AUI rather than thin Ethernet. Desired: - RAM boards: HP 98268A RAM board (three of them to get to 16MB, I'd probably buy extra just to be safe) - AUI LAN board: 98571-66534, aka HP 98235A AUI LAN Upgrade - SCSI board: HP 98658A SCSI Interface Card Anyone have any of this stuff that they might be interested in parting with? I'm also always on the lookout for an HP 98556A 2D/integer graphics accelerator in case anyone happens to have one that needs a home. That's the integer accelerator with a 68020 and some RAM, which piggybacks atop the 98550A (1280x1024 8-bit color card) via its extra Eurocard connector. -- Chris From fritzm at fritzm.org Mon Feb 15 22:01:27 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Mon, 15 Feb 2021 20:01:27 -0800 Subject: PDP-11/70 progress (and a cry for help) In-Reply-To: References: Message-ID: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> Hi Josh, In the situation you describe, I guess I would first chip clip '174s for a slice of both PCA and PBC on the LA, run the troublesome instruction sequence, and look at the trace. Check that CLKPCA H and CLKPCB H are happening when and only when expected, and that all the timing there looks okay. You would also be able to see good-data-clocked-in-but-bad-data-presented on that trace, indicating more failed '174, or see any bad data arriving from the ALU upstream. I'll take a look through the flows after dinner. The "0002" might be one operand used to increment the PC, but the other operand shows up as all zeros because of a bad ALU setup? I guess I'd trace to definitively rule out PCA and PCB first, and then move backward around the chain from there verifying the ALU, ALU muxs, mux sources, etc.? --FritzM. From cz at alembic.crystel.com Mon Feb 15 23:05:37 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 16 Feb 2021 00:05:37 -0500 Subject: TK70 maintenance--fixing capstans and making them work well again In-Reply-To: <255f42ea-c4f3-95c4-df49-4c531439256c@alembic.crystel.com> References: <13273fa7-f84a-3334-de30-abedb1c1dc52@alembic.crystel.com> <255f42ea-c4f3-95c4-df49-4c531439256c@alembic.crystel.com> Message-ID: <69985660-1dc4-27e7-f256-4a19ff1852bc@alembic.crystel.com> Since my last post I've gotten pretty good at getting these tape drives working and I think I see the reasons for a lot of the tape wear: Drag on the capstans. The rear one (tach) is probably the biggest problem, but on 3 of the 4 units I have here (2 TK50, 2 TK70) the bearings are not turning and as a result the capstan is dragging along the bolt at the top, tensioned by the spring on the axle. The result is a lot of drag at best, which will require the unit to apply extra tension to keep the tape moving across the capstan and encoder at a nice 75 inches per second. This translates into more wear at the head, more shedding, and more crap on the heads that people clean till the tape goes south. Also the capstans should "float" on their axles, probably to deal with slightly misaligned tapes. If you push down on the capstan and it doesn't move then it is really bound up and needs a serious cleaning. The solution is to clean out and lubricate the bearings. To do this for the front you can unbolt and remove the capstan. A hint on unbolting: Turn the bolt in a tightening direction and count the rotations before it stops at the bottom of travel. Should be a turn or two. Note this for each capstan, that way you can put the bolt back on at about the same height. Once the capstan is off, you simply wash top and bottom bearings out with 95% isopropyl to get out the old oil and gunk, let it dry, then use watch oil and a watch oiler to put about 6 small drops of oil on the inside bearing face. As the oil seeps into the bearing you will notice you can actually turn it with your oiler. The rear one is a bit more complicated: The bottom bearing holds the encoder wheel on the shaft, so unless you want to take apart the encoder (moderately difficult, I'll write that another day if anyone's interested) focus on the top bearing. Remove the bolt, put a few drops of isopropyl first to loosen up the old oil, let it dry, then put six drops of new oil from an oiler tip on the bearing. It should now turn a *lot* easier. Then assemble, clean off any excess oil, clean the tape head and guide and give it a try. I usually retract the leader before working on all of this to get it out of the way, re-hooking it is pretty simple. The result should be a unit that runs with just enough tension to spin the encoder (good) without drag on the front capstan (better) and minimal extra pressure on the tape head (best). I could probably rebuild these for people if they would want it, what would be a fair price? So far I'm happy: I am able to back up my 300gb ESDI disk on a single tape and the drives are pretty quick all things considered. RT11 backups are easy at 33mb, and I may just load all of my RL02's on tape images so I can have them around. CZ From cc at informatik.uni-stuttgart.de Tue Feb 16 02:54:51 2021 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Tue, 16 Feb 2021 09:54:51 +0100 (CET) Subject: Systems Concepts SC-4 computer In-Reply-To: References: <7wblcla9r0.fsf@junk.nocrew.org> Message-ID: On Mon, 15 Feb 2021, Eric Moore wrote: > Yes, SEL was referred to as systems, but like I said that PDF does not seem I still have problems seeing SEL referred to as something different as "Standard Elektrik Lorenz" (later part of ITT) who made for example the ER56... Christian From derschjo at gmail.com Tue Feb 16 03:13:14 2021 From: derschjo at gmail.com (Josh Dersch) Date: Tue, 16 Feb 2021 01:13:14 -0800 Subject: PDP-11/70 progress (and a cry for help) In-Reply-To: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> References: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> Message-ID: On Mon, Feb 15, 2021 at 8:01 PM Fritz Mueller via cctalk < cctalk at classiccmp.org> wrote: > Hi Josh, > > In the situation you describe, I guess I would first chip clip '174s for a > slice of both PCA and PBC on the LA, run the troublesome instruction > sequence, and look at the trace. Check that CLKPCA H and CLKPCB H are > happening when and only when expected, and that all the timing there looks > okay. > > You would also be able to see good-data-clocked-in-but-bad-data-presented > on that trace, indicating more failed '174, or see any bad data arriving > from the ALU upstream. > > I'll take a look through the flows after dinner. The "0002" might be one > operand used to increment the PC, but the other operand shows up as all > zeros because of a bad ALU setup? I guess I'd trace to definitively rule > out PCA and PCB first, and then move backward around the chain from there > verifying the ALU, ALU muxs, mux sources, etc.? > > --FritzM. > Thanks, Fritz, that's a good idea. I'm a bit short on dip clips at the moment so I had to read PCA and PCB on separate passes (and just the low 6 bits); and right now the clock's still hooked up to RACA CLKA RAR H (which clocks when the ucode ROM address changes) so it's not quite as fine grained as I'd like (I have to move everything around to get the logic analyzer's clock signal hooked up to the main clock and it's just too late tonight...). But still, this is fairly revealing. This is an execution of a MOV #1, R0 instruction poked in at address 40: Addr PCB PCA 334 40 40 260 40 40 343 42 42 022 42 44 027 44 44 205 44 44 260 44 44 343 03 03 010 03 05 316 03 05 164 03 05 240 03 05 352 03 05 170 03 05 (Note that the sample is taken at the beginning of the microinstruction). Based on this, it's clear that things get messed up during 260 (FET.10). The operations performed during this instruction are: t1: BA <- PCB; BC <- DATI t2: t3: BRQ STROBE t4: BUS PAUSE t5: PCA <- PCB + 2 t6 IR <- BUS; BR <- BUS PCB <- PCA t3 FPA <- BA My money's on t5 going wrong -- an ALU input mux or operation being selected incorrectly, possibly. This also somewhat explains why execution doesn't trap due to executing a HALT from an odd address -- it isn't actually executing from the wrong address, because the bus address is loaded from a still-good PCB in t1. More investigation later this week... - Josh From mattislind at gmail.com Tue Feb 16 04:18:01 2021 From: mattislind at gmail.com (Mattis Lind) Date: Tue, 16 Feb 2021 11:18:01 +0100 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: Den tis 16 feb. 2021 kl 03:16 skrev Fred Cisin via cctalk < cctalk at classiccmp.org>: > Thanks for the brochure. > That looks like a fascinating project! > Computerworld mentioned it occasionally in 1980. > > > I love that "Pl/1 will soon emerge as the dominant language of > microcomputers" > > > If you haven't already exhausted such leads (apologies if you already > have), some trivial GOOGLE'ing turned up the name (and autobiography) of a > guy who designed one of their disk controllers: > > https://onedrive.live.com/?authkey=%21AFZhXO9UdDh2wbg&cid=5982EE6D20F4C106&id=5982EE6D20F4C106%2111901&parId=root&o=OneUp I have seen them, except for that one. Quite a rambling story. I only managed to read parts of it. Unfortunately there was little detail of what he did, except that he did everything. A bit interesting to compare the Q1 Story with the one provided by Daniel Alroy. The disk controller probably had some intelligence in itself. It seems to have been connected over sync serial links to the computers. Probably it provided a quite high level interface to the computer. When I analyzed the tracks further I found that track 0 had 40 bytes sectors. Then there were tracks that had 80 character sectors. These were mostly text data on these tracks. A few tracks had sectors with 256 bytes. They seemed to contain binary data. I assume track 0 contains the directory that tells what files go where and the sector size on that track. Supposedly the intelligent floppy controller (more like a file server) knows of the directory structure and file structure of the various types of files there are. In a sense this type of 80 characters record fits very well with classic punch cards. Perhaps data entry was a big application? This type of early distributed systems look a bit like the Cogar 4 / Singer/ICL 1500 systems or Incoterm SPD 10/20. Intelligent terminals with local storage connected to a central storage (file server). > > > https://www.old-computers.com/museum/forum.asp?c=1286&st=1 > > https://philosophycentral.org/technology/ > > > Sorry, NO technical details of the controller that he designed. > > > On Mon, 15 Feb 2021, Mattis Lind wrote: > > Well. Now this is NOT a standard 179x that has written this. As I > mentioned > > early on in this thread it was not at all possible to read the disks > with a > > standard controller. The bit rate was off by quite a bit and the general > > format is different. So this is not necessarily a CRC at all. The machine > > that has written these is the Q1 Lite computer. A very odd mid-seventies > > system. http://bitsavers.trailing-edge.com/pdf/q1/Q1_Sales_Brochure.pdf. > From fritzm at fritzm.org Tue Feb 16 04:36:35 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 16 Feb 2021 02:36:35 -0800 Subject: PDP-11/70 progress (and a cry for help) In-Reply-To: References: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> Message-ID: <8C2F655B-E3EA-4868-BDDC-B3C1BEE9C752@fritzm.org> > On Feb 16, 2021, at 1:13 AM, Josh Dersch wrote: > My money's on t5 going wrong -- an ALU input mux or operation being selected incorrectly, possibly. This also somewhat explains why execution doesn't trap due to executing a HALT from an odd address -- it isn't actually executing from the wrong address, because the bus address is loaded from a still-good PCB in t1. Yes -- that seems to match the observations. So you could set up on t4 or t5 of that microinstruction with the KM11 in single-clock-phase mode, and then have at the ALU with a logic probe to check... There is a small ALU control ROM on the GRA (E74 in the upper left of sheet GRAA), which selects the ALU mode and operation based on lines coming over from the IRC. I had a failure of this part on my 11/45, and ended up with incorrect ALU setup in some circumstances. That part is a 256-bit DM8598 tri-state bipolar mask ROM, and the truth table is on sheet GRAK. Looking back at my notes, I think it was Glen who informed me (on this list, in 2016!) that the Signetics 82S123 PROM could be substituted here. Programmed one up, and it worked, in case you run into the same thing and it is useful info. cheers, --FritzM. From bobsmithofd at gmail.com Tue Feb 16 10:40:29 2021 From: bobsmithofd at gmail.com (Bob Smith) Date: Tue, 16 Feb 2021 11:40:29 -0500 Subject: Systems Concepts SC-4 computer In-Reply-To: References: <7wblcla9r0.fsf@junk.nocrew.org> Message-ID: YEs, SEL purchased by Gould, was Systems Engineering Labs - Their early systems were interesting in the way the I/O bandwidth was much highter than the compute capability. Perfect machine for data collection, and they were sold to many labs. THis continued with their first 32 bit machines. Later, before and after purchase by Gould, they had a more balanced architecture but they sure sucked up power. bob On Tue, Feb 16, 2021 at 3:55 AM Christian Corti via cctalk wrote: > > On Mon, 15 Feb 2021, Eric Moore wrote: > > Yes, SEL was referred to as systems, but like I said that PDF does not seem > > I still have problems seeing SEL referred to as something different as > "Standard Elektrik Lorenz" (later part of ITT) who made for example the > ER56... > > Christian From lars at nocrew.org Tue Feb 16 10:43:01 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 16 Feb 2021 16:43:01 +0000 Subject: Systems Concepts SC-4 computer In-Reply-To: <20210215171846.4cf5c38f@asrock> (Lyle Bickley via cctalk's message of "Mon, 15 Feb 2021 17:18:46 -0800") References: <20210215170347.572E418C097@mercury.lcs.mit.edu> <20210215171846.4cf5c38f@asrock> Message-ID: <7wmtw46k16.fsf@junk.nocrew.org> Lyle Bickley wrote: > I contacted Peter Samson regarding a "SC-4" and this was his response: > > "There was an SC-40 (made after my time there) which was a fast > PDP-10-compatible system. I don?t know of any SC-4 though." Thanks for asking! I'm turning next to Fred Wright, another former Systems Concepts employee. From cclist at sydex.com Tue Feb 16 12:04:37 2021 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 16 Feb 2021 10:04:37 -0800 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> Message-ID: <0829b38f-105a-0f0d-2a22-b4a3e5d754c9@sydex.com> Building floppy controllers from MSI TTL was not uncommon, even after the debut of the WDC LSI chips, which were initially very expensive. Even the bit ordering on some of the early controllers wasn't settled. You can see LSB-first and MSB-first encoded floppies, GCR, MMFM, hard- and soft-sector implementations. There wasn't a strong push toward the IBM implementations (3740/System 3) until the later part of the 70s. All of which can make deciphering of the early floppy formats "interesting". I was surprised in the mid-1970s on a remote console project that I managed to find that the CDC engineers rolled their own UARTs from SSI. Apparently simpler to use off-the-shelf components for a couple-off project than try to justify a part not in the parts crib already that may or may not have a second source. --Chuck From bobsmithofd at gmail.com Tue Feb 16 13:07:11 2021 From: bobsmithofd at gmail.com (Bob Smith) Date: Tue, 16 Feb 2021 14:07:11 -0500 Subject: Deciphering an odd floppy disk format. In-Reply-To: <0829b38f-105a-0f0d-2a22-b4a3e5d754c9@sydex.com> References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> <0829b38f-105a-0f0d-2a22-b4a3e5d754c9@sydex.com> Message-ID: I think by 75 we at DEC hwe had at least two pin compatible source for UART, While CHester G Bell gets credit for the design, my memory is that Vince Bastiani did the design. That set the stage for having the Synchronus /Isochronous chips built too. Signetics was contracted to do the 2652 based on my lineunt design used in the DMC11 (similar to DP8/e and DP11, but ssi chip count reduced and a good bit faster. The SMC chip was based on Frank Zereksi's DU/DUP 11 design. bob On Tue, Feb 16, 2021 at 1:04 PM Chuck Guzis via cctalk wrote: > > Building floppy controllers from MSI TTL was not uncommon, even after > the debut of the WDC LSI chips, which were initially very expensive. > > Even the bit ordering on some of the early controllers wasn't settled. > You can see LSB-first and MSB-first encoded floppies, GCR, MMFM, hard- > and soft-sector implementations. There wasn't a strong push toward the > IBM implementations (3740/System 3) until the later part of the 70s. > > All of which can make deciphering of the early floppy formats "interesting". > > I was surprised in the mid-1970s on a remote console project that I > managed to find that the CDC engineers rolled their own UARTs from SSI. > Apparently simpler to use off-the-shelf components for a couple-off > project than try to justify a part not in the parts crib already that > may or may not have a second source. > > --Chuck From derschjo at gmail.com Tue Feb 16 13:08:28 2021 From: derschjo at gmail.com (Josh Dersch) Date: Tue, 16 Feb 2021 11:08:28 -0800 Subject: PDP-11/70 progress (and a cry for help) In-Reply-To: <8C2F655B-E3EA-4868-BDDC-B3C1BEE9C752@fritzm.org> References: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> <8C2F655B-E3EA-4868-BDDC-B3C1BEE9C752@fritzm.org> Message-ID: On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via cctalk < cctalk at classiccmp.org> wrote: > > > > On Feb 16, 2021, at 1:13 AM, Josh Dersch wrote: > > My money's on t5 going wrong -- an ALU input mux or operation being > selected incorrectly, possibly. This also somewhat explains why execution > doesn't trap due to executing a HALT from an odd address -- it isn't > actually executing from the wrong address, because the bus address is > loaded from a still-good PCB in t1. > > Yes -- that seems to match the observations. So you could set up on t4 or > t5 of that microinstruction with the KM11 in single-clock-phase mode, and > then have at the ALU with a logic probe to check... > I can't, though -- all of this stuff works fine when running slowly :). It's possible that while running in single-clock mode I might be able to see a waveform that's slightly off on the 'scope, if I can pinpoint the failure. Right now I'm thinking it is most likely the AMX selecting the wrong input (I'm guessing that BMX is correctly selecting KOMX, to get the constant "2" for the add operation). > > There is a small ALU control ROM on the GRA (E74 in the upper left of > sheet GRAA), which selects the ALU mode and operation based on lines coming > over from the IRC. I had a failure of this part on my 11/45, and ended up > with incorrect ALU setup in some circumstances. That part is a 256-bit > DM8598 tri-state bipolar mask ROM, and the truth table is on sheet GRAK. > > Looking back at my notes, I think it was Glen who informed me (on this > list, in 2016!) that the Signetics 82S123 PROM could be substituted here. > Programmed one up, and it worked, in case you run into the same thing and > it is useful info. > I think I may have ended up doing a similar substitution with a microcode ROM on my 11/05. Have the 11/70 microcode PROMs been dumped? I had to recreate the 11/05 PROM from the listings in the engineering drawings... - Josh > > cheers, > --FritzM. > > From mattislind at gmail.com Tue Feb 16 13:38:35 2021 From: mattislind at gmail.com (Mattis Lind) Date: Tue, 16 Feb 2021 20:38:35 +0100 Subject: Deciphering an odd floppy disk format. In-Reply-To: <0829b38f-105a-0f0d-2a22-b4a3e5d754c9@sydex.com> References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> <0829b38f-105a-0f0d-2a22-b4a3e5d754c9@sydex.com> Message-ID: Den tis 16 feb. 2021 kl 19:04 skrev Chuck Guzis via cctalk < cctalk at classiccmp.org>: > Building floppy controllers from MSI TTL was not uncommon, even after > the debut of the WDC LSI chips, which were initially very expensive. > I got information from a person that worked for Q1 reseller in Denmark that the floppy controller was built entirely out of TTL chips. No CPU whatsoever. It was interfaced through a parallel bus to the main computer. What is interesting is that it had variable record length. It was specified during the format process which tracks had what number of records and their size. The first track always had 40 bytes record since it was the INDEX track. File allocation was on a track basis. In the INDEX file each file then had a start track and stop track as well as information on how many records there were in the file and what size each record was. Also the number of records per track were included in the file specification. I have never ever heard of such a scheme before. /Mattis From paulkoning at comcast.net Tue Feb 16 13:43:44 2021 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 16 Feb 2021 14:43:44 -0500 Subject: Deciphering an odd floppy disk format. In-Reply-To: References: <8ad4f9c0-172e-f445-ad45-0b064e8d5abc@sydex.com> <9532e740-9c31-0638-6c6d-eccdcbf9dc3f@sydex.com> <0829b38f-105a-0f0d-2a22-b4a3e5d754c9@sydex.com> Message-ID: <0805C044-AA57-4EE3-961E-7CCF218CCBEA@comcast.net> > On Feb 16, 2021, at 2:38 PM, Mattis Lind via cctalk wrote: > > ... > What is interesting is that it had variable record length. It was specified > during the format process which tracks had what number of records and their > size. The first track always had 40 bytes record since it was the INDEX > track. File allocation was on a track basis. In the INDEX file each file > then had a start track and stop track as well as information on how many > records there were in the file and what size each record was. Also the > number of records per track were included in the file specification. > > I have never ever heard of such a scheme before. > > /Mattis I haven't, for floppies. But flexibility even more than that is found in IBM/360 disk drives, where you get to write sectors of variable length, and you don't even have to pick them ahead of time. Not to mention that those have keyed sectors, allowing you to do primitive databases directly in hardware. A similar but more restrictive scheme is the disk drives on the Electrologica X8 (2311 lookalikes, built by CDC I think) where you have a choice of 6 different sector sizes, and you get to make the choice separately for each track, at format time. You can reformat any track at any time. paul From mooreericnyc at gmail.com Tue Feb 16 13:45:37 2021 From: mooreericnyc at gmail.com (Eric Moore) Date: Tue, 16 Feb 2021 13:45:37 -0600 Subject: Systems Concepts SC-4 computer In-Reply-To: References: <7wblcla9r0.fsf@junk.nocrew.org> Message-ID: Or Sugano Electric Laboratory, aka SEL On Tue, Feb 16, 2021, 2:55 AM Christian Corti via cctalk < cctalk at classiccmp.org> wrote: > On Mon, 15 Feb 2021, Eric Moore wrote: > > Yes, SEL was referred to as systems, but like I said that PDF does not > seem > > I still have problems seeing SEL referred to as something different as > "Standard Elektrik Lorenz" (later part of ITT) who made for example the > ER56... > > Christian > From compoobah at gmail.com Tue Feb 16 15:59:32 2021 From: compoobah at gmail.com (Scott Quinn) Date: Tue, 16 Feb 2021 13:59:32 -0800 Subject: IndiZone collections Message-ID: <9c5bc1e7bd19b8224fe93d79cc7588a8d92fc9fd.camel@gmail.com> Curious if anyone on here knows if the contents of any of the earlier IndiZone CDs from SGI are posted? A copy of IndiZone3 came with my copy of IRIX 6.2 a number of years ago, and while the games aren't the sort that would impress a modern XBox user I thought they were kind of neat and showed off the equipment and thoughts of the 1995-era, but I also have some earlier SGIs that would be IndiZone 1/2 era. I found a couple lists of the contest winners (but the CDs have more), and an occasional download link, but nothing complete for either. Anyone have links or lists of what was on them? From phil at ultimate.com Tue Feb 16 16:15:01 2021 From: phil at ultimate.com (Phil Budne) Date: Tue, 16 Feb 2021 17:15:01 -0500 Subject: Systems Concepts SC-4 computer In-Reply-To: <20210215171846.4cf5c38f@asrock> References: <20210215170347.572E418C097@mercury.lcs.mit.edu> <20210215171846.4cf5c38f@asrock> Message-ID: <202102162215.11GMF1td061041@ultimate.com> > > From: Lars Brinkhoff > > > Anyone ever heard of the Systems Concepts SC-4 computer? > Noel Chiappa via cctalk wrote: > > Given the SF address, and Peter Samson's signature, this is the _the_ Systems > > Concepts. Never heard of the SC-4, though. > > > > One oddity: the cover letter is dated 1972, but it talks of "the main G.E. > > computer". GE's computer business was sold to Honeywell in 1970, though? From: Lyle Bickley via cctalk > > I contacted Peter Samson regarding a "SC-4" and this was his response: > > "There was an SC-40 (made after my time there) which was a fast > PDP-10-compatible system. I don?t know of any SC-4 though." The document that raised the question has his name and signature (or the name and signature of *A* Peter R Samson) on it? I suppose one could say that SC-4 might be a marketing term that an engineer might have forgotten, or chosen to have forgotten, but Peter Samson's title in the document is Director of Marketing! The URL again: http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF From fritzm at fritzm.org Tue Feb 16 19:08:27 2021 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 16 Feb 2021 17:08:27 -0800 Subject: PDP-11/70 progress (and a cry for help) In-Reply-To: References: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> <8C2F655B-E3EA-4868-BDDC-B3C1BEE9C752@fritzm.org> Message-ID: > On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via cctalk wrote: > So you could set up on t4 or t5 of that microinstruction with the KM11... > On Feb 16, 2021, at 11:08 AM, Josh Dersch wrote: > I can't, though -- all of this stuff works fine when running slowly :) Oh right -- I keep forgetting that part! So that really does leave you with just the LA to catch things in the act I guess. > Right now I'm thinking it is most likely the AMX selecting the wrong input (I'm guessing that BMX is correctly selecting KOMX, to get the constant "2" for the add operation). I agree; seems a good place to look next. > Have the 11/70 microcode PROMs been dumped? I had to recreate the 11/05 PROM from the listings in the engineering drawings... I am not sure? For the 11/45, I also keyed it in by hand from the engineering drawings, but since it is only a 32x8 bit ROM this was pretty easy. --FritzM. From ethan at 757.org Tue Feb 16 21:41:15 2021 From: ethan at 757.org (Ethan O'Toole) Date: Tue, 16 Feb 2021 22:41:15 -0500 (EST) Subject: IndiZone collections In-Reply-To: <9c5bc1e7bd19b8224fe93d79cc7588a8d92fc9fd.camel@gmail.com> References: <9c5bc1e7bd19b8224fe93d79cc7588a8d92fc9fd.camel@gmail.com> Message-ID: <6fffe4f8-3358-46fe-f327-8790a024bdd4@757.org> Have you checked archive.org? The one site on the internet that didn't whine about posting CD ISOs of a long dead operating system (kudos to them!) If they don't have the ones you have, don't forget to submit them if you would :-) - Ethan > Curious if anyone on here knows if the contents of any of the earlier > IndiZone CDs from SGI are posted? A copy of IndiZone3 came with my copy > of IRIX 6.2 a number of years ago, and while the games aren't the sort > that would impress a modern XBox user I thought they were kind of neat > and showed off the equipment and thoughts of the 1995-era, but I also > have some earlier SGIs that would be IndiZone 1/2 era. I found a couple > lists of the contest winners (but the CDs have more), and an occasional > download link, but nothing complete for either. > Anyone have links or lists of what was on them? > > -- : Ethan O'Toole From jason at textfiles.com Tue Feb 16 21:50:43 2021 From: jason at textfiles.com (Jason Scott) Date: Tue, 16 Feb 2021 22:50:43 -0500 Subject: IndiZone collections In-Reply-To: <6fffe4f8-3358-46fe-f327-8790a024bdd4@757.org> References: <9c5bc1e7bd19b8224fe93d79cc7588a8d92fc9fd.camel@gmail.com> <6fffe4f8-3358-46fe-f327-8790a024bdd4@757.org> Message-ID: Bring it. Bring them all. On Tue, Feb 16, 2021 at 10:41 PM Ethan O'Toole via cctalk < cctalk at classiccmp.org> wrote: > > Have you checked archive.org? The one site on the internet that didn't > whine about posting CD ISOs of a long dead operating system (kudos to > them!) > > If they don't have the ones you have, don't forget to submit them if you > would :-) > > - Ethan > > > Curious if anyone on here knows if the contents of any of the earlier > > IndiZone CDs from SGI are posted? A copy of IndiZone3 came with my copy > > of IRIX 6.2 a number of years ago, and while the games aren't the sort > > that would impress a modern XBox user I thought they were kind of neat > > and showed off the equipment and thoughts of the 1995-era, but I also > > have some earlier SGIs that would be IndiZone 1/2 era. I found a couple > > lists of the contest winners (but the CDs have more), and an occasional > > download link, but nothing complete for either. > > Anyone have links or lists of what was on them? > > > > > > -- > : Ethan O'Toole > > > From lars at nocrew.org Wed Feb 17 01:13:26 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 17 Feb 2021 07:13:26 +0000 Subject: Systems Concepts SC-4 computer In-Reply-To: <202102162215.11GMF1td061041@ultimate.com> (Phil Budne via cctalk's message of "Tue, 16 Feb 2021 17:15:01 -0500") References: <20210215170347.572E418C097@mercury.lcs.mit.edu> <20210215171846.4cf5c38f@asrock> <202102162215.11GMF1td061041@ultimate.com> Message-ID: <7wwnv75fqh.fsf@junk.nocrew.org> Phil Budne wrote: > From: Lyle Bickley via cctalk >> >> I contacted Peter Samson regarding a "SC-4" and this was his response: >> "There was an SC-40 (made after my time there) which was a fast >> PDP-10-compatible system. I don?t know of any SC-4 though." > > The document that raised the question has his name and signature (or > the name and signature of *A* Peter R Samson) on it? > > I suppose one could say that SC-4 might be a marketing term that an > engineer might have forgotten, or chosen to have forgotten, but Peter > Samson's title in the document is Director of Marketing! > > The URL again: > http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF I heard back from Fred Wright: "Although I wasn't at SC in 1972, I'm pretty sure I would have heard of the SC-4 if it had ever existed. The document you linked was just a proposal, and I imagine that that's as far as it ever got. AFAIK, SC didn't create any full-fledged computers between the SC-15 (1970) and the SC-30 (1983)." From derschjo at gmail.com Wed Feb 17 02:45:51 2021 From: derschjo at gmail.com (Josh Dersch) Date: Wed, 17 Feb 2021 00:45:51 -0800 Subject: PDP-11/70 progress (and a cry for help) In-Reply-To: References: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> <8C2F655B-E3EA-4868-BDDC-B3C1BEE9C752@fritzm.org> Message-ID: On Tue, Feb 16, 2021 at 5:08 PM Fritz Mueller via cctalk < cctalk at classiccmp.org> wrote: > > On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via cctalk < > cctalk at classiccmp.org> wrote: > > So you could set up on t4 or t5 of that microinstruction with the KM11... > > > On Feb 16, 2021, at 11:08 AM, Josh Dersch wrote: > > I can't, though -- all of this stuff works fine when running slowly :) > > Oh right -- I keep forgetting that part! So that really does leave you > with just the LA to catch things in the act I guess. > > > Right now I'm thinking it is most likely the AMX selecting the wrong > input (I'm guessing that BMX is correctly selecting KOMX, to get the > constant "2" for the add operation). > > I agree; seems a good place to look next. > I hooked the LA up to the two PROM bits that select the AMX input (RACC UAMX00 H and RACC UAMX01 H), on the ROM & Address Control board. These come from the PROM at U101 and go through a 74S174 at E97 before heading over to the DAP board. And during FET.00 we have: Addr PCB PCA AMX 260 44 44 0 "0" here selects DR (Destination Register) input to the mux and is incorrect; it should be 1 (PCB). During a single-instruction-step run, this value reads out OK on the analyzer. I noted a few other discrepancies in the capture (all of which match the ucode listing during a single-instruction step) which makes me think that the high outputs of the PROM are right on the bleeding-edge of acceptable TTL. I checked out the signal on the scope while running a BR .-1 instruction (which also doesn't execute correctly but at least doesn't halt... I don't have a storage scope to capture this during a single instruction execution) and it looks like the voltage swing is from about 0.15V to 1.7V or so. On the off chance it was the 74S174 at E97 pulling the signals down, I socketed it and substituted a spare '174 in; no change. I also noted that the +5V at this chip was about 4.95V, I goosed it up to 5.10V to see if it made a difference (it did not.) So it seems likely it's the PROM. Looks like I may have some typing to do, though given that the ROM works well enough at slow speeds I might be able to dump it with my Data I/O Model 29 and compare it against the listings in the engineering drawings, to save some time... I'll try to dump the PROM tomorrow and see what I get. - Josh From lbickley at bickleywest.com Wed Feb 17 09:01:17 2021 From: lbickley at bickleywest.com (Lyle Bickley) Date: Wed, 17 Feb 2021 07:01:17 -0800 Subject: Systems Concepts SC-4 computer In-Reply-To: <7wwnv75fqh.fsf@junk.nocrew.org> References: <20210215170347.572E418C097@mercury.lcs.mit.edu> <20210215171846.4cf5c38f@asrock> <202102162215.11GMF1td061041@ultimate.com> <7wwnv75fqh.fsf@junk.nocrew.org> Message-ID: <20210217070117.12b66919@asrock> This was getting long - so I decided to "top post". Sorry ;) Here's Peter Samson's comments after I sent him a copy of the proposal: "Well how about that! (It was never built and the hardware was never designed.) So many ideas and proposals never saw the light of day. I utterly forgot about the SC-4, whatever it was supposed to be." Cheers, Lyle -- On Wed, 17 Feb 2021 07:13:26 +0000 Lars Brinkhoff wrote: > Phil Budne wrote: > > From: Lyle Bickley via cctalk > >> > >> I contacted Peter Samson regarding a "SC-4" and this was his response: > >> "There was an SC-40 (made after my time there) which was a fast > >> PDP-10-compatible system. I don?t know of any SC-4 though." > > > > The document that raised the question has his name and signature (or > > the name and signature of *A* Peter R Samson) on it? > > > > I suppose one could say that SC-4 might be a marketing term that an > > engineer might have forgotten, or chosen to have forgotten, but Peter > > Samson's title in the document is Director of Marketing! > > > > The URL again: > > http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF > > > > I heard back from Fred Wright: > > "Although I wasn't at SC in 1972, I'm pretty sure I would have heard of > the SC-4 if it had ever existed. The document you linked was just a > proposal, and I imagine that that's as far as it ever got. AFAIK, SC > didn't create any full-fledged computers between the SC-15 (1970) and > the SC-30 (1983)." -- 73 NM6Y Bickley Consulting West https://bickleywest.com "Black holes are where God is dividing by zero" From elson at pico-systems.com Wed Feb 17 10:05:56 2021 From: elson at pico-systems.com (Jon Elson) Date: Wed, 17 Feb 2021 10:05:56 -0600 Subject: PDP-11/70 progress (and a cry for help) In-Reply-To: References: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> <8C2F655B-E3EA-4868-BDDC-B3C1BEE9C752@fritzm.org> Message-ID: <602D3EE4.2000008@pico-systems.com> On 02/17/2021 02:45 AM, Josh Dersch via cctalk wrote: > "0" here selects DR (Destination Register) input to the > mux and is incorrect; it should be 1 (PCB). During a > single-instruction-step run, this value reads out OK on > the analyzer. I noted a few other discrepancies in the > capture (all of which match the ucode listing during a > single-instruction step) which makes me think that the > high outputs of the PROM are right on the bleeding-edge of > acceptable TTL. I checked out the signal on the scope > while running a BR .-1 instruction (which also doesn't > execute correctly but at least doesn't halt... I don't > have a storage scope to capture this during a single > instruction execution) and it looks like the voltage swing > is from about 0.15V to 1.7V or so. Well, that sounds like the pull-up transistor on the PROM has gone open or extremely weak. You might try a resistor to +5V and see if that makes it work. It would explain the error only happening at full speed. Jon From macro at orcam.me.uk Wed Feb 17 17:47:16 2021 From: macro at orcam.me.uk (Maciej W. Rozycki) Date: Thu, 18 Feb 2021 00:47:16 +0100 (CET) Subject: Intel Developers' Insight CD-ROM collection archived anywhere? In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020, Glen Slick via cctalk wrote: > > Sadly neither seems to be among the files I have copied. I could yet > > check Intel Dec 1995 Data on Demand discs I happen to have, and do have > > here, but they are cumbersome to handle as they use a proprietary format > > requiring a DOS app to access, and yet more hassle to get anything > > exported (assuming I can recall how I did that many years ago), so it'll > > take a little. > > If you have some Intel "Data on Demand" CD-ROMs it would be nice if > .ISO images of those could be captured and uploaded somewhere. Then > leave it up to anyone interested to deal with extracting documents > from them. Hmm, I'm not sure of the copyright status, even that those were available free of charge. It would be good to have the stuff preserved though, so I'll see if I can get some ack from Intel. I have good experience overall with such enquiries. Ditto about the Insight CDs. > I found this document while looking online. It's not clear to me if > that is a list of documents that are contained on the December 1995 > "Data on Demand" CD-ROMs or if some of those are only available > elsewhere. > > http://alt.ife.tugraz.at/datashts/intel/litguide.pdf This looks to me like a list of orderable hardcopy documents. I still have a long line of those on a bookshelf. But indeed most if not all were available on said CDs, and some were only there. Anyway, sorry to take so long, but such is life. I finally got to my set of Insight CDs and guess what? First that I looked at was October 1996, my oldest, and it does have what you look for: $ ls -la fbldr16*.zip -r-xr-xr-x 1 root root 4619852 Jul 8 1996 fbldr16.zip -r-xr-xr-x 1 root root 1359076 Jul 8 1996 fbldr16a.zip -r-xr-xr-x 1 root root 1253664 Jul 8 1996 fbldr16b.zip -r-xr-xr-x 1 root root 1076370 Jul 8 1996 fbldr16c.zip -r-xr-xr-x 1 root root 930808 Jul 8 1996 fbldr16d.zip $ Do you still need it? I have lost the FTP site I used to host things on and I can't afford the time to set up a new one right away. But I can e-mail you this stuff offlist if your mailbox can swallow it. The choice is either one big file, first in the listing above, or the other four, which are the same contents, split, that I would send in a separate e-mail each. I could split it further too, I know how it worked in the old days. By the look of it all the documentation included with FLASHBuilder is in the form of MS Windows help files rather than PDF. Either way please let me know. Maciej From lars at nocrew.org Thu Feb 18 00:07:24 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 18 Feb 2021 06:07:24 +0000 Subject: Systems Concepts SC-4 computer In-Reply-To: <7wwnv75fqh.fsf@junk.nocrew.org> (Lars Brinkhoff via cctalk's message of "Wed, 17 Feb 2021 07:13:26 +0000") References: <20210215170347.572E418C097@mercury.lcs.mit.edu> <20210215171846.4cf5c38f@asrock> <202102162215.11GMF1td061041@ultimate.com> <7wwnv75fqh.fsf@junk.nocrew.org> Message-ID: <7wzh0152oz.fsf@junk.nocrew.org> > I heard back from Fred Wright: > > "Although I wasn't at SC in 1972, I'm pretty sure I would have heard of > the SC-4 if it had ever existed. The document you linked was just a > proposal, and I imagine that that's as far as it ever got. AFAIK, SC > didn't create any full-fledged computers between the SC-15 (1970) and > the SC-30 (1983)." Following up about the SC-15: "It was a clone of the PDP-15, designed for Information International. The prototype was our main in-house machine for many years. III's main product at the time was the FR-80 microfilm recording machine, initially using PDP-9s and later PDP-15s. Our design let them build their own machines for substantially less than what PDP-15s cost from DEC. We provided designs and prototypes for everything up to the PLS (the Programmable Light Source, a small *very* high-resolution CRT) and camera. I think SC built one SC-15 as part of a system for the Nevada Test Site (while I wasn't here), but most of them were built by III." From ethan at 757.org Fri Feb 19 16:49:15 2021 From: ethan at 757.org (Ethan O'Toole) Date: Fri, 19 Feb 2021 17:49:15 -0500 (EST) Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: References: Message-ID: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> Jumping on thread about older version of Intel dev stuff. My friend has been looking for copies of the Altera/Intel Quartus II software for a while now. Intel pulled every copy from their website and there doesn't seem to be versions online or archived. I assume it is similar issues that others are having with other dev tools from Intel. https://www.intel.com/content/www/us/en/programmable/downloads/download-center.html If anyone has any install bundles below version 13 for Quartus II it would be much appreciated. - Ethan From wrcooke at wrcooke.net Sat Feb 20 07:56:57 2021 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Sat, 20 Feb 2021 07:56:57 -0600 (CST) Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> References: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> Message-ID: <1736829596.265643.1613829417702@email.ionos.com> > On 02/19/2021 4:49 PM Ethan O'Toole via cctech wrote: > > > https://www.intel.com/content/www/us/en/programmable/downloads/download-center.html > > If anyone has any install bundles below version 13 for Quartus II it > would be much appreciated. > > - Ethan I think I have at least ver 12 for Linux. Of course it's pretty big. I can upload it to my web page for download if you like. Let me know. It will be at least tonight or tomorrow morning before I get a chance. Will "A person who never made a mistake never tried anything new." -- Albert Einstein From aek at bitsavers.org Sat Feb 20 12:11:55 2021 From: aek at bitsavers.org (Al Kossow) Date: Sat, 20 Feb 2021 10:11:55 -0800 Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: <1736829596.265643.1613829417702@email.ionos.com> References: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> <1736829596.265643.1613829417702@email.ionos.com> Message-ID: <38659380-8fdb-835f-6e97-d03f1374b11d@bitsavers.org> On 2/20/21 5:56 AM, Will Cooke via cctech wrote: > I think I have at least ver 12 for Linux. Can you still get license keys for the older versions? From derschjo at gmail.com Sun Feb 21 03:33:13 2021 From: derschjo at gmail.com (Josh Dersch) Date: Sun, 21 Feb 2021 01:33:13 -0800 Subject: PDP-11/70 progress (and a cry for help) In-Reply-To: References: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> <8C2F655B-E3EA-4868-BDDC-B3C1BEE9C752@fritzm.org> Message-ID: On Wed, Feb 17, 2021 at 12:45 AM Josh Dersch wrote: > > > I hooked the LA up to the two PROM bits that select the AMX input (RACC > UAMX00 H and RACC UAMX01 H), on the ROM & Address Control board. These > come from the PROM at U101 and go through a 74S174 at E97 before heading > over to the DAP board. And during FET.00 we have: > > Addr PCB PCA AMX > 260 44 44 0 > > "0" here selects DR (Destination Register) input to the mux and is > incorrect; it should be 1 (PCB). During a single-instruction-step run, > this value reads out OK on the analyzer. I noted a few other discrepancies > in the capture (all of which match the ucode listing during a > single-instruction step) which makes me think that the high outputs of the > PROM are right on the bleeding-edge of acceptable TTL. I checked out the > signal on the scope while running a BR .-1 instruction (which also doesn't > execute correctly but at least doesn't halt... I don't have a storage scope > to capture this during a single instruction execution) and it looks like > the voltage swing is from about 0.15V to 1.7V or so. > > On the off chance it was the 74S174 at E97 pulling the signals down, I > socketed it and substituted a spare '174 in; no change. I also noted that > the +5V at this chip was about 4.95V, I goosed it up to 5.10V to see if it > made a difference (it did not.) > > So it seems likely it's the PROM. Looks like I may have some typing to > do, though given that the ROM works well enough at slow speeds I might be > able to dump it with my Data I/O Model 29 and compare it against the > listings in the engineering drawings, to save some time... > > I'll try to dump the PROM tomorrow and see what I get. > > - Josh > A status update here: I've dumped the bad PROM at U101 (and it read out fine on my Data I/O 29, comparing it with the listing in the engineering drawings). A local friend had a spare 11/70 boardset, so while I wait for some (hopefully) NOS bipolar PROMs to arrive, I've installed a spare RAC board. With this installed, instructions execute much better, and after tracing down a faulty Unibus terminator, I got it to run the bootstrap PROM on the M9301! I used my Unibone to boot XXDP+ from an emulated RL02 pack and over the past week I've been running diagnostics and debugging the hardware. Thus far: - Unibus Map registers non-functional: addresses decode but writes have no effect and all reads come back as "0". Replaced bad 8640 bus receiver on the Unibus Map board. - EMKA memory diagnostic hangs the processor in t5 of uAddr 343 (IRD.00), in PAUSE. Traced it down to the HC42 (replaces the original Cache Control Board) board of the Hypercache boardset, lacking any engineering info I swapped this for a spare that I'm fortunate enough to have. The system is now passing all but two diagnostics: - EMKA reports strange errors in banks 50-57 of memory and only with pattern 17; all other banks test fine: MEMORY DATA ERROR PC BANK VADD PADD GOOD BAD XOR MAR BOX MTYPE INT PAT ARRAY 032334 50 157564 05077564 000377 000377 000000 0 ? MJ11 ? 17 ?? 032334 50 156450 05076450 000377 000377 000000 0 ? MJ11 ? 17 ?? 032334 50 155330 05075330 000377 000377 000000 0 ? MJ11 ? 17 ?? 032334 50 154210 05074210 000377 000377 000000 0 ? MJ11 ? 17 ?? 032342 50 154020 05074020 000377 177777 177400 0 ? MJ11 ? 17 ?? 032342 50 153740 05073740 000377 177777 177400 0 ? MJ11 ? 17 ?? 032342 50 153734 05073734 000377 177777 177400 0 ? MJ11 ? 17 ?? 032342 50 153732 05073732 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153730 05073730 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153726 05073726 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153724 05073724 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153722 05073722 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153720 05073720 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153716 05073716 000377 177400 177777 0 ? MJ11 ? 17 ?? Occasionally testing banks 50-57 will die with a trap to 4 instead. Pattern 17 tests using alternating patterns of "0" and "1" bytes, using byte accesses to memory, I'm curious why only this pattern would fail. Accesses to this area of memory from the console work fine - EKBD fails with: ADDRESS MULTIPLEXER, AMX, CPU INPUTS TEST FAILED. ERROR ADDRESS REGISTER NOT SET CORRECTLY. TEST. CALL AT PC. EXPECTED ADRS. GOT ADRS. ERROR REG. 5 00007524 06000000 05777776 144406 (Note the similar address range to the EMKA failures). I've verified that AMX, etc. are not to blame here. I suspect this issue is related to the memory issue above. I've looked at the MMU hardware to see if address generation is breaking for some reason at these addresses and it seems to be OK. I'm going to keep poking at this, but the complexity of the PEP70 memory board plus the lack of hardware docs is going to make this a challenge. If anyone has any bright ideas, let me know. I suppose that worst case I still have a megabyte or so of contiguous working memory; I can modify the memory size jumpers and patch operating systems to ignore the rest. Better than nothing! Anyway: I'm pretty happy with the progress here, I wasn't expecting this to go as smoothly as it has (knock on wood) for a computer in as sad shape as it was. Total carnage here: 4 bad ICs, one dead clock crystal, a dead Unibus terminator, and a marginal HC42 board. And a few slightly dirty backplane fingers... Gives me hope for the 11/45... - Josh From elson at pico-systems.com Sun Feb 21 10:48:16 2021 From: elson at pico-systems.com (Jon Elson) Date: Sun, 21 Feb 2021 10:48:16 -0600 Subject: PDP-11/70 progress (and a cry for help) In-Reply-To: References: <4DDA7707-DDBE-45A2-8CF2-56DDD322ADA5@fritzm.org> <8C2F655B-E3EA-4868-BDDC-B3C1BEE9C752@fritzm.org> Message-ID: <60328ED0.6070302@pico-systems.com> On 02/21/2021 03:33 AM, Josh Dersch via cctalk wrote: > "0" here selects DR (Destination Register) input to the mux and is > incorrect; it should be 1 (PCB). During a single-instruction-step run, > this value reads out OK on the analyzer. I noted a few other discrepancies > in the capture (all of which match the ucode listing during a > single-instruction step) which makes me think that the high outputs of the > PROM are right on the bleeding-edge of acceptable TTL. I checked out the > signal on the scope while running a BR .-1 instruction (which also doesn't > execute correctly but at least doesn't halt... I don't have a storage scope > to capture this during a single instruction execution) and it looks like > the voltage swing is from about 0.15V to 1.7V or so. 1.6 to 1.7 V is the normal internal pull-up of a TTL gate input. It sounds like that is what you are seeing. The PROM can pull low when needed, but has no pull-up working anymore. > On the off chance it was the 74S174 at E97 pulling the signals down, I > socketed it and substituted a spare '174 in; no change. I also noted that > the +5V at this chip was about 4.95V, I goosed it up to 5.10V to see if it > made a difference (it did not.) > > So it seems likely it's the PROM. Looks like I may have some typing to > do, though given that the ROM works well enough at slow speeds I might be > able to dump it with my Data I/O Model 29 and compare it against the > listings in the engineering drawings, to save some time... > > I'll try to dump the PROM tomorrow and see what I get. > > - Josh > > > A status update here: > > I've dumped the bad PROM at U101 (and it read out fine on my Data I/O 29, > comparing it with the listing in the engineering drawings). A local friend > had a spare 11/70 boardset, so while I wait for some (hopefully) NOS > bipolar PROMs to arrive, I've installed a spare RAC board. With this > installed, instructions execute much better, and after tracing down a > faulty Unibus terminator, I got it to run the bootstrap PROM on the M9301! > > I used my Unibone to boot XXDP+ from an emulated RL02 pack and over the > past week I've been running diagnostics and debugging the hardware. Thus > far: > > - Unibus Map registers non-functional: addresses decode but writes have no > effect and all reads come back as "0". Replaced bad 8640 bus receiver on > the Unibus Map board. > - EMKA memory diagnostic hangs the processor in t5 of uAddr 343 (IRD.00), > in PAUSE. Traced it down to the HC42 (replaces the original Cache Control > Board) board of the Hypercache boardset, lacking any engineering info I > swapped this for a spare that I'm fortunate enough to have. > > The system is now passing all but two diagnostics: > - EMKA reports strange errors in banks 50-57 of memory and only with > pattern 17; all other banks test fine: > MEMORY DATA ERROR > PC BANK VADD PADD GOOD BAD XOR MAR BOX MTYPE INT PAT > ARRAY > 032334 50 157564 05077564 000377 000377 000000 0 ? MJ11 ? 17 > ?? > 032334 50 156450 05076450 000377 000377 000000 0 ? MJ11 ? 17 > ?? > 032334 50 155330 05075330 000377 000377 000000 0 ? MJ11 ? 17 > ?? When a memory test reports an error, but the good and bad values are equal, I might suspect bad memory where the program is running from or a CPU error. > 032334 50 154210 05074210 000377 000377 000000 0 ? MJ11 ? 17 > ?? > 032342 50 154020 05074020 000377 177777 177400 0 ? MJ11 ? 17 > ?? > 032342 50 153740 05073740 000377 177777 177400 0 ? MJ11 ? 17 > ?? > 032342 50 153734 05073734 000377 177777 177400 0 ? MJ11 ? 17 > ?? > 032342 50 153732 05073732 000377 177400 177777 0 ? MJ11 ? 17 > ?? > 032342 50 153730 05073730 000377 177400 177777 0 ? MJ11 ? 17 > ?? > 032342 50 153726 05073726 000377 177400 177777 0 ? MJ11 ? 17 > ?? > 032342 50 153724 05073724 000377 177400 177777 0 ? MJ11 ? 17 > ?? > 032342 50 153722 05073722 000377 177400 177777 0 ? MJ11 ? 17 > ?? > 032342 50 153720 05073720 000377 177400 177777 0 ? MJ11 ? 17 > ?? > 032342 50 153716 05073716 000377 177400 177777 0 ? MJ11 ? 17 > ?? And, these look like a byte enable bit might not be getting through and data from the previous test pattern remains in one byte. Jon From wrcooke at wrcooke.net Sat Feb 20 12:43:49 2021 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Sat, 20 Feb 2021 12:43:49 -0600 (CST) Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: <38659380-8fdb-835f-6e97-d03f1374b11d@bitsavers.org> References: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> <1736829596.265643.1613829417702@email.ionos.com> <38659380-8fdb-835f-6e97-d03f1374b11d@bitsavers.org> Message-ID: <1429477478.268824.1613846629291@email.ionos.com> > On 02/20/2021 12:11 PM Al Kossow via cctech wrote: > Can you still get license keys for the older versions? I'm at work right now and not able to verify, but I think at some point they switched to a non-license "free" version that required no license key or perhaps a fixed license key. "A person who never made a mistake never tried anything new." -- Albert Einstein From ethan at 757.org Sun Feb 21 09:23:07 2021 From: ethan at 757.org (Ethan O'Toole) Date: Sun, 21 Feb 2021 10:23:07 -0500 (EST) Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: <1736829596.265643.1613829417702@email.ionos.com> References: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> <1736829596.265643.1613829417702@email.ionos.com> Message-ID: <72c53043-5a74-b7d1-5444-6d3c718bc6d4@757.org> > I think I have at least ver 12 for Linux. Of course it's pretty big. > I can upload it to my web page for download if you like. Let me know. > It will be at least tonight or tomorrow morning before I get a chance. > Will Awesome! That would be great! Thanks! - Ethan From wrcooke at wrcooke.net Sun Feb 21 13:38:37 2021 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Sun, 21 Feb 2021 13:38:37 -0600 (CST) Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: <72c53043-5a74-b7d1-5444-6d3c718bc6d4@757.org> References: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> <1736829596.265643.1613829417702@email.ionos.com> <72c53043-5a74-b7d1-5444-6d3c718bc6d4@757.org> Message-ID: <2136134259.151416.1613936317103@email.ionos.com> > On 02/21/2021 9:23 AM Ethan O'Toole wrote: > > > > I think I have at least ver 12 for Linux. Of course it's pretty big. > > I can upload it to my web page for download if you like. Let me know. > > It will be at least tonight or tomorrow morning before I get a chance. > > Will > Awesome! That would be great! > > Thanks! > > - Ethan I found what seems to be 12.1 Service Pack 1 on my archive drive. There are two of them. I think the second one with "free" in the name is for windows. The other is for Linux. I believe, but I'm not certain, that these were extracted from the download bundle when I got them. I didn't try installing them now, although I'm pretty sure I did when I got them. AT least the LInux one. Anyway, here are the links. If you have any questions let me know. There is also a license file, but I doubt it will be helpful. I will leave these up for at least two or three days. Will http://wrcooke.net/quartus/quartus_12.1sp1.tgz http://wrcooke.net/quartus/quartus_12.1sp1_free.tgz http://wrcooke.net/quartus/license.dat "A person who never made a mistake never tried anything new." -- Albert Einstein From aek at bitsavers.org Sun Feb 21 17:59:48 2021 From: aek at bitsavers.org (Al Kossow) Date: Sun, 21 Feb 2021 15:59:48 -0800 Subject: TI 960 Message-ID: I'm assuming these are 960s Not very often you see paper tape software for them Price is absurd for the mixed bag that is there https://www.ebay.com/itm/Texas-Instruments-Mainframe-Computers-With-Parts-and-Other-Computers/20328577123 From aek at bitsavers.org Sun Feb 21 18:00:36 2021 From: aek at bitsavers.org (Al Kossow) Date: Sun, 21 Feb 2021 16:00:36 -0800 Subject: TI 960 In-Reply-To: References: Message-ID: On 2/21/21 3:59 PM, Al Kossow via cctalk wrote: > I'm assuming these are 960s > Not very often you see paper tape software for them > Price is absurd for the mixed bag that is there > > https://www.ebay.com/itm/Texas-Instruments-Mainframe-Computers-With-Parts-and-Other-Computers/20328577123 https://www.ebay.com/itm/Texas-Instruments-Mainframe-Computers-With-Parts-and-Other-Computers/203285771237 From ethan at 757.org Sun Feb 21 21:59:40 2021 From: ethan at 757.org (Ethan O'Toole) Date: Sun, 21 Feb 2021 22:59:40 -0500 (EST) Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: <2136134259.151416.1613936317103@email.ionos.com> References: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> <1736829596.265643.1613829417702@email.ionos.com> <72c53043-5a74-b7d1-5444-6d3c718bc6d4@757.org> <2136134259.151416.1613936317103@email.ionos.com> Message-ID: > I found what seems to be 12.1 Service Pack 1 on my archive drive. > There are two of them. I think the second one with "free" in the name > is for windows. The other is for Linux. I believe, but I'm not > certain, that these were extracted from the download bundle when I got > them. I didn't try installing them now, although I'm pretty sure I did > when I got them. AT least the LInux one. Awesome! Much thanks for posting those. My friend said they're both Windows, not linux. He added them to his collection but is still on the lookout for "full linux archive of 12." Note - I'm an innocent bystander here. I have an idea what the software is for, but never used it. My friend's twitter thing is https://twitter.com/edgetriggered Thanks again! - Ethan From ethan at 757.org Sun Feb 21 21:59:40 2021 From: ethan at 757.org (Ethan O'Toole) Date: Sun, 21 Feb 2021 22:59:40 -0500 (EST) Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: <2136134259.151416.1613936317103@email.ionos.com> References: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> <1736829596.265643.1613829417702@email.ionos.com> <72c53043-5a74-b7d1-5444-6d3c718bc6d4@757.org> <2136134259.151416.1613936317103@email.ionos.com> Message-ID: > I found what seems to be 12.1 Service Pack 1 on my archive drive. > There are two of them. I think the second one with "free" in the name > is for windows. The other is for Linux. I believe, but I'm not > certain, that these were extracted from the download bundle when I got > them. I didn't try installing them now, although I'm pretty sure I did > when I got them. AT least the LInux one. Awesome! Much thanks for posting those. My friend said they're both Windows, not linux. He added them to his collection but is still on the lookout for "full linux archive of 12." Note - I'm an innocent bystander here. I have an idea what the software is for, but never used it. My friend's twitter thing is https://twitter.com/edgetriggered Thanks again! - Ethan From jwsmail at jwsss.com Sun Feb 21 22:28:49 2021 From: jwsmail at jwsss.com (jim stephens) Date: Sun, 21 Feb 2021 20:28:49 -0800 Subject: TI 960 In-Reply-To: References: Message-ID: <4c04f01e-0b99-d03c-52da-a6e81df7185a@jwsss.com> On 2/21/2021 4:00 PM, Al Kossow via cctalk wrote: > On 2/21/21 3:59 PM, Al Kossow via cctalk wrote: >> I'm assuming these are 960s >> Not very often you see paper tape software for them >> Price is absurd for the mixed bag that is there >> >> https://www.ebay.com/itm/Texas-Instruments-Mainframe-Computers-With-Parts-and-Other-Computers/20328577123 >> > https://www.ebay.com/itm/Texas-Instruments-Mainframe-Computers-With-Parts-and-Other-Computers/203285771237 > > Look at the other auctions.? I wish 11/34s were worth that. Also a Processor tech s100 board with chips "compatable with an apple 1" for 800 bucks. Silent 700 which "can be used with an apple 1" for 999. Must be some rarified air in dyer Indiana.? Or something. I grabbed an IBM M4 which popped up on the FB discussions, but I don't think it was this guy.? And he delivered it to a friend in Evansville.? The seller and systems are in Indiana. thanks Jim From pat at vax11.net Sun Feb 21 22:45:27 2021 From: pat at vax11.net (Patrick Finnegan) Date: Sun, 21 Feb 2021 23:45:27 -0500 Subject: TI 960 In-Reply-To: <4c04f01e-0b99-d03c-52da-a6e81df7185a@jwsss.com> References: <4c04f01e-0b99-d03c-52da-a6e81df7185a@jwsss.com> Message-ID: I got my 029 from the seller and I'm told that I paid too much, but I never see them for sale in reasonable driving distance. I also got a mostly reasonably priced ASR33 He's probably open to offers. He has a garage full of stuff from an estate that he's trying to turn into cash. Patrick Finnegan On Sun, Feb 21, 2021, 23:29 jim stephens via cctalk wrote: > > > On 2/21/2021 4:00 PM, Al Kossow via cctalk wrote: > > On 2/21/21 3:59 PM, Al Kossow via cctalk wrote: > >> I'm assuming these are 960s > >> Not very often you see paper tape software for them > >> Price is absurd for the mixed bag that is there > >> > >> > https://www.ebay.com/itm/Texas-Instruments-Mainframe-Computers-With-Parts-and-Other-Computers/20328577123 > >> > > > https://www.ebay.com/itm/Texas-Instruments-Mainframe-Computers-With-Parts-and-Other-Computers/203285771237 > > > > > Look at the other auctions. I wish 11/34s were worth that. > > Also a Processor tech s100 board with chips "compatable with an apple 1" > for 800 bucks. > > Silent 700 which "can be used with an apple 1" for 999. > > Must be some rarified air in dyer Indiana. Or something. > > I grabbed an IBM M4 which popped up on the FB discussions, but I don't > think it was this guy. And he delivered it to a friend in Evansville. > The seller and systems are in Indiana. > > thanks > Jim > > From cc at informatik.uni-stuttgart.de Mon Feb 22 02:29:42 2021 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Mon, 22 Feb 2021 09:29:42 +0100 (CET) Subject: TI 960 In-Reply-To: References: Message-ID: On Sun, 21 Feb 2021, Al Kossow wrote: > Not very often you see paper tape software for them Unfortunately I haven't found *any* software for the 960, yet. Christian From jbdigriz at dragonsweb.org Mon Feb 22 08:50:18 2021 From: jbdigriz at dragonsweb.org (James B DiGriz) Date: Mon, 22 Feb 2021 09:50:18 -0500 Subject: TI 960 In-Reply-To: References: Message-ID: <20210222095018.1089588c@dragonsweb.org> On Sun, 21 Feb 2021 16:00:36 -0800 Al Kossow via cctalk wrote: > On 2/21/21 3:59 PM, Al Kossow via cctalk wrote: > > I'm assuming these are 960s > > Not very often you see paper tape software for them > > Price is absurd for the mixed bag that is there > > > > https://www.ebay.com/itm/Texas-Instruments-Mainframe-Computers-With-Parts-and-Other-Computers/20328577123 > > > https://www.ebay.com/itm/Texas-Instruments-Mainframe-Computers-With-Parts-and-Other-Computers/203285771237 > Definitely Two 960A's with programmer panels, systems disassembled, no telling how much missing. I see what looks like CRU bus proto boards amidst either spares or the contents of 960 chassis. I do see at least 1 drive of some kind. The racks are nice. Also see DEC, Arete, and AT&T gear in there as well, among other things, some unremarkable, like Dell P4 mobos. This is the seller that wants a grand for the 733 ASR, right? For its "Apple 1" keyboard? Maybe they want $7K here because of the 3b1's keyboard. You'd really have to go see the stuff to get a better idea of what the seller has and what shape it's in, to make some kind of reasonable offer. Hopefully somebody local could do that, if the seller is agreeable. Thanks, jbdigriz From aek at bitsavers.org Mon Feb 22 10:31:55 2021 From: aek at bitsavers.org (Al Kossow) Date: Mon, 22 Feb 2021 08:31:55 -0800 Subject: TI 960 In-Reply-To: References: Message-ID: <5affbac4-7d00-3e86-ff78-26d0ed5fb25e@bitsavers.org> On 2/22/21 12:29 AM, Christian Corti via cctalk wrote: > On Sun, 21 Feb 2021, Al Kossow wrote: >> Not very often you see paper tape software for them > > Unfortunately I haven't found *any* software for the 960, yet. > > Christian I sent him an offer for just the paper tapes. I doubt he'll reply. From unclefalter at yahoo.ca Mon Feb 22 13:31:40 2021 From: unclefalter at yahoo.ca (Brad H) Date: Mon, 22 Feb 2021 19:31:40 +0000 (UTC) Subject: MSI 6800 EPROM Software References: <1162079937.744240.1614022300109.ref@mail.yahoo.com> Message-ID: <1162079937.744240.1614022300109@mail.yahoo.com> Hi there, A longshot I'm sure - but I am wondering if anyone familiar with MSI (Midwest Scentific - SS50 bus system) would happen to have a copy of the software for their 1702A EPROM burner, I think the model is PR-1. I just picked one up and am eager to see if I can use it to read/burn 1702As, something that has been an issue for me for a while now. Many thanks, Brad From jbdigriz at dragonsweb.org Mon Feb 22 13:57:59 2021 From: jbdigriz at dragonsweb.org (James B DiGriz) Date: Mon, 22 Feb 2021 14:57:59 -0500 Subject: TI 960 In-Reply-To: <5affbac4-7d00-3e86-ff78-26d0ed5fb25e@bitsavers.org> References: <5affbac4-7d00-3e86-ff78-26d0ed5fb25e@bitsavers.org> Message-ID: <20210222145759.6fcacddd@dragonsweb.org> On Mon, 22 Feb 2021 08:31:55 -0800 Al Kossow via cctalk wrote: > On 2/22/21 12:29 AM, Christian Corti via cctalk wrote: > > On Sun, 21 Feb 2021, Al Kossow wrote: > >> Not very often you see paper tape software for them > > > > Unfortunately I haven't found *any* software for the 960, yet. > > > > Christian > > I sent him an offer for just the paper tapes. > I doubt he'll reply. > > Please let us know the outcome. If he goes for it, it will greatly increase the odds that *cough* anyone else will make an offer on the rest of it. Especially if he'll throw in the Silent 700 and its stand, and the input card that looks like it belongs with the 960s. I wonder if it may be asking too much to include the 11/34 as well. Certainly clear him some space, though. More room for more liquid merch, I'd think. From cclist at sydex.com Mon Feb 22 18:27:49 2021 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 22 Feb 2021 16:27:49 -0800 Subject: Keys for startech 25U server rack Message-ID: <837c39b0-6ef1-eba5-26e3-03f201ef1726@sydex.com> I dropped by the local e-waste recycler and picked up a Startech 25U server rack for $100. (This one: https://cdn.cnetcontent.com/75/26/75261816-2cf3-43e9-a0b3-1e63752d781e.pdf). Heavy bugger, complete with glass door. I was as surprised as the guy who helped me load it to find that it barely fit in a Gen2 Prius (I left the truck at home). It came with an HP EO4500 PDU, with all 4 power strips (I have no use for this, so if you do, drop me a line. Maybe we can work out something). They also tossed in all of the bags of unused parts. But--no keys! Do all Startech Duraracks use the same key? Anyone know? --Chuck From cctalk at gtaylor.tnetconsulting.net Mon Feb 22 21:36:04 2021 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 22 Feb 2021 20:36:04 -0700 Subject: Keys for startech 25U server rack In-Reply-To: <837c39b0-6ef1-eba5-26e3-03f201ef1726@sydex.com> References: <837c39b0-6ef1-eba5-26e3-03f201ef1726@sydex.com> Message-ID: On 2/22/21 5:27 PM, Chuck Guzis via cctalk wrote: > Do all Startech Duraracks use the same key? Anyone know? I have no idea who uses the same keys. I've found the keys from APC work in multiple vendor's cabinets. So if you have a set, you might give them a try. My experience is that the keys are NOT specific to each cabinet. At least the ones that I've been exposed to over the last 20 years. -- Grant. . . . unix || die From elson at pico-systems.com Mon Feb 22 21:45:24 2021 From: elson at pico-systems.com (Jon Elson) Date: Mon, 22 Feb 2021 21:45:24 -0600 Subject: MSI 6800 EPROM Software In-Reply-To: <1162079937.744240.1614022300109@mail.yahoo.com> References: <1162079937.744240.1614022300109.ref@mail.yahoo.com> <1162079937.744240.1614022300109@mail.yahoo.com> Message-ID: <60347A54.5070803@pico-systems.com> On 02/22/2021 01:31 PM, Brad H via cctalk wrote: > Hi there, > > A longshot I'm sure - but I am wondering if anyone familiar with MSI (Midwest Scentific - SS50 bus system) would happen to have a copy of the software for their 1702A EPROM burner, I think the model is PR-1. I just picked one up and am eager to see if I can use it to read/burn 1702As, something that has been an issue for me for a while now. > > Reading them is pretty easy. BURNING them is crazy. They need an 80 V power supply, and I think you XOR the address or something as you apply the programming voltage. Jon From elson at pico-systems.com Mon Feb 22 22:14:40 2021 From: elson at pico-systems.com (Jon Elson) Date: Mon, 22 Feb 2021 22:14:40 -0600 Subject: ISO IBM flex cables made by Chabin In-Reply-To: <60157B63.3010300@pico-systems.com> References: <60157B63.3010300@pico-systems.com> Message-ID: <60348130.4050903@pico-systems.com> On 01/30/2021 09:29 AM, Jon Elson wrote: > On 01/30/2021 07:29 AM, Al Kossow via cctalk wrote: >> I'm making some replacement cables and paddle cards so >> I'm on the lookout >> for these connectors on cable assemblies. >> >> http://bitsavers.org/pdf/ibm/dasd/21ED/chabin_4.jpg >> >> You'd think there would be piles of them around since >> they were used as >> the interplanar connecting cables in lots of IBM products. >> >> > Oh wow! Yes, I may have some of these laying around > somewhere. I will look, it might be a few days. > I have some Chabin TLC cables that have been cut from the paddle boards. I also have 4 of the SLT-style connectors sawed off of the some paddle boards. Those are quite dirty. I don't know if any of this is of any use to you. But, the contacts inside the connectors might be helpful in reverse-engineering them. Jon From cclist at sydex.com Tue Feb 23 00:06:36 2021 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 22 Feb 2021 22:06:36 -0800 Subject: Keys for startech 25U server rack In-Reply-To: References: <837c39b0-6ef1-eba5-26e3-03f201ef1726@sydex.com> Message-ID: <0973a390-7def-2eec-6964-a73ef13daf34@sydex.com> On 2/22/21 7:36 PM, Grant Taylor via cctalk wrote: > On 2/22/21 5:27 PM, Chuck Guzis via cctalk wrote: >> Do all Startech Duraracks use the same key??? Anyone know? > > I have no idea who uses the same keys. > > I've found the keys from APC work in multiple vendor's cabinets.? So if > you have a set, you might give them a try. > > My experience is that the keys are NOT specific to each cabinet.? At > least the ones that I've been exposed to over the last 20 years. Good enough--I can write the manufacturer for a replacement set without sounding like an idiot. I seem to have inherited the box where all the spare parts were tossed. Lots of brackets that I have no idea what function they perform. The HP PDU was shipped with 10 power strips; which is about 6 too many. Thanks, Chuck From wrcooke at wrcooke.net Tue Feb 23 07:51:44 2021 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Tue, 23 Feb 2021 07:51:44 -0600 (CST) Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: References: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> <1736829596.265643.1613829417702@email.ionos.com> <72c53043-5a74-b7d1-5444-6d3c718bc6d4@757.org> <2136134259.151416.1613936317103@email.ionos.com> Message-ID: <532797379.175082.1614088304708@email.ionos.com> > On 02/21/2021 9:59 PM Ethan O'Toole wrote: > > Awesome! Much thanks for posting those. My friend said they're both > Windows, not linux. He added them to his collection but is still on the > lookout for "full linux archive of 12." > > Note - I'm an innocent bystander here. I have an idea what the software is > for, but never used it. > > My friend's twitter thing is https://twitter.com/edgetriggered > > Thanks again! > > - Ethan Well, let's try again. This one is specifically labeled as Linux, so maybe it's the right one. http://wrcooke.net/quartus/12.1sp1_243_quartus_free_linux.tar.gz Also, feel free to give my email address to your friend. I probably have some other related files stashed away somewhere and would be happy to look for them. Will "A person who never made a mistake never tried anything new." -- Albert Einstein From wrcooke at wrcooke.net Tue Feb 23 07:51:44 2021 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Tue, 23 Feb 2021 07:51:44 -0600 (CST) Subject: Intel/Altera Dev, Seeking Quartus II old versions In-Reply-To: References: <5fb17f5-5587-7b47-35e3-e491cdb31752@757.org> <1736829596.265643.1613829417702@email.ionos.com> <72c53043-5a74-b7d1-5444-6d3c718bc6d4@757.org> <2136134259.151416.1613936317103@email.ionos.com> Message-ID: <532797379.175082.1614088304708@email.ionos.com> > On 02/21/2021 9:59 PM Ethan O'Toole wrote: > > Awesome! Much thanks for posting those. My friend said they're both > Windows, not linux. He added them to his collection but is still on the > lookout for "full linux archive of 12." > > Note - I'm an innocent bystander here. I have an idea what the software is > for, but never used it. > > My friend's twitter thing is https://twitter.com/edgetriggered > > Thanks again! > > - Ethan Well, let's try again. This one is specifically labeled as Linux, so maybe it's the right one. http://wrcooke.net/quartus/12.1sp1_243_quartus_free_linux.tar.gz Also, feel free to give my email address to your friend. I probably have some other related files stashed away somewhere and would be happy to look for them. Will "A person who never made a mistake never tried anything new." -- Albert Einstein From cctalk at gtaylor.tnetconsulting.net Tue Feb 23 11:09:25 2021 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 23 Feb 2021 10:09:25 -0700 Subject: Keys for startech 25U server rack In-Reply-To: <261d7eec.a75f.177cf57ed4b.Webtop.93@btinternet.com> References: <837c39b0-6ef1-eba5-26e3-03f201ef1726@sydex.com> <261d7eec.a75f.177cf57ed4b.Webtop.93@btinternet.com> Message-ID: <8ddaf153-aba1-dfaa-9786-a1a39d08c952@spamtrap.tnetconsulting.net> On 2/23/21 7:43 AM, Joshua Rice wrote: > Deviant Ollam on Youtube does some fantastic lectures/videos on physical > security, and makes it horrifyingly clear how pointless locks and > physical security often is. Locks, of any type, only keep honest people honest. Actually stopping would be bad actors is an entirely different problem. To whit, many locks / enclosures are simply tamper evidence tags. -- Grant. . . . unix || die From cclist at sydex.com Tue Feb 23 18:12:33 2021 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 23 Feb 2021 16:12:33 -0800 Subject: Keys for startech 25U server rack In-Reply-To: <8ddaf153-aba1-dfaa-9786-a1a39d08c952@spamtrap.tnetconsulting.net> References: <837c39b0-6ef1-eba5-26e3-03f201ef1726@sydex.com> <261d7eec.a75f.177cf57ed4b.Webtop.93@btinternet.com> <8ddaf153-aba1-dfaa-9786-a1a39d08c952@spamtrap.tnetconsulting.net> Message-ID: On 2/23/21 9:09 AM, Grant Taylor via cctalk wrote: > On 2/23/21 7:43 AM, Joshua Rice wrote: >> Deviant Ollam on Youtube does some fantastic lectures/videos on >> physical security, and makes it horrifyingly clear how pointless locks >> and physical security often is. > > Locks, of any type, only keep honest people honest. > > Actually stopping would be bad actors is an entirely different problem. > > To whit, many locks / enclosures are simply tamper evidence tags. I did check with Startech and they used to offer replacement keys *with* replacement door locks only. It seems they're out of replacements. For whatever reason, the front and back doors use a double-sided key that's quite different from the side panels, which use what look to be commodity cam locks. Oh well, not that I want to lock this thing, but the side panels use the cam locks as part of the retention mechanism. At least those can be easily and cheaply replaced. --Chuck From jbglaw at lug-owl.de Tue Feb 23 18:16:06 2021 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Wed, 24 Feb 2021 01:16:06 +0100 Subject: VAX 11/750 Message-ID: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> Hi! Just stumbled over https://www.ebay.de/itm/265064917329 . Is it a system somebody of you is offering? Given that it would need to be shipped through Europe and is in unknown condition, I'd probably bid a few Euros on it. MfG, JBG -- From cclist at sydex.com Tue Feb 23 19:02:23 2021 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 23 Feb 2021 17:02:23 -0800 Subject: VAX 11/750 In-Reply-To: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> Message-ID: <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> On 2/23/21 4:16 PM, Jan-Benedict Glaw via cctalk wrote: > Hi! > > Just stumbled over https://www.ebay.de/itm/265064917329 . Is it a > system somebody of you is offering? Given that it would need to be > shipped through Europe and is in unknown condition, I'd probably > bid a few Euros on it. > > MfG, JBG You'd better hurry up--someone's bid ?1.00 already! :) --Chuck From cz at alembic.crystel.com Tue Feb 23 20:53:07 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 23 Feb 2021 21:53:07 -0500 Subject: VAX 11/750 In-Reply-To: <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> Message-ID: Wow, I've always wanted an 11/750. Not sure why, the small box size is impressive and all that. However it doesn't look like that one has a MASSBUS adapter so I will have to pass... And I just gave away a M7850 memory board :-) C On 2/23/2021 8:02 PM, Chuck Guzis via cctalk wrote: > On 2/23/21 4:16 PM, Jan-Benedict Glaw via cctalk wrote: >> Hi! >> >> Just stumbled over https://www.ebay.de/itm/265064917329 . Is it a >> system somebody of you is offering? Given that it would need to be >> shipped through Europe and is in unknown condition, I'd probably >> bid a few Euros on it. >> >> MfG, JBG > > You'd better hurry up--someone's bid ?1.00 already! :) > > --Chuck > From spacewar at gmail.com Tue Feb 23 21:26:47 2021 From: spacewar at gmail.com (Eric Smith) Date: Tue, 23 Feb 2021 20:26:47 -0700 Subject: archive of DEC Notes Message-ID: Does anyone have contact information for the proprietor of this site: http://www.activityclub.org/decnotes/ The site has an index of messages archived from DEC's internal "Notes" (kind of their equivalent of UseNet). It appears from the "Download this site" page that at one time it was possible to download an archive of the actual content, but the hosting used for that only provides one week of free hosting, which has expired. I don't need the entire archive (though I'd like to get it), but I'd especially like to get messages from milkwy::23class_semiconductor and ricks::decschips. From ethan.dicks at gmail.com Tue Feb 23 21:57:05 2021 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Tue, 23 Feb 2021 22:57:05 -0500 Subject: VAX 11/750 In-Reply-To: References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> Message-ID: On Tue, Feb 23, 2021 at 9:53 PM Chris Zach via cctalk wrote: > Wow, I've always wanted an 11/750. Not sure why, the small box size is > impressive and all that. I started on an 11/750 in 1984. They are fantastic little machines. If you only have 3-4 users on them, they are quite peppy. > However it doesn't look like that one has a MASSBUS adapter so I will have to pass... The module map indicates an SI 9400 interface (CMI card to an SI 9xxx SMD disk box) and an L0007, which is an RH750 MASSBUS adapter. Those slots appear to be populated with _something_ in the photo. There _might_ be a MASSBUS connector at the lower-right of the I/O bulkhead. The CPU area seems to show an FP750 Floating Point accelerator installed in slot 1. It also appears there are a couple of cards in the memory area in slots 6 and 8. What I don't know, since I didn't have one, is how you load up a machine with an L0022 14MB memory controller, but it's _possible_ we are looking at 4x 1MB + 2x 4MB (full boat). It also appears that the two DZ11s may still be installed, but the TC-131 might be missing. > And I just gave away a M7850 memory board :-) Indeed you did, well an M8750 anyway. ;-) Cheers, -ethan From shumaker at att.net Tue Feb 23 22:08:47 2021 From: shumaker at att.net (s shumaker) Date: Tue, 23 Feb 2021 20:08:47 -0800 Subject: archive of DEC Notes In-Reply-To: References: Message-ID: On 2/23/2021 7:26 PM, Eric Smith via cctalk wrote: > Does anyone have contact information for the proprietor of this site: > http://www.activityclub.org/decnotes/ > The site has an index of messages archived from DEC's internal "Notes" > (kind of their equivalent of UseNet). > > It appears from the "Download this site" page that at one time it was > possible to download an archive of the actual content, but the hosting used > for that only provides one week of free hosting, which has expired. > > I don't need the entire archive (though I'd like to get it), but I'd > especially like to get messages from milkwy::23class_semiconductor and > ricks::decschips. wayback machine has this available http://www.activityclub.org/decnotes/ Steve From jwsmail at jwsss.com Tue Feb 23 22:29:42 2021 From: jwsmail at jwsss.com (jim stephens) Date: Tue, 23 Feb 2021 20:29:42 -0800 Subject: archive of DEC Notes In-Reply-To: References: Message-ID: <023e08f0-7516-90d8-0198-8e0f16350abf@jwsss.com> On 2/23/2021 8:08 PM, s shumaker via cctalk wrote: >> > wayback machine has this available > > http://www.activityclub.org/decnotes/ I may be missing something, but the download this site has an expired wetransfer link.?? Archive.org when you navigate to that page, says "available on the web, not archived" (essentially).? In other words it didn't grab the transfer image when it was live and likely would only have the useless link to the dead transfer. That search box might not be useful, that's the only thing I saw. Even though Bitsavers was pulled across w/o the requested capture of the capability to navigate it like a hierarchical file system by archive.org (If I understand what is lacking there), at least all the bitsavers content is visible on a document level and is all captured. sites that use devices which need backend code to fetch up stuff won't go into archive.org unless someone makes a script an gets it to be activate on archive.org. Would be nice to have a download of that info. thanks Jim From cz at alembic.crystel.com Tue Feb 23 23:11:07 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Wed, 24 Feb 2021 00:11:07 -0500 Subject: SaturnCalc, Graph, and WP disks uploaded Message-ID: Hi all! Spent some serious time this evening with the RX02 drives: I managed to download the images of the SaturnCalc 3.0, Saturn Graph, and Saturn WP software to RX02 images. I think it's set right, can someone take a look at the images and see if they are good? Should be RT11 format, RX02 (of course), I recorded from both sides of the disks (they're double sided, hole punched by the vendor) and are at https://www.crystel.com/bob You should see the disks and the meta files. Let me know if they work, I need to get to bed. Either burn them on real RX02's or read them with a SIMH image. C From boris at summitclinic.com Tue Feb 23 23:44:57 2021 From: boris at summitclinic.com (Boris Gimbarzevsky) Date: Tue, 23 Feb 2021 21:44:57 -0800 Subject: PDP11 (Qbus) boards available Message-ID: <20210224054523.9AEDE4E74C@mx2.ezwind.net> Have been told by my wife that PDP-11 stuff not coming along with us when we're moving and so time to get it off to a good home. All of it is QBus and material in first batch is what I've got at home and will try to get pictures of another 2 systems in storage locker this week. Locker contains 2 QBus systems, one is a small system with about 64 Kb of RAM and other is larger, also a Qbus system. I powered them up when I got them but that was close to 30 years ago so power supplies will need to be checked out first. Also have a small 4 slot Qbus card cage H9281 which has a DRV11 board in it (photo not shown). Pictures, in order, are 4 channel 12 bit D/A converter, unknown QBus board, programmable real time clock, what I thought was manual for DataTranslation A/D converter but not, A/D converter, have no idea what Dilog board is, box of DEC cables, a few manuals, MINC manuals, 11/23 together with I suspect is a DRV11, not sure what board with bus extensions on top is, bus extender, blank 2 slot board and another board which was part of a parallel interface between MINC and 11/34. Would preferably like to get rid of everything at once. Haven't looked at cost of shipping out of Canada. Alternatively, send me an email off list is you want to pick it up in person. I live in Kamloops, BC. Photographs can be found at: http://drgimbarzevsky.com/Photo2020/PDP11/20210223_photos/PDP11_index.html Boris Gimbarzevsky From jwsmail at jwsss.com Wed Feb 24 00:01:50 2021 From: jwsmail at jwsss.com (jim stephens) Date: Tue, 23 Feb 2021 22:01:50 -0800 Subject: PDP11 (Qbus) boards available In-Reply-To: <20210224054523.9AEDE4E74C@mx2.ezwind.net> References: <20210224054523.9AEDE4E74C@mx2.ezwind.net> Message-ID: On 2/23/2021 9:44 PM, Boris Gimbarzevsky via cctalk wrote: > Boris Gimbarzevsky Boris, it looks like a hex high board is hiding behind the KDF (processor) board and the Data Translation adapter. http://drgimbarzevsky.com/Photo2020/PDP11/20210223_photos/20210223_173156.jpg Any idea what is hiding in the anti stat bag?? One missed, or just in other photos?? Only reason to be curious is it might be hex high. From boris at summitclinic.com Wed Feb 24 00:05:43 2021 From: boris at summitclinic.com (Boris Gimbarzevsky) Date: Tue, 23 Feb 2021 22:05:43 -0800 Subject: PDP11 (Qbus) boards available In-Reply-To: References: <20210224054523.9AEDE4E74C@mx2.ezwind.net> Message-ID: <20210224060553.A5F532743B@mx1.ezwind.net> Jim, that's the board whose picture is 20210223_173156.jpg Not sure what it is - just remember grabbing any QBus boards at UBC SERF with plans to use them sometime. Boris >On 2/23/2021 9:44 PM, Boris Gimbarzevsky via cctalk wrote: >>Boris Gimbarzevsky >Boris, it looks like a hex high board is hiding >behind the KDF (processor) board and the Data Translation adapter. > >http://drgimbarzevsky.com/Photo2020/PDP11/20210223_photos/20210223_173156.jpg > >Any idea what is hiding in the anti stat >bag?? One missed, or just in other >photos?? Only reason to be curious is it might be hex high. > > From jwsmail at jwsss.com Wed Feb 24 00:34:01 2021 From: jwsmail at jwsss.com (jim stephens) Date: Tue, 23 Feb 2021 22:34:01 -0800 Subject: PDP11 (Qbus) boards available In-Reply-To: <20210224060553.A5F532743B@mx1.ezwind.net> References: <20210224054523.9AEDE4E74C@mx2.ezwind.net> <20210224060553.A5F532743B@mx1.ezwind.net> Message-ID: On 2/23/2021 10:05 PM, Boris Gimbarzevsky via cctalk wrote: > Jim, that's the board whose picture is 20210223_173156.jpg > Not sure what it is - just remember grabbing any QBus boards at UBC > SERF with plans to use them sometime. > Boris Interesting it has ACT logo on it.? It's an Able Qniverter.? You plug it into the qubus.? You can then connect a Unibus bridge to the two connectors. https://ia800604.us.archive.org/23/items/able_qnivertermanual/Able_QniverterManual_text.pdf http://www.bitsavers.org/pdf/able/Able_QniverterManual_text.pdf http://www.bitsavers.org/pdf/able/Able_QniverterManual.pdf Annoying the Archive.org version is found before the Bitsavers, and the text version to boot. Attention Josh Dersch. thanks Jim From boris at summitclinic.com Wed Feb 24 00:40:29 2021 From: boris at summitclinic.com (Boris Gimbarzevsky) Date: Tue, 23 Feb 2021 22:40:29 -0800 Subject: PDP11 (Qbus) boards available In-Reply-To: References: <20210224054523.9AEDE4E74C@mx2.ezwind.net> <20210224060553.A5F532743B@mx1.ezwind.net> Message-ID: <20210224064625.C8C674E792@mx2.ezwind.net> Thanks Jim. Now I remember getting it just for that purpose. Was looking at photos I took of boards when I moved out of Vancouver 11 years ago and thought there were a couple of Unibus boards in them which was odd. Have to look at dates on photos as need to see if it was before or after Glen Slick picked up my MINC and RLO2's. Have to admit that my PDP-11 days are in the past so can let someone else have the fun. Boris >On 2/23/2021 10:05 PM, Boris Gimbarzevsky via cctalk wrote: >>Jim, that's the board whose picture is 20210223_173156.jpg >>Not sure what it is - just remember grabbing >>any QBus boards at UBC SERF with plans to use them sometime. >>Boris >Interesting it has ACT logo on it.? It's an >Able Qniverter.? You plug it into the >qubus.? You can then connect a Unibus bridge to the two connectors. > >https://ia800604.us.archive.org/23/items/able_qnivertermanual/Able_QniverterManual_text.pdf > >http://www.bitsavers.org/pdf/able/Able_QniverterManual_text.pdf >http://www.bitsavers.org/pdf/able/Able_QniverterManual.pdf > >Annoying the Archive.org version is found before >the Bitsavers, and the text version to boot. > >Attention Josh Dersch. > >thanks >Jim From trash80 at internode.on.net Wed Feb 24 00:59:31 2021 From: trash80 at internode.on.net (Kevin Parker) Date: Wed, 24 Feb 2021 17:59:31 +1100 Subject: List your old computer Message-ID: <08a001d70a7a$9a705560$cf510020$@internode.on.net> Hi folks - there used to be a web site where you could register and list your "classic/old computer(s)". I'm not looking to do that but am trying to find something from years gone by that I think was on that site. I thought it was https://www.old-computers.com/ or http://oldcomputers.net/ but it's neither of those. My googlefoo has been unable to track it down assuming it still exists. I know at one stage the owner was thinking of closing it down because of hacks or spamming of forms or something like that. Does this ring a bell with anyone? Thank you!! Kevin Parker From trash80 at internode.on.net Wed Feb 24 01:02:19 2021 From: trash80 at internode.on.net (Kevin Parker) Date: Wed, 24 Feb 2021 18:02:19 +1100 Subject: FW: List your old computer In-Reply-To: <08a001d70a7a$9a705560$cf510020$@internode.on.net> References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> Message-ID: <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> My apologies for the tracker embedded in my original post. I use it for my business and forgot to remove it before posting to this list. Kevin Parker -----Original Message----- From: cctalk On Behalf Of Kevin Parker via cctalk Sent: Wednesday, 24 February 2021 6:00 PM To: 'General Discussion: On-Topic and Off-Topic Posts' Subject: List your old computer Hi folks - there used to be a web site where you could register and list your "classic/old computer(s)". I'm not looking to do that but am trying to find something from years gone by that I think was on that site. I thought it was https://www.old-computers.com/ or http://oldcomputers.net/ but it's neither of those. My googlefoo has been unable to track it down assuming it still exists. I know at one stage the owner was thinking of closing it down because of hacks or spamming of forms or something like that. Does this ring a bell with anyone? Thank you!! Kevin Parker From cz at alembic.crystel.com Wed Feb 24 01:41:47 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Wed, 24 Feb 2021 02:41:47 -0500 Subject: PDP11 (Qbus) boards available In-Reply-To: <20210224064625.C8C674E792@mx2.ezwind.net> References: <20210224054523.9AEDE4E74C@mx2.ezwind.net> <20210224060553.A5F532743B@mx1.ezwind.net> <20210224064625.C8C674E792@mx2.ezwind.net> Message-ID: Interesting. I have a Plessy Quniverter and it looks a bit different. Handy device though. I would be interested in that GTSC manual, I have one of those boards, don't see one in your stash. With the manual I could probably figure out how to make an RSX driver and stop entering the date and time all the time :-) C On 2/24/2021 1:40 AM, Boris Gimbarzevsky via cctalk wrote: > Thanks Jim. > Now I remember getting it just for that purpose.? Was looking at photos > I took of boards when I moved out of Vancouver 11 years ago and thought > there were a couple of Unibus boards in them which was odd.? Have to > look at dates on photos as need to see if it was before or after Glen > Slick picked up my MINC and RLO2's.? Have to admit that my PDP-11 days > are in the past so can let someone else have the fun. > > Boris > > > >> On 2/23/2021 10:05 PM, Boris Gimbarzevsky via cctalk wrote: >>> Jim, that's the board whose picture is 20210223_173156.jpg >>> Not sure what it is - just remember grabbing any QBus boards at UBC >>> SERF with plans to use them sometime. >>> Boris >> Interesting it has ACT logo on it.?? It's an Able Qniverter.?? You >> plug it into the qubus.?? You can then connect a Unibus bridge to the >> two connectors. >> >> https://ia800604.us.archive.org/23/items/able_qnivertermanual/Able_QniverterManual_text.pdf >> >> >> http://www.bitsavers.org/pdf/able/Able_QniverterManual_text.pdf >> http://www.bitsavers.org/pdf/able/Able_QniverterManual.pdf >> >> Annoying the Archive.org version is found before the Bitsavers, and >> the text version to boot. >> >> Attention Josh Dersch. >> >> thanks >> Jim > > From frank at tuccio.net Tue Feb 23 15:45:59 2021 From: frank at tuccio.net (Frank Tuccio) Date: Tue, 23 Feb 2021 16:45:59 -0500 Subject: : Re: MSI 6800 EPROM Software Message-ID: <001e01d70a2d$479b38c0$d6d1aa40$@tuccio.net> Message: 5 Date: Mon, 22 Feb 2021 21:45:24 -0600 From: Jon Elson To: Brad H , General at ezwind.net, Discussion at ezwind.net:On-Topic and Off-Topic Posts Subject: Re: MSI 6800 EPROM Software Message-ID: <60347A54.5070803 at pico-systems.com> Content-Type: text/plain; charset=UTF-8; format=flowed On 02/22/2021 01:31 PM, Brad H via cctalk wrote: > Hi there, > > A longshot I'm sure - but I am wondering if anyone familiar with MSI (Midwest Scentific - SS50 bus system) would happen to have a copy of the software for their 1702A EPROM burner, I think the model is PR-1. I just picked one up and am eager to see if I can use it to read/burn 1702As, something that has been an issue for me for a while now. > > Reading them is pretty easy. BURNING them is crazy. They need an 80 V power supply, and I think you XOR the address or something as you apply the programming voltage. Jon Actually, programming a 1702 only requires a -48 volt pulse for each address. Here's the datasheet: https://www.jmargolin.com/patents/1702a.pdf From bhilpert at shaw.ca Tue Feb 23 17:17:30 2021 From: bhilpert at shaw.ca (Brent Hilpert) Date: Tue, 23 Feb 2021 15:17:30 -0800 Subject: : Re: MSI 6800 EPROM Software In-Reply-To: <001e01d70a2d$479b38c0$d6d1aa40$@tuccio.net> References: <001e01d70a2d$479b38c0$d6d1aa40$@tuccio.net> Message-ID: On 2021-Feb-23, at 1:45 PM, Frank Tuccio via cctech wrote: > On 02/22/2021 01:31 PM, Brad H via cctalk wrote: >> >> A longshot I'm sure - but I am wondering if anyone familiar with MSI > (Midwest Scentific - SS50 bus system) would happen to have a copy of the > software for their 1702A EPROM burner, I think the model is PR-1. I just > picked one up and am eager to see if I can use it to read/burn 1702As, > something that has been an issue for me for a while now. >> >> > Reading them is pretty easy. BURNING them is crazy. They > need an 80 V power supply, and I think you XOR the address > or something as you apply the programming voltage. > > Jon > > Actually, programming a 1702 only requires a -48 volt pulse for each > address. Here's the datasheet: > https://www.jmargolin.com/patents/1702a.pdf Ya, but that's with a Vbb of +12V, so the differential required from the power supplies is 60V. (Per the datasheet, it was ~ 55V in the 1702 programmer I once had.) But that's the easy part. And the semi-complex timing and switched-complementing of the address can be done in software. The hassle is that the data lines, address lines and several of the supply and control lines all have to be switched independently with these high voltages. So it's a small mess of specialised discrete drivers and hardware. It's not just pulse a high voltage to one PGM pin like it was for 2716s and later eproms. I don't know what the 2708 (after the 1702, before the 2716) requirements were. From p.gebhardt at ymail.com Wed Feb 24 04:50:29 2021 From: p.gebhardt at ymail.com (P Gebhardt) Date: Wed, 24 Feb 2021 10:50:29 +0000 (UTC) Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> Message-ID: <566388468.3201034.1614163829891@mail.yahoo.com> Am Mittwoch, 24. Februar 2021, 03:53:19 MEZ hat Chris Zach via cctalk Folgendes geschrieben: >Wow, I've always wanted an 11/750. Not sure why, the small box size is >impressive and all that. However it doesn't look like that one has a >MASSBUS adapter so I will have to pass... > >And I just gave away a M7850 memory board :-) > >C > I happen to have a massbus adapter and the cabling with terminator for my 11/750, but I never came across any massbus peripherals. Considering the price back then and the size for these, they seem nowadays quite rare, which is a real pity.? Anybody knows if there was conversion kit to equip CDC 9762 and 9766 type SMD drives into MASSBUS drives much like the TU81 could be turned into a TA81 (SDI)? Cheers, Pierre ----------------------------------------------------------------------------- http://www.digitalheritage.de From cz at alembic.crystel.com Wed Feb 24 08:06:07 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Wed, 24 Feb 2021 09:06:07 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <566388468.3201034.1614163829891@mail.yahoo.com> References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> Message-ID: > I happen to have a massbus adapter and the cabling with terminator for my 11/750, but I never came across any massbus peripherals. Considering the price back then and the size for these, they seem nowadays quite rare, which is a real pity. Sort of. MASSBUS was a very overpriced and to be honest weird system that DEC developed in an attempt to be like IBM and charge very high markups for generic peripherals. While it did support a variety of interface formats (I don't think the RS03 and 04 were SMD, and I know the RP07 was *not* SMD) the industry quickly centered on SMD and that was that. Yes, the TM02 and TM03 formatters allowed MASSBUS to connect to Pertec drives, but I don't think you could run a tape drive and a disk drive on the same MASSBUS channel anyway. Wonder why, technically the MASSBUS cable is just an extension of the Unibus, so it shouldn't matter much what combination of cables you used. Maybe they just wrote different drivers or something. > Anybody knows if there was conversion kit to equip CDC 9762 and 9766 type SMD drives into MASSBUS drives much like the TU81 could be turned into a TA81 (SDI)? I have heard that the difference between what comes out of a MBA (which is huge, several quad height boards in an interface box) and true SMD is the inversion of some differential signals. Whatever it is the changes to a 9762 were very minimal, probably just one of the cards in the card cage. It's quite possible there is no difference, I'll leave that to someone else. My guess is they removed the TM03 formatter from the TU81 and just put in a SDI formatter which was nothing more than yet another closed source version of a Pertec formatter. Maybe DEC lost the contractor who built MASSBUS cables as they were better used to tie ships to a dock. (Yes, I did use a MASSBUS cable to tow a car once. Worked fine) I still have an RM80 drive in my house here, I fire it up every 5 years or so. Mostly for when I get my Decsystem/20 back together. It has the RM80 personality module which is the difference between the R80 and RM80. To be honest I'd bet that one could put an RA81 personality module into it and make an RA80 drive.... Far more interesting would be to see if one could put the RM80 personality module into an RA81 drive and turn that into a 456mb MASSBUS drive. THAT would be interesting.... C From a.carlini at ntlworld.com Wed Feb 24 08:08:20 2021 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Wed, 24 Feb 2021 14:08:20 +0000 Subject: archive of DEC Notes In-Reply-To: References: Message-ID: On 24/02/2021 03:26, Eric Smith via cctalk wrote: > Does anyone have contact information for the proprietor of this site: > http://www.activityclub.org/decnotes/ > The site has an index of messages archived from DEC's internal "Notes" > (kind of their equivalent of UseNet). > > It appears from the "Download this site" page that at one time it was > possible to download an archive of the actual content, but the hosting used > for that only provides one week of free hosting, which has expired. > > I don't need the entire archive (though I'd like to get it), but I'd > especially like to get messages from milkwy::23class_semiconductor and > ricks::decschips. Well if they ever show up, I'd be interested :-). That archive was largely incomplete: it had the message titles but very few of the actual messages. There were some rather harsh negative comments on an FB group when someone pointed to it. Obviously some people thought that when they were writing their original comments that they would be kept private to the 100,000+ Digital employees :-) Anyway, if bitsavers ever wants to set up an archive of Notes conferences, then I'll go and dig out the ones I was hosting back in the day. There might be a few from the old MARVIN cluster too but nothing as interesting as the VAX or semiconductor conferences. FWIW I think the person who originally saved those details might have been Paul S. Winalski, but that might be my memory playing tricks on me. Antonio -- Antonio Carlini antonio at acarlini.com From mattislind at gmail.com Wed Feb 24 09:02:29 2021 From: mattislind at gmail.com (Mattis Lind) Date: Wed, 24 Feb 2021 16:02:29 +0100 Subject: VAX 11/750 In-Reply-To: References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> Message-ID: Den ons 24 feb. 2021 kl 04:57 skrev Ethan Dicks via cctalk < cctalk at classiccmp.org>: > On Tue, Feb 23, 2021 at 9:53 PM Chris Zach via cctalk > wrote: > > Wow, I've always wanted an 11/750. Not sure why, the small box size is > > impressive and all that. > > I started on an 11/750 in 1984. They are fantastic little machines. > If you only have 3-4 users on them, they are quite peppy. > > > However it doesn't look like that one has a MASSBUS adapter so I will > have to pass... > > The module map indicates an SI 9400 interface (CMI card to an SI 9xxx > SMD disk box) and an L0007, which is an RH750 MASSBUS adapter. Those > slots appear to be populated with _something_ in the photo. There > _might_ be a MASSBUS connector at the lower-right of the I/O bulkhead. > > The CPU area seems to show an FP750 Floating Point accelerator > installed in slot 1. > > It also appears there are a couple of cards in the memory area in > slots 6 and 8. What I don't know, since I didn't have one, is how you > load up a machine with an L0022 14MB memory controller, but it's > _possible_ we are looking at 4x 1MB + 2x 4MB (full boat). > Looking at the pictures it seems that the two boards to the left in the memory backlane are NOT M7199 4 Meg boards. Those boards seem to be more like standard full size 11/750 boards but the connectors of those are very different so they would not fit. I just wonder if someone put spare boards there? It may be so that they are not pushed in fully and latched properly? It is impossible to read the ID of the board but they sure look like L0008 microcode boards to me. There are two boards in the CMI bus slots, one seems to be a third party something and the other might as well be the L0007 MBA. It is likely since it has three gate arrays in the correct area as is visible from the picture. My 11/750 has six M8750 and two M7199 and the L0022 controller. I don't know if three M7199 and two M8750 config is possible as well. /Mattis > > Cheers, > > -ethan > From elson at pico-systems.com Wed Feb 24 10:06:50 2021 From: elson at pico-systems.com (Jon Elson) Date: Wed, 24 Feb 2021 10:06:50 -0600 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> Message-ID: <6036799A.6060900@pico-systems.com> On 02/24/2021 08:06 AM, Chris Zach via cctalk wrote: > > Sort of. MASSBUS was a very overpriced and to be honest > weird system that DEC developed in an attempt to be like > IBM and charge very high markups for generic peripherals. > While it did support a variety of interface formats (I > don't think the RS03 and 04 were SMD, and I know the RP07 > was *not* SMD) the industry quickly centered on SMD and > that was that. > OOOOhhh, the RP07! I have stories about that drive! It was a Burroughs mainframe drive they reprogrammed for DEC. It had a number of issues. The worst one was that due to some microcode bugs, it was possible to trash an occasional track descriptor record. When a bad TDR was read, the drive totally locked up, you had to cycle power to reset it. VMS recovered from it quite gracefully, however. They finally fixed it, it required replacing about 10 boards. Then, there was a procedure to rewrite all the TDRs. The DEC FE assured me it would not touch user data. Well, after running the procedure, it came up as a blank disk! YIKES! A quick check at the binary level showed data was still on the drive, but the RMS-11 home block had been overwritten. Well, I had a program that could examine the home blocks, and I knew where to find the backup home blocks. So, I hacked that program to copy the backup block to the main one, and then change the checksums to agree. The other issue is the voice coil could suck dirty air in during long seeks, so they had ti replace the HDA and put a filter over the air exhaust from the voice coil. > Yes, the TM02 and TM03 formatters allowed MASSBUS to > connect to Pertec drives, but I don't think you could run > a tape drive and a disk drive on the same MASSBUS channel > anyway. Wonder why, technically the MASSBUS cable is just > an extension of the Unibus, so it shouldn't matter much > what combination of cables you used. Maybe they just wrote > different drivers or something. > MASSBUS was not anything like a UNIBUS, it was a lot closer to an IBM channel bus and tag cable. >> Anybody knows if there was conversion kit to equip CDC >> 9762 and 9766 type SMD drives into MASSBUS drives much >> like the TU81 could be turned into a TA81 (SDI)? > Well, just the guts inside an RM05, that was a 9762 drive relabeled by DEC. Jon From nw.johnson at ieee.org Wed Feb 24 10:12:43 2021 From: nw.johnson at ieee.org (Nigel Johnson) Date: Wed, 24 Feb 2021 11:12:43 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <6036799A.6060900@pico-systems.com> References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> <6036799A.6060900@pico-systems.com> Message-ID: <912dd92e-bbcf-f6ea-0b48-03c30b3f2802@ieee.org> On 2021-02-24 11:06 a.m., Jon Elson via cctalk wrote: > On 02/24/2021 08:06 AM, Chris Zach via cctalk wrote: >> >> Sort of. MASSBUS was a very overpriced and to be honest weird system >> that DEC developed in an attempt to be like IBM and charge very high >> markups for generic peripherals. While it did support a variety of >> interface formats (I don't think the RS03 and 04 were SMD, and I know >> the RP07 was *not* SMD) the industry quickly centered on SMD and that >> was that. >> > OOOOhhh, the RP07!? I have stories about that drive! > It was a Burroughs mainframe drive they reprogrammed for DEC.? It had > a number of issues. > The worst one was that due to some microcode bugs, it was possible to > trash an occasional track descriptor record.? When a bad TDR was read, > the drive totally locked up, you had to cycle power to reset it.? VMS > recovered from it quite gracefully, however.? They finally fixed it, > it required replacing about 10 boards.? Then, there was a procedure to > rewrite all the TDRs.? The DEC FE assured me it would not touch user > data.? Well, after running the procedure, it came up as a blank disk!? > YIKES!? A quick check at the binary level showed data was still on the > drive, but the RMS-11 home block had been overwritten.? Well, I had a > program that could examine the home blocks, and I knew where to find > the backup home blocks.? So, I hacked that program to copy the backup > block to the main one, and then change the checksums to agree. > > The other issue is the voice coil could suck dirty air in during long > seeks, so they had ti replace the HDA and put a filter over the air > exhaust from the voice coil. >> Yes, the TM02 and TM03 formatters allowed MASSBUS to connect to >> Pertec drives, but I don't think you could run a tape drive and a >> disk drive on the same MASSBUS channel anyway. Wonder why, >> technically the MASSBUS cable is just an extension of the Unibus, so >> it shouldn't matter much what combination of cables you used. Maybe >> they just wrote different drivers or something. >> > MASSBUS was not anything like a UNIBUS, it was a lot closer to an IBM > channel bus and tag cable. >>> Anybody knows if there was conversion kit to equip CDC 9762 and 9766 >>> type SMD drives into MASSBUS drives much like the TU81 could be >>> turned into a TA81 (SDI)? >> > Well, just the guts inside an RM05, that was a 9762 drive relabeled by > DEC. > Actually the RM05 was a 9766 - the 9762 was an RM03 when DEC re-packaged it > Jon From cz at alembic.crystel.com Wed Feb 24 11:26:27 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Wed, 24 Feb 2021 12:26:27 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <6036799A.6060900@pico-systems.com> References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> <6036799A.6060900@pico-systems.com> Message-ID: <4377a056-0b55-2c2a-4439-374f83e8ef68@alembic.crystel.com> Yep. I actually had one. The lid flew off the top of it while we were driving it back from Eastern shore to Baltimore on Rt. 50 but the rest of it was intact. Very different MBA controller from an RM02/03. Unfortunately when Doug closed up the storage place someone swiped MC from there before I could pick it up, and at the same time the RP07 vanished. I'm guessing that the 07 was junked as MC has resurfaced in a museum..... CZ > OOOOhhh, the RP07!? I have stories about that drive! > It was a Burroughs mainframe drive they reprogrammed for DEC.? It had a > number of issues. > The worst one was that due to some microcode bugs, it was possible to > trash an occasional track descriptor record. When a bad TDR was read, > the drive totally locked up, you had to cycle power to reset it.? VMS > recovered from it quite gracefully, however.? They finally fixed it, it > required replacing about 10 boards.? Then, there was a procedure to > rewrite all the TDRs.? The DEC FE assured me it would not touch user > data.? Well, after running the procedure, it came up as a blank disk! > YIKES!? A quick check at the binary level showed data was still on the > drive, but the RMS-11 home block had been overwritten.? Well, I had a > program that could examine the home blocks, and I knew where to find the > backup home blocks.? So, I hacked that program to copy the backup block > to the main one, and then change the checksums to agree. > > The other issue is the voice coil could suck dirty air in during long > seeks, so they had ti replace the HDA and put a filter over the air > exhaust from the voice coil. >> Yes, the TM02 and TM03 formatters allowed MASSBUS to connect to Pertec >> drives, but I don't think you could run a tape drive and a disk drive >> on the same MASSBUS channel anyway. Wonder why, technically the >> MASSBUS cable is just an extension of the Unibus, so it shouldn't >> matter much what combination of cables you used. Maybe they just wrote >> different drivers or something. >> > MASSBUS was not anything like a UNIBUS, it was a lot closer to an IBM > channel bus and tag cable. >>> Anybody knows if there was conversion kit to equip CDC 9762 and 9766 >>> type SMD drives into MASSBUS drives much like the TU81 could be >>> turned into a TA81 (SDI)? >> > Well, just the guts inside an RM05, that was a 9762 drive relabeled by DEC. > > Jon From cz at alembic.crystel.com Wed Feb 24 11:31:32 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Wed, 24 Feb 2021 12:31:32 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <6036799A.6060900@pico-systems.com> References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> <6036799A.6060900@pico-systems.com> Message-ID: <05a47083-bbed-ed87-8bb7-7d89f175818c@alembic.crystel.com> > Well, I had a > program that could examine the home blocks, and I knew where to find the > backup home blocks.? So, I hacked that program to copy the backup block > to the main one, and then change the checksums to agree. That is one way to avoid a very long restore :-) > The other issue is the voice coil could suck dirty air in during long > seeks, so they had ti replace the HDA and put a filter over the air > exhaust from the voice coil. Yes, they had issues. Another one apparently is the heads will glue themselves to the drive after a few years, I was researching ways to unstick the heads without damaging them (hint: Never use Isopropyl to clean a RM03 disk head. It will unglue it and hilarity will result) but that whole thing was mooted when it vanished. > MASSBUS was not anything like a UNIBUS, it was a lot closer to an IBM > channel bus and tag cable. Ok, however the address and data bus feels a lot like a Unibus. And all of the registers are in the drive controller/adapters, it almost feels like you are tickling the adapter directly off the Unibus. Given Dec's joy with Unibus repeaters, bridges and windows it does feel like a window into the Unibus itself. C From bill.gunshannon at hotmail.com Wed Feb 24 11:38:11 2021 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Wed, 24 Feb 2021 12:38:11 -0500 Subject: VAX 11/750 In-Reply-To: References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> Message-ID: On 2/23/21 10:57 PM, Ethan Dicks via cctalk wrote: > On Tue, Feb 23, 2021 at 9:53 PM Chris Zach via cctalk > wrote: >> Wow, I've always wanted an 11/750. Not sure why, the small box size is >> impressive and all that. > > I started on an 11/750 in 1984. They are fantastic little machines. > If you only have 3-4 users on them, they are quite peppy. > At least until one of them fires up Eunice or the Ada Compiler. :-) 750 was my first VAX and first VMS machine, too. bill From decguy at songdog.eskimo.com Wed Feb 24 12:08:47 2021 From: decguy at songdog.eskimo.com (Guy N.) Date: Wed, 24 Feb 2021 10:08:47 -0800 Subject: Funky electronics chain =?UTF-8?Q?Fry=E2=80=99s?= is no more (Seattle Times) Message-ID: <1614190127.1780.18.camel@moondog> https://www.seattletimes.com/business/funky-electronics-chain-frys-is-no-more/ So sad to see them go. There was a Fry's store close enough for me to visit occasionally. What will I do now when I actually want to examine the merchandise before I pay for it? From aek at bitsavers.org Wed Feb 24 12:26:54 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 24 Feb 2021 10:26:54 -0800 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <4377a056-0b55-2c2a-4439-374f83e8ef68@alembic.crystel.com> References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> <6036799A.6060900@pico-systems.com> <4377a056-0b55-2c2a-4439-374f83e8ef68@alembic.crystel.com> Message-ID: <0b8ef352-50d9-308b-5627-6bb1ef7c1129@bitsavers.org> I have two RP07s sitting on the upper mezanine here that were left behind by the former tennant of the building my shop is in. From cz at alembic.crystel.com Wed Feb 24 14:01:10 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Wed, 24 Feb 2021 15:01:10 -0500 Subject: SaturnCalc, Graph, and WP disks uploaded In-Reply-To: <53FEB685-B86D-4034-A3F2-8EDD6E8B8366@MatlockFamily.com> References: <53FEB685-B86D-4034-A3F2-8EDD6E8B8366@MatlockFamily.com> Message-ID: <9f4d8df9-285f-ec2e-19cb-fd62a9586e25@alembic.crystel.com> They are RT11/TSX versions. Now for the problem of the day. The TSX 5.1 distribution floppies have damage to track zero, my guess is they were in the Solarex drives where the wonderful silicon dust did a job on them. Anyone got really good 8 inch floppy skills and want to take a crack at reading them? C From mark at matlockfamily.com Wed Feb 24 13:43:31 2021 From: mark at matlockfamily.com (Mark Matlock) Date: Wed, 24 Feb 2021 13:43:31 -0600 Subject: SaturnCalc, Graph, and WP disks uploaded Message-ID: <53FEB685-B86D-4034-A3F2-8EDD6E8B8366@MatlockFamily.com> Hi all! Spent some serious time this evening with the RX02 drives: I managed to download the images of the SaturnCalc 3.0, Saturn Graph, and Saturn WP software to RX02 images. I think it's set right, can someone take a look at the images and see if they are good? Should be RT11 format, RX02 (of course), I recorded from both sides of the disks (they're double sided, hole punched by the vendor) and are at https://www.crystel.com/bob You should see the disks and the meta files. Let me know if they work, I need to get to bed. Either burn them on real RX02's or read them with a SIMH image. C Chris, I am very interested in Saturn Calc for PDP-11s specifically for RSX. I downloaded your floppies and will take a look at them soon. You mention that they are in RT-11 format. Do you know which PDP-11 OS the Saturn software was for. They had versions also for RT-11, TSX and RSTS. Later they had native VMS and MSDOS versions. There are images of RX50s for RSX Saturn Calc, Graph and WPS at Malcolm?s web site. https://avitech.com.au/?page_id=2570 He also gave me some documentation that I have scanned and put up at http://www.rsx11m.com/SaturnInstall.pdf http://www.rsx11m.com/SaturnCalc.pdf http://www.rsx11m.com/SaturnCalcRef.pdf Saturn products on the PDP-11 and VMS used their own license key systems. I do have valid licenses for Calc and Graph for VMS and have them running on a MV3100-80. It would be great to get the RSX version running. I used it extensively back in the day and it would be wonderful to preserve it. Best, Mark Matlock From elson at pico-systems.com Wed Feb 24 14:22:35 2021 From: elson at pico-systems.com (Jon Elson) Date: Wed, 24 Feb 2021 14:22:35 -0600 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <0b8ef352-50d9-308b-5627-6bb1ef7c1129@bitsavers.org> References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> <6036799A.6060900@pico-systems.com> <4377a056-0b55-2c2a-4439-374f83e8ef68@alembic.crystel.com> <0b8ef352-50d9-308b-5627-6bb1ef7c1129@bitsavers.org> Message-ID: <6036B58B.9020004@pico-systems.com> On 02/24/2021 12:26 PM, Al Kossow via cctalk wrote: > I have two RP07s sitting on the upper mezanine here that > were left behind by the former tennant of the > building my shop is in. > > > Do you have 3-phase power? Will they even spin up? Jon From paulkoning at comcast.net Wed Feb 24 14:27:46 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 24 Feb 2021 15:27:46 -0500 Subject: archive of DEC Notes In-Reply-To: References: Message-ID: <8D9557BE-7BB9-4379-BE15-B3138CD646EB@comcast.net> > On Feb 24, 2021, at 9:08 AM, Antonio Carlini via cctalk wrote: > > On 24/02/2021 03:26, Eric Smith via cctalk wrote: >> Does anyone have contact information for the proprietor of this site: >> http://www.activityclub.org/decnotes/ >> The site has an index of messages archived from DEC's internal "Notes" >> (kind of their equivalent of UseNet). >> >> It appears from the "Download this site" page that at one time it was >> possible to download an archive of the actual content, but the hosting used >> for that only provides one week of free hosting, which has expired. >> >> I don't need the entire archive (though I'd like to get it), but I'd >> especially like to get messages from milkwy::23class_semiconductor and >> ricks::decschips. > > Well if they ever show up, I'd be interested :-). > > > That archive was largely incomplete: it had the message titles but very few of the actual messages. There were some rather harsh negative comments on an FB group when someone pointed to it. Obviously some people thought that when they were writing their original comments that they would be kept private to the 100,000+ Digital employees :-) The more significant issue may be that DEC, and its successor companies, might have objections to the public posting of company confidential material. Too bad only a few things were archived. I looked for myself and found exactly one notesfile ("fddi") with saved content, which made for some fun reading. But other notesfiles that would actually be more interesting at this stage, like ones about RSTS, aren't archived. I wonder if anyone has the full archive dump. If so I'd love to have that. paul From mattislind at gmail.com Wed Feb 24 14:39:01 2021 From: mattislind at gmail.com (Mattis Lind) Date: Wed, 24 Feb 2021 21:39:01 +0100 Subject: SaturnCalc, Graph, and WP disks uploaded In-Reply-To: <9f4d8df9-285f-ec2e-19cb-fd62a9586e25@alembic.crystel.com> References: <53FEB685-B86D-4034-A3F2-8EDD6E8B8366@MatlockFamily.com> <9f4d8df9-285f-ec2e-19cb-fd62a9586e25@alembic.crystel.com> Message-ID: onsdag 24 februari 2021 skrev Chris Zach via cctalk : > They are RT11/TSX versions. > > Now for the problem of the day. The TSX 5.1 distribution have damage to > track zero, my guess is they were in the Solarex drives where the wonderful > silicon dust did a job on them. Anyone got really good 8 inch floppy skills > and want to take a crack at reading them? As far as I understand RX01/RX02 disks are not using track 0 at all. You should be able to splice in track 0 from a working RX disk. /Mattis > > C > From paulkoning at comcast.net Wed Feb 24 14:43:01 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 24 Feb 2021 15:43:01 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> Message-ID: <3B8D6683-389A-4356-831E-D207C39643E1@comcast.net> > On Feb 24, 2021, at 9:06 AM, Chris Zach via cctalk wrote: > >> I happen to have a massbus adapter and the cabling with terminator for my 11/750, but I never came across any massbus peripherals. Considering the price back then and the size for these, they seem nowadays quite rare, which is a real pity. > > Sort of. MASSBUS was a very overpriced and to be honest weird system that DEC developed in an attempt to be like IBM and charge very high markups for generic peripherals. While it did support a variety of interface formats (I don't think the RS03 and 04 were SMD, and I know the RP07 was *not* SMD) the industry quickly centered on SMD and that was that. Overpriced? Compared to what? SMD didn't appear until later; I know Massbus existed in 1974, perhaps earlier. What else would do the job back then? > Yes, the TM02 and TM03 formatters allowed MASSBUS to connect to Pertec drives, but I don't think you could run a tape drive and a disk drive on the same MASSBUS channel anyway. Wonder why, technically the MASSBUS cable is just an extension of the Unibus, so it shouldn't matter much what combination of cables you used. Maybe they just wrote different drivers or something. Electrically it works. I believe at least one system/OS supports this; TOPS-10 perhaps? But most operating systems do not, and yes, that would be a driver issue. Similarly, not all OS support RS03/04 and RM/RP on the same Massbus (RSTS doesn't for example). Meanwhile, speaking of the RP07: DEC never supported that on any PDP-11, but it actually works just fine on the high performance Massbus of the 11/70. In the RSTS group we had one on the big 11/70 system ("ARK" because at one point it had "two of everything"). So RSTS/E will happily drive such a device, if you can manage to power it up. >> ... > > (Yes, I did use a MASSBUS cable to tow a car once. Worked fine) :-) I think IBM's "bus and tag" 360 channel cables are even thicker than a Massbus cable. > I still have an RM80 drive in my house here, I fire it up every 5 years or so. Mostly for when I get my Decsystem/20 back together. > > It has the RM80 personality module which is the difference between the R80 and RM80. To be honest I'd bet that one could put an RA81 personality module into it and make an RA80 drive.... > > Far more interesting would be to see if one could put the RM80 personality module into an RA81 drive and turn that into a 456mb MASSBUS drive. THAT would be interesting.... Yes, but you'd need some driver work, since Massbus disk drivers have to deal with the actual drive topology. So you'd have to define a Massbus ID value for "RM81" and pick the appropriate sector/head/cylinder count. Depending on the OS this may be fairly easy or not so easy. I know how to do it in RSTS (at the source level -- doing it by patches might also be doable). paul From aek at bitsavers.org Wed Feb 24 14:56:46 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 24 Feb 2021 12:56:46 -0800 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <6036B58B.9020004@pico-systems.com> References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> <6036799A.6060900@pico-systems.com> <4377a056-0b55-2c2a-4439-374f83e8ef68@alembic.crystel.com> <0b8ef352-50d9-308b-5627-6bb1ef7c1129@bitsavers.org> <6036B58B.9020004@pico-systems.com> Message-ID: <24a0c89e-a25a-3731-f0b3-36d85b2f2ca3@bitsavers.org> >> Do you have 3-phase power?? Will they even spin up? I do, but I don't care enough about them to try. I just want them gone. Bring your own fork lift, the battery in mine is dead and they are 15 feet up. From pietstan15 at gmail.com Wed Feb 24 17:02:29 2021 From: pietstan15 at gmail.com (stan) Date: Wed, 24 Feb 2021 18:02:29 -0500 Subject: FW: List your old computer In-Reply-To: <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> Message-ID: By any chance, are you thinking of uptimes.net? Some years ago (early 2000's?) it was tracking systems uptimes. I had an Alpha system talking to it at one time. IIRC, the record at one time was a VAX cluster, with an uptime of 1200+ days. Windows NT systems fared a lot worse, average of about 40 some days.... Stan On 2021-02-24 2:02 a.m., Kevin Parker via cctalk wrote: > My apologies for the tracker embedded in my original post. I use it for my > business and forgot to remove it before posting to this list. > > > Kevin Parker > > -----Original Message----- > From: cctalk On Behalf Of Kevin Parker via > cctalk > Sent: Wednesday, 24 February 2021 6:00 PM > To: 'General Discussion: On-Topic and Off-Topic Posts' > > Subject: List your old computer > > Hi folks - there used to be a web site where you could register and list > your "classic/old computer(s)". I'm not looking to do that but am trying to > find something from years gone by that I think was on that site. > > I thought it was https://www.old-computers.com/ or http://oldcomputers.net/ > but it's neither of those. > > My googlefoo has been unable to track it down assuming it still exists. I > know at one stage the owner was thinking of closing it down because of hacks > or spamming of forms or something like that. > > Does this ring a bell with anyone? > > Thank you!! > > Kevin Parker > > > > > 1qZM43W3s0v_y2M0f8BF4c2NfHml5Hf6Bq4h603?si=8000000004908274&pi=cece28eb-2dfe > -4230-a422-38cd80fce8ae> > > From pete at dunnington.plus.com Wed Feb 24 17:11:53 2021 From: pete at dunnington.plus.com (Pete Turnbull) Date: Wed, 24 Feb 2021 23:11:53 +0000 Subject: FW: List your old computer In-Reply-To: References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> Message-ID: On 24/02/2021 23:02, stan via cctalk wrote: > By any chance, are you thinking of uptimes.net? > Some years ago (early 2000's?) it was tracking systems uptimes. I had an > Alpha? system talking to it at one time. > > IIRC, the record at one time was a VAX cluster, with an uptime of 1200+ > days. Windows NT systems fared a lot worse, average of about 40 some > days.... I never got close to 1200 days, but I had an SGI machine at home talking to uptimes.net. I remember watching it from work as it got close to 10000 hours (on the 416th day, 19th November 2002 according to syslog) when suddenly it went off the air. It turned out the electricity provider had (accidentally) tripped the wrong breaker in the local substation. Grr. -- Pete Turnbull From trash80 at internode.on.net Wed Feb 24 17:17:01 2021 From: trash80 at internode.on.net (Kevin Parker) Date: Thu, 25 Feb 2021 10:17:01 +1100 Subject: FW: List your old computer In-Reply-To: References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> Message-ID: <0afd01d70b03$28df4fd0$7a9def70$@internode.on.net> Thanks Stan - no it wasn?t anything to do with uptime. It was like a museum but people registered/listed their machines with some info about them and some pictures. Kevin Parker -----Original Message----- From: cctalk On Behalf Of stan via cctalk Sent: Thursday, 25 February 2021 10:02 AM To: cctalk at classiccmp.org Subject: Re: FW: List your old computer By any chance, are you thinking of uptimes.net? Some years ago (early 2000's?) it was tracking systems uptimes. I had an Alpha system talking to it at one time. IIRC, the record at one time was a VAX cluster, with an uptime of 1200+ days. Windows NT systems fared a lot worse, average of about 40 some days.... Stan On 2021-02-24 2:02 a.m., Kevin Parker via cctalk wrote: > My apologies for the tracker embedded in my original post. I use it > for my business and forgot to remove it before posting to this list. > > > Kevin Parker > > -----Original Message----- > From: cctalk On Behalf Of Kevin Parker > via cctalk > Sent: Wednesday, 24 February 2021 6:00 PM > To: 'General Discussion: On-Topic and Off-Topic Posts' > > Subject: List your old computer > > Hi folks - there used to be a web site where you could register and > list your "classic/old computer(s)". I'm not looking to do that but am > trying to find something from years gone by that I think was on that site. > > I thought it was https://www.old-computers.com/ or > http://oldcomputers.net/ but it's neither of those. > > My googlefoo has been unable to track it down assuming it still > exists. I know at one stage the owner was thinking of closing it down > because of hacks or spamming of forms or something like that. > > Does this ring a bell with anyone? > > Thank you!! > > Kevin Parker > > > > > 1_k-L- > 1qZM43W3s0v_y2M0f8BF4c2NfHml5Hf6Bq4h603?si=8000000004908274&pi=cece28e > b-2dfe > -4230-a422-38cd80fce8ae> > > From cclist at sydex.com Wed Feb 24 18:01:25 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 24 Feb 2021 16:01:25 -0800 Subject: FW: List your old computer In-Reply-To: References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> Message-ID: On 2/24/21 3:11 PM, Pete Turnbull via cctalk wrote: > On 24/02/2021 23:02, stan via cctalk wrote: >> By any chance, are you thinking of uptimes.net? >> Some years ago (early 2000's?) it was tracking systems uptimes. I had >> an Alpha? system talking to it at one time. >> >> IIRC, the record at one time was a VAX cluster, with an uptime of >> 1200+ days. Windows NT systems fared a lot worse, average of about 40 >> some days.... A modern MCU running Linux with battery backup could beat that easily. And probably be faster than the VAX. How far we've come... --Chuck From jnc at mercury.lcs.mit.edu Wed Feb 24 18:06:12 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 24 Feb 2021 19:06:12 -0500 (EST) Subject: Massbus - was: Re: VAX 11/750 Message-ID: <20210225000612.346CC18C095@mercury.lcs.mit.edu> > From: Chris Zach > technically the MASSBUS cable is just an extension of the Unibus No. For one thing, the MASSBUS has no lines for carrying memory addresses. So there is no way to even build a box that 'translates' MASSBUS to UNIBUS; the semantics ('the things you can say', basically) of the two busses are so very different. (The MASSBUS is actually two separate busses; a control bus, and a data bus. The former has 5 lines for 'register address', but that's all. While the control bus is asynchronous, the data bus is synchronous.) Noel From mail at schnitz.com Wed Feb 24 18:07:56 2021 From: mail at schnitz.com (Tom Owad) Date: Wed, 24 Feb 2021 19:07:56 -0500 Subject: List your old computer In-Reply-To: References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> Message-ID: <2666F8F5-EAD1-48B9-9D02-6F1415124C1E@schnitz.com> > On Feb 24, 2021, at 6:11 PM, Pete Turnbull via cctalk wrote: > I never got close to 1200 days, but I had an SGI machine at home talking to uptimes.net. I remember watching it from work as it got close to 10000 hours (on the 416th day, 19th November 2002 according to syslog) when suddenly it went off the air. It turned out the electricity provider had (accidentally) tripped the wrong breaker in the local substation. Grr. Is there anybody still running a service like uptimes.net ? That sounds like fun. From elson at pico-systems.com Wed Feb 24 18:48:57 2021 From: elson at pico-systems.com (Jon Elson) Date: Wed, 24 Feb 2021 18:48:57 -0600 Subject: FW: List your old computer In-Reply-To: References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> Message-ID: <6036F3F9.5010906@pico-systems.com> On 02/24/2021 06:01 PM, Chuck Guzis via cctalk wrote: > On 2/24/21 3:11 PM, Pete Turnbull via cctalk wrote: >> On 24/02/2021 23:02, stan via cctalk wrote: >>> By any chance, are you thinking of uptimes.net? >>> Some years ago (early 2000's?) it was tracking systems uptimes. I had >>> an Alpha system talking to it at one time. >>> >>> IIRC, the record at one time was a VAX cluster, with an uptime of >>> 1200+ days. Windows NT systems fared a lot worse, average of about 40 >>> some days.... > A modern MCU running Linux with battery backup could beat that easily. > > And probably be faster than the VAX. > > How far we've come... > Faster? The only comparison I have is between my KA630-AA and my current desktop (Dell Optiplex 980) running Ubuntu. It seems to be almost 1000 X faster. I have a program that records environmental data every 15 seconds. Then, there are programs that condense and summarize the data. The whole run at the end of the year used to take about 30 minutes. It runs in about 5 SECONDS on the PC. (Yes, I know, only 360 X.) Jon From santo.nucifora at gmail.com Wed Feb 24 18:59:22 2021 From: santo.nucifora at gmail.com (Santo Nucifora) Date: Wed, 24 Feb 2021 19:59:22 -0500 Subject: FW: List your old computer In-Reply-To: <0afd01d70b03$28df4fd0$7a9def70$@internode.on.net> References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> <0afd01d70b03$28df4fd0$7a9def70$@internode.on.net> Message-ID: Looks a little different since the last time I looked around that feature (it was a while back) but I think it may be this site? https://www.1000bit.it/ Santo On Wed, Feb 24, 2021 at 7:32 PM Kevin Parker via cctalk < cctalk at classiccmp.org> wrote: > Thanks Stan - no it wasn?t anything to do with uptime. It was like a > museum but people registered/listed their machines with some info about > them and some pictures. > > > Kevin Parker > > -----Original Message----- > From: cctalk On Behalf Of stan via cctalk > Sent: Thursday, 25 February 2021 10:02 AM > To: cctalk at classiccmp.org > Subject: Re: FW: List your old computer > > By any chance, are you thinking of uptimes.net? > Some years ago (early 2000's?) it was tracking systems uptimes. I had an > Alpha system talking to it at one time. > > IIRC, the record at one time was a VAX cluster, with an uptime of 1200+ > days. Windows NT systems fared a lot worse, average of about 40 some > days.... > > Stan > > > On 2021-02-24 2:02 a.m., Kevin Parker via cctalk wrote: > > My apologies for the tracker embedded in my original post. I use it > > for my business and forgot to remove it before posting to this list. > > > > > > Kevin Parker > > > > -----Original Message----- > > From: cctalk On Behalf Of Kevin Parker > > via cctalk > > Sent: Wednesday, 24 February 2021 6:00 PM > > To: 'General Discussion: On-Topic and Off-Topic Posts' > > > > Subject: List your old computer > > > > Hi folks - there used to be a web site where you could register and > > list your "classic/old computer(s)". I'm not looking to do that but am > > trying to find something from years gone by that I think was on that > site. > > > > I thought it was https://www.old-computers.com/ or > > http://oldcomputers.net/ but it's neither of those. > > > > My googlefoo has been unable to track it down assuming it still > > exists. I know at one stage the owner was thinking of closing it down > > because of hacks or spamming of forms or something like that. > > > > Does this ring a bell with anyone? > > > > Thank you!! > > > > Kevin Parker > > > > > > > > > > > 1_k-L- > > 1qZM43W3s0v_y2M0f8BF4c2NfHml5Hf6Bq4h603?si=8000000004908274&pi=cece28e > > b-2dfe > > -4230-a422-38cd80fce8ae> > > > > > > From paulkoning at comcast.net Wed Feb 24 19:16:11 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 24 Feb 2021 20:16:11 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <20210225000612.346CC18C095@mercury.lcs.mit.edu> References: <20210225000612.346CC18C095@mercury.lcs.mit.edu> Message-ID: <1A375A5B-E57C-49A1-A094-BAE40320683B@comcast.net> > On Feb 24, 2021, at 7:06 PM, Noel Chiappa via cctalk wrote: > >> From: Chris Zach > >> technically the MASSBUS cable is just an extension of the Unibus > > No. > > For one thing, the MASSBUS has no lines for carrying memory addresses. So > there is no way to even build a box that 'translates' MASSBUS to UNIBUS; the > semantics ('the things you can say', basically) of the two busses are so very > different. It's faintly true if you look at the Massbus adapter, rather than the cable. But only faintly. There's a good reason why the big disks on many DEC machines were Massbus devices until MSCP arrived. It's quite clear on Unibus PDP-11s, which needed Massbus both for speed and for a cleaner answer to more-than-18 bit addressing. paul From paulkoning at comcast.net Wed Feb 24 19:19:05 2021 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 24 Feb 2021 20:19:05 -0500 Subject: List your old computer In-Reply-To: References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> Message-ID: <3795B24E-ED36-48A0-B4E3-2585D752729C@comcast.net> > On Feb 24, 2021, at 7:01 PM, Chuck Guzis via cctalk wrote: > > On 2/24/21 3:11 PM, Pete Turnbull via cctalk wrote: >> On 24/02/2021 23:02, stan via cctalk wrote: >>> By any chance, are you thinking of uptimes.net? >>> Some years ago (early 2000's?) it was tracking systems uptimes. I had >>> an Alpha system talking to it at one time. >>> >>> IIRC, the record at one time was a VAX cluster, with an uptime of >>> 1200+ days. Windows NT systems fared a lot worse, average of about 40 >>> some days.... > > A modern MCU running Linux with battery backup could beat that easily. > > And probably be faster than the VAX. > > How far we've come... > > --Chuck Not a general purpose computer, but some SAN storage arrays (clustered storage) I helped create have logged uptimes measured in years. Those have MIPS engines and NetBSD as one of the two operating systems (with large modifications). paul From healyzh at avanthar.com Wed Feb 24 19:46:11 2021 From: healyzh at avanthar.com (Zane Healy) Date: Wed, 24 Feb 2021 17:46:11 -0800 Subject: =?utf-8?Q?Re=3A_Funky_electronics_chain_Fry=E2=80=99s_is_no_more_?= =?utf-8?Q?=28Seattle_Times=29?= In-Reply-To: <1614190127.1780.18.camel@moondog> References: <1614190127.1780.18.camel@moondog> Message-ID: <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> > On Feb 24, 2021, at 10:08 AM, Guy N. via cctalk wrote: > > https://www.seattletimes.com/business/funky-electronics-chain-frys-is-no-more/ > > So sad to see them go. There was a Fry's store close enough for me to > visit occasionally. What will I do now when I actually want to examine > the merchandise before I pay for it? You man not be able to examine the merchandise the next time. Just how hard it has gotten to go into a store and see a product before you buy it really hit home this last weekend. My wife and I were trying to look at laptops, the only place left in the area to really see anything seems to be Best Buy. I found myself really wishing CompUSA was still around. We didn?t bother to even consider going down to Fry?s, as a year ago, they were nothing but aisles of empty shelves. Zane From cisin at xenosoft.com Wed Feb 24 20:11:22 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 24 Feb 2021 18:11:22 -0800 (PST) Subject: =?utf-8?Q?Re=3A_Funky_electronics_chain_Fry=E2=80=99s_is_no_more_?= =?utf-8?Q?=28Seattle_Times=29?= In-Reply-To: <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> References: <1614190127.1780.18.camel@moondog> <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> Message-ID: > https://www.seattletimes.com/business/funky-electronics-chain-frys-is-no-more/ They could probably have hung on a little longer, by stocking those empty shelves with toilet paper, and maybe even some groceries. It has been many years since I was in a Fry's, because there weren't any very close. Last time that I went in, I just wanted an ordinary PC printer cable (DB25 to blue ribbon 36 (often inaccurately called a "Centronics" connector)) The clerk was sure that there had ever been any printer cables other than USB. A friend bought some discounted returned items. Then he found out that returned defective items were simply reshelved until one of the future buyers didn't bother to bring them back again. Often without even confirming that all parts were present. But, I remember the old days, when they had lots of "computer people" food items, and even Jolt cola. -- Grumpy Ol' Fred cisin at xenosoft.com From cclist at sydex.com Wed Feb 24 21:38:10 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 24 Feb 2021 19:38:10 -0800 Subject: =?UTF-8?Q?Re=3a_Funky_electronics_chain_Fry=e2=80=99s_is_no_more_?= =?UTF-8?Q?=28Seattle_Times=29?= In-Reply-To: References: <1614190127.1780.18.camel@moondog> <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> Message-ID: <348787ce-6284-45a7-cda9-491b89baf126@sydex.com> On 2/24/21 6:11 PM, Fred Cisin via cctalk wrote: > But, I remember the old days, when they had lots of "computer people" > food items, and even Jolt cola. You're forgetting Canfield Diet Fudge Chocolate Soda--I remember customers wheeling out dollies of the stuff. The idea was simplicity itself--traditional computer stores had very high sales margins. John Fry figured that if he could run a store in the middle of Silicon Valley with thin margins (like the grocery business), it was a shoo-in for success. They also had various snacks to appeal to the lunchtime crowd. I still have quite a few bagged connectors from Fry's with the red-and-white labels. In 1983, how could you beat 59 cents for a gold-plated card edge connector? Lots of parts on pegboards; occasionally a factory rep would show up during lunchtime to demonstrate a piece of test equipment. One of the few retail establishments that stocked VME cards. Fry's flogged a lot of Everex stuff in the PC department. The cashiers, of course, were minimum-wage and so had no idea of what was passing in front of them. But the sales people were little better, so if you knew exactly what you wanted, it was a glorious place. If you were looking for information, not so much. This was all at the flagship Sunnyvale store. Somewhat later, they opened up stores in Fremont and Palo Alto, which were quite a bit more polished. But this is when Silicon Valley still hosted outfits that actually made things... --Chuck From aek at bitsavers.org Wed Feb 24 21:51:12 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 24 Feb 2021 19:51:12 -0800 Subject: =?UTF-8?Q?Re=3a_Funky_electronics_chain_Fry=e2=80=99s_is_no_more_?= =?UTF-8?Q?=28Seattle_Times=29?= In-Reply-To: <348787ce-6284-45a7-cda9-491b89baf126@sydex.com> References: <1614190127.1780.18.camel@moondog> <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> <348787ce-6284-45a7-cda9-491b89baf126@sydex.com> Message-ID: On 2/24/21 7:38 PM, Chuck Guzis via cctalk wrote: > The cashiers, of course, were minimum-wage and so had no idea of what > was passing in front of them. They also had a no questions asked returns policy, which people abused. When something was returned, they'd rebag it and put it back on the shelf. From aek at bitsavers.org Wed Feb 24 22:07:11 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 24 Feb 2021 20:07:11 -0800 Subject: =?UTF-8?Q?Re=3a_Funky_electronics_chain_Fry=e2=80=99s_is_no_more_?= =?UTF-8?Q?=28Seattle_Times=29?= In-Reply-To: References: <1614190127.1780.18.camel@moondog> <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> <348787ce-6284-45a7-cda9-491b89baf126@sydex.com> Message-ID: The worst were the Fry's sales people on the floor that would ignore you, then badger you to let them write a sale up so they'd get sales credit if you made the mistake of asking them where something was. From cclist at sydex.com Wed Feb 24 22:26:26 2021 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 24 Feb 2021 20:26:26 -0800 Subject: =?UTF-8?Q?Re=3a_Funky_electronics_chain_Fry=e2=80=99s_is_no_more_?= =?UTF-8?Q?=28Seattle_Times=29?= In-Reply-To: References: <1614190127.1780.18.camel@moondog> <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> <348787ce-6284-45a7-cda9-491b89baf126@sydex.com> Message-ID: <6af57a57-2a94-fe28-4af4-b352bb5e0db7@sydex.com> On 2/24/21 7:51 PM, Al Kossow via cctalk wrote: > On 2/24/21 7:38 PM, Chuck Guzis via cctalk wrote: > >> The cashiers, of course, were minimum-wage and so had no idea of what >> was passing in front of them. > > They also had a no questions asked returns policy, which people abused. > > When something was returned, they'd rebag it and put it back on the shelf. Definitely saw my share of that. --Chuck From jwsmail at jwsss.com Wed Feb 24 22:29:50 2021 From: jwsmail at jwsss.com (jim stephens) Date: Wed, 24 Feb 2021 20:29:50 -0800 Subject: =?UTF-8?Q?Re=3a_Funky_electronics_chain_Fry=e2=80=99s_is_no_more_?= =?UTF-8?Q?=28Seattle_Times=29?= In-Reply-To: References: <1614190127.1780.18.camel@moondog> <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> <348787ce-6284-45a7-cda9-491b89baf126@sydex.com> Message-ID: On 2/24/2021 8:07 PM, Al Kossow via cctalk wrote: > > The worst were the Fry's sales people on the floor that would ignore > you, then badger > you to let them write a sale up so they'd get sales credit if you made > the mistake > of asking them where something was. > I always track down the Microcenter guys to get one of them to put one of their tags on my stuff, even the small stuff.? They are usually helpful or will find someone if they don't know.? I never ran into any @ Frys, as when I was going there, I always knew where things were, or just wondered till I found it if they moved it. The real collapse is the swap meets where the vendors could dump their quota merchandise that they had to take to maintain pricing structures.? That channel was BS, but at least in southern CA there were a few swap meets with vendors who would bring a lot of stuff to sell.? Then you could get the odds and ends @ a Frys run later in the afternoon after lunch. I quit going because I couldn't walk well, and there were no scooters or places I could take a spell to rest and continue. I'll miss the one in Anaheim that had the Space Shuttle theme (closed quite some time ago).? The one in Fountain Valley was smaller, but I had transitioned to buying via online and Microcenter runs plus direct from China quite a while ago. Still miss them as that capability in the community means there will be less tinkering and work (and probably is) than there was. Though a lot of the business damage was self inflicted on themselves. One thing that the reporting so far on the subject misses, though people talk about it is that there won't be much of any liquidation sales as there is probably little left of any merchandise to liquidate.? That's how you go out of business, not in the case COVID. thanks Jim From aek at bitsavers.org Wed Feb 24 22:34:16 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 24 Feb 2021 20:34:16 -0800 Subject: =?UTF-8?Q?Re=3a_Funky_electronics_chain_Fry=e2=80=99s_is_no_more_?= =?UTF-8?Q?=28Seattle_Times=29?= In-Reply-To: References: <1614190127.1780.18.camel@moondog> <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> <348787ce-6284-45a7-cda9-491b89baf126@sydex.com> Message-ID: On 2/24/21 8:29 PM, jim stephens via cctalk wrote: > > > there won't be much of any liquidation sales because they hadn't been paying vendors, who took all their stuff back that's why the shelves were empty, no one would give them any stock after that started to happen well over a year ago From gavin at learn.bio Wed Feb 24 22:53:11 2021 From: gavin at learn.bio (Gavin Scott) Date: Wed, 24 Feb 2021 22:53:11 -0600 Subject: =?UTF-8?Q?Re=3A_Funky_electronics_chain_Fry=E2=80=99s_is_no_more_=28Seat?= =?UTF-8?Q?tle_Times=29?= In-Reply-To: References: <1614190127.1780.18.camel@moondog> <77C0CCAA-6198-4AB6-9D44-5BE67342F6BA@avanthar.com> <348787ce-6284-45a7-cda9-491b89baf126@sydex.com> Message-ID: On Wed, Feb 24, 2021 at 10:07 PM Al Kossow via cctalk wrote: > The worst were the Fry's sales people on the floor that would ignore you, then badger > you to let them write a sale up so they'd get sales credit if you made the mistake > of asking them where something was. And of course that process required them to get you over to the computer, ask for your phone number, enter the item#, and wait for the LaserJet to spit out the proto-invoice. The dumb/lazy ones would then hand you the paper along with the item and tell you to show it to the cashier. Of course you had the item so you could just throw the paper away and they would get nothing. The crafty ones though would give you the invoice and then walk the item up to behind the register area where the cashier would have to go retrieve it so you were stuck. Basically you wanted to avoid interacting with them if possible. The fact that most stores had the ability to have 80 active cashiers has to be some sort of record, though I don't think I ever saw the registers on the far side get much use even at Christmas. And then there was the "Fry's seal of quality" as we called the return/restock slip plastered to items on the shelf that had already been returned (at least) once. No sane person ever touched those unless completely desperate. My first Fry's story though comes from the early 1980s when I was visiting HP in Cupertino and went to the original Sunnyvale Fry's and only had a check for payment and they weren't going to take an out of town check until they asked what I was in the bay area for and I said "visiting HP" and then it was "oh, that will be fine then". It says something about HP's reputation at the time that even their customers were considered more trustworthy by a Fry's manager. I also remember on that visit that the aisle-long magazine rack at Fry's had many different nerdy publications but only two which rated an entire double column of rack slots. They were Byte and Penthouse IIRC. We all had a love/hate relationship with Fry's, but they were an institution and will be missed. From spacewar at gmail.com Thu Feb 25 01:40:33 2021 From: spacewar at gmail.com (Eric Smith) Date: Thu, 25 Feb 2021 00:40:33 -0700 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> Message-ID: On Wed, Feb 24, 2021 at 7:06 AM Chris Zach via cctalk wrote: > Yes, the TM02 and TM03 formatters allowed MASSBUS to connect to Pertec > drives, but I don't think you could run a tape drive and a disk drive on > the same MASSBUS channel anyway. Wonder why, technically the MASSBUS > cable is just an extension of the Unibus, so it shouldn't matter much > what combination of cables you used. Maybe they just wrote different > drivers or something. > There's nothing in the hardware that prevents it from being done, but DEC OSes don't support it, and it's generally not a good idea. Tape activity would block disk activity, because it doesn't have anything like modern "tagged command queuing". From cclist at sydex.com Thu Feb 25 10:26:39 2021 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 25 Feb 2021 08:26:39 -0800 Subject: FW: List your old computer In-Reply-To: <01RVZU4PV0WW8ZGJOV@beyondthepale.ie> References: <01RVZU4PV0WW8ZGJOV@beyondthepale.ie> Message-ID: <049f86e1-01ed-8000-112d-78e34caf6b60@sydex.com> On 2/25/21 2:05 AM, Peter Coghlan wrote: > Chuck Guzis wrote: > I don't think so. My Raspberry Pi running Linux becomes choked by memory leaks > when I leave it running more than a few months. No amount of killing processes > or other fiddling with the operating system tools available allows it to > recover and the only alternative I can find is to reboot it. My VAX/ALPHA > machines/clusters just keep on trucking until the next power failure. I suppose it depends on what's being done. I've got an OrangePi PC running headless that's nothing more than an email relay and an Internet radio server. Until we had power cuts because of the summer wildfires, it ran more than a year. It's been running since power returned. I've got a OPi Zero hooked to a stereo system (headless again) running nothing more than mplayer. Various modems/routers and other appliances have been running BusyBox as an embedded OS. They pretty much escape notice. --Chuck From erik at baigar.de Thu Feb 25 11:39:22 2021 From: erik at baigar.de (erik at baigar.de) Date: Thu, 25 Feb 2021 17:39:22 +0000 Subject: FW: List your old computer Message-ID: <1614271162403.null> Hm, just adding that my venerable SUN SPARC UII runs WEB server, ssh, web proxy, sub-version, and is my "cloud" via rsync and of course serves email. Over the last 7 years it got rebooted only twice, because the provider needed to relocate it in the server farm and during one of these reboots we replaced a failed disc in the array. I am pretty sure it would have ran without reboot the full 7 years with one good disc left... From paulkoning at comcast.net Thu Feb 25 11:14:51 2021 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 25 Feb 2021 12:14:51 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: <20210224001606.xm6edrd3xkdyf44t@lug-owl.de> <84569347-ce4f-25cf-bc4d-eaa5136196a6@sydex.com> <566388468.3201034.1614163829891@mail.yahoo.com> Message-ID: <543DE437-80E4-476D-A6C2-907775DF8B60@comcast.net> > On Feb 25, 2021, at 2:40 AM, Eric Smith via cctalk wrote: > > On Wed, Feb 24, 2021 at 7:06 AM Chris Zach via cctalk > wrote: > >> Yes, the TM02 and TM03 formatters allowed MASSBUS to connect to Pertec >> drives, but I don't think you could run a tape drive and a disk drive on >> the same MASSBUS channel anyway. Wonder why, technically the MASSBUS >> cable is just an extension of the Unibus, so it shouldn't matter much >> what combination of cables you used. Maybe they just wrote different >> drivers or something. >> > > There's nothing in the hardware that prevents it from being done, but DEC > OSes don't support it, and it's generally not a good idea. Tape activity > would block disk activity, because it doesn't have anything like modern > "tagged command queuing". I know most DEC OS don't support this but I'm pretty sure that at least one of them does. Not sure which. A given Massbus can only do one transfer at a time, so yes, a tape transfer in progress would mean you can't start a disk transfer (though you can start the seek). For that matter, if one disk is transfering another can't start either. So if you want max throughput, you want to spread the disks over several massbus adapters, and keep the tape separate. But if you need lots of disk space, you may have to put tape and disk on the same Massbus since any given system has a limit on Massbus adapters (4 for the PDP-11/70?) and unit numbers are 3 bits. For PDP-11 systems, not likely to be an issue. For mainframe (PDP-10), it might be. I know mainframe systems at times had dozens of disk drives. One I used (CDC not DEC) had 22 RP04 class drives. paul From jnc at mercury.lcs.mit.edu Thu Feb 25 12:30:29 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 25 Feb 2021 13:30:29 -0500 (EST) Subject: Massbus - was: Re: VAX 11/750 Message-ID: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> > From: Paul Koning > There's a good reason why the big disks on many DEC machines were Massbus > devices until MSCP arrived. It's quite clear on Unibus PDP-11s, which > needed Massbus both for speed and for a cleaner answer to more-than-18 > bit addressing. I follow the first sentence, but I'm confused by the second, especially "a cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS controller/adapter, the RH11, only has 18-bit addressing on the main memory side. It does have more than 18-bit addressing on the device side, but so does the RP11 (sort of). Are you thinking of the RH70? That does have access to more than 2^18 bytes of main memory, but that's because it connects to the -11/70 memory bus (as well as the UNIBUS, which is only used for control, not data). Similar questions about the speed point; passing data through an RH11 doesn't increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's because of its connection to the -11/70 memory bus. Noel From paulkoning at comcast.net Thu Feb 25 12:38:52 2021 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 25 Feb 2021 13:38:52 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> Message-ID: > On Feb 25, 2021, at 1:30 PM, Noel Chiappa via cctalk wrote: > >> From: Paul Koning > >> There's a good reason why the big disks on many DEC machines were Massbus >> devices until MSCP arrived. It's quite clear on Unibus PDP-11s, which >> needed Massbus both for speed and for a cleaner answer to more-than-18 >> bit addressing. > > I follow the first sentence, but I'm confused by the second, especially "a > cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS > controller/adapter, the RH11, only has 18-bit addressing on the main memory > side. It does have more than 18-bit addressing on the device side, but so does > the RP11 (sort of). Are you thinking of the RH70? That does have access to > more than 2^18 bytes of main memory, but that's because it connects to the > -11/70 memory bus (as well as the UNIBUS, which is only used for control, not > data). > > Similar questions about the speed point; passing data through an RH11 doesn't > increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's because > of its connection to the -11/70 memory bus. Yes, I meant the RH70. The point is that, without Massbus, the only I/O bus you have in PDP-11 systems is the Unibus (pre-Qbus that is) with all its limitations. The Massbus enabled the creation of the RH70 with its direct memory connection both for more bandwidth and more address bits. So, for example, you can use an RM03 rather than being limited to an RM02 because of the bus performance. And your disks and tapes don't have to fight all the other I/O devices for unibus map slots. paul From cz at alembic.crystel.com Thu Feb 25 12:43:17 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Thu, 25 Feb 2021 13:43:17 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> Message-ID: <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Oh this is fun stuff. Is there a specification write-up anywhere on the MASSBUS overall? For example I wonder if the RH70 could do a transfer >128kb at a time. Another is around the RH11: There were two models, the traditional RH11 (which could only do so many words on a DMA transfer) and the RH11-C which could do more words per transaction by basically running the Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full 3600 RPM (and I assume can allow the 2020 to run things like RM80's). Another item I always wondered about was the RH11's support of two unibuses. I think the idea was to do the data transfers on the second bus right to an 11/45's FASTBUS memory without worrying about DMA timeouts while running the control and status registers on the normal UNIBUS (which wouldn't block other devices). I wonder, does the MBA on an 11/70 use similar cards to an RH11? C On 2/25/2021 1:30 PM, Noel Chiappa via cctalk wrote: > > From: Paul Koning > > > There's a good reason why the big disks on many DEC machines were Massbus > > devices until MSCP arrived. It's quite clear on Unibus PDP-11s, which > > needed Massbus both for speed and for a cleaner answer to more-than-18 > > bit addressing. > > I follow the first sentence, but I'm confused by the second, especially "a > cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS > controller/adapter, the RH11, only has 18-bit addressing on the main memory > side. It does have more than 18-bit addressing on the device side, but so does > the RP11 (sort of). Are you thinking of the RH70? That does have access to > more than 2^18 bytes of main memory, but that's because it connects to the > -11/70 memory bus (as well as the UNIBUS, which is only used for control, not > data). > > Similar questions about the speed point; passing data through an RH11 doesn't > increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's because > of its connection to the -11/70 memory bus. > > Noel > From billdegnan at gmail.com Thu Feb 25 12:49:04 2021 From: billdegnan at gmail.com (Bill Degnan) Date: Thu, 25 Feb 2021 13:49:04 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Message-ID: On Thu, Feb 25, 2021 at 1:43 PM Chris Zach via cctalk wrote: > Oh this is fun stuff. Is there a specification write-up anywhere on the > MASSBUS overall? > > For example I wonder if the RH70 could do a transfer >128kb at a time. > Another is around the RH11: There were two models, the traditional RH11 > (which could only do so many words on a DMA transfer) and the RH11-C > which could do more words per transaction by basically running the > Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full 3600 > RPM (and I assume can allow the 2020 to run things like RM80's). > > Another item I always wondered about was the RH11's support of two > unibuses. I think the idea was to do the data transfers on the second > bus right to an 11/45's FASTBUS memory without worrying about DMA > timeouts while running the control and status registers on the normal > UNIBUS (which wouldn't block other devices). I wonder, does the MBA on > an 11/70 use similar cards to an RH11? > > C > > > I have a UNIBUS array of backplanes from an Industrial 11/40 that has a lot of MASBUS controllers in it. Or, I think that's what these are. I removed the backplane chassis from the rack and replaced it with two RL02 drives. https://www.vintagecomputer.net/digital/PDP11-40_industrial11/DEC_industrial11_exp_chassis.jpg From paulkoning at comcast.net Thu Feb 25 12:56:27 2021 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 25 Feb 2021 13:56:27 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Message-ID: <6CBD40E9-1621-41C4-93F0-C02DF64523DB@comcast.net> > On Feb 25, 2021, at 1:43 PM, Chris Zach via cctalk wrote: > > Oh this is fun stuff. Is there a specification write-up anywhere on the MASSBUS overall? > > For example I wonder if the RH70 could do a transfer >128kb at a time. ... I don't know the answer to most of your questions, but this one is easy: "no". The reason is that the transfer is controlled by a 16 bit word count register. paul From michael.99.thompson at gmail.com Thu Feb 25 12:55:35 2021 From: michael.99.thompson at gmail.com (Michael Thompson) Date: Thu, 25 Feb 2021 13:55:35 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: Message-ID: The PDP-10 KL10 at the RCS/RI was used to control a real-time flight simulator at Sikorski. It had one of the RH20 Massbus controllers connected to a DTR01 cabinet holding a DR01 chassis. The DR01 was, I think, connected to a DR11 chassis that had A/D and D/A converters boards inside. You could use the same DTR01 subsystem to connect two PDP-10s together with Massbus, or connect a PDP-10 to a PDP-11 with Massbus. -- Michael Thompson From cz at alembic.crystel.com Thu Feb 25 13:04:54 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Thu, 25 Feb 2021 14:04:54 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Message-ID: That is at least one RH11-AB in there, minus the knucklebusters of course. On 2/25/2021 1:49 PM, Bill Degnan wrote: > > > On Thu, Feb 25, 2021 at 1:43 PM Chris Zach via cctalk > > wrote: > > Oh this is fun stuff. Is there a specification write-up anywhere on the > MASSBUS overall? > > For example I wonder if the RH70 could do a transfer >128kb at a time. > Another is around the RH11: There were two models, the traditional RH11 > (which could only do so many words on a DMA transfer) and the RH11-C > which could do more words per transaction by basically running the > Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full > 3600 > RPM (and I assume can allow the 2020 to run things like RM80's). > > Another item I always wondered about was the RH11's support of two > unibuses. I think the idea was to do the data transfers on the second > bus right to an 11/45's FASTBUS memory without worrying about DMA > timeouts while running the control and status registers on the normal > UNIBUS (which wouldn't block other devices). I wonder, does the MBA on > an 11/70 use similar cards to an RH11? > > C > > > > I have a UNIBUS array of backplanes from an Industrial 11/40 that has a > lot of MASBUS controllers in it.? Or, I think that's what these are.? I > removed the?backplane chassis from the?rack and replaced it with two > RL02 drives. > https://www.vintagecomputer.net/digital/PDP11-40_industrial11/DEC_industrial11_exp_chassis.jpg > From cz at alembic.crystel.com Thu Feb 25 13:06:36 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Thu, 25 Feb 2021 14:06:36 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Message-ID: <6e1c3854-7bac-7715-ee22-6017e1d90474@alembic.crystel.com> In answer to my own question: No it does not based on a bit of review. Looks like unique cards to the 11/70. C On 2/25/2021 1:43 PM, Chris Zach via cctalk wrote: > Oh this is fun stuff. Is there a specification write-up anywhere on the > MASSBUS overall? > > For example I wonder if the RH70 could do a transfer >128kb at a time. > Another is around the RH11: There were two models, the traditional RH11 > (which could only do so many words on a DMA transfer) and the RH11-C > which could do more words per transaction by basically running the > Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full 3600 > RPM (and I assume can allow the 2020 to run things like RM80's). > > Another item I always wondered about was the RH11's support of two > unibuses. I think the idea was to do the data transfers on the second > bus right to an 11/45's FASTBUS memory without worrying about DMA > timeouts while running the control and status registers on the normal > UNIBUS (which wouldn't block other devices). I wonder, does the MBA on > an 11/70 use similar cards to an RH11? > > C > > > On 2/25/2021 1:30 PM, Noel Chiappa via cctalk wrote: >> ???? > From: Paul Koning >> >> ???? > There's a good reason why the big disks on many DEC machines >> were Massbus >> ???? > devices until MSCP arrived.? It's quite clear on Unibus >> PDP-11s, which >> ???? > needed Massbus both for speed and for a cleaner answer to >> more-than-18 >> ???? > bit addressing. >> >> I follow the first sentence, but I'm confused by the second, >> especially "a >> cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS >> controller/adapter, the RH11, only has 18-bit addressing on the main >> memory >> side. It does have more than 18-bit addressing on the device side, but >> so does >> the RP11 (sort of). Are you thinking of the RH70? That does have >> access to >> more than 2^18 bytes of main memory, but that's because it connects to >> the >> -11/70 memory bus (as well as the UNIBUS, which is only used for >> control, not >> data). >> >> Similar questions about the speed point; passing data through an RH11 >> doesn't >> increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's >> because >> of its connection to the -11/70 memory bus. >> >> ??? Noel >> From aek at bitsavers.org Thu Feb 25 14:27:36 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 25 Feb 2021 12:27:36 -0800 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Message-ID: On 2/25/21 10:43 AM, Chris Zach via cctalk wrote: > Oh this is fun stuff. Is there a specification write-up anywhere on the MASSBUS overall? there is some documentation on bitsavers the register descriptions were intentionally obfuscated to prevent cloning that was figured out to make SIMH work the CDC drive interface was also slightly modified for the same purpose From derschjo at gmail.com Thu Feb 25 14:37:25 2021 From: derschjo at gmail.com (Josh Dersch) Date: Thu, 25 Feb 2021 12:37:25 -0800 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Message-ID: On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk wrote: > On 2/25/21 10:43 AM, Chris Zach via cctalk wrote: > > Oh this is fun stuff. Is there a specification write-up anywhere on the > MASSBUS overall? > > there is some documentation on bitsavers > > the register descriptions were intentionally obfuscated to prevent cloning > that was figured out to make SIMH work > Interesting... Is this obfuscation documented anywhere (beyond looking at SIMH code?) I was working on an RH11/RPxx emulation for the Unibone that was partially working (and that I should really get back to...) - Josh > > the CDC drive interface was also slightly modified for the same purpose > From glg at grebus.com Thu Feb 25 13:47:36 2021 From: glg at grebus.com (Gary Grebus) Date: Thu, 25 Feb 2021 14:47:36 -0500 Subject: archive of DEC Notes In-Reply-To: <8D9557BE-7BB9-4379-BE15-B3138CD646EB@comcast.net> References: <8D9557BE-7BB9-4379-BE15-B3138CD646EB@comcast.net> Message-ID: <7e853dd5-e78f-71b3-d2c9-7c483a7da22e@grebus.com> On 2/24/21 3:27 PM, Paul Koning wrote: > > >> On Feb 24, 2021, at 9:08 AM, Antonio Carlini via cctalk wrote: >> >> On 24/02/2021 03:26, Eric Smith via cctalk wrote: >>> Does anyone have contact information for the proprietor of this site: >>> http://www.activityclub.org/decnotes/ >>> The site has an index of messages archived from DEC's internal "Notes" >>> (kind of their equivalent of UseNet). >>> >>> It appears from the "Download this site" page that at one time it was >>> possible to download an archive of the actual content, but the hosting used >>> for that only provides one week of free hosting, which has expired. >>> >>> I don't need the entire archive (though I'd like to get it), but I'd >>> especially like to get messages from milkwy::23class_semiconductor and >>> ricks::decschips. >> >> Well if they ever show up, I'd be interested :-). >> >> >> That archive was largely incomplete: it had the message titles but very few of the actual messages. There were some rather harsh negative comments on an FB group when someone pointed to it. Obviously some people thought that when they were writing their original comments that they would be kept private to the 100,000+ Digital employees :-) > > The more significant issue may be that DEC, and its successor companies, might have objections to the public posting of company confidential material. > > Too bad only a few things were archived. I looked for myself and found exactly one notesfile ("fddi") with saved content, which made for some fun reading. But other notesfiles that would actually be more interesting at this stage, like ones about RSTS, aren't archived. > > I wonder if anyone has the full archive dump. If so I'd love to have that. > > paul > > I found a few of my postings in there from AlphaServer and Digital UNIX days. It is fun being reminded of some of the folks I worked with all those years ago. My other reaction was "I'm sure glad nobody is asking me to remember some of that trivia now". Gary From aek at bitsavers.org Thu Feb 25 15:15:13 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 25 Feb 2021 13:15:13 -0800 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Message-ID: <2cf1e40f-5583-2215-7ff0-a8cd26c3dc82@bitsavers.org> On 2/25/21 12:37 PM, Josh Dersch wrote: > Interesting... Is this obfuscation documented anywhere (beyond looking at SIMH code?) Not that I know of. Thinking about it some more I think that it was the massbus device addresses behind the controllers that weren't documented From paulkoning at comcast.net Thu Feb 25 15:26:49 2021 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 25 Feb 2021 16:26:49 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <2cf1e40f-5583-2215-7ff0-a8cd26c3dc82@bitsavers.org> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> <2cf1e40f-5583-2215-7ff0-a8cd26c3dc82@bitsavers.org> Message-ID: <731F3B04-3BD4-45CC-85B2-48A773B5FBE3@comcast.net> > On Feb 25, 2021, at 4:15 PM, Al Kossow via cctalk wrote: > > On 2/25/21 12:37 PM, Josh Dersch wrote: > >> Interesting... Is this obfuscation documented anywhere (beyond looking at SIMH code?) > Not that I know of. Thinking about it some more I think that it was the massbus device addresses > behind the controllers that weren't documented That rings a bell, for the PDP-11 case. I think there is a mapping from RH11/RH70 CSR offsets to Massbus control bus register addresses; it isn't the natural 1:1 mapping of the low order Unibus address bits being used directly as Massbus register addresses. From the software point of view that won't matter, but if you're trying to build a Massbus device you'd have to know it. I'm pretty sure I've seen that mapping somewhere (in the past 10 years), at least in part, but I no longer remember where. paul From jwsmail at jwsss.com Thu Feb 25 17:04:42 2021 From: jwsmail at jwsss.com (jim stephens) Date: Thu, 25 Feb 2021 15:04:42 -0800 Subject: Pinging Jay West Message-ID: Sent out a request via multiple channels to you WRT a local STL system.? can you give me a call or ping back. sent to your emails, discord and other channels. thanks Jim From radioengr at gmail.com Thu Feb 25 17:43:53 2021 From: radioengr at gmail.com (Rob Doyle) Date: Thu, 25 Feb 2021 16:43:53 -0700 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Message-ID: <9e900b95-0efd-b020-273e-8982d25c91ac@gmail.com> On 2/25/2021 1:37 PM, Josh Dersch via cctalk wrote: > On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk > wrote: > >> On 2/25/21 10:43 AM, Chris Zach via cctalk wrote: >>> Oh this is fun stuff. Is there a specification write-up anywhere on the >> MASSBUS overall? >> >> there is some documentation on bitsavers >> >> the register descriptions were intentionally obfuscated to prevent cloning >> that was figured out to make SIMH work >> > > Interesting... Is this obfuscation documented anywhere (beyond looking at > SIMH code?) I was working on an RH11/RPxx emulation for the Unibone that > was partially working (and that I should really get back to...) > > - Josh I did a lot of reverse engineering of the RP06 and RM05 schematics. The implementation in my KS10 FPGA passes all the DSRPA and DSRMB diagnostics that matter. I didn't simulate all of the sector header hardware or ECC hardware since the disk already does that. The register descriptions are at: https://github.com/KS10FPGA/KS10FPGA/wiki/RPxx-Disk-Simulator https://github.com/KS10FPGA/KS10FPGA/wiki/RH11-Massbus-Disk-Controller https://github.com/KS10FPGA/KS10FPGA/issues/8 Rob Doyle. From elson at pico-systems.com Thu Feb 25 17:49:19 2021 From: elson at pico-systems.com (Jon Elson) Date: Thu, 25 Feb 2021 17:49:19 -0600 Subject: Pinging Jay West In-Reply-To: References: Message-ID: <6038377F.2000900@pico-systems.com> On 02/25/2021 05:04 PM, jim stephens via cctalk wrote: > > Sent out a request via multiple channels to you WRT a > local STL system. can you give me a call or ping back. > > sent to your emails, discord and other channels. > thanks > Jim > Anything I can do for you? Jon From rdawson16 at hotmail.com Thu Feb 25 18:10:59 2021 From: rdawson16 at hotmail.com (Randy Dawson) Date: Fri, 26 Feb 2021 00:10:59 +0000 Subject: Original Intel 8085 training briefcase with tapes Message-ID: Just on a chance, would anybody have the paper workbook that goes with this kit? It is a 8085 SDK board in a briefcase, power supply and tape player that was probably part of a class they presented. Mine works fine, including the Sony Walkman in the case, I am listening to the 10 or more training tapes. The whole kit is pristine, but no paper - the workbook from the kit. Anybody help me on this, or want it? I revisit things now and then, and this is one of them. It may need a new home. Randy From aek at bitsavers.org Thu Feb 25 18:16:26 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 25 Feb 2021 16:16:26 -0800 Subject: ISO IBM flex cables made by Chabin In-Reply-To: <60348130.4050903@pico-systems.com> References: <60157B63.3010300@pico-systems.com> <60348130.4050903@pico-systems.com> Message-ID: On 2/22/21 8:14 PM, Jon Elson wrote: > I have some Chabin TLC cables that have been cut from the paddle boards.? I also have 4 of the SLT-style connectors sawed off of the some > paddle boards. I managed to get some complete cables from Bob Rosenbloom so I think I'm set. It sure would be nice if they wouldn't have used connectors on .125 x .250" centers From cc at alderson.users.panix.com Thu Feb 25 19:55:47 2021 From: cc at alderson.users.panix.com (Rich Alderson) Date: Thu, 25 Feb 2021 20:55:47 -0500 (EST) Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: (message from Josh Dersch via cctalk on Thu, 25 Feb 2021 12:37:25 -0800) References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> Message-ID: <4Dmt6C1ksZzfYm@panix5.panix.com> > Date: Thu, 25 Feb 2021 12:37:25 -0800 > From: Josh Dersch via cctalk > On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk > wrote: >> On 2/25/21 10:43 AM, Chris Zach via cctalk wrote: >>> Oh this is fun stuff. Is there a specification write-up anywhere on the >>> MASSBUS overall? >> there is some documentation on bitsavers >> the register descriptions were intentionally obfuscated to prevent cloning >> that was figured out to make SIMH work > Interesting... Is this obfuscation documented anywhere (beyond looking at > SIMH code?) I was working on an RH11/RPxx emulation for the Unibone that > was partially working (and that I should really get back to...) Hey, Josh! You could ask our friends Keith Perez (Massbus Disk Emulator v1) and Bruce Sherry (MDE v2) about it, or even ask me. The primary obfuscation was a lie in the PDP-11 documentation which swapped the names of two signals; this drove Keith nuts until I found the PDP-10 version, which disagreed with the PDP-11 but agreed with what he saw on th elogic analyzer. I used to remember which two signals were involved; I'd probably be able to recall if I could be arsed to go look at the manuals for a moment. For those who don't know, we decided back in the early days of building Living Computers: Museum + Labs that spinning rust with 40 year old bearings was going to be problematical. Add to that the fact that new media was no longer being produced, and we had to do something. My brilliant friend Keith sat down with a logic analyzer and an RP06 attached to a KL-10, and proceeded to spend the next two years (when not called on for other projects) creating a disk emulator. He used a Rabbit processor for the controller, and about half a dozen PIC processors for scut work; we could provide up to 4 RP06 or RP07 drives at a time to the KL-10s with his prototype. Later, Bruce came on board as the museum was ramping up, and redid the design in a Xilinx chip with VHDL. His was fast enough to support up to 8 RP06 or RP07 drives (the max on a single channel); he also did a variant which could emulate up to 8 Massbus attached tape drives, of the TU78 type. As for operating system support, the only DEC operating system which could put tapes and disks on the same Massbus was TOPS-20. Tops-10 explicitly tells you in the SYSGEN process that disks and tapes must reside on different channels; I believe that ITS follows that same principle. WAITS, although originally a highly divergent offshoot of Tops-10, took the Massbus code from TOPS-20 v5 when it was ported to a KL-10 at SAIL, so could in theory have disk and tape on the same channel. At LCM+L, because the emulators acted as both controllers and peripherals, we had to devote separate channels to disk and tape, even under TOPS-20, but it was the hardware, not the OS, which required that. We also had to use two MDEs on the KL-10 boxes; since dual channel disks were not possible, the front end 11/40 needed its own MDE. We eventually put Bruce's MDEs on the DECSYSTEM-20 (running Tops-10) and the other KL-10 (running WAITS), the PDP-11/70 running Unix v7, the KI-10 based DECsystem-10 running Tops-10 v6.03A, and the MIT-AI KS-10 which was purchased from CZ way back in the early days. (I rebuilt the RM03 power supplies and replaced the HEPA filters on them while Keith was working on the first MDE.) We also sent one to Michael Thompson to repay him for lending us some hardware back in the early days. Rich P.S. We're about 10 days from the 1st anniversary of the closing of LCM+L to the public. Lift a pint in memory of the most fun we ever had standing up. From sieler at allegro.com Thu Feb 25 23:14:30 2021 From: sieler at allegro.com (Stan Sieler) Date: Thu, 25 Feb 2021 21:14:30 -0800 Subject: Funky electronics chain Fry?s is no more (Seattle Times) Message-ID: Gavin Scott wrote: > We all had a love/hate relationship with Fry's, but they were an > institution and will be missed. Sometime after his story, Gavin moved to the Bay Area to work for my company. One day, I started to buy something at Fry's and they asked for my phone number. So, I gave the the office number. The salesman entered it, and said "thank you, Mr. Scott". I was still "Gavin Scott" to them 15 years later :) Oh, the "seal of quality". Not only did it scream "do not buy this item", but it was a very useful thing ... although not for reasons Fry's expected. Many times, I'd be looking at some newer tech item (e.g., a 4-bay RAID enclosure), and see that over half of them had the "seal of quality". I quickly developed a rule: two more seals meant: stay away from this product! Stan From lars at nocrew.org Fri Feb 26 01:47:27 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 26 Feb 2021 07:47:27 +0000 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <4Dmt6C1ksZzfYm@panix5.panix.com> (Rich Alderson via cctalk's message of "Thu, 25 Feb 2021 20:55:47 -0500 (EST)") References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> <4Dmt6C1ksZzfYm@panix5.panix.com> Message-ID: <7w7dmvuv74.fsf@junk.nocrew.org> Rich Alderson wrote: > As for operating system support, the only DEC operating system which > could put tapes and disks on the same Massbus was TOPS-20. Tops-10 > explicitly tells you in the SYSGEN process that disks and tapes must > reside on different channels; I believe that ITS follows that same > principle. KS10 ITS has MIT hacked microcode for IO instuctions hardwired to use UBA 1 for disk and UBA 3 for tape. KA10 and KL10 ITS have TM10 I/O bus tape controllers, optionally using a DF10 channel. From toby at telegraphics.com.au Fri Feb 26 07:56:49 2021 From: toby at telegraphics.com.au (Toby Thain) Date: Fri, 26 Feb 2021 08:56:49 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <4Dmt6C1ksZzfYm@panix5.panix.com> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> <4Dmt6C1ksZzfYm@panix5.panix.com> Message-ID: <2a9b644e-e48b-034e-8541-6cc13449fdfe@telegraphics.com.au> On 2021-02-25 8:55 p.m., Rich Alderson via cctalk wrote: > ... > Hey, Josh! You could ask our friends Keith Perez (Massbus Disk Emulator v1) > and Bruce Sherry (MDE v2) about it, or even ask me. > ... > produced, and we had to do something. My brilliant friend Keith sat down with > a logic analyzer and an RP06 attached to a KL-10, and proceeded to spend the > next two years (when not called on for other projects) creating a disk > emulator. ... > > Later, Bruce came on board as the museum was ramping up, and redid the design > in a Xilinx chip with VHDL. ... Are the above projects published? --Toby > > As for operating system support,... > > Rich > > P.S. We're about 10 days from the 1st anniversary of the closing of LCM+L to > the public. Lift a pint in memory of the most fun we ever had standing up. > From lars at nocrew.org Fri Feb 26 08:40:35 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 26 Feb 2021 14:40:35 +0000 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <2a9b644e-e48b-034e-8541-6cc13449fdfe@telegraphics.com.au> (Toby Thain via cctalk's message of "Fri, 26 Feb 2021 08:56:49 -0500") References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> <4Dmt6C1ksZzfYm@panix5.panix.com> <2a9b644e-e48b-034e-8541-6cc13449fdfe@telegraphics.com.au> Message-ID: <7wsg5iuc2k.fsf@junk.nocrew.org> Toby Thain wrote: > Rich Alderson wrote: >> You could ask our friends Keith Perez (Massbus Disk Emulator v1) and >> Bruce Sherry (MDE v2) about it, or even ask me. ... produced, and >> we had to do something. My brilliant friend Keith sat down with a >> logic analyzer and an RP06 attached to a KL-10, and proceeded to >> spend the next two years (when not called on for other projects) >> creating a disk emulator. ... >> >> Later, Bruce came on board as the museum was ramping up, and redid >> the design in a Xilinx chip with VHDL. ... > > Are the above projects published? See here: https://github.com/livingcomputermuseum?tab=repositories From johnhreinhardt at thereinhardts.org Fri Feb 26 08:48:18 2021 From: johnhreinhardt at thereinhardts.org (John H. Reinhardt) Date: Fri, 26 Feb 2021 08:48:18 -0600 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <7wsg5iuc2k.fsf@junk.nocrew.org> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> <4Dmt6C1ksZzfYm@panix5.panix.com> <2a9b644e-e48b-034e-8541-6cc13449fdfe@telegraphics.com.au> <7wsg5iuc2k.fsf@junk.nocrew.org> Message-ID: <6596a3ba-6d10-8aad-ce3c-149f43b9d750@thereinhardts.org> On 2/26/2021 8:40 AM, Lars Brinkhoff via cctalk wrote: > Toby Thain wrote: >> Rich Alderson wrote: >>> You could ask our friends Keith Perez (Massbus Disk Emulator v1) and >>> Bruce Sherry (MDE v2) about it, or even ask me. ... produced, and >>> we had to do something. My brilliant friend Keith sat down with a >>> logic analyzer and an RP06 attached to a KL-10, and proceeded to >>> spend the next two years (when not called on for other projects) >>> creating a disk emulator. ... >>> >>> Later, Bruce came on board as the museum was ramping up, and redid >>> the design in a Xilinx chip with VHDL. ... >> Are the above projects published? > See here: > > https://github.com/livingcomputermuseum?tab=repositories Also here is Rich's announcement on DEC-10 day of 2017 > Happy DEC-10 Day! > > It is my honor to announce that we at Living Computers: Museum + Labs > are releasing to the computing community our Massbus Disk Emulator > and all the associated software. This device connects via Massbus > cables to the RH10 and RH20 interfaces on KI-10 and KL-10 systems, to > the RH11 interface on KS-10 and small PDP-11 systems (including the > front end 11/40 on the KL-10), and to the RH70 on the PDP-11/70. The > MDE provides up to 8 emulated RP06 or RP07 disks (represented by disk > files in the format used by the SimH emulation of these systems). > > We expect that it will also work with the RH780 on the VAX-11/780 and > VAX-11/785 although we have not yet tested it in this configuration. > > The original MDE was designed by Keith Perez in 2005, and emulated up > to four RP06 drives connected to a KL-10. The current generation was > a redesign by Bruce Sherry in conjunction with the restoration of our > DECsystem-1070 in 2012, and initially provided eight RP06 drives on > the RH10. It has undergone continual development, with associated > software created for us by Bob Armstrong, and is now being opened up > for the use of the relevant communities. > > To this end, we have placed the design files for the hardware and the > source files for the software to interface with it, along with our > library of Universal Peripheral Emulator routines, on public access > repositories at Github. The URLs for these repositories are > > https://github.com/livingcomputermuseum/MDE2 > > https://github.com/livingcomputermuseum/MBS > > https://github.com/livingcomputermuseum/UPELIB > > These are released under a very liberal license which will allow for > free use of the MDE by any interested party. > > Happy Dec-10 Day! > > Rich > > > Richard Alderson, Sr. Systems Engineer > Living Computers: Museum + Labs > 2245 1st Avenue S > Seattle, WA 98134 > > Cell: (206) 465-2916 > Desk: (206) 342-2239 > > http://www.livingcomputerss.org/ > > -- John H. Reinhardt From toby at telegraphics.com.au Fri Feb 26 09:07:02 2021 From: toby at telegraphics.com.au (Toby Thain) Date: Fri, 26 Feb 2021 10:07:02 -0500 Subject: Massbus - was: Re: VAX 11/750 In-Reply-To: <7wsg5iuc2k.fsf@junk.nocrew.org> References: <20210225183029.1F27718C0BF@mercury.lcs.mit.edu> <800f96fa-ff49-eb9b-8e65-fcd5f5176e08@alembic.crystel.com> <4Dmt6C1ksZzfYm@panix5.panix.com> <2a9b644e-e48b-034e-8541-6cc13449fdfe@telegraphics.com.au> <7wsg5iuc2k.fsf@junk.nocrew.org> Message-ID: On 2021-02-26 9:40 a.m., Lars Brinkhoff wrote: > Toby Thain wrote: >> Rich Alderson wrote: >>> You could ask our friends Keith Perez (Massbus Disk Emulator v1) and >>> Bruce Sherry (MDE v2) about it, or even ask me. ... produced, and >>> we had to do something. My brilliant friend Keith sat down with a >>> logic analyzer and an RP06 attached to a KL-10, and proceeded to >>> spend the next two years (when not called on for other projects) >>> creating a disk emulator. ... >>> >>> Later, Bruce came on board as the museum was ramping up, and redid >>> the design in a Xilinx chip with VHDL. ... >> >> Are the above projects published? > > See here: > > https://github.com/livingcomputermuseum?tab=repositories > Very nice, thanks. --T From jwest at classiccmp.org Fri Feb 26 11:58:19 2021 From: jwest at classiccmp.org (jwest at classiccmp.org) Date: Fri, 26 Feb 2021 11:58:19 -0600 Subject: Pinging Jay West In-Reply-To: References: Message-ID: <00bf01d70c68$f7578880$e6069980$@classiccmp.org> Replied yesterday. Will reach out today too ? -----Original Message----- From: cctalk On Behalf Of jim stephens via cctalk Sent: Thursday, February 25, 2021 5:05 PM To: Paul Koning via cctalk Subject: Pinging Jay West Sent out a request via multiple channels to you WRT a local STL system. can you give me a call or ping back. sent to your emails, discord and other channels. thanks Jim From bfranchuk at jetnet.ab.ca Fri Feb 26 12:00:34 2021 From: bfranchuk at jetnet.ab.ca (ben) Date: Fri, 26 Feb 2021 11:00:34 -0700 Subject: FW: List your old computer In-Reply-To: <6036F3F9.5010906@pico-systems.com> References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> <6036F3F9.5010906@pico-systems.com> Message-ID: On 2/24/2021 5:48 PM, Jon Elson via cctalk wrote: > Faster?? The only comparison I have is between my KA630-AA and my > current desktop (Dell Optiplex 980) running Ubuntu. It seems to be > almost 1000 X faster.? I have a program that records environmental data > every 15 seconds.? Then, there are programs that condense and summarize > the data.? The whole run at the end of the year used to take about 30 > minutes.? It runs in about 5 SECONDS on the PC.? (Yes, I know, only 360 X.) > > Jon But it seems boot times get longer and longer. Ben. From jwest at classiccmp.org Fri Feb 26 12:39:46 2021 From: jwest at classiccmp.org (jwest at classiccmp.org) Date: Fri, 26 Feb 2021 12:39:46 -0600 Subject: Electronics Plus Message-ID: <000801d70c6e$c1fce030$45f6a090$@classiccmp.org> In case this link only made it to discord, I'm (re-?)posting here. Cindy has been extremely helpful and generous and giving of her time to all in this hobby. It is a very worthy cause. https://www.gofundme.com/f/electronics-plus Not too much more to hit their goal. Lets see if we can put them over, I'm pretty sure most of us have benefited from her efforts. Cindy, a few things have changed on my end with retirement, but I may be able to get that website back online for you. Please reach out to me directly and I'll check. Best, J From cctalk at gtaylor.tnetconsulting.net Fri Feb 26 12:48:55 2021 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 26 Feb 2021 11:48:55 -0700 Subject: Electronics Plus In-Reply-To: <000801d70c6e$c1fce030$45f6a090$@classiccmp.org> References: <000801d70c6e$c1fce030$45f6a090$@classiccmp.org> Message-ID: On 2/26/21 11:39 AM, jwest--- via cctalk wrote: > Cindy, a few things have changed on my end with retirement, but I may > be able to get that website back online for you. Please reach out to > me directly and I'll check. Feel free to email me directly if you need some hosting; DNS, web, email, etc. -- Grant. . . . unix || die From imp at bsdimp.com Fri Feb 26 13:00:05 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 26 Feb 2021 12:00:05 -0700 Subject: Electronics Plus In-Reply-To: <000801d70c6e$c1fce030$45f6a090$@classiccmp.org> References: <000801d70c6e$c1fce030$45f6a090$@classiccmp.org> Message-ID: On Fri, Feb 26, 2021 at 11:39 AM jwest--- via cctalk wrote: > In case this link only made it to discord, I'm (re-?)posting here. > I saw bits and pieces there, but missed the bigger context.... Woof! Definitely worth it... https://www.gofundme.com/f/electronics-plus I noticed someone named Richard Thompson just donated. If you are that person, used to live in the Jemez mountains and hacked on Rainbow stuff back in the day, please contact me... Warner From aek at bitsavers.org Fri Feb 26 13:18:01 2021 From: aek at bitsavers.org (Al Kossow) Date: Fri, 26 Feb 2021 11:18:01 -0800 Subject: Electronics Plus In-Reply-To: References: <000801d70c6e$c1fce030$45f6a090$@classiccmp.org> Message-ID: On 2/26/21 11:00 AM, Warner Losh via cctalk wrote: > I noticed someone named Richard Thompson just donated. Richard runs Manx and the Computer Graphics Museum in SLC https://manx-docs.org/about.php From elson at pico-systems.com Fri Feb 26 13:33:22 2021 From: elson at pico-systems.com (Jon Elson) Date: Fri, 26 Feb 2021 13:33:22 -0600 Subject: FW: List your old computer In-Reply-To: References: <08a001d70a7a$9a705560$cf510020$@internode.on.net> <08b301d70a7a$fe6097b0$fb21c710$@internode.on.net> <6036F3F9.5010906@pico-systems.com> Message-ID: <60394D02.5040303@pico-systems.com> On 02/26/2021 12:00 PM, ben via cctalk wrote: > On 2/24/2021 5:48 PM, Jon Elson via cctalk wrote: > >> Faster? The only comparison I have is between my >> KA630-AA and my current desktop (Dell Optiplex 980) >> running Ubuntu. It seems to be almost 1000 X faster. I >> have a program that records environmental data every 15 >> seconds. Then, there are programs that condense and >> summarize the data. The whole run at the end of the year >> used to take about 30 minutes. It runs in about 5 SECONDS >> on the PC. (Yes, I know, only 360 X.) >> >> Jon > But it seems boot times get longer and longer. > Ben. > > A stock Ubuntu 12.04 on my laptop (with SSD) boots up, I can log in and be on the desktop in 15 seconds. That is good enough for me. I have to run Widows 10 for tax software, and on a VM and magnetic drive, that is quite slow. Jon From linimon at lonesome.com Fri Feb 26 18:57:40 2021 From: linimon at lonesome.com (Mark Linimon) Date: Sat, 27 Feb 2021 00:57:40 +0000 Subject: Electronics Plus In-Reply-To: References: <000801d70c6e$c1fce030$45f6a090$@classiccmp.org> Message-ID: <20210227005740.GA24242@lonesome.com> On Fri, Feb 26, 2021 at 12:00:05PM -0700, Warner Losh via cctalk wrote: > I noticed someone named Richard Thompson just donated. If you are that > person, used to live in the Jemez mountains and hacked on Rainbow stuff > back in the day, please contact me... Or, if you are the Richard Thompson, guitar virtuoso, I will be *very* impressed. mcl From cisin at xenosoft.com Fri Feb 26 19:05:08 2021 From: cisin at xenosoft.com (Fred Cisin) Date: Fri, 26 Feb 2021 17:05:08 -0800 (PST) Subject: Electronics Plus In-Reply-To: <20210227005740.GA24242@lonesome.com> References: <000801d70c6e$c1fce030$45f6a090$@classiccmp.org> <20210227005740.GA24242@lonesome.com> Message-ID: >> I noticed someone named Richard Thompson just donated. If you are that >> person, used to live in the Jemez mountains and hacked on Rainbow stuff >> back in the day, please contact me... > On Sat, 27 Feb 2021, Mark Linimon via cctalk wrote: > Or, if you are the Richard Thompson, guitar virtuoso, I will be *very* > impressed. Not as impressed as I would be if it were to be the same Richard Thompson who went to my high school, and died in a car crash 40 years ago. From aek at bitsavers.org Sat Feb 27 09:44:20 2021 From: aek at bitsavers.org (Al Kossow) Date: Sat, 27 Feb 2021 07:44:20 -0800 Subject: DOS/Batch 10 source disks Message-ID: <45249a9e-b513-f0ed-0eb5-9bbeb5c9128e@bitsavers.org> Did someone on the list buy the pair of source RK05's on eBay? https://www.ebay.com/itm/PDP-11-Program-Monitor-V10-02-CUSP-and-Device-Driver-2xRK05-DEC-Digital-PDP/353391043210 I bought the fortran source disk that was listed at the same time, but didn't go after these because of the cost and I may already have it in the archived DECtapes on bitsavers. From derschjo at gmail.com Sat Feb 27 21:36:58 2021 From: derschjo at gmail.com (Josh Dersch) Date: Sat, 27 Feb 2021 19:36:58 -0800 Subject: ISO: Stabilization feet for DEC H960 rack Message-ID: I realize these are uncommon; curious if anyone has a spare pair somewhere (hey, that rhymes.) I'd like to be able to pull out the CPU on my 11/70 without worrying about the whole thing tipping over and crushing people I care about. It's the little things, really... Thanks! - Josh From ethan.dicks at gmail.com Sat Feb 27 21:54:09 2021 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Sat, 27 Feb 2021 22:54:09 -0500 Subject: ISO: Stabilization feet for DEC H960 rack In-Reply-To: References: Message-ID: On Sat, Feb 27, 2021 at 10:37 PM Josh Dersch via cctalk wrote: > I realize these are uncommon; curious if anyone has a spare pair somewhere > (hey, that rhymes.) I'd like to be able to pull out the CPU on my 11/70 > without worrying about the whole thing tipping over and crushing people I > care about. It's the little things, really... I think they've come up before as something that would be worthwhile to cast a couple dozen of. I don't have any that aren't firmly attached to a full rack, and I have racks with none. -ethan From derschjo at gmail.com Sat Feb 27 22:15:50 2021 From: derschjo at gmail.com (Josh Dersch) Date: Sat, 27 Feb 2021 20:15:50 -0800 Subject: Any interest in a Floating Point Systems AP-120 array processor? Message-ID: I picked this up a number of years ago for reasons that entirely escape me. It's certainly neat, but I don't see myself ever actually using it and it's large and heavy. Documented here: http://bitsavers.trailing-edge.com/pdf/fps/7259-02_AP-120B_procHbk.pdf Mine appears to have a DEC-style interface but I'm unsure what it talks to on the DEC side of things. I can take pictures if there's interest, but it's fairly nondescript, just a large white box with rack-mount ears and a small panel with some switches on it. It's in the Seattle area if anyone wants it, and it's free! Shipping is... not something I really want to think about right now. - Josh From linimon at lonesome.com Sat Feb 27 22:21:05 2021 From: linimon at lonesome.com (Mark Linimon) Date: Sun, 28 Feb 2021 04:21:05 +0000 Subject: Any interest in a Floating Point Systems AP-120 array processor? In-Reply-To: References: Message-ID: <20210228042105.GA29948@lonesome.com> On Sat, Feb 27, 2021 at 08:15:50PM -0800, Josh Dersch via cctalk wrote: > I picked this up a number of years ago for reasons that entirely > escape me. Those are the best reasons!!!1 :-) mcl From steven at malikoff.com Sat Feb 27 23:28:22 2021 From: steven at malikoff.com (steven at malikoff.com) Date: Sun, 28 Feb 2021 15:28:22 +1000 Subject: ISO: Stabilization feet for DEC H960 rack In-Reply-To: References: Message-ID: <6fc152ba960ac01e87c2b6b5d0e2219f.squirrel@webmail04.register.com> Josh said > I realize these are uncommon; curious if anyone has a spare pair somewhere > (hey, that rhymes.) I'd like to be able to pull out the CPU on my 11/70 > without worrying about the whole thing tipping over and crushing people I > care about. It's the little things, really... I made two pairs of repo ones that turned out beautifully. They have a welded steel bar load-bearing skeleton and adjustable pad like the original, and a 3D-printed shell sprayed in satin black that completes the aesthetics and follows the "six foot rule" in that they probably wouldn't be picked out from the originals from a few feet away. I have yet to machine the bolt head tapers to the originals but lost the photo of one that was posted here some time ago. I got a lot of help from cctalk on the dimensions of the foot a while back, but some of these are still a tiny bit inaccurate, but I can't expect the average person to have a surface table, height gauge, angle gauge etc. I was planning to make a few pairs for sale some day. If there was sufficient interest I can get to fabricating the cutting, bending and welding jigs to produce then more quickly than the completely hand-made ones I have done. The biggest problem is I'm not sure how much they would cost. Also I have not yet laser-cut the accompanying kick panel. I have the dimensions for that but I would rather measure one myself before committing to those. http://www.surfacezero.com/g503/data/500/Stabiliser_feet_02.png http://www.surfacezero.com/g503/data/500/Stabiliser_feet_01.png Steve. From cramcram at gmail.com Sat Feb 27 22:39:45 2021 From: cramcram at gmail.com (Marc Howard) Date: Sat, 27 Feb 2021 20:39:45 -0800 Subject: ISO: Stabilization feet for DEC H960 rack In-Reply-To: References: Message-ID: I love to buy some if anyone ever makes reproductions. Marc On Sat, Feb 27, 2021 at 7:37 PM Josh Dersch via cctalk < cctalk at classiccmp.org> wrote: > I realize these are uncommon; curious if anyone has a spare pair somewhere > (hey, that rhymes.) I'd like to be able to pull out the CPU on my 11/70 > without worrying about the whole thing tipping over and crushing people I > care about. It's the little things, really... > > Thanks! > - Josh > From jnc at mercury.lcs.mit.edu Sun Feb 28 01:58:11 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 28 Feb 2021 02:58:11 -0500 (EST) Subject: ISO: Stabilization feet for DEC H960 rack Message-ID: <20210228075811.A229E18C096@mercury.lcs.mit.edu> > From: Steven Malikoff > I have yet to machine the bolt head tapers to the originals but lost > the photo of one that was posted here some time ago. By "bolt head tapers", do you mean the special bolts with countersunk heads, or the countersunk holes in the extension feet? Whichever it was, I can provide photos and/or measurements, as needed. Noel From robert.jarratt at ntlworld.com Sun Feb 28 02:07:55 2021 From: robert.jarratt at ntlworld.com (Rob Jarratt) Date: Sun, 28 Feb 2021 08:07:55 -0000 Subject: ISO: Stabilization feet for DEC H960 rack In-Reply-To: References: Message-ID: <014f01d70da8$d26d6350$774829f0$@ntlworld.com> I would buy some too. > -----Original Message----- > From: cctalk On Behalf Of Marc Howard via > cctalk > Sent: 28 February 2021 04:40 > To: Josh Dersch ; General Discussion: On-Topic and > Off-Topic Posts > Subject: Re: ISO: Stabilization feet for DEC H960 rack > > I love to buy some if anyone ever makes reproductions. > > Marc > > On Sat, Feb 27, 2021 at 7:37 PM Josh Dersch via cctalk < > cctalk at classiccmp.org> wrote: > > > I realize these are uncommon; curious if anyone has a spare pair > > somewhere (hey, that rhymes.) I'd like to be able to pull out the CPU > > on my 11/70 without worrying about the whole thing tipping over and > > crushing people I care about. It's the little things, really... > > > > Thanks! > > - Josh > > From tsg at bonedaddy.net Sun Feb 28 07:14:45 2021 From: tsg at bonedaddy.net (Todd Goodman) Date: Sun, 28 Feb 2021 08:14:45 -0500 Subject: ISO: Stabilization feet for DEC H960 rack In-Reply-To: <6fc152ba960ac01e87c2b6b5d0e2219f.squirrel@webmail04.register.com> References: <6fc152ba960ac01e87c2b6b5d0e2219f.squirrel@webmail04.register.com> Message-ID: <2dda4c71-94b2-3713-6af8-72d26b5bc3c7@bonedaddy.net> I'd buy at least a couple sets (and likely more) On 2/28/2021 12:28 AM, Steve Malikoff via cctalk wrote: > Josh said >> I realize these are uncommon; curious if anyone has a spare pair somewhere >> (hey, that rhymes.) I'd like to be able to pull out the CPU on my 11/70 >> without worrying about the whole thing tipping over and crushing people I >> care about. It's the little things, really... > I made two pairs of repo ones that turned out beautifully. They have a welded steel bar > load-bearing skeleton and adjustable pad like the original, and a 3D-printed shell sprayed > in satin black that completes the aesthetics and follows the "six foot rule" in that they > probably wouldn't be picked out from the originals from a few feet away. I have yet to > machine the bolt head tapers to the originals but lost the photo of one that was posted here > some time ago. > > I got a lot of help from cctalk on the dimensions of the foot a while back, but some of > these are still a tiny bit inaccurate, but I can't expect the average person to have a surface > table, height gauge, angle gauge etc. > > I was planning to make a few pairs for sale some day. If there was sufficient interest I can > get to fabricating the cutting, bending and welding jigs to produce then more quickly than the > completely hand-made ones I have done. The biggest problem is I'm not sure how much they > would cost. Also I have not yet laser-cut the accompanying kick panel. I have the dimensions for > that but I would rather measure one myself before committing to those. > > http://www.surfacezero.com/g503/data/500/Stabiliser_feet_02.png > http://www.surfacezero.com/g503/data/500/Stabiliser_feet_01.png > > Steve. > > From bill.gunshannon at hotmail.com Sun Feb 28 08:49:41 2021 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sun, 28 Feb 2021 09:49:41 -0500 Subject: ISO: Stabilization feet for DEC H960 rack In-Reply-To: <2dda4c71-94b2-3713-6af8-72d26b5bc3c7@bonedaddy.net> References: <6fc152ba960ac01e87c2b6b5d0e2219f.squirrel@webmail04.register.com> <2dda4c71-94b2-3713-6af8-72d26b5bc3c7@bonedaddy.net> Message-ID: On 2/28/2021 12:28 AM, Steve Malikoff via cctalk wrote: > > http://www.surfacezero.com/g503/data/500/Stabiliser_feet_02.png > http://www.surfacezero.com/g503/data/500/Stabiliser_feet_01.png I have to admit I have never seen anything like that on any of my DEC racks. All of mine had the single foot in the middle that slid out to keep the rack from tipping forward. As a matter of fact, none of my racks even looked like that. Interesting. I just confirmed by looking at the one rack I have left (sure could use one or two more, though. Sorry I gave all mine away) and it definitely doesn't look like that. bill From bobsmithofd at gmail.com Sun Feb 28 12:29:38 2021 From: bobsmithofd at gmail.com (Bob Smith) Date: Sun, 28 Feb 2021 13:29:38 -0500 Subject: Any interest in a Floating Point Systems AP-120 array processor? In-Reply-To: <20210228042105.GA29948@lonesome.com> References: <20210228042105.GA29948@lonesome.com> Message-ID: I recall the FPS AP120B as an add on for PDP11 boxes, 11/45, 11/70 for some serious signal processing apps. bb On Sun, Feb 28, 2021 at 1:48 AM Mark Linimon via cctalk wrote: > > On Sat, Feb 27, 2021 at 08:15:50PM -0800, Josh Dersch via cctalk wrote: > > I picked this up a number of years ago for reasons that entirely > > escape me. > > Those are the best reasons!!!1 > > :-) > > mcl From cz at alembic.crystel.com Sun Feb 28 13:20:33 2021 From: cz at alembic.crystel.com (Chris Zach) Date: Sun, 28 Feb 2021 14:20:33 -0500 Subject: ISO: Stabilization feet for DEC H960 rack In-Reply-To: References: <6fc152ba960ac01e87c2b6b5d0e2219f.squirrel@webmail04.register.com> <2dda4c71-94b2-3713-6af8-72d26b5bc3c7@bonedaddy.net> Message-ID: <3d97c216-1b18-7419-f8ba-a0f7e1fb0d8d@alembic.crystel.com> Yep, I remember having both types (screw on and wheel) over the years, I think the screw ons were on the pdp8. The little short corporate rack of the pdp11V03 has a wheel. They are nice because there is nothing more annoying than having a rack fall over on you. Or have it fall over while you get out of the way, then you have to roll it on its' side to get things out so you can lift it back up. Don't ask me how I know. C On 2/28/2021 9:49 AM, Bill Gunshannon via cctalk wrote: > On 2/28/2021 12:28 AM, Steve Malikoff via cctalk wrote: >> >> http://www.surfacezero.com/g503/data/500/Stabiliser_feet_02.png >> http://www.surfacezero.com/g503/data/500/Stabiliser_feet_01.png > > I have to admit I have never seen anything like that on any of > my DEC racks.? All of mine had the single foot in the middle > that slid out to keep the rack from tipping forward. As a matter > of fact, none of my racks even looked like that.? Interesting. > I just confirmed by looking at the one rack I have left (sure > could use one or two more, though.? Sorry I gave all mine away) > and it definitely doesn't look like that. > > bill > From cclist at sydex.com Sun Feb 28 13:42:54 2021 From: cclist at sydex.com (Chuck Guzis) Date: Sun, 28 Feb 2021 11:42:54 -0800 Subject: ISO: Stabilization feet for DEC H960 rack In-Reply-To: <3d97c216-1b18-7419-f8ba-a0f7e1fb0d8d@alembic.crystel.com> References: <6fc152ba960ac01e87c2b6b5d0e2219f.squirrel@webmail04.register.com> <2dda4c71-94b2-3713-6af8-72d26b5bc3c7@bonedaddy.net> <3d97c216-1b18-7419-f8ba-a0f7e1fb0d8d@alembic.crystel.com> Message-ID: <8d8f9c9e-bb2c-a372-6163-7de661f916cf@sydex.com> On 2/28/21 11:20 AM, Chris Zach via cctalk wrote: > Yep, I remember having both types (screw on and wheel) over the years, I > think the screw ons were on the pdp8. The little short corporate rack of > the pdp11V03 has a wheel. > > They are nice because there is nothing more annoying than having a rack > fall over on you. Or have it fall over while you get out of the way, > then you have to roll it on its' side to get things out so you can lift > it back up. Don't ask me how I know. There's also the "cheap and dirty" type that involves a slide-out projection from under the rack. I have an HP storage array rack with that feature and have used it. Works fine to keep the rack from falling on you and is invisible when not being used. --Chuck