My FireBee...

[oehansen]

Well, we're not as bad as all that...

You know what they say in math ... "the exception proves the rule"

[calimero]

When "all" opposition is dead, then you'll have your right-to-life removed, because you exhale too much carbon-dioxide and don't have enough money to pay carbon-dioxide taxes ... we are becoming a burden, and life no longer an inalienable right.

And "democracy" is just means to accomplish complete "dictatorship". As 99% of the population, don't understand each move in the great game. We just believe the empty promises, and suffer the consequences.

warning: total offtopic ahead!

I thinking about this all the time: how is possible that we can not calculate EVERYTHING with today technology?

with today technology, everything:
a) could be know to anyone
b) if first is true, than: everything could be calculated

I am pretty sure that we can produce enough food for entire planet with fraction of today energy cost ONLY if we would optimize entire production chain. Same goes with anything we do in life: is it cheaper to wash (spent water and soap) baby's oldschool - textile diapers or is it cheaper to buy (spent raw material, energy, transport diapers...) Pampers Diapers? (When I say cheaper, I do not think of value in money but rather resources/waste/pollution value!)

but problem is system itself: it was never meant to allow such things - if this would happen, today system would collapse/transform!

[Mathias]

I am pretty sure that we can produce enough food for entire planet with fraction of today energy cost ONLY if we would optimize entire production chain.

We already produce enough food - in fact much more than enough! So it´s not the production chain but the circulation chain.
More exactly, there is always enough food everywhere. I read about the fact that it would always be better to give fasting persons money so they can locally buy food, instead of doing that food programs. There is always enough food everywhere, they just don´t offer it to the suffering ones, ...

but problem is system itself: it was never meant to allow such things - if this would happen, today system would collapse/transform!

Exactly. And it is also not really allowed to use Ataris. And in no case to use computers for two decades. I read yesterday that they expect to sell 2,4 Billion computer devices in 2013 (including smartphones). WTF every 3 years one computer for every individual at this planet, ...

[AnakiMana]

This topic has really derailed.

Mathias, can you or someone else please create a detailed status page showing which features are
1) complete
2) in progress (with notes on progress or who is working on it)
3) not in progress (need volunteers)

It would also be nice to have a list of planned updates and, when possible, your time-goal for them. Like the new cases*. It would be nice to know the goals for Beta status and then final completed status.

A lot of people are confused, even FireBee owners apparently...

This will undoubtedly work as a recruiting tool to help the project reach completion. I know you describe updates on the ACP News page, but it's hard to look at. A simple list would be great, perhaps with links to sub-pages if necessary. It might help me decide when to pull the trigger and buy one!

*Here's a paragraph about the new cases taken from ACP News page:

But all this led to the awareness that we are going to order a new series of mini cases, to have all the colours again available. No sooner said than done! A new batch of cases will be soon available - very likely by the end of the first quater - in the already well known 4 colours, as well as in the 4 Blue/Black or Magenta/Black combinations. Two small optimizations of the case were developed as well. In Vienna we designed a small fitting panel for future SATA converters, which can be fastened with a single screw inside the upper part of the case. Also, we have built a small clip with which the Speaker can simply be suspended. The clip will soon be produced with a 3D-printer and will serve as an optional replacement of the internal hotglued speakers for the already delivered mini cases.

[Mathias]

Mathias, can you or someone else please create a detailed status page showing which features are

Haha, ... Thats exactly what I am working on the last two weeks! Sadly this is a huge task, needing an overview about everything we ever did and like to do. So far I got more than 160 important points. And, let my try to be diplomatic; developers are not that motivated about such "office tasks", so categorizing and indexing every part of the project is somhow running behind every developer and try to sqeeze the information out of them

So "need volunteers" would even start here

About the new mini-case series, they are at the print shop here in Vienna recently for serigraphing. The agreement is that I can pick them up at Thureday. Than I need another 2-3 weeks for packaging, and assembling the LEDs, speakers, and that stuff plus another week for shipping the freight to Switzerland (including complicated customs stuff, and dealing with railway freight, ...). So, you see time-goals are often not very reliable. Better not promising anything, ...

[AnakiMana]

That's ok about time-goals not being reliable... just don't be specific. Even vague updates are encouraging because we can know the status is current, even if "currently still waiting on XX".

Without any updates, we just wonder and sometimes start to doubt.

[oehansen]

That's ok about time-goals not being reliable... just don't be specific. Even vague updates are encouraging because we can know the status is current, even if "currently still waiting on XX".

Without any updates, we just wonder and sometimes start to doubt.

Exactly, and we also need to be able to stay in touch with current development.

Example, I have no atari mega keyboard, so I need a working USB or PS/2 keyboard to work.

I am still waiting for both, neither works ... but I dont know if someone is working on it, or if there is a status, or what. Should I grab a byte, and code the PIC code for PS/2 ... but its based of Eiffel, should exist.

We need to know, and stay in line with the updates ... not just wait, and wait and wait, and wonder.

We can help ...

[lschafroth]

Any updates are welcome. Even if it is a status that something is still being worked on or looked into. At least we know there is current work being done.
A section on the site with a To Do list would be great. Show who is working on it and how to volunteer for each portion you can help with.

More updates please!

There are probably times where someone waited 6 months for an update and finally asked only to find out it was waiting on something the whole time. something we could have helped with.

[vido]

I think this is not so easy ...
I totaly agree that status of the development of the computer should be public available to all the people. But that would be ok if there woulde be a real company behind the project. But thi is a volunteer poject with developers working in their fee time for free. If someone is working on something it doesnt mean it will be finished or available to the public. Until FireBee is not officialy released as usable computer for the end users I think some informations could raise to much hope.

I believe it is not fun to be project maintainer/coordinator of such project. I believe Mathias will tell more about that.

Anyway ... for me and some other people FireBee is allready in usable state.
Users outside development team can allready organise themself and develope on their own.
And I think more informations can be delivered about the status. I believe it is not such a big secret that Mathias is working right now just on that topics. And believe me it is not easy task at all!

[mfro]

Example, I have no atari mega keyboard, so I need a working USB or PS/2 keyboard to work.

I am still waiting for both, neither works ... but I dont know if someone is working on it, or if there is a status, or what. Should I grab a byte, and code the PIC code for PS/2 ... but its based of Eiffel, should exist.

We need to know, and stay in line with the updates ... not just wait, and wait and wait, and wonder.

We can help ...

O.k.

Since you were begging for it : BaS_gcc (the Firebee low-level firmware) is currently in development. All the sources are available in current state on AtariForge. All you need is a Firebee, a PC, a cross compiler, a little knowledge and some time. A good portion of stubbornness never hurts when programming .

Take the sources, talk to me, find some time and code a fine USB low level driver (I do consider a good USB driver a lot better fit for the future than supporting obsolete PS/2) that provides native Atari keyboard and mouse emulation to EmuTOS. May be even as USB "legacy driver" (seems to be easier to design, actually). Even FireTOS could benefit from it since the FireTOS internal driver still seems to have problems with the shift keys.

That's actually something I always wanted to try but didn't find enough time yet.

I'm volunteering to help you (as time permits) to get up to speed if you really want to get into business.

Regards,
Markus

[oehansen]

Since you were begging for it

Yes, I am

: BaS_gcc (the Firebee low-level firmware) is currently in development. All the sources are available in current state on AtariForge. All you need is a Firebee, a PC, a cross compiler, a little knowledge and some time. A good portion of stubbornness never hurts when programming .

Got it!

Take the sources, talk to me, find some time and code a fine USB low level driver (I do consider a good USB driver a lot better fit for the future than supporting obsolete PS/2) that provides native Atari keyboard and mouse emulation to EmuTOS. May be even as USB "legacy driver" (seems to be easier to design, actually). Even FireTOS could benefit from it since the FireTOS internal driver still seems to have problems with the shift keys.

That's actually something I always wanted to try but didn't find enough time yet.

I'm volunteering to help you (as time permits) to get up to speed if you really want to get into business.

Regards,
Markus

Ok, I'm on it ... it'll take me some time to read the source and get into it. After that I'll know, but my first inclination is (squeeze linux's driver there?) of course, that's the first impression without having looked closer into how it would fit, or if it would ...

I'm on it ... how do I keep in touch to get your aid?

[mfro]

I'm on it ... how do I keep in touch to get your aid?

Mathias, looks as if we just recruited a new developer

Great! Welcome to Firebee development!

Since BaS_gcc was started as open software in any sense from the beginning, I - personally - don't have any problem to discuss development progress in public. Right here if nobody objects (provided we don't violate forum rules).

Just give me some time to breath and I'll probably start a new thread tomorrow regarding Firebee low-level firmware development?

[viking272]

than who own http://www.atari.st (LGD) it is top site on Google for term "atari st"...?

It's owned by Richard Davey. He's on Twitter a lot - @photonstorm

[Eero Tamminen]

Take the sources, talk to me, find some time and code a fine USB low level driver (I do consider a good USB driver a lot better fit for the future than supporting obsolete PS/2) that provides native Atari keyboard and mouse emulation to EmuTOS. May be even as USB "legacy driver" (seems to be easier to design, actually). Even FireTOS could benefit from it since the FireTOS internal driver still seems to have problems with the shift keys.

Ok, I'm on it ... it'll take me some time to read the source and get into it. After that I'll know, but my first inclination is (squeeze linux's driver there?) of course, that's the first impression without having looked closer into how it would fit, or if it would ...

David Galvez has done some USB work, you might want to go through his mails on the MiNT mailing list as they discuss different sources for USB code and how & where to integrate it. Google search for USB on Mikro's MiNT mailing list archive might be good starting point for that:
http://www.google.com/search?q=site%3Am ... int%2F+usb

[mfro]

As stated above, I plan to create some kind of tutorial for BaS_gcc coding in a separate thread. It will probably take some time until we come to the "real stuff" because I'd like and take as many people as possible/interested with us.

If you want to do "something useful" in the meantime (I guess you're eager to start with at least something), I suggest to prepare/make yourself familiar with the development environment necessary for BaS_gcc development:

• any PC capable of running a GNU m68k/Coldfire cross compiler toolchain. I strongly recommend a Linux OS (I have mine running on Ubuntu x68_64) since I'll be able to assist with it (although I have a similar environment running on Mac OS X - without BDM in-circuit debuging capabilities, however). The same should be possible based on MS Windows/Cygwin, but I can't help you much with it.
• install Vincent Riviere's m68k-atari-mint toolchain. For Debian-based operating systems, there is a compatible software repository available which allows for an extremely simple installation. Instructions are here.
• install the latest version of Eclipse (which will be used as comfortable IDE). I recommend against using the package supplied with Ubuntu (since it's a few versions back to the "official download"). You'll also need to use the internal package installation functionality of Eclipse (we'll need to do some "tuning" to it to be able to do cross compiling) which is a bit cumbersome with the Ubuntu package due to limited access rights
• install a few additional packages within your Eclipse. Namely CDT (the C development toolset), "CDT GCC Cross Compiler Support", the "Subversive SVN connector" packages (needed for teamwork with AtariForge's sourcecode repository). Hope that's the complete set.
• the compiler toolchain above is not enough if you want to do BDM in-circuit debugging. The m68k-atari-mint format does not provide a binary format that allows to use debugging symbols for symbolic BDM debugging. You'll need to compile a full cross compiler toolchain (including gdb) for m68k-elf. Makefile targets in BaS_gcc allow to use both toolchains. Compiling the m68k-elf toolchain is pretty straightforward, so I don't see a reason to provide binary packages:
  
  • here is a pretty good guide (unfortunately in german only) to build your own m68k-elf toolchain. Just follow it, I only recommend to replace the version numbers by 2.23 for binutils, 4.6.3 for gcc and 7.5 for gdb to avoid getting into version difference trouble with the m68k-atari-mint toolchain from Vincent
• the instructions above also mention the BDM toolset. Do not follow them (outdated). Instead, make sure to download the latest version from the Sourceforge CVS of the project and follow the instructions (they should work OOTB for 32 bit host systems, I can provide patches for 64 bit systems)
• look for a BDM cable/connector. Google for "P&E BDM pod" and/or "TBLCF BDM". Both work for me, but unfortunately I can not help you with a shop to purchase them (the P&E pod was part of my Coldfire evaluation board package while the TBLCF I have is not available from the original supplier anymore)

I guess that's enough work for you to do to keep you busy until I finished the first chapter about Firebee firmware coding? Everybody who's interested in the topic is invited to attend!

Regards,
Markus

[oehansen]

Ok, I prefer OpenSuSE myself ... no windows here. I have the cross compiler toolchain downloaded and built, am making sure they are the newest packages right now.

A BDM, am going to look for it ...

Am already looking at the code, but understand that your document will be needed. I suspect that will show the hierarchy of how the BaS_cc is supposed to initialize and work, on an OS basis. Where the hooks are supposed to be, for example for a "driver" system. How too hook, and register the routines?

[Eero Tamminen]

As stated above, I plan to create some kind of tutorial for BaS_gcc coding in a separate thread.

If you want to do "something useful" in the meantime (I guess you're eager to start with at least something), I suggest to prepare/make yourself familiar with the development environment necessary for BaS_gcc development:

I think the dev env setup instructions would be good to have on that other thread too.

[mfro]

Am already looking at the code, but understand that your document will be needed. I suspect that will show the hierarchy of how the BaS_cc is supposed to initialize and work, on an OS basis. Where the hooks are supposed to be, for example for a "driver" system. How too hook, and register the routines?

We will hopefully cover the possibilities of interception in enough detail when we come to it later.

Until then, I'm afraid I have to disappoint you: there is (at least not currently) no defined API to call BaS services from the OS.

The idea (which I'd like to stay with wherever possible) is that the OS actually doesn't need to know anything about BaS if BaS behaves exactly like TOS expects its hardware to behave. The consequence for device driver code is that it has to map to something TOS knows about. In case of a keyboard and mouse driver for example it has to behave as much as the original keyboard and mouse as possible.