Re: Question about DECtape formulation
On Sun, Jan 23, 2022 at 03:09:53PM -0800, Gary Oliver wrote: > Taking the bits of tape, I exposed them to various concentrations of > isopropanol/water (from about 25% to 99% iso) and found than in all cases, > some of the data side of the tape came off on the wipe.? The remaining tape > fragment appears intact - the brown oxide was still there but both sides > were now the same color, rather than the data side being darker (as were all > my tapes before the test.) > I had done the careful test to find something safe to clean DECtape. One time I grabbed the wrong bottle and that removed the coating. Tape was now totally unreadable in that location. Didn't have any luck with cleaning helping data errors so stopped trying. This was a long time ago so I don't remember if my incorrect cleaning result matched your description.
Re: TI-99/4a Monitor power cord
On Fri, Nov 05, 2021 at 10:13:48PM -0500, David Williams wrote: > I have a TI monitor that has a power cord that is becoming sticky and gummy > and I'm looking at what to do with it. > Any other suggestions on dealing with the cord besides replacing it? > Once the plastic starts breaking down I haven't found anything permanent. Some are breaking down slow enough that cleaning lasts for a couple years. I go though my various cleaners/solvents until I get to one strong enough to clean it up without too much damage. The ones for removing gummy adhesive remover seem to work OK. A mild abrasive cleaning pad or cleaner can also help since sometimes you need to remove the surface plastic layer to get to more stable plastic. Aggressive solvents will also do that but I have trouble controlling them. Not familiar with 99/4a monitors to comment on replacing cord.
Re: LINCtape images
On Fri, Nov 05, 2021 at 10:55:38AM +0100, Christian Corti wrote: > On Thu, 4 Nov 2021, David Gesswein wrote: > > On Wed, Nov 03, 2021 at 10:57:21AM -0500, Jay Jaeger wrote: > > > > > > I have some LINCTape images with diagnostics. Let me know if you need one > > > and I can send you the image. > > > > > I can add them to my browsble archive if you wish. > > http://www.pdp8online.com/images/index.shtml > > Thanks to you all, I've been able to do the first step in recreating > LINCtapes. I have successfully extracted the MARK12 binary [1] from the > dial.linc tape image and convert it into a BN that can be loaded with the > BINLDR. We testet it yesterday and guess what, we could mark new LINCtapes > on our PDP-12 without errors. > Good to hear your machine it working. Looks like your .BN isn't my sites BIN loader conversion. Did you try mine and it didn't work or you had already done your own before I added it?
Re: LINCtape images
On Fri, Nov 05, 2021 at 10:07:33AM -0400, Chris Zach wrote: > Speaking of which I have a couple of boxes of Linctapes from a pdp12 system > that was used in a college. Is there any value in getting the data off them? > If you know they are all CS101 projects then may not be worth the time but I mostly just read the tapes to be sure. Does cause my archive to have a lot of marginal stuff to search through but hopefully the search will help find what you are looking for. Not everybody agrees on what is uninteresting.
Re: LINCtape images
On Tue, Nov 02, 2021 at 07:53:42PM -0700, Vincent Slyngstad wrote: > On 11/2/2021 2:25 PM, Jay Jaeger via cctalk wrote: > > Here is a program I wrote for reading/writing tape images via XModem > > protocol for my PDP-12, and another for comparing two linctapes. > > Cool! I was able to recover the code and convert it into a more modern PAL > dialect. Your listings also don't display the many literals that were > generated on page zero (except sort of implicitly). > Did you put them on your site?
Re: LINCtape images
On Wed, Nov 03, 2021 at 10:57:21AM -0500, Jay Jaeger wrote: > > I have some LINCTape images with diagnostics. Let me know if you need one > and I can send you the image. > I can add them to my browsble archive if you wish. http://www.pdp8online.com/images/index.shtml
Re: SerialDisk (Re: LINCtape images)
On Tue, Nov 02, 2021 at 03:12:05PM +0100, Christian Corti wrote: > On Tue, 2 Nov 2021, Vincent Slyngstad wrote: > > Another option would be to spin the data onto LINCtape with a TD8E, then > > mount the result on the PDP-12. I think Dave is creating the images in > > the first place with either a TD8E, or possibly a custom controller. > > I think he used a custom controller. > I have several TD8E controllers, but the TU56s are wired for the TC08, and > one unit for the TC11. > The TD8E can't read LINCtapes without putting an inverter in the clock line. With it still wasn't great. Code I used depended on the databreak interface board I made for formerly online PDP-8. Being slowly reworked to get rid of the obsolete java front end and dependance on a parallel port which my new server didn't have so will be back online at some point. Currently I use a beaglebone that connects in place of the TD8E. Works better but code gets confused at times with errors. Really needs a rewrite. Also doesn't like most of the LINC-8 tapes I have. Haven't had time to figure out why. http://www.pdp8online.com/dectape/
Re: Burnable, patched Microvax-2000 SCSI-boot EPROM images?
On Tue, Sep 21, 2021 at 12:15:12PM -0400, Paul Koning wrote: > > On Sep 21, 2021, at 12:00 PM, Jonathan Stone via cctalk > > wrote: > > > > The RD53s in both Microvax 2000s are dead. I'm reluctant to buy more 30+ > > year old rotating media. > > If I'm going to buy a disk emulator, I'd much prefer SCSI to MFM, for the > > obvious performance reasons. > > Emulators presumably act, performance wise, like SSDs. Given that, an MFM > emulator will significantly outperform a SCSI hard drive since it has no seek > delays. > > David Gesswein's MFM emulator works impressively well and is inexpensive, too. > The MFM emulator can't transfer data faster than the 5 Mbit/second, 625k Byte/sec of the ST-506 standard. Seek time isn't zero due to overhead in moving the data in the Beaglebone to where the PRU processors can access it. Think its around 0.6ms/head. An entire cylinder is transfered on each seek. Additional time if cylinder was written to. Each track written needs to be moved also. Most ST-506 drives are slower. I'm faster than average seek for RD54 but it wins for single track seek at 4ms with 15 heads.
TSS/8 & dectape
I'm having trouble using DECtapes with TSS/8 under SIMH. I tried with both the RF image and LCM RK05 image and no mater what I do it hangs if I try to access a DECtape. I am trying to use COPY command from account 2. I attach a dectape in simh then assign it in TSS and then try to get a directory or zero the tape with copy. Both hang. Anybody with more TSS knowledge know how to get this to work. Images from bitsavers http://www.pdp8online.com/ftp/images/bitsavers/unknown/ 7196, 7211, 7242, and 7280 have text where TSS/8 was mentioned. These are the ones I wanted to use TSS to see if I can get a directory. 7241, 7253, 7264, 7265, 7275, 7278, 7291, 7292 have contents but nothing I can identify. There are also some LINCtapes that had read issues so unable to determine what the are. What I have decoded http://www.pdp8online.com/images/index.shtml See last 3.
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.
Re: Got DSM-11 running, any manuals online?
On Sat, Jan 09, 2021 at 01:06:19PM -0700, Warner Losh wrote: > > DEC standard 144 of any help? > http://bitsavers.org/pdf/dec/standards/EL-00144_B_DEC_STD_144_Disk_Standard_for_Recording_and_Handling_Bad_Sectors_Nov76.pdf > > Warner > Thanks for looking. That standard is only capable of marking bad sectors. It doesn't have the information on where the bad sectors were remapped to. I took a quick look at the DSM image. It looks like cylinder 511 is where the controller tables are. This cylinder does have a different format. The data didn't match this standard.
Re: Got DSM-11 running, any manuals online?
To possibly be clearer the image of the disk was a raw dump of the disk taken with the mfm emulator/reader board so it sees all the extra data the controller puts on the disk and the bad sectors etc. As far as I know no documentation exists of the low level format and revector table etc. For RQDX3 the controller has extra information at the beginning of the disk so mounting the raw image under SIMH doesn't work. The RQDX2 apperently puts its information at the end. Might be possible to reverse engineer the format if we get sector dump from the host to compare to the raw disk dump. Nobody has decided to tackle that. For the dump of my RD53 on Vaxstation RQDX3 head 0 sectors 0-2 are normal, 3-16 are funny format. Head 1 and 2 are all funny format. Head 3 sectors 0-2 are funny format. Removing those didn't work for me if I got my dd commands correct. On Fri, Jan 08, 2021 at 09:29:19PM -0500, Chris Zach wrote: > If so, then that's probably what the RQDX1/2 format *was*: Just a big bunch > of 512 byte blocks, starting at zero and going up to the top. > > The controller had to know the geometry of the drive in order to move the > heads, know how many cylinders there were, etc. One thing I did notice is > the last cylinder of the disk is not formatted like the others and throws a > bunch of errors on the MFM_READ command on all tracks. It's possible that > the controller checks there first, then consults the ROM based lookup tables > to get the proper disk geometry. Which explains why some controllers > supported RD51,52 and later ones supported the 53 but none supported the 54. > > On the RQDX3 formatted disks, the first few tracks are also in a weird > format, it's possible that is where the controller stores the > head/cyl/sector format information. Note that a RQDX3 disk image does not > seem to be able to connect up to the RQ driver like the RQDX2 one. > > Interesting stuff. I'm guessing if you remove the first couple of tracks > from the file one could then read the rest of the disk on SIMH (as the rest > is probably just a big pile of blocks and that's all that matters to SIMH) > unless there are remapped sectors in which case I have no idea how those > would work. > > Fun stuff. > C > > On 1/8/2021 8:54 PM, Eric Smith via cctalk wrote: > > On Fri, Jan 8, 2021 at 6:16 PM Chris Zach wrote: > > > > > True, however SIMH has to write things to a "real" file that emulates > > > something of a disk. > > > > > > > I thought the SIMH representation of an MSCP disk was just a linear array > > of 512-byte blocks, from block 0 to block n-1, in which case, it's still > > not at all surprising that any RQDXn, or any other MSCP disk with the > > standard Unibus/Qbus MSCP port interface would "just work". > > > > If I'm wrong about how the disk is represented by SIMH, then maybe it could > > be more surprising. > > > > > --
Re: ICL PERQ 2 T2 Micropolis 1303 spinning down.
On Sat, Jan 02, 2021 at 09:29:16AM -0500, Chris Zach wrote: > Meantime, anyone know how to convert one of Dave G's disk images on the MFM > formatter to a format that can be read by SIMH? I have been working a lot > with this thing, and would like to see if any of the data is really there. > The extracted data file will work if the controller isn't too smart so the OS view of the disk doesn't match the actual disk format. This seems to be the case for many non DEC systems. DEC liked smart controllers where the disk has extra data the controller used for storing info it needs and doing bad block remapping etc. SIMH doesn't deal with the disk level format so this information needs to be removed and bad block mapping handled. As far as I know nobody has taken the time to figure out how to do this. The only way I know currently for certain DEC controllers is to create an emulator file and use a real machine. My code will handle bad block remapping for some simple sector/track remapping that is indicated in the sector header but not for complex stuff DEC did. It does put the output data in logical sector order.
Re: ICL PERQ 2 T2 Micropolis 1303 spinning down.
This is my info on RD53 sticking heads. Your symtoms match what I have seen with this drive. If the heads are stuck to the rubber bumper the drive will spin back down when it finds the heads won't move. It will also spin down if it can't switch from the coarse speed control loop to using the head servo signal. There is a narrow band where the heads are parked with the proper signal. When the rubber has deteriorated the heads are no longer over it. Adding shims can fix that. I used a tent with RK05 filter but others have opened drives in reasonably clean locations sucessfully. Best to keep the pets away. http://www.pdp8online.com/rd53/rd53.shtml Shim picture. http://www.pdp8online.com/rd53/pics/lock.shtml?small On Sat, Jan 02, 2021 at 02:05:11PM +0100, Mattis Lind wrote: > Den l?r 2 jan. 2021 kl 11:48 skrev Rob Jarratt >: > > > When that has happened to MFM disks of mine it has been because for one > > reason or another the heads have not moved and found track 0. Why they > > aren't moving could be more than one reason. They could be stuck, or there > > could be some other problem that is preventing them getting the power > > needed to move. > > > > Did you solve the problem? How? > > I have heard that Micropolis 1325 is prone to have a problem with a rubber > bumper that sticks to the head mechanism. Maybe it is the same for this > Micropois drive? What resolutions are there to this type of problem? > > /Mattis > > > > > > Regards > > > > Rob > > > > > -Original Message- > > > From: cctalk On Behalf Of Mattis Lind > > via > > > cctalk > > > Sent: 02 January 2021 08:59 > > > To: General Discussion: On-Topic and Off-Topic Posts > > > > > > Subject: ICL PERQ 2 T2 Micropolis 1303 spinning down. > > > > > > I have a nice ICL PERQ 2 T2 that I am going to start working with now. > > > > > > First thing was to try to image the hard drive. It is a Micropolis 1303. > > It spins > > > up but when it reaches what I think the correct speed it immediately > > spins > > > down. Usually I think there would be a click and then the heads would > > > recalibrate. But there is no click and no head movement. > > > > > > I really would like to make an image of the drive. What are your > > thoughts? > > > Are the heads sticking? > > > Some kind of solenoid that is not releasing the heads? Not properly up to > > > speed? (but it sounds like the speed is right) > > > > > > /Mattis > > > > > > > --
Re: Ouch, but 2 Perqs out.
On Sat, Dec 12, 2020 at 10:00:43PM -0500, Chris Zach wrote: > > I'm going to have to get that GSC thing out as well if I am going to reach > these. > Looks like a rebadged HP 1000 series machine.
Re: Care and feeding of some Lisp machines (TI Explorer and Xerox Star)
On Mon, Sep 14, 2020 at 03:35:50PM +0200, Michael Engel wrote: > > Before I start to disassemble and test the machines, I would be interested > to hear about specific problems you might have experienced bringing up one > of these two machines, preferably those on the unexpected side. > I recently worked on getting a Xerox Star running. https://lists.vcfed.org/pipermail/vcf-midatlantic/2020-August/018468.html Others finished getting it running last weekend. If it has a Quantum Q2040 the heads will likely be glued in place by a deteriorating rubber stop. The page above has link to how I delt with it to recover the drive contents. Some also have dry bearings. We decided to use a drive emulator for now using the Darkstar Viewpoint disk image. Also check the voltage drop on the +5.2 under load discussed in the page linked to. > Another thing that is also missing is the mouse pad for the three button > optical Xerox mouse. Is it possible that an optical mouse pad for Sun/SGI > machines is compatible? > You can print one http://www.digibarn.com/collections/devices/xerox-mousepad/index.html
Re: Getting files off a 7300--Mission accomplished
On Mon, Jul 20, 2020 at 11:58:01AM -0700, Ian Finder wrote: > I may be able to track down floppies for 7300 TCP, if we can confirm it is > extinct in the wild... > It may exist but is wounded. https://archives.loomcom.com/retrocomputing/UnixPC/Install/standardized/ethernet/ All the 10S disks seem to have been read in a way that only got 9 sectors per track so are no good. The ethernet_hardware_diag.dd is bad. The files are in multiple locations on this site but any 10S image thats not 404480 is bad. Manual is here https://archives.loomcom.com/retrocomputing/UnixPC/3B1_Docs/
Re: Getting files off a 7300--Mission accomplished
On Mon, Jul 20, 2020 at 05:12:10PM -0400, Chris Zach wrote: > Working on it. Question: Was the 67mb drive in a 7300/3B1 a miniscribe 6085? > Yes it was. http://www.pdp8online.com/3b1/drive.shtml
Re: Getting files off a 7300
On Mon, Jul 13, 2020 at 06:12:34PM -0400, Chris Zach wrote: > Anyone know the best way to get files off an AT 7300/3B1 computer? This > one has a lot of Perq stuff in a directory as well as hilarious things you > can do with RP06 disk platters (ah, when we were young...) > You may have finished by now but since I have done that reasonably recently I though I would document what I did/found. Probably the best way was the serial already discussed since you can start it running and let it run without needing to interact. I used kermit. Copy here http://unixpc.taronga.com/csvax/ Kermit setting I used on Linux set line /dev/ttyUSB2 set speed 9600 set send packet-length 1000 set file names literal SET CARRIER-WATCH OFF kermit settings I used on 3b1 set window 3 set receive packet-length 1000 set file names literal set file type binary I had enabled login on the serial port and had logged in so didn't need the set line. You have the floppy drive. The normal 3b1 format is 8 or 10 sectors but it can with the proper software read & write DOS disks. Later versions of the OS came with msdos command to read floppies and md_write and md_format. You probably want to use them to install mtools which are nicer for using msdos floppies. Binaries in above directory. /dev/fp021 is floppy first partition, /dev/fp020 is full disk Also found this page on transfering files that gives another method. https://rhodesmill.org/brandon/notes/unixpc/transfer.html If you have a floppy or hard drive image such as from my emulator there are tools to work with them. https://github.com/dgesswein/s4-3b1-pc7300 Since mounting was done as Linux kernel driver its going to be work to get it to build on current Linux. I have a fedora core 20 system I keep around that the driver works with. > It does have an AUI Ethernet port on the back, but doesn't appear to have > TCP/IP installed. Maybe I can install TCP and find my old Synoptics 10bt to > AUI adapter? > Never had access to a machine with Ethernet so can't help.
OSI floppy test program
I and others were having some problems with our floppy drives. Since I couldn't find a diagnostic program for the Ohio Scientific I wrote one. http://www.pdp8online.com/osi/osi-floppy-test.shtml With some floppy testing info here http://www.pdp8online.com/osi/floppy-repair.shtml If you try it let me know how it goes.
Re: Looking for a pair of DEC RL02 drives, working or otherwise
On Sun, May 10, 2020 at 07:29:53PM -, Stephen Buck wrote: > Looking for a pair of DEC RL02 drives, working or otherwise, for a PDP-11 > restoration destined for a local computer museum in Boulder, Colorado. It's > fine if it's not working - I'm happy to try and get it up and running. Thanks! > > masterb2...@gmail.com has RL drives. Looks like most may be RL01's. He is also desiring to move whole racks vs parting them out. Ebay is https://www.ebay.com/sch/masterpequa/m.html though currently doesn't have any PDP-8 stuff up. He has a lot more pre and post Omnibus equipment that he will be selling in various condition. Keep in mind he is not a PDP-8 expert in any questions. Equipment is in Long Island.
Re: DEC OS/8 Question (getting an error TOO BIG INIT)
On Wed, Apr 08, 2020 at 03:34:18PM -0400, Bill Degnan wrote: > Hi, > . FRTS > > ..dumps me to the * prompt ... > > *RKB0:ADVENT.LD [return] > * [esc] > > rather than loading ADVENTURE I get the following result: > > D.F. TOO BIG INIT > MAIN 1740 > . > You need to specify the datafiles to use. .R FRTS *RKB0:ADVENT.LD *RKB0:ADVENT.TX/1 *RKB0:ADVENT.DA/2 *$ . http://www.pdp8online.com/pdp8cgi/os8_html/ADVENT.DC?act=file;fn=images/os8/diag-games-kermit.rk05;blk=2243,9,1;to=auto
Re: ISO earl TI DSP kits
Until they are up on bitsavers you can get them from here. http://www.pdp8online.com/misc/TMS320_TMS340.zip On Sun, Mar 08, 2020 at 01:04:41PM -0400, emanuel stiebler wrote: > On 2020-03-07 14:38, David Gesswein via cctalk wrote: > > > I found around 70 disks for the TMS320C30 and TMS340x0. I can read these > > Let me know your current desires for archiving such as IMD or files, text > > label > > info or disk pictures etc. Do you want the TMS340 graphics processor disk > > images also? > > Please share those ... > > > > --
Re: ISO earl TI DSP kits
On Sat, Mar 07, 2020 at 02:45:28PM -0500, Toby Thain wrote: > > Curious what kind of tools that comprises and for what platform? The > 340x0 was used in Truevision NuVista video cards and for a long time I > was looking for the Mac (MPW I think) cross-development tools. > They were DOS tools. We used boards with the 34010 and 34020 in our emulator of military UYQ-4 and UYQ-21 displays. The UYQ were vector display list units which we emulated with 1280x1024 raster display.
Re: ISO earl TI DSP kits
My previous employer likely still has the the in circuit emulator for the TMS32010 unless they cleaned up. If the CHM is intereted in it I can enquire if they would like to donate it. I know I have some of the stuff since previous work used them as fast microcontrollers. Should have the data books though I think they were perfect bound. May have others that I snagged when it was being thrown out. I have the wirewrap prototype of the radar scan converter where we used the C30. I found around 70 disks for the TMS320C30 and TMS340x0. I can read these Let me know your current desires for archiving such as IMD or files, text label info or disk pictures etc. Do you want the TMS340 graphics processor disk images also? Small chance I have some TMS32010 stuff though not likely to find it any time soon. Earliest work was on VAX and I know that is all gone. I didn't personally do any of the '10 work. On Fri, Mar 06, 2020 at 11:53:27AM -0800, Al Kossow wrote: > CHM doesn't seem to have much early DSP stuff in the collection > Does anyone have any of the TMS32010/20/30 or C1x/2x/3x hw/sw kicking around? > > Other than the docs I've scanned there doesn't seem to be much on the web > either. > > > > --
DEC flat cables
Has anyone found a good method for repairing the DEC flat cables? The ones with flat wires with plastic laminated to each side. The glue holding the plastic on fails and you end up with two sheets of plastic and loose wires. I had some success with contact cement but it only glues the plastic to the flat wires since it doesn't have any body. I tried one of the rubbery adhesives but it wouldn't set. I assume the plastic prevented evaporation of the solvent. I assume the air cure products would have the same issue. I assume two part or UV cure products if UV makes it through the plastic might work better since they come thick enough to fill between the wires. I've never used any of these to know if they may be a better choice. Desirable would be reasonably quick set.
Re: AED WINC08
On Mon, Nov 11, 2019 at 12:27:29AM -0600, Eric Moore wrote: > Hello, I have a working AED WINC08 drive, which is a winchester drive > emulated to look like an RL02, along with the qbus controller card. > > https://archive.org/details/bitsavers_aedbrochurJan82_2107642/page/n1 > > The winchester drive itself is a fujitsu M2302B. One of the disks (it shows > up as 2 10MB volumes in RT-11) is having write issues. How can I find a > replacement disk drive in working order? The 2302b has a shugart compatible > interface, so should any shugart compatible 8" winchester drive work in the > aed winc08 rl02 emulator? > I looked at the Fujitsu brochures on bitsavers for this drive. It looks like it is SA4000 type with internal data separator so you will need to find that type of disk. I have no actual experience with it to know how picky it was about the disk and what the low level format routines support if you have them. It won't work with my emulator since it only supports SA1000 type drives with the data separator in the controller.
Re: How to format Dectape (TC08 + TU56)
On Tue, May 28, 2019 at 09:21:43PM -0700, Marc Howard wrote: > Hi, > > I fired up the 8/A tonight and the TU56's are failing diags. I want to > format a tape for scratch use but I can't find the MAINDEC that does this > (along with flipping up the backplane switch. > > Can someone refresh me on the proceedure? > td8e_format.bin in here will work. http://www.pdp8online.com/ftp/images/paper_tape/ Manual here http://www.pdp8online.com/pdp8cgi/query_docs/view.pl?id=55 UNIT? 0 FORMAT? MARK 0201 WORDS,2702 BLOCKS.OK?[YES OR NO] YES SET SWITCH TO WTM
More facets of hard disk recovery (SA1000, RD53) and emulation
I have made a SA1000 adapter board for my MFM reader emulator. I did a small run which seems to work so if you are interested email me to get in on the next order. Prices may get a little better if I get enough orders. http://www.pdp8online.com/mfm/ http://www.pdp8online.com/mfm/sa1000/sa1000_usage.shtml I have used it for reading Shugart SA1004 and Quantum Q2040 drives. Another has used it to replace drive in a TRS-80 Model II 8 Meg drive unit. Some other items that may be of interest: Dealing with stuck head problem with Quantum Q2040 drives http://www.pdp8online.com/q2040/q2040.shtml Using a DAC to pull the head servo to recover otherwise unreadable data from DEC RD53 drive. Also procedure tried for Q2040 but data had been erased so not successful. http://www.pdp8online.com/mfm/head_servo/
Re: warped RK05 pack -- lost cause?
On Thu, Jan 10, 2019 at 11:13:00AM -0800, Fritz Mueller wrote: > > > On Jan 10, 2019, at 12:47 AM, Christian Corti via cctalk > > wrote: > > > > I don't think it's the platter but perhaps a dirty hub ring or centering > > cone. Try cleaning the ring and the cone of your disk pack. > > Ah, thanks ? I?ll take a look! > I've found a few packs won't fit properly on the centering cone on my drive. Check to see if it sits flat on the magnet or one edge is up slightly. I wasn't able to see any obvious issues causing it. I haven't resolved the issue so can't give you a solution. If you do find the cause let us know.
Decus #8-250 Fast Fourier Transform
Anybody on the list get these tapes? https://www.ebay.com/itm/Decus-8-250-Fast-Fourier-Transform-FFT-Software-on-Paper-Tape-for-PDP-8-/192646534861?hash=item2cdaa0d6cd%3Ag%3A4ukAAOSwjexbjeWx=true=pZk7jy9IX%252F2eOztzfa26ClklLrI%253D_cvip=true=true=nc&_trksid=p2047675.l2557 I missed seeing that auction.
DEC DS-32 and IBM Series 1
Someone in Barnet, North London, post code is EN5 1RJ has two DEC DS-32 drives and IBM Series/1 computer and some drives. Last wording was Sale or swap. You may contact them at st...@pdp8online.com.
Unknown boards
Can anyone identify these boards? Person I got them from can't remember anything about them. http://www.pdp8online.com/ftp/misc/unknown_boards/ Date codes of 1964. Size 4.5"x3.25". Looks like used card edge for keying but has separate 23 pin connector for electrical connection. No useful markings I can see. Has card ## on the back. Search by picture didn't find anything. Thanks
Re: Commodore Pet 8032 keyboard repair - conductive or capacitive?
On Mon, Jun 05, 2017 at 07:35:13PM -0400, Ray Arachelian wrote: > Very true, I was one of those kids back then. :-D Though to my eye, I > don't see the PCB pads worn at all, so more than likely it's the rubber. > If you haven't seen it there is stuff to repair that. I have used this on remotes successfully. Other similar products are availabe. Haven't had that type of keyboard with problems to try. http://store.caig.com/s.nl/sc.2/category.181/.f
Re: How to refurbish plotter pens?
On Thu, Apr 20, 2017 at 07:37:43PM +0200, Philipp Hachtmann wrote: > I know the following configs: > > Outer shell (always same), narrow inlay, narrow top cap --> for the > pen you pictured, > > Outer shell, wide inlay, wide top cap --> For the Fisher pen > > Outer shell, some other inlay, ink top cap, some plastic ink pen > stuff --> The ink pen config > > I should have all those. Don't know if more existed. > Not yet tried the ink variant. > Felt tip was also available. picture here http://ferretronix.com/1627/
