BigDumbDinosaur wrote:
Thanks for posting that stuff.
Rambling thoughts: casually perusing the Seagate ATA manual highlights the considerable differences between ATA (IDE) and SCSI. The equivalent Seagate SCSI manual runs some 230 pages, versus 80 pages for the ATA manual.
Makes sense, the SCSI protocol supports a wider array of device types and many more of them. (I want to say I recall from my fuzzy memory seeing some SCSI scanners and printers back in the day.)
PATA really only needed to address two devices and at the basic level ATA you can get PIO mode out of most IDE drives and CD-ROMs. I don't recall the details, but when I wrote some professional disk cleaning software we were using the low level ATA and ATAPI commands to identify the drives and to execute their secure erase method (if they had them). You ALMOST didn't need to too concerned if you were working with an HDD, SDD, or CD-ROM.
Quote:
Attachment:
parallel_1997.pdf
Most of that is due to the much higher level of intelligence embodied in SCSI. Of course, that intelligence comes at a cost, which is why IDE came into existence—the bean-counters won out over the engineers.
SATA continues with that thinking; it’s essentially the same, but with a very fast serial connection instead of a parallel one.
Almost, SATA does implement a few new features over PATA, or at least the protocol level they do. (Native Command Queuing springs to mind)
Quote:
Something I’ve often thought about is how to go about adapting SATA peripherals to a 65xx system—high-capacity SATA disks are inexpensive and fast. The principle roadblock to doing so is SATA technical documentation is closely guarded and only available at considerable cost, unlike PATA and SCSI, documentation for both having been widely promulgated.
Some SATA to PATA adapters can be had for not a lot of money. No idea how well they work, but that would save you from having to try and break down the SATA line protocols. (Unless you like reverse engineering that stuff.
)
Did some digging and found this blog post which seems to go into some detail about the signalling that happens with the SATA lines:
https://www.delkin.com/blog/sata-serial-ata/Maybe someone with more hardware smarts than me can figure it out?
Quote:
In my application, I implemented SCSI with a host adapter designed around the AMD/NCR 53C(F)94 bus controller, which has the intelligence required to manage the SCSI bus. While I am intimately acquainted with how SCSI works at the hardware level, most of that knowledge wasn’t a prerequisite to implementing a working subsystem with the 53CF94. I'm not aware of any readily-available controller IC that could take on such a role and allow implementation of SATA (or SAS, for that matter) on a home brew system. Given the complexity involved, designing a suitable host adapter using off-the-shelf silicon isn’t likely to happen.
The ATA bus is essentially an extension of the 16-bit PC-AT internal I/O bus. That characteristic means a reasonably-functional host adapter can be readily fashioned with off-the-shelf silicon. However, the result will be a “dumb” interface, which means the intelligence required to manage the bus has to be in the device driver. Such an arrangement will be inherently slow on any 65xx system, irrespective of the raw performance of the attached peripherals. Lack of intelligence in IDE, as well as the need to “byte-bang” the interface, is what motivated me to use SCSI; the SCSI driver only has to know how to talk to the host adapter, which handles all aspects of communicating with the addressed peripheral.
I do recall looking over the schematics for the Magic-1 home brew CPU/Computer and he used a 8255 to control handle PATA devices. Which appears to be not terribly different from a VIA, just fewer features, but more I/O ports. (So yea, basically a VIA for the 80x86)
Not sure how much the ATA controllers from the past (or present) handle device or if they just pass thru like the 8255 does. But I'd think if a home brew CPU made from discrete ICs could handle it, the 6502 probably could as well.
When I was working with these things I was using FreeBSD; all I had to do was build up a structure to send to the kernel and it did the hard work sending the command along to the correct drive.
(Heck I recall digging through the kernel some, apparently some Fujitsu drives didn't put their name in the identification block correctly and the kernel had a hack to fix it the right way around.)
Login
Register
FAQ
Search
