Which ports should be cared of first?

[joska]

1. ST-RAM (0-14Mb) must be like on a real Falcon. I.e. this memory range must be available to the complete chipset without any software kludges or hacks.
2. The "Videl" must be compatible with the real Videl and be able to use the complete ST-RAM as a framebuffer without software hacks. Extended videomodes should ofcourse be able to access the complete 128Mb of RAM connected to the FPGA.

Even this is debatable with the same questions you asked before: who will be using it?

Well, you have to draw the line somewhere. What is the point in a "Falcon" that can't run important Falcon software like Apex Media?

How many SV users use Falcon resolutions (besides an ocassional gaming session with games that won't run on the Firebee anyway)?

Why can't Falcon games work on the Firebee? Yes, I know that they won't work *now*, but not mainly because the Firebee has a ColdFire CPU. The problems are elsewhere - the incompatible "Videl", missing DMA sound, missing DSP, no ST-RAM...

We really have to avoid situations of sacre FPGA developer resources putting huge efforts into the implementation of legacy modes, chips and ports nobody will use afterwards.

I agree. But what is the goal here? I agree that it doesn't make much sense to add functional ACSI, SCSI and Centronics connectors. The functionality of these interfaces should IMO be handled similarly to how it's done in the MIST. But it does make sense to make sure that the Firebee can run legacy software. If it can't do that, what's the point in the first place?

When I bought my Falcon 20 years ago I was disappointed with the lack of compatibility with legacy software. Most of the stuff I had didn't work. But it really didn't matter, because back then software was being developed so it didn't take long before "everything" (except games, sadly) took advantage of the Falcon. We're not there now. We can't expect the same to happen for the Firebee, it must be able to run old software to be of any use.

[joska]

I have three or four, one laser and three inkjets all of which are perfectly capable of photo printing (bar the laser which is back and white). Although you are right, USB would be far better, but there aren't any drivers..

So that's one. Anyone else using a parallell port printer here?

USB itself is not really a problem. Many modern printers have ethernet or wifi, many routers have printer servers and USB-ports, you can connect the printer to your PC (which all of you got to do real work on) and share it or even buy a dedicated Centronics -> USB adapter. So there are many ways to connect to a printer. The biggest problem is to make sure that you get a printer that understands what the f**k your Firebee is feeding it with

[Zogging Hell]

So that's one. Anyone else using a parallell port printer here?

Hhhmm maybe I might be the only one who actually quite likes picking up old printers (maybe it is some sort of mental illness ). I do genuinely still use my Atari's seriously for drafting documents (my PhD is currently being drafted on a Mega ST, and hopefully will eventually get printed on the Firebee somehow ), and I need to print of hard copies now and again. The Atari is pretty distraction free, whereas the PC tends to put all sorts of other things in your way to deal with.. like Windows update.. On a side note the last printer I saw with a parallel port was my Epson Stylus C64, which must be mid-noughties I guess, it really has been a long time.

USB itself is not really a problem. Many modern printers have ethernet or wifi, many routers have printer servers and USB-ports, you can connect the printer to your PC (which all of you got to do real work on) and share it or even buy a dedicated Centronics -> USB adapter. So there are many ways to connect to a printer. The biggest problem is to make sure that you get a printer that understands what the f**k your Firebee is feeding it with

Ai true, but I must admit I tend to avoid wifi like the plague as setting it up has proved a hassle for me in the past (maybe it is the wretched Samsung laser I'm using), and USB is just a plug in and play option. Ethernet is a pretty good alternative though, although for similar reasons to the wifi, network printing has always baffled me. Anything with dns numbers and so on reminds me of the early days of connecting the Atari to the internet and the mind boggling frustration of trying to get a connection.

[Shredder11]

I have a Hewlett Packard Deskjet 930c from around 2000 that has both a Parallel and USB port. I've not tried it with any of my Atari computers but it did work fine with a Psion Series 3mx from 1998. The print quality is superb too especially with black monochrome documents

[Mathias]

Jo Even, …
you need to stop arguing against technical stuff just because YOU do not need it. Thats totally respectless.

I fear that much work will be spent on implementing stuff that at best only will be used by a few.

Yes, I can share this fear. But as you have seen tha last years it is - in the end - only the developers personal idea and decision, about what interrests him – what finally gets developed. All of you developers are perfect in NOT really working together, but "just doing what is recently interresting". I am stunned that we got where we are.
But it seems to be some illness in the Atari community, to fear what others might do or not do.

Don´t get me wrong, but in the end the entire "argument" you are using here is totally wired, when you think about the fact that we are working together at a totally niche plattform with a very low volume series of computers, ... :-p

E.g. SCSI - can some of you who have voted for this please tell me why you would need SCSI? I don't use SCSI (or spinning disks of any sort) on any of my retro hardware. I'm just very happy to get rid of that junk Are there any good reasons to stick with a powersucking, big, noisy and fragile old SCSI disk when SD-cards costs about the same as small burger?

Yes, here, I am going to explain it a last time, and would than ask you to stop going on with your personal war against SCSI:
Personally I like to use the FireBee in future for everything. So I am missing 2 things that can be immediatly done when SCSI is finished. Scanners: I have some scanners where Atari SCSI drivers exist, and that I can immediatly use once the SCSI interface is implemented. The 2nd one is a DAT Streamer. I have one at my hand, and it is still the most secure possibility to long-term-save digital data. Especially as the driver GEMAR is free now, I like to use this streamer. Additionally I like to use CD Burners, ZIP Drives, and some of my old disks as well, but that is not soo important. But, SCSI disks seem to always have a much higher quality than IDE/SATA disk are. Non of my SCSI disks ever failed, while all IDE/SATA got huge problems after a few years.

For others there are other import needs why SCSI shall be implemented soon! For example for Samplers and sample dumping, for using Cutting Plotters, external measuring equipment, or be it simply to replace an old Atari with a FireBee without the need to change the equipment. Finally we got requests for very special things like a mixing desk automation, that uses MIDI and SCSI together for exampel, ...

And the printer port - hands up anyone who has a good, working printer with a parallell port. I don't even know when they stopped making this, I haven't seen one in atleast ten years.

Here! I got 3 printers, that can be immediatly used at the printer port, if it would work correctly. Thanks to NVDI it would instantly work. The printer port would highly increase the real world usability of my FireBee as I need to print out things on a daily basis.
Of course network printing would be nice as well, but that seems to be not as near than debugging the printer port, as you know, after 3 different people tried to implement network printing.
On the other hand, PHERP is the first step to real printing usability of the Bee. I already had situations, where my Bee saved me, with PHERP and hooked up to a recent Minolta Colour copier, while recent Linux and CUPS only produced PostScript errors, but the Bee could do PDF-direct-prints without problems.

IMO the MIST solved this in a much better way - instead of implementing the physical ports, only the registers of the device in question is implemented in the FPGA. The data is then piped to the microcontroller which then takes care of transporting it to the outside world via modern devices. This is much more flexible and user friendly than a parallell port which no current printer can be connected to. And most importantly, it's a lot less work.

Yes MiST has sone nice and wise features. If you like, go on and produce some addon card for the FireBee, hooked up to the Expansion Socket (or other ports). But do not try to argue against those further ports and interfaces the easyness of other solutions.

And finally, please do not forget about the fact that most of these ports you do not like, are mainly FPGA I/Os . The FireBee would be THE machine for FPGA developers, if we would have a few, let´s say 5 or more. As you know every port may becom everything - in real time and at runtime, ...
So basically 156 FPGA I/Os. A possible rich source for every electronic enthusiast!

[Dal]

Not many votes for the ROM port which seems weird. To paraphrase Jo a little, what's the point in a "Falcon" that can't run important Falcon software such as Cubase and Logic.

OK, we accept for now that CAF is off the radar until DSP is implemented, however why should I be denied the option of bringing a small Atari based sequencer into my live stage rig?

[joska]

you need to stop arguing against technical stuff just because YOU do not need it. Thats totally respectless.

Mathias, what is respectless is to ask developers to spend lots of time on feature you really don't know if anybody is actually going to use. There are very limited (almost non-existing) resources - they should be spent very carefully. I repeat - implementing working SCSI/ACSI connectors is a total waste of time because there are so many other issues with the Firebee that stops them from being useful anyway. When these issues are fixed - *then* it's time to consider the external ports.

I strongly suggest to first find out what people are going to actually *use* these connectors for, and then decide if it's worth implementing them or not.

Personally I like to use the FireBee in future for everything. So I am missing 2 things that can be immediatly done when SCSI is finished. Scanners: I have some scanners where Atari SCSI drivers exist, and that I can immediatly use once the SCSI interface is implemented. The 2nd one is a DAT Streamer. I have one at my hand, and it is still the most secure possibility to long-term-save digital data. Especially as the driver GEMAR is free now, I like to use this streamer.

Would it not be better to spend these resources on a USB scanner driver instead? With SCSI you're limited to a very small set of really old scanners.

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!

For others there are other import needs why SCSI shall be implemented soon! For example for Samplers and sample dumping, for using Cutting Plotters, external measuring equipment, or be it simply to replace an old Atari with a FireBee without the need to change the equipment.

The problem is that there are so many other issues with the Firebee that the *software* would still not work. E.g. what's the point in connecting a sampler when Falcon sample editing software doesn't work? 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.

On the other hand, PHERP is the first step to real printing usability of the Bee. I already had situations, where my Bee saved me, with PHERP and hooked up to a recent Minolta Colour copier, while recent Linux and CUPS only produced PostScript errors, but the Bee could do PDF-direct-prints without problems.

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?

Yes MiST has sone nice and wise features. If you like, go on and produce some addon card for the FireBee, hooked up to the Expansion Socket (or other ports). But do not try to argue against those further ports and interfaces the easyness of other solutions.

Not quite sure what you mean here.

And finally, please do not forget about the fact that most of these ports you don not like, are mainly FPGA I/Os . The FireBee would be THE machine for FPGA developers, if we would have a few, let´s say 5 or more. As you know every port may becomeverything - in real time at runtime, ...
So basically 156 FPGA I/Os. A possible rich source for every electronic enthusiast!

I have never argued against this. It's clear that the Firebee is a much more complex and powerful device than e.g. the MIST. But it needs work to reach it's full potential and right now it's *not* the lack of SCSI that's the problem.

[joska]

Not many votes for the ROM port which seems weird. To paraphrase Jo a little, what's the point in a "Falcon" that can't run important Falcon software such as Cubase and Logic.

Instead of adding a physical ROM-port I suggest to reverse-engineer the dongles and implement them in the FPGA. I think that would be more flexible and also a more robust solution.

You are ofcourse completely right. The software you mention is stuff that obviously must work on a "Falcon".

OK, we accept for now that CAF is off the radar until DSP is implemented, however why should I be denied the option of bringing a small Atari based sequencer into my live stage rig?

Getting CAF to run would be a lot of work I think. It depends on the presence of the SCSI controller, the complete Falcon DMA sound-system as well as the DSP.

[Mathias]

you need to stop arguing against technical stuff just because YOU do not need it. Thats totally respectless.

Mathias, what is respectless is to ask developers to spend lots of time on feature you really don't know if anybody is actually going to use. There are very limited (almost non-existing) resources - they should be spent very carefully.

You are doing if there is a bunch of willing and waiting developers, that just wait for some orders (from me or others) to do work on stuff that is not used by anybody, ... additionaly you are doing like if there is anybody working on senseless stuff.
As you know exactly Wolfgang suggested to implement SCSI in an early stage into the FireBee core, as he has it already done for the Suska, and as it is comparatively easy to implement. It was his idea to work on it, and it seems to be much less work than any other FPGA stuff. He is the professional, and it is up to him.

I repeat - implementing working SCSI/ACSI connectors is a total waste of time because there are so many other issues with the Firebee that stops them from being useful anyway. When these issues are fixed - *then* it's time to consider the external ports.

I strongly suggest to first find out what people are going to actually *use* these connectors for, and then decide if it's worth implementing them or not.

You are in no posititon, to decide what other developers have to do or not (as I am not). Of course it would be nice to have a team that is deciding logically what to do when, but has this idea ever be followed inside the ACP? So I do not understand what your plan is. 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. 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.

Would it not be better to spend these resources on a USB scanner driver instead? With SCSI you're limited to a very small set of really old scanners.

I don´t think so, but I am willing to discuss this.
My idea always is, to reach the general possibilities in most easy way. That means in the case of scanners, that there are already SCSI scanner drivers. So if somebody would implement SCSI, we could immediatly use Scanners (additionally I could use 2 Scanners I have at home, but that is not important for the general question). Later, we could implement new USB scanners. Your idea to create new USB scanner drivers would mean, to change the USB system (kick theuBoot stuff), 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! While the SCSI Scanners have everything in working condition, except the SCSI implementation!

There are two more factors why SCSI Scanners might be a good idea.
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!
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. I just use SCSI scanners (still), and do not like to get a new one for the FireBee, I even do not have the place for a new 2nd one at the desk. So my usage of stuff is often driven by using the old stuff still, and not following the industires get new/kick older ones/buy/buy/buy-philosophy. And I belive (I may be wrong) many Atari users think similar, and like to go on with using working but older stuff, instead of throwing it away and get new stuff that needs to be thrown away in 2 years. BUt I might be wrong.

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?

The problem is that there are so many other issues with the Firebee that the *software* would still not work. E.g. what's the point in connecting a sampler when Falcon sample editing software doesn't work? 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. And Mikro is not not doing the Illegal instruction handler because he is occupied by the ACSI interface for 3 years now

On the other hand, PHERP is the first step to real printing usability of the Bee. I already had situations, where my Bee saved me, with PHERP and hooked up to a recent Minolta Colour copier, while recent Linux and CUPS only produced PostScript errors, but the Bee could do PDF-direct-prints without problems.

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"
But of course your question here is suggestive. For me it would be important to have a FireBee that can print (from within programs, not just externally created PDFs). 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. Or to have a very bad working CUPS that is totally unsuited for the Bee, and no real solution.
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?

And finally, please do not forget about the fact that most of these ports you don not like, are mainly FPGA I/Os . The FireBee would be THE machine for FPGA developers, if we would have a few, let´s say 5 or more. As you know every port may becomeverything - in real time at runtime, ...
So basically 156 FPGA I/Os. A possible rich source for every electronic enthusiast!

I have never argued against this. It's clear that the Firebee is a much more complex and powerful device than e.g. the MIST. But it needs work to reach it's full potential and right now it's *not* the lack of SCSI that's the problem.

Nobody said SCSI is the missing link for the firebee to reach its full potential. But also nobody who may care about SCSI will be forced to stop working on things that lead the FireBee to reach its full potential!

[oehansen]

Fully agree to everything you wrote not quoted.
Even this is debatable with the same questions you asked before: who will be using it?

Nearly every Firebee screenshot I have seen uses screen resolutions and bit depths a real Falcon cannot display. People ask about connecting 1920x1400 monitors, not about ST low or Falcon compatible TC.

This will not be possible with a "traditional" Falcon setup, at least not at reasonable speeds. Even a FPGA blitter implementation would need to have a "legacy Falcon mode" _and_ something much more advanced (and likely completely incompatible) to achieve reasonable speeds at high resolutions.

How many SV users use Falcon resolutions (besides an ocassional gaming session with games that won't run on the Firebee anyway)?
We really have to avoid situations of sacre FPGA developer resources putting huge efforts into the implementation of legacy modes, chips and ports nobody will use afterwards.

Those mirror my emotions on the issue ...

Programming a chip, exactly, in an FPGA requires a huge effort. One can just look at the SD2IEC for commodore, to see that even for vintage computing that old floppies is not the way to go. But one has to be realistic and understand the need to read old medium, and store the contents on newer media. For that, of course, the need for both mediums on the firebee is obvious.

But I can't see that as a need for a game port, on the firebee ... or midi ... is midi even being used in modern music environment? Wouldn't both of these be better of, by utilizing a mouse port that supports even some modern game tools and translates these to atari's internal? and the same for midi? I never use these, so must admit my ignorance in these two areas.

[vido]

Hello,

I am reading this thread and I find it very useless. Everyone has its own opinion and needs what should be implemented. I agree with some and some are not of my interest as they dont go with my needs. Anyway this is open project and developers develop regarding to their interests, time and needs. Most of us have families and other more important tasks in our life or even other more fun things to do in our spare time.

Before such survey as this one is, I would do a survey who would participate in a team of developers for the FireBee project and at which kind of development could participate?

Well I guess because of what I wrote first. there would not be much voluntiers
With such survey as a basis I would consider if there is a point to argue what to develop first or we can just wait who will have enough spare time and interest to develope something?

[TheNameOfTheGame]

I have three or four, one laser and three inkjets all of which are perfectly capable of photo printing (bar the laser which is back and white). Although you are right, USB would be far better, but there aren't any drivers..

So that's one. Anyone else using a parallell port printer here?

USB itself is not really a problem. Many modern printers have ethernet or wifi, many routers have printer servers and USB-ports, you can connect the printer to your PC (which all of you got to do real work on) and share it or even buy a dedicated Centronics -> USB adapter. So there are many ways to connect to a printer. The biggest problem is to make sure that you get a printer that understands what the f**k your Firebee is feeding it with

Yes, I have a Deskjet 672C hooked up via parallel port on my Atari.

(I also have a US Robotics 33.6 modem on my serial port)

[TheNameOfTheGame]

Not many votes for the ROM port which seems weird. To paraphrase Jo a little, what's the point in a "Falcon" that can't run important Falcon software such as Cubase and Logic.

OK, we accept for now that CAF is off the radar until DSP is implemented, however why should I be denied the option of bringing a small Atari based sequencer into my live stage rig?

There are lots of cool uses for the ROM port including such dongles. So yea I think it is important for any "Atari" machine to support it.

[Knezzen]

Instead of adding a physical ROM-port I suggest to reverse-engineer the dongles and implement them in the FPGA. I think that would be more flexible and also a more robust solution.

It's not just the dongle's. I personally use a Emagic Unitor II, Emagic LOG-3 to their full extent. This gives me 6 more MIDI outputs.
Both connects to the ROM-port and they are both needed for me to work.

A serious Atari-based studio is impossible to build around the FireBee at the moment because of the lack of the ROM-port. I need my MIDI outputs.
No one makes music with just one synthesizer anymore. If you don't implement a ROM-port and you put the dongles in FPGA, you would still need to build some kind of clone of the MIDI-interfaces to get the outputs and for it to work with Logic.

Im pretty sure the Steinberg people would like to use their MIDEX-expanders as well.

This is why implementing the dongles in FPGA will be pretty much useless for serious MIDI users (like me).

[Ektus]

But I can't see that as a need for a game port, on the firebee ... or midi ... is midi even being used in modern music environment? Wouldn't both of these be better of, by utilizing a mouse port that supports even some modern game tools and translates these to atari's internal? and the same for midi? I never use these, so must admit my ignorance in these two areas.

I'm no musician, but midi is also essential for Midi Maze, and a digital joystick is needed also.

Regards
Ektus.

[AtariSociety]

Wonder if ROM port gets working if my Spectre GCR will work. hehe

TJ

[Eero Tamminen]

Regarding DSP emulation and Falcon SW using DSP. Quite many such programs require exact timings for operations (e.g. DSP based MP2 playback used in some demos and games). Unless Firebee has some way to slow it down to Falcon speed, or at least to get very exact speed balance between ColdFire CPU and simulated DSP, things might not work (lock up or fail, any DSP generated sounds sound awful etc).

[Xyla]

But I can't see that as a need for a game port, on the firebee ... or midi ... is midi even being used in modern music environment? Wouldn't both of these be better of, by utilizing a mouse port that supports even some modern game tools and translates these to atari's internal? and the same for midi? I never use these, so must admit my ignorance in these two areas.

MIDI is absolutely ESSENTIAL if the Firebee is ever going to gain acceptance among musicians. Yes MIDI is used in any modern music environment that utilizes any of the many extremely sought-after hardware synthesizers out there. Almost everyone I know who makes electronic music has at least one classic hardware synth that they use in their studio, and that is not likely to change any time soon.

Not to mention without MIDI-controlled hardware synths, the only other option for making the Firebee usable as a music production computer would be to write completely new software synthesizers (and a way to use them within an Atari sequencer), and not only is that not very feasible for the Firebee's 266MHz processor, but I think we all know it's not likely to happen at all.

MIDI implementation is a quick way to make it so people will consider buying a Firebee rather than an older Atari-made computer if they want an Atari to make music with.

[wongck]

LOL

This thread supposed to be just a survey, but hey, any discussion on the Atari is good !!!
This means there are people who cares about it.
If someone don't care, they don't bother....

If you want something done... best do it yourself.
I did PHERP because like Jo said.... I never seen a parallel port printer in more than 10 years or so.
I needed printing so network printing was the only solution for me, and I can already make PCL files from NVDI since 10 years back.

Now I am having some issues with colour PCL on NVDI, so I was thinking if I can make colour PDF on my Atari instead of PCL.
And sent it to a network printer... wouldn't that be nice. So I am trying to make a PDF maker for the Atari, not sure if it will work or when it will come.

As Vido said, we do have a life and soemtimes more important things to do.

Also I already told why I wanted SCSI, as the only other port I wanted.

[mfro]

Hmmm. I'd say the discussion is actually worth a lot more than the poll itself

I suppose there were people voting that already own a Firebee and quite a few others that don't. As long as the poll doesn't differentiate, the poll will compare Apples to Oranges IMHO.

Opinions from some that have practical experience with the Firebee (and its deficiencies/needs) and others that don't (they are not even asked if they would buy a Bee if the ports they voted for would be functional).

[Xyla]

Well, for me personally, I will say that I am definitely planning to buy a Firebee... but there is a good chance I will buy a Falcon first because of the missing functionality. If certain ports and abilities were finished (MIDI, DSP, and full Videl compatibility), I wouldn't even be considering a Falcon (which will likely be more expensive than a Firebee). I think there are many people in the same position as me. I posted on the Facebook Atari Musicians group and many people are dismissing the Firebee currently because of the lack of MIDI.

[mfro]

...but there is a good chance I will buy a Falcon first because of the missing functionality...

Realize that there will never be full compatibility between Falcon and Firebee. It might be getting closer, but you just can't change everything without changing anything.

[simonsunnyboy]

Full Falcon compatibility is not a must...as long as code for the Bee works on the Falcon aswell. For this the Bee should support some basics...as a game developer, Videl and joystick ports are a must. And the IKBD joysticks working does not help if they are only available with a connected MST keyboard.
Make the 9pin joysticks available for the majority who will connect USB keyboards to the Bee, without having to use original Atari equipment. It can't be too hard to simulate IKBD packets from another set of connectors.

My vote would be valid in both cases, owning a Firebbe now or considering to buy one.

[joska]

Instead of adding a physical ROM-port I suggest to reverse-engineer the dongles and implement them in the FPGA. I think that would be more flexible and also a more robust solution.

It's not just the dongle's. I personally use a Emagic Unitor II, Emagic LOG-3 to their full extent. This gives me 6 more MIDI outputs.
Both connects to the ROM-port and they are both needed for me to work.

Yes, very good point. I had forgotten about these devices. Just curious - does these work with accelerated machines?

[joska]

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?

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.

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.

Your idea to create new USB scanner drivers would mean, to change the USB system (kick theuBoot stuff),

No it doesn't.

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.

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.

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.

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.

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?

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.

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.

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.

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.