Someone shared the following eBay auction in the
comp.sys.ibm.ps2.hardware newsgroup and I figured that someone
subscribed to cctalk might be interested:
Link - IBM 9331-011 8" External Floppy Drive - eBay 183038271095
- https://www.ebay.com/itm/183038271095
--
Grant. . . .
unix || die
On Tue, Jan 30, 2018 at 11:38 AM, Bill Degnan <billdegnan at gmail.com> wrote:
> https://archive.org/details/LOGIC_AppleII_Disk-CPM014
>
> is this what you mean?
>
While that's useful (thanks!), I'm really looking for the complete ZCPRn
distributions, which included source code for the CCP replacement and the
utilities etc.
That's why ZCPR3 took up _nine_ volumes of the SIG/M library.
The IPA is heated to 60C before the ultrasound is able to remove the oxide
remnants, FWIW.
While we can often get the entire smooth surface of the head clean with
swabs and IPA, it is very difficult to clean all the material that forms in
the cruciform trench recessed into the head (where the read/write and erase
coil poles are visible).
Heads can seem clean to the naked eye, but a good stereo microscope will
insure that you have a clean and smooth surface.
Regards,
Carl
Date: Fri, 26 Jan 2018 12:15:34 -0800
> From: Fritz Mueller <fritzm at fritzm.org>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: ultrasonic cleaning for disk heads
> Message-ID: <9F2C2AC7-1B35-46F5-BD92-CC3DFD29FBFA at fritzm.org>
> Content-Type: text/plain; charset=utf-8
>
> I watched with great interest one of curiousmarc?s recent Alto videos,
> wherein they clean a Diablo drive head ultrasonically. I?ve been
> struggling a bit with my restored RK05 drives to completely clean the heads
> after minor head crashes. Not being able to get them really sparkling
> clean makes me always worried about running the drives for more than a few
> minutes at a time, and a little nervous every time I spin them up?.
> Scrubbing and scrubbing and scrubbing with IPA and kimwipes just doesn?t
> seem to get all the crud off.
>
> I do have an alignment pack that I could use to re-align the heads after
> removing them for a proper cleaning this way. Decent ultrasonic cleaners
> aren?t terribly expensive and might be nice to have around the shop anyway
> (I could also do all my eyeglasses :-)
>
> In the video, the heads are submerged in IPA in a glass cylinder, which is
> then placed in the ultrasonic bath.
>
> Has anybody on the list here done this and have tips/advice beyond what
> can be seen in the video? It looked very effective! I?m also having a
> little trouble sourcing the squat form glass graduated cylinder online.
>
> cheers,
> ?FritzM.
>
>
I watched with great interest one of curiousmarc?s recent Alto videos, wherein they clean a Diablo drive head ultrasonically. I?ve been struggling a bit with my restored RK05 drives to completely clean the heads after minor head crashes. Not being able to get them really sparkling clean makes me always worried about running the drives for more than a few minutes at a time, and a little nervous every time I spin them up?. Scrubbing and scrubbing and scrubbing with IPA and kimwipes just doesn?t seem to get all the crud off.
I do have an alignment pack that I could use to re-align the heads after removing them for a proper cleaning this way. Decent ultrasonic cleaners aren?t terribly expensive and might be nice to have around the shop anyway (I could also do all my eyeglasses :-)
In the video, the heads are submerged in IPA in a glass cylinder, which is then placed in the ultrasonic bath.
Has anybody on the list here done this and have tips/advice beyond what can be seen in the video? It looked very effective! I?m also having a little trouble sourcing the squat form glass graduated cylinder online.
cheers,
?FritzM.
Hi all --
Finally got around to fixing the H777 supply in my 11/24 (in the "L-box"
BA11-L chassis) and now I'm looking at getting it to do something.?
First order of business is getting the console SLU hooked up, and I'm
missing the bulkhead panel for it.? There's a 20-pin ribbon cable that
runs from the CPU backplane to this panel, which breaks it out into two
25-pin D-sub serial ports. According to the schematics, this is P/N
54-14218.
Anyone have one of these lying around?? Otherwise I'll just build
something of my own...
Thanks,
Josh
> From: David Bridgham
> Our plan is to produce a Unibus board as well, we just chose the QBUS
> first.
For no particularly strong reasons; I had working QBUS machines, and
prototyping cards, etc, etc.
> (actually, this should work with Q18 QBUS systems as well)
Goodness, never thought of that. Hmmm.. it's probably enough hassle to mod
the software (who ever heard of a 'QBUS map' on a QBUS -11 - but you'd need
it to give DMA devices access to high memory) that it's probably just easier
to go out and get Q22 hardware. Does anyone even have a Q18 /23? I think that
was only the A model, right? I've never seen one.
> we plan to also implement the Able ENABLE+ functionality
In other words, a 'USIC' with Able ENABLE functionality added in.
> This will, of course, require you to modify your OS to support this
> non-standard memory.
We should be programming compatible with the ENABLE, so for OS's where
ENABLE support already exists, it should be a compile-and-go.
> Noel has already done so for v6 Unix.
Back in the day, with a real hardware ENABLE. PWB1, actually (pretty much
V6).
It wasn't too much work; one just changes the address definitions for the
User and Kernel PARs from the DEC addresses to the Able ones, and recompiles
all the kernel modules that touch them. One then has to set up the DEC User
and Kernel PARs (which I did in the assembler startup, which was the only
source module that took any serious changes).
(If your OS uses Supervisor mode, well, err... :-)
There are some other minor tweaks needed, e.g. this comment:
/ these routines are used to access /dev/kmem and look at possible
/ NXM locations in the system. The reason it uses this mechanism
/ is that some locations to be examined are on the bus before the
/ ABLE map, and thus cannot be examined by playing with the ABLE
/ map regs, e.g. using the standard u access routines
.globl _fkbyte, _skbyte
.globl _fkword, _skword
Noel
> That sounds pretty awesome. Good job there!
Thanks.? Feeling good today after a bit of frustration with development
not going faster.
> Do you know how hard it would be to take this design and make a UNIBUS
> version? I have an 11/34 languishing under the bench in my hardware
> lab and one of the principal reasons for the languishing is that I
> don't have any drives to go with it.
Our plan is to produce a Unibus board as well, we just chose the QBUS
first.? A Unibus version of the hardware ought to be a fairly
straightforward adaptation of the QBUS board while the QBUS modules in
Verilog will just have to be replaced with Unibus versions.? The busses
work pretty similarly so we're expecting that to also be relatively
straightforward.? Yeah, I've told myself that before.? :-)
For the Unibus (actually, this should work with Q18 QBUS systems as
well), we plan to also implement the Able ENABLE+ functionality which
would give 11/70 size memory.? We'll have some SDRAM onboard that we'll
use for RAM disks but we'll carve out 4MB of that for machine memory and
include mapping tables to access it.? This will, of course, require you
to modify your OS to support this non-standard memory.? Noel has already
done so for v6 Unix.
For those of you who are following along with our QSIC project, today we
booted v6 Unix successfully for the first time.? We'd first tried this a
week or two back but discovered that Unix does use partial block reads
and writes after all and I hadn't implemented those yet.? We're running
this on an 11/23 using the QSIC with an SD card emulating a couple RK05s.
Moving on to a small RAM disk next so we don't have to swap off the
flash memory.? After that, either a larger RAM disk using the SDRAM or
an RP11 to get larger disks than RK05s.
We're getting close to the time when we need to think about making our
own circuit board rather than using the wire-wrap prototype we've been
having fun with so far.
> From: David Bridgham
> today we booted v6 Unix successfully for the first time.
As in, the OS image was loaded from the SD card, then started up using only
the SD card for 'disk'. So this is a pretty major milestone. It's been a long
road (I just looked, and we started on this in the summer of 2015), but we're
finally getting there!
The Unix file system, including the OS and all the various bits and pieces
needed, like /bin/sh, etc, was prepared on a simulator (stock V6 won't run on
a /23, which has no switch register), and then loaded into the SD card using
'dd' running on a Linux box.
Our emulated RK11 doesn't do a perfect job of emulating an RK11 yet (e.g. for
some reason we haven't yet looked into, the BDV11 ROM code won't load the
bootstrap off the 'disk'; Dave had to manually load in an RK bootstrap using
ODT), but enough is now working to let Unix load and run.
> Unix does use partial block reads and writes after all
For swapping, not for file-system I/O (which is all block-based).
> We're getting close to the time when we need to think about making our
> own circuit board rather than using the wire-wrap prototype we've been
> having fun with so far.
At which point we'll be able to supply them to anyone who wants one...
It will be a while yet, but I think we are 'over the hump' on the project,
with the OS booting and running properly.
Noel