>From: "Chuck Guzis" <cclist at sydex.com>
>
>On 26 Jul 2007 at 21:59, dwight elvey wrote:
>
> > I'm only familiar with the 2901 and 3000. I've looked at the
> > signetics 8X300 but that is more of a halfway between uController
> > and bit slice.
> > Dwight
>
>MMI's 6701 was *very* close to the 2901. There was also Moto's 10800
>ECL series and some early Fairchild (3800?) parts, as well as Intel's
>3000 series (you can find that on the old MDS-800 8" floppy
>controllers).
>
Hi
When I worked at Intel, I was responsible for test of the analog board
that went with the 3000 series controller board.
It seemed that even at the time, most of the engineers were
only digital and something like a PLL or balanced mixer were
beyond them.
I did find a bug on the controller cards. It seems that there was
a race. It was on one of the lines from the ROMs that controlled
one of the states. The problem was that the newer ROMs
were getting too fast and the outputs were changing too
quickly. I don't recall what was done to fix that but I thought
it was interesting. I believe they added a little more delay
to one of the clocks.
Dwight
_________________________________________________________________
http://newlivehotmail.com
Hello. I found one of these (bare) cards for my Apple II, and have looked
around on the web for documentation and software. I saw an old post you
made about the same hardware, and was wondering if you had anything to share.
Thanks.
>
>Subject: RE: MMI 6701 bit slice?
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Fri, 27 Jul 2007 08:32:44 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 27 Jul 2007 at 6:51, dwight elvey wrote:
>
>> When I worked at Intel, I was responsible for test of the analog board
>> that went with the 3000 series controller board.
>> It seemed that even at the time, most of the engineers were
>> only digital and something like a PLL or balanced mixer were
>> beyond them.
>
>One thing I recall about the MDS floppy controller boards is that
>they ran hot as a two-buck pistol. That was probably true of most of
>the bit-slice stuff of the time.
That and straight 74 (not LS or AS) TTL.
>Around that time, I'd heard something concerning the Intel 8272 (the
>8271 was apparently a horrible botch) FDC that I've long wondered was
>true or not.
The 8271 was single density only and at the time the market wanted DD.
Worked ok but wrong part too late.
>
>I'd heard that Intel started development on the 8272, but couldn't
>quite pull it off, and traded the basic design to NEC in exchange for
>NEC's graphics controller. NEC completed the design as the uPD 765
>and licensed it back to Intel. Is there the slightest grain of truth
>to this?
No. 765 was a NEC design and licensed to Intel. There were some IP
trading done between NEC and intel but involved other parts like
7201 (AKA 8274) and others (micros). Back then the chip makers
very incestuous. From 79 to mid 80 was a very crazy time.
>The 765/8272 in any case was too late for our own development. Like
>a lot of other outfits, we went with the gang on Red Hill Road for
>FDCs.
By then WD had been making functional (usually) 1791/1793 parts for
two maybe three years. However, along the way they often would have
receipe problems and were known to deliver bad parts that would not
work at all. The 1793 was a complex part for it's time and for WD
the only thing they did that was more complex was WD16
(microprogrammed CPU also known as LSI-11). FYI: SMC created a
varient that didn't have the three voltage needs of the WD part
that was also socket compatable.
Allison
I'm not sure if this is sad or funny.
I was in contact with the original owner and was possibly going to take it,
but I gave up my claim because she found someone local who wanted it (you
apparently).
The issue is the shipping cost .... which I fear could be $50 (Ohio, 44720),
these were heavy. Very heavy. My real purpose, frankly, is as possible
spare parts for a (probably non-working) 1620 (the KSR keyboard version of
the same basic printer). I have typewheels, ribbons (may or may not be any
good) and full documentation (including the service manuals)(although I'm
not sure that I know where they are).
Any idea on the shipping cost to Ohio, 44720?
By the way, the 1610/1620 does have software handshaking (ETX/ACK), and if
you short a jumper on the CPU board, it's serial interface runs at 1,200
baud. In that case, you MUST use ETX/ACK handshaking, but it will print at
45 cps instead of 30 cps (and I seem to recall that it does bidirectional
printing in that mode also, if the next line has been fully received). The
difference is quite significant.
Thanks,
Barry Watzman
Watzman at neo.rr.com
------------------------------
Date: Thu, 26 Jul 2007 16:22:04 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: AVAILABLE: Diable 1610 Hytype DW printer
I went ahead and picked up the Diablo 1610 printer from the local
party here who was trying to find a home for it. Now I want to give
it a home...
I checked it out--it works just fine and includes several typewheels
(all various flavors of Courier) and ribbons as well as the
operator's manual. Includes forms tractor. In pretty good condition
for a 30 year old printer.
This is an RO (no keyboard) model in charcoal color skins. Serial
interface 110-300 baud w no handshake; 1200 using ETX/ACK.
Free for shipping from Eugene, OR.
Cheers,
Chuck
Thank you.
--
Paul Braun
Valparaiso, IN
"There's a fine line between stupid, and clever." - David St. Hubbins
"Enjoy every sandwich." - Warren Zevon
"The Fountain of Youth is a state of mind." - The Ides of March
I've been offered a couple "late model" CompuPro Systems - a 10+ and an
MP310 - but I don't know anything about these "new" systems; all my
experience was with the pure S100 stuff, from early Econoram through the
816 systems. Can anyone provide details on anything in the 10 series?
Were these still based on S100 cards (though with switching power
supplies?) or were they some sort of single-board attempt at survival?
Thanks -
Jack
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.22/922 - Release Date:
7/27/2007 6:08 AM
Hello.
I'm finally down to the end of my collection - all of the hardware has
gone to good homes (except my 128k Mac and my Amigas. Love my Amigas.)
I have 5-50lb boxes of Byte, going back to the '70's, as well as
Information Age and probably a few Dr. Dobbs' thrown in somewhere.
There are also a couple of boxes of miscellaneous books and documentation.
I don't want to just pitch this stuff, but I also really don't want to
go through the hassle of packing and shipping 300lbs of paper.
I live in NW Indiana, about 45 minutes East of Chicago.
First person to email me off-list (has to be off-list, since I unsubbed
a while ago) who can come down in a fairly short amount of time and pick
this stuff up gets it. I ask for nothing, except maybe to buy me lunch.
If I don't hear from anyone by the end of next week, it's going in the
trash. I hate to do that, but I need the space.
Thanks!
--
Paul Braun
Valparaiso, IN
"There's a fine line between stupid, and clever." - David St. Hubbins
"Enjoy every sandwich." - Warren Zevon
"The Fountain of Youth is a state of mind." - The Ides of March
A little background on the subject...
I'm working with a number of old 100 TPI 5.25" HS diskettes and a
catweasel to read them. The data encoding is plain MFM and thus far,
the whole project involving some 27-year old media is going pretty
well, considering the age and condition of the media.
Occasionally, I'll pick up a data error (no big surprise). According
to what I've been able to determine from the CW output, most of the
errors involve extraneous noise in the read output. In other words,
if the normal pulse timings for MFM are 0.5 1.0 and 1.5 cell-time
units, a pulse will sometimes be seen that occurs less than 0.25 time
unit from the previous one.
The CW output is essentially a bunch of 7 bit numbers that express
the number of clocks seen since the last pulse was read.
My original thought was to ignore each noise pulse by adding its
clock-count value to that of the next pulse that comes along. In
other words, if I get a stream of pulses with clock counts of, say,
10 20 30 20 5 15 10..., I'd skip the 5 pulse and convert the 15 to a
20.
This doesn't work well. While it's better than acually counting the
extraneous pulse as a data pulse, much better results are obtained if
the pulse is simply ignored and the next pulse clock-count is used as-
is without "correction".
Does anyone know why this would be? I can't rationalize it.
Cheers,
Chuck