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

[orange]

this thread is too long.. can someone make a summary? is that C(yclone)20 thing complete, can we have schematics?

what can we use to backup the original games now?

I had tried OWS, MFMwrap and some special version of DMS in past with no luck. is extra hardware on real Amiga necessary even for reading only?

[hit]

Originally Posted by orange

this thread is too long.. can someone make a summary? is that C(yclone)20 thing complete, can we have schematics?

its not useable in the current state. no update since end of last year (software svn repository) to the public - and it all depends on Richard Aplin. the hardware wont change that much, as described here: http://cyclone20.wiki.sourceforge.net/ (links to google docs).
i hope he pops-up once in a while and says something.

[musashi5150]

Originally Posted by orange

is extra hardware on real Amiga necessary even for reading only?

No, the CAPS/SPS dumping tools are proof that no extra hardware is needed for read only.

[gizmomelb]

Originally Posted by musashi5150

No, the CAPS/SPS dumping tools are proof that no extra hardware is needed for read only.

doesn't the CAPS/SPS dumping tools need extra memory?

[Supamax]

Originally Posted by gizmomelb

doesn't the CAPS/SPS dumping tools need extra memory?

Ha ha, well said! The extra memory is indeed some extra hardware .

[musashi5150]

Originally Posted by gizmomelb

doesn't the CAPS/SPS dumping tools need extra memory?

Ah, c'mon!

[demoniac]

Originally Posted by gizmomelb

doesn't the CAPS/SPS dumping tools need extra memory?

Well technically you can do dumps with only a serial null modem cable -- it just takes 30-60 mins per track.

[mr.vince]

Originally Posted by musashi5150

No, the CAPS/SPS dumping tools are proof that no extra hardware is needed for read only.

That is because the floppy "controller" of the Amiga is non-existent in reality. I mean, the software is supposed to be able to READ the protection to verify it's an original. The whole concept of a good disk protection is inventing something that can be read, but not written on that particular piece of hardware.

Cyclone20 is so good because it's, in concept, that simple. All it does is read and write magnetic fluxes. It does not care if some flux combination is right or wrong. It's up to the software to decide about data integrity and authenticy. But Cyclone20 on the other hand is quite "intelligent". Because the speed of drives varies, it is not possible to write an exact copy of a disk made on drive a directly to drive b. Cyclone20 can compress or expand the magetic flux (read: solely timing information) as appropriate by measuring the speed of the drive it is working on. This is quite tricky, but already works well. Put precomping and other neat things on top, and you have the ultimate floppy tool.

Rich is currently in the process of refining C20's firmware, which needed to become faster to deal with HD disks (which have 1us bitcells). This required rewriting the core in assembler. While this seems to work as expected, there is a bug in the USB routines which locks up during transmission from time to time. This is extremely hard and complex to debug (think of a computer that has no keyboard and no monitor, but only a terminal, which locks up, while you want to debug the very same terminal), so just takes time. We all have daytime jobs, and while there are hands to help, this debugging must be made by Rich. He invented it, he knows where to look. It's hard to debug someone else's code.

In regard to the SVN: We had to find out the hard way that it does NOT make ANY sense to release something to the public that is as complex as C20, but only finished for about 15%... Because of this the decision was made not to release anything until it's in a usable state. I also write a piece of documentation for it, so people can get a good start.

Besides, the projects (Cyclone20 & Softpres) have already been presented at the Computerspielemuseum in Berlin, Germany last week. The museum is part of the http://www.keep-project.eu and while the disk reading is only a small piece of the whole project, it's an important piece because this is the door through which all legacy software comes in. I did show the whole cycle of reading a disk on the Amiga with the Softpres capture tool (which works while C20 is not ready yet to do it), analyzed it with the Softpres Analyzer, made an IPF and then wrote it back to disk with Cyclone20. We hope that one day, both technologies (C20 for input / output and Softpres Analyzation as the technology for authenticy checking, integrity verification and long term storage (IPF)) will be used by national libraries, museums, etc. because there is no better alternative we can think of. We really want to make sure, that our legacy and the games and software we liked so much (and still do) are preserved the right way.

So while this project might look it's stalled, much work is going on in the background you simply do not see anywhere. If we'd have someone funding this project, Rich would love to play with it all day long, but until then... we all have to earn money, make a living, support our families and find some time to work on the projects we like so much.

Thanks for waiting.

[gizmomelb]

so with the Cyclone 20 archiving magnetic fluxes - does that mean Rich has invented the fluc capacitor?

OMG! Now where's my DeLorean?


EDIT: on a serious note..

No idea if Rich has a full time/part time or contract work but I'm sure that a paypal account directly for him would be well patronised (not as an incentive, but as a thankyou).

My secret hope is that Rich and Jeff are busy toiling away collaboratively and we'll have the ultimate floppy archiver / SD card floppy image solid state floppy emulator pop it's head out sometime soon

Jeff's done some very nice coding recently and added limited write support to his SD card solid state floppy emulator (not bad for a comparatively 'slow' PIC vs ARM chip) :

26/04/2009: Firmware SD HxCFloppyEmulator v0.0.4.3
-Write support : MFM encoder bug corrected, GAP3 first byte encoding (WD1793)

18/04/2009: Firmware SD HxCFloppyEmulator v0.0.4.2
-Faster write routines
-500kb/s write support (warning alpha version/unstable)

21/03/2009: Firmware SD HxCFloppyEmulator v0.0.4.1
-256bytes sector write support added

15/03/2009: Firmware SD HxCFloppyEmulator v0.0.4.0
-Write support added :
Warning: the only sector format supported by the write feature is 250kbits/S MFM (DD) 512bytes sector. Tested with PC and Atari ST. Should work with any computer using this common format (CPC, ZX SPECTRUM, MSX ,etc).
-Some code optimizations : table driven crc7 generator and faster MFM handler

[Slayer]

Originally Posted by mr.vince

So while this project might look it's stalled, much work is going on in the background you simply do not see anywhere. If we'd have someone funding this project, Rich would love to play with it all day long, but until then... we all have to earn money, make a living, support our families and find some time to work on the projects we like so much.

Thanks for waiting.

Very well written there mr.vince! Very Concise and Insightful. Also very sensible. I do say though, point us to a donate button for Richard and I'm sure I wouldn't be the only one willing to flick him the odd twenty euro or similair...

I'm thinking the great things you can do with this, coupled with classic machines, brought together with some coding with serial cables and alike modified and realised with a little electronics...

that's another reason I collected the hardware too, to solder things together LOL

[mr.vince]

While I am sure that Rich will appreciate the support, we're talking thousands of dollars each month. Maybe you're overestimating the size of the community...

[Slayer]

You're probably right mr.vince

if only people stopped wasting money on there other things!

Please keep us/me informed I'll be one of the first to put my money where my mouth is

[orange]

@musashi5150

but those caps dumping tools seem to be available only to people who have games they miss.
since they have a LOT of games, I can't send them anything interesting so they won't let me download the tools
is there any (equally good) alternative to backuping originals on Amiga?

[hit]

@orange: you can try wwarp ( http://www.whdload.de/whdload/ ) but not sure, if those dumps are useable somehow.
for non-protected disks, you can try adfread 1.1 by T.Willen ( http://eab.abime.net/showthread.php?t=27232 ) - needs two diskdrives on one cable in a wintel-pc - but gives good results. this will create adf images.

Edit: http://ftp.back2roots.org/winuae/adfread-1.1.zip - needs a driver: http://simonowen.com/fdrawcmd/

[Supamax]

Originally Posted by hit

@orange: you can try wwarp ( http://www.whdload.de/whdload/ ) but not sure, if those dumps are useable somehow.
for non-protected disks, you can try adfread 1.1 by T.Willen ( http://eab.abime.net/showthread.php?t=27232 ) - needs two diskdrives on one cable in a wintel-pc - but gives good results. this will create adf images.

@orange:

DISK2FDI is a much better option than adfread. I discussed this with Toni some time ago, and I hadn't time to make more tests and update him about my results (I got a lot of dumping errors. There's a thread about it).
However, I warmly recommend DISK2FDI (unregistered). The BEST for PC (true DOS mode and 2 floppies).

[hit]

Originally Posted by Supamax

@orange:

DISK2FDI is a much better option than adfread.

never tried this, since adfread worked pretty well here, still some bad disks, so i will try your suggestion ( http://www.oldskool.org/disk2fdi/trial.html ).

[Supamax]

Originally Posted by hit

never tried this, since adfread worked pretty well here, still some bad disks, so i will try your suggestion ( http://www.oldskool.org/disk2fdi/trial.html ).

Whichever program you'll use, make 2 dumps of the same floppy and then compare them byte-by-byte with some utility (es. UltraCompare).
If they are 100% equal, you have a good dump.
If they have even only 1 byte different, you need to make another dump and compare it with the previous two in order to see which one is the good one.

But never make only one dump...

[hit]

ah, good point. i had adfread running for many retries on some very bad floppies - 99% completed but never made the full image.
i'll gonna try disk2fdi, maybe it spits out the last bit

[mr.vince]

Originally Posted by orange

@musashi5150

but those caps dumping tools seem to be available only to people who have games they miss.
since they have a LOT of games, I can't send them anything interesting so they won't let me download the tools
is there any (equally good) alternative to backuping originals on Amiga?

You simply have not understood, or just did not want to, what I did write to you in private.

So here we go: You sent your request to SOFTPRES, but all we can offer is the DUMPING tool for reading raw images. If you want CYCLONE20 (which is NO Softpres project) you have to wait like all of us. There is no "they do not want to". What I said was that it does not make any sense to give you our capture tool because you want to make backups. It's like getting a paint program for making music.

Please feel free to contact me in case you want to dump anything of interest for the community. But once again: Softpres can not help you making copies of your disks.

Originally Posted by Supamax

Whichever program you'll use, make 2 dumps of the same floppy and then compare them byte-by-byte with some utility (es. UltraCompare).
If they are 100% equal, you have a good dump.
If they have even only 1 byte different, you need to make another dump and compare it with the previous two in order to see which one is the good one.

But never make only one dump...

While making several dumps is always a good idea, you can not compare dumps. There are many things that will come out different in consecutive revolutions, e.g. weak bits, bad bits a write splices etc. The raw binary will differ in many places.

The Softpres dumping tool does record 5 revolutions of every track so the chance is high we get good dumps. We'd do more, but this could simply fill the ram of the Amiga too quickly.

[Supamax]

Originally Posted by mr.vince

While making several dumps is always a good idea, you can not compare dumps. There are many things that will come out different in consecutive revolutions, e.g. weak bits, bad bits a write splices etc. The raw binary will differ in many places.

The Softpres dumping tool does record 5 revolutions of every track so the chance is high we get good dumps. We'd do more, but this could simply fill the ram of the Amiga too quickly.

No no no, sorry, perhaps I didn't make myself clear: I'm talking about .adf dumps (normal ADFs, not custom/extended) of Amiga non-error-protected disks.
Of course, if the disk has some errors, intentional (for protection) or not (physically ruined floppy), two dumps of it will never be equal.