I have no idea about the material, but I can tell you about one
application method you may not have considered. I have mentioned it
here before but maybe you have joined the list recently.
Similar drums were made by ICT/ICL from 1962 to 1965 for the 1300
series, and probably for the 1200 series drum based computers in the
They too had fixed heads with set screw adjustment, which was carried
out by monitoring the pressure of compressed air blown through a
venturi in each head while moving an Allen screw.
The 1300 drums were 12000 48bit word capacity, driven by a 3/4
horsepower motor geared up to 5240rpm at the drum spindle for lower
After many experiments they found they could not beat the human hand
applying a magnetisable compound like a potter making a pot. Sounds
very low tech but apparently it works, and I have drums which have not
been touched since manufacture and they still work 46 years on. Of
course for you, low tech could be a bonus as it means low cost. Maybe
your local educational establishment has a skilled potter who could do
a great job for a reasonable price, or just for interest.
> The drum is quite low density, and does not have air bearing heads.
> The head heights are actually adjustable with a bunch of set screws.
> The heads themselves are also pretty big. This is a late 1950s drum,
> not a 1970s era hard disk - there is a world of difference. I would
> bet the heads ride a few thousands above the surface.
> The whole assembly is in a very rigid cast chassis, driven by a
> relatively low-frills AC motor, apparently.
> My thinking is that the drum could be recoated (this is assuming it is
> indeed shot), and using the rigid cast chassis, ground down to a
> smooth surface with a custom made tool. This is much like a "poor mans
> wheel lathe" used on railroad wheels. As long as the bearings are
> still pretty tight, there should be very little wobble between the
> drum and chassis. With each head being adjustable for height, much
> inaccuracy across the drum becomes fairly unimportant. Inaccuracy
> around the drum is more of an issue, but I suspect it will not be too
> bad if the correct tool material and magnetic coating is used, and the
> drum ground down gently. I will ask my real machinist friends about
> the tooling, as I doubt I (or any of us) could make it.
Does anyone know of a 'bridge' converter that would allow a scsi disk to interface to an MFM controller?
----- Original Message -----
From: Dave McGuire <mcguire at neurotica.com>
Date: Wednesday, November 19, 2008 8:38 am
Subject: Re: AT&T 7300/3B1's (was: Re: Who is vintagecomputermuseum?)
> On Aug 18, 2008, at 10:26 AM, Mark Tapley wrote:
> > I'll hunt for mice. I don't think I kept a spare, but if I did,
> > I'll let you know.
> [old message referring to 3B1 mice, I couldn't find mine]
> I found my 3B1 mice. I hope to get the machine running soon,
> I seem to have a shortage of functional MFM drives. Ugh.
> Dave McGuire
> Port Charlotte, FL
It looks like sometime in the future I may need to rebuild a damaged
magnetic drum. It has some scratches that may be too deep. As a
brainstorm, I am wondering about recoating the surface. If I use
refined iron oxide, what would I use as a fixer (glue)? What was
typically used on early hard disk platters and drums?
Hmm... I've sent a number of things to this list which have not ever
shown up here. Curious if I can actually really post to the list...??
I also see that postings from others show up about 5 to 6 days after they
post them. For example, yesterday 11/29, I received gobs of postings
dated 11/24. There will be many days of silence and then all of a sudden
I'll get a bunch of them all at once, that many days behind.
mailto:chrise at pobox.com
Does anyone here have pull with Sun Microsystems or know someone who does?
I'm trying to get the right person jazzed up about the idea of a Type 7
keyboard built like a Model M. I've already emailed clickykeyboards.com
about it and they'll do the engineering and design work for about $27k. A
Type 7 sells brand new for around $50. I'm sure people would be more than
willing to pay twice as much for a "Type 7m".
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Q: What is the most annoying thing in e-mail?
I was staring at an SBC I have here with a 6MHz Z-80, some ROM, some RAM,
and a 26-pin off-board bus for some Z80-PIO boards (this thing was built
as a multi-parallel-printer switcher). I've been musing about what it
would take to boot CP/M up on this.
For user I/O, I was planning on a console serial port and a
emulator. I have IM6402s on hand, but I'd be interested in hearing if
certain other chips are preferred, based on what BIOS code is floating
around out there. I also have a 16550, but I don't think I have any
Z80-SIO chips handy.
For mass storage, I was planning on either Compact Flash or an SD card.
I think I've seen both as I googled around for modern SBCs. Any of the
media I have lying around is plenty large enough (I even have some 4MB
CFs and a 2.5MB full-sized PCMCIA flash card on hand).
I am a little unclear, though, about how traditional CP/M systems
were set up for ROM and RAM. Was it common to use a "shadow ROM"
in low mem at reset, then have the BIOS live at the top of memory?
How did 64K RAM CP/M machines handle the BIOS? Did they temporarily
ghost the ROM on top of RAM until some bit of code could read ROM
and write RAM then bank out the ROM? Since I think I "need" at
least 48K of RAM, I was planning on a pair of 62256s. I could easily
do 56K of RAM low and 8K of ROM high, I think, unless there's some
other arrangement that's obvious to try for a simple design.
I've never tried writing a BIOS for a CP/M machine, but my understanding
is that things are modular enough that once you know what I/O chips
you have and at what I/O addresses, for a straightforward, non-clever
design, the coding is equally straightforward and non-clever (but please
feel free to enlighten me if otherwise).
Thanks for any tips, especially from anyone on the list who has ever
rolled their own CP/M machine.
Ethan Dicks, A-333-S Current South Pole Weather at 4-May-2008 at 19:40
South Pole Station
PSC 468 Box 400 Temp -74.2 F (-59.0 C) Windchill -105.4 F (-76.4
APO AP 96598 Wind 7.4 kts Grid 77 Barometer 691.6 mb (10194
Ethan.Dicks at usap.gov <http://www.classiccmp.org/mailman/listinfo/cctalk>
Funny you should mention the subject, I am working on a very similar
Last year, I made a completely home brew Z80 computer with prototype boards.
It is a fun project and you can definitely build your own CP/M computer from
scratch. It really is not that hard.
This year, I am remaking the design using manufactured PCBs.
I recently got my first batch of prototype PCBs and have been building up
and testing them.
So far, I have gotten the CPU, ROM, RAM, UART, and most of the glue logic
working and tested.
It is not complete yet as I still need to wring out much of the hardware and
have not even started on the PPI or RTC.
However, last year I was able to boot the previous system into its monitor
and even boot CP/M.
CP/M used a 32K ROM drive for drive A:, a 448K RAM drive for drive B:. I
implemented an IDE port and a hard disk for drive C:.
Those all worked pretty good. I built but never tested a floppy drive
The whole system is pretty simple, uses plain 74LSxxx chips, no programmable
parts (except the EPROM) or hard to get parts.
No SMT or funky technologies, just plain through hole DIP chips.
I have all the software and am presently going through the library
reinstalling it on the new system.
So far, I have most of the easy stuff working. I do have the RAMless
monitor working and next will be the regular monitor.
Finally it will be the CP/M system and the RTC software.
Anyway, if your interested, I am keeping a small Google group of files and
> What is the minimum satisfactory sampling rate if one wanted to emulate an ST-412
> interface and have it RLL (2,7)-capable?
2x, assuming you regenerate the clock. With a digital DLL, the incoming clock would
be on the order of 8x the maximum incoming frequency.
The bitstream is not variable frequency. You can think of what is needed as the inverse
of the read recovery circuit on the drive controller.
The tricky part is generating the recirculating bit stream that you send as read data
back from the simulated drive. It is expecting the data that it just wrote to be in
the data read back on the next revolution. And you need one of these bitstreams for each
> Actually, it's not clear to me if any of the
> bridges supported that command.
I don't know of any MFM/RLL controllers that supported scsi inquire.
ESDI was the first 5" drive interface to support geometry inquiry
which is needed to make inquiry work w/o the host specifying
the drive geometry to the bridge board.