Mathias wrote:You are in no posititon, to decide what other developers have to do or not (as I am not).
I am of course in no positition to dictate anyone. I'm just expressing an opinion on what I think is sensible and not regarding what - and when! - to implement. But you are in this position. If not, why did you even start this poll? What do you need this for if not to prioritize future development?
Mathias wrote:To ask the users what they like is a first step here now, as we have now 2 people willing to work on the FPGA.
The poll as it is is pretty worthless, as already pointed out by mfro. One example: Five people has voted for ACSI. Does these people know that TOS 4/FireTOS doesn't support ACSI at all? These five votes are of no value whatsoever because you haven't asked the users *what* they want to use ACSI for. When you know that, you can decide if ACSI is worth working on or if the users are better off with other solutions.
Most ACSI devices are either dead or dying, and also very, very slow. At best, some people will use the ACSI-port to transfer some old data to their Firebee and then never use ACSI again. A total waste of development time, this can be much better spent on the floppy controller so everybody can transfer their old data via floppy instead. Floppy is the only universal language in the 16/32-bit Atari world.
Mathias wrote:But it is not getting easier when you argue against the needs of the users. With this arguments you can - as I said already - argue against the entire project as well if you like.
I don't argue against the needs of the users, because I know very little about them. I argue against the strange logic of spending time on stuff (yes, SCSI) when the result won't be of any use because of other issues with the Firebee that no-one are working on... I also don't buy the "people will use their old equipment"-argument. Yes, some might do that, maybe the have something unique that there is no obvious replacement for. But I'm pretty sure that when someone buys a Firebee to replace their ST, they don't want to use their Megafile for long when cheap, reliable and much, much faster solid state media is the alternative. They might want to click that "printer port"-button in this poll, but when they receive the Firebee and realise how easy it is to connect it to the network and print to their modern printer that's connected to their PC they might not use that inkjet from 1997 much longer.
Mathias wrote:Your idea to create new USB scanner drivers would mean, to change the USB system (kick theuBoot stuff),
No it doesn't.
Mathias wrote: create new classes, create a scanner driver from scratch, and somehow implement it to graphic applications, create a GEM GUI for it, ... it will end up in trys to port SANE just to see that it is not working at the Bee without huge porting work, just like it was with CUPS!
Without writing new drivers you are restricted to one series of *old* scanners. You don't need to support all USB-scanners out there to have a useful replacement.
Mathias wrote:While the SCSI Scanners have everything in working condition, except the SCSI implementation!
You don't even know if the software is working on the Firebee. Please remember that no sources are available if it doesn't.
Anyway, scanners was just an example. I wouldn't mind if SCSI was added to a working Firebee. But I would be slightly disappointed (or maybe a bit pissed off) if SCSI was added to a Firebee with a graphic solution that is no more Videl/shifter-compatible than the ATI graphics card in my Milan. Or even worse, we got a half-assed SCSI-solution where the controller is implemented but needs a dirty software-trick to work because no-one has addressed the "FPGA can't access ST-RAM" issue.
Mathias wrote:1) USB is in general crap. It is using the CPU and is in general totally silly at a low end CPU. SCSI or FireWire with DMA are much better solutions for our "small" computers!
USB is not crap. SCSI and FireWire is not crap either, but annoyingly weird, expensive and hard-to-get in ordinary shops.
Mathias wrote:2) You are very often arguing for new technology or stuff, against old one. BUt many Atari users who use Scanners may have old ones, and like to keep them.
Yes, that is a very good point - if we knew anything about the Firebee users' needs. We don't.
Mathias wrote:joska wrote: I see the point about the tape streamer (although both my DAT streamers broke and I lost all my backups). But is this enough to make it worthwhile? You need to perform a proper survey first to determine this!
Ähm, first you asked about personal needs for SCSI, and now as I told it to you, you talk about a proper survay - about my needs? Not really?

I'm not sure if I understand you. Yes, the users' personal needs are vital information when it's time to decide how to spend development resources. But a single users' personal needs are worth nothing. You are expecting to sell more than a single Firebee, right?
Mathias wrote:joska wrote:That's where the focus should be IMO. Improve software compatibility with the real Falcon, and when things are starting for work properly you can think about adding the external interfaces.
I agree totally to that idea. But Wolfgang will not start to write the illegal instruction handler instead of implementing SCSI.
Forget about the illegal instruction handler. The CPU is the smallest (and easiest to solve) issue when it comes to compatibility with legacy hardware. The real problem is the very incomplete implementation of key hardware like the Videl, RAM-access, DMA sound, DMA disk (floppy)... Without these the Firebee is just another clone, like the Milan or Hades. Yes, fix midi-port. Pointless and complete waste of time, because the Firebee is not capable of running the software musicians wants to run on an Atari.
Mathias wrote:joska wrote:Exactly. This is the way forward. What do you think the answer would be if you asked 100 Firebee users if they would like to use an old or a new printer?
Perhaps they would answer "the one they already have"

The thing is that printers and harddrives from the golden era of Atari computing are - with a few exceptions - dead or atleast well past being reliable. Mechanical devices like these does not last forever. Time spent on improving network printing (or even a USB driver) gains a lot more users than time spent on the parallell port.
Mathias wrote:And after 3 people tried for a long time to implement network printing, it might be quicker to debug the parallel port and have a well known solution with NVDI for some common printers, than to create printing from scratch new.
You don't have to create anything from scratch. Network printing is already working.
Mathias wrote:Of course everybody would love if the Ataris could print at every new printer, but what is the quickest and most easy way to print out at all soon?
See above - the already working solution.