I have proceeded as far as full block diagrams (still have to write all
of the verilog) and basic SW architecture. This is why I've had this
discussion. I've thought about this *a lot* and have gone through
several iterations of what will or will not work given timing constraints.
I have
I chose ESDI and SMD fundamentally because the interface is 100% digital
(e.g. the data/clock separator is in the drive itself). So I don't need
to do any oversampling.
TTFN - Guy
On 4/17/22 11:12, Paul Koning via cctalk wrote:
On Apr 17, 2022, at 1:28 PM, shad via cctalk wrote:
> On Apr 17, 2022, at 1:28 PM, shad via cctalk
> wrote:
>
> hello,
> there's much discussion about the right method to transfer data in and out.
> Of course there are several methods, the right one must be carefully chosen
> after some review of all the disk interfaces that must be
hello,
there's much discussion about the right method to transfer data in and out.
Of course there are several methods, the right one must be carefully chosen
after some review of all the disk interfaces that must be supported. The idea
of having a copy of the whole disk in RAM is OK, assuming
I think the issue is that you're thinking of somehow emulating the
formatted data. I'm working on just emulating the bit-stream as then
it'll work with any controller and sector/track layout so I won't
actually know what a sector really is (unless I do "hard sectoring"
which some drives did
-Original Message-
From: Guy Sotomayor [mailto:g...@shiresoft.com]
Sent: Friday, April 15, 2022 3:25 PM
To: t.gard...@computer.org; cct...@classiccmp.org
Subject: Re: idea for a universal disk interface
I'm looking at what the spec says. ;-) The read command delay from the head
set