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

[alexfreed]

Sorry for beeing here: I'm not much of an Amiga person. Instead I have some Apple 2 credentials. See my http://mirrow.com/FPGApple

I have read this thread and I'm very impressed. I want to extend this to Apple formats. Should be an ultimate tool to read all kind of floppies and preserve the data. I also want to add the reverse channel - to a floppy controller. So images stored in the MMC/SD should be readable as virtual disks.

I have even ordered a SAM256 board but it will take a while to arrive. Meanwhile I happen to have an almost identical Olimex board but with a smaller SAM64 chip that only has 16K of RAM. My (Apple) needs are rather limited so maybe I can use this board.

The original blog described storing the track in RAM. The code I have downloaded appears to just stuff a FIFO that is emptied into the USB endpoint. I wonder if anyone ever set a "high water" mark to check how full does the FIFO get?
My calculations are that if the worst case data has a transition every 2 us we need only one byte to count the ticks and so we have 500K per sec - a bit less than half of the USB speed. So it should be possible to dump the data without a huge FIFO. Maybe even use ping-pong buffers? One is filled up while the other feeds the USB.

Any thoughts?

[alexfreed]

Originally Posted by kipper2k

I really don't want to think that the soldering is bad, but i guess thats next on the list to check, anyone any ideas ?

thanks

I guess it's a good time to connect a serial cable and see what the ARM has to say on the debug hotline.

[mr.vince]

Originally Posted by alexfreed

I have even ordered a SAM256 board but it will take a while to arrive. Meanwhile I happen to have an almost identical Olimex board but with a smaller SAM64 chip that only has 16K of RAM. My (Apple) needs are rather limited so maybe I can use this board.

We're currently loading the firmware into RAM, with a 32k window for data. So given the fact that the chip has only 16k, you can not store the firmware (22k). Also the data window will overflow at 16k I assume so this is a no go, even when storing the firmware in flash.

Chris

[mr.vince]

Originally Posted by kipper2k

ARM pin -> Floppy pin
PA0 -> 22 (Write data)
PA9 -> 26 (Track 0)
PA10 -> 14 (Select 0 - and/or to Floppy pin 12 see note)
PA23 -> 10 (Motor 0 - and/or to Floppy pin 16 see note)
PA26 -> 30 (Read data)
[slurp tea]
PA27 -> 18 (Step direction)
PA28 -> 20 (Step)
PA29 -> 32 (Side select)
PA30 -> 8 (Index)
PA31 -> 24 (Write gate)

Here are my pinouts...


8 - PA30
10 - PA23
14 - PA10
18 - PA27
20 - PA28
22 - PA0
24 - PA31
26 - PA9
28 - PA4
30 - PA26
32 - PA29
34 - PA3

ALL ODD PINS TO GROUND

I see you have not soldered floppy pins 12 and 16. Can you please solder them, too? Depending on the cable you are using this might be the cause it is not working. As long as you do not plan extending the work done to two drives (we don't) you will never run into any problem, but can just take any cable that comes along.

You might also want to PM me so I can send you a small fix for the source you are using to compile the firmware. The original one, published on 24h of December, has a small stepping bug regarding the init. This also caused trouble for me, so we should try that to. As Rich said, more recent source will be coming, too.

[RichAplin]

Originally Posted by alexfreed

I happen to have an almost identical Olimex board but with a smaller SAM64 chip that only has 16K of RAM. My (Apple) needs are rather limited so maybe I can use this board.

.. I wonder if anyone ever set a "high water" mark to check how full does the FIFO get?

Heh high water mark measurements were back a few pages ;-)
http://eab.abime.net/showpost.php?p=...&postcount=214

Yes it could be made to work with a much smaller FIFO buffer than the current 32k (although <16k is a bit hairy depending on your PC and how busy it is) and you can compile the code to run from Flash (although then you get minor niggles when developing having to swap between the original bootloader and the new firmware b/c they both want the interrupt vectors and... stuff. all minor fixable niggles). I'd say it's "premature optimisation" unless you're really bored, but I know how it goes when you're waiting for the postman.

[Jeff_HxC2001]

Originally Posted by RichAplin

Nope, I'm using HxC as a front-end tool to decode IPF images (was super easy way to do it, and supports lots of formats already).

Sweet video of Jeff [en francais], interesting is at 2:00..

[ Show youtube player ]

So basically, he's used various generations of hardware to make tethered and standalone disk emulators, and as you see has got it all working pretty damn well (his IPF support will emulate protected disks for example).

We can certainly use the Cyclone20 board in the same way, either tethered to a host PC or as a standalone emulator, it's really just a case of which hardware option you prefer. I

There's no huge point in reinventing the GPL'd wheel so basically the "standalone emulator running off SD card" version of Cyclone20 might as well be a port of Jeff's HxC firmware onto the Olimex board, using his tools and HFE image format and everything, cos he did it pretty well.

Adding floppy emulation support to the Cyclone board when it's plugged into a PC (i.e.talking to the C# app) is easy enough to do - cos it's almost the same thing as writing a disk - so I'll chuck that in when I have a second. The only real frill you could add would be "write support" so the amiga can write back to the emulated floppy... but that's fun for a rainy day.

Hmmmmkay so I have a whole shitload of tidying up the code to do, and a few gross bugs to fix, but I'll upload something (src+binary) in the next few days.

So who's got a working board apart apart from me+MrVince?

here some older video :
USB HxC Floppy Emulator video demo - part 1:
[ Show youtube player ]
USB HxC Floppy Emulator video demo - part 2:
[ Show youtube player ]
SDCARD HxC Floppy Emulator - demonstration :
[ Show youtube player ]
SDCARD HxC Floppy Emulator - Amiga 600 - State of The Art:
[ Show youtube player ]

If you want, i can put the .C20 file writer in the hxc floppy emulator source tree.
and if you are interested by some others computers/file format support (C64,Spectrum...), i can add them !
:-)
Jeff / HxC2001

[flunky]

Which is the latest available software version ?
I am using V11 from SVN tree.

[gizmomelb]

ahh I think we have the equivalent of a retro geek black hole here - it's attracting all of the best and brightest retro preservers in their fields!

(in no order!) RichAplin, Mr. Vince, JeffHxC2001, LuigiDifraia, AlexFreed, Toni and the SPS team etc.

Could this project be the One to Preserve them all? Will it enable all ancient data from round, black orbs of knowledge to be trapped and preserved for eternity for future generations to laugh and mock?

[alexfreed]

Originally Posted by RichAplin

Heh high water mark measurements were back a few pages ;-)
http://eab.abime.net/showpost.php?p=...&postcount=214

Sorry, missed it. Quite a few messages here! Thanks.

Yes it could be made to work with a much smaller FIFO buffer than the current 32k (although <16k is a bit hairy depending on your PC and how busy it is) and you can compile the code to run from Flash (although then you get minor niggles when developing having to swap between the original bootloader and the new firmware b/c they both want the interrupt vectors and... stuff. all minor fixable niggles). I'd say it's "premature optimisation" unless you're really bored, but I know how it goes when you're waiting for the postman.

I did notice the size of the code but I thought removing a few non-essentials like "printf" and most or all of the serial channel code and the bootloader for a good measure (I have JTAG) could do the trick.

[Arnie]

Would anyone be willing to supply me with a working board and software as my soldering skills and conpiling skills are non existant

[IFW]

Hi Arnie and everyone else interested,

We are prototyping hardware, software and firmware at the moment.

Once we have all the results we really want, we'll publish the details.
We'll help people building their own boards as long as they are meant for supporting preservation projects, not just curiosity.

We'll also likely switch our dumping requirements to using this board for any dump submitted to SPS in the future for any platform - which will include the majority of commercial platforms from 80s-90s.

In the meantime there is no point in ordering the hardware or anything else; these boards arrive in a couple of days anyway regardless of where you order them from. We got our boards in like 24 hours I think from an UK Olimex distributor.

So there is no rush, it's done when it's done, but definitely sooner than say Duke Nukem Forever

Cheers,
IFW

[mr.vince]

Originally Posted by RichAplin

Yes it could be made to work with a much smaller FIFO buffer than the current 32k (although <16k is a bit hairy depending on your PC and how busy it is) and you can compile the code to run from Flash (although then you get minor niggles when developing having to swap between the original bootloader and the new firmware b/c they both want the interrupt vectors and... stuff. all minor fixable niggles). I'd say it's "premature optimisation" unless you're really bored, but I know how it goes when you're waiting for the postman.

Originally Posted by alexfreed

I did notice the size of the code but I thought removing a few non-essentials like "printf" and most or all of the serial channel code and the bootloader for a good measure (I have JTAG) could do the trick.

Well I would not want to be without the debug output for the time being. Also I got occasional overflows (with 32k) on an P4 / 2 GHz with 512 MB of RAM and running nothing but a bare bones WinXP. So...

Originally Posted by flunky

Which is the latest available software version ?
I am using V11 from SVN tree.

There is currently no newer source available. We have done some work in several places, especially Rich, but I think there is some more merging / evolving / tidyding involved before there will be a new release. Doing this before christmas has not lead to anyone jumping aboard and I think we all fear that the more people lay hands on it right now, the more could be broken.

Originally Posted by IFW

So there is no rush, it's done when it's done, but definitely sooner than say Duke Nukem Forever

Come get some! I really wonder if that will EVER come out... but the original is still worth playing. Just fire up Dosbox and presto.

[Toni Wilen]

Finally done

(still todo: find power supply or 5v-only floppy drive)

[flunky]

It works.

[Slayer]

Originally Posted by IFW

We are prototyping hardware, software and firmware at the moment.

Once we have all the results we really want, we'll publish the details.

Cheers,
IFW

I can live with this, let me know whats what :-)

[Arnie]

Originally Posted by IFW

So there is no rush, it's done when it's done, but definitely sooner than say Duke Nukem Forever

Cheers,
IFW

LOL

[LuigiDifraia]

None of the drives I bought has come in yet so that I haven't finalized the cable routing with some soldering.

I also had a go with the autorouting feature of the CAD I use (eagle) to see how it would look like in a custom board and... well, it was unable to autoroute with the default settings

Cheers,

Luigi.

[Supamax]

@ Luigi

Very nice and intelligent cabling indeed!

[gizmomelb]

Originally Posted by kipper2k

I really don't want to think that the soldering is bad, but i guess thats next on the list to check, anyone any ideas ?... update, i checked wiring it all looks good, i even tried the straight/swap cable and shorting 12 >14 and 10 >16 to see if that helps... sigh!

heya, not trying to be a smartar5e or anything but have you checked your wiring against some of the recent pics on here? to compare? it's very easy to lose count and accidentally wire up a wrong pin.

otherwise I've found even just a quick continuity test can sometimes detect dodgy soldering.

EDIT: also the more I'm waiting for my birthday to arrive the more I'm thinking I'll just buy this cheaper board from ebay and make my own daughter PCB with the SD slot (and maybe the buttons and LEDs - if they're going to be used at all - which I suspect they might for the floppy emulator rather than the USB floppy reader).

also theorising forward to the standalone floppy emulator - if there's been a 32KB FIFO buffer set aside in the ARM RAM - shouldn't that more than enough to support emulated disk writes? (on the Amiga it's almost 3 tracks - are there any games anyone can think of which may write out that much data when saving? just in case the buffer fills too fast?)

Could tracks/sectors be written back to the C20 disk image by using an LBA offset for where the C20 disk image is on the SD card? (the C20 image may need some padding out to fit nicely on 2's complement boundaries to make LBA accessing / writing easier / quicker).

Otherwise I guess possible alternatives for writable emulated floppy images would be:

1) adding on at least 4MB RAM and interfacing it to the ARM so that the C20 image is held in RAM and then writes are made to that image. When the user presses a button (or at regular intervals) the RAM image is copied to the SD card so that high scores etc. are saved permanently.

2) the ARM's buffer is copied across to another MCU which either has enough on-board RAM to build a floppy image (as described in point 1) or which has a bigger allocated buffer region along with enough cpu horsepower to LBA write data to the SD card.

3) any data written to the floppy drive is written to a new file which essentially acts as a DIFF to the original disk image the next time it is loaded.

eg: Great Giana Sisters appears to write to track 151 as discussed in this thread. So giana.c20 image is loaded for the first time, there's no giani.sav file so it doesn't bother applying the diff.

the user plays the game, gets a hi-score and wants to 'write' the hi-score back to the disk - so the ARM detects the disk write and creates a .SAV file with the same name as the loaded image. The block is written into the .SAV file and closed. The data written to the .SAV file would include the block(s) number and the actual data. Possibly a table / list might be needed in the ARM's RAM so it knows which blocks / sectors have been modified - that way when the ARM goes to read a specific sector / block it knows to look in the .SAV file instead of the original C20 image. This list is also saved as part of the .SAV format (or could be saved as a seperate file if too difficult / slow to append to the .SAV file).

Likewise, if the computer is turned off and the user wants to play the game again at some stage in the future the giania.c20 image is loaded and it checks if there's a giana.sav - there is, so it loads the pointer list of which tracks have been modified into the ARM's RAM. If one of the tracks in the list is requested by the host computer to be loaded then the data is loaded from the .SAV file instead of the original .C20 image.


Hope that makes sense?

Anyone have any comments / ideas to add - I'm just throwing out some theories to see what the electronics and code gurus think.

[kipper2k]

Originally Posted by gizmomelb

heya, not trying to be a smartar5e or anything but have you checked your wiring against some of the recent pics on here? to compare? it's very easy to lose count and accidentally wire up a wrong pin.

otherwise I've found even just a quick continuity test can sometimes detect dodgy soldering.

Hi.

Soldering is perfect, i even trashed it all and redone it and checked it again... i think i'll go blind if i look at it any more, i even traced it back to the chip to see if a trace was bad (continuity check). Pretty soon i'll be chucking it at the next Polar Bear that walks by lol. You dont need to run fast, you just need to run faster than someone else

i tried it on 2 comps and a laptop and still no joy, i'm resigned to hoping an update will fix it.

I think i even lost my silver medal for my wiring in the Red to Blue category