b2 - new emulator

[melchett]

...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.

[melchett]

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...

[JasonStonier]

To quote Garth Algar: it's almost too easy

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

[Coeus]

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.

[JasonStonier]

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)

[JasonStonier]

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

[melchett]

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

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.

[melchett]

... although for the record, unless I'm an absolute idiot (which is possible)...

For the record, you're not

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

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]

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.

[melchett]

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

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.

[melchett]

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.

[JasonStonier]

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]

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.

[melchett]

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.

[melchett]

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...

[JasonStonier]

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.

[melchett]

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...

[melchett]

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]

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]

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]

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]

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 :


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

[cardboardguru]

Hi Tom,

Thanks for b2. I'm finding it really useful. I'm on macOS Big Sur, so it's just the thing.

I'm doing some programming for the Beeb using Beebasm, and I'm trying to get an ideal workflow. The ideal would be one button to assemble, make the disk image, and run it on b2. Currently I'm using Visual Studio Code as an editor, and I've got it working with one button to build and one to run. Using VSC tasks.

But the one annoyance is that I'm specifying the disk to boot from with: "open -a \"b2 Debug\" --args -0 ${workspaceRoot}/CGDisasm.ssd -b"
This means that I have to manually close b2 each time before doing the run task, or the emulator just sits there doing nothing.

In the b2 debug docs, I see the http interface, and that's exactly what I need. But I'm struggling to work out exactly what command I need. I'm new not only to b2, but also to VSC and CURL, and I just can't work it out. Tried many varieties of CURL call, but the only thing I've managed to do is make b2 do a reset. I can't get it to switch to a specfic config. And I can't get it to even load the disk image, never mind boot it.

Any clues?

Thanks.

[TobyLobster]

Hi @cardboardguru,

I use this to quit the old instance of b2, then wait a second for it to take effect before starting a new copy of b2:

Code: Select all

    osascript -e 'quit app "b2 Debug"'
    sleep 1
    open -a 'b2 Debug' --args ...

which works nicely for me.

[cardboardguru]

Thanks TobyLobster. That works for me too.

I'd still like to get the http method for doing it working though, as that would leave the state of the emulator the same.

But your script is FAR less frustrating than having to stop b2 manually.

[tom_seddon]

Thanks for the comments, and I'm glad you're finding b2 useful. I need to update the documentation with some examples that you could copy and paste! - at the moment it's just a bit of a brain dump, and that doesn't really necessarily make it very clear how to accomplish a given goal.

For now, two suitable examples for selecting config and mounting a disk might be the Makefiles for Stunt Car Racer or Beeb-NICCC - and hopefully it'll be fairly clear how to modify them for your situation.

https://github.com/kieranhj/scr-beeb/bl ... efile#L213
https://github.com/kieranhj/stnicc-beeb ... kefile#L84

Let me know if you run into any difficulties, and I'll try to help.

--Tom

P.S. I've added an github issue about the quality of the documentation: https://github.com/tom-seddon/b2/issues/151 - I do try to put at least a note in the documentation about everything, so it's in some sense pretty complete, but that doesn't automatically make it useful

[TobyLobster]

Thanks Tom, those examples were useful.

[rodders]

Hi Tom. Just tried your b2 emulator on Ubuntu 20.04 and it looks very good.
One issue I've noticed is with the Basic Editor, the standard version is OK but in your modified version the cursor in the edit screen appears to be one line up from where it should be which is very confusing. Just thought I'd let you know in case you were unaware and there is some underlying bug.

[rodders]

Aha! I was using the snap installation. I've rebuilt the latest from scratch and its fixed. Looks like the snap is out of date.

[derek]

Hi,

I was struggling to compile B2 on Linux Mint 19.3, after downloading the ZIP file from Github.

But, I tried cloning the GIT source to my hard drive and the compile process worked perfectly, both on the Release and Debug version of the B2.

I am not very knowledgeable with regards to GITHUB, so I read a book last night, and things seem to be clearer.

I must say the B2 emulator is excellent, I like the Clone function which I think can be very useful, also the keyboard mappings are correct for my Fujitsu Core i7 Celsius H7000 laptop.

I would like to get the SDCARD images working on this, I assume that it is just a matter of adding the ROM and link the image file.

Can Beeblink network other BEEB emulators?