Re: WARNING: Clear QIC Tape Bands
On 1/18/22 8:22 AM, Chuck Guzis via cctalk wrote: You should be warned that Plastibands do deteriorate after a year or so--I have a package of them that cannot be stretched without breaking. Do you keep them in sealed bags? I keep mine in a zip-lock and the ones that I got a couple years ago stretch just fine. (I checked after I saw this.)
Re: seeking Motorola M68MM01A2 documentation
If you include the 6875 Timer chip, follow the data sheet carefully, it's a little tricky in its discretes (I don't remember from 40 years ago what exactly it is). The biggest disadvantage to the 6850 ACIA and 14411 Baud rate generator is the baud rate is NOT software selectable. SWTBUG was much better than MIKBUG and GMXBUG was even better. If you want to emulate both the SWTPC and Motorola board addresses I would strongly recommend some kind of programmable logic to handle the very different addressing schemes. The SS-30 I/O Bus had the address decoding on the motherboard. Each slot was allocated 4 address (the later MC6809 version upped this to 16 address.) Where as the Motorola system addressed differently. On 1/18/2022 6:22 PM, Chris Elmquist via cctalk wrote: On Tuesday (01/18/2022 at 11:35PM +), Jonathan Chapman wrote: How's about a Glitchbus board set that's compatible? I was planning on doing it anyway. That would be very cool. Something along those lines was my plan B and I even dug out a tube of 6802's for the effort. I think I could wire up a prototype over a weekend. MC6802 is a nice "cheat" as you don't have to mess with the two-phase clock stuff. What would be really slick is an SBC that has everything on it to be either an Altair 680 or an SWTPC 6800 just by changing some jumpers, switches, etc. and putting the correct ROM monitor on the board. If there was a PROM, a 32K SRAM, an ACIA and a bonus PIA socket, along with a small amount of glue logic, I think we could run the ROM monitor for either system and a bunch of legacy code in 32K of RAM-- which would have been a big system in the day. The PIA would provide a fun GPIO capability just for toggling bits to and from the real world. The ACIA was the serial console device on the Altair and the later MP-S on the SWTPC and so you would run SWTBUG on the SWTPC personality to use that. I don't see a need for MIKBUG compatibility here, since that requires the bit-banged console via another PIA and odd external timer chip. Baud rate generator that can do 16x for 110, 300, 1200 and 9600 would be ideal. I'd want 110 for a real Teletype, 300 for Kansas City Standard tapes, 1200 for a DecWriter and 9600 so that I don't fall asleep ;-) When can I order one! :-) Thanks Jonathan, Chris
Re: AOL diskettes
On Tue, 18 Jan 2022, Grant Taylor via cctalk wrote: On 1/18/22 2:21 PM, Peter Coghlan via cctalk wrote: https://www.thisiswhyimbroke.com/floppy-disk-table/ I like it! But I hate the price. The problem is right there in the name of the site. :D 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_!
Re: seeking Motorola M68MM01A2 documentation
On Tuesday (01/18/2022 at 11:35PM +), Jonathan Chapman wrote: > How's about a Glitchbus board set that's compatible? I was planning on doing > it anyway. That would be very cool. Something along those lines was my plan B and I even dug out a tube of 6802's for the effort. I think I could wire up a prototype over a weekend. MC6802 is a nice "cheat" as you don't have to mess with the two-phase clock stuff. What would be really slick is an SBC that has everything on it to be either an Altair 680 or an SWTPC 6800 just by changing some jumpers, switches, etc. and putting the correct ROM monitor on the board. If there was a PROM, a 32K SRAM, an ACIA and a bonus PIA socket, along with a small amount of glue logic, I think we could run the ROM monitor for either system and a bunch of legacy code in 32K of RAM-- which would have been a big system in the day. The PIA would provide a fun GPIO capability just for toggling bits to and from the real world. The ACIA was the serial console device on the Altair and the later MP-S on the SWTPC and so you would run SWTBUG on the SWTPC personality to use that. I don't see a need for MIKBUG compatibility here, since that requires the bit-banged console via another PIA and odd external timer chip. Baud rate generator that can do 16x for 110, 300, 1200 and 9600 would be ideal. I'd want 110 for a real Teletype, 300 for Kansas City Standard tapes, 1200 for a DecWriter and 9600 so that I don't fall asleep ;-) When can I order one! :-) Thanks Jonathan, Chris -- Chris Elmquist
Re: AOL diskettes
On 1/18/22 2:21 PM, Peter Coghlan via cctalk wrote: https://www.thisiswhyimbroke.com/floppy-disk-table/ I like it! But I hate the price. -- Grant. . . . unix || die
Re: seeking Motorola M68MM01A2 documentation
How's about a Glitchbus board set that's compatible? I was planning on doing it anyway. Thanks, Jonathan ‐‐‐ Original Message ‐‐‐ On Tuesday, January 18th, 2022 at 16:45, Chris Elmquist via cctalk wrote: > On Tuesday (01/18/2022 at 03:37PM -0600), Mike Katz wrote: > > > If the software is using ROM routines then the address doesn't matter for > > > > the applications. If not, you can create an abstraction layer (set of > > > > drivers for the ACIA, 6875 Timer and PIA) and if all of the code is written > > > > to the abstraction layer then all you need to do is link in the appropriate > > > > binary for the abstraction layer. This will work for both C and machine > > > > language. > > Understood but I don't want to force the developer to make different code > > for this machine than for the real 680. This is an attempt to get him > > something that he can use to make code for the real 680 without having > > a real 680. > > I have a real 680 myself but I'm not up to shipping it around, loaning > > it out, etc. yet still want to help the effort. But since I am not the > > one actually doing the effort, I wanted to help by providing something > > that was usable without having to change his approach. > > Thanks for the suggestions though. > > Chris > > > On 1/18/2022 2:14 PM, Chris Elmquist wrote: > > > > > On Tuesday (01/18/2022 at 02:01PM -0600), Mike Katz wrote: > > > > > > > I think it might be easier to modify the 680 prom for the I/O addresses > > > > of > > > > > > > > the board rather than modify the board to match the ROM. > > > > > > > > Agreed-- except the goal, which I failed to elaborate on, is to come > > > > > > > > up with an Altair 680 development environment so that someone can port > > > > > > > > some code to the platform without having the real thing. I wanted to > > > > > > > > make that environment as close to real as possible (without having front > > > > > > > > panel switches and LEDs)-- which means having the I/O in the same place > > > > > > > > as the original as well as the authentic PROM code running. > > > > > > > Especially if the address decoding for the I/O is done in PAL (10L8 for > > > > > > > > example). > > > > > > > > No PALs on the board but there is a bipolar PROM (82S129). I'm not > > > > > > > > adverse to making a new one of those or bodging something that drops > > > > > > > > into that socket to modify the decoding if neccessary. I was just hoping > > > > > > > > to not have to butcher the board itself too much. > > > > > > > Some 6800 address decoding was done with 74LS138s. This had the > > > > potential > > > > > > > > to be inefficient in terms of memory usage or if the '138s were cascaded > > > > > > > > then propagation delay could become an issue. > > > > > > > > Yes. This seems to be a limited function CPU board and I suspect it > > > > takes > > > > > > > > that approach just to get the four PROMs and I/O decoded very coarsely. > > > > > > Chris > > Chris Elmquist
Re: AOL diskettes
>>> I can only conclude you needed something to save the surface on one of >>> these... >>> https://www.thisiswhyimbroke.com/floppy-disk-table/ >> >> I just love that table > > Although the ad says "1.44 megabytes", it is a 720K. > The write enable notch is not openable to write protect it, > and the shutter may have lost its spring.. The one *with* the spring working has a handy catch basin for your distal finger fragments. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- My opinions may have changed, but not the fact that I'm still right. ---
Re: AOL diskettes
What's the going price for a Cray round sofa/bench?
Re: AOL diskettes
I can only conclude you needed something to save the surface on one of these... https://www.thisiswhyimbroke.com/floppy-disk-table/ On Tue, 18 Jan 2022, Mike Katz via cctalk wrote: I just love that table Although the ad says "1.44 megabytes", it is a 720K. The write enable notch is not openable to write protect it, and the shutter may have lost its spring..
Re: AOL diskettes
On Tue, 18 Jan 2022, Peter Coghlan via cctalk wrote: I can only conclude you needed something to save the surface on one of these... https://www.thisiswhyimbroke.com/floppy-disk-table/ I have a RAMAC platter. (24" diameter; arguably FIRST hard disk, from 1958?; when they wouldn't let Nikita Krushchev into Disneyland, they took him to the IBM factory, instead.) It has enough damage to no longer be usable in a drive. I have a round patio table base. I still need a 2 foot round piece of [UV absorbing?] [tempered?] glass. -- Grumpy Ol' Fred ci...@xenosoft.com
Re: seeking Motorola M68MM01A2 documentation
On Tuesday (01/18/2022 at 03:37PM -0600), Mike Katz wrote: > If the software is using ROM routines then the address doesn't matter for > the applications. If not, you can create an abstraction layer (set of > drivers for the ACIA, 6875 Timer and PIA) and if all of the code is written > to the abstraction layer then all you need to do is link in the appropriate > binary for the abstraction layer. This will work for both C and machine > language. Understood but I don't want to force the developer to make different code for this machine than for the real 680. This is an attempt to get him something that he can use to make code for the real 680 without having a real 680. I have a real 680 myself but I'm not up to shipping it around, loaning it out, etc. yet still want to help the effort. But since I am not the one actually doing the effort, I wanted to help by providing something that was usable without having to change his approach. Thanks for the suggestions though. Chris > On 1/18/2022 2:14 PM, Chris Elmquist wrote: > > On Tuesday (01/18/2022 at 02:01PM -0600), Mike Katz wrote: > > > I think it might be easier to modify the 680 prom for the I/O addresses of > > > the board rather than modify the board to match the ROM. > > Agreed-- except the goal, which I failed to elaborate on, is to come > > up with an Altair 680 development environment so that someone can port > > some code to the platform without having the real thing. I wanted to > > make that environment as close to real as possible (without having front > > panel switches and LEDs)-- which means having the I/O in the same place > > as the original as well as the authentic PROM code running. > > > > > Especially if the address decoding for the I/O is done in PAL (10L8 for > > > example). > > No PALs on the board but there is a bipolar PROM (82S129). I'm not > > adverse to making a new one of those or bodging something that drops > > into that socket to modify the decoding if neccessary. I was just hoping > > to not have to butcher the board itself too much. > > > > > Some 6800 address decoding was done with 74LS138s. This had the potential > > > to be inefficient in terms of memory usage or if the '138s were cascaded > > > then propagation delay could become an issue. > > Yes. This seems to be a limited function CPU board and I suspect it takes > > that approach just to get the four PROMs and I/O decoded very coarsely. > > > > Chris -- Chris Elmquist
Re: AOL diskettes
I just love that table On 1/18/2022 3:21 PM, Peter Coghlan via cctalk wrote: On Tue, 18 Jan 2022 at 13:38:32 -0700, Adam Thornton via cctalk wrote: I wish I'd kept some. I had some AOL CDs from slightly later that made decent coasters for decades. Although I guess with the shutter, the floppy wouldn't really have made a very good coaster. I can only conclude you needed something to save the surface on one of these... https://www.thisiswhyimbroke.com/floppy-disk-table/ Regards, Peter Coghlan. Adam
Re: seeking Motorola M68MM01A2 documentation
If the software is using ROM routines then the address doesn't matter for the applications. If not, you can create an abstraction layer (set of drivers for the ACIA, 6875 Timer and PIA) and if all of the code is written to the abstraction layer then all you need to do is link in the appropriate binary for the abstraction layer. This will work for both C and machine language. On 1/18/2022 2:14 PM, Chris Elmquist wrote: On Tuesday (01/18/2022 at 02:01PM -0600), Mike Katz wrote: I think it might be easier to modify the 680 prom for the I/O addresses of the board rather than modify the board to match the ROM. Agreed-- except the goal, which I failed to elaborate on, is to come up with an Altair 680 development environment so that someone can port some code to the platform without having the real thing. I wanted to make that environment as close to real as possible (without having front panel switches and LEDs)-- which means having the I/O in the same place as the original as well as the authentic PROM code running. Especially if the address decoding for the I/O is done in PAL (10L8 for example). No PALs on the board but there is a bipolar PROM (82S129). I'm not adverse to making a new one of those or bodging something that drops into that socket to modify the decoding if neccessary. I was just hoping to not have to butcher the board itself too much. Some 6800 address decoding was done with 74LS138s. This had the potential to be inefficient in terms of memory usage or if the '138s were cascaded then propagation delay could become an issue. Yes. This seems to be a limited function CPU board and I suspect it takes that approach just to get the four PROMs and I/O decoded very coarsely. Chris
Re: AOL diskettes
On Tue, 18 Jan 2022 at 13:38:32 -0700, Adam Thornton via cctalk wrote: > > I wish I'd kept some. I had some AOL CDs from slightly later that made > decent coasters for decades. Although I guess with the shutter, the floppy > wouldn't really have made a very good coaster. > I can only conclude you needed something to save the surface on one of these... https://www.thisiswhyimbroke.com/floppy-disk-table/ Regards, Peter Coghlan. > > Adam >
Re: AOL diskettes
On 1/18/22 1:38 PM, Adam Thornton via cctalk wrote: I wish I'd kept some. I had some AOL CDs from slightly later that made decent coasters for decades. Although I guess with the shutter, the floppy wouldn't really have made a very good coaster. Chuckle. When I think of "coasters" I think of CD-ROMs, particularly bad burns on CD-Rs. That being said, I do have some rubber coasters in the shape of 3½" floppy disks. -- Grant. . . . unix || die
AOL diskettes
> From: Grant Taylor > > I wince at the idea of running with QIC tape. But my experience is with > QIC-80 tapes of the '90s which were so unreliable as to be in the same > category as AOL floppy disks during the late '90s around the transition > to CD-ROMs. As in I would trust an AOL floppy disk to better hold my > data for a week than I would a QIC-80 tape to hold data for a month, > much less a year. ...and I didn't even trust an AOL floppy to go from > computer to computer for 5 minutes. -- Talk about a race to the bottom > for quality. I wish I'd kept some. I had some AOL CDs from slightly later that made decent coasters for decades. Although I guess with the shutter, the floppy wouldn't really have made a very good coaster. Adam
Re: seeking Motorola M68MM01A2 documentation
On Tuesday (01/18/2022 at 02:01PM -0600), Mike Katz wrote: > I think it might be easier to modify the 680 prom for the I/O addresses of > the board rather than modify the board to match the ROM. Agreed-- except the goal, which I failed to elaborate on, is to come up with an Altair 680 development environment so that someone can port some code to the platform without having the real thing. I wanted to make that environment as close to real as possible (without having front panel switches and LEDs)-- which means having the I/O in the same place as the original as well as the authentic PROM code running. > Especially if the address decoding for the I/O is done in PAL (10L8 for > example). No PALs on the board but there is a bipolar PROM (82S129). I'm not adverse to making a new one of those or bodging something that drops into that socket to modify the decoding if neccessary. I was just hoping to not have to butcher the board itself too much. > Some 6800 address decoding was done with 74LS138s. This had the potential > to be inefficient in terms of memory usage or if the '138s were cascaded > then propagation delay could become an issue. Yes. This seems to be a limited function CPU board and I suspect it takes that approach just to get the four PROMs and I/O decoded very coarsely. Chris -- Chris Elmquist
Re: WARNING: Clear QIC Tape Bands
On 1/18/22 11:38, Zane Healy via cctalk wrote: > > >> On Jan 18, 2022, at 10:09 AM, Jonathan Chapman via cctalk >> wrote: >> >>> My opinion is that if you're trying to use DC carts for archival >> storage, you should have your (tape) head examined. >> >> Not archival storage, just day-to-day operation on old stuff, like >> Sun3/Sun4, AT UNIX PC, etc. > > Can you do tape operations over TCP/IP to a machine with a better drive, or a > VTL? On VMS, the last tape backups I did on a physical box, were to a > virtual tape drive on a SIMH/VAX system. If this is a SCSI QIC drive, I'd suggest moving to DLT, 8mm or even DDS. None of these suffer from the "broken bad" problem. SCSI tape drives as a class, are pretty much interchangeable as there's an ANSI spec for the command set. If it's a QIC-02 interface, you might want to look into emulation using an MCU. QIC-02 interface is stupid simple and any moderately capable MCU should be able to generate the required signals. You can probably fit the contents of every QIC tape that you own on a single SD card. QIC-36 is going to be a bit more difficult, but there were (and maybe still are) QIC-36-to-QIC-02 bridge boards around. My .02 for whatever its depreciated value is worth. --Chuck
Re: seeking Motorola M68MM01A2 documentation
I think it might be easier to modify the 680 prom for the I/O addresses of the board rather than modify the board to match the ROM. Especially if the address decoding for the I/O is done in PAL (10L8 for example). Some 6800 address decoding was done with 74LS138s. This had the potential to be inefficient in terms of memory usage or if the '138s were cascaded then propagation delay could become an issue. On 1/18/2022 12:54 PM, Chris Elmquist via cctalk wrote: I have quite a few Motorola Microsystems Exorciser boards including this 6800 single board computer for which I am lacking any documentation. I've seen a brochure in Al's collection on Bitsavers but haven't found any details that might discuss jumper settings or even better, a schematic. Wondering if anyone would have a user manual or other detailed docs for this board? M68MM01A2 -- has 6800 CPU, 6875 1.0 MHz clock generator, 6850 ACIA and MC14411 baud rate clock, (4) EPROM/ROM sockets and (2) 6821 PIA sockets with the 86-pin Exorciser edge connector. I'm interested in seeing if I can minimally modify it to have a similar memory map to the Altair 680 so that the Altair's PROM monitor could run on it. Thanks! Chris
Re: WARNING: Clear QIC Tape Bands
> On Jan 18, 2022, at 10:09 AM, Jonathan Chapman via cctalk > wrote: > >> My opinion is that if you're trying to use DC carts for archival > storage, you should have your (tape) head examined. > > Not archival storage, just day-to-day operation on old stuff, like Sun3/Sun4, > AT UNIX PC, etc. Can you do tape operations over TCP/IP to a machine with a better drive, or a VTL? On VMS, the last tape backups I did on a physical box, were to a virtual tape drive on a SIMH/VAX system. Zane
Re: WARNING: Clear QIC Tape Bands
On Jan 18, 2022, at 8:58 AM, Chris Zach via cctalk wrote: > >> As someone that has worked with computer tapes for nearly 40 years, I have >> to question the sanity of this. These > tapes are *HOW* old? What was their intended lifespan? While we all like to > keep our hardware as original as possible, does it really make sense to try > to run systems in this day and age with QIC tapes? > > Well, you gotta use something to back up those ESDI drives. > > I'm finding the TK50's and TK70's to be pretty good, the big massive problem > with them is those two pulleys having the grease dried up. Since one of them > runs the tape tachometer they need to spin freely and smoothly. > > Count the turns on the top bolt as you remove it, take off the pulleys, > lubricate or replace the bearings, reassemble, good for another 20 years or > so. > > QIC Yeah that's not going to work well. Times change. I’m also not using MFM or ESDI drives. I converted my Q-Bus HW to SCSI 20+ years ago. When I get it back up and running, I plan to convert it to SCSI2SD. OTOH, I am trying, for some insane reason to get a DSSI system going. I started converting my SCSI based DEC HW to SCSI2SD last summer. Having said that, that’s good news on the TK50’s and TK70’s, I have a couple boxes in my office (so somewhat nicely stored) that I need to read, in my nonexistent free time. My plan has been to buy a refurbished SBB that will read them. I’m more likely to trust the TK50 in my PDP-11 than the 4mm DAT. I’ve read 30 year old 9-track tapes on production hardware, and I’ve read very old TK50’s (as well as other DLT-style tapes). Things like QIC, 8mm, and 4mm, I try my best to avoid on production systems. Zane
Re: seeking Motorola M68MM01A2 documentation
On Tuesday (01/18/2022 at 02:09PM -0500), Bill Degnan wrote: > Not exactly a match but I do have this, if it helps: > https://www.vintagecomputer.net/motorola/mek6800d2/MEK6800D2.pdf Thanks Bill. I have that too and in fact a couple D2 boards so I am set there. This is a specific detail so that I can make mods to the board without having to reverse engineer it first. But I suspect it will come to that. Thanks anyway! Chris > On Tue, Jan 18, 2022 at 1:54 PM Chris Elmquist via cctalk < > cctalk@classiccmp.org> wrote: > > > > > I have quite a few Motorola Microsystems Exorciser boards including this > > 6800 single board computer for which I am lacking any documentation. > > > > I've seen a brochure in Al's collection on Bitsavers but haven't found > > any details that might discuss jumper settings or even better, > > a schematic. > > > > Wondering if anyone would have a user manual or other detailed docs for > > this board? > > > > M68MM01A2 -- has 6800 CPU, 6875 1.0 MHz clock generator, 6850 ACIA and > > MC14411 baud rate clock, (4) EPROM/ROM sockets and (2) 6821 PIA sockets > > with the 86-pin Exorciser edge connector. > > > > I'm interested in seeing if I can minimally modify it to have a similar > > memory map to the Altair 680 so that the Altair's PROM monitor could > > run on it. > > > > Thanks! > > > > Chris > > -- > > Chris Elmquist > > > > -- Chris Elmquist
Re: seeking Motorola M68MM01A2 documentation
Not exactly a match but I do have this, if it helps: https://www.vintagecomputer.net/motorola/mek6800d2/MEK6800D2.pdf Bill On Tue, Jan 18, 2022 at 1:54 PM Chris Elmquist via cctalk < cctalk@classiccmp.org> wrote: > > I have quite a few Motorola Microsystems Exorciser boards including this > 6800 single board computer for which I am lacking any documentation. > > I've seen a brochure in Al's collection on Bitsavers but haven't found > any details that might discuss jumper settings or even better, > a schematic. > > Wondering if anyone would have a user manual or other detailed docs for > this board? > > M68MM01A2 -- has 6800 CPU, 6875 1.0 MHz clock generator, 6850 ACIA and > MC14411 baud rate clock, (4) EPROM/ROM sockets and (2) 6821 PIA sockets > with the 86-pin Exorciser edge connector. > > I'm interested in seeing if I can minimally modify it to have a similar > memory map to the Altair 680 so that the Altair's PROM monitor could > run on it. > > Thanks! > > Chris > -- > Chris Elmquist > >
seeking Motorola M68MM01A2 documentation
I have quite a few Motorola Microsystems Exorciser boards including this 6800 single board computer for which I am lacking any documentation. I've seen a brochure in Al's collection on Bitsavers but haven't found any details that might discuss jumper settings or even better, a schematic. Wondering if anyone would have a user manual or other detailed docs for this board? M68MM01A2 -- has 6800 CPU, 6875 1.0 MHz clock generator, 6850 ACIA and MC14411 baud rate clock, (4) EPROM/ROM sockets and (2) 6821 PIA sockets with the 86-pin Exorciser edge connector. I'm interested in seeing if I can minimally modify it to have a similar memory map to the Altair 680 so that the Altair's PROM monitor could run on it. Thanks! Chris -- Chris Elmquist
Re: WARNING: Clear QIC Tape Bands
On 1/18/22 11:21 AM, Jonathan Chapman via cctalk wrote: I don't do a reinstall of SunOS every day, though! Fair enough. If I had a process where something might fail in between uses, I'd augment the process to re-write the image to a (new instance of) tape before I try to use it. Yeah, it's not like irreplaceable data is being lost. But when they fail, you have to at least re-band another tape, and with this stuff pulling oxide off, probably clean the drive too. And of course write a new tape out. I get that. I was actually thinking of something more dastardly like a process that generates data as a one and done. As such the entire process that generates the data needs to be re-done. Extrapolate backwards /after/ doing the physical tape maintenance. "Tape" is I think what most people call them :P Ya. But "tape" is not descriptive in my opinion, especially when you have other types of tape; DLT, DAT, 9-track, etc. ;-) -- Grant. . . . unix || die
Re: WARNING: Clear QIC Tape Bands
> However, "couple (of) months" seems incongruent with "day-to-day". I don't do a reinstall of SunOS every day, though! > I am assuming that the day-to-day operation to mean that the source data > is still accessible on the source system. As such, it's probably simply > a matter of annoyance when a QIC* fails and you must re-do the process > that was using it. Yeah, it's not like irreplaceable data is being lost. But when they fail, you have to at least re-band another tape, and with this stuff pulling oxide off, probably clean the drive too. And of course write a new tape out. > *Can I use /just/ QIC as a proper name or should I say /QIC/ /cartridge/ > analogous to VIN number? "Tape" is I think what most people call them :P Thanks, Jonathan
Re: WARNING: Clear QIC Tape Bands
On 1/18/22 11:09 AM, Jonathan Chapman via cctalk wrote: Not archival storage, just day-to-day operation on old stuff, like Sun3/Sun4, AT UNIX PC, etc. Okay. I can see that. However, "couple (of) months" seems incongruent with "day-to-day". I am assuming that the day-to-day operation to mean that the source data is still accessible on the source system. As such, it's probably simply a matter of annoyance when a QIC* fails and you must re-do the process that was using it. *Can I use /just/ QIC as a proper name or should I say /QIC/ /cartridge/ analogous to VIN number? Works well enough for my needs :) I've got a small stack of QICs I use primarily with the Suns, they are reliable enough. Again, we're not storing launch codes on these or shooting them to the moon or something, I just want tape bands that don't destroy tape. ACK -- Grant. . . . unix || die
Re: WARNING: Clear QIC Tape Bands
> I wince at the idea of running with QIC tape. But my experience is with > QIC-80 tapes of the '90s Yes, small ftape QIC-80s were certainly in the "not great" category! Thanks, Jonathan
Re: WARNING: Clear QIC Tape Bands
> My opinion is that if you're trying to use DC carts for archival storage, you should have your (tape) head examined. Not archival storage, just day-to-day operation on old stuff, like Sun3/Sun4, AT UNIX PC, etc. > As someone that has worked with computer tapes for nearly 40 years, I have to > question the sanity of this. These > tapes are HOW old? What was their intended lifespan? While we all > like to keep our hardware as original as possible, does it really make > sense to try to run systems in this day and age with QIC tapes? Works well enough for my needs :) I've got a small stack of QICs I use primarily with the Suns, they are reliable enough. Again, we're not storing launch codes on these or shooting them to the moon or something, I just want tape bands that don't destroy tape. Thanks, Jonathan
Re: WARNING: Clear QIC Tape Bands
On 1/18/22 8:33 AM, Jonathan Chapman via cctalk wrote: https://i.imgur.com/48EfOQG.jpg Ouch! With my luck, that would have been the index / start of tape marker rendering the rest of the tape mostly unusable. That's after sitting parked a couple months. Um I would naively think that would invalidate any test / concern unless it was specifically for the problem that you're describing. I have a Dysan doing it too. The Dysan had been re-banded with a boiled 3M band and run for years like that with no shedding. Is that belt or tape media? I (mis)took it to be tape media. I have another Dysan with a green Plastiband in it which is also fine, minimal/no shed. So, I think we may need to re-evaluate if the clear Amazon cheap "plastibands" are perhaps totally incompatible with tape. My naive understanding was that they were Good Enough™ to get data off of the tape as in one (or a few) last hurrah(s) for data recovery. (Comparing multiple reads.) I know, I know..."just use the band to get data off." But I want to *run* QICs without having to destroy them constantly. I wince at the idea of running with QIC tape. But my experience is with QIC-80 tapes of the '90s which were so unreliable as to be in the same category as AOL floppy disks during the late '90s around the transition to CD-ROMs. As in I would trust an AOL floppy disk to better hold my data for a week than I would a QIC-80 tape to hold data for a month, much less a year. ...and I didn't even trust an AOL floppy to go from computer to computer for 5 minutes. -- Talk about a race to the bottom for quality. -- Grant. . . . unix || die
Re: WARNING: Clear QIC Tape Bands
As someone that has worked with computer tapes for nearly 40 years, I have to question the sanity of this. These tapes are *HOW* old? What was their intended lifespan? While we all like to keep our hardware as original as possible, does it really make sense to try to run systems in this day and age with QIC tapes? Well, you gotta use something to back up those ESDI drives. I'm finding the TK50's and TK70's to be pretty good, the big massive problem with them is those two pulleys having the grease dried up. Since one of them runs the tape tachometer they need to spin freely and smoothly. Count the turns on the top bolt as you remove it, take off the pulleys, lubricate or replace the bearings, reassemble, good for another 20 years or so. QIC Yeah that's not going to work well. Times change.
Re: WARNING: Clear QIC Tape Bands
On 1/18/22 07:33, Jonathan Chapman via cctalk wrote: > https://i.imgur.com/48EfOQG.jpg > > That's after sitting parked a couple months. I have a Dysan doing it too. The > Dysan had been re-banded with a boiled 3M band and run for years like that > with no shedding. I have another Dysan with a green Plastiband in it which is > also fine, minimal/no shed. So, I think we may need to re-evaluate if the > clear Amazon cheap "plastibands" are perhaps totally incompatible with tape. > > I know, I know..."just use the band to get data off." But I want to *run* > QICs without having to destroy them constantly. > Big difference here--Al and I are interested in getting the stuff off and tossing the cart afterwards. You should be warned that Plastibands do deteriorate after a year or so--I have a package of them that cannot be stretched without breaking. And I've got factory 3M carts with the original bands where the same thing has happened--it's just harder to see. To be clear (no pun intended), I wipe the clear ones down with isopropanol before installing. Regardless, they're all TPU. P.S. If you're interested in fun, try re-banding a TR-7 cart successfully. My opinion is that if you're trying to use DC carts for archival storage, you should have your (tape) head examined. It's an old, cheap (for the time) medium with a fatal design flaw. --Chuck
Re: WARNING: Clear QIC Tape Bands
On Jan 18, 2022, at 7:33 AM, Jonathan Chapman via cctalk wrote: > > I know, I know..."just use the band to get data off." But I want to *run* > QICs without having to destroy them constantly. As someone that has worked with computer tapes for nearly 40 years, I have to question the sanity of this. These tapes are *HOW* old? What was their intended lifespan? While we all like to keep our hardware as original as possible, does it really make sense to try to run systems in this day and age with QIC tapes? Can you emulate the tape device? Zane
WARNING: Clear QIC Tape Bands
https://i.imgur.com/48EfOQG.jpg That's after sitting parked a couple months. I have a Dysan doing it too. The Dysan had been re-banded with a boiled 3M band and run for years like that with no shedding. I have another Dysan with a green Plastiband in it which is also fine, minimal/no shed. So, I think we may need to re-evaluate if the clear Amazon cheap "plastibands" are perhaps totally incompatible with tape. I know, I know..."just use the band to get data off." But I want to *run* QICs without having to destroy them constantly. Thanks, Jonathan
