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).


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.


TTFN - Guy

Reply via email to