Chinon HD drive won't read HD floppies?

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

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.

Quote:

---

Originally Posted by Bryce

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?

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.

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.

Quote:

---

Originally Posted by Bryce

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.

Quote:

---

Originally Posted by Bryce

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.

Quote:

---

Originally Posted by Bryce

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?

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.

Quote:

---

Originally Posted by Bryce

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.

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.

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?

Quote:

---

Originally Posted by ptp170

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).

Quote:

---

Originally Posted by ptp170

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)..

Quote:

---

Originally Posted by Bryce

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).

Quote:

---

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

Quote:

---

Originally Posted by ptp170

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.

Quote:

---

Originally Posted by ptp170

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.

Quote:

---

Originally Posted by BLTCON0

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.

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?

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?

http://www.amibay.com/attachment.php...2&d=1434657175

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'

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.!

try pushing down on the disk when its in the drive.im curious.

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

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

Quote:

---

Originally Posted by hooverphonique

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.

---

The bitstream with any plain (ID-unaware) drive connected would be identical to no drive connected at all, that is all 1's, for the very reason you just mentioned.
RDY is active low - so the CIA will keep it high (=1) until something connected to it signals by driving it low (=0). So both no drive at all AND a connected but detection-unaware drive would, as you correctly state, leave RDY untouched, resulting in a stream of 1's.

An easier argument: If it was as you say, then the separate DD-ID circuitry would not be required for external DD drives, nor would e.g. (on the A2000) the J301 jumper be needed to enable detection of a DD drive as df1:

If you take a look at the A2000 schematics, you can see that all J301 does is bridge the ID circuitry to the RDY line.
With J301 closed, the RDY is fed: ~(~SEL_1 & Q) = SEL_1 || ~Q
Now before the ID detection routine enters the bitstream-reading loop, MTR is driven high and SEL_1 low, then in the main loop before each reading of RDY a high to low transition of SEL_1 is executed, resulting in a low to high transition on U108's clock input. This latches the state of MTR into U108's D input, and Q = D, therefore Q becomes MTR each time the loop is executed and since MTR is not changed throughout the loop it remains fixed to its initial high state.
Thus, right before RDY is read, Q = high = 1 and SEL_1 = low = 0, and thus RDY = SEL_1 || ~Q = 0 || 0 = 0 and therefore we get a stream of 0's as we indeed should for a 3.5" DD drive.

But the same procedure for a plain drive as unit 0 will yield a stream of 1's. A way to resolve this is to make an assumption on the drive type, the natural one being it's a 3.5" DD one as all pre-HD Amigas came with one installed anyway.

Quote:

---

Originally Posted by ptp170

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-d...4/11/0018.html

- - - Updated - - -

And further still!

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

---

There are two possible ways to read the IDs table - one is the inversion of the other. Both are correct depending on your view of what "read the state of the RDY signal" means.
This can be done either in the high/low mentality or in the logic state mentality.

Since RDY is an active low signal (-) read through the positive logic CIA (+) the composition is (-) and therefore you read 1's when it is inactive.
(this would be a technician's preferred interpretation)

But if you choose to interpret 'state of RDY' in the logic sense, that is true for active and false for inactive, then you end up with 0's when it is inactive.
(this would be a programmer's preferred interpretation)

So, the table can be either:

$0000 0000 = nothing
$FFFF FFFF = 3.5" DSDD disk in drive
$AAAA AAAA = 3.5" DSHD disk in drive
$5555 5555 = 5.25" DSDD disk in drive

or

$FFFF FFFF = nothing
$0000 0000 = 3.5" DSDD disk in drive
$5555 5555 = 3.5" DSHD disk in drive
$AAAA AAAA = 5.25" DSDD disk in drive

So, you just throw in a 3.5" DSDD disk to determine which of the two versions of the table your software follows, then you know how to interpret the other numbers as well.

EDIT: These tables were based on info from the Hardware Reference Manuals which appears to be incorrect. Apparently the table should be (non-inverted, true RDY state approach):

$FFFF FFFF = no drive connected
$0000 0000 = 3.5" drive (DD or HD) with no disk in it OR 3.5" drive (DD or HD) with a DD disk in it
$AAAA AAAA = 3.5" HD drive with an HD disk in it
$5555 5555 = 5.25" DSDD disk/drive

Given the two links I've posted, I'm wondering it this is a kickstart/software issue? The one difference is that I'm using AmigaKit 3.1 ROMs and the last machine was 3.0...

Isn't the disk.resource (and trackdisk.device?) library located in the ROM? Maybe AmigaKit's included version has a bug in it? I haven't got any 3.0 ROMs to try it with.

I have 3.1 roms in my A1200, they're from Amigakit (the ones before the blue sticker). My HD drive works O.K.

Quote:

---

Originally Posted by BLTCON0

Quote:

---

Originally Posted by ptp170

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-d...4/11/0018.html

- - - Updated - - -

And further still!

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

---

There are two possible ways to read the IDs table - one is the inversion of the other. Both are correct depending on your view of what "read the state of the RDY signal" means.
This can be done either in the high/low mentality or in the logic state mentality.

Since RDY is an active low signal (-) read through the positive logic CIA (+) the composition is (-) and therefore you read 1's when it is inactive.
(this would be a technician's preferred interpretation)

But if you choose to interpret 'state of RDY' in the logic sense, that is true for active and false for inactive, then you end up with 0's when it is inactive.
(this would be a programmer's preferred interpretation)

So, the table can be either:

$0000 0000 = nothing
$FFFF FFFF = 3.5" DSDD disk in drive
$AAAA AAAA = 3.5" DSHD disk in drive
$5555 5555 = 5.25" DSDD disk in drive

or

$FFFF FFFF = nothing
$0000 0000 = 3.5" DSDD disk in drive
$5555 5555 = 3.5" DSHD disk in drive
$AAAA AAAA = 5.25" DSDD disk in drive

So, you just throw in a 3.5" DSDD disk to determine which of the two versions of the table your software follows, then you know how to interpret the other numbers as well.

---

Well a DD disk produces $00000000 so in that case this meaning that $55555555 is actually correct for HD 3.5" floppy.. Ignore!

Quote:

---

Originally Posted by ptp170

Well a DD disk produces $00000000 so in that case this meaning that $55555555 is actually correct for HD 3.5" floppy..

---

According to the Hardware Manual, yes.
The table it lists indicates:
$0000 0000 --> nothing
$FFFF FFFF --> 3.5" DSDD
$AAAA AAAA --> 3.5" DSHD
$5555 5555 --> 5.25" DSDD

But in the link you posted someone wrote this comes from the developer includes:

DRT_EMPTY EQU $FFFFFFFF
DRT_AMIGA EQU $00000000
DRT_150RPM EQU $AAAAAAAA
DRT_37422D2S EQU $55555555

Which agrees to the HW manual for 3/5" HD/5.25" but does not agree for 3.5" DD/nothing.

I don't know if the hardware manual got it wrong, the same values are present in both the 2nd and the 3rd release.
But according to the includes equates, you're of course right it thinks it's a 5.25" drive.

Just ran DriveID on my A1200 which I've also equipped with an FZ-357A drive. It reports $0000 0000 for DD disks and $AAAA AAAA for HD disks. So I guess the hardware manual has it wrong on both revisions and that your drive indeed misreports itself, it should be easy to fix though, just cut the RDY line and use the equation: RDY_A = XOR(MTR_F, RDY_F) where RDY_A is the READY line on the Amiga side, RDY_F the same line on the floppy side and MTR_F the drive's dedicated motor control signal.

Quote:

---

Originally Posted by BLTCON0

Just ran DriveID on my A1200 which I've also equipped with an FZ-357A drive. It reports $0000 0000 for DD disks and $AAAA AAAA for HD disks. So I guess the hardware manual has it wrong on both revisions and that your drive indeed misreports itself, it should be easy to fix though, just cut the RDY line and use the equation: RDY_A = XOR(MTR_F, RDY_F) where RDY_A is the READY line on the Amiga side, RDY_F the same line on the floppy side and MTR_F the drive's dedicated motor control signal.

---

Not getting email notifications any more for this thread... Weird?!

Thanks for confirming things using your own machine. Not sure how to implement your fix above though? Are you talking about a hardware fix with a 74LS86 (or similar) or a software 'patch' here?

My only other thought was that a knackered capacitor somewhere is holding the RDY line in one state for too long and this causes the flip flop to be interpreted in an inverted manor? I've looked at the schematic's for the RDY line and there seems to only be one tiny value capacitor on the Amiga side. I've replaced the SMD capacitor on the Chinon just in case this causing an issue but it made no difference.

Which revision machine do you have? I've been looking at this schematic (http://www.amigawiki.org/dnl/schematics/A1200_R1.pdf) and on Sheet 8 it implies there is some sort of 'overlap' problem with U26 and U26X which controls the motor. On the later schematic (http://www.amigawiki.org/dnl/schematics/A1200_R2.pdf) this issue seems to have been corrected with just U26 used. < Just looked on my actual board and found that U26X isn't populated.

EDIT: Actually, can't I just NOT gate the RDY line? According to those links that should 'correct' signal?

Quote:

---

Originally Posted by ptp170

EDIT: Actually, can't I just NOT gate the RDY line? According to those links that should 'correct' signal?

---

Sadly not.
RDY has dual usage on the Amiga.

When the motor is ON, it is interpreted as it was meant to (i.e. it indicates the motor is rotating at full speed and thus the drive is ready for I/O).
This function of RDY seems to be OK on your drive (but since Amiga OS doesn't use RDY that way, try with some NDOS trackloading game/demo that utilises it to make sure).
So RDY should not be inverted when the motor is ON, i.e. one part of the equation is ~MTR_F * RDY_F (motor on means MTR = 0 or ~MTR =1, thus ~MTR_F * RDY_F preserves whatever RDY_F is when the motor is ON).

When the motor is OFF, RDY_F has no significance, and they decided to utilise it for ID purposes. Thus inversion should only occur then. This gives the other part of the equation: MTR_F * ~RDY_F (i.e. when motor off aka MTR = 1, invert RDY_F).

Thus RDY_A = ~MTR_F * RDY_F + MTR_F * ~RDY_F = MTR_F /+ RDY_F (where /+ is XOR, ~ is NOT, + is OR and * is AND).

But this is (it just occured to me!) only partially useful as it does not take into account the fact that IDs work correctly for DD disks... so a more complete equation will be required (I'll work it out and update if interested). Too bad though cause it won't be as simple as a single XOR :)

Quote:

---

Originally Posted by BLTCON0

Quote:

---

Originally Posted by ptp170

EDIT: Actually, can't I just NOT gate the RDY line? According to those links that should 'correct' signal?

---

Sadly not.
RDY has dual usage on the Amiga.

When the motor is ON, it is interpreted as it was meant to (i.e. it indicates the motor is rotating at full speed and thus the drive is ready for I/O).
This function of RDY seems to be OK on your drive (but since Amiga OS doesn't use RDY that way, try with some NDOS trackloading game/demo that utilises it to make sure).
So RDY should not be inverted when the motor is ON, i.e. one part of the equation is ~MTR_F * RDY_F (motor on means MTR = 0 or ~MTR =1, thus ~MTR_F * RDY_F preserves whatever RDY_F is when the motor is ON).

When the motor is OFF, RDY_F has no significance, and they decided to utilise it for ID purposes. Thus inversion should only occur then. This gives the other part of the equation: MTR_F * ~RDY_F (i.e. when motor off aka MTR = 1, invert RDY_F).

Thus RDY_A = ~MTR_F * RDY_F + MTR_F * ~RDY_F = MTR_F /+ RDY_F (where /+ is XOR, ~ is NOT, + is OR and * is AND).

But this is (it just occured to me!) only partially useful as it does not take into account the fact that IDs work correctly for DD disks... so a more complete equation will be required (I'll work it out and update if interested). Too bad though cause it won't be as simple as a single XOR :)

---

That's makes sense thank you. I too forgot that if we 'fix' the ID signal it will mess up the DD ID.. shame, as I ordered two 78LS86 from eBay :lol:

Might be time to order a proper oscilloscope as I've been wanting a Rigol DS1054 for a while now:D

Quote:

---

Originally Posted by BLTCON0

Quote:

---

Originally Posted by hooverphonique

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.

---

The bitstream with any plain (ID-unaware) drive connected would be identical to no drive connected at all, that is all 1's, for the very reason you just mentioned.

---

you are right, of course.. don't know where that brain fart came from :-)

- - - Updated - - -

Quote:

---

Originally Posted by ptp170

Might be time to order a proper oscilloscope as I've been wanting a Rigol DS1054 for a while now:D

---

yes, get one of those.. I have a DS2072 modded for 300MHz bw and all options installed, and I think the 1054 can be modded, too ;-)

Quote:

---

Originally Posted by hooverphonique

Quote:

---

Originally Posted by BLTCON0

Quote:

---

Originally Posted by hooverphonique

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.

---

The bitstream with any plain (ID-unaware) drive connected would be identical to no drive connected at all, that is all 1's, for the very reason you just mentioned.

---

you are right, of course.. don't know where that brain fart came from :-)

- - - Updated - - -

Quote:

---

Originally Posted by ptp170

Might be time to order a proper oscilloscope as I've been wanting a Rigol DS1054 for a while now:D

---

yes, get one of those.. I have a DS2072 modded for 300MHz bw and all options installed, and I think the 1054 can be modded, too ;-)

---

Ordered my 1054Z today and I've got links to the sites in readiness ;)

This is going to be the most expensive floppy drive fix ever :roll:

Wow, what a great thread. I've learnt many things about Amiga drives that I didn't know. I was always of the opinion that they were more or less a PC drive. Looks like I need to read up more on this.

@ptp170: The Rigol is a great scope for the price. A good choice you've made there.

Bryce.

Quote:

---

Originally Posted by Bryce

Wow, what a great thread. I've learnt many things about Amiga drives that I didn't know. I was always of the opinion that they were more or less a PC drive. Looks like I need to read up more on this.

@ptp170: The Rigol is a great scope for the price. A good choice you've made there.

Bryce.

---

Isn't it just !

Found this as well which is a great resource for Amiga drives! http://issuu.com/ivanguidomartucci/d...ut---ebook-eng

DS1054Z is arriving today, plus I've got a logic analyser on the way too :D

Although I own other relatively expensive but older scopes, I bought a Rigol MSO1104Z-S which includes a Logic analyser and frequency generator. Very happy with it so far. At first I was double checking with an Agilent or Tektronix scope to be sure the readings were correct, but it proved to be pretty trustable and accurate. What LA have you gone for? I assume it's a USB thingy?

Bryce.

Quote:

---

Originally Posted by Bryce

Although I own other relatively expensive but older scopes, I bought a Rigol MSO1104Z-S which includes a Logic analyser and frequency generator. Very happy with it so far. At first I was double checking with an Agilent or Tektronix scope to be sure the readings were correct, but it proved to be pretty trustable and accurate. What LA have you gone for? I assume it's a USB thingy?

Bryce.

---

It's a clone of the 8 channel Salene LA, they seem to be a bit hit and miss depending on how good the clone is but thought it would make a nice item to go with the Rigol.

Playing with the 1054 now... First thing I did was 'upgrade' it... I'm getting baffled by doing the simplest things... There are so many features it's quite overwhelming.. I might actually have to resort to the manual. Still, I've managed to grab a poor snapshot of what's happening on the RDY line and I think the issue might be that some of the data state transitions aren't making it to 5v so it might be that the Amiga isn't seeing a'll the '1s' that is should...

If that's the case, then you can solve it by adding a pull-up resistor on the RDY line. The lower the resistor value, the faster it will switch from 0 to 1. I'd try something "weak" first like a 10K though. If that doesn't work you could go down to about 2.2K.

As far as the scope is concerned, that's a bit (way) off topic, maybe we should move that part of the discussion to PMs?

Bryce.

Quote:

---

Originally Posted by Bryce

If that's the case, then you can solve it by adding a pull-up resistor on the RDY line. The lower the resistor value, the faster it will switch from 0 to 1. I'd try something "weak" first like a 10K though. If that doesn't work you could go down to about 2.2K.

As far as the scope is concerned, that's a bit (way) off topic, maybe we should move that part of the discussion to PMs?

Bryce.

---

I've packed up for tonight and will continue tomorrow after work. I've figured out how to capture the information now and I think I've located the ID HD signal which appears to be 16 high to low pulses just before the drive motor kicks in... I'll see if I can Photoshop something together to show everybody :)

Or just stick a USB stick in the scope and press the screenshot button?

Bryce.

Quote:

---

Originally Posted by Bryce

Or just stick a USB stick in the scope and press the screenshot button?

Bryce.

---

This event occurs between you physically inserting a disk and the drive motor spinning up.

The purple trace is pin 9 on the CIA (ignore the PAUL[a] label) and the yellow is at the floppy interface. I looked at both areas just in case something was interfering between both points

The first image is what happens with a DD disk. 'Strange' result which is what i was kind of seeing last night.
Attachment 90587


The second image is what happens with a HD disk. 16 pulses low to high.

Attachment 90588

I'm a bit stumped!! :blink:

Well captured, looks like you've got to grips with the scope already :) The first signal is very suspect. Considering it's going into a TTL input it's random at best, but it's too structured to be simple noise. So something has failed somewhere, it's like a pulsed connection to a discharging capacitor.

Bryce.

I took it to work to play around with on my lunch break so I could get used to it :)

I was expecting the HD signal to be strange and not the DD one. I will dismantle and probe further ;)

- - - Updated - - -

Out of curiousity I've looked at the RDY line on the Teac drive that originally came with the 1200 and also a modified Sony MPF920-E and there is no signal before the motor spins up.

But of an update, I didn't realise HD functionality was supported in the 2.04 ROM. I've used the drive in my restored A500+ and it works flawlessly!

So, that eliminates the HD drive as being the issue. I've got some 3.0 ROMS on the way plus another motherboard so should be able to identify what the culprit is before long.
If it still refuses to work then I've ordered a set of Panasonic capacitors and see if that solves the problem..

The HD ID burst on the 500+ is exactly the same as measured on the 1200..

Keep tuned folkes, I've not given up....

Quote:

---

Originally Posted by ptp170

Out of curiousity I've looked at the RDY line on the Teac drive that originally came with the 1200 and also a modified Sony MPF920-E and there is no signal before the motor spins up.

---

Correct, no standard DD drive includes an ID mechanism. That's an Amiga-specific requirement.
For "internal" (unit 0) drives the DD ID is not a requirement, for "external" (unit 1/2/3) drives a NAND gate suffices as the ID is all 0s. If you want to see the complete external drive interfacing, take a look at the A2000 schematics, both motor handling via a flip-flop and ID generation via NAND are shown there because the 2nd internal drive is by all means 100% the same as an external drive for the A500.

Right, epic update time.

New capacitors in the 1200 - No change
3.0 ROMS - No change
New 2B motherboard tried with 3.0 and 3.1 ROMS - No change

So it's either something to do with the 1200's architecture or something in the ROMs that can't quite figure out the signal from the HD floppy. As posted previously, the drive works perfectly in a 500 plus...

One is a tad stumped!

Yes it doesn't make much sense. But the A1200 architecture doesn't have any issue - with respect to the floppy, the architecture is basically the same as the A500's. And of course there's nothing wrong with the ROMs.
The logical conclusion is 2000 years ago someone placed a curse on you :)
Maybe you can test it as an external drive. If you have a casing that takes standard Amiga drives, you'll just have to bypass the PCB's RDY segment and wire it directly (to avoid having the PCB erroneously present the drive as a DD one).

Quote:

---

Originally Posted by BLTCON0

Yes it doesn't make much sense. But the A1200 architecture doesn't have any issue - with respect to the floppy, the architecture is basically the same as the A500's. And of course there's nothing wrong with the ROMs.
The logical conclusion is 2000 years ago someone placed a curse on you :)
Maybe you can test it as an external drive. If you have a casing that takes standard Amiga drives, you'll just have to bypass the PCB's RDY segment and wire it directly (to avoid having the PCB erroneously present the drive as a DD one).

---

This has turned out to be the most expensive floppy drive in history so far!

Still suspicious about the trackdisk library in the ROMS however. Those two links on Page 2 hinted at ID issues nearly twenty years ago so maybe its related to an early revision of the 357A drive?

I think I'll try and look into using the Setpatch command to use a custom trackdisk lib although I've never done this before (assuming its possible?) so any pointers from anyone would be a great help :thumbsup::thumbsup::thumbsup:

I think the confusion with ID issues was about the interpretation of the bits state, considering RDY is an active low signal.
I doubt there are two versions of the high-density ID (if I get your theory right, you're suggesting early rev FZ-357A has an HD ID "compatible" with the 2.04 ROMs while the 3.0/3.1 ROMs expect the inverse. But on the other hand, the inverse is for 5.25" drives, so a 5.25" would also appear as an 3.5" HD unit, doesn't make much sense to make such a mess, even for Commodore :) Furthermore, the A4000 was shipped with either the FB-357A or the FZ-357A so it's highly highly doubtful there's any "old" vs "new" scenario).

Maybe you can simply softkick the 2.04 ROM for your test?

Random, and completely uneducated thought! Try a 3.1 rom in the 500 Plus?