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

[Smiley]

This sounds great and I'm always looking for something new to solder/build.

Hopefully if it is completed, it should work with WinUAE?

[Toni Wilen]

Originally Posted by mr.vince

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

Afaik minimum/maximum times are for weak bits and dos-based fdi imaging program does support weak bit protections (also there is some weak bit handling in UAE-side part)

Multiple single tracks aren't going to work very well because there is copy protection that reads few bytes from single track 64 (!) times and at least 50 reads must be different.. (I don't remember the name of that game)

[mr.vince]

Maybe if we have some kind of shuffle algorithm. Does any other game name come to your mind when you think of this kind of protection?

I think we might take FDI and port it to some v2.0... ;-)

Best,
Chris

[Galahad/FLT]

Originally Posted by Toni Wilen

Afaik minimum/maximum times are for weak bits and dos-based fdi imaging program does support weak bit protections (also there is some weak bit handling in UAE-side part)

Multiple single tracks aren't going to work very well because there is copy protection that reads few bytes from single track 64 (!) times and at least 50 reads must be different.. (I don't remember the name of that game)

Wasn't Cardiaxx was it?

[Marcuz]

i think it's a great idea! why don't you add also 2 amiga joystick ports as an afterthought, so i can throw away catweasel as it is ?

[Toni Wilen]

I think it was Magic Lines.

[Smiley]

Originally Posted by marco pedrana

i think it's a great idea! why don't you add also 2 amiga joystick ports as an afterthought, so i can throw away catweasel as it is ?

You can always steal the logic chips out of Fleabay USB controller, wire up two 9pin females and add them to your enclosure with the new uber cool floppy controller.

Only downside I can think of is seperate drivers and 3 usb cables coming out of the enclosure. My kind of party!

If these floppy controllers do end up being designed and easily buildable I will surely add my USB adapter into one big uber unit with the floppy controller.

USB adapter.....http://eab.abime.net/showthread.php?p=479786

[BippyM]

Seems someone has been bitten by that Amiga bug again eh Richard????


Nice to see you about and getting involved in this scene again

[Jope]

Originally Posted by Smiley

You can always steal the logic chips out of Fleabay USB controller, wire up two 9pin females and add them to your enclosure with the new uber cool floppy controller.

Only downside I can think of is seperate drivers and 3 usb cables coming out of the enclosure. My kind of party!

Hm, if you indeed want to go the discrete component route, you would naturally add a USB hub chip in there so that you could use one cable only.

But I do believe the joystick ports for this would be in the firmware for the microcontroller?

[RichAplin]

Hiya,

I'm gathering most of my guff in
http://docs.google.com/Doc?id=dgddtc7_102gbzr2mgr
which people are welcome to edit or whatever.

In short:

FDI file format
Yes, cool, looks totally competent and the low level bitstream thing looks fine. Either me or someone can write code to read and write that format for interchange with other programs if required. Same with IPF etc.

Connecting real drive to WinUAE as DF0 is either fairly easy or extremely complicated depending how accurately you want it emulated. Naturally the answer is "perfectly emulated please", which sounds a bit tricky off the top of my head. Essentially you're trying to connect an emulated machine running in pseudo-time (under a task-switching OS) via several pieces of software and hardware with variable latency to a piece of plastic spinning at 300RPM.
Hm. Inherently tricky, but probably not impossible. I think I'd let that one sit on the back burner for a while.

Joysticks are easy. The CPU has ridiculously programmable I/O pins and can do anything required to read a stick and send it back via USB along with disk data. You could repurpose a regular PC USB joystick controller chip if you like, really then it's a separate project to Cyclone.

Weak bits etc:
I had some thoughts about this (i.e. what they actually are), and I found some Atari ST hackers on a forum who seem to think much the same thing, so maybe we're both right. Basically I kinda think it's most likely to simply be PLL confusion on readback, and juuuust possibly deliberate generation of wonky fluxes by sending too many transitions too close together when writing. See doc.

What people can do to help
Make your own!
Well, I'm waiting on my ARM boards to arrive in the post from the Ukraine right now. I believe they're the right tool for the job but I can't guarantee it of course. If anyone wants to buy one so they can build a Cyclone20 at the same time as I do, please do, that'd be great. (ebay store link in the document) You could also wait a bit until I've had some tangible results probably in week or two; up to you.

I don't expect building it to require anything else that isn't available from your Radio Shack/Tandy/Whatever, but we'll see - maybe $5 of other bits and pieces depending what options you want. Programming the initial firmware into the ARM board may require a $15 "JTAG Wiggler" but I'll let you know on that. There shouldn't even be any unusually fiddly soldering.

If it turns out lots of people are interested we can ask the nice Ukraine person if he'll pre-flash boards with our firmware before he mails them out.
Once the initial ARM flash is done I think we can reprogram them via USB, so we can load different firmware into the device as required.

Helping with software
I'm totally up for people helping with either the PC or ARM software, all we really need to do is make sure we wire the same chip pins to the same disk drive pins so our hardware is compatible, and I guess I'll lead on that one.

So probably nothing to do for a week or two while I get the basics fired up, but once I have, I'll start a sourceforge project and we can all get stuck in.

Dig up old amiga disks
I actually (gasp) don't have an amiga, any amiga disks (I think) or anything much like it. I think I have a low density Mac floppy somewhere. Anyway, I have a couple of PC floppys and that'll do for now. It would definitely be useful if a couple of people with a decent stash of Amiga disks were to build/obtain a prototype Cyclone20. Perhaps when I get the basic circuit done we can hand-make two or three of them and mail them to those who refuse to pick up a soldering iron.

Making PCBs for a real product
Someone with appropriate skillz is welcome to do this and sell them when the time comes. Probably won't be me but I'll put a schematic and pics up and I imagine some other interested community members will make their own in parallel to me.
Other things: This is a homebrew project, hooking up a 1541 disk connector or a C64 cassette deck or (nod to Clive Sinclair) running a nuclear power station should all be straightforward.

Super hardcore version for recovering screwed up disks:
Looking at the floppy drive in my hand, I can frickin _see_ the head pickup read lines... ooh now if those babies had a 20MSPS low-noise ADC on them, you could really have a serious pop at reading bad disks. Would be good to have a drive with double-resolution head stepping too. Actually a floptical drive would probably kick ass at this... aaanyway..

[Toni Wilen]

Originally Posted by RichAplin

Connecting real drive to WinUAE as DF0 is either fairly easy or extremely complicated depending how accurately you want it emulated. Naturally the answer is "perfectly emulated please", which sounds a bit tricky off the top of my head. Essentially you're trying to connect an emulated machine running in pseudo-time (under a task-switching OS) via several pieces of software and hardware with variable latency to a piece of plastic spinning at 300RPM.
Hm. Inherently tricky, but probably not impossible. I think I'd let that one sit on the back burner for a while.

I know but it should work, if the USB hardware stores few bytes (10-50?) in buffer, sends them in one burst (including original sampling time between bytes/pulses/whatever), emulator buffers them internally and "outputs" them to emulated hardware using original timing.

If there is buffer underrun, emulator can simple pause until enough data is available again (everything stops but it is better than disk error..)

No emulator support = I won't be interested

[IFW]

Weak bits can be generated by:
- omitting clock bits and violating recording rules
- generating data that are just at the turning point of the data window boundaries

Omitting clock bits would turn on more agressive gain control in some FDCs. Depending on the implementation they may just output data once a satisfactory level has been reached or simply inject a new bit where it should have been...

[RichAplin]

Originally Posted by Toni Wilen

I know but it should work, if the USB hardware stores few bytes (10-50?) in buffer, sends them in one burst (including original sampling time between bytes/pulses/whatever), emulator buffers them internally and "outputs" them to emulated hardware using original timing.

If there is buffer underrun, emulator can simple pause until enough data is available again (everything stops but it is better than disk error..)

Yes, I agree it can be done especially if you freeze the emulator when you're waiting for stuff to be read/written to disk; I still have a feeling there are more complex issues beyond just buffering the data to the drive though, especially when writing...

For example; you have some software that's sitting polling the CIA in the 'amiga' to see when the index mark comes up, it then writes a track immediately, and as soon as that's written steps to the next track and continues.

What we're doing behind the scenes in our hypothetical WinUAE plugin is continuously polling the Cyclone via USB to get the index sync mark; we'd get a packet over USB (with a timestamp saying 'the index mark went high at xxxxx microseconds') then we replay that into WinUAE.
The emulated code sees this then kicks off a disk write, which winUAE captures and buffers and sends to the drive, along with microsecond-accurate timestamp for when writing started.
Our drive then gets this USB packet, has to wait for the physical index mark to come around again, then wait the right amount of delay, then start writing the track to the real disk (...and not underrun while writing)
...all the while what is the 'amiga' doing? is it frozen while we wait for the track to write (b/c the it thinks it's already written and wants to move the disk heads to the next track already);maybe we are we letting the 'amiga' run ahead of our disk write.. but what about if instead it tries to re-read the track it just wrote to do a verify?.. etc,etc.
I think it's probably all fixable but it doesn't sound easy.

I am guessing if you don't support write it's quite a lot easier.

..anyway, sounds like the sort of thing you're eager to make work! Good thing it'll be open source; be my guest! ;-)

Rich

[jabsy]

Originally Posted by Toni Wilen

No emulator support = I won't be interested

Likewise... I've already got 2 unsupported catweasel IV's. If this works one of them is heading to Ebay, maybe both...

[mr.vince]

I have been thinking about disk reading, error correction and so forth. I would like hear some thoughts on this...

Hoe are we going to detect reading errors? From what I have experienced with Catweasel I might sometimes take 50+ tries to read a track before the data is right. How are we going to "know" that our read is right without checking against e.g. AmigaDOS rules? How are we doing a verify in case of an error that is there for protection.

The Catweasel image tool lets you chose a format, or offers you to detect the format of the disk. Then the tracks are checked against that particular format while reading. Errors are put on a stack and are reread after the rest has been read. The program will continue forever until every sector has been read ok.

I tried tihs with an original copy of "Hostages" which is basically an AmigaDOS disk with a RNC protection track on track 0 head 1. Catweasel did as expected: It read the whole disk then started retrying the error tracks on track 0 head 1.

Looking from the side of software design I would recommend format templates on a plugin basis so new formats can be generated without a rewrite of the whole program. I also found out that in case of Catweasel other companies sent in disks because they wanted to have their special disks for special machines recovered. I guess with our open source approach anyone could design his own input plugin.

I think writing back from some image should be "easier" because in case of e.g. IPF we know what we have and what we want to write.

Any comments?

Best
Chris

[RichAplin]

Heh ok then, I have to admit that really I'm just being picky about the quality of the emulation of the physical drive in all conditions (i.e. things a disk copier might try to do).

If you're not worried about perfectly emulated writing (and I can't see why you would be) then yes we can probably make any protected game load off a real disk into WinUAE.
Caveats:
a) The disk must obviously be readable on a real amiga and not written with wonky head alignment
b) WinUAE has no show-stopping emulation problems with the specific game other than some disk protection
c) Probably.

happy now? ;-)


I actually assumed catweasel did that already - i.e. gives you seamless use of a real disk drive in the emulator? If not it's a bit of an oversight. Still, writing windows drivers for PCI cards doesn't look like a lot of fun so I'm glad to be going USB.

It'll probably work fine, if you get a super-tricky app you might need to put the emulator into some kind of "ultra hardcore" mode, where the emulated CPU is paused here and there to let the world of spinning plastic disks to catch up. Most games however won't notice anything.

Progress
By the way I got bored last night for my ARM board to arrive so today I hacked something together with an (inadequate) Atmega128 chip I had lying around, and I have a proof-of-concept prototype working right now and successfully controlling the drive, stepping, reading tracks, and sampling bitcells. It has a 62.5ns bitcell timing accuracy right now, which doesn't suck but I want better on the end result. Pics etc when I have second. It's not capable of doing much more than analysing a disk (it doesn't have enough ram to buffer the disk data or fast enough serial to get the data off-chip!) but it works pretty well - I read a Mac disk and it's cute to see the variable-density recording.
Yay wires.


^Note this isn't the final CPU chip, I just had it kicking around. This is not the droid you're looking for.


Easy peasy wiring! I think it's actually the same number of wires as the original cyclone.

Workie! Well, reading disks and dumping timing information out via 2MBPS serial connection.

[hit]

just three days from first posting to a prototype. not that bad. keep staying bored

[Photon]

My advice is (I see you Toni and you have started the discussion already, great!):
1) Don't make a driver, make a floppy read/write app
2) Make it the deluxe, 100% reliable, workhorse file<->floppy solution first. Don't add stuff not related to writing floppies in a better way
3) Make it open source and port the app to every OS known to mankind !! (Mainly, the different Windoze flavors I guess...)
4) Make it dirt cheap. Expect Amiga users to want it for < 25€... Impossible of course, me, I'd pay 100€ for a perfect plug-in solution rather than a free PCB layout and buying components for 45€ from 5 different places...

[Smiley]

Wow. Such a lot of progress in such little time! Keep up with it. This is defintely a piece of hardware the Amiga community desperately needs.

Don't get me started on the Catweasel....

I really hope that it will work with WinUAE. I am using a emulated WHDLoad setup but it would be great if I could start using my stockpile of floppies again.

[IFW]

Originally Posted by mr.vince

I have been thinking about disk reading, error correction and so forth. I would like hear some thoughts on this...

Hoe are we going to detect reading errors?

It's really simple as long as you try it with a working application: you don't.
Most programs can detect disk reading errors by using EDCs on the track/sector data and once a read error has been detected they'd retry.
There are programs that don't do that... in that case a read error under emulation would cause exactly what it would with real hardware; crash, malfunction, missing or weird graphics, sound and any other fun effects.

As for imaging: trying to understand the format just being read is a bad idea. As long as you don't know what you read in advance it requires very complex analysation, supporting hundreds of formats - and inevitably you'd still need to correct mistakes done through automatic processing.
Hence a much better way is oversampling the data and reading it a few times and run a powerful analyser at a later stage that gives full control over the data already available... exactly what we do.

This had not been an issue for duplication simply because the formats had already been scripted; therefore they could be matched with the data available on the master - or converted on the fly from a different (like AmigaDOS) format to a custom one.