B-Em

[lovebug]

im having issues with my github repos again, my b-em there looks nothing like my local files and when I try to push changes it keeps warning me about merge conflicts. i think i'll delete it and start again

i really dont understand this github thing

maybe I shouldnt use computers when im tired

[paulb]

im having issues with my github repos again, my b-em there looks nothing like my local files and when I try to push changes it keeps warning me about merge conflicts. i think i'll delete it and start again

Could it be the branch that GitHub is showing? In the "Code" view, the pull-down menu shows the current branch, next to the number of branches and tags. I find these things easy to overlook, then wondering where various files or directories have gone.

I also find myself checking the git manual pages over and over again to make sure I'm pushing and pulling to branches in the intended way. Git's usability still leaves a lot to be desired, but there is an industry-wide culture of making excuses for it and other half-finished tools and technologies.

i really dont understand this github thing

I think that GitHub and those that mimic it, like GitLab, all tend to suffer from the inevitable clutter of feature accumulation without a coherent approach to usability. And corporate priorities mean that essential and obvious functionality often gets pushed into an easily forgotten corner. So instead of an obvious link for commit history, I have to remember that the "1,898 commits" statistic is a link that shows commits in a branch.

The only really positive thing I can say is that at least it isn't a service provided by Atlassian with their constant notifications pestering everyone to use the premium version and their other enterprise-haunting products.

[Coeus]

im having issues with my github repos again, my b-em there looks nothing like my local files and when I try to push changes it keeps warning me about merge conflicts. i think i'll delete it and start again

Merging is a fundamental part of the philosophy of distributed source code control systems like git compared to using locks in centralised systems. Just because it is the modern fashion, though, doesn't make it perfect. It's advantage is that several people can work on things in parallel but then, if the automatic merge algorithm can't do the merge, someone has to work out what the final version should look like.

With git, normally, if someone else has made changes to the branch you are working on and has committed them to the remote repository you are trying to push to, you will need to pull first which attempts to do the merge in your repository rather than the remote one. That means if there are conflicts you need to resolve them before you can complete the pull and then push your own changes.

The risk of merge conflicts is reduced if you pull reasonably often. This is more an issue if you are working on the master branch. One way to side-steps this is to create a new branch for the work your are doing, push it to github as a new branch, the submit a pull request then, someone else (me in the case of B-Em) has to understand the change well enough to resolve any conflicts.

P.S. if this is the -fullscreen option and you have now solved the scaling issue, if it is easier you could post the final main.c and I can merge it and credit it to you (if you let me know you GitHyb name/e-mail).

[lovebug]

I haven't fixed the scaling issue yet, but something weird was happening with regular b-em before I made the -fullscreen mod which was

b-em starts in windowed mode, if I use the menu to select full screen mode then it does switch to full-screen and shows the menu bar on the top

however if I instead use F11 to toggle between windowed and full-screen mode then full-screen mode doesn't show the menu bar and the image fills more of the screen area

so I think the issue with the new -fullscreen command line option is that the scaling calculated for the fullscreen mode without the menu bar but it is being rendered with the menu bar which pushes everything down and the last 1.1 rows are being cropped

[lovebug]

I have fixed the issue, I needed to move the call to video_enterfullscreen() to the end of the main_init()

[Coeus]

...
b-em starts in windowed mode, if I use the menu to select full screen mode then it does switch to full-screen and shows the menu bar on the top

however if I instead use F11 to toggle between windowed and full-screen mode then full-screen mode doesn't show the menu bar and the image fills more of the screen area

Yes, this is a feature. The idea is that if you use F11 (can be mapped to any other key) to enter full-screen then you obviously know the key to you can use it again to get out of full-screen. If you use the menu, you presumably don't know the key so would need the menu to get back to window mode or to quit. In bother cases, though, it should show the full output. If that's not the case, we need to treat that as a bug.

[lovebug]

...
b-em starts in windowed mode, if I use the menu to select full screen mode then it does switch to full-screen and shows the menu bar on the top

however if I instead use F11 to toggle between windowed and full-screen mode then full-screen mode doesn't show the menu bar and the image fills more of the screen area

Yes, this is a feature. The idea is that if you use F11 (can be mapped to any other key) to enter full-screen then you obviously know the key to you can use it again to get out of full-screen. If you use the menu, you presumably don't know the key so would need the menu to get back to window mode or to quit. In bother cases, though, it should show the full output. If that's not the case, we need to treat that as a bug.

I wasn't sure if the full screen with/without menu bar was a feature or a bug, thanks for clearing that up

[lovebug]

oh btw that main.c I posted has been modified to 2 frames for 100% speed as in my case 1 frame causes glitching so I would suggest just copying the 3 small changes for the -fullscreen mod (marked with // lovebug) into your copy of main.c instead of using my main.c file directly

[Coeus]

oh btw that main.c I posted has been modified to 2 frames for 100% speed as in my case 1 frame causes glitching so I would suggest just copying the 3 small changes for the -fullscreen mod (marked with // lovebug) into your copy of main.c instead of using my main.c file directly

Thanks. I tried to commit this using the git --author option to credit it to you but it is insisting on an e-mail address. Do you have one you use for GitHub that I can use - you can PM it to me if you don't want to publish it on here?

[tricky]

I found that playing samples slowed the emulator to about 1/3rd speed, at least on my desktop i7 on windows. I mean to profile it, but forgot! There was something else that slowed it down, but I can't remember what it was now :O

[lovebug]

oh btw that main.c I posted has been modified to 2 frames for 100% speed as in my case 1 frame causes glitching so I would suggest just copying the 3 small changes for the -fullscreen mod (marked with // lovebug) into your copy of main.c instead of using my main.c file directly

Thanks. I tried to commit this using the git --author option to credit it to you but it is insisting on an e-mail address. Do you have one you use for GitHub that I can use - you can PM it to me if you don't want to publish it on here?

im LoveBug2084 on github and my registered email is gamelovebug@gmail.com
thanks

[Coeus]

im LoveBug2084 on github and my registered email is gamelovebug@gmail.com
thanks

Thanks. I have committed your changes, excluding the change to vid_fskipmax, and pushed to master along with another fix as, when I came to test the change, I found the content was not being scaled to the new full-screen window.

On vid_fskipmax, do check out the latest on Issue#214 and the associated branch.

[lovebug]

Thanks and I'll check it out

[lovebug]

heh you left the // lovebug in the mod

I only put those in so you guys could easily find my bodges

[lovebug]

I really need to learn how to use github correctly, I usually have no issues with my own projects but even then it does sometimes go completely wrong requiring me to delete the online backup.

for other peoples projects I have even more disasters

[lovebug]

im LoveBug2084 on github and my registered email is gamelovebug@gmail.com
thanks

Thanks. I have committed your changes, excluding the change to vid_fskipmax, and pushed to master along with another fix as, when I came to test the change, I found the content was not being scaled to the new full-screen window.

On vid_fskipmax, do check out the latest on Issue#214 and the associated branch.

im really impressed with the fixes to latest build, the graphical glitching is fixed and I can enjoy speed set to 100% at 1 frame now

well done

[lovebug]

Oh

Something strange with the latest build

If I start b-em with the -fullscreen option which shows the menu bar on top then everything is fine

if I start b-em without the -fullscreen option and then use F11 to switch to full screen then the glitchy mess returns

what is the difference between fullscreen with menu bar and fullscreen without menu bar ?

this is very strange

[Grasshopper]

I just tried building the latest version in MX Linux. Unfortunately, when I ran the executable I got the following error message:

b-em: /build/allegro5-keC96M/allegro5-5.2.6.0/src/bitmap_draw.c:34: _bitmap_drawer: Assertion `bitmap != dest && bitmap != dest->parent' failed.
Aborted

This didn't happen with previous versions.

With regards to the full screen options, until I read this thread, I actually assumed that the inconsistent behaviour when selecting full screen mode through the menus, or by pressing F11, was a bug.

I can definitely see the benefit of having two full screen modes, one with menus and one without. But I think it would make more sense (and be more intuitive) if both modes could be selected through their own separate command line switches, or menu options. If the user selected the menu-less option though the menus, then a popup message could be displayed on the screen warning the user that the only means of regaining access to the menus is by pressing F11.

[Coeus]

I just tried building the latest version in MX Linux. Unfortunately, when I ran the executable I got the following error message:

b-em: /build/allegro5-keC96M/allegro5-5.2.6.0/src/bitmap_draw.c:34: _bitmap_drawer: Assertion `bitmap != dest && bitmap != dest->parent' failed.
Aborted

See: https://github.com/stardot/b-em/issues/217 and the branch in which I have pushed a fix.

[Coeus]

what is the difference between fullscreen with menu bar and fullscreen without menu bar ?

The code is in fullscreen.c:

Code: Select all

void toggle_fullscreen_menu()
{
    if (fullscreen) {
        gui_allegro_init(queue, tmp_display);
        video_leavefullscreen();
        fullscreen = 0;
    } else {
        fullscreen = 1;
        video_enterfullscreen();
        gui_allegro_destroy(queue, tmp_display);
    }
}

void toggle_fullscreen()
{
    if (fullscreen) {
        video_leavefullscreen();
        fullscreen = 0;
    } else {
        fullscreen = 1;
        video_enterfullscreen();
    }
}

but to summarise, the version without menu detaches the menu from the allegro display before making it full-screen and then re-attaches it again afterwards. Looking into this I wonder if there is a memory leak there but I don't think that has anything to do with the behaviour when full-screen mode is in operation.

There is an additional complication in the pipeline, at least for Linux. Up to and including Allegro 5.2.8, the al_set_display_flag call used to set full-screen mode is handled in the core part of Allegro by the driver for X11. In 5.2.9 the native dialog add-on, which produces the menu, overrides this but fails to handle the ALLEGRO_FULLSCREEN_WINDOW flag, so that call does nothing. In that case B-Em does the best it can which is to set the window as maximised and also frameless. This applies regardless of whether the menu is actually attached.

I can definitely see the benefit of having two full screen modes, one with menus and one without. But I think it would make more sense (and be more intuitive) if both modes could be selected through their own separate command line switches, or menu options. If the user selected the menu-less option though the menus, then a popup message could be displayed on the screen warning the user that the only means of regaining access to the menus is by pressing F11.

That's certainly possible. Adding a second command line option would be easy enough, though which would -fullscreen do and what do we call the other. As for the menu, we could make it a radio button type like some of the others (speed, tube etc.).

The other thing to note is that it isn't necessary F11 to enter and leave fullscreen as this is remappable via the "remap keyboard" setting. I have noticed a pop-up with some GNOME applications saying "<whatever> full screen, F11 to exit" or something like that but I don't know if this is produced by the application of gnome-shell. If we can get Allegro to process ALLEGRO_FULLSCREEN_WINDOW through GTK (see 5.2.9 above), that may happen automatically.

[markusher]

That's certainly possible. Adding a second command line option would be easy enough, though which would -fullscreen do and what do we call the other.

Kiosk (mode) for no menus?

[Grasshopper]

See: https://github.com/stardot/b-em/issues/217 and the branch in which I have pushed a fix.

Thanks. That fixed the issue.

That's certainly possible. Adding a second command line option would be easy enough, though which would -fullscreen do and what do we call the other. As for the menu, we could make it a radio button type like some of the others (speed, tube etc.).

Upon further reflection, instead of having two distinct full screen modes, I think it would make more sense to have a single mode, and a separate flag to indicate whether menus should be displayed in that mode. This would mean that F11 simply acts as a shortcut to selecting full screen mode from the menus or command line.

You could then keep the original -fullscreen command line option, and add a new option called something like -hide-fullscreen-menus (or something equivalent but less verbose).

[lovebug]

Upon further reflection, instead of having two distinct full screen modes, I think it would make more sense to have a single mode, and a separate flag to indicate whether menus should be displayed in that mode. This would mean that F11 simply acts as a shortcut to selecting full screen mode from the menus or command line.

You could then keep the original -fullscreen command line option, and add a new option called something like -hide-fullscreen-menus (or something equivalent but less verbose).

I had the same thought, I think this would be the nicest solution

[scruss]

Can I just say how delightfully well b-em runs on a Raspberry Pi 5?

[lovebug]

When I take a screenshot with b-em it seems to crop the last line from the bottom of the image

[dr_d_gee]

Just like to say that the current GitHub version of B-em is the best BBC emulator I've come across for Linux.

The current version of BeebEm for Linux is over 15 years old. The Windows version crashes under Wine if I try to change the model on the hardware menu. B2 works — and is available as a Snap package, making it easy to install. However it uses 100% CPU according to htop and the laptop fans are on the whole time. The release version of B-em fails to make correctly (Zorin OS — Ubuntu 2020 LTS variant).

One feature I would like to see is the ability to extract files from, and insert files to, a disc image — as on the current Windows version of BeebEm. VDFS doesn’t really meet this need as AFAICT only one FS can be active at a time.

I'd like to see it released and ideally available in one of the current cross-platform Linux packaging formats — AppImage, Flatpak or Snap… take your pick.

[mbernardi]

I've just downloaded the Windows Binaries from https://github.com/stardot/b-em for both 32 and 64 bit systems, unzipped them to a folder, and tried to run b-em.exe, which fails with a popup error of:

The code execution cannot proceed because libssp-0.dll was not found. Reinstalling the program may fix the problem.

Since b-em isn't actually installed, (just run from a folder) this isn't any help. I believe that this dll is related to the C++ Runtime module, is a particular version needed?

[Coeus]

I've just downloaded the Windows Binaries from https://github.com/stardot/b-em for both 32 and 64 bit systems, unzipped them to a folder, and tried to run b-em.exe, which fails with a popup error of:

We had something similar a while back so I wonder if this is a regression. I will see if I can modify the script that builds the Windows version to include a copy of that DLL.

[Coeus]

One feature I would like to see is the ability to extract files from, and insert files to, a disc image — as on the current Windows version of BeebEm. VDFS doesn’t really meet this need as AFAICT only one FS can be active at a time.

I will have a think about this. The reasons B-Em does not already have this feature are:

• The user interface is built with the "Native Dialogs" addition to Allegro, the platform independent library that the rest of B-Em is built on. This add-on is not very flexible: basically there are menus and file selection dialogs and I think the latter are limited to host files.
• It didn't seem too pressing as there are other tools to do the job in some fashion. One very competent one is Steve Harris's MMB Utils in Perl: https://www.spuddy.org/Beeb/mmb_utils.html This is a Perl script with a number of sub-commands and, though it seems to be aimed at managing the MMB files used by MMFS and similar SD card systems, it has commands to construct an SSD from files on the PC and to unpack an SSD into PC files. Another option that allows individual files to be copied is: https://github.com/SteveFosdick/AcornFsUtils, which also handles ADFS. There may be some graphical options too - that isn't something I have really looked at.

You're right that VDFS is not aimed at doing this. The use case of VDFS is where you want the same files to be accessible from both the host (PC) and guest (BBC Micro) without needing to copy back and forth, i.e. the normal place for these files to reside is in a directory on the host, not in a disc image. That suits, for example, using an editor on the host to edit a file then immediately run it on the guest.

But, it can be used for copying. On the Master there is the *MOVE command which, together with "temporary" filing systems (the -FS- syntax) enables files to be copied and there is also JGH's TreeCopy command which doesn't need a Master and can copy whole directory trees, for example from ADFS to Econet etc.

I'd like to see it released and ideally available in one of the current cross-platform Linux packaging formats — AppImage, Flatpak or Snap… take your pick.

I can certainly have a go at that. Interesting that there are a number of these formats. There is a disincentive to packaging software because different distros use different package formats so the solution is not one, but several, portable formats!

[dr_d_gee]

Thanks for mentioning the various options, almost all of which I was unaware of.

The only utility I was aware of is graphical but runs only on RISC OS — BBCFiles. It will convert almost any possible format to any other, including BBC Applications which run on RISC OS using the Beebit emulator.

I have come across one issue with BeebEm, however: I can't find a way of mapping a key to f0 — and nor does it appear to be mapped to anything by default — at least when using the "logical" keyboard layout. I've managed to remap other keys (accidentally at first, then remapped them back again!) but nothing works with f0. Not widely used I imagine, although it is one of the keys used by *EDIT.