idea for a universal disk interface

[Guy Sotomayor]

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:ggs at shiresoft.com]
> Sent: Friday, April 15, 2022 3:25 PM
> To: t.gardner at computer.org; cctech at 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