My description is for Shugart PC drives not the Chinon 357. However, the "8 data bits" is correct, I never said they were being sent serial or parallel, just that it's an 8bit message.
That assumes a dedicated FDC with its own command set which the Amiga lacks - its "floppy disk controller" is a collection of control bits spread over the two CIA chips and some setup/configuration registers in Paula, that's about it. It's as primitive as it gets which at the same times makes it very flexible as very few assumptions are made about the way data is put on the disk - in other words, the functionality of a dedicated FDC must be implemented in software, so one's free to program for a variety of formats.
Even the MFM encoding scheme is different on the Amiga from the IBM PC standard (of course Commodore had to do it differently - in lack of a dedicated FDC, standard MFM encoding/decoding would be extremely slow as it could only be done by the CPU and in a clumsy way, but the Amiga-version of MFM can be encoded/decoded rapidly by the blitter, somewhat making up for the lack of a dedicated FDC. Of course when reading/writing standard PC disks via CrossDOS the regular MFM scheme is used, thus done by the CPU, with obvious slowness compared to handling Amiga disks, even on the A1200's 68020).
Good information to know though. I wasn't aware that the Amiga uses the Ready signal that way. How does this then work if you connect a PC drive to an Amiga?
Bryce.
There are two peculiarities with the Amiga:
1. Even though the normal usage of the READY line is endorsed, Amiga OS completely ignores it and relies on time-delays to ensure the drive is READY. So in that matter, a PC drive can perfectly be used with its absent READY line under Amiga OS usage.
2. Especially for unit 0, no receipt of an ID sequence from the drive is an acceptable condition and interpreted as "DD unit". In other words, trackdisk.device (Amiga OS's "software" FDC) makes the assumption that, since all Amiga models come with a 3.5" drive built in as df0:, it must be there. So, only Amiga-HD drives actually include circuitry to provide an HD-ID. Plain DD Amiga drives don't stream any ID sequence on the READY line since they're assumed to be there, so again no difference from a standard PC floppy here.
For big box Amigas which provide for two drives internally, there's a jumper and some circuitry on the motherboard to stream a DD-ID on behalf of unit 1, so again a plain old standard drive can be used there. If an HD drive is installed as unit 1, the jumper is left off as the drive provides its own HD-ID.
There does exist a special version of the Chinon FB-354, I think it's the rev D, this includes the DD-ID circuitry onboard. It's used in the A1011/A1411 external drives.
- - - Updated - - -
Is there any jumpers that need bridging on a 1B to enable HD functionality?
No, HD-detection is done in software. Even the A1000 can use an HD drive just fine if equipped with an HD-aware kickstart/workbench.
It seems the drive is not streaming the proper HD-ID sequence to let the OS know it's an HD unit.
In that case, since the OS doesn't specifically expect a DD-ID sequence from unit 0, the drive is assumed to be a DD unit and operates as such, which is consistent with your observations.
Other weirdness is that if I leave a HD PC Floppy in the drive and reboot it Workbench requests that you insert a disk into DF0: ... if you click cancel it continues loading from the CF Card... maybe this is something to do with CrossDOS's automounting???
Well, DF0: has the highest boot priority by default and Kickstart knows there is a disk in there (this is irrelevant to DD vs HD - there's a dedicated diskchange detection switch).
So an attempt to boot from df0: is made, but if the drive is incorrectly streaming "nothing" instead of "HD-ID", the ROM will behave as if no disk is inserted and, since booting was meant to take place from df0:, will ask for something bootable to be placed there. Nothing to do with any automounting features.