o1i's Planet AROS

(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.

What's new

I have just uploaded a small update again to the Subversion repository. In this update you can find the following changes:

Implementation of all form of the following addressing modes for both as source and as destination addressing:

immediate long, word, byte;
indirect addressing: (Ax);
indirect addressing with pre-decrement: -(Ax);
indirect addressing with post-increment: (Ax)+;

Implementation of instructions:

MOVE.x #imm,Dy;
MOVEA.x #imm,Ay;
MOVEQ #imm,Rx;
MOVE.x Rx,Ry

Code was refactored to avoid repetition of the same code chunks in the addressing modes and instructions.
Implementation dumping the compiled code to the console.
New configuration (comp_log_compiled) is also added to turn it on/off.

Featuring...

It is always exciting to find out some magic details about the internal behavior of a complex system. I remember when I realized for the first time how the texts are stored in the Commodore Plus/4 games, back in the days. I was amazed how I can change the text that showed up on the bottom scroll of Tycoon Tex.

Let me offer some small excitement to you all: I just implemented a funny little feature in the E-UAE JIT engine. Now we can turn on dumping the compiled code to the console, together with the original Motorola 68k instruction that was compiled and the macroblocks that describe the intermediate translation form.

The purpose of this feature wasn’t (purely) the entertainment, but I was really fed up with the situation that the generated code cannot be debugged properly. Previously, I added a trap instruction (tw) into the translated code at some point, so I was able to have a look on the output from the Grim Reaper window (which was awesome, but let’s not mix it up with actual debugging).

Too bad that GDB is so limited: it cannot debug into any code segment that wasn’t loaded by DOS (like generated code). Not to mention how cumbersome the console interface is... (Or am I missing something? Enlight me please.)

I would like to thank Frank Wille the sources for the PowerPC disassembler that makes it possible to list the translated code.

How to turn on this feature: there are two settings that control the logging. These are:

comp_log – if it was set to “true” or “yes” then the JIT logging is turned on and dumped to the standard output.
comp_log_compiled – if it was set to “true” or “yes” then the compiled code is listed through the JIT logs.

Let’s see a small demonstration of this feature, shall we? (Not for the faint-hearted!)

The following list is the output from the very simple test code: iamalive.asm, slightly edited and formatted for educational purposes...

M68k: ADD.L #$00000001,D1

Mblk: load_memory_long
Dism: lwz r15,64(r14)
Mblk: load_memory_long
Dism: lwz r3,68(r14)
Mblk: rotate_and_copy_bits
Dism: rlwimi r15,r3,16,26,26
Mblk: load_memory_long
Dism: lwz r3,4(r14)
Mblk: load_register_long
Dism: li r4,1
Mblk: add_with_flags
Dism: addco. r3,r3,r4
Mblk: copy_nzcv_flags_to_register
Dism: mcrxr cr2
Dism: mfcr r15
Mblk: rotate_and_copy_bits
Dism: rlwimi r15,r15,16,26,26

M68k: MOVE.W D1,(A0,$0180) == $00dff180

Mblk: load_memory_long
Dism: lwz r4,32(r14)
Mblk: add_register_imm
Dism: addi r5,r4,384
Mblk: check_word_register
Dism: extsh. r0,r3
Mblk: copy_nz_flags_to_register
Dism: mfcr r6
Mblk: rotate_and_copy_bits
Dism: rlwimi r15,r6,0,0,2
Mblk: rotate_and_mask_bits
Dism: rlwinm r15,r15,0,11,8
Mblk: save_memory_long
Dism: stw r3,4(r14)
Mblk: save_memory_spec
Dism: mr r4,r3
Dism: mr r3,r5
Dism: rlwinm r0,r3,18,14,29
Dism: lis r5,27315
Dism: ori r5,r5,23016
Dism: lwzx r5,r5,r0
Dism: lwz r5,16(r5)
Dism: mtlr r5
Dism: blrl

M68k: BT.B #$fffffff8 == 0000001a (TRUE)

Mblk: save_memory_long
Dism: stw r15,64(r14)
Mblk: save_memory_word
Dism: sth r15,68(r14)
Mblk: load_register_long
Dism: lis r3,27606
Dism: ori r3,r3,45096
Mblk: save_memory_long
Dism: stw r3,76(r14)
Mblk: opcode_unsupported
Dism: li r3,24824
Dism: lis r4,27315
Dism: ori r4,r4,21752
Dism: bl 0x7f91acc0

Done compiling

Colorful, isn't it? :)

Okay, let's try to understand what is going on.

I marked the three Motorola 68k instruction that was compiled here with orange color, the code roughly looks like this:

1. Increase register D0 by one;

2. Put the content of register D0 to the address that is calculated by using register A0 plus offset of 0x180 (A0 was initialized previously with the value: 0xDFF000, which is the base of the custom chipset memory area) - in layman terms: load it to the background color.

3. Go back to step 1.

Now, let's see the second level of the list:

First of all the prefix "Mblk:" marks the macroblocks (white), "Dism:" is the actual PowerPC code (yellow).

As I already mentioned earlier: some macroblocks can be optimized away (although it is not implemented yet), and a macroblock means at least one PowerPC instruction, but it can be a series of instructions also.

The steps can be interpreted roughly as:

1.1. Load the arithmetic flags from the memory where the interpretive emulator stores them.

1.2. Load the previous content of the emulated D0 register into a PPC register.

1.3. Load the constant for the add instruction (one) into a PPC register.

1.4. Add the second register to the first one (increase D0 by one).

1.5. Save the arithmetic flags after the operation.

2.1. Load the previous content of the emulated A0 register into a PPC register.

2.2. Add the offset (0x180) to the content of A0 and load it into a new PPC register.

2.3. Check the content of the emulated D0 register to set up the arithmetic flags according to it.

2.4. Save back the modified D0 register to the memory for the interpretive emulator.

2.5. Calculate the offset and load the function address for the memory write operation handler and call it (namely the custom chipset write handler). This is a function from the interpretive emulation and it was written in C, therefore we must store all volatile registers back to the memory, the C code won't preserve these. (This is why we stored the D0 register in step 2.4.)

3.1. Save the arithmetic flags back to memory where the interpretive emulator stores them. (These were kept in a non-volatile register, so these were preserved while we called the helper function in step 2.5.)

3.2. Update the emulated PC register to the current state for the following instructions.

3.3. Call the interpretive emulation for the branch instruction (because it is not implemented yet, so we reuse the interpretive implementation).

4. Done. Phew.

Funny, eh? :)

If you are not familiar with assmebly then don't stretch yourself too much by trying to understand this techno-blahblah.

For the rest: who can spot what can be optimized on the compiled code?

What is Jack?

Jack is a great, multi-purpose commodity for AmigaOS, AROS, Classic Amiga, MorphOS and now WarpOS.

Show me:

http://www.youtube.com/watch?v=t5DmlQmyzbY (February 2012)

Since I just bought a new SSD and I am about to reinstall my laptop, it is time to do another update on the project: another batch is uploaded to the SourceForge repository. (I hope I won’t lose the sources… ;)

So, what was made into this update? A quick list about what happened in the last two weeks:

Direct memory writing support
Detecting of special memory accesses per instruction and calling the chipset emulation on memory writes from the compiled code
Implementation of some instructions:

ADDQ.L;
MOVE.x register to memory;
MOVE.x register to register;

Implementation of some addressing modes:

immediate quick, like: ADDQ.L #x,reg;
indirect addressing with post increment, like: MOVE.x reg,(Ay)+;

Misc fixed stuff:

proper logging for JIT (with a new configuration item: comp_log);
slightly reworked temporary register handling;
better handling of reloading/saving of flags and the base register;
reloading of the emulated PC before leaving the compiled code is added (probably this was responsible for the reboot-loop at booting the OS, see below).

The most important change was the handling of the memory writes. When I started to plan the project this was one of the concerns: how to figure out which memory access requires special handling and which one can hit directly the emulated memory. By overcome of this issue all three problems are resolved:

memory accesses are emulated as it is needed;
self-modifying code is handled by using the processor cache;
translated code lookup is managed by simulating the cache lines.

Luckily, the x86 JIT implementation already solved this issue (too): every instruction is executed by the interpretive emulator first for a couple times to prevent unnecessary translation of the code pieces that won’t be executed often (like initialization/cleanup code). While it is doing that it collects some information about the executed code that can be reused for the translation. One of these is the memory access type. Very clever solution, I must admit.

I am still chasing the ghost-bug that prevents the OS from booting. The recent fixes for the PC register (program counter) reloading changed the behaviour. Instead of running around in a reboot-loop, the OS is waiting for something to happen, most likely some hardware to trigger something. So, it is still no good, but looks a bit better.

Where to go from here: more addressing modes and instructions will be implemented before I start working on the implementation of the optimizing routines. First, I want to make sure that most of the Mandelbrot test is executed using compiled code, thus it will be easier to test the optimization and finally we can see how better the JIT performs than the interpretive. Exciting!

You have probably noticed that the state of the project on SourceForge is still pre-alpha. I don’t want to change it while the OS cannot be run on the emulation, so this is the other important goal.

So much for today. While you are enjoying the sunny, warm summer, don’t forget about us who are suffering from the cold, rainy days: Winter is coming… :/

Just for breaking the silence after a long time, I want to tell you, that I did not loose interest in AROS or uae. It's just "some" missing spare time ;). Nevertheless quite some stuff happened behind the curtain (and will stay there, until it is done).

Another showstopper was, that my old build environment stopped building working AROS binaries, when I tried to do parallel ABI v0 and ABI v1 builds. First I was not able to build the AROS tree at all. It took me hours to get a working tree .. bad especially, if you only have a few moments a week time, to do something productive and all you get a build errors..

But after a lot of fiddling, both AROS ABIs built and booted fine. Binaries from one ABI crashed on the other ABI. Looked good.

The only problem was: Neither of "my" ABIs worked on the official builds. Binaries built for "my" ABI crashed on Icaros, without even entering main. Well, quite some hours of debugging (and thus weeks..), I decided to give up my old build environment and start from scratch on a fresh linux machine.

As my build environments all run on virtual linux machines, setting up a new machine is quite fast. I chose Debian squeeze as a base system. Installed it with minimal packages (template "ssh-server").

As maybe one or another might try to do that, too, these are the packages, I had to add:

apt-get install subversion
apt-get install xterm
apt-get install gcc
apt-get install automake
apt-get install bison
apt-get install flex
apt-get install netpbm
apt-get install make
apt-get install libpng12-dev
apt-get install bzip2
apt-get install g++
apt-get install libx11-dev
apt-get install libgl1-mesa-dev

Especially bad is, if you don't have libx11-dev, as you can build AROS without errors, but you only get an emergency shell and it is not really obvious, that this package is missing during build time.

But now, guess what, I can run the ABI v0 binaries from my builds on Icaros again :)!

So now I just have to get janus-uae building on the new machine, still some way to go..

PS: And even something to celebrate, this seems to be blog post #100!

Krzysztof 'deadwood' Smiechowicz released an update of his MPlayer port for AROS/x86. It is based on Fabien 'Fab' Coeurjoly's current MorphOS version of the video player.

Download: mplayer-1.0-v4.i386-aros.zip (6 MB)

I've already been told to change the Blog or create another exclusively for Kitty. Well I might consider that in the future... But right now I'll keep sharing Images that several artists have produced regarding the Kitty Character. You can send directly to my email - just like the next one.

This one is from Sami Ryhänen (Thanks a lot Sami):

And she's a real fox! I really like the what the artist done with the hair and subtly worked around the feline pose. Besides I'm a real sucker for purple/magenta in the background!...
So here's one more Kitty - keep it coming.

Also I've added the Mascot reference to Wikipedia to AROS: http://en.wikipedia.org/wiki/AROS_Research_Operating_System

I've also tried to add AROS Kitty as an entry to Wikipedia (http://en.wikipedia.org/wiki/Wikipedia_talk:Articles_for_creation/AROS_Kitty), but unfortunately it got halted, with the comment that "The mascot doesn't appear to be independently notable of the OS".

But like Alain Thelier wrote me:

Like Tux is not independently notable of the (Linux) OS.
You can make "Tux plush toy" or Tux mug" but it will remain an object with the Linux penguin
Whatever usage (game,object,etc...) you will do with Tux it will remain (in all minds) the Linux penguin
So Tux dont have independance.

Tux in Wikipedia

I guess it really sums it up my opinion. But I got to cover my bases well before I attempt to reason with the Wikipedia editor.

More images showing Kitty - Well here's a link to the banner of the natami forum:

Yep... It's Kitty on the Floppy Disk...

And another from Manu that it is in his site (Slipped this one):

I usually stay far away from the subjects at hand, but I believe that people give too much sentiment (in a loss for a better and no insulting term) to CUSA bussiness.
And that's what we are talking about - Business!...

On a recent Amiga.ORG thread someone gathered a bunch of questions for the CEO of CUSA, and here are the answers.

So here's my (and maybe a whole lot of people) perception of the ongoing projects and companies involved or indirectly contributing to the Amiga... hmmm... thing?!...

Well that might sound biased, but the truth is that people are making assumptions on what is right, or moral or convenient... That's a perception regarding what seems the goals and envolvement of diferent parties (which might be wrong on all accounts). There's no judgement passed here.

Not long ago (maybe 5/6 years ago) AROS was widely recalled as a EVIL or PROFANE piece of software that was hurting the Amiga community and legacy (and all other related terms)... Then it passed as gimmick, a toy and nothing would ever come of it.
Guess what - in 2012, people are starting to say "Well it may just be the future of AmigaOS"...
Some people which would claim a sanity/reality check on people advocating for AROS...
What has changed? Certainly not in financial terms... Things still being done at the expense of the developers good will and some bounties...

So I guess you should look at these image for what it is, and not what is meant to represent. There are some good intentions, but in (again that word) a reality check the words from CEO from CUSA (Barry whatever) sound reasonable to most of us, if we detach ourselves from the Amiga sentiment present in all of us. Liking it is quite a different thing, but does it really needs to be fighted?

I don't see me buying any hardware from CUSA, but hell - if they have the means to do what they want with Amiga name, am I going on terrorist rampage? Hell, no!
People will recognize good value for their money, and that's not Amiga brand that will change that aspect - CUSA will have to prove they have a better product. And for all accounts it might not do Amiga Community after all.

Although I really hoped the Amiga name had something to do with AROS/MorphOS/OS4 (that's just my humble opinion and you know what they say about opinions)....

Loved this passage:

Do you plan to begin some sort of a cooperation with the Amiga
community that has nurtured the legend for so many years?
What I mean is to convince (in a financial way) three Amiga
teams (AmigaOS, MorphOS, AROS) to work on one operational
system dedicated to one machine created by CUSA.
Unfortunately, there appears to be much animosity between the next
gen Amiga OS teams. We’ve made it quite clear that we would like
AmigaOS running on our x86 machines, so in terms of usefulness to
the collaboration, Hyperion could potentially do that with the
assistance of AROS. While it would be wonderful if MorphOS Team
could get involved, I don’t see how it could be directly useful.

Lovely, but truthful or even realistic? More like the intelegent answer!

P.S.: I still vouch for the Volunteers and everyone else helping those guys!...

To show some progress I checked in a massive changeset into the SourceForge SVN that represents the implementation of the following features:

Macroblock collection and handling
Code generation from the macroblock buffer
Macroblocks for many basic high level instructions that are used for the code translation intermediate representation
Temporary register allocation/freeing, flushing
Emulated 68k register mapping to temporary registers, automatic loading/saving from/to the interpretive emulator Regs structure
Compiling of pre- and post-code for the translated block
Temporary PPC register, emulated M68k register and flag flow-tracking for macroblocks
Basic functions for flag emulation implementation

Sounds quite a big chunk of work, and to tell you the truth it really was. As it seems so far my initial plansare working, the macroblocks are the implementation of the Microcode-VLIW-like approach I explained previously.

What is still missing for your happiness: there is no addressing mode and instruction implementation yet. So, basically this is still not too useful for the average users, thus there is no binary release yet.

But all of these are the foundations of the house and now I can go on with building the walls, which will be much more perceptive: addressing modes and instructions.

Unfortunately, I wasn't able to find the bug that blocks the Kickstart from running, maybe an other Kickstart file might help, we will see.

In the meanwhile enjoy this beautiful diagram of the (oversimplified) method of compiling in this implementation:

Code translation flow diagram

Jack 3.1 is now available for immediate download for all Amiga-like operating systems. Non-AmigaOS 4 users should read the notes outlined below.

For the time-being Jack can only be downloaded from OS4Depot.net.

SO WHAT'S NEW? (click on Read More to find out)

JIT-enabled Odyssey 1.16.1 Released for AROS

We are happy to annouce that the first update to Odyssey Web Browser for AROS is available. The major feature introduced in this update is JavaScript Just-In-Time compilation which enhances the performance and usability of the browser! Don't miss out on this update!

The first update to Icaros Desktop 1.4 is now available for download. It includes a faster, enhanced version of Deadwood's OWB port and provides a new feature many people were waiting for: the ability to transfer files over Windows shared folders. Network preferences have been updated with a brand new panel called "File Servers", where AROS users can place settings for Windows shares over the

First update to the popular AROS distribution Icaros Desktop 1.4 has been released. The new version comes with support to Windows XP shared folders; a faster, enhanced version of AROS OWB port and - as usual - some new games and applications.

The founder and CEO of Commodore has died on yesterday, april 09th 2012, at age 83. He contributed, without any doubt, to change the destiny of information technologies in the end of the previous century, placing on the market products like the Commodore VIC-20 and the C64. I personally wish to say my 'farewell' to the man who sold the computers which changed my life, and turned me into a geek

Few post early, i talk about some russian diskmag (oldgames7), which are based on the panorama engine done by Crhis Dragan, which lately was ported to the SDL/Freetype/etc by Ransom (Ransom was a member of some old and welknown in the past in amiga demoscene group IRIS (they do Eurochart and tons of quality demos)). He and Crhis kindly give me the sources of all their stuff, and so i port it to os4/mos/aros, what mean that any diskmag based on the Panorama will works on any of our amiga oses. And "oldgames7" was kind of first cross-platform test.

So, few days ago, HUGI 37 was released. HUGI is very old and wellknown diskmags which till the issue 34 was avail for Windows only, but since i have good contacts with authors (currently its Magic who works on hugi mostly, together with Adok) i annoy them to release amiga versions as well. Issue 34/35/36 are avail for amigaos4 only, but now AROS time is coming as well ! (for morphos there was also some port back in past).

To be honest, you can use with the current .exe any version of hugi starting from the very old issues when panorama start to be use (i think its around 15-16 or co). Through till issue 34 there wasn't a lot of amiga articles. But when Magic take a rule on diskmag, its start to be filled with more scene related content and with many (in compare with previous issues) amiga related articles.

Issue37 is intersting to read for some oldschool diskmag fans, but if you want jump to amiga articles only, then you can check those ones:

from HeadLines

Revision 2012 Warm UP: Evens & Releases. What to Expect: chapter "Other Platform releases
Special Effects in the Moview with Danny of TBL

from Behind The Scene

Desire - Comeback to the demoscene
The Making of "We Come In Peace"
Dismag Galore #2 : chapter about amiga releases
GUI on Amiga today
Amiga in 2012 - Present days
Viva Amiga Party 2012

from Interviews

Blast from the past: Mantronix of Phenomena
Top Personality: Ubik of Elude

from PartyZone

Revision 2011 report
The Amiga 25 years party
BreakPoint 2010 report

Issue37 also have a lot of good and quality music done by real proffesionals, specially for that diskmag. To add , issue have a lot of good design, art and any kind of articles, reports and interviews. Just take a look on how it looks like (screens from aos4):