foss-north 2018: Atari ST Free Operating Systems

[1st1]

I see already, you need about another year to understand my idea. Same as with Vampire (soon this will be alive on ST board).

Ps: If you don't need that unix stuff, just don't open the bash...

[vido]

I have yet to find an Atari (or "Atari") that 1ST Word does not run on. The majority of GEM applications works everywhere.

Yes, clean GEM applications should run everywhere. FireBee can be a problem even if it is clean and needs recompilation. But there are several GEM applications which dont run everywhere. As: SoftPC which I would really like to see it running on my Milan or FireBee, Photoline which doesnt run or is unusable on the FireBee, Callamus, ...
And I believe 1st1 also means applications which are copyrighted to be included in the distribution.

But generaly I agree with the idea to have applications included in distribution. Just I believe it should be only free software and for some applications dependand on the platform.

[OL]

I have yet to find an Atari (or "Atari") that 1ST Word does not run on. The majority of GEM applications works everywhere.

Yes, clean GEM applications should run everywhere. FireBee can be a problem even if it is clean and needs recompilation. But there are several GEM applications which dont run everywhere. As: SoftPC which I would really like to see it running on my Milan or FireBee, Photoline which doesnt run or is unusable on the FireBee, Callamus, ...
And I believe 1st1 also means applications which are copyrighted to be included in the distribution.

But generaly I agree with the idea to have applications included in distribution. Just I believe it should be only free software and for some applications dependand on the platform.

Some years ago I have compiled "dosbox" it was working but keyboard was absolutely wrong and never try to do working, but dosbox is not difficult to compil with SDL as I remember.

Olivier

[christos]

I see already, you need about another year to understand my idea. Same as with Vampire (soon this will be alive on ST board).

Ps: If you don't need that unix stuff, just don't open the bash...

Freemint is free software so there is nothing stoping you from creating your own distro.

P.S. vanillamint is great. If only i had an atari capable of running it...

[jury]

Last week, I made a presentation at foss-north 2018, in Gothenburg, Sweden.

Just finished watching.
Great presentation, thanks for sharing it.

[vido]

Some years ago I have compiled "dosbox" it was working but keyboard was absolutely wrong and never try to do working, but dosbox is not difficult to compil with SDL as I remember.

Dosbox would be great to have on the FireBee, Milan 060, Hades 060, Vamipre, ...
About the keyboard maybe it would be great to contact Partice abour SDL. Maybe there is a bug?
He is realy nice person ready to help and recently I contacted him about GFX bitdepth bug in SDl and he fixed it really fast.

I would also like to see Hatari version which was compiled by Vincent. It is not that bat on the FireBee. It could be usefull in some cases. But if I remeber right there is also problem with the keyboard. With some optimisations I guess it couls be usefull o the FireBee not to mention Aranym.

Ahhh ... and Mac Mini Color! I know someone using it Monochrome version is great on the FireBee

[joska]

I see already, you need about another year to understand my idea.

On the contrary, I totally understand your idea. Basically you want an Ubuntu-like MiNT-distribution. Now, that would be cool if it hadn't been for a few minor details:

First of all, it's not really possible because of copyright. If you respect copyright you simply can't create the kind of distribution you describe, because there are no free alternatives to key components like a VDI with GDOS and printer support, or drivers for many graphics cards. There are even harddisk driver limitations to consider. And applications? Name a single, usable FREE word processor. Or spreadsheet.

Secondly, major parts of these distributions is built on software ported from the unix world. Much of this software isn't really usable on Ataris, often because they use huge amounts of RAM and/or simply crashes too often. This is because MiNT isn't very unix, but more like DOS with extensions. Huge stack usage and memory mapped files is a real pain on a system with no virtual memory. Throwing more CPU and RAM at it (emulators, Firebee) helps, but doesn't cure it. How to fix this? You tell me

Third - while distros like EasyMiNT is very easy to install when you follow instructions they are not easy to maintain or configure. To make things truly userfriendly huge efforts is needed to create functional, userfriendly GEM frontends that actually does what the user need. This is where you discover how immensely powerful text config files are, and how incredibly hard it is to recreate their functionality as userfriendly GUI programs.

There used to be a commercial distribution called MiNT '98, this was the closest you'll get to what you describe with it's web-based config interface.

Ps: If you don't need that unix stuff, just don't open the bash...

"unix" isn't equal to a command line. I have bash running on VanillaMiNT on my Ataris, the command line is often the most efficient tool. No, the "unix stuff" I speak of is the resource hungry boot scripts, slow boot, memory usage and CPU usage of a system that many Atari users believe is MiNT. I have used this for many years, since KGMD in the mid 90's via an early version of SpareMiNT that Frank Naumann created to EasyMiNT and Gentoo. Generally speaking performance, stability and reliability has decreased steadily. We are moving in the wrong direction. One reason is probably that unix software written in the 90's were designed for machines with less resources than today, and thus more suitable for our systems. But a more likely reason is that while KGMD and SpareMiNT were created by Atari users that did this work on actual Atari machines and used the results productively, today's work is done on PC's and the result is rarely tested much by real use. Even MiNT itself suffers by this. It is no longer possible to compile MiNT on an Atari. MiNT developers probably spend most of their Atari time developing on a PC, and very little actually using their Ataris. The result is too little testing.

[joska]

Yes, clean GEM applications should run everywhere. FireBee can be a problem even if it is clean and needs recompilation. But there are several GEM applications which dont run everywhere. As: SoftPC which I would really like to see it running on my Milan or FireBee, Photoline which doesnt run or is unusable on the FireBee, Callamus, ...

Neither SoftPC, PhotoLine or Calamus are clean GEM applications. Fixing them to work everywhere - especially on the Firebee with it's CPU incompatibility issues - is not about patching but often major rewrites. E.g. SoftPC needs actual Atari video hardware to work. But Firebee aside, these are special cases. GEM software in general works, especially on systems with a 68k compatible CPU...

[mikro]

Even MiNT itself suffers by this. It is no longer possible to compile MiNT on an Atari.

While I agree with many points with you, I think you exaggerating here a lot. Of course it's still possible, even with the old gcc 2.95. The fact the snapshots are cross compiled is a convenience, not requirement.

[OL]

Some years ago I have compiled "dosbox" it was working but keyboard was absolutely wrong and never try to do working, but dosbox is not difficult to compil with SDL as I remember.

Dosbox would be great to have on the FireBee, Milan 060, Hades 060, Vamipre, ...
About the keyboard maybe it would be great to contact Partice abour SDL. Maybe there is a bug?
He is realy nice person ready to help and recently I contacted him about GFX bitdepth bug in SDl and he fixed it really fast.

I would also like to see Hatari version which was compiled by Vincent. It is not that bat on the FireBee. It could be usefull in some cases. But if I remeber right there is also problem with the keyboard. With some optimisations I guess it couls be usefull o the FireBee not to mention Aranym.

Ahhh ... and Mac Mini Color! I know someone using it Monochrome version is great on the FireBee

I think I'm able to fix keyboard issue but it is really strange as other software I have compiled with SDL work nice

For Mac Mini color for me coldfire is not enough it work ok on Aranym JIT only, don't think on coldfire it is enough, perhaps with some adjustment on 68080 could work, video is so slow.

I'm too tired in this moment to do anything, I will look what I can do after hollyday if I'm better.

Olivier

[joska]

While I agree with many points with you, I think you exaggerating here a lot. Of course it's still possible, even with the old gcc 2.95. The fact the snapshots are cross compiled is a convenience, not requirement.

That would have been great if it was correct, but at least here I'm not able to compile with 2.95 (standard EasyMiNT install from ~2006), compilation fails when compiling libkern. Just downloaded the current sources and tested on my Milan060. IIRC I managed to compile Helmut's branch with 2.95 a few years ago but from what I can see that branch is very out of sync.

Just to be sure that my gcc setup hasn't been damaged I compiled an ancient kernel I had on my Milan, and it compiled fine.

[ThorstenOtto]

That would have been great if it was correct, but at least here I'm not able to compile with 2.95

That might be true, i think 2.95 isn't supported anymore. But this is only a matter of the compiler version, not whether using native gcc or using a cross-compiler.

PS.: all that discussion here seems a bit OT, i just wonder that Vincent didn't complain yet

[mikro]

That would have been great if it was correct, but at least here I'm not able to compile with 2.95

Not sure whether you are so determined to prove everyone that older is better or just lazy to verify your claims but no, you are wrong. It is possible to build latest freemint sources with gcc 2.95.

The particular error you're seeing is coming from the fact that at some point 'as' from binutils had strengthened its policy what is and isn't allowed in .S files and FreeMiNT had to cope with that if we wanted to compile the sources using latest tools (what we did).

So to make your "impossible" task possible, you have to upgrade binutils. I even give you a step by step tutorial for your EasyMiNT:
- rpm -e --nodeps binutils
- wget http://mikro.atari.org/files/gcc/m68020 ... nt.tar.bz2
- cd / && tar xjf /root/binutils-2.26-m68020-60mint.tar.bz2
- cd /root/freemint
- make

Please tell me where do you see the need for a cross compiler. But yeah, this is getting way too OT. I just don't like people claiming things without verification.

P.S. For those who really want to follow the steps above one secret hint: disable -Werror, gcc 2.95 incorrectly spits out a warning or two.

[1st1]

joska, I understand your arguments about abandonware, they are more catholic than the pope. WIth your argumentation, no EasyAraMint, no Beeky, no Amitari with Atari-Works and DOOM +WAD file inside. They already contain all of these applications. I don't want that someone to integrated HDDRIVER and NVIDI, but it just has to be explained to the one who wants to install that distribution that he has to get+install HDDRIVER, and additionally to the GEM/BGM partiions one EXT2 of at minimum X GB in size, and NVDI by himself before beginning with the distribution. That's the same procedure as for EasyMiNT, except that it does not tell how big the partition must be.

[vido]

I think I'm able to fix keyboard issue but it is really strange as other software I have compiled with SDL work nice

For Mac Mini color for me coldfire is not enough it work ok on Aranym JIT only, don't think on coldfire it is enough, perhaps with some adjustment on 68080 could work, video is so slow.

I'm too tired in this moment to do anything, I will look what I can do after hollyday if I'm better.

If you are able to compile dosbox for coldfire (and other Ataris) and fix the keyboard issue it would be really great!
But first take a rest and do wahtever you like! Tis is just a hobby after all!

[joska]

Not sure whether you are so determined to prove everyone that older is better...

While older sometimes is better, this does not apply to gcc. But can you realistically use gcc >= 4 on a real Atari? The need for cross compilation (or atleast ARAnyM on a fast machine) is dictated by the resources demanded by the more recent gcc versions. So while modern gcc produces better code than 2.95, 2.95 is better in the sense that it's usable on a real Atari.

I'm not out to prove that "older is better", I'm suggesting that while current compilers are better and generate more correct code, the source code correctness might actually be worse due to a lot less testing by developers and a lot less end-users. Simply a result of not using FreeMiNT for real-world work anymore.

So to make your "impossible" task possible, you have to upgrade binutils. I even give you a step by step tutorial for your EasyMiNT:

Thanks, but this does not solve my problem. I actually didn't see the error your mention. I may have already upgraded binutils a while ago. The problem appears to be somewhere else in the toolchain. The (to me incomprehensible, but certainly very clever) build system is supposed to autogenerate makefiles in the .compile_XXX folders, but for some reason this fails for the 030 target. If I cd to sys/libkern and then make 030 it works. I could now make a 030 kernel.

Then I tried to build a Milan kernel, which failed when building dos.c.

I'm sure you're right that it's possible to build with 2.95, but not out of the box. I guess because - as I've already mentioned - nobody actually compiles MiNT on an Atari anymore. Or are there people that are actually using gcc >= 4 on real hardware? If so I would be interested in hearing from them.

- wget http://mikro.atari.org/files/gcc/m68020 ... nt.tar.bz2

Did you test this on EasyMiNT? Because EasyMiNT wget does not handle the redirect to https.

- cd /root/freemint
- make

And did you test this? This will attempt to build a coldfire binary of libkern and not a single kernel will be built. Yes, I know how to work around this. Anyway, as pointed out this thread is not the right place to discuss these details. I will complain on the MiNT-list sometime in the future.

And yes, I know I sound like a grumpy old fart. Probably because I am. I highly appreciate the work and effort that's put into MiNT, and I certainly understand how open source software has made this possible. I guess what frustrates me is that retro computing is becoming more and more like the classic car scene: People are upgrading and modifying and polishing and admiring their cars, but when they take the car outside it's usually on a trailer.

[joska]

joska, I understand your arguments about abandonware, they are more catholic than the pope. WIth your argumentation, no EasyAraMint, no Beeky, no Amitari with Atari-Works and DOOM +WAD file inside. They already contain all of these applications.

Exactly. Of course, ignoring copyright is an alternative and solves my first issue. I have done so myself many times. But what about (2) and (3)?

I don't want that someone to integrated HDDRIVER and NVIDI, but it just has to be explained to the one who wants to install that distribution that he has to get+install HDDRIVER, and additionally to the GEM/BGM partiions one EXT2 of at minimum X GB in size, and NVDI by himself before beginning with the distribution. That's the same procedure as for EasyMiNT, except that it does not tell how big the partition must be.

Yes, and those are the areas where most people got stuck. The problem is that a surprising number of people does not read instructions. Those that do generally did not have problems with installing EasyMiNT.

Anyway, it is fully possible to create a very good distro which is almost idiot-proof. I would love to do so myself, but the problem is the amount of work involved. It is not a one-man job. I made the FreeMiNT setup for the Firebee (which is a very simple setup compared to the one you envision) almost entirely on my own and eventually dropped it due to the amount of time it took. And that was the easy part, other people had to make MiNT actually work on the Firebee or painstakingly create several hundreds icons for the desktop.

[PeterS]

Some years ago I have compiled "dosbox" it was working but keyboard was absolutely wrong and never try to do working, but dosbox is not difficult to compil with SDL as I remember.

Dosbox would be great to have on the FireBee, Milan 060, Hades 060, Vamipre, ...
About the keyboard maybe it would be great to contact Partice abour SDL. Maybe there is a bug?
He is realy nice person ready to help and recently I contacted him about GFX bitdepth bug in SDl and he fixed it really fast.

I would also like to see Hatari version which was compiled by Vincent. It is not that bat on the FireBee. It could be usefull in some cases. But if I remeber right there is also problem with the keyboard. With some optimisations I guess it couls be usefull o the FireBee not to mention Aranym.

Ahhh ... and Mac Mini Color! I know someone using it Monochrome version is great on the FireBee

I did a quick test of DosBox when it was released and it worked fine apart from the keyboard which was unintelligible.

[BlankVector]

Dosbox would be great to have on the FireBee, Milan 060, Hades 060, Vamipre, ...

I compiled it long ago, and I was even able to run a few very old MS-DOS games (I can't remember which ones... Maybe Pac-Man or something like that).
DOSBox for MiNT

BUT

• It is extremely slow, even on ARAnyM-JIT
• There is still the keyboard bug. Only a few keys work. I was too lazy to investigate that (in SDL?), but if someone has a look, I'm pretty sure it could be improved.

[vido]

I compiled it long ago, and I was even able to run a few very old MS-DOS games (I can't remember which ones... Maybe Pac-Man or something like that).
DOSBox for MiNT

BUT

• It is extremely slow, even on ARAnyM-JIT
• There is still the keyboard bug. Only a few keys work. I was too lazy to investigate that (in SDL?), but if someone has a look, I'm pretty sure it could be improved.

I tried your dosbox and hatari you compiled. I was satisfied with both of them on the FireBee except I think they both had keyboard problem.
Such emulators are good to have even if they are slow as they could be used to convert files or something like that and some software is useful even if emulator is slow. But if someone would take some time to optimize it I believe it could be faster.

I think emulators realy make sense on the FireBee and other Atari clones as they allready have limited compatibility with original Atari computers.

[joska]

I have no experience with developing with SDL on Ataris, but my impression when I test SDL based software is that keyboard handling is iffy in all of them. SDL reports keyboard events both when a key is pressed and when a key is released, but there is no clean way to detect a key *release* in TOS. I don't know how SDL solves this, but it seems to be room for improvement here. Ideally this should be done in MiNT by adding a proper API for this.

[ThorstenOtto]

I have no experience with developing with SDL on Ataris, but my impression when I test SDL based software is that keyboard handling is iffy in all of them.

Most of this problems usually result from different keyboard layouts. Even when designed for the same region, PC and atari keyboards are just different.

SDL reports keyboard events both when a key is pressed and when a key is released, but there is no clean way to detect a key *release* in TOS.

Not on the BIOS or GEMDOS level, but the keyboard controller (and that is what is usually emulated) behaves similar, it sends a scancode for both keypresses and releases.

Ideally this should be done in MiNT by adding a proper API for this.

IIRC dosbox does in turn use SDL, so that wouldn't help much.

Without taking a look at dosbox, i would bet that there are just too many layers involved there (host system with several layouts, SDL translating them to Atari scancode, TOS or Mint translating through keyboard tables, then dosbox translating that back to pc style scancodes).

In general you can't expect much there. After all, you are either running one emulator in another, or on a system with just not enough power. It would be more a prove of concept, or maybe to run some really old games that aren't available elsewhere.

[joska]

I'm not talking about emulators, but SDL-applications/games running on a real Atari. I'm experiencing the occasional lost keypress/release.

Not on the BIOS or GEMDOS level, but the keyboard controller (and that is what is usually emulated) behaves similar, it sends a scancode for both keypresses and releases.

Exactly, you must hook into the keyboard interrupt vector and decipher the IKBD data to detect a key release. This is not very clean.

IIRC dosbox does in turn use SDL, so that wouldn't help much.

Not sure what you mean. If the OS offers an API to the keyboard data stream and SDL use this API, then keyboard support would be improved.

[jfl]

But can you realistically use gcc >= 4 on a real Atari?

I guess it depends on what you mean by "real Atari" and "use". I used GCC4 quite a lot on my FalconCT63 and now on my Firebee. I wouldn't dream of using it on a bog standard Falcon or TT though, and I don't compile heavy stuff too, just my own programs.

[BlankVector]

SDL reports keyboard events both when a key is pressed and when a key is released, but there is no clean way to detect a key *release* in TOS. I don't know how SDL solves this, but it seems to be room for improvement here.

SDL for Atari can use several drivers for keyboard input. It can be selected with the SDL_ATARI_EVENTSDRIVER environment variable:

Code: Select all

SDL_ATARI_EVENTSDRIVER
 Set to 'ikbd' to force IKBD 6301 keyboard driver
 Set to 'gemdos' to force gemdos keyboard driver
 Set to 'bios' to force bios keyboard driver


See full Atari documentation there:
http://hg.libsdl.org/SDL/file/d684a767e240/README.MiNT