Actually I am talking about emulating the bit stream, index to index - RLL encoded and containing gaps, marks, headers, data, CRC, ECC, etc. Exactly as the bit stream would come out of a theoretical disk drive, no bit shift, no write splices, no instantaneous speed variation, no long term speed variation. That means the controller will have a very easy time of it.
My point is the ESDI/SME bit stream is 15 Mb/sec or lower and the others are lower still while any modern memory can transfer in the Gb/sec range so the track will arrive at the emulator hardware at much higher rate than the controller can absorb and since the track is coming from memory there is negligible latency. You seem to assume that the transfer out of the emulator can't start until the entire track is in the emulator - that's not what I am saying. To use your example, sure it takes 65us to transfer the entire track out of memory but it takes 16.67 msec to transfer it out of the emulator. I suggest transfer out of the emulator hardware can start with the first word into it. Tom -----Original Message----- From: Guy Sotomayor [mailto:g...@shiresoft.com] Sent: Saturday, April 16, 2022 5:14 PM To: t.gard...@computer.org; cct...@classiccmp.org Subject: Re: idea for a universal disk interface 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; cct...@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
