• Please review our updated Terms and Rules here

AT controllers that support unbuffered seek

famicomaster2

Experienced Member
Joined
Feb 3, 2017
Messages
317
Location
Southeastern US
Hello, today I come to you all with another potentially unanswerable question.

What AT hard disk controllers support unbuffered seek? I can't seem to find any, I am led to believe that one must exist.

I'd like to use my ST-506, TI-5, EC5300, SA-1004, JCT 100, etc disk drives which do not support buffered seek step rates. I do not own a working XT and am priced out of the market for the hardware required to get one working. For some reason, my machine does not seem to support any 8-bit controllers.

As a result of that and as a matter of convenience, it would be best for me to find a 16-bit controller that supports unbuffered seek.

Do any exist? Does anyone have one laying around?
 
I believe that the step rate on AT class 412/506 controller cards is determined by the system BIOS not the card itself. I know that is the case with floppy disks, but I assume it also applies to hard disks since 16-bit MFM cards have no ROM
 
Yup. There's generally a time "threshold" where step pulses issued faster than the threshold result in a ballistic (buffered) seek; slower than that (usually around 3 msec), steps are taken one at a time. All done in software, AFAIK.
 
I believe that the step rate on AT class 412/506 controller cards is determined by the system BIOS not the card itself. I know that is the case with floppy disks, but I assume it also applies to hard disks since 16-bit MFM cards have no ROM
Some of my AT controllers have ROMs still. The step rate is a component of the controller chip itself, it's only written in software as far as I'm aware. I've never seen a machine with a step rate that was definable in the system CMOS.
 
Yup. There's generally a time "threshold" where step pulses issued faster than the threshold result in a ballistic (buffered) seek; slower than that (usually around 3 msec), steps are taken one at a time. All done in software, AFAIK.
Actually, it was via one of your posts that I found it was not entirely software defined.

Of course, if I single step drives very slowly it will work. It will work fine during the low level format on my current controller, but as soon as it does any other seek it will fail.
 
Actually, it was via one of your posts that I found it was not entirely software defined.

Of course, if I single step drives very slowly it will work. It will work fine during the low level format on my current controller, but as soon as it does any other seek it will fail.
What's the drive? What and how is the controller set up? It matters.
 
What's the drive? How is the controller set up? It matters.
Any of the drives listed in my first post. They all behave exactly the same. The controller is in a 16-bit slot, and it's configured at the primary address. The floppy controller is enabled and so is the BIOS.
 
In any case, let's go to fundamentals. Can you monitor the status of control connector pin 8? Normally this is asserted at the completion of a seek operation. Also, is the drive terminator present?
 
Last edited:
In any case, let's go to fundamentals. Can you monitor the status of control connector pin 8? Normally this is asserted at the completion of a seek operation.
Yes, the 7287 is an RLL controller.

The seek complete signal? Why does that need to be monitored? The controller operates fine with over a hundred other drives, the only drives it has difficulty with are those that do not support buffered seek.
 
Newer controllers use "implied seek", so no explicit seek operations are usually used. However, you can check to see if your 7287 supports explicit seek with seek-rate timing by issuing a command 7xh to the controller. x=the step rate. That's how I got my st506 to work--but it was with an 8 bit controller. More modern controllers probably rely on the seek complete signal. So what to do?

1. Use a period-appropriate disk controller; e.g. WD1001 and hack up an interface and driver for it.
2. Synthesize the seek complete signal using a small MCU.
3. Fake up a driver that attempts to read/verify a sector on every track between where you are and where you want to be.

None of which is easy, but I'd be inclined to do (2) first.
You could also use David Gesswein's device to do the job, although if you want to have an online drive functioning as normal PC disk, that's probably not what you're after.
 
Last edited:
The MFM emulator is massively overpriced and overcomplicated, and doesn't really achieve what I want here. I was lent one for testing but sent it back after a couple days.

The drive generates the seek complete signal. It shouldn't have any bearing on the controller. The ST-506 generates it's own seek complete signal just fine.

Where would I issue this command? How would I go about that?
I don't know x86 assembly, only 6800 and 6502. I never had much interest in low level programming for the PC.

To be clear, I don't want to read or write any data from the drive, I just want to have them seek around. Sadly, with no buffered seek support from the drives and no unbuffered seek from the controller, I have no way to make them move other than in single, slow steps.

If it were feasible, I would not be opposed to modifying the BIOS on the controller. It's got a bunch of really annoying bugs and even some misspelled text ("Plaese").

I can't use an 8-bit controller at all, my machine doesn't seem to recognize any of them. Here are the 8 bit controllers I've tried:
WD XT-GEN (with SuperBIOS)
DTC 5150XL
2x DTC 5150CX
IBM Xebec controller
SMS Omti 3310(?)

I have some SCSI translator boards which claim support as well, but because they do not have an identify command they do not detect. Even if they did, I would need to pass the drive geometry to them at boot (which I don't have the software to do) and even beyond that, my Adaptec controller maps every drive as if it has 32 heads n 63 sectors, so many drives show up as having 20-40 cylinders. This means they basically don't seek.
 
To be clear, I don't want to read or write any data from the drive, I just want to have them seek around.

This was completely lost in the discussion about errors, etc. This is a fish of a different stripe.

You can ignore all the signals on J2 with an ST506-type drive. You can simply drive the STEP/ and DIRECTION/ lines (while asserting the proper SELECT/ and monitoring TRACK 0/ with just about any device capable of driving and reading TTL level data. Even a parallel printer port could do this. Just time the pulses to be greater than the track-to-track seek time. An Arduino would be perfect for this as a standalone device.

I regret that I didn't understand the point of what you were trying to do. Being in the data recovery business, I mistakenly thought that you were actually trying to use these drives for something.
 
No, we've spoken before. I have no intention of storing or retrieving data from these disks. The fun for me is in the mechanical movement.

There is a large suite of benchmark and testing software for PC that I want to rub against these drives to demonstrate their mechanical operation to others. Ab Arduino, while very capable of this task, is not suitable for this application, because I would have to instead spend months if not years rewriting all of the existing software. I am well aware of the simplicity of the interface but surely you can understand why that would be uneconomical as a project.

This is why I just want a 16-bit controller to put into the machine which will actuate the drives for me properly, which is why that was the initial question I asked.
 
Sorry, I don't understand. I often program MCUs to take over the job of obsolete PC or other hardware. But that's me, and to quote Nick Marlowe, "It's what I do".
 
Rather than spend a full year of my free time reinventing the wheel, why would I not use the existing standard software by which I have already tested hundreds of other drives?

Do you know of a controller or not? I will never be convinced to consider the alternative of building my own entire hardware and software library and re-testing 150+ drives to keep from invalidating my existing results.
 
Given that the control interface is scarcely more than a floppy interface, I don't get your "full year" idea. It'd be less than a week for me--and I'd have the confidence of not fooling with some crotchety hardware. The interface is basically TTL OC, unlike the data interface, which is differential.

Perhaps I'm missing something in your post, but if it's just moving the positioner around, that's kid stuff.
 
Given that the control interface is scarcely more than a floppy interface, I don't get your "full year" idea. It'd be less than a week for me--and I'd have the confidence of not fooling with some crotchety hardware. The interface is basically TTL OC, unlike the data interface, which is differential.
I am very well aware of how simple the interface is. Reimplementing about 20 pieces of test and benchmark software from the PC to some random microcontroller would be the difficult part. Good luck finding source for most of them.
For any of those seek time benchmarks to be valid, I would then proceed to re-test every prior drive in my collection.

This would be a very time consuming process for anybody.

If you are willing to take on the project and can complete the entire hardware and software side of this endeavor in less than a week, I would be more than happy to send you my 5 floppy disks of various test and benchmark software to either be translated to a point where I can reliably retest a large number of drives, or cycle accurate so that I don't have to.

Regardless, the easier option for me by significant margin is to just find a controller which supports this one feature, just as my title and original post state.

Please, I would prefer you not reply if you do not have any helpful information to add. "You should re-engineer every part of you existing setup" is not helpful. It only serves to add unnecessarily clutter to a thread where I'm trying to get some real advice.
 
Back
Top