B-Em and Allegro 5

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Coeus
Posts: 406
Joined: Mon Jul 25, 2016 11:05 am

B-Em and Allegro 5

Postby Coeus » Sun Mar 19, 2017 8:17 pm

ThomasAdam wrote:Having already started to look into this, it's not so much a port, as it is a complete rewrite. That's important to note, because there's very few similarities between Allegro4 and Allegro5.

That said, what interests me about Allegro5 is the backend parts. On Windows, there's the use of its native GUI stuff, and on !Windows, you can use GTK. QT is questionable at this point; B-em is written in C, not C++.

It is per this example: https://github.com/liballeg/allegro5/bl ... /ex_menu.c -- that the possibilities of having a non-modal menu are realised, which would then be platform-agnostic, AIUI.

But, getting to that point isn't a small amount of work. I should really push what I have to Github; I've been a little busy with $LIFE -- sorry, chaps. There are other changes with Allegro5 that I've not looked into yet, but from what I've been seeing thus far, I think there's sill enough of the things we're making use in Allegro4 that are available in Allegro5 -- and by that, I mean all of the video rendering, etc.

Kindly,
Thomas


I am quoting the whole of Thomas's post because it was originally in another thread.

On the question of how different they are I did find https://wiki.allegro.cc/index.php?title ... m_A4_to_A5.

The Allegro 4 main loop example we have in B-Em - in the OS-specific module there is a loop that calls main_run(). That checks fcount to see if a frame update is due and if so runs m6502_exec and a bunch of other stuff and, if not, does a wait(1). So, to implement the change to event-driven isn't it a case of putting a call to main_run(), with the checking if fcount removed, as the action in response to an event of type ALLEGRO_EVENT_TIMER?

The hairy piece of code is video_poll in video.c so the big thing is whether the format of Allegro bitmaps have changed in a way that means this would have to be changed much. Certainly this is the module in B-Em I least understand.

Did you discover any other differences? I assume linux-gui.c would need to be updated too.

User avatar
hoglet
Posts: 6129
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em and Allegro 5

Postby hoglet » Sun Mar 19, 2017 8:43 pm

One thing I'd like to better understand is the level of support for Menus in Allegro 5 on the different platforms we want to support.

The B-Em Linux UI uses the Allegro 4 Menus/Dialogs API, where as the B-Em Windows UI I think bypasses Allegro and uses Windows APIs directly.

I'd like to better understand the rationale for that split, as it means the Menus are implemented twice.

I think Menus were dropped from Allegro 5.0:
https://www.allegro.cc/manual/5/native_dialog.html

And then possibly added back in to Allegro 5.1:
http://liballeg.org/a5docs/trunk/native_dialog.html

Is it clear which Allegro 5 version we should be using?

In Optima (my Atomulator port to Allegro 5.1.8/Raspberry Pi) the Allegro Menu and Dialog APIs was not implemented on the Raspberry Pi platform, so I ended up implementing Menus using a third-party library called TGUI which ended up quite nice, but it was a lot of work.

Dave

User avatar
hoglet
Posts: 6129
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em and Allegro 5

Postby hoglet » Sun Mar 19, 2017 9:01 pm

Coeus wrote:The Allegro 4 main loop example we have in B-Em - in the OS-specific module there is a loop that calls main_run(). That checks fcount to see if a frame update is due and if so runs m6502_exec and a bunch of other stuff and, if not, does a wait(1). So, to implement the change to event-driven isn't it a case of putting a call to main_run(), with the checking if fcount removed, as the action in response to an event of type ALLEGRO_EVENT_TIMER?

This is what the Allegro 5 code in Optima ended up like...

There is an allegro timer feeding an allegro event queue at the video frame rate (e.g. 60Hz)
https://github.com/hoglet67/Optima/blob ... tom.c#L173

Other event sources like the mouse and keyboard are registered:
https://github.com/hoglet67/Optima/blob ... tom.c#L178

atom_run() now processes allegro events:
https://github.com/hoglet67/Optima/blob ... tom.c#L204

Every 60Hz, atom_update_display() is called, which does all the actually emulation:
https://github.com/hoglet67/Optima/blob ... 02.c#L1194

Under load, whole frames are skipped.

Dave

SarahWalker
Posts: 1028
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: B-Em and Allegro 5

Postby SarahWalker » Sun Mar 19, 2017 9:25 pm

hoglet wrote:The B-Em Linux UI uses the Allegro 4 Menus/Dialogs API, where as the B-Em Windows UI I think bypasses Allegro and uses Windows APIs directly.

I'd like to better understand the rationale for that split, as it means the Menus are implemented twice.

The Windows native menu is there because the Allegro menus are pretty bad, but I needed some kind of menu system for Linux. Hence the two implementations!

Coeus
Posts: 406
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em and Allegro 5

Postby Coeus » Sun Mar 19, 2017 10:23 pm

hoglet wrote:Is it clear which Allegro 5 version we should be using?

In Optima (my Atomulator port to Allegro 5.1.8/Raspberry Pi) the Allegro Menu and Dialog APIs was not implemented on the Raspberry Pi platform, so I ended up implementing Menus using a third-party library called TGUI which ended up quite nice, but it was a lot of work.

Dave


If we need menus, then the one that supports them, unless we want to to use a separate GUI toolkit directly as you did. Nothing wrong with that but no point in making work if we can avoid it.

Regarding the Raspberry Pi is that considered a separate platform? I thought it just ran Linux? Perhaps the problem is that the Allegro menus use GTK+ on Linux, at leas that's what the first few lines below suggest:

Code: Select all

$ ldd /usr/lib/liballegro_dialog.so
   linux-vdso.so.1 (0x00007fffc54c3000)
   libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007fbc23441000)
   libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00007fbc2318c000)
   libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007fbc22f65000)
   libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007fbc22d19000)
   libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fbc22ac7000)
   libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fbc227b4000)
   ...


I don't think GNOME runs too well on the Pi so it could well be that GTK+ is not installed either.

harrowm
Posts: 121
Joined: Sun Nov 30, 2014 11:07 pm
Location: Singapore

Re: B-Em and Allegro 5

Postby harrowm » Tue Mar 21, 2017 2:18 am

In Allegro 5.x (latest), menus and dialogs are implemented via native calls to the underlying OS. This works (I've tested it) on OS X, windows and Linux (Ubuntu and Debian). On some Linux distros you have to make an extra call to stop your window shrinking when the menus are drawn. AtomulatorOSX has some sample code. If you are forming a team to get this done .. I'd suggest tackling Atunulator at the same time, I'm happy to volunteer.
Malcolm

Coeus
Posts: 406
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em and Allegro 5

Postby Coeus » Thu Mar 23, 2017 3:52 pm

harrowm wrote:In Allegro 5.x (latest), menus and dialogs are implemented via native calls to the underlying OS. This works (I've tested it) on OS X, windows and Linux (Ubuntu and Debian). On some Linux distros you have to make an extra call to stop your window shrinking when the menus are drawn. AtomulatorOSX has some sample code. If you are forming a team to get this done .. I'd suggest tackling Atunulator at the same time, I'm happy to volunteer.
Malcolm


But it would be interesting to get to the bottom of the Raspberry Pi thing, i.e. why the Allegro menus don't work there. I don't know how many people use B-Em on a Raspberry Pi but if it can be used to emulate the co-processors, as in the PiTubeDirect project, then presumably it should be possible to run B-Em on a Pi.

So if you wanted to do divide and conquer on this, I think the tasks are:

1. Re-write the main loop to be event driven and set up the necessary timer events, referring to what hoglet has done on Optima (above).
2. Check/update video.c and vidalleg.c for any changes to Allegro's bitmap format.
3. Update/re-write linux_gui.c to use the new Allegro 5 menus and dialogs.
4. Related to the above, investigate the menu situation on Raspberry Pi further.
5. Resolve general issues due to some Allegro 4 API functions disappearing.

What I don't know is which or these Thomas has been working on so someone else could work on something different and merge together. So I think we are waiting for him to post what he has done so far.

harrowm
Posts: 121
Joined: Sun Nov 30, 2014 11:07 pm
Location: Singapore

Re: B-Em and Allegro 5

Postby harrowm » Fri Mar 24, 2017 8:36 am

Also,
- move to the Allegro sound libraries
- change the config files to use Allegro 5

And
- multiple windows e.g. like the debug screens look difficult and need more investigation

Coeus
Posts: 406
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em and Allegro 5

Postby Coeus » Fri Mar 24, 2017 12:38 pm

Thanks for completing the list.

On the question of multiple windows and debugging I think we should be safe here. The debugger is actually command-line-based and on Linux it simply reads commands from stdin and sends output to stdout which would normally be the terminal window from which you started B-Em. That does mean, of course, that if you arrange to start B-Em from a menu in a desktop environment you wouldn't see this but then you probably wouldn't start with the debug option in that case. If you did want a desktop environment menu item to start B-Em with debugging it would be trivial to script starting a terminal emulator with B-Em running inside it rather than the usual shell.

Using stdin and stdout doesn't work on Windows even if you start B-Em from a command prompt window so on Windows only the debugger uses the WIn32 API directly to create a console window from which it can read input and direct output. Because it uses the Win32 API directly it is not limited to what Allegro provides in the way of native dialogs.

If we ever wanted to provide a fancier GUI debugger then I agree that the very limited set of native dialogs provided by Allegro aren't up to the job. On the other hand a discussion with Fordp suggested implementing the GDB remote debugging protocol so that may enable the fancier GUI to be provided by another, external program, for example Visual Studio on Windows.

harrowm
Posts: 121
Joined: Sun Nov 30, 2014 11:07 pm
Location: Singapore

Re: B-Em and Allegro 5

Postby harrowm » Thu May 11, 2017 4:48 am

I took a look at Allegro 5.2.2 and Raspberry Pi menus/native dialogs. I'm not an expert, so please correct me if I've got something wrong:

* Allegro has been changed for the Raspberry Pi version so that there is only one full screen window. This is why there are no native menus, dialog boxes .. its like an old style full screen DOS window.
* Raspberry Pi has hardware drivers for Open GL ES .. but these use the low level "dispmanx" calls to the display chip .. and bypass the X window system completely (which (I'm guessing) is why Allegro is full screen).
* There is a beta Open GL driver .. which may give some options to compile Allegro as if its a standard X window Linux box .. but this doesn't seem to be very stable on my Raspberry Pi 2 .. and it won't ever be available on a Pi1 or PiZero due to the hardware used.

In order to get B-Em working well on a Raspberry Pi, apart from the Allegro issue, you'd probably have to swap out the C code that emulates the 6502 for an ARM assembler version, which is what Dave did for Optima.

So maybe the Raspberry Pi version of B-Em should be a separate project/code base like Atomulator/Optima ?

Malcolm


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 2 guests