Chinon HD drive won't read HD floppies?

ptp170

R Tape loading error, 0:1
AmiBayer
Blogger
Joined
Aug 20, 2010
Posts
715
Country
UK
Region
Devon
I've bought a Chinon FB357A from a 4000 for use on my 1200. Now, I've used exactly the same model of Chinon on my old 1200 before I sold it with no issues whatsoever.

This 'new' drive was jumpered to DF1: and I 'think' I've set the jumper correctly to DF0:

The drive now reads Amiga and PC DD perfectly, however, HD floppies are a no go... For a PC 1.44Mb floppy I just get df0:???? (as expected) and also PC0:????.
Weirdly I also occasionally get 'ERROR VALIDATING FILE ALLOCATION TABLE...PROCEED AT YOUR OWN RISK'

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???

And yes, I've verified the HD switch is working with a multimeter!

Old 1200 setup was a 1D4 with 3.0 ROMs, CF, DBK 030
New setup is a 1200 1B with 3.1 ROMs, CF, Apollo 040

Is there any jumpers that need bridging on a 1B to enable HD functionality?

CK
 

Bryce

Active member
AmiBayer
Joined
Aug 21, 2012
Posts
2,586
Country
Germany
Region
Nordrhein Westfalen
Sounds like the DD/HD sensor is broken. Is it mechanical or optical?

Did you just test it at the sensor or did you test it at the chip? It could be a broken wire or dry joint causing the issue.

Bryce.
 
Last edited:

ptp170

R Tape loading error, 0:1
AmiBayer
Blogger
Joined
Aug 20, 2010
Posts
715
Country
UK
Region
Devon
Sounds like the DD/HD sensor is broken. Is it mechanical or optical?

Did you just test it at the sensor or did you test it at the chip? It could be a broken wire or dry joint causing the issue.

Bryce.
It's mechanical. I've tested continuity at the switch and across to the test points which is near an IC. Unfortunately the IC is on the other side of the board and would require quite a bit of dismantling to get to.

Workbench's Format tool lists any HD floppy as 880kb and not 1720kb....ummmmm

This is why I was wondering if it's a jumper problems. As surely the drive triggers some sort of signal back to the Amiga to let it know it's a HD and not a DD floppy?
 

Bryce

Active member
AmiBayer
Joined
Aug 21, 2012
Posts
2,586
Country
Germany
Region
Nordrhein Westfalen
Hmmm, it get's complicated at this stage, there's no "DD/HD Pin" that goes back to the computer. The system works like this:

The Floppy drive uses the HD sensor to know how many tracks the media can take, but it doesn't automatically share this information with the computer. The OS has to "ask" the floppy drive to check how many tracks the media has (or can have if the disk isn't formatted). This communication is done with the 8 data bits, which obviously work, otherwise you couldn't read any disk. If you try to format a DD disk in HD, the Floppy will check the sensor and just send an error back to the OS. So either the controller IC on the floppy isn't getting the signal from the sensor, or the controller is damaged and is no longer reacting to this signal.

Bryce.
 
Last edited:

hooverphonique

New member
Joined
Apr 23, 2012
Posts
329
Country
Denmark
Region
Fyn
That's not completely true... a few corrections.. Note that most of the info below does not hold true for regular PC HD drives, only the chinon 357.

The Floppy drive uses the HD sensor to know how many tracks the media can take

HD disks uses the same number of tracks/cylinders as DD (80). The data density of a track is twice as high on a HD disk, which is why amiga HD drives have to drop to half rpm's to match the amiga data rate.

This communication is done with the 8 data bits, which obviously work, otherwise you couldn't read any disk.
a floppy drive doesn't have 8 data bits, but two serial lines, one for writing and one for reading.
The DD/HD/5.25" identification happens using a serial bit stream over the READY line, though, which is clocked out using the SEL line.

If you try to format a DD disk in HD, the Floppy will check the sensor and just send an error back to the OS.

the amiga cannot tell the drive to format in "HD", so if the amiga thinks it's a HD disk, and the drive doesn't, the track will be written and then overwritten because the rotational speed of the drive will be twice what it's supposed to.

hope that clears up a few things..

@ptp170

does the drive drop to half rpm's when using a HD disk?
 
Last edited:

Bryce

Active member
AmiBayer
Joined
Aug 21, 2012
Posts
2,586
Country
Germany
Region
Nordrhein Westfalen
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. 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.
 
Last edited:

hooverphonique

New member
Joined
Apr 23, 2012
Posts
329
Country
Denmark
Region
Fyn
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. 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.

sorry for the confusion.. where are these 8 bits read from? I never heard about them before...

the word (32 bits) clocked out from the 357 is such that when a DD disk is inserted, it behaves like a normal pc drive (i.e. not asserting the ready line). a HD disk causes an alternating pattern to be clocked out.

this clocked out word is also used at reboot to determine if the drive in question supports HD or not.
 

Bryce

Active member
AmiBayer
Joined
Aug 21, 2012
Posts
2,586
Country
Germany
Region
Nordrhein Westfalen
Ah, I think the confusion is coming from my side. I was speaking about the FDC, not the controller on the drive itself. I called both controller without specifying that I'd just swapped from one to the other. That's what happens when you are answering threads while doing something completely different at the same time :D

Bryce.
 

ptp170

R Tape loading error, 0:1
AmiBayer
Blogger
Joined
Aug 20, 2010
Posts
715
Country
UK
Region
Devon
I'm at work at the moment so can't verify the rpm...

Are you saying the normal 150rpm speed only applies to DD disks and the speed is halved to 75rpm for HD floppies? That seems incredibly slow and just 1/4 the speed of a normal PC drive?
 

BLTCON0

Math inside
AmiBayer
Joined
May 7, 2011
Posts
2,221
Country
Hellas (Greece)
Region
Chania, Crete
I'm at work at the moment so can't verify the rpm...

Are you saying the normal 150rpm speed only applies to DD disks and the speed is halved to 75rpm for HD floppies? That seems incredibly slow and just 1/4 the speed of a normal PC drive?

No, it's only twice as slow.
Normal speed is 300 rpm, same as on PCs. On the Amiga 150 rpm is for HD drives/disks (you can practically think that the Amiga HD drives read an HD disk as two DD disks at 300 rpm - that would take twice the time, the same net effect as with halving the rotational speed).

Paula is allowed to DMA 3 words of MFM floppy data per scanline. Per second, that gives a capacity of (recall that one word of MFM data is actually one byte of "real" data):
- For PAL: 625 scanlines/field * 25 fields/second * 3 words/scanline = 46875 words/second of MFM data = 46875 bytes/second
- For NTSC: 525 scanlines/field * 29.97 fields/second * 3 words/scanline = 47202.75 words/second of MFM data = 47202.75 bytes/second

A drive spinning at 300 rpm means it spins at 5 revolutions per second. At each revolution a complete track passes under the heads. A high density drive/disk offers an unformatted capacity of 2 MB ( = 2000000 bytes), spread over 160 tracks, this means each track is 12500 bytes, so the throughput of such a drive at 300 rpm would be 12500 bytes/track * 5 tracks/second = 62500 bytes/second.

Quite obviously, the throughput of a double-density drive which packs 1 MB over the same 160 tracks would be half that figure (always at 300 rpm), that is 31250 bytes/sec.

So, while the 300 rpm throughput of DD drives is far below the Amiga's chipset capacity, the 300 rpm throughput of an HD drive is far beyond it. Of course at 150 rpm the HD throughput drops back to 31250 bytes/second and the Amiga comfortably handles that, at the cost of slowness.

If more floppy DMA time was/could be allocated per scanline Paula could probably handle HD floppies just fine at 300 rpm too (5 instead of 3 slots per scanline and a 1 usec/bitcell option would suffice - I doubt there would be any limitations with outputting at twice the speed).
 

hooverphonique

New member
Joined
Apr 23, 2012
Posts
329
Country
Denmark
Region
Fyn
I'm at work at the moment so can't verify the rpm...

Are you saying the normal 150rpm speed only applies to DD disks and the speed is halved to 75rpm for HD floppies? That seems incredibly slow and just 1/4 the speed of a normal PC drive?

well, almost.. DD speed is 300rpm and HD is 150rpm.. if you have access to an oscilloscope, you can confirm this by tapping into the INDEX signal (one impulse per revolution)..
 

BLTCON0

Math inside
AmiBayer
Joined
May 7, 2011
Posts
2,221
Country
Hellas (Greece)
Region
Chania, Crete
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.
 
Last edited:

hooverphonique

New member
Joined
Apr 23, 2012
Posts
329
Country
Denmark
Region
Fyn
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.

Are you positive about that? As far as I remember, the ID stream of a DD drive is just zeroes, i.e. the drive doesn't even need to know about/have this ID mechanism, because, by default, a drive won't change the state of the READY signal when pulsing SELECT while the MOTOR line is not asserted.
 

ptp170

R Tape loading error, 0:1
AmiBayer
Blogger
Joined
Aug 20, 2010
Posts
715
Country
UK
Region
Devon
That is an awesome amount of information! Thank you :)

Have monitored the flywheel and the speed does indeed halve if the HD switch is toggled...

The importance of the RDY line seems to be key here then as no ID can 've streamed to Paula. This is interesting because I think I've read somewhere that a jumper on the chinon is responsible for the RDY line being connected?
 

roy_bates

resistance is futile!
AmiBayer
Blogger
Joined
Dec 18, 2011
Posts
8,387
Country
england
Region
birmingham
can you take a picture of the jumper block on the back of the drive.

i think four jumpers needs to be there...from memory.

are the jumpers like this?

attachment.php
 
Last edited:

ptp170

R Tape loading error, 0:1
AmiBayer
Blogger
Joined
Aug 20, 2010
Posts
715
Country
UK
Region
Devon
Hi Roy,

The jumper block is 6 pins, in a 3x2 layout. At the moment on the bottom row the central pin and the right hand side pin are jumpered together. When this drive was received it was the central pin and the left hand side pin which seemed to equate to the drive being used as df1: in a previous setup...


I've just used a program off Aminet called Drivespeed. It's verified that the floppy rpm are what they are meant to be for DD and HD floppies.

Another program I found was one called DriveID. Aparently this is able to verify what Paula is seeing via the RDY line. If there is a HD floppy inserted then there is meant to be a flip flop signal transmitted on the RDY line.

DriveID reports '0' when a DD disk is inserted and '55555555' when a HD floppy is in there. All other non existent drives report as 'ffffffff'.

I'm not sure how to interpret this?

- - - Updated - - -

EDIT: Reading the PCFloppy2Amiga.guide on Aminet says that a HD disk should be 'AAAAAAAA'
 

ptp170

R Tape loading error, 0:1
AmiBayer
Blogger
Joined
Aug 20, 2010
Posts
715
Country
UK
Region
Devon
EDIT EDIT: Just found this also in the guide.

When the READY signals are put in a long integer it will give the following
result:
FFFFFFFF = no drive connected (READY stays high, all the time)
00000000 = @{"double*density*disk" link "3.5 880 kb" 0} in HD drive or double density drive
AAAAAAAA = @{"high*density*disk" link "3.5 1760 kb" 0} in HD drive (READY alternating 1010....)
55555555 = @{"5.25*inch*40*track*amiga*drive" link "5.25 440 kb" 0} connected. (0101...)

I found these definitions disk.h in resources of the includes for 2.0. There is
also a flag for DRIVE3_5_150RPM mentioned in trackdisk.h.


So the Amiga thinks this is a 5.25" drive.!
 

roy_bates

resistance is futile!
AmiBayer
Blogger
Joined
Dec 18, 2011
Posts
8,387
Country
england
Region
birmingham
try pushing down on the disk when its in the drive.im curious.
 

ptp170

R Tape loading error, 0:1
AmiBayer
Blogger
Joined
Aug 20, 2010
Posts
715
Country
UK
Region
Devon
I've locked up my man cave for tonight but I'm curious as to your line of thought!

- - - Updated - - -

The plot thickens!

http://mail-index.netbsd.org/amiga-dev/1994/04/11/0018.html

- - - Updated - - -

And further still!

http://www.amiga.org/forums/archive/index.php/t-19858.html
 

hooverphonique

New member
Joined
Apr 23, 2012
Posts
329
Country
Denmark
Region
Fyn
I don't know if it makes any difference to your investigation, but RDY goes to one of the cia's, not paula, and the decisions based on it are purely software, i.e. the hardware doesn't care about the id stream at all...
 
Top Bottom