23.2.15

First boot from virtual filesystem!

After implementing some more functions and some debugging, I am now able to boot from a virtual filesystem. All AmigaOS files are stored in a linux-native filesystem and mounted inside uae for AmigaOS to use:
It is still *slow*. I don't know if this is because of the missing jit, the many debug log messages or any other issues, but hey, it at least works so far :)!

Config file used contains:
filesystem2=rw,dh0:sys:m68k,0
uaehf0=dir,rw,dh0:sys:m68k,0
filesystem2=rw,dh1:work:m68k-work,0
uaehf1=dir,rw,dh1:work:m68k-work,0

18.2.15

Getting closer ..

Still no contents, but at least no hang anymore..

10.2.15

Getting close..

Filesystems in uae are very dependent on interprocess-communication. While I really thought, I got this covered and right, somehow all those semaphores always got jammed somehow, resulting in a hang, as soon as the first AmigaOS filesystem packet reached the emulation code. AROS semaphores are just different than Windows Events, which have quite some more possibilities. So I had a look at fs-uae (isn't open source nice?) and found out, that obviously they had to struggle, too, as they provide glib, pthreads and sdl semaphore based uae implementations. So, we have SDL (and pthreads), too, so why not just use that code:
Not perfect, still hangs, but at least I now can see the workbench icon of my virtual work drive. This proves, that the problem was in the semaphore code, as with my own implementation, I got a hang much earlier. Did I say, I have not much time at the moment? But this nags on my mind, so I *have* to do it.

4.2.15

Small steps..

Currently I don't have much time to work on WinUAE, but I tried to get the virtual filesystems working:
It shows up in the early boot sequence, but it does not work later on. It's a first step at least..

2.12.14

More GUI details

Not that anybody has ever used that function, but I like it. And the GUI should really be the same, compared to WinUAE:

and on AROS:

The windows font seems to be easier to read, but AROS is more optimized for 16:9 screens ;).

28.11.14

GUI!

So one thing is for sure, if I ever release a working WinUAE port for AROS, it will have a GUI ;).

In the last post, the GUI contained just some useless gadgets, without content and actions.

Current state:
  • Most gadgets show real values, read from the config files (no sliders, no listviews so far)
  • Added winuae.ini handling, so that last floppy selections and rom selections survive restarts. Still buggy, but promising. Did you know, that WinUAE writes these things to winuae.ini and not to the registry, if you create an empty winuae.ini file in the directory of winuae.exe ;)?
  • List on the left side activates the correct pages on the right
  • Reset/Quit/Start/Cancel buttons work
  • After a Zune Bugfix you can now insert floppies and change roms (still some smaller bugs, but in overall, it works). So some buttons work, should not be too hard, to expand this to many more buttons.
  • Still a lot of work remaining..
See here:


And btw, this is all ABI v1 now. I guess, you all need some motivation to test ABI v1. So once I will release alpha versions, you will have to use and test ABI v1, which will never get completed, if nobody tries to use it ;).

24.10.14

GUI ..?

First of all, I was not able to get the JIT running, so I lost motivation and started something else.

I always wondered, how the WinUAE gui was built and had a look, how a Windows gui is calculated. Well, every single "object" has fixed coordinates and sizes..!

Example:
IDD_FLOPPY DIALOGEX 0, 0, 396, 303
STYLE DS_LOCALEDIT | DS_SETFONT | DS_3DLOOK | DS_CONTROL | WS_CHILD
FONT 8, "MS Sans Serif", 0, 0, 0x1
BEGIN
    LTEXT           "System ROMs:",IDC_PATHS_ROML,3,2,260,8,SS_CENTERIMAGE
    EDITTEXT        IDC_PATHS_ROM,3,13,377,15,ES_AUTOHSCROLL
    PUSHBUTTON      "...",IDC_PATHS_ROMS,384,13,11,15
    LTEXT           "Configuration files:", 

                    IDC_PATHS_CONFIGL,3,32,164,8,SS_CENTERIMAGE

...

So GadTools would still be up to date on Windows as it seems.

I had the idea, to build a real object tree from these coordinates and then generate a Zune gui source code from it. Worked, but a lot of those boxes overlap and are much bigger than necessary. So the tree was not really the right tree. A pity, as my conversion code was working quite nice :(.

Nevertheless, I rewrote it and tried using fixed coordinates in Zune, too. (Sorry Zune purists):

So far looking not too bad ;). Now I'll have to see, how much of the Windows-GUI code I can reuse, because at the moment, those gadgets do .. nothing.