idea for a universal disk interface

[Guy Sotomayor]

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

Since I'm not looking at formatted data rate (just handling the raw bit 
stream) it doesn't really matter what the formatted rate is...and the 
formatted data is different between different controllers, so I don't 
want to even try to do that on the fly (and they might do tricks where 
different tracks/cylinders have different formats.

If some one wants the "formatted" data, then I'd let them post process 
that off the captured data.

As I said, I'm trying to do this with fairly simple logic and low cost 
storage (as such this isn't going to particularly cheap).  I don't want 
to add another $100+ to the cost just to have a high performance drive 
when the HW is capable of doing a suitable job with a $10 SD card.

In reality an SD card (from a storage perspective) is way overkill.  
We're talking about emulating drives with capacities < 1GB and good 
quality SD cards contain 32GB for $10 or so.

TTFN - Guy

On 4/15/22 12:12, Tom Gardner wrote:
>
> I haven't looked it up but I bet the head switch time is a lot longer 
> than 1-2 usec - that's what the leading gap is for and the sync took 
> most of the gap back in those days.
>
> The issue is sustained data rate isn't it?  The ESMD raw data rate is 
> 24 Mb/s but the formatted data is something like 80% of that or maybe 
> 2.5 MB/sec.  A modern HDD in sequential mode can sustain a much higher 
> rate, e.g. Seagate SAS 
> <https://www.seagate.com/files/www-content/solutions/mach-2-multi-actuator-hard-drive/files/tp714-dot-2-2006us-mach-2-technology-paper.pdf> 
> at 520 MB/sec.  My understanding is that the sectors are slipped 
> and/or cylinders are horizontal so that head switching doesn't lose 
> any revolutions.  Maybe one would run into a problem at the cylinder 
> seek moment so maybe one would have to keep each full emulated 
> cylinder on the modern drive’s cylinder, but with Terabytes of data on 
> a modern drive who cares about some wasted storage
>
> Tom
>
> -----Original Message-----
> From: Guy Sotomayor [mailto:ggs at shiresoft.com]
> Sent: Friday, April 15, 2022 10:56 AM
> To: t.gardner at computer.org; cctech at classiccmp.org
> Subject: Re: idea for a universal disk interface
>
> I ran the numbers for Zynq FPGAs.  First of all for ESDI and SMD the 
> head switch time is 1-2us (basically the time it takes for the clocks 
> to re-lock on the new data).
>
> Two tracks isn't sufficient (which is the "other" track...you will be 
> wrong).
>
> So I decided to go and have a full cylinder (I'm allowing for up to 
> 32KB tracks and up to 16 heads) which is 512KB.  The Zynq DMA from HW 
> block RAM to DRAM (at 500MB/s) is ~1ms.  Given that the previous 
> cylinder could be dirty (e.g. has written data), the worst case seek 
> time is ~2ms.  This allows me to emulate any seek latency curve(s) I want.
>
> In my design, any dirty data is written back to storage in a lazy 
> manner so the performance of the storage isn't really an issue.
>
> I should note that the Zynq 7020 module has 1GB of DRAM on it, so 
> there is no additional cost to just put the entire disk contents in 
> DRAM and I'm using the attached SD Card interface for storage (so you 
> can use a
>
> $10 SD Card for storage).  Adding a high speed disk interface (e.g.
>
> MD.2, PCIe, or other serially attached storage) would add additional 
> cost in terms of having to create the interface as well as a 
> reasonably fast drive and I don't see the advantage.
>
> I'm planning on using a Zynq UltraScale+ module to allow for larger 
> disks and multiple disk emulations (it has more block RAM and 4GB of 
> DRAM on the module).
>
> TTFN - Guy
>
> On 4/14/22 23:34, Tom Gardner wrote:
>
> > I suggest if we are talking about an emulator it really isn't 
> necessary to have the entire disk in DRAM, two tracks of DRAM acting 
> as a buffer with a modern HDD holding the emulated drive's data should 
> be fast enough to keep any old iron controller operating without 
> missing any revolutions.  The maximum unformatted track length of any 
> old iron drive is well known and therefore one can allocate the number 
> of blocks sufficient to store a full track and then write every track, 
> gaps and all to the modern disk.  Given the data rate, track size and 
> sequential seek times of a modern HDD one should be able to fill then 
> next track buffer before the current track buffer is read into the 
> controller.  If two track buffers and an HDD isn't fast enough then 
> one could add a track buffer or two or go to SSD's.
>
> >
>
> > This was the approach IBM used in it's first RAMAC RAID where I think
>
> > they had to buffer a whole cylinder but that was many generations ago
>
> >
>
> > Tom
>
> >
>
> > -----Original Message-----
>
> > From: Guy Sotomayor [mailto:ggs at shiresoft.com 
> <mailto:ggs at shiresoft.com>]
>
> > Sent: Wednesday, April 13, 2022 10:02 AM
>
> > To: cctech at classiccmp.org <mailto:cctech at classiccmp.org>
>
> > Subject: Re: idea for a universal disk interface
>
> >
>
> > I've had a similar project in the works for a while (mainly for ESDI 
> and SMD).
>
> >
>
> > I think the main issue you're going to face is that what you need to 
> do for something like ESDI or SMD (or any of the bit serial 
> interfaces) is going to be radically different than something like IDE 
> or SCSI.  This is not just the interface signals but also what's 
> needed in the FPGA as well as the embedded SW.
>
> >
>
> > For example, for the ESDI and SMD interface in order to meet the head
>
> > switch times (1-2 microseconds) requires that a full cylinder be
>
> > cached in HW.  Once you do that and look at the timings to move a max
>
> > cylinder between the HW cache (that will serialize/de-serialize the
>
> > data over the
>
> > interface) and storage, you'll see that the only way to have any
>
> > reasonable performance (e.g. not have seek times be > 40ms for *any*
>
> > seek) is to cache the entire drive image in DRAM and lazily write 
> back dirty tracks.
>
> >
>
> > I've been looking at the Xylinx Zynq SoCs for this (mainly the Zynq 
> 7020 for single drive emulation and the Zynq Ultrascale+ for up to 4 
> drives).  In my case the HW, FPGA logic and SW will share significant 
> portions but they will not be identical.  In my case there is no need 
> for an external PC (just adds complexity) other than something to do 
> basic configuration (e.g. drive parameters such as number of heads, 
> number of cylinders, etc) which will actually be over USB/serial.  The 
> actual persistent storage will be an SD card since all reading will be 
> done at "boot time" and writes will be handled in a lazy manner (since 
> the writes will first go to the DRAM based upon time or seek).
>
> >
>
> > It may also be sufficient for configuration purposes to have a file
>
> > (text) on the SD card that defines the configuration so no external
>
> > interactions would be necessary. I'm still thinking about that one.
>
> > ;-)
>
> >
>
> > TTFN - Guy
>
> >
>
> > On 4/12/22 22:35, shadoooo via cctech wrote:
>
> >> Hello,
>
> >> I'm a decent collector of big iron, aka mini computers, mainly DEC 
> and DG.
>
> >> I'm often facing common problems with storage devices, magnetic 
> discs and tapes are a little prone to give headaches after years, and 
> replacement drives/media in case of a severe failure are unobtainable.
>
> >> In some cases, the ability to make a dump of the media, also 
> without a running computer is very important.
>
> >>
>
> >> Whence the idea: realize an universal device, with several 
> input/output interfaces, which could be used both as storage emulator, 
> to run a computer without real storage, and as controller emulator, to 
> read/write a media without a running computer.
>
> >> To reduce costs as much as possible, and to allow the better 
> compatibility, the main board shall host enough electrical interfaces 
> to support a large number of disc standard interfaces, ideally by 
> exchanging only a personality adapter for each specific interface, 
> i.e. connectors and few components.
>
> >>
>
> >> There are several orders of problems:
>
> >> - electrical signals, number and type (most disk employ 5V TTL or
>
> >> 3.3V TTL, some interfaces use differential mode for some faster
>
> >> signals?)
>
> >> - logical implementation: several electrical signals are used for a
>
> >> specific interface. These must be handled with correct timings
>
> >> - software implementation: the universal device shall be able to
>
> >> switch between interface modes and be controlled by a remote PC
>
> >>
>
> >> I suppose the only way to obtain this is to employ an FPGA for 
> logic implementation of the interface, and a microprocessor running 
> Linux to handle software management, data interchange to external (via 
> Ethernet). This means a Xilinx Zynq module for instance.
>
> >> I know there are several ready devices based on cheaper 
> microcontrollers, but I'm sure these can't support fast and tight 
> timing required by hard disk interfaces (SMD-E runs at 24MHz).
>
> >>
>
> >> The main board should include a large enough array of bidirectional 
> transceivers, possibly with variable voltage, to support as much 
> interfaces as possible, namely at least Shugart floppy, ST506 MFM/RLL, 
> ESDI, SMD, IDE, SCSI1, DEC DSSI, DEC RX01/02, DG6030, and so on, to 
> give a starting point.
>
> >> The common factor determining what kind of disc interface can be 
> support on hardware side is obviously the type of transceiver 
> employed, for instance a SATA would require a differential serial 
> channel, which could not be available.
>
> >> But most old electronic is based on TTL/CMOS 5V logic, so a large 
> variety of computer generations should be doable.
>
> >>
>
> >> For the first phase, I would ask you to contribute with a list of 
> interfaces which could be interesting to emulate, specially if these 
> are similar to one from my list.
>
> >> I please submitters to send me by email or by web link when 
> possible, detailed documentation about the interface they propose, so 
> I can check if it could be doable and what kind of electrical signals 
> are needed.
>
> >> Also detailed information about interfaced I listed is appreciated, 
> as could give some detail I'm missing.
>
> >>
>
> >> Thanks
>
> >> Andrea
>
> > --
>
> > TTFN - Guy
>
> >
>
> >
>
> >
>
> --
>
> TTFN - Guy
>
-- 
TTFN - Guy