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

[IFW]

Unfortunately, we only have 64kB ram on the entire board.
That is shared between your code, data (which of course means your buffers as well...) and stack.
If you run code from the flash, the execution time can become much slower - not very healthy when you don't really have any cycles to spare.
So writing 128kB at once to a card is very unlikely... not to mention you don't want to move the card between your machine and the board all the time, it's just not convenient.

Adding ram or using a board with fast ram access is the way to go, but we'll see.

[gizmomelb]

how about writing to RAM that supports SPI (using it as a either a buffer or a data store)? Adding the hardware to the ARM development board should be easy enough, but it depends whether or not the SPI and the RAM is fast enough to store to.

[Loedown]

Originally Posted by IFW

Unfortunately, we only have 64kB ram on the entire board.
That is shared between your code, data (which of course means your buffers as well...) and stack.
If you run code from the flash, the execution time can become much slower - not very healthy when you don't really have any cycles to spare.
So writing 128kB at once to a card is very unlikely... not to mention you don't want to move the card between your machine and the board all the time, it's just not convenient.

Adding ram or using a board with fast ram access is the way to go, but we'll see.

I would have thought that writing data back to the interface could easily be done on a track by track basis, with an option to quit after a certain amount of retries, to write the track 'as is'

With the cost of RAM being absolutely neglible and the fact that you're already using a microcontroller, why the hell would you worry about the RAM inbuilt in the micro, use a dedicated 41256 or whatever is more current, even stick a SIMM slot on the board, naturally it increases the cost somewhat, but be assured, people will pay for a *completely* working solution?

Speed isn't the issue here, no one is going to care if it takes a few minutes per disk, as long as it works, so if you perceive the problem to be data transfer, as long as it doesn't take years to transfer files to / from, who cares?

Paul

[mr.vince]

Speed is a problem, looking at this from the preservation point of view. When being at conventions or similar, it would be neat to have something fast.

I agree that RAM would help, maybe just a bigger revision of the ATMEL with RAM built in would be nice. The main thing why this CPU was chosen is that Rich wanted to proove it can be done with the smaller one.

We're also currently looking at a difference bitweens board revisions, where the latest Olimex is fine, while the Ukraian one has a "major" flaw which disables the option to reenumerate the board. If anyone already has a true blueprint that one, I'd love to see it.

[hitm4n]

OMFG. I just spent 2 hours reading this thread, excited about the prospect of an easy adf dump tool, getting more and more excited as the thread developed and with all the help and positivity. I felt like it was getting close a couple pages back, around xmas, and now i'm so disappointed... sigh...

[LuigiDifraia]

Originally Posted by IFW

Unfortunately, we only have 64kB ram on the entire board.
That is shared between your code, data (which of course means your buffers as well...) and stack.
If you run code from the flash, the execution time can become much slower - not very healthy when you don't really have any cycles to spare.
So writing 128kB at once to a card is very unlikely... not to mention you don't want to move the card between your machine and the board all the time, it's just not convenient.

Adding ram or using a board with fast ram access is the way to go, but we'll see.

Well, all good points. However, may I please insist on the point that some of us would be happy to go for a reduced set of features and hopefully with the board we already got?
This can be done in parallel if we at least share some updates on what has been tested and which issues have been met. We don't want to reinvent the wheel each time, do we?

I now have the new development board up and running nicely. I am happy with it and my next step would be to benchmark the USB communication. If HD is not possible, nevermind, I am happy with a reduced capability. If that same firmware can image HD disks provided that it is given additional RAM, that is fine, it's going to be revision 2.x.

[IFW]

Originally Posted by LuigiDifraia

Well, all good points. However, may I please insist on the point that some of us would be happy to go for a reduced set of features and hopefully with the board we already got?

That's the only reason I am still evaluating this board - you know we got quite a few of these ourselves too

[mr.vince]

Originally Posted by mr.vince

We're also currently looking at a difference between board revisions, where the latest Olimex is fine, while the Ukraian one has a "major" flaw which disables the option to reenumerate the board. If anyone already has a true blueprint that one, I'd love to see it.

Ok, already found the docs. Good news is... the reenumeration can be fixed. This is not an issue on the Olimex board (latest revision E). There actually IS something to do this on the Ukranian board (which is a rip off of the Olimex design, but obviously from the revision that was not working - maybe D) but it is broken. I was too lazy to find out where that circuit was broken, so I cut it off and built a similar one on the breadboard part of the board. I will be posting a DIY fix once I find some time to do this.

Please note that this fix only does fix an issue with the board bought from the Ukraine (or older Olimex boards, which should not have been around anymore when this project was started). It does not fix anything in regard to USB reliability. It just makes the Ukranian board work at all for what IFW is investigating. ;-) For anyone wondering what this does... we're able to reconfigure the board and make itself unplug and replug. This is just a small step, but an important one, which would have meant keeping another fork of source code just for the Ukranian boards and another firmware binary.

[LuigiDifraia]

Originally Posted by mr.vince

Ok, already found the docs. Good news is... the reenumeration can be fixed.

I am quite happy of my new board and I'd like to check if the re-enumeration issue is present on it or not. Does anybody mind sending me the details of the re-enumeration test (how to perform it, what results to look for, etc)?
I understand you might not want to send unfinished code, so feel free to just describe the issue or point to some docs. I guess I can do some tests with devcon or maybe the GUI application Rich found on the net for doing this kind of stuff?

Btw, I just found out my USB transfer test code doesn't work with the Ukrainian board. This code and the new board seem to work OK with the C# test application I use to do bulk transfer.
If you are interested in testing it on your other boards, just feel free to ask for the firmware. More than happy to provide it.

[IFW]

If you do a bus reset, the board won't recover if you have this issue.

[Loedown]

Originally Posted by mr.vince

Speed is a problem, looking at this from the preservation point of view. When being at conventions or similar, it would be neat to have something fast.

I agree that RAM would help, maybe just a bigger revision of the ATMEL with RAM built in would be nice. The main thing why this CPU was chosen is that Rich wanted to proove it can be done with the smaller one.

We're also currently looking at a difference bitweens board revisions, where the latest Olimex is fine, while the Ukraian one has a "major" flaw which disables the option to reenumerate the board. If anyone already has a true blueprint that one, I'd love to see it.

Well, point 1, it would be neat, to be speedy, yes it would be, but I bet it would be even neater if there was actually something more than vapourware. Did you know I have the design for a 1Tb drive mounted on a 2 X 2 mm chip, I just haven't built it yet? Sounds exciting, but counts for exactly jack shit until built.

Point 2, now we have someone's ego / short-sightedness as the hold up for the whole project.

If I had just a little more knowledge about such things, I would do the damned thing myself, it would work, it wouldn't cost the earth and I can assure you that it wouldn't be done to prove a point, it would be done to preserve the very old disks I have here and for everyone elses very old disks.

Paul

[hitm4n]

A simple adf dumping board that connects an amiga floppy drive to a pc or allows a pc drive to read amiga discs (either would do), would be a godsend for tons of people. Even if it was slow, and read one sector, dumped it, read another etc., had no buffering to speak of, i wouldn't care. Just so long as we could dump discs... All these years later, how come no-one has designed one simple device. I really am amazed with some of the amiga enthusiast techy talent floating around...

Was this project trying to do too much ?

[IFW]

No, it just takes time - a lot, especially if it's not your day job.

[mr.vince]

Originally Posted by Loedown

Well, point 1, it would be neat, to be speedy, yes it would be, but I bet it would be even neater if there was actually something more than vapourware. Did you know I have the design for a 1Tb drive mounted on a 2 X 2 mm chip, I just haven't built it yet? Sounds exciting, but counts for exactly jack shit until built.

I see. So you would not mind telling the folks here it does work and it is real if I would send you the hardware + the code to try it out? Wait a minute... Hm. That was smart. You nearly tricked me. I think we can all live with the fact that you call it vaporware.

Yes, that was sarcastic. And too bad you are not able to build such a thing. I would just love to buy it from you. I mean, it would not cost the earth and I'd have more time doing other things instead of soldering circuits on Ukranian boards that should have been already in there in the first place.

Originally Posted by hitm4n

A simple adf dumping board that connects an amiga floppy drive to a pc or allows a pc drive to read amiga discs (either would do), would be a godsend for tons of people. Even if it was slow, and read one sector, dumped it, read another etc., had no buffering to speak of, i wouldn't care. Just so long as we could dump discs... All these years later, how come no-one has designed one simple device. I really am amazed with some of the amiga enthusiast techy talent floating around...

Sorry this is again a sarcastic answer. Why hasn't any big company decided to give out their trade secrets for free? Why aren't cars for free? I guess it is because we're not living in Star Trek (which I'd really enjoy for it's social principles). I do not see why anyone here should speed up free work for the community in his spare time while others make a living on selling retro stuff. Why don't you go ahead and buy a Catweasel? Oh, I see. It is expensive, has a closed source firmware, can not read copy protected disks nor can it write them... I mean, the product is around for what... 13 years now?! And they ARE getting paid for it. At least it can read standard Amiga disks. Already - after 13 years of existence. Can someone please go ahead an harass them?

Originally Posted by IFW

No, it just takes time - a lot, especially if it's not your day job.

Hmmm... Why isn't this our day job?

[hitm4n]

Sorry, my annoyance isn't directed at anyone. More a big disappointement on a project that was forever close since last xmas and does (to be quite fair) sound quite dead now in a "i'm joe public and i want to buy one" type way. It seems to me that this poject is clever, well needed and got very close. I just wonder why have we only got this close now and not 10 years ago ? I think almost every disc that people want to dump are standard ones. Is a working board possible for this job now ?

[mr.vince]

Microcontrollers have gotten very cheap. Now it is the time to do such a thing. It just happens to be a side project for "private pleasure". We do not earn our money with this stuff, and companies making $$$ don't even bother.

[IFW]

We looked once, several years ago, and it was not feasible economically - anything even remotely capable of similar things was in the range of thousands of dollars.
To be honest in order to have a professional development environment you'd still need to pay a few thousand per license, but at least the hardware itself has gotten very cheap.

That is the reason why it is possible now.

[Arnie]

Harassing people for leaving the project or because the project isn`t going fast enough is not going to get this project finished. It may never get finished, so what?, these people are doing it in their spare time and do not owe anyone anything. So please stop sniping, bickering and point scoring, it`s becoming a bore to read.

[killergorilla]

Agreed.

If you are that worried about dumping your disks then buy an amiga that can do it, or contact someone who is willing to dump them.

[LuigiDifraia]

Originally Posted by IFW

If you do a bus reset, the board won't recover if you have this issue.

Well, devcon shows that the device "requires reboot" if I restart it.
If I list the available usb class devices after restarting it, I get:

USB\VID_0000&PID_0000\...other stuff here : Unknown device

Anyway, is there anything that is expected on the firmware side for a restart to occur successfully (e.g. a callback, or something)? I implement my own custom USB device with very basic functionality at the moment.