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 support).
At a 15Mhz clock rate, 30 bytes is 1.3333us. Not a lot of time. And
frankly, that's defined by the controller and not the drive (though
usually the drives specify some layout but that's only a
recommendation). Dealing with drive speed variations doesn't solve
anything because it's actually done via the drive itself (e.g. the drive
provides the clock to the controller so any variation is already
accounted for). The drive really cares about total bits (e.g.
bits-per-inch) that the media supports.
If we assume 32KB track at 500MB/s DMA transfer rate, that takes 65us.
But as I've said, the spec says that the time between a head select and
read is 15us or so, you can see that you can't just transfer a track and
still meet the minimum timings. I will agree that you can probably take
longer but I'm trying to have a design that can meet all of the minimum
timings so I can emulate any drive/controller combination with at least
the same performance as a real drive (and in many cases I can provide
*much* higher performance).
By keeping a full cylinder in the FPGA Block RAM I can keep the head
select time < 1us (it's basically just selecting the high order address
bits going to the block RAM).
By keeping the entire disk image in DRAM, I can emulate any drive (that
fits in the DRAM) with identical (or faster) performance. If I wanted to
do something simpler (not much though) I could have a smaller DRAM (but
since the Zynq modules I'm using have 1GB or 4GB of DRAM there isn't
much motivation) but then any seek would be limited by access to the
backing store. Also remember, in the worst case you have to write the
previous track out if it was written to so that will slow things down as
well. With the full image maintained in DRAM, any writes can be
performed in a lazy manner in the background so that won't impact the
performance of the emulated drive.
TTFN - Guy
On 4/16/22 14:32, Tom Gardner wrote:
-----Original Message-----
From: Guy Sotomayor [mailto:g...@shiresoft.com]
Sent: Friday, April 15, 2022 3:25 PM
To: t.gard...@computer.org; cctech@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 command is 15us (so I was wrong) but still not a lot of time (that is after
a head set, a read command must be at least 15us later).
<snip>
-----
And after the read command is given there is a gap, usually all zeros, at the
end of which is a sync byte which is then followed by the first good data (or
header) byte. In SMD the gaps can be 20 or 30 bytes long so there is quite a
bit of time until good data.
Tom
--
TTFN - Guy
