o1i's Planet AROS

April 16, 2014


Using AROS/m68k as a j-uae guest system works

Just to give you a short update, most of the problems with AROS/m68k coherency should be gone now (at least on my system). Of course Paolo will find some heavy bugs, as soon as I send him the new version ;). The only smaller thing not supported yet are window shapes, most noticeably on popup menus.

You will have to use the same theme both on AROS/host and AROS/guest, but then you should not really notice any differences between them.

Border gadgets should behave more smoothly, speed should be much better and world peace will happen of course, too. At least if Europe finally stops provoking Russia one day (sorry for Off-Topic useless political remark. NSA: no need to watch me closer).

There are now two different 68k daemon bundles, one native for AROS (elf), one for AmigaOS3 (hunk). Show-stopper at the moment is, that you also need different j-uae executables for each guest system, so at the moment AmigaOS 3 is not supported anymore.

So next thing is, to get AmigaOS3 working again, without damaging AROS guests ;).

by noreply@blogger.com (o1i) at April 16, 2014 09:02 AM


The powder Diaries -1 – The seeds are sown

I tried at least three times to write memories about this game; it was our mother lode project and writing about it in a satisfying way is a good deal of text and so is not easy. This is the first part, talking about the beginnings and how the idea came out.

the Beginning: QUAZAR, Nike and M-Type

In 1988 had occasion to met with Max,another amiga user. We were exchanging games and tools; one day he showed me a demo made by some schoolmates. Was a simple demo with a starfield and a scroller plus a ripped module but was kinda exciting for me. Since I got my amiga 500 I was intrigued by the crackers intros and, having finally the opportunity to know one of those groups – albeit tiny- was a good chance. so i started to cooperate with them.

Around the same time, i got in touch with Nicola Valentini – nicknamed Nike – that liked to swap software and was trying to learn assembly for coding; i later found out he was in the same classroom with Filippo and Max: how small world, isn’t’it? However, he was coding small intros for which i helped do the graphic and the music; it went with the nickname “Nike” but haven’t found its stuff anywhere

Filippo and Thomas lived in a suburb of Fano, called Centinarola; Especially Thomas used to live in top of a hill in the middle of marche landscape, and we were used on Fridays to reach the place and sit upstairs in the old kitchen – where he had its own lab – to do code experiments and decide what to do next.

and after a couple of simple demo, one came out that was a bit unconventional: using balls we made an animation of a figure; using the joystick we were able to move balls around and to create animation frames. So in the spring of 1990, the internally called “Pupo” Demo came out, and was a mild success.

I knew Marco Maltese since the eighties; we were both spectrum users and both were  building our games in Basic on the ZX spectrum and compiling it; actually he taught me some trick like using IN ports to read keys or joystick, or to use the IS compiler rather than the FP to have dramatical increase in speed – with the sacrifice of tihngs like DIM and other advanced instructions, though.

When Amiga started to be sold in the 500 model he was working in a local computer store in Senigallia, actually he was also dating the daughter of the store owner, but this is secondary: in its position he was exposed to a good deal of hardware and software and had occasion to test the 500 beforehand. I started to get some software such as Deluxe Paint or other utilities even BEFORE to buy my own 500, because once i saw it i falled in love with it; was able to buy my Amiga 500 in summer of 1988 and started to meddle with dpaint.

Both me and mMaltese were r-type fans and estimators, snd that was obvious: r-type came out in 1987 and set a new standard for horizontal shoot’em ups both in the graphics and in the gameplay, providing,with its beam cannon, an elegant solution to the power-up syndrome.

We begun to plan to build a worthy evolution of the game, hoping to squeeze the amiga machine with 32 color graphics – if not 64 with Half Brite – and HUGE enemy sprites. However,our knowledge of the new hardware and a proper workflow for the capabilities of the machine was unknown to us: surely the Amiga Basic would not be able to handle the mass of graphics we had in mind, and at the time AMOS was still just an hypothesis,not even vaporware. At the end our designs were mostly brainstorming and a way to improve our skills in a more powerful environment than the Spectrum and C-64 one. I was composing music on the sonix program first, then SoundFX and at the end Noisetracker – a Soundtracker clone; and he was designing ships on dpaint, but everything was kinda hanging waiting to have the way to develop. Our knowledge of BASIC was not going to cut it this time for our expectations – that included as said big bobs, maybe even lot of parallax scroll.

The project was called M-Type (a pun between R-type and the initials of Maltese), and i remember its idea was to have multiple ships with multiple way of firing; in some way this predated the idea of powder but also of the future evolutions of the R-type franchising, especially R-Type Final – that came out in 2003.

That is the problem when you live in the future: everybody else that follow your tracks – consciously or less – ends up looking like a copycat.

February 1990

At the time I was an art student; well not exactly: being sent to repeat my fourth year in Art school twice, despite my efforts and overnight work  this in italy means you are done with high school, and not in a good way. so went to study in a private institute to get my five year degree (called “maturity degree” in italy) and in the meanwhile was continuing to work on some graphics for the M-type project; my ideas were mostly on paper about semi-organic ships (imagine metal ships with blood vessels protruding from it.

Tomas and Filippo were trying to make some games to increase their skills in assembly coding; Tomas was working on a side volleyball game a la “Power spikes“, and we had the idea to use non-human characters for it; i recovered a funny hairy character i designed for an old BASIC spectrum game and made it the main player;  the provvisional name was “alien volley”.

Then one day me and nicola were talking about the recent r-type conversion – made by Factor 5 – and how we were thinking we can do it better. Was intention of nicola to learn to program in assembly, and a video game seemed to be the right project. Keep in mind that at the time there was a shortage of good horizontal shooters on the Amiga: the best so far was R-type, and then Blood Money – despite being technically good – was very difficult; plus Menace was too easy.

That spring Nicola went to a trip in Budapest with the school for five days; however, i think he got struck by a lighting or something like that, because when he came back home started to write a tool to compose maps, that we called MED – acronym for Map Editor; was a pretty simple tool that allowed to choose a group of tiles from a page and to copy it in the scrollable area, ten blocks at the time. Blocks were 16×16 pixel and 16 color depth. He also started the base code for Powder, at the time with only the ship shooting in the scrolling landscape.

And so I started to design the first map of the game: city. At the beginning the inspiration for city came to me from blade runner and the several cyberpunk stuff trending in that moment, so that the round building and the grey stones one survived all the way to the final game,albeit modified and improved. Same for the monorail tracks around; the only thing that did not survived was an olive color in the palette (thought because one of my first enemies was a flying version of my first car), replaced by the light brown.

NIKE'EM-UP ELEMS1Some early sprites that I made for the player ship when i started to work with Nicola – also see the test for the factory ship at night on the top

At the time was nicola itself to convert the IFF graphics in raw format (RAW format under Amiga mean that the bitplanes are saved one after the other uncompressed), then in the future we found some external tool for that, maybe prepared from demoscene coders.

One day Nicola shown up at Thomas since was asking help on how to fix the code for the game, that was kinda behaving poorly;  Filippo and Tomas decided to help Nicola and at the end all of them decided to join together in building the game. There have been some moments I wish was able to capture, like when Tomas found a weird routine in Nicola Code and commented aside “How the f***k is possible to wait for the blitter this way?”.

I also prepared the first music for the game; i found the guitar chords in a demo that was using wireframe graphics for text and meters (forgot the name)and loved it; at least for one year this music was on our ears while trying to test stuff. We were thinking at a way to make the music react with the game so there are at least two or three situations sketched up.

Music – Powder city soundtrack v1 – 1990 (Unreleased) from simone bernacchia on Vimeo.

Since we were still planning stuff, Nicola wanted more variety on the graphics and thought my ship was not too fancy; so i thought Maltese was the right guy and so did let him know about our project. The other liked its graphics and so at the end he was in too.

So far was able to work on the game just sporadically since was also busy with my final exams, but after the half of June, finally relieved of the taks, was able to get more involved on it.

by simonebernacchia at April 16, 2014 07:54 AM

April 14, 2014


The Powder Diaries – 2 – a Summer of Coding

A summer of Powder

The summer of 1990 has been one of the most intense times since; me thomas filippo and nicola were busy in working with powder and also trying to go to the same college. Marco was more adamant in getting in the game industry straight away and was trying to focus deeply in the game. So its work was in a more advanced state.

At the time powder was being written using the Seka Assembler, but later developers found the Asm-One assembler to be more performant and switched.

Taking advantage of its parents busy schedule, me, Maltese and sometime Tomas were using Maltese living room and bedrooms as development studio. We planned powder to have ten levels, five of which with Maltese graphics and five with mine. My levels were supposed to be (according to our internal naming): city,factory,ruins,forest and space while Maltese levels would be: sea, starships graveyard,clouds, Maze and final. Maltese also took in its hands the player ships design – for coherency and also because was better able to design the tilt of the ships.

Maltese started to sketch ships for the game and, for test purposes, adapted one of the main ships he designed for M-type to the Powder palette; Tomas andNicola loved it and started to fantasize about power ups; we were looking for a way to avoid the Power Up syndrome too,and recently we had occasion to see a Toaplan coin-op called Hellfire, where the player ship was able to switch fire positions, and thought we could have different way of fire available at once. At the beginning we had only the normal shoot and the laser, then we expanded to include homing missiles, the orientable cannon and the armored bomber. Another coin-op we took inspiration and in exchange we had parallel ideas to was Air Buster, even though rhytm and play actionwere at the end different.


The game has started using a 16 full color palette; it was the convinction of Nicola and mine that the actual use of dual playfield (three bitplanes for foreground, three bitplanes for background) was too chastising for a nice arcade-like graphic style, so we decided to reduce the frame rate at 25 fps and keeping the palette full 16 color. This would have allowed big sprites moving at a decent rate. However the code review of Tomas and Filippo shown that lot of raster time was lost and that keeping all elements at 16 colors was going to waster raster time and memory,. so they came out with an idea; it was possible to enable or disable less bitplanes using some selected palettes; they called the system SBE/SPE (Single Bitplane Enabled / Single Palette Enabled); that gave us graphic artist a way to create sprites with less colors but with interesting schemas. Then the use of those palettes were enabled by flags in the enemy editor.


This work file from Space shows all 2/4 and 8 palettes available.

Looking for a title

Well it was hard to find an appropriate name for yet another shoot’em up: most of the names were pretentious and bold looking: Thunderforce, Herzog Zwei, Cardiaxx, Io, R-Type, Salamander, etc. I suggested Powder both for the assonance to the gunpowder and also for the skill of our ship to reduce enemies to dust (in italian the name “polvere” can be used for powder, dust and occasionally ashes).

I was trying to create something that was unseen on amiga – at least at the time – like a multiplexor(?) robot made with all pieces where you can destroy the shell first then you have to destroy the internal machinery; it was supposed to be placed as city boss but at the end it had to be scrapped due to memory constraints and for the bad look of the rotated pieces.

The game graphics also got reworked. The first level to be reworked was Forest, suppsedly set in a redwood forest; palette got adjusted to a milder shade and the background tiles reworked based on some encyclopedia and magazine photos. For the ruins level I remember took inspiration from my art school books and tried to reproduce several architectonic features and monuments; plus the sky was much more in the purple tone, since the idea was we were liberating an alien world.

Factory, instead, was inspired from my night outskirts around Ancona, especially by the oil refinery, its compicated towering and piping structure and the way was glowing at night, together with the glowing lightnings over the Adriatic sea on rainstorms; all reminded me strongly of Blade Runner (guess you realized am a strong aficionado of this movie,huh?) and inner piping of structures like the Atmospheric processor in Aliens. It was sharing the original city palette at beginning.

A very important thing that hoped could distunguish powder – at least aesthetically – was the idea that every level got a different light sourcing and every object – including the player ship -would be affected by it; that meant more work but also a more immersive feeling.

Fall 1990

It was september, time for university entry tests. It was our intention to work together and,if possible, to stay together. With the exception of Maltese, more determined to work straight out, me and the programmers underwent entry tests in Cesena and Bologna respectively.

Tests were pretty hard for my background and, beside Tomas attempt to decode the barcode close to quiz answers by hand, nothing else particular comes to my mind. however at the end, the team suffered a split. Nicola was admitted in Cesena , Filippo in Bologna and finally me and Tomas went to pursue Electronic Engineering in Ancona, or “Tyrell Corporation”, as i called it inside my mind.


So in the fall and winter of 1990 my course of study in Ancona College started. The Engineering faculty is located in a place called Monte d’Ago – on the top of one of the hills surrounding Ancona; to reach it i was,from the Ancona train station, required to cross the street, reach the bus stop, take the overcrowded bus to the cemetery below, then go uphill on the slope for another 400/500 feet with no sidewalk to the entrance of the main movie-theater-like classroom located in “quota 145″ (no names for floors, just the elevation in meters). Do everything in reverse to go home, not mentioning train problems, bus problems,etc. so when possible i tried to go there with the car, but then finding a parking was sometimes next to impossible, since was not the only one.

However, was there listening to the teachers talking about disciplines that were at a WAY higher level that me, an art school student graduated from a side institute, were able to handle properly, but i was trying. I found myself trying to follow and copy almost painstakingly the most of the stuff that teachers were writing (badly) in the whiteboard; beside that, the work on Powder still continued, albeit slowly, on the evenings at home or in some of my notebooks, with sketches for enemies and maps and trying to create animations, that was a bit hard since the Dpaint version I was using was still at 3 – that means no onion skin, just a lot of back and forth on frames to make sure the animation was right.

Some reworking had been made to the factory level: after one discussion with thomas that said that the level and concept “looked like sh*t” i was so upset that modified the palette and reviewed all of the graphics already done working all night for it! Fctory was at the core of my idea of different light sources – together with space – and i really did not wanted that scrapped out!


A workfile of Factory – there are three screens full of blocks like this!
In the top left a couple blocks remaining from the old version,
that was having a much more contrasted lighting

Even soundtracks were progressing, albeit slowly. Was around this time that i created the soundtrack for space, the one for factory and had to rework the boss track that I did for city, making it the main level track, due to the fact that programmers got fed of it and that they thought the boss track was more suitable for the level action.

Music – Powder City Level soundtrack v2 – 1990/91 (Unreleased) from simone bernacchia on Vimeo.

Had also my first event-driven soundtrack done: the one for the space level; our first idea was to have at least two point of interaction: one with the energy less than 50% and the other one with less than 10%.  It was also meant like this due to the fact that at beginning we expected the player to have only one life.

Music – Powder Space soundtrack v1 – 1990 (Unreleased) from simone bernacchia on Vimeo.


by simonebernacchia at April 14, 2014 04:55 PM

April 09, 2014



As I did a quick Zune GUI for minunzip (which now was also ported to AmigaOS4 by kas1e), Carsten Siegner sent me the sources for his MorphOS program "InstantZip". Thanks for that!

It was a little bit hard, to get it compiled and at least somewhat working on AROS, especially, if you only have a few minutes spare time now and then to fix the problems.

As it seems, AROS ListView does not support mulitselection, I switched to NList-classes and now it has some basic functionality, it can at least extract single files from an archive, as you can see below.

It might still take some time (and motivation..) to get it in a releasable state, but it might happen eventually ;).

by noreply@blogger.com (o1i) at April 09, 2014 10:12 AM


Amiga / AROS: pointless bickering of a decaying world

Probably this will be considered old story from many of my readers, however i thought at the end is still good to post it.

This article was started with a more innocent motive at the begin of September, then to shelve it due to my Family visit in Los Angeles at the end of September; however i feel that is necessary to bring the cat out of the bag; i will still keep the original subject.

At the time i considered myself flabbergasted from what happened at the begin of September on the Amigaworld.net Forum: it gaves me at first a sense of despair on how the equilibrium that is building among the flavors might stall in every moment just for a word or (in this case) a theme. Things started in fact regarding a picture posted by Serk118uk on this thread on aw.net regarding the new version of Annotate on AROS using a morphOs theme by RainCaller, Christopher ‘ChrisH’ Handley added this remark:

Apart from mistaking AROS for OS4 (from a quick glance), it now seems that I’m going to mistake AROS for MOS. Doesn’t that theme break some MOS copyright?

I would much rather AROS try to stand on it’s own feet, rather than try to ape another OS that is (in many but not all ways) better than it.

The discussion went on a bit before to be put back on-topic; however, CrisH did not quit and put the same question on AROS-EXEC in this thread; plus he created a spin-off thread again in amigaworld.net here.

Well this time am pretty pleased that the members of aw.net did not pay too much attention to the bickering of Chris, and its supposed idea that an amiga-like OS should not have skins of the competitors: since was possible, people always themed their oses, is more a sort of tribute than aping (people who can skin their OSes are a little bit more computer-literate) and, especially in the Amiga and like world, almost everybody know ups and downs of the other systems so they know is not the competitor, is just an aesthetic taste, not some malicious intent to deceive almost non-existing “n00bs”.

Point taken, i still feel saddened by those threads; is really the title the most appropriate in my opinion to see how sometimes people that support Amiga and its offspring (legitimate or not) ends up shooting themselves in the foot; whether we like it or not, Amiga technology is already considered a thing of the past and even the knowledge related is slowly disappearing; so why still behave like it is still relevant whether a desktop environment is ‘genuine’ or ‘polluted’ from the other like-os and all this overzealous bickering?

Honestly amigans and like have IMO more relevant problems to solve: the original hardware and the accessories in example are starting to wear out; fortunately there are still some vendors that can provide original material, but in example is hard to replace or purchase an accelerator card or a graphic board non-standard such as picasso or bvision without ending on the huindreds of dollars/euros/pounds depending where are you located; despite this, ideas for replacement boards or alternate accelerator cards are substantially non existants or dead in the water, either for lack of documentation, for hard-to-understand still ongoing NDAs and limitations imposed from old hardware producers and, finally, for an absolutely crazy individualistic and ego-profit driven tendence of the amiga hardware designers that tend to keep progresses on their own personal projects secret and not to share with the community; recently following this thread i stumble in the pages of Majsta, a serbian(?) Amiga user that is working on its own accelerator card for A600 via FPGA; in the page Sharing he mention its own opinion, that i find pretty appropriated for this topic:


I just don’t understand Amiga community. First of all we are in situation that things are stuck for 20 years or so and people who know something want’s to keep that private. For what ??? They just don’t want to share any ideas or knowledge or experience.

For past 2 years there are only few people who wanted to help me. Others just told me something like “You want to someone do all the work for you” or “Code speaks for itself don’t need explanation???”. Also those ones who created something related to Amiga hardware spend lot of time on most Amiga forums just to laugh at my work instead of giving support and sharing knowledge.

That is the main reason why Amiga is going nowhere.

I was thinking that they would like to see that someone want’s to join them to work hard and share ideas. And if this situation continues Amiga will become nice memory and nothing more. In all my work regarding to PC, electronics, networks people wanted to help and all my life I helped others to learn but here in Amiga scene people are different.

And there is about 100 forums where I shared my knowledge and every time I found some solution I post it so people can learn from it so that they don’t need to waste time and to continue their work. Working on this accelerator I spend thousand hours to do something that someone could do for only 10 minutes and still they didn’t want to take that 10 minutes for me.

But they didn’t understand that this work is not for me that this work is for all Amiga community.

They can’t understand that era of money earning from and for Amiga is gone forever but if we unite we can do something. Few people are working on Amiga hardware and for them all others are just stupid to enter their circles and they don’t want to waste their time to anyone who want’s to work hard.

I started this project without any knowledge related to Amiga accelerators and Amiga hardware and now I m in situation to know lot of things. There are no open hard&soft databases. Where are the people who worked on old projects??? They only write something on the forums and laugh at those who are trying to create anything. They don’t have will to start new projects or share ideas regarding old ones…

So Amiga community is just Talk Talk community.

A similar project on its preliminary steps (forum in italian) met a problem in which to save time they tried to use a more recent version of the minimig core but seemed that the minimig forum either removed the link or the forum tiself became read only.

Still about the ego clash is difficult not to remember what happened to the Amiga Guru Book in 2008, or some limiting licenses to open sourced components (Warp 3d in example with a license that forbid its use on mos and AROS);  however in a way or another i already discussed those topics, but the main persisting question is when we Amigans will put down our weapons and our flags and just enjoy our hobby platform, whatever incarnation is, without belittling ourselves and others?


by simonebernacchia at April 09, 2014 06:20 AM

AROS: What is the state of Developing tools for middle and advanced Users?

On the begin of June 2012, a discussion on Amigaworld.net started by PhantomInterrogative introduced the experience made from the ADAM community (yes, ADAM, the home computer extension for the colecovision), left in the cold from the Coleco bankrupt in 1984; the post, summarized, tells how, in order to keep alive the community, users had to make the ‘paradigm shift’ to become developers of their own software; while a comparison between the two situations cannot be easily made (ADAM was not a successful machine and a 8-bit one, only a dozen users remain so far), however developers are a nowadays a rare breed among Amiga OSes, knowledgeable developers even more; due to the increasing age, even find adequate documentation for the Innards of the Amiga related OSes is pretty difficult, though efforts like the recent Amiga Wiki from Hyperion, the AROS wikibooks for users and for developers and several web sites that provide transpositions from the AmigaGuide versions exists; therefore a similar paradigm shift is probably a good idea even in the Amiga/MorphOs/AROS communities.

However, programming so far has not a task for everybody in the Amiga universe at least since the demise of Commodore (and the new system, unlike the old 8-bits, does not provide a main programming language in front of the face of the user, but that is another topic).

Right now the most rewarding way to build a proficient program in a NG Amiga system has indeed been using C/C++, and that is not on everybody skillset; other operating systems however are actually providing alternative languages that can be compiled or executed as runtime; well known are Java, Python, Lua, Visual Basic, VB.NET, etc – not to mention alternate toolkits such Flash/AIR or the latest trend HTML5; those languages and runtimes have a less steep learning curve and in some way is possible for somebody to produce simple programs or intermediate utilities and games; those rapid development tools can provide a shortcut for hobby programmers to use the Amiga systems in a more proficient way if available; but What rapid development tools (or in some cases what development tools at all) are actually available for AROS  so far?

NOTE: on the scope of the article, as middle and advanced user is meant somebody with a good experience with the system and a basic programming experience like Basic,HTML or basic javascript, able to learn at least new language basic skills with the help of tutorials and reverse engineering examples.


IDEs and Editors

Actually in order to write either code or fast text, in AROS there are four main editors available; the first is the System Editor; does not support syntax highlighting and has very basic features as copy/paste and find,however has a tabbed view that allows to have more files open at once.

For more traditionalistic coders, a port of Vim is available for AROS made by Hitchhikr; not the most recent port and am unsure whether is still working, but provides all main Vim features and syntax highlighting; usually distributed with Icaros Desktop up to 2009 as far as i know, is available on the AROS archives here.

then there is NoWinEd by Sh1nKurO; born as a base text editor to be used in a never taked-off magazine, is available throughout all Amiga systems with different look and features according to the version of MUI/Zune available; the common ones are: tabbed display, autosave, handling of UTF-8 files and autosave and auto-backup; other versions beside AROS one -due to some still unfixed Zune shortcomings – also support drag and drop of files.

Annotate! is so far the most advanced text editor on AROS; designed by Doug Bakewell then updated and maintained by Daniel Westerberg is distributed under the label Onyxsoft as GPL software; supports multiple tabs,syntax highlighting, advanced find/replace, macros, an AREXX port and – though some GUI design choices might look a bit unconventional, like the scrollbar without arrows on the left – do its own job pretty well. I used it to code my experiments with lua/zulu and it behaved pretty good. Had to investigate the xml syntax file in order to personalize it but, if you know xml, is a pretty trivial task since the file is pretty self-explanatory It can be downloaded here.

There is one Integrated Development Environments or IDE officially,called Murks!IDE that, in theory, could be used to develop applications under AROS, however i am not sure whether is still actively maintained since the files on the sourceforge.net repository are from January 2010. Murks looks kinda primitive at first sight and does not support syntax highlighting; it does however supports tabs and can be used to compile C and C++ projects.

In 2010 an user called Proto started work on an alternate IDE called Ganymede that should have, in its intentions, cross-platform and commercial; the development thread on Aros-Exec is here where Proto shown screenshot and even videos of its incoming creature; Steve ‘ClusterUk’ Jones was in contact with him and had occasion to test some development builds, however in November 2011, Steve declared in the same thread that the development of Ganymede stalled; from the images and videos posted so far, Ganymede supported some interesting features, including syntax highlighting, a scintilla-style grouping of functions, a debugging report window; was also intention of Proto to find a way to support GDB for debugging. Personally i wonder if Proto could release its work done so far as open source and let the project be finished by other developers or if he is available to set a ‘ransom’ to free the code that might be collected via bounty;

The last IDE that want to mention is not native of AROS but is a pretty effective one especially for cross-platform productivity:  AmiDevCpp is a work of Heinz-Raphael “Heinz712″ Reinke based on the free Development Environment WxDev-Cpp and Jocke “Zerohero”Birging ‘s Crosscompiler and runs on Windows. According to the AmiDevCpp web site, AmiDevCpp provides a comfortable Development Environment to Amiga Developers such as Project managment, Class Browser, Code completion and a lot more features; it also can be expanded with plug-ins that the web site call DevPaks.



PortablE is a rewrite for modern systems of the original Amiga E, made by Chris Handley; it works translating the E code in C++ code and then amking it compile by the extension PEGCC in an executable. E language has been quite known under Amiga OS in the nineties, and after the fdevelopment of the original Amiga E language stopped in 2000, PortablE was one of those projects that took over the inheritance.

The PortablE web site explains more:

PortablE is capable of generating code for both the C++ (and AmigaE!) languages, which is then compiled to a proper executable. It supports Windows, AmigaOS3, AmigaOS4, AROS & MorphOS. (It can potentially support other OSes & generate code for other languages.)

PortablE has native executables for Windows, AmigaOS3, AmigaOS4, AROS (x86) & MorphOS, because PortablE is written in E itself!

It comes with portable modules to cover stuff like file & directory access, shell parameter parsing, graphics, sound & GUIs. These portable modules are NOT always supported by all OSes, especially not by Windows yet. You can find a complete list & description of all of them in the “Standard Functionality” document, but essentially Windows only supports Shell-like stuff.

Many Amiga modules are also provided for AmigaOS3/OS4/AROS/MorphOS: AmigaGuide, AmigaLib, Asl, Commodities, Console, DataTypes, Devices (inc. AHI & Timer), Diskfont, Dos, Exec, Gadgets, Gadtools, Graphics, Icon, Identify, IFF, IFFParse, Images, Intuition, Layers, Locale, Keymap, MPEGA, MUIMaster, Resources, ReqTools, RexxSysLib, Utility & Workbench. Plus part of class, mui/*_mcc, Other & Tools. Also ‘libraries/ahi_sub’ & ‘libraries/cd_play’. (Additional modules can be added if there is interest, but the original idea for PortablE was to provide abstract modules that did not expose the OS.)

Additionally, some modules contributed by others are currently only available for some targets: ‘mui/Lamp_mcc’(OS3/OS4), ‘mui/TheBar_mcc’(OS3/OS4).

Modules that are specific to certain OSes: ‘Picasso96API’ (OS4), ‘target/application’ (OS4′s application.library), ‘target/cybergraphics’ (AROS/MOS).

For Amiga-like OSes, 256MB of installed memory is the recommended minimum. A stack of at least 100KB is also required.


In the same web site is present a comprehensive documentation, links to the original E language documentation, and together with PortablE is possible to download several examples of tools and demos to compile and test.


Hollywood name is well known in the Amiga and AROS community; as a language syntax is between lua and Basic, which makes it quite easy to grasp; its actual incarnation is at version 5.0 and has been already used to build great tools on AROS such as the Amiga [AROS]Media Center and also small tools as Acuario (a screensaver), the image viewer LookHere, the profile manager for AROS Broadway and several games.

I asked Fabio ‘Allanon’ Falcucci, developer of AMC, of the SCUILib Hollywood Library (that provide tools to create advanced GUIs) and other applications made using Hollywood to write me an introduction and summary about its features and about Hollywood and AROS:

Hollywood is a great tool and a nice choice for all people looking for a simple yet powerful programming language, it offers many modern features and it is ideal for anyone that does not like all “C” stuff and weird constructs. It is based an Lua scripting language and its programs can be run interpreted or compiled, compiled programs are something like Java programs, they are compiled in bytecodes and linked with a JIT player that executes the code when launched. Speaking of AROS it’s a great resource for begginers but also for experienced programmers just because there aren’t much high level programming choices available to code under this operating system if we are excluding “C”. Nice examples of Hollywood are LoView and LookHere, two free image viewers done respectively by Tuxedo amd me, Dental Info and Dental Canal, both commercial products developed and sold by Ferrule Media, and AMC, a Media Center developed and sold by me.

One of the biggest advange of Hollywood is the complete compatibility between all supported OSes, if the programmer does not use explicitely platform dependant features the source code can be easily compiled for almost all OSes including AROS, Linux, Windows, OSX and all amigaish systems.

Hollywood states itself as a multimedia programming language oriented to make presentation and run interactive slides but with the latest release it have become more powerful offering commands to manage almost anything you can thing about: transition effects, pictures, videos, music, samples, sprites, layers, windows, they just some examples of object you can handle with Hollywood. Hollywood programs can interact with the users with the keyboard, mouse, pad and joystick. In my opinion it’s a perfect tool to develop 2d games (even complex games) as well as applications. With the latest release, 5.0, Hollywood exposes an interface for a plugin system: virtually there is no more limitations with plugin systems, anyone now have the tools to make additional plugin available for this great language; some examples released from the author are an XML parser, SVG support, Ogg Thora & Ogg Vorbis support, and some more available for free.
Unfortunately Hollywood it’s not perfect because it’s still lacks some features, in my opinion, that should be added; for example threads are not yet supported, and there is no support for 3D graphics, moreover 2D graphics are only partially hardware accelerated and this could lead easily to slowdowns when you fill the screen with animated and moving object. Another major missing piece is a GUI framework and it’s still missing because of the cross platform nature of Hollywood: there is no common GUI framework for all supported OSes. To try to fill this gap I have started a project to build a GUI framework coded with Hollywood, full platform independant. I’ve got nice results but my time is limited and actually the project is going quiet slowly, but this demonstrate again that actually Hollywood can be used for almost anything.
The good thing is that the author, Andreas Falkenhahn, is very active on this project and listen to the community resquests implementing features or modifying behaviours suggested by the user-base.

Concluding this brief summary about Hollywood I can say that actually it’s the only choice for AROS programmers (begginers or experienced) that does not like “C” (or does not have time to learn it) to unleash their creativity.

Fabio is also the owner and main contributor of the new blog Hollywood Tools, dedicated to tutorials, libraries and applications for all systems developed using Hollywood.

Together with Hollywood is provided, only for Amiga OS and MorphOS (probably due to the usual shortcomings of AROS), the Designer program; recently updated to version 5.0, it is a graphical frontend for Hollywood; according to the Airsoft Software website it is -beside a Multimedia editor for Hollywood – also a graphical editor that supports also the SVG format.

Considered the base requirements (kickstart 3, 68020, a board using Picasso96 or CyberGraphX) i might guess that Designer might be used via Janus UAE, but would like that someone that alredy tried to confirm or deny this.

Hollywood and Designer are commercial products and for pricing I refer towards the Airsoft Software website.

Amilua and Zulu

Whoever follows me knows that Amilua and zulu are among my favorite RAD tools on AROS; however, for the uninitiated will explain briefly that Amilua is a port of the scripting language Lua made by Matthias ‘Mazze’ Rustler with bindings to the Intuition interface and Zulu is a binding to Zune; lately other bindings have been added such as socket support and SQLite recently; Some interaction with AREXX and shell script is also possible parsing the Environment variables.

Using the syntax combined of Lua and the MUI class definitions is possible to create simple GUI programs and frontends; actually Zulu is powering the front-end of some utilities by Yannick Erb,including a nice weather widget, the Theme Manager and some utilities made by Steve Jones; an advantage of Amilua/Zulu is that the script can be launched from shell and from icon via icon tooltips so that will behave like an application; to write Amilua/zulu scripts any text editor can be used, however i personally like to propose Annotate, also because there are additional Syntax Highlighting extensions (one made by me some time ago) for Lua.

On the negative side of Amilua/Zulu is: first of all that the binding does not support callback hooks (events that call a function) and that prevents the building of more sophisticate interfaces; the existing apps need to redraw the app window in order to show updates and that might make the application look slow. Mazze once said that was thinking a way to enable callback hooks via Lua instructions rather than C like Zune is expecting; wish that some more developer might help Mazze in improve Amilua/Zulu that so far shown its power and potential once improved; personally would also love to see more bindings with Cairo and other (of course to be ported) graphical toolkits like WxWidgets; some impressive demos can be seen on the Lua all-in-one archive available for Windows and Linux; though not recent it still can be used to build fast tools and even videogames; an impressive one is this quake-style game using a binding with the irrlicht engine (like to see that ported too).

By the way Amilua and Zulu are included in the nightly builds and in every AROS distro, so is easy to try out. If you new to Lua, there are some good generic tutorials in this website, plus some good hints and discussions (some of my own experiments) in AROS-Exec.

AROS Ruby and Zuby

Dave “Misterdave” Webster has been working on porting Ruby on AROS; following what Mazze did with Amilua/zulu he created a binding with MUI that end up being called Zuby (my fault? :P); however, Dave improved the binding keeping it abstract so that, unlike zulu, is not strictly tied to the MUI syntax in building Interfaces; in fact Dave has made Zuby able to use XML documents as reference to build the interface, as he shown in its blog, using Glade GUI Builder XML as reference for zuby to buid the GUI for the example shown.

Since had no news about ArosRuby/Zuby at least since last February – when the last post appeared on Aros-Exec, I asked further information to MisterDave via PM and he kindly answered:

Don’t worry, I haven’t given up on arosruby What I have been trying to do in the past 6 months is to keep the version in the Mercurial repository (http://code.google.com/p/arosruby/) as the ‘definitive’ version, which should be of release quality more or less. I tend to bundle this up and post binaries on to Aminet and Aros Archives, although I haven’t done so for a while. Ideally this should be stable enough to put into an AROS distribution or I could create a GUI installer for users to install the binary release themselves.

There are a couple of C extensions that I am working on:
* the socket library – I have been trying on and off for about 3-4 months to get this to work, but I think that there is some incompatibility between the Unix socket API and the AROS socket API, despite them theoretically being the same. This may just be a bug in AROS that has been recently fixed. I will have to download a new nightly and check. This feature has been the tipping point for me before contacting Paolone and the other distro maintainers, however, I may just go ahead anyway and add the socket library later on.

* The other part is the Zuby extension which hooks into Zune/MUI and implements the same interface asRuby-GTK for the Ruby programmer (http://ruby-gnome2.sourceforge.jp/). The advantage here is that I can just use the default Gnome GUI builder Glade and use ‘ruby-glade-create-template’ to generate the ruby stub code. Now the tricky thing is that my own version of the source for this was built rather quickly and experimentally so, while it does ‘work’, I need to get rid of some rough edges. What I need to do is to check this piece by piece and add it to the public source repository over time.

Regarding your question about your RAD article, I did set up a blog to talk about the development on arosruby back in February, however, I have only made one post so far. Hopefully this might give you a bit more of an idea about what I have planned. If you want to ask me some questions then, yes, I would be happy to.http://davewebster.wordpress.com/

As with most hobby projects, the day job takes its toll on one’s free time, however, I am on holiday next week, so hopefully I can get some more stuff pushed into the Mercurial repository. The repository has an updating changelog, so hopefully this will give you a good idea in the future of what I add, however, please feel free to nag me :) http://code.google.com/p/arosruby/source/list

Have no experience with Ruby Language, but for beginners like me there are good platform semi-agnostic tutorials on nettuts that also include screencasts; that should give at least the basic notions to get dirty with it, and then as usual, hope there will be some extra hints in the source code of the examples included in AROSruby and Zuby, however anybody that will grasp the base concepts can also write their own tutorials to help spread the technology…

[UPDATE - Misterdave did let me know that since the final code quality of AROSRuby is still not satisfying, he did not put any binaries to dowload yet; however, if somebody want to beta-test AROSruby my advice is to get in otuch with him via PM in AROS-Exec or in its own blog. ]


Recently the user Mequa started the operation of building an AMOS interpreter , rewritten in C++ that uses SDL and can be compiled for the modern Amiga systems: X-AMOS is a brand new addition to the panorama of the languages available for AROS – the first build from the begin of June – but since the roots on the original AMOS code it is expected to gain popularity pretty fast. The implementation, according to Mequa itself, is not yet complete, as answered to an user from Mequa itself on this post on Amigaworld.net explains what still is missing to have a more detailed reimplementation:

First of all, GOTO is not yet implemented in XAMOS, but may be in a future build.

For…Next is also not yet implemented, though you can use While…Wend to get identical functionality. So the current program is not yet supported.

Let’s assume, however, that a future version of XAMOS will implement For…Next in the same way as it currently does While…Wend. Then the jump-points of both the For and Next will be pre-calculated.

(Note that in AMOS, the “F” in “Next F” isn’t needed, and does nothing on that line, besides the “syntactic salt” of having to match with the variable given in “For” if not omitted.)

So then, if XAMOS is extended to support For…Next, GOTO and line numbers, here’s how that program will execute:
1) Print “I am going to Crash” ten times, and exit the For loop.
2) On the GOTO, jump back into the For loop, and print “I am going to Crash” once more.
3) On the “Next”, jump back to the For (pre-calculated jump-point). Here is where AMOS would crash.
4) On the “For”, F will be 10 or more, so jump to after the “Next”.
5) Repeat from 2), giving an infinite loop, printing “I am going to Crash” repeatedly and with F either increasing or remaining at 10.

In this thread on AROS-exec, Mequa also draw a sort of a roadmap for the further development of XAMOS:

Not in any particular order:

- SDL features:
Full collision detection (needed for games, simple collision already possible)
Multiple screen support
Screen Clone
Bob/Sprite Hot Spots (handles) including with Abk support
Bob/Sprite/Screen priority switching
Rainbows (behind screens, simple implementation already done)
Graphical text

- Language features:
Full syntax error checking (may be a lot of work – also with AMAL)
Call functions without using ()
Use of “To” syntax instead of comma
Call procedures without using Proc
Variable scoping and Global/Shared (currently all variable are global)
For…Next (as well as While…Wend)
Goto/Gosub, labels, line numbers (for legacy – usage discouraged)
Print statements with ;
Data statements

- Extended language features from AMOS:
Call procedures as functions as well as using Param (extended from AMOS)
Custom datatypes (already implemented as static types only)
Simple object orientation (much groundwork already done)

- Compiler (to C++ source) including AMAL

- GUI features:
Cross-platform IDE (may not be AROS-compatible at first or may require a rewrite for AROS).
Possible syntax colouring (in future)
Integrated sprite bank viewer

Other languages/tools


There have already been available builds of Python for AROS, since PyAROS around 2004 and then the port of Python 2.1 made by Stanislaw Szymczyk for the AROS self-compile bounty; however as far as i know nobody made any MUI binding for it (that might have maybe be called -to follow the tradition- ZuPy?) nor many of the libraries used in other systems such as PyGame have been ported yet.


MUIBuilder is a small utility that should help build MUI and Zune GUIs, created by Eric Troel and ported on AROS by Mazze; last version was a recompile of original 68k 2.3 sources and wasreleased on January 2011; despite it generates C code i guess that some medium-experienced developer can translate the soruces for zulu, being however aware of the usual amiulua/zulu shortcomings.


MuiBase is a relational database written for Amiga systems, Windows and Linux; has an internal LISP-type syntax language that allows to develop pretty complex applications and display it via ZUNE/MUI windows; through the language it is possible to define some export filters of the data as text (as far as i know no complex database formats are supported, rather CSV or similars to export).


FreePascal has been ported to AROS last year by Marcus ‘Alb42′ Sackrow; as from the Alb42 words “Lazarus is a RAD for Freepascal which is very easy to use, as GUI-API it uses the own LCL (which is a port of VCL of Delphi). IT can use variant Widgetsets, e.g. GTK, GTK2, QT, Win and some more.

Marcus made Freepascal able to generate Zune interfaces,even if not in a typical MUI fashion (with buttons statically positioned rather than the usual cascading resizeable approach of GUI; as from the latest news I know of, on March 2012 Markus was working on the port of Lazarus/LCL (that is also developed in FreePascal); the progress can be seen in its blog and in this AROS-Exec thread.


AREXX might be considered outdated by some but so far is one of the most important pieces on Rapid development since allows applications that have a port to communicate and allows also IPC control; is known that the version used on AROS is derivated from Regina Rexx and has some incompatibilities with some Amiga AREXX commands; insome case this prevents some amiga scripts to work completely under AROS. Staf Verhagen ported Regina Rexx on AROS and,as far as i know, is trying to iron some of the incompatibilities when is not busy with the ABI v1.

This article purposedly omits some projects that are present in AROS but lack advanced functionalities, like SDLBasic, that in its actual AROS incarnation has basic drawing tools but no sprites, for example.

It was my intention with this article to attempt in provide an overview of what Rapid Development Tools under AROS are actually available and how powerful they are; those tools that can allow some less advanced user to build basic applications and utilities in order to utilize AROS as base for their own projects. The situation is indeeed improved in the latest years despite i think there is still a good amount of stuff to be done.

Feel free to comment with correction, updates, additions to this article incase i omitted something or made mistakes.



   dave - 13/7/2012  3:28
its all seems very interesting, thanks , i have to ask though is AROS being forgotten and are any of the core devs going to get and port to the latest $129 Exynos4412 Quad-core ARM Cortex-A9 development board! see https://plus.google.com/u/0/106075758531242552855/posts/BKRWqcfjqCC
with the very latest Linaro SIMD optimized builds as the base
and can someone thats in charge please update the http://en.wikibooks.org/wiki/Aros/Platforms/Installing_on_Android etc we need to be far more visual in the ARM cortex quad space if we want more pro developers and students to come take a look it seems, thanks anyway.p.s i posted here as its easy to post directly to you as i dont have or like registering to post one off comments at al the AROS boards, please pass these coments and news along there, thanks

saimon69  - 13/7/2012  7:7

Well, if is another ARM board i think there will be chance for AROS to appear at first hosted like is happening now on RaspberryPI; do you know if there are open source graphic drivers to use for the platform above?

dave 13/7/2012  9:19
as far as im aware its using the standard mali drivers here
and Linaro optimized SIMD builds use that so not fully open as yet but close enough for most needs and a blob underneath doesnt seem so bad for a hosted OS like AROS to be built on it, it as by far the fastest ARM cortex quad there is for the moment apparently and super cheap too helps a lot.mali 400 is also going to be the defacto standard for all the cheap A10 cortex dual sticks too so it also the best base to build anything on

dave   13/7/2012  10:20

ohh i also forgot to mention the current FLOSS ARM mali reverse engineering lima project by the apparently famous linux dev Luc Verhaegen ? that write the original AMD reversed engineered xf86-video-radeonhd driversee here http://limadriver.org/ and https://gitorious.org/lima thats moving along nicely although still in the reversing stages as yet.

so again the ARM mali gfx core is the one to concentrate on
for longevity as the simplest option, its also the fastest ARM cortex gfx with 4 cores included in that SOC above too :) all good for the future if AROS is the progress and prosper and even get some touchscreen and virtual reality additions in the near future perhaps…

jers a direct link to that quad board and addon they make for it plus their links to their expanding dev sopport can be found there OC http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G133999328931

have fun ;)


by simonebernacchia at April 09, 2014 06:15 AM

Technologies:AROS: tweeting ahead :)

I started to use my binarydoodles account on Twitter also because often i have no time to write a real post; at least i can keep information flow once in a while instead of a long silence; i got my idea from what linux hater made recently,though i had my twitter account idle for more than one year. 

This does not mean,though, that am going to stop blogging: i finally had some time to work in the article already up and have another one in early stages; just that is so hard to find the time to do adequate coverage struggling also with marital life and a job that takes good amount of my daily time…  

by simonebernacchia at April 09, 2014 05:48 AM

AROS: Cooperare Necesse Est

The following is the translation of this post appeared on the italian blog on May 21,2011: despite almost one year is already passed by since that post, its actuality is still strong, especially concerning the new Directory Opus Magellan Cross Bounty and the recent Odissey Web Browser port by Fabien “Fab1″ CoeurJoly; it summarize my basic idea about how the actual NG Amiga and like Operating Systems can find a way not to compete each other but instead, in a pure “divide et impera” fashion each one cover the different market segment and promote a better interoperability.

Sorry if lately i did not took care of my posts; might seems improbable but am still putting back the pieces from my SCALE exhibit; my main laptop started to behave erratically, with long pauses between keyboard inputs up to 10 seconds, USB that is not recognizing devices and sticks and browsers that regularly freeze when am trying to watch flash videos or trying to use google voice; [fixed last year with a re-format :NDR] to this add an increased workload (and a decreased paycheck :/) to have a snapshot of my actual situation.

There is an unfinished article here where am trying to talk about the ABIv1 development and the new kernel features (like VESA screen dragging and a further modularisation); there are still several details to be ironed out, including the optimisations made by Kryztof “Deadwood” Schmiechoviz(check) for some Graphics.library functions and the actual work in progress of Pavel “Sonic” Fedic concerning the graphic subset that will target Wanderer and the GUI; worthy to mention also the hard work made by Toni Wilen and Jason McMullan for the continuous improvement of AROS 68k, now also able to boot in some real hardware machines (despite optimization is still lacking); their work also have been helpful in improving AROS retrocompatibility and in making several native libraries that were not yet created work; lastly, i need to mention that Kalamatee continued its work in improving Wanderer and in its transformation in a modular tool, which should also be possible to add “plug-ins” (like the fanous tree view shown here some time ago).

But the real focus of this article is a post that I made on the Amiganews.it forum, proposing my personal point of view on how a cooperation could be set up between Amiga OS,MorphOS and AROS. Here is the post text:

I am taking the occasion to spin-off this amigaworld.net thread where, for the third(!) time in the last six months, somebody ask if there is a way to join forces between the three Amiga and like OSes.
Since am aware of the clear differences, both architecturally and philosophically speaking, existing nowadays between the several Amiga-like oses and also of the strong opinions among their developers and users, will not discuss of it.Instead, will take advantage of the topic to underline some, for me, important points:

1) Amiga and like systems transversally cover almost all the available processors (ARM [hosted], PPC, X86, 68k for AROS, PPC on mac hW and pegasos for MOS, PPC fo os4 and 68k for classic) and price ranges (low for AROS, middle for MOS and classic HW, high for OS4);

2) is well known that Amiga and like systems are now reduced to a hobby market range with a very reduced number of users (probably all together in the single digit of the thousands) and that is a big no-no for any commercial venture since a ROI is not guaranteed;

Honestly i tihnk that those two factor are something that we should take advantage of: rather than try to have a dominating platform over the other two, right now i think the most important factor is make people aware that amiga and like systems exists, that there is a basic coherence among them and that all together cover most of the consumer computing; then would be good to work to increase the user base – no matter of what system and finally , once users are present, give them a way to use all three systems together in a workflow almost seamlessly.

Is my presonal opinion that Amiga and like systems have still appeal in the hobby market even among the non-amiga users that do not like the idea to user windows or mac and that consider linux too hard to handle properly: also, usually people does not have just one hobby: rather it might also be interested in side activities such as collections, robotics, ham radio, etc.

Think for a moment what potential can have for a person -probably even an ex amiga user that owns an old pc or an old ppc mac- and, due to the fact that those machine are by today standard and requirements obsolete, cannot use it; the possibility to have Morphos and AROS in those two machines running almost the same applications that communicate via network and therough AREXX keeping their own files synced or sharing the data processing – a case that i have in mind (because have a close experience with it) is about the fater of a close friend of mine, that used amiga to handle its Ham radio staton; right now i think is using windows but you can see how it might have been easier for him to use both AROS in the PC and the amiga, both communicating through AREXX; pity thisa example is purely academical since the ham radio software have never been ported on AROS.

I assume the fact that, for an hobbyist that includes computing in its interests (possibly amiga and like), there is an added value in using its favorite machine to accomplish hobby related tasks.But, in order to reach this optimal situation i think that some level of cooperation are required: of course i cannot expect that all os4, morphos and AROS developers decide to join forces for it; what i consider more feasible instead is that some base ground can be laid down in order to increase the interoperativity.

This can be obtained providing both developers and users of adequate tools;
For the developers is important that some key libraries and technologies are available in all three systems to make the development and porting of application easier; those may be in example MUI, AREXX,SAMBA, AHI, LUA/RUBY/PYTHON, language bindings in the same style of Zulu and Zuby, maybe some extra tool such as QT and WxWidgets [there is lately some resistance to it due to the fact that those are not native toolkits, problem is we are in a chicken-and-egg situation: NDR]; every os can handle it in a personalised way but is important that base features and API need to be common or similar;

For final users instead, is important to have a way for the three systems to “talk” and “work” together: in example two portings of the same software can talk through AREXX,or a Lua or Python script that can be made run in two different Amiga Systems but it behaves in the same way and display in the same way thanks to libraries like Zulu (my favorite) that will allow to hae common GUI everywhere.

With this approach is possible from one side to keep authonomy between all Amiga and like Systems and also keep the hold on the market segment where the system has its main focus (advantage for the flavor-specific developers) and, from the other side users are allowed to use and interoperate the flavors in a coherent way (advantage for final users); as a plus, a similar versatility should look more viable for new users towards all flavors and with more users usually there is the hope that there might be more interest for investments from commercial entities on the technology [and - with some daydreaming, if and when somebody might decide to port AROS towards other non-amiga 68k machines (vecchi mac 68k, falcon, maybe even x68000) so to allow the use of AROS even in those systems and in the same time make AROS become a vaid option to still use those system proficently for their own hobbies].

Would like to hear other opinions about my viewpoint.

Despite the text above was supposed – beside its length – to be self-explicative, want to further explore what said above:

- the first important problem is not the disappearance of one of the Amiga-like OS, rather than the disappearance of the Amiga philosophy and way of doing things as a whole: there are very few users left (as said above, in the single digit of thousand overall) and,unless made for ‘acts of love’, is simply not feasible for complex commercial programs, not suitable for the so-called average Joe and, among geeks, is either considered extinct,useless or its existence ignored, also due to the fact that new generations never used one and also that those seems to have a more ‘disposable’ approach towards consumer electronics hardware and software.

Now, with the Amiga and like OSes stuck in a stuation like this, bickering among neighbors can only do more harm than good and ultimately lead also the most hardcore fans to think it is a lost cause.

What was my proposal, then?
1) that each flavor continues to take care of its main reference target hardware and their base core technologies, since full spectrum coverage from all systems combined is, and will repeat it more and more, a vantage point;

2) An agreement is sought on the technologies (like network protocol, scripting languages and IPC scripting languages like AREXX, interpreted languages with binding like lua and zulu, GUI libraries like ZUNE,MUI [and others if required]) and in a minimum subset of commands features and API needed to have an advanced interoperability between the systems; those are basic networking and distributed computing needs though, but Amiga os and like have been sorta left behind in this part:

To tell the thuth, those tools, especially the interoperativity ones should be part of every operating system; a (big) problem of the original Amiga OS was that the OS Maker support got lost in the moment on other systems small and home LAN were flourishing (though the same home maker did not do any effort to create a network infrastructure too as far as i know) and therefore Amiga OS was left behind until third party apps and stacks did not appear; however, is indeed a basic need now to have ways for applications and file systems to interoperate between them and between like OSes and with other OSes, o course.If can also be done in a more amiga-ish way even better.

3) [is a necessary repetition] Is essential to be aware that right now the very same idea of what has been Amiga OS, its own philosophy, its user experience, its coding style and guidelines and the technologies related with it are endangered; in my opinion is very important to increase the external awareness of the EXISTENCE of Amiga and like oses, its usefulness on hobby projects and is available on omst of the processors and platforms (am a bit biased on this when i think on AROS but ppc is well covered by os4 and MorphOS too);

4) When the 68k AROS port from Jason and Toni started to deliver usable results i personally thought that this was the good time to propose AROS not only as a viable actively developed alternative for old 68k machines and homebrew hardware like monimig and Natami, but also as a viable alternate OS for other 68k platforms such as Atari falcon, the japanese x68000, and even (heresy!) ST machines and propose itself as a transversal OS for active retrocomputing use;

5) Last but not least [and another for me fundamental repetition] is the most difficult thing to do: change the way we are relating with each other; when the ‘Red vs Blue’ war was exploding on the net, i already stopped using proficiently Amiga and getting interested on it since at least a couple of years earlier and so lost (fortunately?) this part of Amiga history; as far as i hear from several users, seems that the actual state of things is broken beyond repair [in some cases perhaps kept artificially so] but then i can see people like Fabien ‘Fab1′ Coeurjoly, Itix and others help other developers to port their programs on other Amiga-like systems (see OWB, mplayer,screenrecorder); something even unthinkable just some year ago; all this reminds me the dynamics of a dying small country town like the one I grew up in Italy, as said in one of the answers to the same forum thread as above:

…am honest to say that i refuse to have a revenue oriented viewpoint at the situation, at least i refuse to think that there should be a winner system: main problemis to have a user base that is transversal to all Amiga and like systems, that should be the goal instead to behave like disputing neighbors in a small town in risk to disappearance thay, instead of working together to make tihngs such a tourims flourish to keep the place alive and thriving, mind only to fight with each other; yes because THIS is EXACTLY the actual situations; and while some of you might enjoy to be the disputing neighbor, i don’t; since i used to live and grow in a place with people behaving the same way, i feel so frustrated to see all good work and a nice potential thrown away in name of some few ego-stroking personalities.

Nothing else to add, guess the above is self-describing; so now is time to act.

by simonebernacchia at April 09, 2014 05:48 AM

AROS: Rant: Are we entitled to develop tinker and play with the Hobby OS we like?

(brief, a bit OT but effective)

Not the first time that i take this topic, but there are people out there that think about the involvement with AROS community and about tinkering with AROS as, in the order: useless, time wasting and even harmful in some cases.

Considered that am not working on any plan to overturn the world or that am not doing any active damage or boycot, i wonder why some people feel entitled to tell others what to do and how to do it, but most importantly i wonder: can I do what i like? Or better: can I use an OS that i feel more suitable for my style of computing and also try to improve it, find a way to integrate it in my hobbies and when possible in my work life, spread and endorse my experience despite its known shortcomings?

The answer might be. from an idealistic side, an obvious yes; however, despite this there is people out there that feels that sometihng like tihs is an insult or similar to that; non  uncommonly, same people profess that other solutions promote freedom…. isn’t that ironic?

Well, i know this blog is mostly dead but like opinions on it.

by simonebernacchia at April 09, 2014 05:48 AM

AROS: Sweet as a Raspberry Pi :9

First of All, Thanks to the ilCannocchiale staff for fixing comments; pity lots of more stuff need to be still fixed including permalinks…

This year had life going through and at the last moment prevented me to participate at SCaLE; might need to change home again, this time due to a problem with neighbors too long and complicate to discuss here; thank God the work side is good and have no complains.

Not too much news under the AROS front at first glance; however, as usually “look is deceiving” because we had a good amount of ports; Especially Slazard ‘Bszili’ Biro and Yannick ‘Yannickescu’ Erb are bringing to AROS a good amount of games and emulators i can remember Frogatto, TORCS (not released due to problems with GLSL), Flare, Gigalomania and lots of others; Joao Ralha, recently opened a new AROS blog called AROS Playground where reviews ported games and provides developer interviews;

Timothy ‘Terminills’ Deters is working on porting Gutenprint on AROS, on interfacing it with a generic Amiga printer driver.
Gutenprint, formerly know as Gimp Print are High Quality printer drivers based off the hpijs printer system; the name is from the fact that those drivers were originally developed for GIMP; were also adopted from Mac os X in the early version as printer drivers.
According to its plans Gutenprint will talk to the printer via a bridge software and to a generic 3.1 driver written by Jason ‘Ezrec’ McMullan; the driver written by Jason is also able to translate Gutenprint commands in Turboprint and 3.1 printer commands, however this implementation is not limited to Gutenprint; the printer driver is a 24 bit one and in the intentions of Terminills should also bring advanced features such as ipp (internet Printing Protocol), printer detection and driver auto detection; Terminills is also working at the zune based interfaces to configure the printers;
Among all the ports of Yannick ‘Yannickescu’ Erb, in 2010 was the long forgotten and neglected structured Graphics program Amifig to AROS; started a slow but steady work on updating it first improving the rendering, then adding file export and import with a side application; now a new version is available, with a new name, ZuneFig, a rewamped User Interface now in Zune, support for gradient and  Library previews and a better redraw with Anti-Alias;
Nik ‘Kalamatee’ Andrews is working on the native Raspberry Pi port of AROS; on March 14 he has been able to make AROS boot to wanderer;  the pictures of the first boot have been spreaded on the net via twitter and Amiga and AROS forums and communities; last week Kalamatee worked on debugging the SD card driver so to support also SDHC; the SD card support is also actually under further development by Pavel ‘Sonic’ Fedic to bve implemented as multiplatform device driver since the logic is changing form platform to platform; right now Kalamatee loosened a bit the grip on the port since he need to implement USB and still is trying to find a way to implement it. Curious is also that among the motivations of Kalamatee is the idea to finish its modular overhaul of Wanderer so that could be optimized for a less powerful machine like the Raspberry PI.
To finish,lately on aw.Net some threads appeared where people seems interested in a new kernel for amiga os or its like tastes; is known that in the past at least two attempts have been made: one was the well known Anubis, brought on by Alex ‘MrBIOS’ Perez, the other one was ARIX, started by Michal Schulz and from which the idea of Anubis took shape; summarizing, the idea behind those two partial forks is to have the actual exec kernel substituted by a linux one together with a wrapper that translates the AROS API calls in linux ones so that AROS binaries libraries and programs can run on top of it with no recompilation; is a similar approach to the system adopted by Android and can bring the advantage of memory protection, SMP and linux drivers to AROS; both projects have an actual unknown status and would like to know by the maintainers if there has been any progress since.

by simonebernacchia at April 09, 2014 05:48 AM

New home for BinaryDoodles

Two days ago was trying to get a look on how things were going in my blog. Got a red screen saying that ilcannocchiale.it is distributing malware. Well, that is the last straw. I decided will move slowly my posts here AND also post new articles here.

by simonebernacchia at April 09, 2014 05:48 AM

March 20, 2014

Icaros Desktop

Create ZIP files under AROS

Strangely enough, there was a (quite, relatively) simple task that was still impossible to perform under AROS: creating ZIP archives. You could extract files from them, even when password protected, but you couldn't easily create one. Well, let's write a big "THANK YOU!" to our friend Serk118uk, as his upcoming tool Arzip is fixing this issue once forever! He has also written a wonderful ZIP

by Paolo Besser (noreply@blogger.com) at March 20, 2014 05:05 PM

March 14, 2014


PPCJITBETA02 (The Beginning of a Beautiful Friendship)

We have just arrived to another exciting milestone on the long road: all the important instructions for the initial release are implemented under the JIT compiling.*

Lots of bugs were fixed, the emulator is much more stable now than the initial beta release.

Some new features are added too: I have merged the SAM440EP/Flex support (thanks to Soft3) and the CGX overlay for MorphOS (thanks to Thunder and Fab). See configuration documentation regarding how to set the overlay up.

As I already mentioned in the previous post: this beta release was delayed for a couple weeks due to a bug that slipped into the code base long time ago. It was discovered on Mac first, but I was able to reproduce it on MorphOS too. Took me a while to figure out what was going on, but it is fixed now.
This was a very tricky bug, it could be blamed for random crashes and endless loops also, not only on Mac, but on all supported platforms. It was triggered randomly based on the distance between the main application code and the code buffer in memory. (Thanks to Mike for discovering this right before I released the beta.)

I have spent a significant amount of time on figuring out how can I do the build for all supported platforms (AmigaOS4, MorphOS and MacOSX-PPC) using my environments. It wasn't easy, but finally I managed to do most of the release on my own.
As it seems MorphOS SDK does not support G5 yet, so I was not able to do the compiling by myself, but thanks to Fab the G5 executable is also available in the release package.
So, as of now users on all major supported platforms can grab the package and start using the right version.
(Sorry, Linux and BSD folks, you are still on your own.)


And the World trembled...

 ...or at least that tiny part which I am involved in when I am wearing my crazy latex suit with a huge letter "A" on my chest for my secret identity: the Amiga Software Developer.

After the first beta release forum posts, emails, news sites, blogs had risen in an enormous unmanageable thunderstorm, struck on me with insane amount of communication. (While the rest of the World barely noticed what have just happened.)
Finally I crawled through messages from every possible (and impossible) source and answered the questions to my best knowledge, accepted the good advices, kindly rejected some nonsense.



Since I received tons of feedback (good and bad), I inclined to draw some conclusions from the reaction to the very first beta release. Here is the summary for your benefit:

Some people don't understand how the JIT works and what is the exact purpose of it. All I can say is: please read the documentation... Some other (knowledgeable) folks stood up on the forums and educated the others, well done! I hope this helps, because I really don't have time to deal with it.

Many of the users have irrational expectations for how much the JIT compiling will speed up the emulator. (According to somebody: it supposed to be "ten times faster than the interpretive"... Err... Not likely. How did they come up with any number anyway?)

Well, the implementation is not finished yet, some of you guys don't really understand the concept of "beta release". Okay, I admit I was cheating a bit: technically the JIT compiler wasn't feature-complete when the first beta was done. Yet the remaining pieces were related to not too often used instructions anyway.
For the second beta the instructions are done*, yet there is clearly room for improvement regarding some bugs. Probably as soon as I will be able to fix up the optimization of the register- and flag-flow there will be a significant bump for the speed. (No, not "ten times" fold.)

It is hard to measure how much faster the programs are running and some lovely people baffled on this too. Since there is usually no obvious visual clue for the speedup and a 30%-50% increase in the processor speed is probably hard to notice while your favorite jump-and-run game is jumping and running.
Yet, you can feel that the whole emulation is more snappy than before probably even when you simply run Workbench. Except when it crashes. But even then: it crashes 30%-50% faster! :)

Too bad that some good souls are obsessed with their favourite game/program and keep saying that the JIT is worthless because it doesn't make any difference for that particular piece of software. As it seems this JIT compiling is not for you then.

There was one more interesting thing what I have noticed too late unfortunately: G5 support for MorphOS. Since I don't have a G5 machine I never considered that there is a need for that. But there were some murmur about the speed of the MorphOS version on G5 on some forums. No wonder: it needs a special version, which can be compiled from the sources for some time now. (Thanks to Tobias Netzel and to Fab for the special build.)
Probably the same applies to the PA Semi processor and the Amiga X1000, but I don't have that one either. (Donations? :)
Also the mysterious support for SAM440EP/Flex, what I have never heard of before. No wonder it was missed.

Fun fact from the Outer World: I tried to explain to my colleagues how I spent my Summer vacation. However, I am significantly older than almost any of them, so they were looking at me with confusion in their eyes mixed with a little pity. "Yea, my father loves fooling around with those old machines too!" - was one of the comments. Well put, Sir, well put.



To make you (some other geeks around the World) happy: here is the new beta...

In case you stop reading here (or you already skipped the first cheesy part):
as always, please read the README for your comfort and safety. Thanks.

Since I bought an iBook for 50 NZD, now I can produce the MorphOS and the MacOSX versions too which were also included in this release together with the AmigaOS4 version. (And by buying a Mac I broke one of my principles: no Apple product crosses the door of my house. I hope you guys are content what you were doing...)

You can find the changes since the last beta in the README file, or in the changesets at the SourceForge repository from R67 down to R53.



I must admit I have learned a lot in the past month about the sorry state of the E-UAE project. I didn't know what is the current situation of the various binary releases until I received some references to modified AmigaOS4 and MorphOS binary versions.
I guess this is the destiny of any abandoned open source project: lots of good people is trying to improve it, but nobody is standing up and takes over the maintenance of the project.

Well, I am of the same kind, as it seems. It was never my goal to take the ownership of the E-UAE project or fork it into a new iteration.
However, as soon as I released the first beta of the JIT compiled version the watching eye of the public turned to my little scared pet project and I received lot of questions about whether this-or-that particular fix from various developers were included or not. (Mostly not.)

To satisfy at least some part of the user base I tried to gather the various fixes from every corner of the Internet and applied them on the source code. This means no way new base source repository for the E-UAE project, but at least it will help whoever wants to grab the torch and probably it will be useful for you, dear user in the meanwhile in the form of the beta releases.


Progress indicator

As of now I switch from batch release strategy to immediate update. This means: I will commit each change one by one to the SourceForge repository as soon as the change is ready instead of buffering up lots of changes locally and commit them in a big changeset.
So, if you look for the repository changesets and the tickets then you can watch the progress of the project closely.

I also make use of the tickets in the completion of the various fixes and tasks:


I added milestones to the tickets, so you can get a feeling of the upcoming beta and the included changes, fixes.
Open tickets are defining the majority of the outstanding work. I am currently working on the accepted ticket, while pending tickets are already committed to the repository, but not released in binary form yet. Released tickets are the closed ones.

For PPCJITBET03 you can find the planned changes here:


There is also a milestone named "PARKED" which is a holding box for the various bugs and problems that are not considered for this project (yet).



Finally, big thanks goes to: Thunder, kas1e, MickJT, Fab, Tobias Netzel and Mike Blackburn for helping me with lots of things regarding bug finding, fixing, platform support and constantly watching out for the updates on the repository.

I am still waiting for any (detailed) bug reports, just have a good read of the README file before you jump to your email client.

*There is a fine print here: I was struggling with CMP2 instruction and finally I gave up after a couple days. The binary code for the instruction is bundled with CHK2 and I couldn't figure out how solve the exception handling for that. So, this instruction remains unimplemented for now, not a big deal luckily.

by noreply@blogger.com (Álmos Rajnai) at March 14, 2014 11:57 PM

March 03, 2014


Working in a train..

Usually I don't like to do business trips by train. There seems not to be any rationale behind that, but I simply prefer airplanes or cars. But this time I decided to take a laptop, install VMWare-Player on it and take my virtual AROS development machine with me.

So I had 5 hours time for doing some stuff and 5 more on going back. Not too bad. Maybe I should use trains more often ;).

So what did I do?
  • Closing of windows is now done with the nice AROS function WindowActionTags(WAC_SENDIDCMPCLOSE). Much nicer than placing the mouse over the close gadget and click it with a program.
  • I can now build juae with a debug option, which shows both coherency windows and the main window simultaneously, so I can see, what really happens in the guest.
  • A lot of hacks, which magically moved the guest border gadgets are gone now, as gadgets have the same dimensions both in guest and host AROS.
  • Fixed an old bug, which made border gadget moves sometimes quite buggy, even if guest was AmigaOS 3. 
  • Cleaned up dual build system (AmigaOS and AROS guest daemons)
And maybe I fixed a bug, which caused a lot (and I mean a lot, some 20/second) of unnecessary ScreenToFront calls for non existent screens. If this also happened with AmigaOS 3 guests, performance for sure suffered. I'll have to do a lot of regression tests, so that all my fixes still work with AmigaOS 3 guests..

What's next? Nothing. Will be skiing for the rest of the week ;).

by noreply@blogger.com (o1i) at March 03, 2014 04:17 PM

February 24, 2014


Greetings from SCALE

Here i am writing from SCALE in Hilton LAX: there have been some problems in getting here, mostly related to what route to take, parking validation and stuff but at last stand is up. Due to time constraints i had to reuse the old signs from 2011 and also right now broadway is still running while burning latest ARIX and icaros isos.

Digital image

the AROS and ARIX booth at SCALE 12x

Day 2

Day two seems dragging on a bit less franticly than day one; i installed the latest Icaros lite in the spare stick and now am showing it in the netbook; however old broadway had the advantage of going out in the VGA monitor and now instead gotta show the small netbook screen. So i moved the AROS video on the second screen on my big laptop and the netbook is showing now OWB in a screen on background while in foreground a music video is looping.

Icaros 1.5.2 takes 700 meg of the 4-gig card leaving 2.9 gig free, which is nice :)

BTW due to circumstances will need to wrap up from 2 pm so if you are inside SCALE please visit me until am here …

Wrapping Up

At the end the experience has been interesting; i just wonder how come am almost the only one on doing this at linux and open source conventions here in the States, that is so far a channel to try to gather power users and developers at least to be aware of the existence of this platform; is also interresting that the video I made two years ago for the exhibition but that was not ready in time shown to be a good attention grabber: a talking kitty is always nice to see ;) – for more info on the making of the video, please refer to the Vimeo page, unless you want to see a “making of”…

Introduction to AROS v0.1 from simone bernacchia on Vimeo.

Also the brochure, this year, is kinda special: since was presenting AROS and ARIX i decided for a two-faces brochure; took a while to get the layout right and at the end i went to print the same evening before the event; here is a prototype and Here is the link to download it as PDF.

AROS-ARIX brochure

AROS-ARIX brochure

by simonebernacchia at February 24, 2014 06:55 PM