Jo Even, I think we got some communication problems. Thus I am writing again a long posting, and hope it helps to clear things. But it may look like it takes total huge space and is a real problem, what it is not in my opinion.
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.
I am happy that you are expressing your opinion. As well I like to support your ideas about reasonable development work. I was just against your unlogical arguments of efficiency, that are not valid in my opinion (which still may be wrong), as the entire project is about some hobby and "un-efficiency" hardware.
With the sentence above I wanted to express that you exactly know from internal discussions, that no developer ever did anything what he doesnt´t like to do. So it is up to the developer who is developing what is happening.
Additionally you should know that I always like to gain synergy effects and always tried to ask people for collaboration and wise development plans, even milestones and such stuff.
joska wrote:But you are in this position.
I really have to wonder about this. You know exatly that I have no power inside the team, that I simply try to make suggestions, and that I never brought anybody to develop anything that he doesn´t count as meaningfull. All my tries to structure the project, or to ask for developing/debugging stuff that is not interresting for developers leaded to nothing at all! So what are you talking about here? I have no chance to force anybody to do anything, I just try to keep things in mind, and ask for stuff that has to be done one day. And you know that!
As well you never critizised me in such a way inside the team, but tried to always support me about things that need to be done. Additionally you are the most active guy in the team. So I really belive we have a communication problem here in this thread.
joska wrote:If not, why did you even start this poll? What do you need this for if not to prioritize future development?
It should have been a support for decisions that will be done by some developers. Of course the needs of the users are just one part. Other parts are interrest of the developer, amount of needed work, availaible time, ... it was not thought as a democratical vote for things that have to happen, but as assistance to developers upcoming decisions.
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.
Not the poll is not worthless! Nobody is stopping you from taking the resoults, and open another thread and discuss ACSI for example! I do not understand why that should make the general poll useless? And I am not responsible to aks what they like to use ACSI for! Why do you think I have to do this? You can do it by your own if you like, and there may evolve good discussions about your questioning.
I was just against the behavior of "how" you argued agains the needs of people. Just make an ACSI thread and make suggestions, no problem!
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...
Again, where does this idea come from, that working on SCSI stops people doing other usefull stuff?
joska wrote: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.
Perhaps, perhaps not, I do not know. I for myselve like to use my "old stuff" as long as possible. For me there is no need to get a new printer, especially not just because of the interface. And I love my Megafile, and have it connected to my MegaST even if I have a Link and SCSI chain as well (with bigger disks). But I do not know what other people like. But if there are 10 to 20% of users who like to hook up ACSI stuff to their FireBees - and be it just because they like the box - I will not thell them that they are crazy! Especially I will not tell them that they have to get new stuff.
Mathias wrote:Your idea to create new USB scanner drivers would mean, to change the USB system (kick theuBoot stuff),
No it doesn't.
uBoot is capabel of driving Scanners, Printers and other stuff? If yes, thats very good, I didn´t know this.
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.
Jo even, are you kidding me? I never asked to restrict anybody to old scanners. Of course I would love to be able to use any scanner with the Bee, but it will not happen quickly. And all our serious Atari-scanner-drivers we got right now, are for SCSI. So I belive - recently - that the fastest way to be able to use scanners with the Bee at all, would be to implement SCSI. I may be wrong.
The other point is that I own 3 SCSI scanners, that they work perfectly, and that I would like to use them with the Bee as well. I am not willing to throw away working scanners just because the FireBee does not support SCSI.
joska wrote:I wouldn't mind if SCSI was added to a working Firebee.
Good. So whats all your arguing about?
joska wrote: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.
Again I am wondering about your judging of other developers. If users judge your work, for example the not sorted list of your great resolution switcher, you are pissed off. But now you are judging the work that Wolfgang and Roger are planning to do? Really? If so, stop arguing here, go to the development forum or write them a mail that you will be pissed off when they implement SCSI.
Do you have in mind why SCSI was planned first? Because several users wrote us mails, that they need it, and because it is already done inside the Suska, and much more easy to implement thant any other stuff from the list above.
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.
I was talking about the bus, not about devices in 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.
Exactly, and that is why I started this poll.
joska wrote: 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?
I am not expecting to sell anything. I am doing a project to keep the plattform alive, and perhaps make it a prospering niche-platform apart "Retro". YOU asked for exact informations form single users. So I started to talk about me personally. Of course that is not representative. But YOU asked for it! Perhaps others will follow, or - as said, we can go on at another place/thread with talking about SCSI.
joska wrote: 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.
I totally agree to this statement. But it is not connected to the questions of the ports. So let´s try to get all that points fixed too!
joska wrote: 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.
Well, but you will agree that a working MIDI port is necessary to have Music applications running. BTW the Electronic Cow stuff is already working, and if we would have the MIDI port fixed we could realy use it immediatly.
On the other hand a working MIDI port is for sure needed to debug one of the Sequencers. Or shall we first "port" Cubase and Notator and than care about MIDI ports? The only thing to avoid - and if this is your concern I have to again agree - is that users think, a working MIDI port means several working Sequencers.
joska wrote: 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.
Jo Even, again I do not understand you. You know that developers tried to implement network printers (and did not succeed). You know as well that no developer who cares about ports in FPGA can work on MiNT network stuff, and the other direction, that no MiNT developer is doing VHDL port descriptions, so why are you connecting that points? Of course I would love a network PostScript printer for the FireBee! But again, NVDI is here and few Paralell-port debugging might bring us some printer drivers and general printing possibilities soon. Working on the one should of course not exclude working at the other, but that was at no time the case!
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.
Yes, but there is no real solution for users, and you know that I am behind network printing for 4 years (the MiNT98 solution).
MegaST 4 with Sounddesigner II MegaBus hardware and 56001, Hades 040, MagiC Mac at Mac OS 9 and a FireBee.