keithOK, so I finally bit the bullet and have the floppy drive under direct SX control.
I have my amiga power supply, which is a modified PC supply with harddrive leads powering the drive directly with +12v and +5v. I also have a number of leads running direct from the SX to the drive.
I am successfully stepping the drive, although I must admit the direction select is kind of wierd. I expected just to set the lead high or low, but it looks like it needs an edge to change. So HIGH to LOW causes it to step IN, increasing cylinder from 0 to 79, and LOW to HIGH causes it to step OUT, decreasing cylinder from 79 to 0.
I must admit my floppy drive is very cool with the cylinder number in an LED bar graph.
I’ve forgot to run a SIDE lead over, I’m doing that now.
It won’t be long until this is fully automated.
well I’m getting junk out of the read data lead, even though it looks like I am successfully turning on the motor, selecting the drive, and I can step around.
No problem stepping at all, but the read data lead is just putting out junk, like the heads are turned on, but they aren’t touching the disk surface.
Note that when I say JUNK, this isn’t just random noise. There is definitely a pattern I’m seeing, but its definitely NOT MFM formatted…. I’m not sure if I’m seeing noise due to a spinning motor, or what. This junk is only present when the motor is on, or at least when the motor lead is dropped low.
I really can’t hear the motor, but I can hear the stepping. It seems to me as though the drive isn’t engaging the disk. Like it doesnt seem like the head is making contact on the disk itself. I thought select a SIDE might do that, but it hasn’t yet. I do see my drive activity light on solid, which I think is a good thing.
There’s something Im obviously missing. I should be hearing the drive engage the disk, and I really should be hearing the disk spin. I can’t hear either, and I wonder what I’m missing.
Read data can be considered valid only after head settling time, 20ms can be quite safe. Can this be the case if you start reading data right after you step, within milliseconds?
I thought about that, but no, because I’m just looking at the lead on a scope. The entire time the motor lead is low, I see noise on that read data lead. Even if I eject the disc, I still see the same pattern of noise.
It’s my understanding that as long as the motor is on, the head should be on the disk, and be putting out valid MFM waveforms. (or at least 20ms after a change)
I think my order of operations must be wrong — or I’m not doing something I need to be doing.
I would imagine, at a minimum, to read the first cylinder, all I have to do is
a> set the motor lead low, from high
b> select the drive by lowering SEL1
Things like DIRection only affect stepping, no need to step if you want to read the first cylinder, I’m not sure about selecting a head. I would imagine you need to tell it which head to read, although I would imagine it should default.
I’ve tried specifying which head too, with no luck.
My perception is that in 3.5 inch drives, heads get loaded onto disk’s surface as soon as floppy is inserted. That is, all the time the floppy is inside the drive.
What about resistor termination? Remember all output floppy signals are open collector (? or open drain, or whatever this technology is called), thus you need to add pull-up resistor, 4k..10k to +5v for these.
Here’s what I know is working.
1. MTRXD is actually controlling the motor. I can hear the motor faintly spinning the drive. Eject the disk, and the motor stops.
2. Selecting the drive is obviously working because the drive is responding to particular commands.
Direction and stepping appear to be working, although I don’t have it working reliably and it doesn’t appear to be intuitive.
Disk ready doesn’t appear to be functioning, and I haven’t seen anything on Track 0 lead either.
I get output on the read data line anytime the motor lead is low. When I eject the disk, the motor stops, but the junky output stays pretty consistent. This is definitely not just messed up real data, this appears to be some consistent signal.
That was it, Tim, I wasn’t using any pull up resistor, and so the data really wasn’t recognizable. I have noticed that the ramp up from low to a high, that transition is really much slower than on the Amiga. I tried using a 10k and 4.7k. The 4.7k appears to do the best job, at least in how the signal looks on the scope.
I wish I knew what the amiga actually did in terms of hardware, termination, etc. I guess I could open it up, but I’m not sure if everything would be easily accessible/traceable.
Now it’s odd that the drive is forever putting out data when the motor is on, properly MFM formatted, even without a disk in the drive. This sort of perplexes me. I’ve contemplated looking to see exactly what it’s spitting out. Maybe an easter egg message, “hey stupid, put the disk back in drive” or something 🙂
My SX software, however, had no problems reading the data, in just about perfect condition.
I have noticed that my USB transfer doesn’t work quite at 100%, but its pretty close. Must be timing related. Simply redoing the transfer solves any problems.
So this is a good milestone. It’s funny that I was getting good data, but I just couldn’t recognize it was working….
Thanks for the tip, Tim!!!
Any time man 🙂
I doubt the drive can output any MFM data when there’s no disk in drive. I think the spindle is just too lazy to spin without floppy.
But you can read and decode that phantom data just for fun 🙂
BTW, there are Amiga internals schematics in Amiga manuals. All floppy interface lines, along with pinouts, resistors and such can be seen there, no need to pull your Amiga apart. Check them out at aminet.net.
Tim Says: “I doubt the drive can output any MFM data when there’s no disk in drive. I think the spindle is just too lazy to spin without floppy.”
It seems odd to me too, but damned if the data coming from the drive when there is no disk in there sure looks like just regular ‘ole data.
Obviously the amiga creates the MFM when writing to a disk, so without a disk, well, there’s no MFM. That doesn’t quite explain what I’m seeing, however. Is it possible the head picks up noise from the internal electronics of the drive when its not in close proximity to the disk surface?
Well the point is moot, unless the data turns out to be a secret message from aliens, in which case this will be the single most important scientific discovery of mankind.
Then again, it could just be noise. 🙂
Thanks.
This as well can turn out to be the final message of God to its creation, as has been told by Douglas Adams 🙂
hi!
i make a similar project with pic 18f452 and lcd display
but i not decode mfm data , i am curious ,about your sx software ?
if you have any information ?
thanks
a+
Sund,
I decode the MFM data in software on the PC after the SX transfers the data to it. The MFM decoding routines I’m using are mostly from Marco Veneri’s AFR project.
I have a link to both veneri’s code and floppy.c from fellow in this post:
https://techtravels.org/?p=34
MFM on the amiga is screwy, namely that even and odd bits are stored on each half of the sector, and so have to be recombined. This is sort of a shame for data recovery, because if you are missing the first or last half of a sector, you lose the entire thing.
IIRC, the operations are done on a 16-bit word, combinations of one byte even, one byte odd.
The other main problem that has to be dealt with on the PC is that the data is shifted coming out of the drive, so you need some way to sync the data to 0xAAAA 0xAAAA 0x4489 0x4489 magic sync value.
Veneri handles this by looking for the sync, shifting one byte at a time, and then each bit until a match is made. Once this match is made, then each call to his MFM read routines includes the shift that was found in the first search routine. Personally, I’d like to see the data shifted, and then “normal” reads after that. The problem is that each sector can be shifted by a different amount, so you’d need to search/realign for each sector.
Eventually I’d like to add some of this intelligence to the SX side of the house, because I have plenty of speed and memory to work with.
thank , for all this information
i explain little my project
i want to try emulate amiga drive from pc,
send an adf file to my pic 18fxxx and coding mfm data and send when
the real amiga ask it
i have not the problem of shift or sync because i make it ,
but i not see the problem ogf odd and even bits interleave
and i think is not simple to make, i see the floppy.c(thanks)
anaother question
your sx you code in asm ?
Sund:
There is someone who has a really nice project, who watches this blog, who is already doing this with an ATMEL controller.
TIM: Do you have a website, etc, presence? Here’s an amiga.org link
https://www.amiga.org/modules/myalbum/photo.php?lid=2486&cid=5
He writes to an SD card from the PC, sticks it in his hardware, which attaches to the amiga floppy drive port. An lcd selection picks the appropriate .ADF file to “load” into the amiga.
He’s done great work, and is progressing much faster than I am!
My SX code is a hodge-podge of ASM and SXB(aka basic). The init routines, memory management/layout, some subroutines, and non-time sensitive items are in SXB. The ISR is pure ASM. Communications with USB and memory chip is all ASM. So I guess you could say its assembly code wrapped in an SX/B body.
SXB has some advantages regarding ease of use, etc, where I can sort of abstract some higher-layer details away. I have enough memory/cycles etc for speed not to be an issue.
Thanks.
Keith,
Thanks for your kind word about my project 🙂 I’ve been out for some time engaged in releasing a more cool project — my second baby was born on April, 10. And it’s a boy!
I am keeping an eye on this blog, and will gladly answer whatever questions you guys have got.
Congrats Tim!! That is a cool project indeed! 🙂
I’m finishing up my current semester at school, so I’ve been MIA for awile. I need about two more weeks and then I’ll have the whole summer to get this thing rolling again.
I’m real close having a simple hacked together model working completely. I’m anxious to get my first .adf from a disk. It will be fun to test in an emulator…