Re: Identifying TO-3 w/HP house numbering
On Wed, Oct 17, 2018 at 9:33 AM Josh Dersch via cctalk wrote: > And I was wrong -- the flyback's fine (yay!). Found a nearby 0.015uF, 400V > film capacitor that was shorted. Replaced it and now I have video! It's a > bit dim, it's too wide, and gets wider as it warms up but it's a start :). That suggests to me that what we call the 'EHT' over here -- the 12kV-15kV on the final anode of the CRT -- is low and is sagging under load. Low EHT will cause a dim picture, it will also cause the electron beam to be less 'stiff' (as the electrons are not moving as fast) so the deflection coils have a greater effect and the picture is larger. Possibly more capacitor trouble in the flyback area. -tony
Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
On Wed, Oct 17, 2018 at 8:15 AM emanuel stiebler via cctalk wrote: > there were > TK50Z as an external drive, on "SCSI" I have one - for a MicroVAX 2000. I rarely used it. > TK50 on QBUS with an TQK50 controller which really didn't stream to often We had one in the 1980s. You are right. It didn't. > TK50 on QBUS with an TQK70 controller, which doubled the memory of the > TQK50, which was capable of streaming ... Ooh! That works? I might have to nab a TQK70 for that MicroVAX II I have (the one we had at work in the 1980s. I got it when the company folded). Mostly, really just need to image any tapes I have more than write new tapes, presuming the media hasn't degraded too much in the past 30 years. -ethan
Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
> On Oct 17, 2018, at 10:50 AM, Ethan Dicks via cctalk > wrote: > > On Wed, Oct 17, 2018 at 8:15 AM emanuel stiebler via cctalk > wrote: >> there were >> TK50Z as an external drive, on "SCSI" > > I have one - for a MicroVAX 2000. I rarely used it. > >> TK50 on QBUS with an TQK50 controller which really didn't stream to often > > We had one in the 1980s. You are right. It didn't. I wonder if that was a VAX-specific issue. It streamed fine on J-11 based PDP11 systems running RSTS. While most VAXen have faster CPUs than PDP-11s, that doesn't necessarily carry over to I/O. paul
OTsorta : Old phone system(s) avail
I know some of our members are into phones... I am tossing the following in a skip to go to a recycler. I'd rather not ship the units, but am willing to pull any boards if someone needs them. Toshiba Strata DX Toshiba CIX200 Toshiba CIX40 The will be sent off to recycler Monday or Tuesday. J
Re: OTsorta : Old phone system(s) avail
Hi Jay, On 17/10/2018 16:21, Jay West via cctalk wrote: > I know some of our members are into phones... I have an idea for a project to reduce my dependency on my phone. I'm trying to move to a model where voice, voicemail, and SMS are all that I need when I'm on the go. SMS would be used as an interface to control various simple Internet-like functionalities. > I am tossing the following in a skip to go to a recycler. I'd rather not > ship the units, but am willing to pull any boards if someone needs them. > > > > Toshiba Strata DX > > Toshiba CIX200 > > Toshiba CIX40 I'm still looking into whether these devices will help me. I'm at the point of figuring out what the unknown unknowns are, as I'm new to telephony. Where are you located? I am in London, UK. I'm aware that due to the likelihood of shipping there's a good chance this won't work out. Kind regards, Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: OTsorta : Old phone system(s) avail
I'm still looking into whether these devices will help me. I'm at the point of figuring out what the unknown unknowns are, as I'm new to telephony. Where are you located? I am in London, UK. I'm aware that due to the likelihood of shipping there's a good chance this won't work out. It's an older office phone system. Boxes that run a bunch of office phones. Not a mobile phone. Anyone know of an ESS-5A that needs a home? I really would like to bring one to HOPE in NYC one year. - Ethan
Re: OTsorta : Old phone system(s) avail
On 17/10/2018 16:57, et...@757.org wrote: > It's an older office phone system. Boxes that run a bunch of office > phones. Not a mobile phone. I'm not looking for a mobile phone. I'm looking for server-side telephony hardware and services to implement an "SMS-based API" so that I can perform various operations by using simple commands over SMS. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: OTsorta : Old phone system(s) avail
On Wed, 17 Oct 2018 at 17:54, Andrew Luke Nesbit via cctalk wrote: > > I have an idea for a project to reduce my dependency on my phone. I'm > trying to move to a model where voice, voicemail, and SMS are all that I > need when I'm on the go. There are plenty of such devices around. Some are trendy retro things: https://www.techradar.com/reviews/new-nokia-3310-2017-review https://www.theguardian.com/technology/2018/aug/16/nokia-8110-4g-review-nostalgia-the-matrix-banana-phone If you don't want something "retro" then there are still candy-bar feature-phones: https://www.techadvisor.co.uk/feature/mobile-phone/best-basic-phones-of-2018-3641218/ Here are some international models: https://www.lifewire.com/basic-cell-phones-577534 -- Liam Proven - Profile: https://about.me/liamproven Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
ISO IBM 3708 documentation
Does anyone have copies of the planning (GA27-3609) or configuration (GA27-3726) documents for the 3708 protocol converter?
Re: OTsorta : Old phone system(s) avail
On 10/17/2018 10:04 AM, Andrew Luke Nesbit via cctalk wrote: I'm looking for server-side telephony hardware and services to implement an "SMS-based API" so that I can perform various operations by using simple commands over SMS. Remember that it is possible to spoof or hijack SMS / phone numbers. So don't rely on just that for security. -- Grant. . . . unix || die
Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
I took most of this off line, but I'll try to close down the discussion, so we can get back to TUHS history. Please be careful of your wording as it is easy to get confused particularly if you never used the original 1/2" tape system you might not understand the actual terms. The term for reading Read and Write I/O Sizes in a user program are different than tape block sizes (or as they were originally referred LRECL - Logical Record Length). As I said to Paul K, I sadly know way more about the minutia of tapes that I really should admit [I broke in during the 60s using 7-track tapes on the IBM Mainframes which really date me and I remember the 5-track tapes on one of the systems, but I never personally used it]. On Wed, Oct 17, 2018 at 2:14 AM emanuel stiebler wrote: > Longer blocks, too (2k or so) which would make any buffering issues more > severe. > *Your user program read/wrote with 2K or more using DMA reads or writes but it wrote 512 byte 'blocks.'* As Paul W pointed out correctly, the TK50 and its children in the DLT* family all used a fixed format 512 byte *blocks on the tape*.This cannot be changed. The tape format is handled by the tape controller microcode and all of the blocks on all the streamers (DLT, 1/4, 1/2", 4mm and 8mm) that I know about were fixed at 512 byte, although the OS could write multiple (N) blocks at a time to the tape controller which will will write as N blocks on the tape. This was different from 1/2" parallel 7 and 9-track tape which was actually had variable size 'blocks' in the writes and the tape format. Since the terminalogy was defined (by IBM) for 5/7/9 track drives, we still use that terminology. The trick is that streamer** format write* (which is bit seral): <512 bytes of serial data [blk1]><512 bytes of serial data[blk2]>.<512 bytes of serial data>[blkn] The key is that there are no inter-record gaps (IRG) between the and < frames when recording on a streamer. BTW: they usually use a serpitine scheme - starting with the center of the tape and moving outwards in a circular pattern - IIRC down on tape end and up on tape start -- but that's fuzzy in my memory and I'm at work so I can not look in any of the controller books have at home. If you lose the bit stream on input (data under run), the tape controller backs up the tape and when it starts to write again, it goes over the last block trailer and start its new write at the end of it. For instance the original 1/4" QIC format wrote 4 passes, then later when the recording head got better, it wrote 9 passes and then even more, but in the newer formats (and withe better media) the head was smaller. Also remember that EOT is handled different in the streamer formats from 1/2" 7/9 track and IIRC EOT can even differ between the different streamer formats. If you look at 1/2" parallel 7/9-track (which is where the terms and basic concepts originate) 9-track has a 'inter-record gap' between the last block's trailer and the next block's header. When IBM originally defined that 7 and 9 track formats (whch ANSI later codified), these gaps are defined so that the there is time to start and stop the motors (somewhere, I have a very old IBM document from the late 60s that describes this very well using IBM terms like LRECL and DASD - direct access storage device ;-) The key difference from a streamer tape is that the IBM LRECL or logicial record size, could (and did) vary ***. But to try to keep the amount of wasted space (*i.e.* least amount of inter-record gaps), different programs use different 'block size' and some formats (like ANSI labeled tapes) the block size (LRECL) can vary within the tape itself. Also, I don't think I ever knew why, but for some reason IBM's tape utilites tended to like LRECL 10240 and 20480. Since many of us UNIX folks came from IBM and Multics, we also used the same sizes (*i.e.* 20b or 10240 8 bit bytes) - it was reasonably efficent (we got 150M per traditional 2400" 1/2 tape at 6250 BPI - you could get 1/3 more space when 3M created a 3600" that fit in the original 1/2" reel) . Thus the on-tape format of 1/2" (which is parallel encoding and one pass over the tape): .. [if the last last 'file' on the tape a second] Note: LRECL BYTES of BLK1 did not have to be the same as much less Thus concept (and term) of 'tape blocks' was born. Also note be careful the term 'file' has specific meaning to a tape. DEC started to use the term 'save set' to disamiguated it BTW. A tape 'file' N tape blocks, followed by an a EOT mark.Thus, two adjacent tape marks actually delinated end of recorded data in the tape. Thus in 7/9 track formats when a new file is written the last is backed up over and data frame writing starts over writing the second after the last So ... what this all means is that from the OS side, you start a DMA on X blocks and then let the tape controller read or write it. No matter the number of blocks
Re: TK50, was: Re: Ultrix Tape: Block Size?
emanuel stiebler writes: > TK50 on QBUS with an TQK50 controller which really didn't stream to often > TK50 on QBUS with an TQK70 controller, which doubled the memory of the > TQK50, which was capable of streaming ... Now *that* I wasn't aware of! Thanks! I'll have to open up my PDP-11/83 tonight. Its TK50 will stream while writing, as long as what's being written can be read reasonably fast from (RQDX3/RD54) disk. The TQK controller is sitting right up at the top end of the Q-bus, to get high priority -- but I don't know if it's a TQK70. I've really just assumed it's a TQK50 without thinking too much about it... -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay
Working with Old Tapes
Probably preaching to the choir, but if you are going to be mounting an old tape, there are some issues to be aware of. Tape is really stable over time and your data is likely still there. As tapes age, the surface of the gluey oxide coating degrades. The symptoms will be very discernable with a nine-track drive as you can see the head/tape interface easily. The surface of the tape in contact with the drive's head will ablate, leaving gunk on the head. The tape will make a squeaking noise while running and may eventually stop moving due to sticktion at the head. Cleaning the head from time to time may get you through a read of a tape for backup purposes, but there is a machine called a 'tape cleaner' which is a drive which leads the tape through a path seeded with knife-edges. As the tape travels through the machine, the knife edges scrape a layer of oxide coating from the tape and smooths and polishes the surface exposed. This will restore a tape to full usability and should not affect data stored on the tape. Pinch rollers can also collect oxide and need cleaning. Pinch rollers on old drives may be so degraded as to make the drive unusable. I had a Data General cart drive using Qic 300? tapes. The drive roller was wrecked. I found in my junkpile a roller from an Epson Actionprinter 3250, removed it from the printer's output roller and after cleaning the drive axle in the qic drive, used some windex to lubricate a ballpoint pen barrel, stretched the roller onto the pen body, held the body to the face of the drive axel and pushed the roller on. It worked beautifully from then on. Stone knives and bearskins. You can carefully make a set of knife edges on a board, thread the tape through the edges, and use the drive you have to move the tape through your homemade cleaner. Best, Jeff
Re: Identifying TO-3 w/HP house numbering
Yay! Congrats Josh! Marc > On Oct 16, 2018, at 8:39 PM, Josh Dersch via cctalk > wrote: > >> On Tue, Oct 16, 2018 at 11:19 AM Josh Dersch wrote: >> >> Thanks, all, for the responses! The way it measures out makes it look >> like it may be an MJ10006 or similar. I think it's probably ok. >> >> I poked around a bit more this morning and it's looking like part of the >> flyback is shorted out -- we have a 2382 at the museum and I popped it open >> just now and I verified that it measures differently (i.e "not shorted" :)) >> at the same points. So that's likely my problem. Drat. >> >> - Josh >> > > And I was wrong -- the flyback's fine (yay!). Found a nearby 0.015uF, 400V > film capacitor that was shorted. Replaced it and now I have video! It's a > bit dim, it's too wide, and gets wider as it warms up but it's a start :). > > Thanks again, > Josh
Re: Working with Old Tapes
On 10/17/18 10:51 AM, Jeffrey S. Worley via cctalk wrote: > Cleaning the head from time to time may get you through a read of a > tape for backup purposes, but there is a machine called a 'tape > cleaner' which is a drive which leads the tape through a path seeded > with knife-edges. As the tape travels through the machine, the knife > edges scrape a layer of oxide coating from the tape and smooths and > polishes the surface exposed. This will restore a tape to full > usability and should not affect data stored on the tape. > "Tape Scrapers" do exactly that. Bake the tapes first, preferably with a lot of moving air before attempting to "clean" a tape. If you don't all you will do is scrape off the binder. Their original purpose was to remove surface debris, NOT cut a layer of binder off.
Re: Working with Old Tapes
> On Oct 17, 2018, at 2:05 PM, Al Kossow via cctalk > wrote: > > > > On 10/17/18 10:51 AM, Jeffrey S. Worley via cctalk wrote: > >> Cleaning the head from time to time may get you through a read of a >> tape for backup purposes, but there is a machine called a 'tape >> cleaner' which is a drive which leads the tape through a path seeded >> with knife-edges. As the tape travels through the machine, the knife >> edges scrape a layer of oxide coating from the tape and smooths and >> polishes the surface exposed. This will restore a tape to full >> usability and should not affect data stored on the tape. >> > > "Tape Scrapers" do exactly that. Bake the tapes first, preferably with > a lot of moving air before attempting to "clean" a tape. If you don't > all you will do is scrape off the binder. > > Their original purpose was to remove surface debris, NOT cut a layer > of binder off. The 1/2 inch tape drives I'm familiar with incorporate such a device. Typically it's a ceramic thing, so it looks like a small shiny white rectangle near the heads. It has to be scrubbed clean periodically when it gets brown from accumulated ferrite dust. paul
Re: OTsorta : Old phone system(s) avail
Thanks Liam!! Please read on below... On 17/10/2018 17:07, Liam Proven via cctalk wrote: > On Wed, 17 Oct 2018 at 17:54, Andrew Luke Nesbit via cctalk > wrote: >> >> I have an idea for a project to reduce my dependency on my phone. I'm >> trying to move to a model where voice, voicemail, and SMS are all that I >> need when I'm on the go. > > There are plenty of such devices around. By "model" I meant something different so I think I may have confused some readers. But the answers I got have been very helpful anyway. > https://www.theguardian.com/technology/2018/aug/16/nokia-8110-4g-review-nostalgia-the-matrix-banana-phone >From the list you posted, the Nokia 8810 looks like my favourite so far. But the details of the review leave many things to be desired, especially the reported difficulty of texting. In fact, by "model", I meant a simple model of usage, i.e., voice and SMS to reduce dependence on the phone. If the phone breaks or is stolen, disruption to life is minimal. This also means that the phone is not used for 2FA (I believe using one's primary phone for 2FA is a terrible idea). Second, relatively advanced functionality can be implemented by sending SMS messages with simple commands and receiving a response to the phone in some appropriate format. The server-side service, which might use a service like Twilio, could do the heavy lifting. A navigation service would be a useful service if you find yourself in a pinch, for example. Third, access to WiFi and 4G are necessary for tethering, for when the user wants to do real computing on a GNU/Linux laptop. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
RT-11 DY install
I'm trying to use a simulated RX02 disk (under simh) with RT-11 and can't seem to get the DY driver to install. Here's the relevant log: sim> set ry enabled sim> att ry0 ry0.dsk RY: creating new file RY: buffering file in memory sim> c .install dy ?KMON-F-Invalid device installation DL0:DY.SYS .dir dy.sys DY.SYS 4P 20-Dec-85 1 Files, 4 Blocks 14841 Free blocks I've tried with 2 different software "kits", the one from the simh site and the one from bitsavers. Any ideas? Thanks, Don
Re: Working with Old Tapes
On 10/17/18 11:10 AM, Paul Koning via cctalk wrote: > The 1/2 inch tape drives I'm familiar with incorporate such a device. > Typically it's a ceramic thing, so it looks like a small shiny white > rectangle near the heads. It has to be scrubbed clean periodically > when it gets brown from accumulated ferrite dust. Certainly mine do--some drives use a single ceraminic "blade" and others use a sort of comb structure. My tape cleaner uses a tungsten carbide blade and a follow-up vacuum that picks up the debris. But even after baking, there are a few tapes that have issues where the binder has bled through to the surface. Such tapes will even stall when being drawn through the mechanism of a cleaning machine. I find that coating the tape with cylcomethicone allows the tape to pass freely. The lubricant evaporates without affecting the tape in a few minutes-half hour. I've used the same on floppy disks with good success. My application method is with a felt wick fed by a reservoir. FWIW, Chuck
Re: OTsorta : Old phone system(s) avail
[Reposting because my previous reply to this message was set to the wrong From address.] On 17/10/2018 17:39, Grant Taylor via cctalk wrote: > Remember that it is possible to spoof or hijack SMS / phone numbers. So > don't rely on just that for security. Good point. As far as I can tell, there's no way of securing communications with a purely SMS-based approach. Maybe voice fingerprinting and authentication for each request..? I can already smell feature creep. -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: OTsorta : Old phone system(s) avail
On 10/17/2018 01:32 PM, Andrew Luke Nesbit via cctalk wrote: [Reposting because my previous reply to this message was set to the wrong From address.] I hate it when I do that. Good point. As far as I can tell, there's no way of securing communications with a purely SMS-based approach. I think you need additional factors in the SMS message to validate things. Each additional factor makes it harder to /successfully/ spoof control messages. Think something along the lines of a OTP. Maybe voice fingerprinting and authentication for each request..? I can already smell feature creep. Um, as far as I know, SMS doesn't carry anything other than a small amount of text. Maybe you're meaning MMS, which can carry voice and more text. I think that voice recognition might be more problematic. As in speech recognition. I would wonder about some sort of challenge response and / or SMS(MMS)-back system. You could also look at signing MMS messages (which can carry more data) with a standard PKI. That way it would be trivial to have the recipient validate things. -- Grant. . . . unix || die
Re: OTsorta : Old phone system(s) avail
> On 17 Oct 2018, at 17:39, Grant Taylor via cctalk > wrote: > > Remember that it is possible to spoof or hijack SMS / phone numbers. So > don't rely on just that for security. Good point. As far as I can tell, there's no way of securing communications with a purely SMS-based approach. Maybe voice fingerprinting and authentication for each request..? I can already smell feature creep.
Re: Identifying TO-3 w/HP house numbering
Josh - You may want to contact Denis Kohlhagen, at Butler Winding. IF this is for the preservation of an HP terminal in the museum, they may wish to assist in rebuild/rewinding that flyback. There are US firms that can perform this work, and publicity of preserving history is desired by some corporate marketing dept. Butler Winding 7426A Tanner Parkway; Arcade, NY 14009 USA http://www.butlerwinding.com/ Phone: 1-716-532-2234 Fax: 1-716-523-2702 == “I poked around a bit more this morning and it's looking like part of the flyback is shorted out -- we have a 2382 at the museum and I popped it open just now and I verified that it measures differently (i.e "not shorted" :)) at the same points. So that's likely my problem. Drat. - Josh” Sent from iPad Air
Re: RT-11 DY install
On 10/17/18 1:53 PM, Don Stalkowski via cctalk wrote: I'm trying to use a simulated RX02 disk (under simh) with RT-11 and can't seem to get the DY driver to install. Here's the relevant log: sim> set ry enabled sim> att ry0 ry0.dsk RY: creating new file RY: buffering file in memory sim> c .install dy ?KMON-F-Invalid device installation DL0:DY.SYS .dir dy.sys DY.SYS 4P 20-Dec-85 1 Files, 4 Blocks 14841 Free blocks I've tried with 2 different software "kits", the one from the simh site and the one from bitsavers. Any ideas? Thanks, Don Try set cpu 256K set rx disable set ry enable show ry RY address=1170-1173, vector=264, BR5, 2 units RY0 512KB, not attached, write enabled double density RY1 512KB, not attached, write enabled double density Note: Apparently the RY emulation won't load if more than 256K memory is specified as the DEC hardware did not support DMA in a 22bit box. I'm entirely not sure why SIMH has to enforce this as its possible to work around (e.g. TSX+ supports buffering the IO). Anyone know how to override and load in SIMH? Jerry
Re: RT-11 DY install
On 10/17/2018 07:19 PM, Jerry Weiss via cctalk wrote: > On 10/17/18 1:53 PM, Don Stalkowski via cctalk wrote: >> I'm trying to use a simulated RX02 disk (under simh) with RT-11 >> and can't seem to get the DY driver to install. >> >> Here's the relevant log: >> >> sim> set ry enabled >> sim> att ry0 ry0.dsk >> RY: creating new file >> RY: buffering file in memory >> sim> c >> >> >> .install dy >> ?KMON-F-Invalid device installation DL0:DY.SYS >> >> .dir dy.sys >> >> DY .SYS 4P 20-Dec-85 >> 1 Files, 4 Blocks >> 14841 Free blocks >> >> I've tried with 2 different software "kits", the one from the simh site >> and the one from bitsavers. >> >> Any ideas? >> >> Thanks, Don >> > > Try > set cpu 256K > set rx disable > set ry enable > > show ry > RY address=1170-1173, vector=264, BR5, 2 units > RY0 512KB, not attached, write enabled > double density > RY1 512KB, not attached, write enabled > double density > > Note: Apparently the RY emulation won't load if more than 256K memory > is specified as the DEC hardware did not support DMA in a 22bit box. > I'm entirely not sure why SIMH has to enforce this as its possible to > work around (e.g. TSX+ supports buffering the IO). Anyone know how to > override and load in SIMH? If it didn't it wouldn't be emulating real PDP-11 hardware. I have a number of RX02 systems and they do not work with more than 256K. bill
Re: Documation TM200 card reader - pinch roller restoration
A quick update. Thanks to those who sent pics of intact rollers. Derived from those the correct pinch roller diameter is 27.20 mm. Notes here: http://everist.org/NobLog/20180922_data_in_holes.htm#rub It seems there's a few people who need new M200 rollers. Once/if I perfect a successful method of making replacements I'll offer them for postage and a few dollars. But I'm in Australia. Or, there's this guy in the USA: http://www.terrysrubberrollers.com/ Now the correct OD is known he's an alternative, with real rubber. (Maybe my end result will be rubber too. That remains to be seen.) I still haven't found a service manual for the TM200 (with schematics.) Guy
Re: Working with Old Tapes
> On Oct 17, 2018, at 12:22 PM, Chuck Guzis via cctalk > wrote: > >> On 10/17/18 11:10 AM, Paul Koning via cctalk wrote: >> >> The 1/2 inch tape drives I'm familiar with incorporate such a device. >> Typically it's a ceramic thing, so it looks like a small shiny white >> rectangle near the heads. It has to be scrubbed clean periodically >> when it gets brown from accumulated ferrite dust. > > Certainly mine do--some drives use a single ceraminic "blade" and others > use a sort of comb structure. > > My tape cleaner uses a tungsten carbide blade and a follow-up vacuum > that picks up the debris. > > But even after baking, there are a few tapes that have issues where the > binder has bled through to the surface. Such tapes will even stall when > being drawn through the mechanism of a cleaning machine. > > I find that coating the tape with cylcomethicone allows the tape to pass > freely. The lubricant evaporates without affecting the tape in a few > minutes-half hour. I've used the same on floppy disks with good success. > > My application method is with a felt wick fed by a reservoir. > > > FWIW, > Chuck > Chuck, Where can you get that chemical? Is it a common one? Marc
Re: Working with Old Tapes
On 10/17/2018 11:05 AM, Al Kossow via cctalk wrote: Bake the tapes first, preferably with a lot of moving air before attempting to "clean" a tape. I looked to see if someone suggested a temperature / time, didn't see it. Can you suggest what would work. Also, I've got some friends following on an audio group who are attempting to restore and transcribe tapes, wondering if there might be anything you can recommend, given that media is thinner, and the data is analog, not digital in nature. If too far off topic on the latter, still wondering on the baking process experiences and recommendations. thanks Jim
