Cyclone 20 - idea for homemade USB-based floppy controller (Catweasel-ish)
 

(Edit: Hi, if you just got here, this thread contains everything you want to know, skip to the last page for current progress.
There is also a project doc Here )


Hiya,

Mr Vince got me thinking about Cyclone and how I'd always wanted to do a "real" hardware copier that could actually sample and recreate the proper bitcell timing on disks; i.e. write long tracks etc under software control and other fun stuff.
This is no big woop nowadays - Catweasel has done it for years (as far as I can tell, not got one), but I've got an itch to scratch and it's 20 years since the first Cyclone, so I'll see if I can whip up a modern version of the original. Hopefully it can be made from parts (well one board) readily available on ebay, any old 3.5" floppy drive, and very minimal easy soldering.

The only advantage over Catweasel would be that you could make it yourself fairly easily (in something of a wry tribute to the original Cyclone) , it'd be USB-based and work on XP, Vista etc without complaint, and we might as well open-source the software because I sure as hell can't be arsed to write lots of nicities once the really geeky stuff is working. It might technically be cheaper but not so much that'd you'd do it to save money. Other nice thing about GPL is there's a bunch of sweet code out there already to save us time. Someone could write drivers for WinUAE etc if required, although mainly I imagine it just a raw floppy read/write tool and not much more.

Certainly writing IPF images back to make working disks would be on the agenda if anyone wants to do it, I can't personally see a reason why not.

No promises mind, is just a thought at the moment, but I have some parts in the post & I'll let you know if it gets any further. It's definitely technically doable though... ;-)

I'd be very interested in that Richard - sounds like a great plan :) :great

USB floppy drive with fully controllable raw read/write ability = Yes, please!

What a great idea! :great I'm definitely interested. :)

Yes please :)

EDIT: is it only the software which prohibits the CatWeasel to write ipfs back to disk? Or is the limitation in hardware?

Catweasel (I am guessing - not got one) doesn't have any significant restrictions on what it can write to disk in hardware - te programmable bit-timing stuff I mention has been easy to do in FPGAs for many years (as seen in Catweasel) and is now easy to do with cheap (<$10) ARM microcontrollers.

Skimming the catweasel docs there is mention of things like bitcell timing error diffusion which (to modulate the bitcell width over successive written words to arrive at a very precise overall track length) which clearly indicates that Jens the designer knows exactly what he's talking about. This makes me assume that nobody's written IPF writing software yet, and I can only assume that's b/c people are nervous about encouraging piracy, not because it's in any way hard.

Obviously that last argument is kinda based on the assumption that software on Amiga floppy disks still has some kind of real monitary value, which I'm not personally sure it really does other than in the time-addled nostalgic minds of us old folk. ;-)

IPF format is not documented and library does not return enough information to write it back properly, especially if it has "flakey" bits.

EDIT: and I am not even interested because CWMK4 won't apparently never work on my development PC (no 64-bit drivers) and promised real time reading has not been implemented. (yes, I know I have said this already many times but I never stop until it gets fixed)

Jean-Francois Del Nero, the guy who created the floppy disk emulator claims to have reverse engineered IPF format.

http://jeanfrancoisdelnero.free.fr/f...tor/index.html

He said in a post to this forum (or was it Amiga.org?) that his stand alone emulator supports IPF images with copy protection.

If he has, he should be able to help here too. Msg him.

Nope. http://eab.abime.net/showpost.php?p=459546&postcount=23

btw, I am never going to even attempt that, not going to annoy SPS guys :)

But:

http://www.amiga.org/modules/newbb/v...orumpost555456

No need :)

The only thing that cannot be queried with the recent interface of the library (the latest features are only documented in UAE and upcoming emulators) is the exact location of weak bits.

However that could be:
1, added to the library
2, very easily derived from the data by simply locking the same track a few times and comparing the returned data.

Lemme get this straight - you can build a USB floppy controller that will read Amiga disks? If you pull it off can you also put a couple of Amiga Joystick connectors in there as well (using the same USB port) - if so then I'm very interested... :agree

mm looks pretty straightforwad
 

Sure you can. I've not made it yet, I just scribbled down some back-of-a-napkin calculations the other day and it looks laughably easy with a modern cheapo ARM system-on-a-chip. It's insane what you get in a $10 chip nowadays!

Here's a bunch of rambling. Excuse the style, it was late.
http://docs.google.com/Doc?id=dgddtc7_102gbzr2mgr


I've got an ARM prototyping board in the mail off ebay which I think I paid $75 for, but there's definitely cheaper options out there.

This one has an Atmel AT91 (NOT to be confused with an Atmel AVR, different thing) with 64k of RAM (a good bare minimum) and lots of useful connectors, level shifters, plenty of space for soldering easy components, etc.
Basically it's the easy, deluxe option.
http://cgi.ebay.com/ATMEL-AT91SAM7S2...QQcmdZViewItem

Errrm Amiga joysticks? I actually can't even remember how they work. 9-pin D wasn't it? [quick google] ...Erm yes that's trivial, especially if you only want digital sticks. I'll put something in the doc about it.
Basically you'd want to add a 9-pin d-connector and 6 short pieces of wire; you'd be done before your tea cooled down enough to drink properly.

Bear in mind that I have no intention currently of actually making these things for people (mine will probably be a breadboard with wires) or a cases or proper shiny software etc.
I have about the attention span/leisure time to hack it together and get it working over a couple of weekends, take some pics and put schematic & code on sourceforge, and it can be a community project.

If you want 5V USB power to make the whole thing neat you'd have to start with a (modern) 5V USB floppy drive (e.g. $8 from amazon) and open it up. This gives you a drive mechanism you know to be good at USB power (5v 500ma), however we don't know how well they'll perform reading amiga disks - in theory they'll be fine but hey, let's see. I'll order a couple now.

I expect people will use a variety of drives (authentic Amiga drives, new USB drives, old PC drives, old 5.25" drives,etc) and doubtless some will work fine and others not for the usual array of reasons.
Older drives will def. need external power (suggest a spare ATX power supply which already has right connectors) and may need a level shifter chip (e.g. $1.50)

Cheers
Rich

Looks good so far :)

Except one possible "detail", does this allow reading (preferably writing too) in real time? I mean can I get bytes (DSKBYTR-register like data, the rest is easy in software) in real-time without too big lag for real-time emulation.

I guess the biggest problem is lag caused by USB drivers/hardware.. Some kind of pre-buffering tricks should help. I hope.. I really want direct, transparent emulated DF0: using real disk drive (CWMK4 was supposed to be able to do that but..)

As long as there are free IO pins: support buttons 2 and 3 (mouse/cd32 pad :)) Note that CD32 pad requires bidirectional lines.

Insane. Great :D

at last ! we will be able to write back :D yehhaaa ;)

Rich, seems like we're not alone wanting something like this. ;-)

Short preface: Rich did the Cyclone app for the Amiga, I worked at the same company (Cachet) for about three years making parameters for it. I'd be glad to help researching on this. I also have some disks that are still in good condition for testing the product on nasty copy protections.

Concerning images: I think we all want the same... we want to write back disks to play on real silicon. And we of course want to read disks. We can use an own, open source format for this. I think ADF will not do as ADF ist not capable of holding real magnetic flux information (the sampled MFM signal from the drive head). We would need to design something ourselves. I would suggest making one step before making to. First, do a raw MFM container format. This will result in huge images (Rich - 8 MB per image?). This can also be used for writing the data back to disk. I only see on exception from the rule, which would be weak bits, which could be solved by allowing track duplicates of MFM data. So if track 0, side 1, has known weak bits, read it 3-5 times and store them. Step two would be designing something like IPF, but open source, with the intention of adding a descriptive language like FreeForm (as used by Trace machines) to reduce the amount of disk space used by the images.

Concerning IPF: This format is for preservation. I don't see any need to write to it. I assume all we want is to extract or convert the data and feed it into our format for writing back to disk. Maybe the guys are open minded and even like the approach we're taking. If have asked Ville9 from Softpres to comment on this. Maybe in the end, everyone could do dumps using the hardware we're going to build, send the raw image over to Softpres and have it archived using their analyzer. Maybe we could also share code. We'll see. I really appreciate all the work Softpres has done so far.

From what I have been reading in the docs, everything for regenerating magentic flux should be there. At least WinUAE can read all it needs from, and Softpres claims it preserves everything needed. So... yes, I assume we should be able to make a copier that will transform and IPF back to magnetic flux.

For us living in Europe: I guess that when development of the main hardware is over, we want to have some custom made PCB to cut down costs and to make this thing fit into some case so the casual user does not destroy it by shortening connections etc. Since 2006 any maker of electronics has to recycle them. This ROHS thing basically costs some grand to get approved because you have to make some kind of safety deposit in case you ever go bankrupt. I am not sure about this, BUT I recommend we start (now... or soon...) finding someone who already has this licence and can supply us with the PCBs. I am not sure if Jens Schoenfeld will be interested or if he sees this as malicious competition. I *think* I'd be glad having Jens in there. He could contribute to the software and he could sell the hardware here in Europe, even though the design is open source.

Concerning 9pin in... good idea, we should include support for joysticks and gamepads.


Ok, just some thoughts...

Where do we start? Rich, can any one of us do anything to help right now? I mean, would it be of any help if I start getting the same breadboard, so I could do parallel work and testing over here?

Best,
Chris

There is already FDI format that should support "everything". (not sure if it is good enough for this solution but afaik it can store flux changes)

Also WinUAE has full FDI support which means image testing can be done without writing complex conversion routines etc..

EDIT: added url

http://www.oldskool.org/disk2fdi/files/DISK2FDI.ZIP (FDISPEC.TXT inside, "pulses-index streams track")

Ok, let's take a look at the specs. FDI is free I assume?

Chris

I think this is something we could work with BUT I see not option for a track being in there multiple times (which we'd need for weak bits).

Rich, what do you think?

But I assume the format could be modified. Is anyone in contact with the author? Toni?

Best,
Chris