Small steps

Spare time is still an issue, but at least there were a few commits by me.

I am trying to get the pointers in sync on non-Picasso96 screens. For P96 screens this is rather trivial, as I know, where the upper left corner of the amigaOS screen in compared to my AROS mouse coordinates.

It all comes down to coordinates conversion from AROS to amigaOS.

WinUAE does this different, it just hides the windows pointer and so the amigaOS mouse is the only one existing.

Somehow I don't like this. I take the AROS mouse coordinates and try to move the amigaOS mouse exactly below the AROS mouse. For P96 this works perfectly.

For OCS/ECS/AGA screens, there is some kind of border around the screen, which (for me) is hard to calculate. But I seem to be getting there.

But as life goes, I triggered quite a bug in the Gtk GUI. It uses arrays to store the widget pointers, for example an array, which hold all sound option widgets (One widget for "mono" and so on).

Those arrays were not NULL terminated, so it was hard to say, how many elements were in there. And there were quite some code parts like that:

while(array[i++]) {

Which of course terminates not really on the end of the array. So I ended up, NULL terminating all arrays. Still some crashes. So I ended up recounting all possible elements of those arrays and correcting the size of them. Boring work, but now it stopped crashing.

Bad thing is, that I also found a too small array in code written by me ;).

So what is the lesson for today: C arrays are evil. Sometimes.


Blogger Hardwired said...

As for the option to hide the aros pointer, maybe you could add as an option!

Don't forget that you can have different imagery for AmigaOS pointers and that might collide aesthetically.

Other than that... Thanks for the continuing effort on this bounty.

No time soon, someone will want a 2nd part for this bounty!!!... ;)

5:12 PM  
Blogger Jaiminho said...

i would love to see some activities on the 68k (second phase of the bounty), but i wouldnt keep my breath (even if i wonder how much of aros would build for 68k straight).

about the pointer, seems to be out of scope, as it would be a soft pointer the right way of hide it (i dont think its possible to hide the actual hardcoded pointer)

have 68k screens is allready a big step, have 68k datatype and shell 68k magic support does make my imagination go wild, and imho the pointer is the less i would care...

as far as i saw aros and janus is allready rocking hard! =o)

4:42 AM  
Blogger o1i said...


Second part? Let's just finish the first one ;).


Most stuff should be build able, as AfA already runs on 68k. Bad thing is, that AfA has its own "quite individual" build system. But I will not take that bounty.

I think, AROS pointers are quite limited, at least in hosted the pointer seems to be very static. So you will end up having two mouse pointers, the aos3 pointer below the AROS one. Gives you a chance to see the original os3 pointer (busy etc.). But nothing prevents you from using a transparent pointer image in aos3. One could also hack SetMousepointer to always blank the aos3 pointer.

Datatypes and Shell is not part of the bounty, sorry. It is not impossible, but we'll have to see, if someone wants it or not.

9:11 AM  
Blogger Jaiminho said...

well, i had the impression that have aros self-compile ok wouldnt be hard make the build system work under aos (removing arch specific files), but maybe issues arises from the headers.

afa approach for indivdual builds doesnt make much sense, imho.(mmakefiles with the respective targets make sense, if the build system works on aros, it in theory was supposed to work on aos)

best regards.

12:49 AM  
Blogger Jaiminho said...

ps: winuae 2.0
"- 68040 MMU emulation (from Aranym) finally merged. For example Enforcer and
M68K Linux compatibility. (NOTE: not compatible with JIT)
maybe it could be better for build 68k files under a 68k-linux-hosted (in theory it was supposed to work under aos)

4:28 AM  
Blogger o1i said...


MMU support might be nice, but I would not want to lose JIT for that. And there are not that many amigaOS applications, using the MMU at all.

For building under m68k, I don't see any advantages there. We have perfect working m68k-gcc crosscompilers for Linux and so you have a stable, never crashing build and development environment.

Building under m68k/Linux might give you the same environment, but you would need a m68k-Linux => m68k -amigaOS crosscompiler. So you could also use the i686-Linux => m68k amigaOS crosscompiler. No difference, besides from much more speed.

I am currently building the 68k parts from Linux, no problems there. Besides sometimes some includes, which don't work with gcc, but this would be the same on all hosts, too.

Building under AROS won't help you for a native amiga AROS port either, sorry.

8:29 AM  

Post a Comment

<< Home