b2 - new emulator

discuss bbc micro and electron emulators (including mame) here!
User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Tue Aug 25, 2020 2:00 pm

JasonStonier wrote:
Mon Aug 24, 2020 10:55 pm
...but changing and recompiling makes no difference to the actual reported MHz.
I made some changes for you and created a pull request for B-em - you can pull them down directly if you clone this

Code: Select all

git clone https://github.com/ajgbarnes/b-em.git
Basically - I have added a command line switch -sp which takes values 0 to 9 (default 4) so when you start it up you can specify the emulation speed. You need the following:

Code: Select all

./b-em -sp8
I'll look another time on how to add this to b2 as it's hitting the same issue.

User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Tue Aug 25, 2020 2:10 pm

JasonStonier wrote:
Mon Aug 24, 2020 10:55 pm
It's got to be independent of the host processor speed as it runs exactly the same (wrong) speed on the Pi 3B+ and the Pi 4, so I wonder if it's calculating it on the fly from cycles over time ticks.
I had a cursory glance when making the switch changes to B-em - it IS independent of processor in that a timer is created using Allegro which puts events on a queue based on a requested time interval and the code just processes those as fast as it can. Any events in the main loop which are beyond a time limit are discarded rather than processed (otherwise the queue would grow and grow and it'd never catch up I guess). There are MANY events that are discarded though by B-Em. Not sure if that's a problem just yet but means it'll discard many stale timer events.

BOTH b2 and b-em use Allegro 5.2 - I was reading something on some forums that something introduced some slowness to the OpenGL driver - unclear right now if that's a Raspian or Allegro issue but people who wrote code on Jessie and moved to Stretch noticed a 25% ish reduction in screen drawing of their games. I'm on Buster btw. I have skimmed this so need to find some less distracted time this evening to look a bit deeper and get some stats out of B-Em.

I may try the experimental OpenGL dirver if there still is one on Buster. Maybe that will help. Getting closer and at least I understand the calibration / queuing / event timers in B-em...

User avatar
JasonStonier
Posts: 358
Joined: Mon Dec 10, 2018 8:10 pm
Location: Dorset
Contact:

Re: b2 - new emulator

Post by JasonStonier » Tue Aug 25, 2020 3:33 pm

To quote Garth Algar: it's almost too easy :shock:

Just signed up to a CodeAcademy C++ course, so give me a week or so and I'll jump in and give you a hand 8)

Coeus
Posts: 1897
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: b2 - new emulator

Post by Coeus » Tue Aug 25, 2020 3:50 pm

melchett wrote:
Mon Aug 24, 2020 9:08 pm
I was thinking the same - it's similar for both B-em and b2 in that regard, although I can't ramp up to 400% on b2 that I can notice at least. What I don't know and maybe the emulator authors can answer is how is 100% calibrated on different machines by the emulator to keep it a "2 Mhz". What is it querying or polling?
Could you confirm which version of b-em you are running on the Raspberry Pi? Is it version 2.2, which is based on Allegro 4, or a more recent version from github which has, for a while now, been based on Allegro 5?

The general approach in B-em is to run a fixed number of 6502 instructions and, by implication, the right number of video output operations etc. because all the hardware is lock-step with the 6502, then ask the OS to wait for some period of time and repeat. With the current (GitHub) version, the faster you ask it to go, the shorter the delay it is asking the OS for.

I can see how this might be out by a factor of two because flipping the display buffers may also introduce a delay but I can't think why it should be out by a factor of four. Most of B-Em is single-threaded, though Allegro uses some background threads for its own purposes.

User avatar
JasonStonier
Posts: 358
Joined: Mon Dec 10, 2018 8:10 pm
Location: Dorset
Contact:

Re: b2 - new emulator

Post by JasonStonier » Tue Aug 25, 2020 5:01 pm

I'm running the github version, so assuming it's on Allegro 5.

In mine, the results are very slightly different between a Pi 3B+ and a Pi 4.

on the 3B+ I have in front of me now
100% selected equates to between 0.78 and 0.86MHz reported as 42% ish
400% selected equates to between 1.6 and 2.4MHz (very variable 'flickering') reported as 102 to 110% ish

On Pi 4 (which <might> have other crap running which could skew this result)
100% = 0.65MHz
400% = 2.1MHz (very variable again)

User avatar
JasonStonier
Posts: 358
Joined: Mon Dec 10, 2018 8:10 pm
Location: Dorset
Contact:

Re: b2 - new emulator

Post by JasonStonier » Tue Aug 25, 2020 5:28 pm

melchett wrote:
Tue Aug 25, 2020 2:00 pm

I made some changes for you and created a pull request for B-em - you can pull them down directly if you clone this

Code: Select all

git clone https://github.com/ajgbarnes/b-em.git
Thanks! works well...although for the record, unless I'm an absolute idiot (which is possible)...

Your github linked above is the original code, but if I clone github.com/stardot/b-em I get your updated code with

"-spx - Emulation speed x from 0 to 9 (default 4)\n" at line 143, plus the updates at line 175 - 179

User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Tue Aug 25, 2020 5:29 pm

Coeus wrote:
Tue Aug 25, 2020 3:50 pm

Could you confirm which version of b-em you are running on the Raspberry Pi? Is it version 2.2, which is based on Allegro 4, or a more recent version from github which has, for a while now, been based on Allegro 5?
Latest version from Github - with Allegro 5.2
Coeus wrote:
Tue Aug 25, 2020 3:50 pm
The general approach in B-em is to run a fixed number of 6502 instructions and, by implication, the right number of video output operations etc. because all the hardware is lock-step with the 6502, then ask the OS to wait for some period of time and repeat. With the current (GitHub) version, the faster you ask it to go, the shorter the delay it is asking the OS for.

I can see how this might be out by a factor of two because flipping the display buffers may also introduce a delay but I can't think why it should be out by a factor of four. Most of B-Em is single-threaded, though Allegro uses some background threads for its own purposes.
Not sure yet either - it's clearly capable of running smoothly when it receives the right number of timer events in the queue. I'll compare it to what's happening in Windows when I get a chance.

User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Tue Aug 25, 2020 5:35 pm

JasonStonier wrote:
Tue Aug 25, 2020 5:28 pm
... although for the record, unless I'm an absolute idiot (which is possible)...
For the record, you're not :D
JasonStonier wrote:
Tue Aug 25, 2020 5:28 pm
Your github linked above is the original code, but if I clone github.com/stardot/b-em I get your updated code with
That was me being sloppy on a day off... should have been this branch.

Code: Select all

https://github.com/ajgbarnes/b-em/tree/speed-switch
JasonStonier wrote:
Tue Aug 25, 2020 5:28 pm
Your github linked above is the original code, but if I clone github.com/stardot/b-em I get your updated code
Wow - think that's the fastest I have ever had a pull request processed outside of work.

Coeus
Posts: 1897
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: b2 - new emulator

Post by Coeus » Tue Aug 25, 2020 5:43 pm

melchett wrote:
Tue Aug 25, 2020 5:29 pm
Not sure yet either - it's clearly capable of running smoothly when it receives the right number of timer events in the queue. I'll compare it to what's happening in Windows when I get a chance.
AFAIK it runs fine on Linux on my Intel desktop so I don't think this is a Linux vs. Windows issue. It will be worth looking at main.c and in particular at:

Code: Select all

void main_setspeed(int speed)
{
    log_debug("main: setspeed %d", speed);
    if (speed == EMU_SPEED_FULL)
        main_start_fullspeed();
    else {
        al_stop_timer(timer);
        fullspeed = FSPEED_NONE;
        if (speed != EMU_SPEED_PAUSED) {
            if (speed >= NUM_EMU_SPEEDS) {
                log_warn("main: speed #%d out of range, defaulting to 100%%", speed);
                speed = 4;
            }
            al_set_timer_speed(timer, emu_speeds[speed].timer_interval);
            time_limit = emu_speeds[speed].timer_interval * 2.0;
            vid_fskipmax = emu_speeds[speed].fskipmax;
            log_debug("main: new speed#%d, timer interval=%g, vid_fskipmax=%d", speed, emu_speeds[speed].timer_interval, vid_fskipmax);
            al_start_timer(timer);
        }
    }
    emuspeed = speed;
}
and the table that refers to which is:

Code: Select all

const emu_speed_t emu_speeds[NUM_EMU_SPEEDS] = {
    {  "10%", 1.0 / (50.0 * 0.10), 1 },
    {  "25%", 1.0 / (50.0 * 0.25), 1 },
    {  "50%", 1.0 / (50.0 * 0.50), 1 },
    {  "75%", 1.0 / (50.0 * 0.75), 1 },
    { "100%", 1.0 / 50.0,          1 },
    { "150%", 1.0 / (50.0 * 1.50), 2 },
    { "200%", 1.0 / (50.0 * 2.00), 2 },
    { "300%", 1.0 / (50.0 * 3.00), 3 },
    { "400%", 1.0 / (50.0 * 4.00), 4 },
    { "500%", 1.0 / (50.0 * 5.00), 5 }
};
Then look at this:

Code: Select all

static void main_timer(ALLEGRO_EVENT *event)
{
    double now = al_get_time();
    double delay = now - event->any.timestamp;

    if (delay < time_limit) {
...
    }
}
So this time_limit is there to make sure that, in the event the host system is too slow to run at the requested speed, timer events don't fill up the Allegro event queue. If the queue becomes full that means no other events, like keypresses etc. get processed. You could experiment with the * 2.0 in main_setspeed and see if changing that helps. The general idea is we want to be able to maintain the right average speed even if the host is temporarily busy doing something else, i.e. we want to distinguish between a case of the host being temporarily busy and just consistently too slow.

I would offer to try this myself but I don't have a Raspberry Pi 4.

User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Tue Aug 25, 2020 10:05 pm

Coeus wrote:
Tue Aug 25, 2020 5:43 pm
AFAIK it runs fine on Linux on my Intel desktop so I don't think this is a Linux vs. Windows issue. It will be worth looking at main.c...
I don't think it's an issue with the design or "Linux" or the initial coding which is all wonderful - something peculiar to Raspbian and RPI 3 B+ / 4. I started instrumenting those areas when I first looked earlier today and the queue processing wasn't abnormal from first glance (in exactly the areas you later confirmed). I'm on holiday at the moment so quite a few distractions. It all works well on B-em and B2 just throttled by default. I need to compare B-em on Ubuntu vs Raspbian tomorrow and log the different events. Timing seems "right" in the allegro event queue (although the music 500 events ALLEGRO_EVENT_AUDIO_STREAM_FRAGMENT come thick and fast through regardless of if you have it switched on or not however commenting out the processing makes zero difference to performance).

The "if (delay < time_limit)" is interesting but maybe a red herring - when I run at 400% I get a slight reduction in dropped messages but nothing significant e.g. 2-3%. Seems more that I get more events through from the ALLEGRO_EVENT_TIMER timer that helps it process quickly enough. What I want to check is that the timing calculation is right for those events. But I need the comparison against a "well running system" so I'll fire up my Ubuntu (debian) partition and see what that is doing.

Was hoping to get there tonight but life and holiday intervened in a good way :D

Just want to say too that the code on both B-em and b2 is most accesible and readable e.g. pretty quickly earlier today reached the code on b-em that you highlighted subsequently. Focusing on B-em just because I have it readily compiling on multi-platforms right now. Will get there with b2 it's just newer to me.

Thanks Coeus and Tom for your continued support with this - I know RPi isn't an "official" platform for these emulators and they are so close to working by virtue of your original visions.

User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Wed Aug 26, 2020 10:24 am

Coeus wrote:
Tue Aug 25, 2020 5:43 pm
It will be worth looking at main.c and in particular at.....
It appears that it's the video processing that is taking the time on the RPi 4 / Allegro 5.2 / OpenGL combination

1. Changing time_limit to e.g. * 1000 does not speed up or slow down (although presumably at some point the queue will fill up)
2. Increasing just the timer_interval for 100% to e.g. 1.0 / (50.0 * 4.0) makes no difference
3. However... if I increase the fskipmax for 100% to 4 or 5 with the timer_interval at default of 1.0 / 50.0 then it does make a difference to the emulated MHz.

I'll continue digging.

User avatar
JasonStonier
Posts: 358
Joined: Mon Dec 10, 2018 8:10 pm
Location: Dorset
Contact:

Re: b2 - new emulator

Post by JasonStonier » Wed Aug 26, 2020 12:07 pm

Mrs Melchet: what shall we do on our holiday today, dear?
Melchet: wanna help me with this coding problem?
Mrs Melchet: come on children! Let's go to the cinema!

Coeus
Posts: 1897
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: b2 - new emulator

Post by Coeus » Wed Aug 26, 2020 1:39 pm

melchett wrote:
Wed Aug 26, 2020 10:24 am
I'll continue digging.
In vidalleg.c there is a call to al_flip_display. The Allegro documentation warns that this may wait for vsync but I think we rely on it not doing so.

User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Wed Aug 26, 2020 5:29 pm

Coeus wrote:
Wed Aug 26, 2020 1:39 pm
The Allegro documentation warns that this may wait for vsync but I think we rely on it not doing so.
Another stolen 5 minutes and a I quickly added the follow before al_create_display in video.c

Code: Select all

al_set_new_display_option(ALLEGRO_VSYNC, 2, ALLEGRO_REQUIRE);
Didn't improve anything so guessing it's off already or overriden by the graphics driver on Raspbian.

User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Wed Aug 26, 2020 5:32 pm

JasonStonier wrote:
Wed Aug 26, 2020 12:07 pm
Melchet: wanna help me with this coding problem?
It's all highly secretive... and minutes stolen whilst waiting to e.g. leave or for the house to wake up... partly because they'll judge me doing this on days off...

User avatar
JasonStonier
Posts: 358
Joined: Mon Dec 10, 2018 8:10 pm
Location: Dorset
Contact:

Re: b2 - new emulator

Post by JasonStonier » Wed Aug 26, 2020 11:24 pm

An hour ago Mrs S said “are you coming to bed, or carrying on with that soldering?”
Apparently “soldering dear” was, for some unfathomable reason, the wrong answer. No idea why.

User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Fri Aug 28, 2020 9:15 am

JasonStonier wrote:
Wed Aug 26, 2020 11:24 pm
An hour ago Mrs S said “are you coming to bed, or carrying on with that soldering?”
I don't think that was a question... :roll:

User avatar
melchett
Posts: 317
Joined: Tue Jan 28, 2003 9:52 am
Contact:

Re: b2 - new emulator

Post by melchett » Fri Aug 28, 2020 6:34 pm

Coeus wrote:
Wed Aug 26, 2020 1:39 pm
The Allegro documentation warns that this may wait for vsync but I think we rely on it not doing so.
I created a pull request - on my Ubuntu 20.04 partition it is the difference between 100% running at 1.2MHz / 60% versus 2MHz / 100%.

Coeus
Posts: 1897
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: b2 - new emulator

Post by Coeus » Fri Aug 28, 2020 10:12 pm

JasonStonier wrote:
Tue Aug 25, 2020 5:28 pm
Your github linked above is the original code, but if I clone github.com/stardot/b-em I get your updated code with
The other easy mistake is to forget that cloning a git repository clones the whole thing and leaves you on the master branch. If you want to test out a particular branch you still have to switch to it. And no, getting tripped up by this does not make one an idiot - it has happened to me.

Coeus
Posts: 1897
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: b2 - new emulator

Post by Coeus » Fri Aug 28, 2020 10:16 pm

melchett wrote:
Tue Aug 25, 2020 5:35 pm
Wow - think that's the fastest I have ever had a pull request processed outside of work.
I don't guarantee to always merge them that fast, though I have merged your vsync merge request today, but I do try to be responsive. I see open source projects with not only a long list of issues but also a long list of pullrequests. What incentive is there for people to contribute and make software better for others if their work is ignored for long periods?

Coeus
Posts: 1897
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: b2 - new emulator

Post by Coeus » Fri Aug 28, 2020 10:20 pm

melchett wrote:
Tue Aug 25, 2020 2:10 pm
BOTH b2 and b-em use Allegro 5.2 - I was reading something on some forums that something introduced some slowness to the OpenGL driver...
I have experienced a slowdown with B-Em on desktop Linux with Intel integrated graphics when the window is completely obscured. Obviously that is not something you'd do playing a game but when listening to Music on the Music 5000 wghile doing something else it can be. Interestingly, as long as at least a corner of the window is visible the slowdown doesn't happen.

ACCORDIONMAN
Posts: 13
Joined: Fri Dec 27, 2019 2:43 pm
Contact:

Re: b2 - new emulator

Post by ACCORDIONMAN » Fri Nov 13, 2020 10:02 am

Hi everyone, I hope I'm posting in the right place. I was getting a bit of 'sound/graphics' lag using the B2 Emulator. Just wanted to report it here in case anyone has any insight.

I'm playing the game Thrust, with .ssd file downloaded from BBC Games Archive site.

My computer specs are :
Image

Seems the sound is slightly slower than the graphics, but i get an approx 0.5 - 0.7 second delay after the key press.

This issues is slightly less noticable using the in-build we games player on the site. Also, different games seem to suffer a slight variation in delay. Chuckie Egg for instance is quite snappy.

Anyone have any idea whay I might do to improve performace please? I can't see anything else running on the system. Cheers
Attachments
Screenshot 2020-11-13 at 09.57.51.png

Post Reply

Return to “8-bit acorn emulators”