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

[IFW]

The thing with running images from IPFs or converting from IPFs (like installing under whdload etc) is that only known good images exist and read errors do not occur.
Therefore even games without (seemingly or for real) any EDC checks can work flawlessly regarding read defects.

[RichAplin]

Originally Posted by hit

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

Yes boredom is a constant peril;

[ Show youtube player ]

With my friend Lars, (also prone to boredom)
[ Show youtube player ]

Rich.

[hit]

pretty cool, much better than those winamp visuals

[mr.vince]

Originally Posted by IFW

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.

Sounds good. Is there anything you want to or can share with us? I mean, we're going for the hardware... do we have to reinvent the imaging process or is there code or more concept stuff we can get from you?

Best,
Chris

[RichAplin]

If anyone's super-keen they can order some parts now.
The only thing most people will need is the ARM board, a cheap parallel-port ARM JTAG programmer, and a suitable 34-pin male connector (or just some 0.1" headers like I used) to plug the floppy drive cable into. Total is probably $100 of parts.

Cheapskates
It's probably possible to use a cheaper CPU board (alas the RAM problem means we can't use a $15 pirate-TV card, which I would love because of the irony)
http://cgi.ebay.com/ws/eBayISAPI.dll...m=120341303051
...Is the most incredible bargain.

The issue with this chip (ATMEGA256) is that you need a very high speed external TTL serial-to-USB converter in order to get the data in and out quick enough (not enough on-chip ram to buffer much). That costs you an extra $20 or more. I have such an converter that's sitting here running at 2MBPS (surprisingly), but that's pretty borderline, especially as the Atmel isn't really fast enough to do much clever data packing/unpacking on the fly.

The Atmel works great driving the floppy signals (which are all 5v, open collector) I'm not quite so sure that the ARM (which is 3.3v) will do it without a buffer chip or some resistors, but that's very minor stuff.

I expect I'll 'deliver' a test app (written in C#, with source) that talks to the board and can reliably read and write disk tracks in the rawest form possible* and will maybe draw some pretty pictures of the disk data. The board firmware will just be some C source (and binary image), and we'll have it set up so you can reflash it as easily with the test app.

(*ok not quite true, reading the disk head with high-speed analog converter would be the awesome-est, but you only need that for bad disk recovery and it wouldn't be quite such an easy DIY project.)

We'll also have a look at WinUAE real time emulation. If someone knows or wants to get knowledgable about that project (i.e. build the source code) then go for it please.

Beyond that, i.e. actually converting the raw disk data into usable disk images (i.e. providing Amigados/MSDOS/Mac/etc sector read/write and hence file system) is all pretty well-trodden ground by several parties ; emulator authors, the SPS and Jens at Catweasel.

My coding style is fast'n'loose and my attention span short, so I'm probably the best person to kick this off, provide sample code and how-to's, and hand the writing of useful applications over to the community.
I can see a "do it all" app growing that supports reading and writing disks in whatever wierd formats people want to add.

It's worth bearing in mind that it has plenty of use beyond Amiga disks (as Catweasel does) so open-src'ing it is most likely to add support for extra formats and useful functionality.

Agree with Mr Vince - Perhaps the SPS people would like to contribute their code?

Anyway people are welcome to buy an ARM board + JTAG programmer now, or you can wait till mine turns up (next week hopefully) to be sure it's the right thing.

Also I think it should have frickin' laser beams coming out of it. That's next on my list after writing long tracks.

[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

Also it appears that CPU has a Flash-over-USB 'test' mode, which means no need to buy a programmer. Sweet.

I suspect that will end up being the 'production' board.
Rich

[IFW]

I could create the dumping/transfer etc sw for it - that would ensure that it will have all the data needed.
We'd have to replicate Trace speeds: freely adjustable sampling/writing cellrate 1000 to 4000 ns (ie 1 to 4 microsecs) at 50 ns cell rate adjustments.
It is possible to write below 1000ns with a Trace, but it cannot read such data back. (ie no verify)
If all that can be done with this board... I am on board

[IFW]

So... what I need exactly - and this has not been the first time to say it.
To be able to sample the read line at exactly 50ns intervals.
Once exactly that data is available in a buffer - I'll take care of the rest I must be able to sample the index line state at the same time or be able to tell at exactly where the index signal was high in the buffer.
The buffer area must be large enough to be capable of holding at least two consecutive revolutions worth of data. (ideally 3, 2 can be worked around)
As for writing: a single buffer, plus the ability to start writing at the exact clock cycle (given in the minimum of 50ns stepping) counted from the leading edge of the index signal and set the hardware to stop writing at an exact clock cycle and/or index signal.

[RichAplin]

Sure, those numbers are not a problem - you will be able to write anything you want with 41ns resolution (or better, TBC).

As for reading you effectively just get time stamped flux transitions (again 24Mhz or higher sampling rate) and a very accurately measured (for what it's worth) index hole signal.

I specifically want to be able to stretch a track of a specified number of bits length to fit exaaaaactly onto a destination disk track (as nearly as the drive erase electronics and disk speed wobble will allow). This involves diffusing the error over the track length, and the lower your timer granularity the more you introduce noticable jitter in the written bits. Anyway, blah blah.

There isn't enough ram on chip to store an entire track at 8-bit time sample resolution, but it has plenty of oomph for simple on-the-fly data packing and also can stream in+out over USB while running (assuming we keep the master PLL at a multiple of 48Mhz; this gives us the 41.6ns sampling rate - it's just about possible we can run the chip overclocked at 96Mhz and get 20ns sample cells while keeping USB going at the same time)

Thanks for the help! I expect it'll save a lot of time and make it all the fun-ner.
Rich.

[Interceptor]

so this (really rather cool) thing will allow us to read C64/Apple ][ GCR disks? and connect 3" amstrad drives etc?

[IFW]

We need 20 read signal samples per 1 us or 20Mbps. A 300RPM drive sports 5 revolutions per sec. Given that I'd need at least two revolutions worth of data the buffer must be 20/5*2=8Mb ie 1MB buffer is required.
Alternatives:
- very quick transfer to host from a ring buffer. Buffer sync problems should be detected and if that happens (ideally, not very often...) the dumping process on that track thus the transfer of data gets restarted.
- count the read signal state in 50ns steps and store the result in the buffer. The state should be stored with the counter. Reason: counter overflow can happen so assuming signal state is a bad idea.

ie the buffer could contain something like this for a byte:
1 bit with read line state
1 bit index signal
6 bit counter value

8 bits if purely used for sampling would have given 8*50ns worth of data ie 400ns.
If we expect the data usually to be within reasonable timing boundaries we could say that 1us worth of data would be more common than anything below that. So we'd have a 6 bit counter ie 2^6= 64 counter values per state byte. That means upto 64*50ns per byte 3200ns. Note that there is no guarantee that a single signal fits into this; it must continue in the next state byte if it takes longer.
That is an 1:8 compression ratio in the buffer if we are lucky enough, but saying that it should average out as 1:4 should be fair enough.
ie if the hw is fast enough to do the kind of processing needed for storing this data during the sampling phase 256KB RAM can be enough.
Without any magic/hope involved, 1MB would work.

[IFW]

I thought Rich was asleep in SF at this time 3:30 am?

Rich: Sounds good! I'd be very interested for sure. See my last post about compression or transfer from ring buffer stuff.

Inty: YES, including read/write. Connecting any drives (actually just driving signals connected) is something that driver sw can take care of, I'll leave that for Rich

[IFW]

As for having 20ns cell rate instead of 50ns - I sure wouldn't complain

[mr.vince]

Sounds sweet. I just see 64K onboard with this chip...

Although I assume that compression will work at a factor ofd 1:4 or at least 1:2, I think it could help to have enough ram right on the board, especially for writing back. Getting 1 meg of ram should not be to expensive, should it? I am just curious what kind of RAM to connect where.

Concerning overclocking... we'd have to run some test cycles. The chip will only be on for a specified amount of time, the amount of time it takes to read or write a disk. But even if the temperature is withing an acceptable range, what do we do if someone starts a copy party? :-) Besides temperature... will the built in ram be fast enough? I mean, it's a one chip design, so I assume we should not be getting any timing problems, because the whole thing is running at a higher speed, right?

Chris

[IFW]

Hi Chris,

As for dumping we either need plenty of ram, or have a ring buffer/double buffer or similar approach where data prefetching starts, but as soon as it is possible the transfer of the data towards the host (PC) starts as well in parallel, so there is enough buffer space left for most of the time. The firmware on the board however must be able to detect when it would write to a buffer area not yet transferred, and stop and restart the process.
Unless you heavily multitask on your PC normally this panic/restart process wouldn't have to happen very often, but given the non real-time nature of most OSes, it is better be safe than sorry.

For writing again a large buffer would make it extremely simple, but just starting the data transfer from the host and pushing the data as soon as buffer space is available should work most of the time. Again, there are no guarantees that the host could always keep up, so safeguards (panic... restart writing) must be implemented against a possible buffer underrun.

Cheers,
IFW

[IFW]

Concerning ram speed: anything that operates safely witihin the expected operating freuqency/data rate should be fine. Ideally we'd have enough ram on-board, but I could also imagine driving external memory.

I can also propose to use this device plugged directly into the hardware as an FDD replacement as an added bonus, directly replaying the images from your host.

Or even inerfacing to some other USB device and say store your entire disk based collection on a dirt cheap (these days anyway...) 16GB flash.
Imo that would make more sense;
- no need to write
- no need to get hold of disks
- more fun
- very helpful for quickly checking emulation vs real hardware without ever writing a disk (I am not just talking about Amiga, but tons of other systems)
- very fast turn around time to those who'd still want to develop some disk based demo/game for nostalgia's sake

But first things first; let's get a hardware that would work according to the proposed/expected specs and flexibility. We can always extend on functionality later.

[mr.vince]

Its funny that you mention the floppy emulator. That was my first idea when I though about playing on real silicon. But this won't help reading original disks, so I gave that hardware a lower ranking on my "things I always wanted to get involved with" list.

Apparently, there already is a thingie doing this:
http://eab.abime.net/showthread.php?t=34444

But obviously this is only for use with a) a real computer feeding the data or b) an sd card plus (beware, assumption) it will not work with IPFs from sd card as the dynlib for IPFs is not open source and will not run on the FPGA.

Just before we start whining: Rich - concerning the hardware we're going to make is powerful enough (looking at the specs it should be), could this concept be integrated lateron?

Gee, this is so exciting. I guess I am going to buy a second A500 off eBay and I really would like to turn on my soldering iron just *right now*.

Best,
Chris

[Eclipse]

This will copy virtually 1:1? And copy back IPF images?

[RichAplin]

Hiya,

Eclipse: That's the plan. And you get to make it yourself (so a nice glow of pride) and you give an old washed up PC floppy drive a new lease of life.

Floppy emulator; sure. Can't see any problems with that. The guy who did the Amiga-on-an-FPGA did such a thing (reading data off SD card) so he could load disks. The "deluxe" PCB I suggested has an SD slot so it would be easy enough to do. There are other ARM boards around with LCD/OLED displays and buttons so you could make it all standalone; it really just depends how much one wants to fiddle with electronic gadgets; it's all pretty easy nowadays I have to say. ;-)

The RAM issue is up in the air ; yes you can hook external RAM onto this CPU (although it's tedious number of wires to solder) and the more deluxe of the proposed development boards has an SD card slot so there is easy, infinite storage right there. (Using an SD card as a track buffer is not a brilliant idea for a couple of reasons but might be made to work in a pinch with a fast enough SD card).

I am currently assuming that it can be made to work with on-the-fly streaming of data over USB, which looking at the numbers should I think work ok.
If the PC has some kind of fit and fails to poll the USB bus frequently enough you'd get a buffer overrun in the Cyclone but it's easily detected and you'd just reread the track. It's not acceptable for this to happen very often of course.

There aren't lots of cheap SoCs with more than 64k RAM because they tend to balance it out with other things (more Flash generally).
However on-chip ram is also very fast; if we add off-chip ram we add much construction complexity (or we just upgrade the board to the $150-$200 level and get one with gobs of SDRAM etc. There are a number of boards with ARM11's at 500Mhz and hundreds of megs of ram (& I have a couple in the mail for another job) but what's the fun in that? ;-)

Using a cheap wireless router (by far the best $/MIPS ratio of any readily available boards) was something I considered but there's multiple problems with making something easily DIY-able by people, and a chronic lack of public chip-register documentation on the (often Broadcom) SoCs they use, the SoCs are always BGA parts which means if a pin isn't routed on the PCB you're screwed, etc,etc. You have to do a lot of physical hacking on those things to add suitable I/O's, basically.

RAM usage
Incidentally, you don't need 1MB per track because the sampling doesn't quite work like that; the hardware timer on the chip is set up to be edge-sensitive, so you get an interrupt when the edge changes and you just grab the hardware timer value which tells you the exact pulse interval. Writing is the exact reverse (you have output compare pins that automatically change state when hardware timer rolls over), or optionally you can live the high life and use a hardware shift register to dump your bits out for you. Luxury!
These chips are designed for exactly this kind of thing, so it's all set up very nicely; a transition on a capture input pin causes the CPU to make an instant shadow copy of the current timer register, which you then go and read; there's almost no latency and no sampling jitter at all.

So yes, you're just storing one value per transition, not per sampling cell.
On the mac disk I'm looking at right now I see 87,344 '1' bits on track 0.
This depends on the data density and the actual data itself, the theoretical max is around 110k transitions.

If we stored one byte per transition (which would be fine) we're talking more than our available 64K, but not by a huge or impossible amount. Making it work will be the sort of minor late-night challenge that back in the day we used to call fun. ;-)

Thing is, the cyclone firmware itself will not be whole lot of code; we're just using it as a really accurate timing and playback device. as long as the device uses the same USB protocol (easy enough) people can make a variety of devices.

If someone wants to make one with 2MB of RAM that ends up reading/writing disks faster than one with 64K ram because it can buffer more, great; the PC-side of it will be open-src so you can just detect your new hardware type and it should only require minor tweaks to support.

I expect the one-chip 64k RAM version to work fine and I prefer to start with something that anyone can make with less than 32 wires to solder, no smaller than 0.1" pitch.

Regardless of RAM, all models will required to shoot frickin' laser beams and there will be I/O pins dedicated to the task and WinUAE support (via new emulated Agnus register; FRKNLASR )

[alexh]

Originally Posted by RichAplin

Floppy emulator; sure. Can't see any problems with that. The guy who did the Amiga-on-an-FPGA did such a thing (reading data off SD card) so he could load disks.

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.

Originally Posted by RichAplin

There aren't lots of cheap SoCs with more than 64k RAM because they tend to balance it out with other things (more Flash generally).
However on-chip ram is also very fast; if we add off-chip ram we add much construction complexity (or we just upgrade the board to the $150-$200 level and get one with gobs of SDRAM etc.

If you use external SRAM the speed could be comparable. Perhaps not 100's of MHz.

Originally Posted by RichAplin

There are a number of boards with ARM11's at 500Mhz and hundreds of megs of ram (& I have a couple in the mail for another job) but what's the fun in that? ;-)

I could let you have a few trays of OX810's (400MHz ARM9 + DDR SDRAM) but they are BGA so not that useful for homebrew PCB's. I could probably stump up to 2-3 devkits if Rich & co. are interested. Perhaps a little overkill for this project? Hardware PWM's with RAMP function built into each GPIO

Full documentation of all HW available of course.