idea for a universal disk interface

[Guy Sotomayor]

It's not really fast enough and you'll get into all sorts of 
complications once you start to think about trying to keep up with 
simulation rotations.  For example, if someone starts a read at half way 
through a rotation (e.g. after the index pulse) now you have to have 
logic/code that can start/stop the transfer in random places.  The way 
that I have it designed, it's all sequential so no random start / 
lengths and it's all done during a seek which the data isn't being 
clocked out.

The Zynq-7020 (which is my low end design) has 4.9Mb of block RAM (in 
140 36Kb blocks).  In the cylinders I actually use 9-bits per byte as I 
need an escape in order to encode some other data.  ;-) With that it can 
hold the 512KB needed with some to spare.  My high end design will use 
the Zynq-Ultrascale+ (ZU3CG) has 7.6Mb of block RAM (in 216 36Kb 
blocks).  If I go to the next higher version (ZU4CG)the block RAM goes 
down to 4.5Kb (in 128 36Kb blocks) but gains 13.5Mb in "UltraRAM" which 
should allow for any reasonable cylinder buffering.

Of course, I'm just describing my design and design requirements.  First 
and foremost I wanted a simple HW & SW design that could provide 
accurate drive timings (e.g. I could faithfully reproduce the timings of 
any particular drive) so as to maximize the compatibility with any 
controller (and I have some weird ones).

I've been pouring over ANSI specs, controller specs and drive specs for 
SMD/ESDI for a few years now and have thought about a number of 
different ways to do this and what I've described is what I've come up with.

You may have different goals which may drive you to make different 
choices/decisions.

TTFN - Guy

On 4/19/22 11:49, shadoooo via cctalk wrote:
> Guy,
> I understand that cylinder command has no particular timing requirements, while head command must be effective within microseconds. My doubt is, RAM access on high performance port could be fast enough to satisfy also the latter.
> In case it couldn't or was not assured, I think the best strategy could be to preload only a small block of data for each head, for prompt start on head command; enough to manage safely RAM access latency.
> Each block also would work as buffer for data of subsequent RAM accesses, until whole cylinder had been processed.
> This strategy would remove the strict requirement of blockram capacity for the Zynq, and given that bigger models cost a lot, it would be a significant spare for anybody.
> Furthermore,  support for any hypotetical disk with bigger cylinder (not SMD) or for tape with very large blocks or "infinite" streams could not be feasible with the whole cylinder design. I would prefer to avoid any such limitation, in way to possibly reuse the same data transfer modules for any media.
>
> Andrea

-- 
TTFN - Guy