Eye-Candy

Not that it is really useful, but with some small icons the gui looks even more like WinUAE.
Other than that I am optimizing my build environment a bit at the moment, so that I can build for different AROS architectures from one source tree. Yes, I know, I could use the AROS build system. I just like to write Makefiles and use them, the way I want ;-).

Janus-UAE2 Picasso96 working

Some many hours of debugging more, I managed to get the first Picasso96 / uaegfx screen to work:

Merging the WinUAE Windows render calls to the SDL render calls used in Janus-UAE2 was not so trivial as it seems. Finally I was just missing the call to update the display after drawing, so I saw a blank window for a long time. Luckily while debugging this, I cleaned up a lot of the code and fixed a bug or two. So after finally finding the right place to update the window contents, everything was working at once.

Bad weather outside is sometimes good for coding :-).

Janus-UAE2 (WinUAE port)

After a long break (and a long silence here), I returned to my WinUAE port. It still had no Picasso96 support, something which annoyed me a long time now. Problem was, that even everything looked ok (to me), as soon as the uaegfx monitor was added, it crashed. As both uaegfx and rtg.library are closed source, debugging it was a nice lesson, but lead to no results.

So I compared all uae generated 68k library and modeinfo structs with the fs-uae structs and (for me) everything looked ok.

So after quite some debugging, I decided to annoy Toni with my problem .. and he pointed me to a zero clockrate in my modeinfo structure .. which really caused the above mentioned crash.

Problem was, that I added

int default_freq = 0; 

as a stub in aros.cpp and while merging newer WinUAE sources later obviously changed picasso96_win.cpp as a quick hack to make it compile to

#ifndef __AROS__ 
int default_freq = 50; 
#endif 

which finally lead to a zero PixelClock..

Big thanks to Toni for pointing me in the right direction!

So now I can see all Picasso96 modes:

 When I use the screenmode, I only get a blank window, but in my debug output, I can see some chars rendered a least:

I hope, the path to some usable output will be shorter than the bugfixing of the screenmodes..

FinalWriter for Windows..

While searching for some old FinalWriter documents of mine (which I have so far not yet found..), I discovered the old Windows FinalWriter Demo Version..

Testing the GUI

and enabling some hardware ..

Not that those are working (haven't tried), but nice that they show up at least.

Bug fixed (hopefully) - part 2

The problem with bugfixes, that try to fix randomly appearing bugs, is, that you can never be sure to have it really fixed. So one day after the last post the bug appeared again, just under a little bit different circumstances.

So back to bug-hunting again, but I was sure now, that the problem is in the Zune Listclass, not in my code. So after some time I discovered, that the Listclass stores the sizes of the columns of each line in an array, which gets allocated at object creation time.

WinUAE does not create Listviews with a certain amount of columns, but increases the amount of columns after object creation. So in my Zune-equivalent columns got added after OM_NEW, too. Which caused the dimensions-array to grow outside of its bounds.

So my last commit to the AROS-SVN now should fix this issue and the bug should be gone now  (until my next post here shows otherwise).

The really sad thing is that I added a note in the List-Class some time ago, that this array might cause problems, if the amount of columns gets increased. After quite some bug-hunting I landed exactly at this comment.. So remember: Always fix the code at once. Or at least, remember you own remarks.

Scary as it is, looking back one year, I posted a screenshot already, which would be suitable for this post , too. Fast progress this is not :-(.

Bug fixed (hopefully)

Not much progress on WinUAE on AROS the last months.. why?

I never got the harddrive tab working reliable. Adding a new harddrive with the gui always resulted in a TLSF memory allocation error and I had no idea, why. The pool was damaged somewhere..

So I searched and debugged for .. many hours. Too many, so I always stopped hunting for the bug after maybe 5 hours and gave up. And restarted weeks later. And restarted.. and the last start was finally successful :-).

The gui in that AROS WinUAE-port is quite different from an "usual" zune gui: It is not created at once, but added with single calls gradually, as the gui is built by the original WinUAE gui sources and some glue code (remember gtk-mui? now the same happened with the windows gui tollkit ;-) ).

So it calls MUIA_List_Format no only once or twice, but in one place more often than 6 times, enlarging the format by 1 every time. Until 6 everything was fine, 7 it crashed. When I discovered this yesterday, I had at least a reproduce-able crash. And today I think I found the culprit: In the AROS list.c code some memory was not cleared in ParseListFormat, before using it. And so it happened, that there was no terminating NULL pointer at the end of one array, but some garbage.. which caused the crash most likely.

After adding MEMF_CLEAR, it finally seems to be reliable:

Quite some hours wasted here..