idea for a universal disk interface

[Tom Gardner]

I don't know it for certain, but I am pretty sure that it is true that virtually all controllers issue the commands in this sequence, Set Cylinder, Set Head and then Seek, or words to that effect.
They then wait for Ready which can be 10's of milliseconds later. So there is plenty of time to load the whole track much less just the first few bytes after index sufficient to start a data transfer

Likewise, I don't know it for certain, but I am pretty sure that it is true that virtually all controllers switch heads sequentially when transferring blocks beyond the end of the track, so again, if necessary, those first blocks of the next track could be preloaded, but I am pretty sure that this is unnecessary, since there is more than a sufficient amount of time from the set head command to access the first block of bytes of the next track, sequential or not, after which the sustained data rate from memory far exceeds the clock rate to the controller

BTW, at the end of any real track is always a Gap4 for speed variation and truncation residue so there is a fair bit of time there for housekeeping too.

In other words, IMHO, a buffer on the order of a few memory words is more than enough

Tom


-----Original Message-----
From: shadoooo [mailto:shadoooo at gmail.com] 
Sent: Tuesday, April 19, 2022 11:49 AM
To: cctalk at classiccmp.org
Subject: RE: idea for a universal disk interface

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