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

[RichAplin]

Originally Posted by alexh

Would MiniMig have anything close to a floppy emulator? Because you have both ends of the system wouldn't he have simplified the inner workings of the Amiga FDC and how it is coupled to the SD card? I don't think the RTL which makes up MiniMig could be wired up to a floppy disk drive and function with minor tweaks, I imagine it would be a re-write. But I could be wrong.

Yes Minimig has a floppy emulator implemented on an external PIC CPU, it looks like you stick SD cards in one side with WinUAE images on and MFM comes out the other. Straightforward - especially compared to the FPGA stuff.
The only tweak comes with the amount of RAM you have available on chip and the timer precision. Most small microcontrollers (lower than ARM SoCs) usually don't have PLL clock multipliers and are designed to use teeny power and be cheap rather than wind up fast. Also 8 bit MCUs are just tediously inefficient in many ways compared to arm; writing some assembler for my Atmega board here reminds me of the Amstrad days. Do you remember how tedious it is to add one to a 32 bit number with only 8-bit registers? ;-)

ARMs rule in general, but ARM SoCs perform particularly well b/c they wind up to mad clock speeds via the aftorementioned PLL, have proper 32-bit registers, and usually have 32-bit single-cycle SRAM all on chip. They have a chaming ability to overclock (purely in software- yay) because nothing fast ever leaves the chip itself. In our case (no peripherals except USB) I'm hopeful we can run it at 96Mhz and it probably won't even get perceptably warm to the touch.

Mainly though, they're cheap and extremely easy to wire up. You could probably even do this whole shebang on a single-sided PCB with one chip, two connectors (usb+floppy), a couple of decoupling caps and a crystal if you were sneaky with the routing.


Oh yes one final thought re floppy emulator; errrrm yes I think we can make cyclone20 work seamlessly as both drive controller and emulated drive. Potentially I think everything can be done in software (just changing direction of a few of the lines) although actually you'd probably want to swap the read and write lines (two wires) over when pretending to be a drive as those two IO ports have Special Powers.

[Toni Wilen]

Originally Posted by RichAplin

Oh the Ukraine guy sells a cheaper ARM board without the bits we don't need but the same CPU (AT91S256) for $45 with free shipping:
http://www.mcuboards.ecrater.com/pro...hp?pid=2024153

Looks nice, I am ready to order one (or one of those more expensive versions that include SD slot, thinking about floppy emulator mode..)

The RAM issue is up in the air ; yes you can hook external RAM onto this CPU

Please, no soldering of 100s of SMD pins or building my own PCB

data "compression"

Perhaps encoding method that stores most common case ("standard" 1, 2 and 3 "length unit flux changes" +-15%) using less bits (like 4 or 5) and more bits for special cases like very short or long flux changes (for example max value = lenght continues in next value)

[RichAplin]

Originally Posted by Toni Wilen

Perhaps encoding method that stores most common case ("standard" 1, 2 and 3 "length unit flux changes" +-15%) using less bits (like 4 or 5) and more bits for special cases like very short or long flux changes (for example max value = lenght continues in next value)

Yes, something like that will do the trick I imagine.

Anyway, joy! I was just rummaging around in my nostalgia box and lo! An original A500 workbench disk! ;-) I _knew_ I kept that around for some reason.

Better yet, it appears that I didn't reformat it for a PC in the intervening two decades because running with my prototype board as seen in previous pics it looks like it has lovely clean Trace-duplicator-style data bits on it.
Yay amiga disk!
Ok maybe I'll go on the hunt for some 4489's.. I bet there's some on there somewhere... ;-)

I wrote a bit of C# code today to draw graphs of bitcell distributions. It's... well... it's an acquired taste. Don't use this video to try and get the wife interested in your hobby...
[ Show youtube player ]

[mr.vince]

I like this video. ;-)

[hit]

i'd say too, this isnt that boring at all. looks like some real progress.

[Eclipse]

Originally Posted by RichAplin

Yes, something like that will do the trick I imagine.

Anyway, joy! I was just rummaging around in my nostalgia box and lo! An original A500 workbench disk! ;-) I _knew_ I kept that around for some reason.

Better yet, it appears that I didn't reformat it for a PC in the intervening two decades because running with my prototype board as seen in previous pics it looks like it has lovely clean Trace-duplicator-style data bits on it.
Yay amiga disk!
Ok maybe I'll go on the hunt for some 4489's.. I bet there's some on there somewhere... ;-)

I wrote a bit of C# code today to draw graphs of bitcell distributions. It's... well... it's an acquired taste. Don't use this video to try and get the wife interested in your hobby...
[ Show youtube player ]

You need a real original game with the copy protection intact really for a thorough test.
Maybe someone could donate one

[mr.vince]

We're already collecting disk to test. I am coordinating the collection for Germany, but anyone from Europe or even elsewhere is invited to send something in. Just plain formatted disks will help (to differentiate between different models), but also copies made with the Cyclone + hardware dongle on a real Amiga + ADFs copied to disk.

Please PM me if you want to help.

Thanks
Chris

[Eclipse]

Will you not have to buffer the data if you want to read HD disks? The Amiga reads it at the same rate of DD disks hence the Amiga HD drives spinning at 150RPM too.

[RichAplin]

Hey joy, I'm an idiot.
My math was wrong (I thought it was odd) and the 64k RAM will be just fine (at least for normal density disks);
Ok so the only legal combinations of bits off a disk are;
"[1]01" - 2 x 2us = 4us interval
"[1]001" 6us interval
"[1]0001" 8us interval
And this is what we see in the video I put up; three distinct peaks, corresponding to those combinations.

Mkay so if the track is 200,000us long, and our bits as shown above are 2us apart, we have 100,000 bits. Let's say 110k to account for long tracks.
If every bit pair is "[1]01" we'll have one transition per two bits, so 55k transitions, so 55kbytes. That's the absolutely worst case (and of course a track like that compresses well)
Other cases get progressively better of course (1:3, 1:4 etc). So, the RAM thing should be no problem with 64k, (we'd only have to get jiggy if we're reading/writing high density disks, and even then only if we're in 'raw' mode (i.e. sending one byte per transition))

Yay!

Eclipse: Yes we would, but we can do the buffering on the PC side where life is easy.

Does anybody care about amiga HD disks? I doubt anyone did any copy protection on them anyway(!), and we'll be able to read+write known-format ones fine. (with a known format you just decode to MFM bits instead of storing each bit timing, so less data, a track will fit in RAM)

[dlfrsilver]

Hey Rich, one question, since you know well about making disk protection, we have actually 4 games from Psygnosis using an unknown format.
These games are Obitus, Nitro, armour geddon, don't remember the last one.

I personally think that since the amiga support GCR reading in hardware, this could be
the answer. The GCR format allows a way way bigger disk format, could you have a look
and check them or confirm what kind of format it is ?

[RichAplin]

The SPS guys will know what it is (assuming they have the image), so perhaps they'd like to comment?
BTW using anything other than MFM is I think very unlikely.
Rich.

Originally Posted by dlfrsilver

Hey Rich, one question, since you know well about making disk protection, we have actually 4 games from Psygnosis using an unknown format.
These games are Obitus, Nitro, armour geddon, don't remember the last one.

I personally think that since the amiga support GCR reading in hardware, this could be
the answer. The GCR format allows a way way bigger disk format, could you have a look
and check them or confirm what kind of format it is ?

[RichAplin]

Heh so I got MFM decoding working. Look what I found on my test disk... not seen this in a while... ;-)

echo "A500/A2000 Workbench disk. Release 1.2 version 33.50*N"
echo "sample Startup-Sequence for use with a Hard Disk with Workbench installed"
BindDrivers
IF EXISTS sys:system
path sys:system add
ENDIF
IF EXISTS sys:utilities
path sys:utilities add
ENDIF
SetMap usa1

dir ram:
path ram: add

addbuffers df0: 20

failat 25
assign >NIL: dh0:
IF FAIL
echo "Transfering control to DH0:*N"
path reset
assign SYS: dh0:
if exists: dh0:c
assign C: SYS:c
endif
if exists: dh0:l
assign L:


yay disk reading! Next, writing. and long tracks. and stuff. Oh, and my real frickin ARM board, this Atmel is cute but wimpy.

[mr.vince]

Well, I'd call that a boring startup-sequence... I just don't remember well, but I think you should take a look at that one from Double Dragon II. *sfg* Sorry, could not resist.

Well, congrats. Looks like this thing is coming together. Can't await the board arriving here.

Best,
Chris

PS: Sorry for any typos. My 2 year old son just *likes* hitting keys.

[hit]

Originally Posted by RichAplin

Heh so I got MFM decoding working. Look what I found on my test disk... not seen this in a while... ;-)
...
yay disk reading! Next, writing. and long tracks. and stuff. Oh, and my real frickin ARM board, this Atmel is cute but wimpy.

thats means, you were able to dump a whole amiga disk, and decode/access its contents already? what kind of format is the raw dump (well, i'm obviosly missing some technical knowledge...)

[chiark]

Good grief, I can't believe the progress you've made.

Seriously, congratulations - that's a fantastic step!

[IFW]

Originally Posted by RichAplin

The SPS guys will know what it is (assuming they have the image), so perhaps they'd like to comment?
BTW using anything other than MFM is I think very unlikely.
Rich.

It's very well known what it is.
Just for 4 games it's not worth supporting a new physical encoder as well as decoder.
Saved for a very rainy day.

http://www.softpres.org/wip:2003-04-04?s=5
See "Psygnosis Recording Format"

[IFW]

You should have er... about 111200 bits for a long track that is still readable on an Amiga.

[gizmomelb]

just for interests sake - this guy has been working on a USB Amiga floppy drive adapter for the past coulple of years, his notes and java code is quite an interesting read at least.

http://www.techtravels.org/amiga/amigablog/?cat=2

[RichAplin]

Originally Posted by hit

thats means, you were able to dump a whole amiga disk, and decode/access its contents already? what kind of format is the raw dump (well, i'm obviosly missing some technical knowledge...)

Long answer:
If you saw the legendarily boring youtube video, what was being displayed was the temporary Atmel chip prototype measuring the bit timings off a Workbench disk. I have the atmel connected to a windows app via a USB-to-serial cable.
This particulary RS232 serial connection I have will only reliably run at 1mbps (heh, 'only'), so it's not fast enough to send a whole 8-bit time measurement for every bit transition on the disk, which is the crazy, insanely perfect deluxe way to do it. This temporary CPU is only barely fast enough also to read and process the measurements.

However, it works, so I did the 'crappy' option as a hack and instead of sending the precise measurement of each bit transition back to the PC (as we intend to do on the USB version) it just approximates the timing into two bits (00='101', 01='1001', 10='10001' and 11='WTF?' for bad bits) and sends that instead. This lowers the data rate enough that you can spit it out over 1mbps serial - remember the crappychip doesn't have enough ram for a useful buffer, it has to go out 'live' - so that's what it does.
My windows app grabs the data, and about 150 lines of c# code is enough to find the sync marks and decode the MFM into real sector data. I dumped the whole disk's worth of 512-byte sectors to a file, and scrolled through it with a text editor for a laugh. What I pasted above was one of the more obvious bits of random text i found in the raw disk image - something that looks like a hard disk startup-sequence (or at least one sector of it).

Decoding Amigados sectors from MFM is very straightforward, and lo, out pops the disk data. Reconstructing it into a navigable/readable file system is a bit more work and is probably a good project for someone else.


Short answer:
Yes.

[RichAplin]

BTW, the SPS has done a lot of good work IMHO;
I heard there was interest in 'watermarking' disks written with a modern device (e.g. cyclone20) so that SPS and other software archeologists would be able to readily detect them and not bother rescanning them or whatever.

I think that's a good idea - with the tools we have now we can easily (I think) modulate the track timing in such a way that provably no old hardware can detect it, yet a machine capable of measuring precise (e.g. 50ns) shifts would know it wasn't an original.

This would also be a test built into the cyclone software, and no personally identifable information would be in the mark - it might simply be a light that comes on in Cyclone. "Is this a 1989 original, or is it a recent re-write?" Yes/No.

No DRM is intended, I think it's respectful to software archaeologists and perhaps to deter casual forgery, e.g. people selling fake disks on ebay.
The latter presumes that (a) Original copies of floppy disk games will become desirable items beyond nostalgic 30-somethings, and (b) forgers won't be able to take out the watermarking functions from the (open source) ARM code. ;-)

Anyway, I like the archaeology concept, it makes all this stuff sound more Indiana Jones.