5 Jul
2000
5 Jul
'00
3:36 a.m.
> My circuit is much more "hackable",
anyone with a TTL databook can figure
> out what it does and improve on it. Or you can build one yourself from
> scratch. (Other than the 128K*8 SRAM, all the other parts were literally
> purchased from the local electronics shop. Heck, most of the chips can
> be bought at Radio Shack!) Total cost for the chips in my buffer is
> about $30.00, about half of that in the SRAM chip.
I sympathize with that, but for those of us who are
much better at software
than hardware, something off-the-shelf is a big plus.
OTOH, something I can put together on a Sunday afternoon with parts I bought
at Radio Shack is an even bigger plus for me :-).
It's not like my buffer uses any complex electronics. It's all perfectly-
standard TTL parts and a SRAM chip, and it's currently residing on a pretty
randomly wired solderless breadboard so you don't need any fancy construction
techniques. Except for the capacity of the SRAM chip, this is all quarter-
century-old technology.
As Chuck pointed out, maybe the fact that this is quarter-century-old
technology put together with quarter-century-old construction and design
techniques makes it less accessible to some of the younger members
of this list. Maybe the way to make it more accessible to them is to put
the circuitry on a CPLD, I dunno, I think it's fine as it is.
I suppose there *are* folks who might be interested in using such a device
who don't know which end of a soldering iron to pick up, but a very valid
point is that I built this without even touching a soldering iron!
And the fact that I built it without even drawing a schematic first would
tend to implicate the design as being on the naively simplistic side, too :-).
(I still gotta draw that schematic up for you guys...)
Another point to note is that the Catweasel samples at
7 or 14 MHz (software
selectable). In reading some old 8" MFM disks, I found that there had
been a lot of bit-shifting over the years (or maybe there was not enough
write precomp applied to begin with)
I will admit, MFM *does* require at least twice the timing resolution of FM.
I once got in a small argument with some other members of this list about
AC circuit design of MFM vs FM data recovery circuits. IIRC, they were
insisting that MFM did come "for free" if you had the frequency response
necessary for FM at half the data rate. My point was that it
wasn't the max pulse frequency which made life difficult, it was the phase
response (finding where the pulse occured in the window) that was the tough
point.
, and I had to use an extra heuristic
to make them readable at all. I'm not sure that 4 MHz would have been
a high enough sample rate for these.
Yeah, well, with my circuit if you don't like the sample rate, you buy
a different off-the-shelf oscillator in a can and plug in. If you
now need more buffer RAM, you plug in a second RAM chip and wire it up.
That's IMHO the beauty, but maybe a software-only hacker doesn't see that.
Tim.
5 Jul
5 Jul
3:59 a.m.
As Chuck pointed out, maybe the fact that this is
quarter-century-old
technology put together with quarter-century-old construction and design
techniques makes it less accessible to some of the younger members
of this list. Maybe the way to make it more accessible to them is to put
the circuitry on a CPLD, I dunno, I think it's fine as it is.
It's compatable with my 500ft deep junkbox. Likely if I built it the
parts would be 25 years old too. ;)
tend to implicate the design as being on the naively
simplistic side, too :-).
Oh, it doesn't bust, rust or collect dust then.
I will admit, MFM *does* require at least twice the
timing resolution of FM.
I once got in a small argument with some other members of this list about
AC circuit design of MFM vs FM data recovery circuits. IIRC, they were
insisting that MFM did come "for free" if you had the frequency response
necessary for FM at half the data rate. My point was that it
wasn't the max pulse frequency which made life difficult, it was the phase
response (finding where the pulse occured in the window) that was the tough
point.
Also since precomp ranges from .0625uS to as long as .375uS the ability
to slice a bit finer is a desireable thing.
Allison
6:39 a.m.
True, but if he's only reading, the present frequency is plenty. The
assumption is that the write precomp on the already-written media is
sufficient. If it's not the data might never have been readable.
Dick
----- Original Message -----
From: <allisonp(a)world.std.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 6:59 AM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
<snip>
> I will admit, MFM *does* require at least twice
the timing resolution of
FM.
> I once got in a small argument with some other
members of this list
about
> AC circuit design of MFM vs FM data recovery
circuits. IIRC, they were
> insisting that MFM did come "for free" if you had the frequency response
> necessary for FM at half the data rate. My point was that it
> wasn't the max pulse frequency which made life difficult, it was the
phase
> response (finding where the pulse occured in the
window) that was the
tough
point.
Also since precomp ranges from .0625uS to as long as .375uS the ability
to slice a bit finer is a desireable thing.
Allison
6:53 a.m.
Just a thought about the CPLD vs. TTL discussion: Would it
be possible to design the device such that it could be
built EITHER in TTL chips OR as a CPLD? With the same
interface to the host computer and software? If it could,
then those who prefer CPLDs could use one, and those who'd
rather rummage about in the "500ft" junk box can do that.
Or am I missing an fundamental difference here?
--
John Honniball
Email: John.Honniball(a)uwe.ac.uk
University of the West of England
7:40 a.m.
You've raised a valid point, but it hinges on the amount of effort involved,
not on the details of the hardware. If you use a 44-pin CPLD programmable
in-circuit by means of a parallel cable, you have to hook up the CPLD, which
means 44 wires, and you have to hook up the RAM, but that's part of the 44
wires, AND you have to hook up the host interface, but that's part of the 44
wires, and you have to hook up a few of the lines to the FDD, but that's
part of the 44 wires. So, aside from power and ground, you have about a
dozen wires to the parallel port, a half dozen to the FDD, and two dozen to
the RAM, of which,say 8 are shared with the host adapter port. Those are
two levels, so that's an additional 8 wires. (now, I'm just guessing here)
Given that you have the same logic in TTL SSI and MSI parts, e.g. counters,
latches, gates, I'd say you'll have the same connections to the
"outside"
and at least twice as many for the inside. What's more, the required power
will be considerably greater. If you provide sufficient capacitors on the
board, the CMOS CPLD can probably run from the power it draws from the two
outside sources, in fact probably from the pullup resistors on the FDD
cable. The TTL won't do that. If you go with HCMOS that might work with
the same source of power, but now you won't be able to dig them out of the
old parts bin.
If the CPLD is designed using the FREE software on the XILINX website, the
schematic will be drawn in primitives, since the CPLD libraries don't
contain the same features as the FPGA libraries. That will limit the
ability to use the same schematic. With a little effort, the same logic
could be implemented in both technologies, however. The SSI/MSI board will
be considerably larger, though. A board for the CPLD version would be
barely large enough to support the connectors.
I guess you'll have to weigh the alternatives yourself.
Dick
----- Original Message -----
From: John Honniball <John.Honniball(a)uwe.ac.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 9:53 AM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
Just a thought about the CPLD vs. TTL discussion: Would it
be possible to design the device such that it could be
built EITHER in TTL chips OR as a CPLD? With the same
interface to the host computer and software? If it could,
then those who prefer CPLDs could use one, and those who'd
rather rummage about in the "500ft" junk box can do that.
Or am I missing an fundamental difference here?
--
John Honniball
Email: John.Honniball(a)uwe.ac.uk
University of the West of England
1:04 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1100 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000705/5c0fc8fe/at…
2:03 p.m.
plz see embedded comments below.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 4:04 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
The fact is that you can, but it depends on a number of things including
your definition of properly and the frequency. This circuit is going to be
so slow it won't make a lot of difference for speed reasons. Moreover,
we're talking CPLD, *NOT* FPGA. Routing delays in a sizeable FPGA will have
huge effect on system performance, while those in a relatively small CPLD
like this one are negligible. A CPLD is like a large PAL, AOI-gate-like
architecture with programmable polarity, clock, and either registers or
latches, with various types of outputs. It's not at all like a Xilinx FPGA
of about the same size, e.g. XC3120, andit costs a lot less.
Just a thought about the CPLD vs. TTL discussion: Would it
be possible to design the device such that it could be
built EITHER in TTL chips OR as a CPLD? With the same
I've done a significant amount of design with FPGAs (not CLPDs, though,
so this might be different), and my experience suggests that no matter
what the manufacturers claim you _can't_ take a TTL-based circuit, feed
it into the schematic capture program, and expect the result to work
properly. There are many differences between designing with TTL
and with FPGAs. The
main one is that signals routed across the chip through the various
routing muxes are subject to considerable delays. Delays that can cause
race hazards and glitches where you least expect them. Since the FGPAs
generally have an excessive number of flip-flops anyway, the solution is
obvious -- make everything synchronous. Which is rather different to how
you design with TTL.
By comparison with FPGA's of various types these relatively small CPLD's
are
very easy and pleasant to use. My only complaint is that they never seem to
have the right numbe of pins. Either the package is too big or there aren't
enough pins. <sigh>
CPLDs are a rather different architecture, and probably don't suffer from
this, but it's something to be aware of. Just in case it catches you...
-tony
2:18 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2174 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000706/579e94da/at…
3:01 p.m.
Modern design strategy, (developed as a result of much experience like
yours) demands that all the circuitry in an FPGA be synchronous, i.e. driven
by the same (not derived or gated) clock. Having been raised on individual
components, I find this restrictive, but that's because of my age, not my
wisdom. In reality, once an FPGA is on the table you have to use techniques
that will be likely to yield the lowest-risk result. You can't poke around
with a 'scope, so you have to rely on a simulator. It's a pain!
A lot depends on the flop-flop types you use in an FPGA, Tony, and there are
more types availablel today than there were ten years back. These CPLD's
have quite a variety as well, but the task is one that requires only one
clock for the "main" task, i.e. SIPO/PISO from/to the RAM. Synchronization
with the parallel port is driven from the PC, so its interface has to be
dual-rank registered, but I doubt there's need for gating the clock. That
is, as you say, an iffy practice justified only by a pipeline register to
resync the output of that circuit segment.
I've concluded that a 44-pin CPLD, though it might hold sufficient resources
to effect some FDC functions, won't have enough ins and outs to accomodate a
large SRAM. We're looking at 30 pins here just for the SRAM and half that
number +1 would be needed with a DRAM. That might still not be enough . . .
I've made a couple more remarks below, if you're interested.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk
To: <classiccmp(a)classiccmp.org
Sent: Wednesday, July 05, 2000 5:18 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
<snip The reason this
will likely work is because the whole process is
synchronous. It lends itself to glitch-free operation in a CPLD, because
the CPLD is basically a large PAL. Think of the XC9572 as half-a dozen
26CV12's with both pin and register feedback and product-term sharing.
What might make this thing workable for
everybody would be developing a
schematic with fairly straighforward and well defined constructs, as one
might find in a databook, and a conversion, component by component to the
CPLD. Unfortunately , the XILINX software only supports the small CPLD's
with a library of primitives and no MSI's.
The frequency (IMHO) is irrelevent. I've seen
FPGA-based designs where
the maximum clock frequency on the board was 32kHz. The reason is that a
narrow glitch, a small faction of the clock, will still trigger a
flip-flop in the FPGA if it appears on the clock input [1]. It may well
flip the write-data flip-flop in a floppy drive. Or provide just enough
of a write pulse to the SRAM to cause you problems later.
[1] Yes, it is a bad idea to gate clock signals to FPGA flip-flops for
_exactly_ that reason. Clock enable inputs are provided for a reason :-).
Flipflops with enables solve that problem to large extent.
> so slow it won't make a lot of difference for speed reasons. Moreover,
> we're talking CPLD, *NOT* FPGA. Routing delays in a sizeable FPGA will
have
> huge effect on system performance, while those in
a relatively small
CPLD
like this one
are negligible. A CPLD is like a large PAL, AOI-gate-like
3:09 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2801 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000706/fc8676ba/at…
3:36 p.m.
There are a couple of things not so obvious to the casual looker-on. First,
the FPGA uses a RAM lookup table to generate all its logic functions, hence,
the 5-input limit on XC3000-series logic cells, (32-bit LUT). This means
that a NAND output propagates just as fast (or slowly) as an XOR, since the
prop-delay of the LUT is what it is regardless.
I have to take exception to your suggestion of making a modified version of
your FPGA to generate test points. There are lots of flops in an LCA and
limited routing resources. WHERE in the array your test point is driven to
an I/O cell is going to have major impact on the timing. Moreover, because
the routing resource allocation is critical, which flop you use will have
effects on speed and propagation of your signals. I know that's a fine
difference, but at any speed over half the rated speed of the device, it's
likely to affect your outcomes. Consequently, you can't rely on the timing
of a specially routed signal if it's not going to be part of the final
result. Another problem is that recompiling often leads to timing AND
pinout changes. Few devices allow pin locking and of those it's really only
effective if you are satisfied with 50% or lower utilization. I've seen
boards fresh from the PCB house, no parts on them yet, which had to have a
dozen or more wires placed on them in spite of the fact that all the parts
on the board were programmable logic.
That's why I made the remark I made about simulation, which has LONG been
near and dear to my heart. I tolerate its weaknesses where they occur for
the benefit and confidence the give me. I've seldom been disappointed.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk
To: <classiccmp(a)classiccmp.org
Sent: Wednesday, July 05, 2000 6:09 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
That's likely to change circuit timing and pinout.
But, of course, this 'recompile' means
that the circuit is rerouted. If
> your design in marginal anyway then the glitches will move around.
If they just move around, you may not see them.
If your circuit is
pipelined and synchronous, it will have few hazards or none at all.
> Please don't think I'm totally
against FPGAs. I'm against the misuse of
> FPGAs, including using them when half a dozen TTL chips would be better
> (for a suitable definition of better). I'm also against just shoving an
> existing circuit into them and hoping it works, because most of the time
> it wont...
<snip
> I've seen inexperienced Xilinx
designers use AND gates to gate the clock
> to most of the flip-flops in their circuit and then wonder why they get
> false clocking...
Inexperienced designers with TTL did the same
thing until they were wised
up.
> -tony
> Modern design strategy, (developed as a result of
much experience like
<snip will be likely
to yield the lowest-risk result. You can't poke around
with a 'scope, so you have to rely on a simulator. It's a pain!
Actually, you can probe with a 'scope if you have enough routing
resources and pins left over (it's worth building the prototype with 'too
big an FPGA' for this reason). You simply route internal signals to pins,
recompile, and test.
3:56 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 4924 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000706/af223014/at…
7:48 p.m.
How, true! It's a good thing we're looking at a CPLD rather than an FPGA.
The CPLD is not without its problems, but the architecture, particularly for
small ones, is straighforward enough that one can look at it simply as a
number of interconnected PALs.
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk
To: <classiccmp(a)classiccmp.org
Sent: Wednesday, July 05, 2000 6:56 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
<snip
> > That's why I made the remark I
made about simulation, which has LONG
been
> Last time I used an FPGA simulator (a
couple of years back, and it was
> one provided by Xilinx), it was so broken as to be unusable. It showed
> glitches where there were none (like on the output of D-types far from
> any clock edge), it failed to show then when they most certainly did
> occur, it failed to get a couple of simple test circuits 'right' (it said
> signals were undefined when they certainly were not!), it couldn't handle
> external memory devices or logic in any reasonable way, etc.
Ah, yes . . . good old SILOS . . . it's one
of many and there are good ones
and not-so-good ones. The one from MENTOR was OK but the one purchased from
XILINX (SILOS) was useless. However, I bought the MAXPLUS+ software from
ALTERA the same year that I learned how crappy the XILINX software was, and
its simulator had problems that couldn't be worked around, too. I had a mux
that simulated a 70 ns prop-delay with a one and 15 with a zero. The spec
showed no difference and the FAE couldn't explain the problem either. That
was not such a good investment either.
> I can assure you that bringing out signals
_carefully_, noting how the
> timing differed from internal signals when it mattered, was a _lot_
> easier and more reliable. It actually meant that physical circuits
> started working and working reliably!
That requires more effort, (painstaking manual
layout and floorplanning)
than I've ever wanted to use up on an FPGA. Nowadays, when there are over a
million gates in one of these babies, you either have to trust your
simulator or go nuts trying to figure out how to do otherwise.
<snip
> -tony
>
<snip
There are 2 issues here.
Firstly, the fact that you may not have enough routing resources to feed
out the signal. This is trivially cured by using a larger FPGA for the
prototype...
The second problem which I agree with is that re-routing the device
changes the timing. However, if you're not running the device close to
the maximum speed _and_ you've got an almost fully synchronous design,
then this shouldn't matter. If it's that critical, then you probably
should be routing the device by hand anyway (this is slow and painful,
but you can get the last few ns out of a chip that way...)
If your circuit is _that_ critical as to timing, then any change in the
logic is going to cause a re-route, which is going to change timings all
over the circuit. Unless you really know what you are doing, and know how
to handle this (which will involve hand-routing, most likely), IMHO you
should re-think the design. I've seen designs where a 'section', compiled
and stuck in an FPGA worked, but when something totally unrelated was
added, the first part fell over due to timing changes. Since the speed of
the circuit was nowhere near the maximum speed the FPGA was capable of,
that was a bad design IMHO.
The main thing to keep in mind is that what's under study is a CPLD. They
are not at all like FPGA's in many respects, including, by the way, the ones
you seem to remember so well, for obvious reasons. The delay in a CPLD is
always determinstic and predictable, and the timing spec's are simple and
easy to understand. The I/O is straightforward and so is the "routing"
though there's little of that to bother with in a small part like the
XC9572. I have severe doubts about the pin count, though, and can't
understand why the same die in a different package costs so much more. (the
PLCC84 is just under $30 while the PLCC44 is at $5.50) Fortunately, there's
a good chance another device, perhaps from another vendor, and in a 68-pin
package, maybe one from ALTERA or CYPRESS might fill the bill without
breaking the bank. Their software is free as well and they support a wider
range of CPLD's. Of course they're not readily available form DigiKey . . .
> near and dear to my heart. I tolerate its
weaknesses where they occur
for
> > the benefit and confidence the give me. I've seldom been disappointed.
11:53 p.m.
New subject: Sat SoCal Garage Sale, RoadTrip to NoCal
Saturday July 8th from 7am til 4 pm is the once a year garage sale in my
condo association, and my garage door will be open with LOTS of neat
computer stuff priced to move. Apollo workstations with HP 1097C color
monitors, IBM model 95 servers, Quadra 950 macs, keyboards, mice,
networking, old laptops, various commodore and atari items, Apple II stuff,
firewall systems, Russel Hobbs electric tea kettles, pretty rocks, boxes of
books, cables of many tupes.
Location
Old Chapman Townhomes is about 3 miles east of the 22/55 freeway junction.
East on Chapman to Canyon View, right about 100 feet, then turn left into
the townhome complex on Brynhurst, left again in 30 feet, then right on
Cadbury and I will be at the Culdesac at the end of Cadbury.
RoadTrip
Next week, about July 11th, I will be packing up the car and heading up to
San Jose and Sillycon valley for the rest of the week. If I have something
you want, and you can meet up with me "reliably" on Wednesday or Thursday,
I may be able to bring it up with me. Ditto if you have something I want,
or suggestions on places to poke in interesting boxes.
6 Jul
6 Jul
9:03 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 4615 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000706/a637e718/at…
12:02 p.m.
Well, I'm not sure I buy the economic justification for the higher cost of
the PLCC-84 vs the PLCC-44. I'll allow, however, that your supposition
applies. However, in the case of the PGA vs PLCC is just the raw cost of
the package. If you follow the history of prices in the various packages
through the market cycle, the price offset for the PGA vs PLCC stays pretty
constant though the base price of the device moves up and down. The TQFP
and PQFP packages tend to be the cheapest but they're a pain to prototype.
Xilinx wants over $1k in onesies for their PGA packages these days. I doubt
they sell many.
I remember when the Intel folks were first selling their 80186 in PLCC.
They also had it in PGA and CLCC. At the time the PLCC went under $10, the
PGA was still over $40. Likewise, the '286 was at $6 for the PLCC when the
PGA was still over $35. I always liked the PGA for prototypes, but quickly
built a board with a PLCC socket on it so I could use the PLCC in a PGA
environment.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Thursday, July 06, 2000 12:03 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
>
> How, true! It's a good thing we're looking at a CPLD rather than an
FPGA.
Yes, this part of the discussion has moved away from talking about
designing a disk controller and become a more general discussion of FPGAs.
<big snip>
> understand why the same die in a different
package costs so much more.
(the
> PLCC84 is just under $30 while the PLCC44 is at
$5.50) Fortunately,
there's
Popularity, and the cost of making the package AFAIK. The silicon die is
cheap. PGA packages, in particular, are expensive (in one case with one
of the chips I was using, the 132 pin PGA was more expensive than a
package with a higher pin count that was less suitable for prototyping
(PQFP, maybe). A lot more expensive.
> > I can assure you that bringing out signals _carefully_, noting how the
> > timing differed from internal signals when it mattered, was a _lot_
> > easier and more reliable. It actually meant that physical circuits
> > started working and working reliably!
> >
> That requires more effort, (painstaking manual layout and floorplanning)
> than I've ever wanted to use up on an FPGA. Nowadays, when there are
over
a
million gates
in one of these babies, you either have to trust your
simulator or go nuts trying to figure out how to do otherwise.
I have come to realise that software has bugs. Often serious bugs. And
the fact that a simulator says something is no reason to necessarily
believe that the real circuit will do the same. I 'went nuts' trying to
get the simulator to do something even remotely sensible (it managed to
put a 20 ns glitch on the output of _one_ output of a synchronous counter
for no apparent reason!). Designing so that rerouting wouldn't cause
problems, then bringing out test signals most certainly 'worked for me'.
-tony
5:19 a.m.
I have to take exception to your suggestion of making
a modified version of
your FPGA to generate test points. There are lots of flops in an LCA and
limited routing resources.
I agree here. My practice has been to route the design without the test
points and then use the low level editor to add what test points I could
without changing the layout/routing. Of course then you can't count
on the signal you wanted to test on being there and being routable to a
IOB. It's definitely a different world than 74 series logic.
Eric
7:43 a.m.
On Thu, 6 Jul 2000 00:18:20 +0100 (BST) Tony Duell
<ard(a)p850ug1.demon.co.uk> wrote:
One final point that perhaps Tim could answer. If he
does provide a
schematic, would he have any objections if somebody else created a CPLD
(or FPGA, or..) version? Giving him full credit for the original idea, of
course. Because if he doesn't mind, then the whole issue goes away. You
can build whichever version suits you...
That sounds like a good plan to me! Build in whatever
technology is appropriate at the time -- who knows how
we'll build one of these things in five or ten years from
now?
-tony
--
John Honniball
Email: John.Honniball(a)uwe.ac.uk
University of the West of England
7:39 a.m.
On Wed, 5 Jul 2000 23:04:23 +0100 (BST) Tony Duell
<ard(a)p850ug1.demon.co.uk> wrote:
I wouldn't expect the two designs to be identical at that
level, just to appear to function the same to the external
world. That way, we'd be able to write the same software
to work with either hardware implementation.
Just a thought
about the CPLD vs. TTL discussion: Would it
be possible to design the device such that it could be
built EITHER in TTL chips OR as a CPLD? With the same
I've done a significant amount of design with FPGAs (not CLPDs, though,
so this might be different), and my experience suggests that no matter
what the manufacturers claim you _can't_ take a TTL-based circuit, feed
it into the schematic capture program, and expect the result to work
properly. -tony
--
John Honniball
Email: John.Honniball(a)uwe.ac.uk
University of the West of England
9:14 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 653 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000706/fe5a097f/at…
5 Jul
5 Jul
6:36 a.m.
Quite so, but please see my embedded comments below.
Dick
----- Original Message -----
From: <CLASSICCMP(a)trailing-edge.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 6:36 AM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
software
The choice appears to be between
something that may work and something that
will, though I believe the sample rate ought to be increased.
FM.
If you want to use a single oscillator
and still write with typical precomp,
you'll have to use 24 MHz and divide it down into 6 and 8 MHz.
>> My circuit is much more "hackable",
anyone with a TTL databook can
figure
>> out what it does and improve on it. Or you
can build one yourself from
>> scratch. (Other than the 128K*8 SRAM, all the other parts were
literally
> purchased
from the local electronics shop. Heck, most of the chips can
> be bought at Radio Shack!) Total cost for the chips in my buffer is
> about $30.00, about half of that in the SRAM chip.
>I sympathize with that, but for those of us who are much better at than hardware,
something off-the-shelf is a big plus.
OTOH, something I can put together on a Sunday afternoon with parts I
bought
at Radio Shack is an even bigger plus for me :-).
Buying parts at Radio Shack is risky. I once bought a significant number of
parts from them only to find that not one of them was in spec. I've not
bought any components from them since, and that was in '77. They do have
some interesting tools, but they immediately discontinue them if they're any
good.
It's not like my buffer uses any complex electronics. It's all perfectly-
standard TTL parts and a SRAM chip, and it's currently residing on a
pretty
randomly wired solderless breadboard so you don't
need any fancy
construction
techniques. Except for the capacity of the SRAM chip,
this is all
quarter-
century-old technology.
As Chuck pointed out, maybe the fact that this is quarter-century-old
technology put together with quarter-century-old construction and design
techniques makes it less accessible to some of the younger members
of this list. Maybe the way to make it more accessible to them is to put
the circuitry on a CPLD, I dunno, I think it's fine as it is.
I believe that the CPLD makes it accessible to those who otherwise might be
disinclined to build any hardware. The advantage is that the file
associated with the definition of the hardware is part of the package. The
programming cable is, likewise. The CPLD makes using components known to be
working and already in the user's possession, on an old motherboard or video
card, say, workable.
I suppose there *are* folks who might be interested in using such a device
who don't know which end of a soldering iron to pick up, but a very valid
point is that I built this without even touching a soldering iron!
And the fact that I built it without even drawing a schematic first would
tend to implicate the design as being on the naively simplistic side, too
:-).
(I still gotta draw that schematic up for you
guys...)
>Another point to note is that the Catweasel samples at 7 or 14 MHz
(software
selectable).
In reading some old 8" MFM disks, I found that there had
been a lot of bit-shifting over the years (or maybe there was not enough
write precomp applied to begin with)
I will admit, MFM *does* require at least twice the timing resolution of I once got in a small argument with some other members
of this list about
AC circuit design of MFM vs FM data recovery circuits. IIRC, they were
insisting that MFM did come "for free" if you had the frequency response
necessary for FM at half the data rate. My point was that it
wasn't the max pulse frequency which made life difficult, it was the phase
response (finding where the pulse occured in the window) that was the
tough
point.
I think you'll need to go faster than that, else missing an edge will create
more phase shift than you can trivially resolve.
, and I had to use an extra heuristic
to make them readable at all. I'm not sure that 4 MHz would have been
a high enough sample rate for these.
Yeah, well, with my circuit if you don't like the sample rate, you buy
a different off-the-shelf oscillator in a can and plug in. If you
now need more buffer RAM, you plug in a second RAM chip and wire it up.
That's IMHO the beauty, but maybe a software-only hacker doesn't see that.
Agreed, though the software will have to be adjusted accordingly. There
will have to be a fair amount of work to deal with the write side of the
problem. (Is that a right-brain activity?)
Tim.
7:26 a.m.
As Chuck pointed out, maybe the fact that this is
quarter-century-old
technology put together with quarter-century-old construction and design
techniques makes it less accessible to some of the younger members
of this list. Maybe the way to make it more accessible to them is to put
the circuitry on a CPLD, I dunno, I think it's fine as it is.
I don't think that's the reason to put it in a CPLD. The reason to put
it into a CPLD is to make the circuitry modifiable on the fly. Right now
the design puts all of the complexity on the software side. The CPLD
gives the possibility of moving some of that into the hardware side.
It also gives the possibility of using different methods to read different
formats, while retaining the possibility of reading it raw. There also happen
to be some of us that prefer reading schematics to reading code. :)
Eric
7:44 a.m.
What the CPLD allows is incorporation of rudimentary FDC functions into the
CPLD so the device doesn't have to be connected in parallel with an external
drive cable. That simplifies packaging and construction, and ensures that
the sampler board won't disturb the system's floppy subsystem. The circuit
wouldn't be modifiable on the fly, however, unless you consider the multiple
minutes of reprogramming time and the associated physical effort "on the
fly."
So far, I've seen no reason to make this baby reconfigurable. What do you
have in mind?
Dick
----- Original Message -----
From: Eric J. Korpela <korpela(a)ellie.ssl.berkeley.edu>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 10:26 AM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
happen
> As Chuck pointed out, maybe the fact that this is
quarter-century-old
> technology put together with quarter-century-old construction and design
> techniques makes it less accessible to some of the younger members
> of this list. Maybe the way to make it more accessible to them is to
put
the circuitry
on a CPLD, I dunno, I think it's fine as it is.
I don't think that's the reason to put it in a CPLD. The reason to put
it into a CPLD is to make the circuitry modifiable on the fly. Right now
the design puts all of the complexity on the software side. The CPLD
gives the possibility of moving some of that into the hardware side.
It also gives the possibility of using different methods to read different
formats, while retaining the possibility of reading it raw. There also to be some of us that prefer reading schematics to
reading code. :)
Eric
8:50 a.m.
The circuit
wouldn't be modifiable on the fly, however, unless you consider the multiple
minutes of reprogramming time and the associated physical effort "on the
fly."
I do consider that to be on the fly.
So far, I've seen no reason to make this baby
reconfigurable. What do you
have in mind?
FM, MFM, or GCR decom in the CPLD.
Eric
1:41 p.m.
It will require no modification at all to handle those formats. It samples
the data at a harmonic of the data rate and writes it back at a harmonic
suitable for adjustment for write precompensation. Dealing with the
different modulations, as you've named, is a software post-processing task.
Likewise, if a little extra effort is put into the design, it can record,
quantitatively the location of the index/sector pulses in order to enable
reading and writing of hard-sectored diskettes. There are too many
mechanical variations to allow simple timing of the theoretical locations of
these events.
The notion of reprogramming the thing is perhaps a pregnant one, but I have
reservations about the suitability of this particular device, for want of
pins. A single or pair of 256Kx4 DRAMs might be manageable, but SRAMS would
require 30 connections and the EPP/SPP interface would require 13. Then
there are a few connections to the drive cable required. As you can see,
we're past being out of pins already. A 68-pin device would be more likely
to work. Perhaps a video DRAM would work with fewer connections.
Dick
----- Original Message -----
From: Eric J. Korpela <korpela(a)ellie.ssl.berkeley.edu>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 11:50 AM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
you
>
The
circuit
> wouldn't be modifiable on the fly, however,
unless you consider the
multiple
minutes of
reprogramming time and the associated physical effort "on the
fly."
I do consider that to be on the fly.
> So far, I've seen no reason to make this baby reconfigurable. What do
have in mind?
FM, MFM, or GCR decom in the CPLD.
Eric
3:02 p.m.
Dealing with the
different modulations, as you've named, is a software post-processing task.
You prefer software solutions. I prefer hardware. It doesn't make either
of us wrong. When you close your eyes, you see pseudocode. I see schematics.
The notion of reprogramming the thing is perhaps a
pregnant one, but I have
reservations about the suitability of this particular device, for want of
pins.
Yes, I would probably choose a larger CPLD than the one previously mentioned.
Eric
3:17 p.m.
I'm afraid you missed my point. This device we've been discussing has
absolutely no facility for dealing with the different modulation schemes,
e.g. MFM, RLL, GCR ... That would be a mite more complex than we want or
need, methinks.
As for me, I seldom see pseudocode, having been a hardware type for
twenty-odd years. Before that I was a high-level programmer, when those
guys used threetran, er,I mean FORTRAN, but they made us use FTN-II when
FTN-IV was available, and COBOL, APL, etc. We didn't have these new-fangled
languages like ALGOL or PASCAL ...
If you want to build a controller using hardware to deal with the various
modulation schemes, remember that they use lots of different timing
elements, and that makes CPLD design harder. I've never seen a controller
that did multiple modulations aside from FM/MFM. It might be interesting to
see . . .
Moreover, that's quite some distance off-target for this topic, since it's
intended to sample and software/massage the data so all sorts and sources of
data can be dealt with equivalently.
Dick
----- Original Message -----
From: Eric J. Korpela <korpela(a)ellie.ssl.berkeley.edu>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 6:02 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
mentioned.
>
Dealing with the
> different modulations, as you've named, is a software post-processing
task.
You prefer software solutions. I prefer hardware. It doesn't make either
of us wrong. When you close your eyes, you see pseudocode. I see
schematics.
> The notion of reprogramming the thing is perhaps a pregnant one, but I
have
> reservations about the suitability of this
particular device, for want
of
pins.
Yes, I would probably choose a larger CPLD than the one previously
Eric
7 Jul
7 Jul
2:42 p.m.
So far,
I've seen no reason to make this baby reconfigurable. What do you
have in mind?
FM, MFM, or GCR decom in the CPLD. 
5 Jul
5 Jul
9:01 a.m.
As Chuck pointed out, maybe the fact that this is
quarter-century-old
technology put together with quarter-century-old construction and design
techniques makes it less accessible to some of the younger members
of this list. Maybe the way to make it more accessible to them is to put
the circuitry on a CPLD, I dunno, I think it's fine as it is.
I'm afraid I don't follow this arguement. I'm far from competent as far as
electronics go. However, this sounds like something I could build with the
most difficult part being digging up the parts (I don't have much faith in
my local Radio Shack).
Of course I'm also not one of the younger members, and I have worked as an
electrician in a past life...
I suppose there *are* folks who might be interested in
using such a device
who don't know which end of a soldering iron to pick up, but a very valid
point is that I built this without even touching a soldering iron!
Well, considering I know a guy at work that is totally software, and just
plain scares me when he starts messing with hardware, that is talking about
building a couple projects for his Linux box I don't think that not knowing
which end of a soldering iron is a valid point. Besides as you say, you
didn't touch one to build this.
Zane
| Zane H. Healy | UNIX Systems Adminstrator |
| healyzh(a)aracnet.com (primary) | Linux Enthusiast |
| healyzh(a)holonet.net (alternate) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
9:48 a.m.
Actually my point on using the PLD was that it would simplify
layout/building/retrofitting. I've checked and the CPLDs do not support
"true" open collector outputs so you are stuck with the 74HCT drivers in
any case.
--Chuck
1:55 p.m.
I agree that the device in question doesn't offer OC/OD outputs, a tristate
driver would work as well, and the CPLD drives a bit MORE (8 mA) than the
typical HC/HCT device (6 mA). I think the CPLD would provide an easy-to
build alternative that would require some assembly, but which could be
modified without wiring or soldering/.
If you look at FDC's used in many systems, including some of the ones used
in PC-clones, didn't bother with OC drivers. It's not critical unless you
have more than one controller on the cable. That happens rather seldom.
HCT's by the way, don't have open collectors. In fact, they don't have
collectors at all. It doesn't matter, though. If you drive a line with a
tristate buffer with the appropriate polarity at its input, it will behave
pretty much as an OC device does, only better and faster. If you don't
believe that, try plugging a 74126 with an input grounded into a circuit
prevously occupied by a 7403. of course it must be wired such that the
logic functions the same, but it's a valid comparison. The more common 7438
is not valid for comparison because they didn't get around to building a
tristate buffer in the '126 pinout. When you hit the enable with a high,
the output will go low, lickety-split, just like the OC. You'll need a
pullup in either case.
Dick
----- Original Message -----
From: Chuck McManis <cmcmanis(a)mcmanis.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 12:48 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
Actually my point on using the PLD was that it would
simplify
layout/building/retrofitting. I've checked and the CPLDs do not support
"true" open collector outputs so you are stuck with the 74HCT drivers in
any case.
--Chuck
12:52 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 3160 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000705/c080b207/at…
2:07 p.m.
Plz see comment below.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 3:52 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
<snip>
>
I learnt about 10 years ago that it's quicker to
solder up the circuit
(using verowire or something), or wire-wrap it, than to solve all the
stray capacitance problems that those darn breadboards introduce.
I'm not saying that you can't build circuits on said breadboards, but you
need to take care. and it's better if you don't really know what you are
doing to solder the circuit up. You'll have less problems!.
That's so true! I was surprised to read in the spec's for my first ones
(and last, by the way) that the capacitance between adjacent contacts is 5
pf, I don't remember much else about them.
> techniques. Except for the capacity of the SRAM chip, this is all
quarter-
> century-old technology.
>
<snip
2:20 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 855 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000706/36c843e7/at…
8762
days inactive
8764
days old
33 comments
10 participants
participants (10)
-
allisonp＠world.std.com -
ard＠p850ug1.demon.co.uk -
CLASSICCMP＠trailing-edge.com -
cmcmanis＠mcmanis.com -
eric＠brouhaha.com -
healyzh＠aracnet.com -
John.Honniball＠uwe.ac.uk -
korpela＠ellie.ssl.berkeley.edu -
mikeford＠socal.rr.com -
richard＠idcomm.com