[cctalk] Re: Gb Ethernet and 10Mb links
On 5/29/23 14:03, Antonio Carlini via cctalk wrote: > > I believe the 10Gb standard specifically prohibits autonegotiation, so > 10G should not drop down to 1G or 100Mb/s. Is that maybe only applicable to the 10G standards for optical fibre? According to Wikipedia 10GBASE-T supports autonegotiation: "10GBASE-T cable infrastructure can also be used for 1000BASE-T allowing a gradual upgrade from 1000BASE-T using autonegotiation to select which speed is used." https://en.wikipedia.org/wiki/10_Gigabit_Ethernet#10GBASE-T "The autonegotiation specification was improved in the 1998 release of IEEE 802.3. This was followed by the release of the IEEE 802.3ab Gigabit Ethernet standard in 1999 which specified mandatory autonegotiation for 1000BASE-T. Autonegotiation is also mandatory for 1000BASE-TX and 10GBASE-T implementations." https://en.wikipedia.org/wiki/Autonegotiation#Standardization_and_interoperability
[cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man
On 1/25/23 11:53, Steve Lewis via cctalk wrote: > > And back on the stenography-keyboard like thing -- what about morphing > keys? If a keyboard had actual screens on the keys, and the keys change > (the actual symbol) based on the context of whatever you're doing. I know > we have macros and reprogrammable keyboards, but morphing the actual symbol > on the keys might be neat. A keyboard using small 48x48 pixel OLED screens on each of the keys has been done. It was many years ago and they were super expensive at the time. As a result they were not commercially successful. https://en.wikipedia.org/wiki/Optimus_Maximus_keyboard
[cctalk] Re: 2 sets of IRIX, 2 Indys and I1
On 1/20/23 11:19, Chris via cctalk wrote: > > I have 2 IRIX sets. 15 disk 6.5.4 iinm. And a 3 diak 6.5.6. Have 2 > Indys, 1 is busted up, the 1 I'll wind up keeping for an extended period > probably. 1 Indy has an r5000 I think and a graphics card. The other is > mediocre. Also have an R1000 Impact I2. The first thing to be aware of is that the 3-disk set for 6.5.6 will be just the "overlays" (in SGI terminology). The 15-disk 6.5.4 set will include the base 6.5 distribution (12 disks) plus the 6.5.4 overlays (3 disks). No matter what version of 6.5.x you install, you'll need the same base disks from that 6.5.4 set. Then add the overlays for whichever specific point release you want. > Question is are these versions of Irix suitable. Or couldnI do better. > And on account of SGIs licensing scheme, which attaches a specific os > version to a maxhine (or vice versa), does that entitle me to obtain and > install those specific versions. Put anotjer way if I obtained images > from somewhere, installed the correct versions of Irix, would thoae > machines then be legit? Or am I supposed to pay through the nose for a > subscription or whatever? The machines you have were supported up to 6.5.22, so you can run anything up to that. (And frankly, I don't know why you'd want an earlier 6.5.x release.) After that only the O2, Octane, and newer systems were supported. You can also go with something older than 6.5.x. Both 6.2 and 5.3 are options on the Indys. Only 6.2 would support the R10K Impact system. IRIX 6.5.x likes lots of RAM. Consider 128 MB the minimum, 256 MB is better. (Which doesn't sound like a lot today, but it was 25 years ago when these machines were current!) If you have less RAM, then definitely consider earlier IRIX. The final release was 6.5.30, but that was way back in 2006. Even extended support contracts for those paying the big money ran out sometime around a decade ago. There is simply no way to pay for a license or subscription for any version of IRIX at this point in time. I can't comment on the legalities of it, but "use what you can get" seems to be a common approach in the SGI community as a result. > Take the I2s for instance. Is the hardware any more reliable, > longevity wise, then your average good quality pc? I don't know about longevity. They were high performance systems compared to PCs of the era. The operating system was very stable. They're very different hardware than PCs of that (or any) era. Those are why people still love them today, more than longevity. You're talking about 25-30 year old machines. They will have problems these days. I don't often see SGI stuff discussed on this list. You might get more detailed info from web forums: https://forums.irixnet.org/ https://forums.sgi.sh/ (I'm a user of the irixnet.org forums.)
[cctalk] Re: Restoring unknown format backup tapes
On 12/30/22 15:17, John Herron via cctalk wrote: > This may be a larger conversation than I intend but how would you all > generally start if you ha backup tapes that you wanted to try and > read/restore? > > Supposedly they're Amiga qic tapes. I'm a little worried about the > structural integrity of the tapes. Not knowing what software was used, > would this be a literal job for something like tar via a Linux system? Then > see if I can interpret the dump and sort out files afterwards? It is unlikely that the tapes are in tar format, so tar on Linux won't help. The chance that they are in tar format is much higher if they're from Amix (Amiga Unix) instead of AmigaOS. There is a better possibility that the tapes were created by BRU since AmigaOS 2.x (and maybe later) included a version of that. BRU is now Argest Backup, if you need to go down that road. It is also possible that the tapes were created with any of the many third-party backup applications that existed for AmigaOS. In any case, using dd (not tar) on Linux to copy the tapes to disk to "interpret" and "sort out files afterwards" is at least a starting point. Other list members are better qualified to comment on the physical aspects of doing that without destroying the fragile old tapes.
Re: Retro networking / WAN communities
On 2022-04-12 09:49, Paul Koning via cctalk wrote: > > Does anyone still remember the other 100 Mb Ethernet-like proposal, I > think from HP, which added various types of complexity instead of simply > being a faster Ethernet? HP's proposal was called 100BaseVG, aka 100VG-AnyLAN, and could carry Token Ring frames in addition to Ethernet. https://en.wikipedia.org/wiki/100BaseVG
Re: Mounting ULTRIX CDROMs on Linux
On 2021-07-26 9:34 a.m., Maciej W. Rozycki via cctalk wrote: > On Fri, 21 May 2021, Maciej W. Rozycki wrote: > >> ISTR upstreaming some fixes to Linux UFS support 20+ years ago to address >> this very problem (IIRC OSF/1 or Digital Unix CD-ROMs were also UFS, and I >> had a need to access them under Linux for some reason) and with them in >> place I thought the loop device hack was not needed anymore. >> >> Perhaps my memory tricks me or something has since regressed though, e.g. >> due to changes in the block layer, so I'll try to remember to see what's >> happened here when I get to my Ultrix CDs when I'm in my remote lab next >> time. It's not a feature that's used on a regular basis after all, so any >> regression can be long-lived. > > I remembered right. An old Linux 2.4.26 kernel binary mounts a UFS CD > here using the old IDE hardware driver just fine with no need for block > size translation via the loop device: > > # mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom > # mount | grep ufs > /dev/hdc on /mnt/cdrom type ufs (ro,ufstype=old) > # uname -a > Linux (none) 2.4.26 #8 SMP Sat Aug 14 21:00:06 CEST 2004 i586 unknown unknown > GNU/Linux > # > > Not anymore with Linux 2.6.18 or anything newer: > > # mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom > mount: wrong fs type, bad option, bad superblock on /dev/hdc, >or too many mounted file systems > # dmesg | tail -n 1 > UFS: failed to set blocksize > # mount -t ufs -o loop,ro,ufstype=old /dev/hdc /mnt/cdrom > # mount | grep ufs > /dev/hdc on /mnt/cdrom type ufs (ro,loop=/dev/loop0,ufstype=old) > # uname -a > Linux (none) 2.6.18 #9 SMP Sun Nov 26 18:31:10 GMT 2017 i586 unknown unknown > GNU/Linux > # > > So we do have a regression here, sigh. Thanks for the analysis. I would have speculated that the difference was in the SCSI CD-ROM driver for /dev/sr* devices since those are what are used in modern Linux distributions. But your results quite clearly show that's not the case. It also shows just how long ago the change happened. Very interesting.
Re: Help Identifying Mystery SBUS Cards
On 2021-07-11 4:37 a.m., Classic CMP via cctalk wrote: > > (2) A dual width SBUS framebuffer, with space for a piggyback daughter > SBUS card in the middle. It features 3 x Bt457 RAMDACs and an Actel > A1020A chip. Possibly part of the "SPARC Card TV" partially described here: http://www.hyperstation.de/SBus-Framebuffer/SPARC_Card_TV/sparc_card_tv.html You seem to be missing the upper board, though. > (4) Possible Serial card with a DB9 connector, although there’s WAY too > much logic for a simple serial card. Has a jumper for 4Mhz / 16Mhz > which hints at maybe something Token-ring? Most likely Sun's "TRI/S" token ring interface, 501-1932. https://shrubbery.net/~heas/sun-feh-2_1/Devices/Communication/COMM_TRI_S.html > (5) A SBUS card with S-Video and what I assume to be composite. Looks > like a 501-3019 on first inspection but there’s less logic and no > heatsink on board. Probably the earlier Sun VideoPix (501-1706) in that case. https://shrubbery.net/~heas/sun-feh-2_1/Devices/Graphics/GRAPH_VideoPix.html
Re: Compaq C V6.5-303 for Tru64?
The new URL is: https://myenterpriselicense.hpe.com/cwp-ui/free-software/T64_DTK You need to log in to download it, but you can create an account for free if you don't already have one. (I don't know if you might need a paid license to run/use the software.) On 2021-06-04 6:49 p.m., Larkin Nickle via cctalk wrote: > Does anyone have a copy of Compaq C V6.5-303 for Tru64? It used to be > available from > https://h20392.www2.hp.com/portal/swdepot/try.do?productNumber=T64_DTK, > but this link has been dead for a while and hasn't been archived. >
Re: Mounting ULTRIX CDROMs on Linux
On 2021-05-20 4:49 p.m., Antonio Carlini via cctalk wrote: > > Great, thanks for that. I would probably have never guessed that I > needed loop. I'm glad it worked. I still find it illogical to loop mount a device, but it works. I never would have figured it out on my own either. I don't remember who taught me that trick so I can't give credit where it is due.
Re: Mounting ULTRIX CDROMs on Linux
On 2021-05-20 5:05 p.m., Jonathan Stone via cctalk wrote: > > What does one have to do (Linux, MacOS, *BSD) to write such an image > to the CD with 512-byte blocks, so it can be read by a DEC boot-ROM? There's nothing special needed to write the disk -- just burn it the way you would any other ISO image. It is the filesystem contained in that disk image that determines block size.
Re: Mounting ULTRIX CDROMs on Linux
On 2021-05-20 4:01 p.m., Warner Losh via cctalk wrote: > On Thu, May 20, 2021 at 1:56 PM Antonio Carlini via cctalk < > cctalk@classiccmp.org> wrote: > >> I'm running Linux Mint (an ubuntu derivative) and I want to mount ULTRIX >> CDROM discs to see what I can see. >> >> (I'm eventually going to image these, but I presume that will "just >> work" with dd or ddrescue). >> >> They are supposed to be UFS format (according to the net) and that >> usually means you have to tell mount exactly which option to use (as not >> all UFS implementations are compatible). >> >> I've tried (all the options I can find) and failed: >> >> $ sudo mount -t ufs -o ufstype=44bsd /dev/sr1 /tmp/mount > > 44bsd is likely too new. ufstype=old or =sunos or =sun might work. Setting ufstype=sun will indeed work for loopback mounting Ultrix CD images. With physical CDs, the Linux CD-ROM driver expects the filesystem to use 2048 byte blocks but the UFS CDs have 512 byte blocks. So you'll also have to add "loop" to the options: sudo mount -t ufs -o ro,ufstype=sun,loop /dev/sr1 /tmp/mount That will mount the physical CD using a loopback device so you can access the 512 byte per block filesystem. (FWIW, I learned that trick with IRIX EFS CDs, which have the same problem.)
Re: WTD - Jupiter Ace plastic rivets
On 2020-12-03 9:20 p.m., Philip Pemberton via cctalk wrote: > Has anyone got a couple of the white plastic rivets which are used to > hold the Jupiter Ace case together? > > They consist of a 4-point clawed rivet of about 5mm long, and a pin > which pushes down the centre to open it out. > > I need five of them ideally - but even two or three would get the case > buttoned up, if not perfectly. > > I've checked the local plastic supplier catalogues and haven't found > anything which quite matches up. Do any of these meet the required specifications? https://www.jetpress.com/component-and-fastener-products/expansion-plastic-rivet Also, try auto parts vendors. Similar plastic rivets are commonly used to hold trim panels in place. Some keywords to look for are "door panel retainer" or "bumper retainer".
Re: Crypto Ancienne: TLS for the Internet of Old Things
On 2020-11-16 1:34 p.m., Cameron Kaiser via cctalk wrote: > If you have an older pre-C99 system, I've backported a TLS 1.2 library to gcc > versions as early as 2.5 as long as it has 64-bit ints (long long, usually) > and stdarg.h. > > https://github.com/classilla/cryanc That looks interesting. I'm sure I'll end up playing with that at some point. I doubt that I personally have any practical use for such a thing, but that won't stop me from looking into it! I've got a few systems that I can try it out on that aren't (yet) on the "supported" list. Thanks for sharing!
Re: WTB: AUI cables
On 2020-11-17 3:22 p.m., Maciej W. Rozycki via cctalk wrote: > > In maybe 2 minutes of clicking I found these reasonably priced and using > standard slidelock assemblies, sold brand new on both sides of the pond: > > http://www.computercableinc.com/ccinc/products.jsp?sub=AUI+Transceiver=2041 > http://www.pacificcable.com/Picture_Page.asp?DataName=TRAN-6 Those seem rather high priced to me. These are not true AUI cables, but they are what I use for about 1/4 the price of the ones mentioned above: https://www.cablesalescanada.com/index.php?main_page=index=480_494_495 (That's a Canadian seller since that's where I am, but they'll ship to the US if that's where the original poster is.)
Re: About to dump a bunch of Compaq SCSI disk caddies (and disks)
On 2020-07-07 12:52 p.m., Liam Proven via cctalk wrote: > On Tue, 7 Jul 2020 at 18:14, Alessandro Mazzini via cctalk > wrote: >> >> Flebay is quite overpriced, sadly ( personal opinion anyway, from >> the point of view of someone that's now looking at finding a thing >> since months and is fixated about a real price vs an enflated one > > I often hear comments like this, but I don't really understand them. > > People pay what they are willing to pay. That is true if things are actually selling. But from what I've seen (and why I agree with the earlier comment about ebay often being overpriced) is that sellers list stuff at overly inflated prices and then let it sit there unsold. For a recent real-world example, look at SPARCstation 20s on ebay. A quick glance shows there are at least three listed right now between $800 and $1000 (US Dollars), and they've each been listed for 4-8 months. About a week ago there were two other SS 20s up for auction with $99 USD starting bids. The cosmetically better one went for just over $200 with several bidders. The damaged one sold (just minutes later) for $125 USD with only two bidders. (I was the winning bidder on that one.) Those auctions are probably very good indications of what people are willing to pay. But those other sellers are still asking 4x or 5x that amount in their "buy it now" sales ... unsold for months and seemingly unaware of the auction values of the two that did sell.
Re: Info / packs for Amcodyne 7110 "Arapahoe" drive?
On 2020-01-10 7:12 a.m., Al Kossow via cctalk wrote: > On 1/9/20 8:57 PM, Josh Dersch via cctalk wrote: >> Hi all -- >> >> Got one of these: >> http://www.bitsavers.org/pdf/amcodyne/7110/Arapahoe_7110_Brochure_Nov84.pdf >> >> >> sans power supply and packs. > > HP used them in one of their disk products, that is probably where the eBay > guy pulled the drive from, since he has a LOT of HP disk parts he's been > selling off. > > I also have a couple of the drives, w/o media or any more docs. If we can > identify the HP product, its early enough that HP would have printed a good > service manual. Is it from the HP 7907A drive? The 20.5 MB capacity (each) for the fixed and removable discs seems to match. It's roughly the same time frame, too. http://www.hpmuseum.net/display_item.php?hw=555
Re: AIX 5L/ia64 media?
On 2019-07-25 6:07 a.m., Plamen Mihaylov via cctalk wrote: > I know it was a short lived, but anyone has the installation cd or iso > image? It's not an installation cd, but yesterday I stumbled upon some developer stuff (mostly for device drivers) for AIX on Itanium on IBM's own FTP site: ftp://ftp.software.ibm.com/aix/itanium/ I doubt there's much there that's useful, but I didn't really look in too much detail.
Re: looking for info on SIMMS
On 2019-06-12 11:46 p.m., Paul Anderson via cctalk wrote: > I'm sorting out a bunch of SIMMS and would like to identify the type of > system they are from and the size. Does anyone know of any published lists > that could help me ID them? > [...] > 54-24829-DA > 54-20352-01 > 54-21139-CL > 54-21225 > 54-20410-01 > 54-20116 Those ones starting with 54- all look like DEC part numbers for individual SIMMs that (at least in some cases) were used to make up a larger kit with a completely different name. E.g., the 54-21139-CL are 4MB SIMMs that were sold in sets of 8 as the MS15-CA 32MB kit. Unfortunately, I have no idea what the others are. Just that they might be part of different kits.
Re: Making a bootable LIF CD for the 9000/382
I've successfully booted both my HP 9000/380 and 425e systems from a Toshiba SD-M1711 DVD-ROM drive jumpered to 512 byte/sector mode. In my case I was using CD images provided by David Collins from hpmuseum.net. The boot CD image that I got from him has the same md5sum as the hpux9_install.iso image that I just downloaded from bitsavers. I didn't need to do anything special to burn it or boot from it. It just worked. On 2018-07-06 12:49 PM, Al Kossow via cctalk wrote: > Couple of related things, does anyone have a list of SCSI CDROMs known to > boot on the 68K 9000s? > I've ordered another A1999 to see if my drive is just bad, and have started > digging through my > boxes of drives for other models to test.
