50 fps on b-em?

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Post Reply
User avatar
0xC0DE
Posts: 343
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

50 fps on b-em?

Post by 0xC0DE » Sat May 11, 2019 3:00 pm

I'm converting one of my Acorn Electron demo effects to the BBC Micro. Since I don't have an actual Beeb myself, I have been testing my code on the excellent b-em emulator. I hit a point where the BBC version (synchronized to VSYNC) is running at approximately 25fps when I expected it to easily match the 50fps of the Electron version!

I though I was going crazy until I eventually tested the same BBC version of my code in BeebEm. Sure enough it seems to run at 50fps as expected. And the information in the title bar of BeebEm confirms the emulator itself is indeed running at 50fps on my computer.

Is there any way to display actual fps information in b-em as well? Can anybody confirm this speed difference between b-em and BeebEm?
0xC0DE
:idea: Follow me on Twitter :idea: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

User avatar
tricky
Posts: 3737
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: 50 fps on b-em?

Post by tricky » Sat May 11, 2019 6:19 pm

I've never seen any speed difference between the two, but beebem seems to have a vsync that either lasts an extra scan-line or is a scan-line late.
What does jsbeeb say? In debug mode, it has a glowing highlight where it thinks the raster is.
Mame also has extra debug info, although last time I checked it didn't like its 6845 simulation was very basic.
Do you have a colour that you can palette switch to get a better idea of what is going on?
In the b-em debugger, you can use s followed by the number of instructions to run, this might give you an idea where the time is going.

User avatar
0xC0DE
Posts: 343
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: 50 fps on b-em?

Post by 0xC0DE » Sat May 11, 2019 6:23 pm

Here is an example:

textscroller.ssd
(200 KiB) Downloaded 13 times



Designed to run at 50fps. It looks like 50fps in BeebEm, but more like 25fps in b-em. On my computer at least. I cannot test on a real Beeb because I don't have one :mrgreen:
0xC0DE
:idea: Follow me on Twitter :idea: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

User avatar
SarahWalker
Posts: 1197
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: 50 fps on b-em?

Post by SarahWalker » Sat May 11, 2019 6:52 pm

Running at 50 fps here on both B-em v2.2 and Beebem v4.14. B-em's frame pacing isn't great, but it's still putting out 50 fps.

User avatar
0xC0DE
Posts: 343
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: 50 fps on b-em?

Post by 0xC0DE » Sat May 11, 2019 6:55 pm

Thanks for testing. Can b-em show current fps?
0xC0DE
:idea: Follow me on Twitter :idea: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

User avatar
SarahWalker
Posts: 1197
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: 50 fps on b-em?

Post by SarahWalker » Sat May 11, 2019 7:58 pm

No. It's assumed that if you're running on a machine made in the 21st century then it will run at 50 fps.

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

Re: 50 fps on b-em?

Post by Coeus » Mon May 13, 2019 8:09 pm

Which version of B-Em are you running this on and on what OS?

B-Em v2.2 is Allegro 4 based, the current version in Stardot Github is Allegro 5 based so I did wonder if that made a difference. To test the theory I modified the current Github master by adding a new integer variable flipcount and then found this:

Code: Select all

        al_flip_display();
which is where the drawn changes should become visible and added some lines:

Code: Select all

        al_flip_display();
        if (++flipcount == 500) {
            log_info("500 frames completed");
            flipcount = 0;
        }
so if this is working correctly it should be logging that message every 10 seconds and I got this in the log:

Code: Select all

13/05/2019 20:58:30 INFO 500 frames completed
13/05/2019 20:58:40 INFO 500 frames completed
13/05/2019 20:58:50 INFO 500 frames completed
13/05/2019 20:59:00 INFO 500 frames completed
13/05/2019 20:59:10 INFO 500 frames completed
13/05/2019 20:59:20 INFO 500 frames completed
13/05/2019 20:59:30 INFO 500 frames completed
So, could there be an OS dependency? My result was on Linux. As another general test of how fast the emulated machine is going, how many seconds does CLOCKSP take timed with a stopwatch, i.e. not relying on self-reported time? I get 40s in Master mode (Basic 4) and 50s in BBC B mode.
Last edited by Coeus on Mon May 13, 2019 8:10 pm, edited 1 time in total.

User avatar
0xC0DE
Posts: 343
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: 50 fps on b-em?

Post by 0xC0DE » Mon May 13, 2019 8:41 pm

I'm testing my code on b-em 2.2 and beebem 4.14, both on Windows 10. On a laptop from this century I assure you :mrgreen:

I have now discovered that any video setting in b-em other than "hardware line doubling" visibly slows down the entire emulator to about 25fps.
No big deal. I'll just leave this set to "hardware line doubling".
0xC0DE
:idea: Follow me on Twitter :idea: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

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

Re: 50 fps on b-em?

Post by Coeus » Mon May 13, 2019 9:41 pm

Looking into this further it seems it is definitely CPU dependent. The previous machine I ran the test on is a desktop machine with an Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz. On my salvaged out of a skip laptop which has an Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz, with the same patched B-Em I get:

Code: Select all

13/05/2019 22:17:35 INFO 500 frames completed
13/05/2019 22:18:06 INFO 500 frames completed
13/05/2019 22:18:36 INFO 500 frames completed
13/05/2019 22:19:07 INFO 500 frames completed
13/05/2019 22:19:38 INFO 500 frames completed
So that is definitely slow, at times as little as 1/3 speed. Checking the CPU usage:
top.png
B-Em is clearly CPU limited. The slowest laptop I have on which B-Em works nicely at full speed has an Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz

The other thing that is interesting from the screenshiot of top is that B-Em is not using the whole CPU, just the whole of one core. That means in theory it could be made to run acceptably fast on older, multi-core CPUs by sharing the work between threads but that would be somewhat complicated.
Last edited by Coeus on Mon May 13, 2019 9:46 pm, edited 2 times in total.

User avatar
tricky
Posts: 3737
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: 50 fps on b-em?

Post by tricky » Tue May 14, 2019 10:13 am

I have an i5 laptop (W7) and a couple of extra features added to b-em and it can't manage full speed, although the stock allegro 4 is fine. Infact , my 14 year old atom netbook (XP) is also fine with the old b-em, so maybe it is a windows 10 thing?
I've not found any cycle level sim where everything is off the same clock to be accelorateable on multi-core.
You could time stamp all writes affecting the display only and have a second thread process them and resimulate the 6845 to unload the display side. Possibly do the same with sound, but not speech.

User avatar
0xC0DE
Posts: 343
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: 50 fps on b-em?

Post by 0xC0DE » Tue May 14, 2019 11:14 am

My Dell laptop has an Intel(R) Core(TM) i5-5300U CPU @2.30 GHz
64-bit Windows 10
8 GB RAM
0xC0DE
:idea: Follow me on Twitter :idea: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

User avatar
Pernod
Posts: 1662
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: 50 fps on b-em?

Post by Pernod » Tue May 14, 2019 11:35 am

Coeus wrote:
Mon May 13, 2019 9:41 pm
The other thing that is interesting from the screenshiot of top is that B-Em is not using the whole CPU, just the whole of one core. That means in theory it could be made to run acceptably fast on older, multi-core CPUs by sharing the work between threads but that would be somewhat complicated.
You'll find the majority of emulators only use a single core. If you're emulating a single CPU machine then what do you offload to another core? I believe the problem relates to how you keep what's been done in each core in sync, it adds alot of overhead to be worthwhile. Even MAME mostly only uses a single core, though some drivers do make use of others to perform GPU tasks.

There's a good discussion at https://forums.bannister.org/ubbthreads ... ber=106795.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
SarahWalker
Posts: 1197
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: 50 fps on b-em?

Post by SarahWalker » Tue May 14, 2019 5:13 pm

I'm a bit surprised it's using that much CPU. When I was finishing White Light a couple of years ago, for obscure reasons I did much of the final tweaking & bug fixing on B-em v2.2 running on an Athlon 750, a CPU from 1999 (hence the 21st century comment!). It ran at (just about) full speed on that, so why it's running slow on a massively quicker Core 2 or i5 is beyond me.
Last edited by SarahWalker on Tue May 14, 2019 5:14 pm, edited 1 time in total.

User avatar
tricky
Posts: 3737
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: 50 fps on b-em?

Post by tricky » Tue May 14, 2019 6:23 pm

Actually, I just checked and my version that slowed down is due to the extra UI I added and updated every clock cycle!

User avatar
Rich Talbot-Watkins
Posts: 1549
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: 50 fps on b-em?

Post by Rich Talbot-Watkins » Tue May 14, 2019 8:06 pm

You should take out the bitcoin mining code too!

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

Re: 50 fps on b-em?

Post by Coeus » Tue May 14, 2019 10:52 pm

SarahWalker wrote:
Tue May 14, 2019 5:13 pm
I'm a bit surprised it's using that much CPU. When I was finishing White Light a couple of years ago, for obscure reasons I did much of the final tweaking & bug fixing on B-em v2.2 running on an Athlon 750, a CPU from 1999 (hence the 21st century comment!). It ran at (just about) full speed on that, so why it's running slow on a massively quicker Core 2 or i5 is beyond me.
I did just try v2.2 vs. the current Allegro 5 version, on the desktop (i5) on Linux. V2.2 uses about 20% CPU (but Xwayland is also using about 30%). The current GitHub Master (Allegro 5-based) uses 30% CPU (but no significant Xwayland use).

The most CPU intensive thing is the video emulation, not the 6502. Writing into the Allegro 5 bitmaps was pretty slow until I implemented an in-line function to do it. Then came VideoNULA which also increased CPU utilisation but people wanted to be able to try out games that make use of VideoNULA and, when I mentioned it, people said modern CPUs are fast and certainly for my reasonably modern desktop machine it is certainly fast enough.

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

Re: 50 fps on b-em?

Post by Coeus » Tue May 14, 2019 11:09 pm

Pernod wrote:
Tue May 14, 2019 11:35 am
You'll find the majority of emulators only use a single core. If you're emulating a single CPU machine then what do you offload to another core? I believe the problem relates to how you keep what's been done in each core in sync, it adds alot of overhead to be worthwhile. Even MAME mostly only uses a single core, though some drivers do make use of others to perform GPU tasks.
In the case of B-Em the obvious thing would be to work out a way to run the CPU emulation in one thread and the video emulation in a parallel thread. A really simplistic idea would be to have the threads synchronised around a clock i.e. each thread does one tick's worth of work and then they all synchronise but I suspect that would mean more time would be spent in the synchronisation primitives than doing actual work.

I did see an idea, maybe from RTW, about a scheme were the CPU emulation could communicate touched memory regions to the video emulations so they don't have to be absolutely locked in ssync, just in sync at the moments where it counts but that sounds complicated to implement.

tom_seddon
Posts: 336
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: 50 fps on b-em?

Post by tom_seddon » Tue May 14, 2019 11:53 pm

What I've done for b2 is run the BBC emulation on a second thread, and have it emit a sort of video data packet every cycle, containing hsync state, vsync state, and RGB data for 8 x Mode 0 pixels - this is supposed to very roughly correspond to sampling the RGB plug's pins. The emulator thread writes this data into a lockless circular buffer as it goes.

When the main thread needs to redraw the window, it consumes, at least in part, the current buffer contents in order to produce more texture data (there's a very primitive CRT emulator for this), and uses that as the emulated display. It knows how many µsecs'-worth of display it's trying to produce, so it knows how many cycles'-worth of data it has to consume to do this.

The circular buffer has a fixed size, so the emulator thread will correctly stall if the main thread stops consuming the buffer, e.g., due to a modal file dialog. The main thread can handle as much or as little data as is available, so it can't get starved - at worst, no data available at all, it just displays the same texture as it did last frame...

I think this sort of approach is the right thing for modern systems, since everything is multicore these days. Anywhere you can get some straightforward parallelism, without driving yourself mad in the process, you should...

--Tom

User avatar
BigEd
Posts: 2630
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: 50 fps on b-em?

Post by BigEd » Thu May 16, 2019 5:19 pm

Pernod wrote:
Tue May 14, 2019 11:35 am
You'll find the majority of emulators only use a single core. If you're emulating a single CPU machine then what do you offload to another core?
...
There's a good discussion at https://forums.bannister.org/ubbthreads ... ber=106795.
Thanks, good link! The case which is likely to work best, I think, is any unidirectional subsystem. So: video out, and audio out, are obvious candidates. Both of those can take significant processing. Maybe the input side of the user interface?? But anything which is bidirectional runs into questions of synchronisation and data coherency, which are made much harder if cycle accuracy is needed. (Arguably the Tube decouples the two sides enough that the two sides could be on different cores: but sometimes there will be intensive communication, and again cycle accuracy is a problem.)

Post Reply