USB compatibility
#11
(08-07-2014, 03:40 PM)obo Wrote: I got writing working a few days ago for general MFM and FM formats, but haven't added pre-compensation yet. The documentation wasn't completely clear on how the bulk data for writes should be supplied, though I figured (correctly) it'd probably be the reverse of reading and require a RAM upload in advance.

I've a few extra questions too:

1) If the index is already active when an index-synchronised read/write is started, does the firmware wait for the start of the next index or start immediately?

2) Does the density setting control double-stepping tracks, or something else?

3) What difference does the 300 vs 360rpm make for reads and writes? Is it only for drives that support programmatic control of the motor speed?

4) Do you have any recommendations on when (if ever) the device needs resetting? Does closing and re-opening the device give a fresh session, or is it still possible there may be buffered data from a previous session?

Cheers Smile

Hi! Sounds like you are making progress. A DoCMD_ReadFlux() fills the RAM with the data from the track, which can then be transferred via the USB port or serial ports. DoCMD_WriteFlux() writes whatever length you want from the contents of the RAM. So, you need to transfer what you want to write to the RAM prior to doing the write command. For dual drives, you can read and write without doing a transfer at all because the RAM is holding the data.


Answers to your questions:

1) When a read or write command is issued, you can specify the ff_Index flag and that will wait for the index before the command starts. If the index pulse is low (active) when the command is issued, it waits for the start of the next index pulse. This guarantees that data always starts at the very beginning of the index pulse.

2) The density control is for changing between low density and density drive modes. This changes the drive hardware so it works with DD or HD types of disks.

3) Most all 1.2MB 5.25" drives can switch between 300RPM and 360RPM modes. Most do this when changing the density though, with DD using 300RPMs and HD using 360RPMs. Some drives have individual DD/HD and drive speed jumpers.

4) SCP never resets, and there is no need to reset it. The RAM contents remain the same until you power it off.
Reply
#12
Thanks for your answers Smile

I'm still a little confused with 2) and 3), and how they work compared to traditional FDCs. I'd always assumed that the density detect hole on the disk had complete control over the change in density behaviour within the drive. I'd also suspected the change between 300rpm and 360rpm might be triggered by some kind of media sniffing by a traditional FDC.

Ideally I'd like to image disks completely blind, but in an authentic way compared to a normal FDC. Knowing the maximum head and cylinder values should be enough, with the rest worked out. Previously I'd scan the track at each data rate until I found some valid sectors, leaving the FDC and drive to worry about the density and drive rotation speed. Having manual control of both settings potentially makes it more difficult!

With the SuperCard Pro I'm currently scanning at 300rpm and low density, and performing the same flux-level data rate scanning as above to find content. I can check the index time to determine whether I'm really scanning at the 300rpm, but if the drive supports dual speeds I don't think I can tell which is the natural speed for the media I'm reading, can I?

Is it possible to determine the density hole setting from the disk, for automatic density selection in the drive? I'm not sure I can think of a case when I'd want a different density to that of the media.
Reply
#13
Even with a real PC, there is no way to know what drive speed was used to record the original disk without using some mechanism to check it. What a FDC driver does for 5.25" disks is read a sector at one density and look for valid data. I have seen the driver put the drive into high density mode (360 RPMs) and try to read a sector number that is beyond what a low density disk would have. If it finds it, then its probably safe to assume it's not a low density disk. If it doesn't find it, then it switches to low density and tries checking valid sectors. This occurs only on a disk change, not on subsequent reads.

For a 3.5" disk/drive, the drivers rely strictly on the lack or presence of the HD hole (opposite of the write protect) to control the density.

SuperCard Pro gives you complete control of everything, just in case it is required. However, SOME drives will not change when told to, and are hardwired to act in certain ways. Most all of the 3.5" drives ignore any commands to change the density unless deliberately jumpered to have control (and only certain drives even have jumpers), and respond only to the HD hole being open or closed.
Reply
#14
It sounds like I'm best extending my existing multi-rate scanning to handle the extra combinations. I automatically convert between 250Kbps@300rpm and 300Kbps@360rpm for writing, which are effectively the same bit-cell size. Though media from 500Kbps@300rpm read at 360rpm requires scanning at a new 600Kbps to work.

The manual density control might also boil down to re-reading at the other density if nothing was found. Hopefully writing can make assumptions on the data rate, where 500Kbps or above will be high density, everything else low.

I think I've got all the pieces I need now, I just need time to put them all together. Thanks again for your help Smile
Reply
#15
Writing should be hard coded by the user to a known disk type really. There is no way to guess what type of media is actually being used, because you can successfully write HD on a LD disk and vice-versa.

Let me know if you have any more questions!
Reply
#16
I see SAMdisk 3.8.4 was released. How far along are you with the SCP hardware support?
Reply
#17
SCP support is in a separate branch, destined for a 4.0 release in the coming months. I've ended up refactoring a lot of the core disk code, so even though the bulk of the SCP reading and writing seems to be working it's not accessible in normal use.

Once the new core is complete I expect it should drop in fairly easily to support what it was previously able to do through the PC FDC. I might need to do a little more work for special formats, such as weak sectors, but the SCP flexibility should make that easier overall.
Reply
#18
Cool! Well, as always, if you need some help with accessing the hardware let me know!
Reply




Users browsing this thread: 1 Guest(s)