Beebem on the Raspberry pi (It is too slow)

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
pau1ie
Posts: 249
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford

Beebem on the Raspberry pi (It is too slow)

Postby pau1ie » Wed Jun 20, 2012 10:03 pm

I had a play with my raspberry pi this evening, and I got beebem up and running on it. The bad news is that the Raspberry pi is too slow to run it - you get one frame every 4 seconds. I tried reducing the graphics, but that didn't make a difference (Apparently the pi's graphics chip is pretty powerful anyway).

I did have a little trouble getting it compiled, it seems that the R1-R4 definitions in tube.h are duplicated in a system header file somewhere, so I renamed them to TR1 - TR4 in tube.h, tube.cpp, z80_support.cpp, and i86.cpp.

Anyway, here is what I did. I opened the terminal to download and unpack the source:

Code: Select all

mkdir Programs
cd Programs
wget http://beebem-unix.bbcmicro.com/download/beebem-0.0.13.tar.gz
tar xvf beebem-0.0.13.tar.gz


I discovered that you need a couple of dependencies when I ran configure the first time, so install them:

Code: Select all

sudo aptitude install libgtk2.0-dev libsdl1.2-dev
cd beebem-0.0.13


Then I edited the five files as I mentioned above. You need to be careful - don't do a global search and replace because there are other variables with R1 etc as part of their names, which you most likely want to leave as they are.

Then compile:

Code: Select all

./configure
./make
sudo make install


And bob's your uncle.

As I say, one frame every 4 seconds means games are unplayable, which is a pity.

Cheers

PaulH
I'm working on http://bbcmicro.co.uk

User avatar
richardtoohey
Posts: 3353
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Beebem on the Raspberry pi (It is too slow)

Postby richardtoohey » Wed Jun 20, 2012 10:06 pm

You can try my changes here ...

http://www.stardot.org.uk/forums/viewto ... 609#p47487

Suspect it will still be too slow, but should give a bit of a boost.

My credit card has been debited, so hopefully my Pi is a day or two away!

User avatar
richardtoohey
Posts: 3353
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Beebem on the Raspberry pi (It is too slow)

Postby richardtoohey » Wed Jun 20, 2012 10:13 pm

And meant to say, from my readings on the web, that the Pi's CPU is NOT that powerful - I think I read it is like a ~400 Mhz Pentium (but was it a Pentium I or II?) The GPU is powerful, but not the main CPU. (But, hey, we're talking about $35.)

Also, I don't think the OS releases are fully optimised yet.

So plenty of hope - don't give up just yet!

elecdrum
Posts: 74
Joined: Fri Jun 11, 2010 8:10 pm

Re: Beebem on the Raspberry pi (It is too slow)

Postby elecdrum » Mon Jun 25, 2012 10:17 pm

Maybe when Riscos is properly implemented Beebit may be the one to go for.
I was playing 'eye of the beholder' in dosbox on the 'Pi' in Debian and it was perfectly playable. So I would say that bodes well for the future.

User avatar
nOmArch
Posts: 1326
Joined: Fri May 21, 2010 7:27 pm
Location: Gloucestershire
Contact:

Re: Beebem on the Raspberry pi (It is too slow)

Postby nOmArch » Tue Jun 26, 2012 11:41 am

Overclock the cpu to 900Mhz, should give you a little more juice to play with.
Alex

Back up to 1 Beeb again. \o/

User avatar
pau1ie
Posts: 249
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford

Re: Beebem on the Raspberry pi (It is too slow)

Postby pau1ie » Tue Jun 26, 2012 2:01 pm

I was going to leave it, but you prompted me to investigate further. Linux format recommended installing a commodore emulator, http://www.viceteam.org/, which they say is sluggish but playable. You can get it from Debian once you enable the contrib repository.

I profiled the emulator, and just over 1/3 of the time was spent in the Exec6502 Instruction function, the next biggest function being PollHardware. My laptop seemed to run it about 100 times faster. However, it did not spend as long in PollHardware.

I did read that debian does not ship the driver for the graphics chip, so the graphics are not accelerated. I am not sure that it makes a difference. I was going to try running it on OpenElec which is overclocked and does include the graphics driver, but I am not sure when I will get around to that.

Am I correct in thinking that the Commodore used the 6502 chip as well, so presumably it should take a similar amount of power to emulate. I wonder if it would be possible to take the emulator out of vice and put it into beebem. However, I can't see my having time to do that! Something I might have time to do is try it in b-em if it is not too much trouble to get it working. Has anyone compiled that recently?

PaulH
I'm working on http://bbcmicro.co.uk

TopBanana
Posts: 1034
Joined: Wed Jun 09, 2010 2:16 pm

Re: Beebem on the Raspberry pi (It is too slow)

Postby TopBanana » Tue Jun 26, 2012 4:18 pm

Isn't the Pi supposed to be equivalent to a Pentium II running at 300Mhz ?

With 256Mb RAM ?

So that would be roughly 1998 technology ??

My gut feel would be that it will never work that well :( :( [-X [-X

The C64 ran at 1Mhz , the Beeb ran at 2Mhz, so presumably an emulator has to do more to run a Beeb ? On my desktop machine (2xQuad Xeons 32Gb RAM) Vice64 shows a CPU utilisation of 0% when idle, BeebEm between 3% and 4% when idle. So in a very unscientific test BeebEM uses between 3 and 4 times the processing power of Vice64.

If the same is true of the Linux builds then Vice may run just quick enough to be usable, but to be honest, I would ask why you'd want to try when you can run it on any PC that's less than 6 years old without issue #-o

User avatar
richardtoohey
Posts: 3353
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Beebem on the Raspberry pi (It is too slow)

Postby richardtoohey » Tue Jun 26, 2012 8:13 pm

TopBanana wrote:Isn't the Pi supposed to be equivalent to a Pentium II running at 300Mhz ? ... I would ask why you'd want to try


http://www.raspberrypi.org/faqs

That is, graphics capabilities are roughly equivalent to Xbox 1 level of performance. Overall real world performance is something like a 300MHz Pentium 2, only with much, much swankier graphics.

(Anyone tried one of the RISCOS BBC emulators running under RISCOS on the Pi?)

And the answer to your second question "why would you want to try" - it's a challenge, man! :lol: (But probably one that will be too hard and I'll go and play on something else - but I will give it a go!)

TopBanana
Posts: 1034
Joined: Wed Jun 09, 2010 2:16 pm

Re: Beebem on the Raspberry pi (It is too slow)

Postby TopBanana » Wed Jun 27, 2012 8:39 am

Raspberry PI FAQ wrote:The GPU is capable of BluRay quality playback, using H.264 at 40MBits/s. It has a fast 3D core accessed using the supplied OpenGL ES2.0 and OpenVG libraries

Graphics capabilities are roughly equivalent to Xbox 1 level of performance. Overall real world performance is something like a 300MHz Pentium 2, only with much, much swankier graphics


Erm ......

I always got the impression that the graphics capabilities leant towards playing video (as in BlueRay or DVD video), but having seen this ...

http://www.youtube.com/watch?v=e_mDuJuvZjI

... clearly it can do more.

I'm presuming therefore that BeebEm isn't using the OPenGL and Open VG graphics libraries ?

Also Quake isn't having to run under any GUI ... how much of a difference does that make to the CPU load ?

EnglishMan Liveing in Kiwi Land wrote:And the answer to your second question "why would you want to try" - it's a challenge, man!

However, I'd still have to ask why ? Walking up Everest in your underpants is a challenge, that doesn't mean I'd want to do it :lol:

User avatar
richardtoohey
Posts: 3353
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Beebem on the Raspberry pi (It is too slow)

Postby richardtoohey » Wed Jun 27, 2012 9:12 am

TopBanana wrote:I'm presuming therefore that BeebEm isn't using the OPenGL and Open VG graphics libraries ?
...
However, I'd still have to ask why ? Walking up Everest in your underpants is a challenge, that doesn't mean I'd want to do it :lol:
Beebem uses SDL, but I don't know enough graphics (yet?) to figure out what will happen below that.

I'm off to climb Everest with my underpants ... on my head ... want any pictures? :lol:

User avatar
GroovyBee
Posts: 45
Joined: Tue Jul 19, 2011 10:24 am
Location: North, England

Re: Beebem on the Raspberry pi (It is too slow)

Postby GroovyBee » Wed Jun 27, 2012 12:06 pm

I've looked at the BeebEm source code and I can understand why the 6502 emulation takes a chunk of time. Could somebody produce a listing with speed optimisations enabled so I can see what the exactly the compiler system makes of the file 6502core.cpp.

User avatar
pau1ie
Posts: 249
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford

Re: Beebem on the Raspberry pi (It is too slow)

Postby pau1ie » Wed Jun 27, 2012 2:27 pm

Could somebody produce a listing with speed optimisations enabled so I can see what the exactly the compiler system makes of the file 6502core.cpp.


I am not sure what you mean. I did consider I could compile it with -O3 or -Ofast. Do you want the assembly the compiler produces or something? Or do you want me to redo the profiling with -O3 or -Ofast? By default it compiles with -O2.

Or are you talking about something else entirely?

Thanks

PaulH
I'm working on http://bbcmicro.co.uk

User avatar
GroovyBee
Posts: 45
Joined: Tue Jul 19, 2011 10:24 am
Location: North, England

Re: Beebem on the Raspberry pi (It is too slow)

Postby GroovyBee » Wed Jun 27, 2012 5:48 pm

pau1ie wrote:I am not sure what you mean. I did consider I could compile it with -O3 or -Ofast. Do you want the assembly the compiler produces or something? Or do you want me to redo the profiling with -O3 or -Ofast? By default it compiles with -O2.


I'm not sure what version of GCC you use to create the code but sometimes -O3 doesn't give you the best results. Just a listing of 6502core.cpp at -O2 will be fine. No need to profile again.

TopBanana
Posts: 1034
Joined: Wed Jun 09, 2010 2:16 pm

Re: Beebem on the Raspberry pi (It is too slow)

Postby TopBanana » Wed Jun 27, 2012 8:02 pm

richardtoohey wrote:I'm off to climb Everest with my underpants ... on my head ... want any pictures? :lol:


Yeah, go on then :shock: :lol:

User avatar
richardtoohey
Posts: 3353
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Beebem on the Raspberry pi (It is too slow)

Postby richardtoohey » Wed Jun 27, 2012 8:09 pm

Everest is later ... I'm still stuck at this stage ...

Code: Select all

sudo aptitude install libgtk2.0-dev libsdl1.2-dev
It goes for a while, then gets a few 404s, and then stops ... Got a lot to learn about Debian ...

User avatar
pau1ie
Posts: 249
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford

Re: Beebem on the Raspberry pi (It is too slow)

Postby pau1ie » Wed Jun 27, 2012 8:34 pm

Here is the assembly generated by the following: I ran make then copied and pasted the command, changing it to generate assembler.

Code: Select all

 g++ -S -Wall -DDATA_DIR=\"/usr/local/share/beebem\"  -DHAVE_CONFIG_H -I. -I. -I.. -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -I../src/gui -I../src/    -g -pg -O2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -MT 6502core.o -MD -MP -MF ".deps/6502core.Tpo"  -o 6502core.a 6502core.cpp


gcc is the version which came with debian:

Code: Select all

$ gcc --version
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Is this what you wanted?

PaulH
Attachments
6502core.zip
(101.27 KiB) Downloaded 101 times
I'm working on http://bbcmicro.co.uk

User avatar
richardtoohey
Posts: 3353
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Beebem on the Raspberry pi (It is too slow)

Postby richardtoohey » Wed Jun 27, 2012 8:43 pm

Paul, did you have a chance to try my SDL changes?

I'm bogged down trying to get the dependancies installed, and I'm dying to know if my changes make one iota of difference (they did on a slow laptop.)

User avatar
pau1ie
Posts: 249
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford

Re: Beebem on the Raspberry pi (It is too slow)

Postby pau1ie » Wed Jun 27, 2012 8:52 pm

Code: Select all

sudo aptitude install libgtk2.0-dev libsdl1.2-dev

It goes for a while, then gets a few 404s, and then stops ... Got a lot to learn about Debian ..


You probably need to update the local copy of the package database. They seem to remove old versions of software when they replace it with a new one. Before you install anything, do

Code: Select all

sudo aptitude update
sudo aptitude safe-upgrade
 


The first command downloads the package lists, and the second one upgrades any packages which have had bug fixes. Then your install command should work, so then you can climb Everest and be back in time for tea.

Sorry, I didn't try your changes yet. My wife has nicked the telly. I am using the raspberry pi over ssh at the moment, but it is no good for testing performance of graphics. I will get a chance tomorrow...

Cheers

PaulH
I'm working on http://bbcmicro.co.uk

User avatar
richardtoohey
Posts: 3353
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Beebem on the Raspberry pi (It is too slow)

Postby richardtoohey » Wed Jun 27, 2012 9:04 pm

Thanks for the advice - I'm familiar with FreeBSD/OpenBSD ports & packages - the concepts are similar, but the implementations/commands a bit different!

Before I read your posting I had one last go and just said Y to everything, and it seems to have worked - at least I get to the same stage as you:

Code: Select all

In file included from main.cpp:57:
tube.h:45: error: conflicting declaration ‘R1’
/usr/include/sys/ucontext.h:45: error: ‘R1’ has a previous declaration as ‘<anonymous enum> R1’
I'll try your changes and then mine.

Good luck with the telly - I have the same problem!

User avatar
GroovyBee
Posts: 45
Joined: Tue Jul 19, 2011 10:24 am
Location: North, England

Re: Beebem on the Raspberry pi (It is too slow)

Postby GroovyBee » Wed Jun 27, 2012 9:18 pm

The compiler is doing sensible things with the switch statements and its inlining stuff too. Both of which are good. I think it'd need a bit of a rewrite to get the speed up to something sensible. As a side note you might also want to disable the profiling code because I can see the function prototypes being called.

SDL is also a possible cause for speed issues. A couple of years ago I looked at the Wii version and the code was less than optimal.

User avatar
richardtoohey
Posts: 3353
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Beebem on the Raspberry pi (It is too slow)

Postby richardtoohey » Wed Jun 27, 2012 9:49 pm

The good news is I can compile it and run (so thank you for your clear instructions, Paul.)

The bad news is I get FPS 0 or 1.

The worse news is that my SDL changes appear to make no difference - still stays at 0 or 1 FPS. Not one tiny bit of difference (doesn't seem right - on other machines it has lifted FPS 10 or more ...) There is definitely a huge inefficiency in there - it is redrawing the entire screen far too often.

I'll have another look when I have more time - to make 100% sure that I am building the right source, and then running the right binary. And also that I got ALL my changes out of my hacked & bodged version - I tried to extract the key parts, maybe I missed something.

Maybe the Everest and underpants job is becoming more appealing ... :D

EDIT: then I remembered that there was a nasty bit of code to try and fudge CAPS Lock (because of the way older versions of SDL worked) ... but knocking that out didn't help. I've put a message in when it is re-drawing the screen, and that hardly comes up at all ... so stuck in a loop somewhere else ...

Stating the obvious ... CPU is at nearly 100%, so either it really can't cope or there is still something really inefficient going on - I know of the CAPS Lock code, and the SDL rendering ... but there must be more ... got to find my old notes!

User avatar
helpful
Posts: 372
Joined: Tue Sep 22, 2009 12:18 pm
Location: London
Contact:

Re: Beebem on the Raspberry pi (It is too slow)

Postby helpful » Thu Jun 28, 2012 10:26 am

Looks like RISC OS is the way to go if you want to run BeebEm on you R-Pi :-)

http://www.iconbar.com/forums/viewthrea ... e=1#120720
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/

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

Re: Beebem on the Raspberry pi (It is too slow)

Postby Rich Talbot-Watkins » Thu Jun 28, 2012 11:03 am

I would certainly expect a BBC emulator to run perfectly well on a 700MHz ARM11 machine, even a cycle accurate one like B-Em, though it's possible that you'd have to pay special attention to writing code in a certain way that'd optimise well for the small I- and D-caches.

If it's spending a large amount of time in the 6502 emulation, then this is something that could be specially optimised for the ARM platform with inline assembler, because no compiler will generate nice code like this, for example:

Code: Select all

; perform ADC operation (decimal mode off)
; r0 = A
; r1 = value to add
; r2 = P flags
    movs    r3,r2,lsr #1        ; get 6502 C into ARM C
    mvn     r3,r3,#&FF000000    ; move 6502 A to ARM bits 24-31...
    orr     r0,r3,r0,lsl #24    ; ...with bits 0-23 set to propagate the carry
    adcs    r0,r0,r1,lsl #24    ; perform ADC (will set ARM C,V and N same as 6502)
    bic     r2,r2,#NZVC_mask    ; clear all affected 6502 flags
    orrcs   r2,r2,#C_flag       ; set 6502 C if ARM C set
    orrvs   r2,r2,#V_flag       ; set 6502 V if ARM V set
    orrmi   r2,r2,#N_flag       ; set 6502 N if ARM N set
    movs    r0,r0,lsr #24
    orreq   r2,r2,#Z_flag       ; set 6502 Z if result zero
(courtesy of !65Host)

User avatar
PitfallJones
Posts: 424
Joined: Fri Feb 22, 2008 3:44 pm
Contact:

Re: Beebem on the Raspberry pi (It is too slow)

Postby PitfallJones » Thu Jun 28, 2012 3:00 pm

I don't have a pi so this is only conjecture but I definitely remember running an earlier version of BeebEm on a 486 with no problem. (Dos version probably). The graphics doesn't even need some fancy library like SDL - on the pc you can just use the basic GDI to display the bbc screen.

A bit of an aside but I'd be interested if any one has any options about the MK802 and how it compares to the pi.

It's a bit more expensive than the pi at ~$80 but it's tiny and totally encased.

http://www.engadget.com/2012/06/07/mk802-android-4-0-mini-pc-hands-on-impressions/

-PJ

mk802.jpg
(42.22 KiB) Downloaded 3102 times

User avatar
pau1ie
Posts: 249
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford

Re: Beebem on the Raspberry pi (It is too slow)

Postby pau1ie » Thu Jun 28, 2012 7:29 pm

Having profiled the code I think we can say that it is the 6502 emulation that is the problem. The code is written with one function per opcode. I believe the only way to get the performance increase is to use assembler as Rich says. Rich - the snippet you posted, is this from a complete emulator that we could try to plug in? I have searched but can only find teasers on the internet. I might try to write a JIT compiler, as this is likely to get the speedup required. Of course I am completely unqualified to do this, and I am likely to get stuck and give up. I will see how I get on over the weekend using http://www.altdevblogaday.com/2011/06/12/jit-cpu-emulation-a-6502-to-x86-dynamic-recompiler-part-1/ as a basis unless anyone has any better ideas.

I checked B-EM and VICE and they both use a similar approach, writing a function for each opcode.

Cheers

PaulH
I'm working on http://bbcmicro.co.uk

User avatar
richardtoohey
Posts: 3353
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Beebem on the Raspberry pi (It is too slow)

Postby richardtoohey » Thu Jun 28, 2012 8:27 pm

pau1ie wrote:Having profiled the code I think we can say that it is the 6502 emulation that is the problem.
Yes ... my initial optimism has faded away - if you printf() a comment at the start of the screen rendering code, it only appears every 3 or 4 seconds. If you completely comment out the screen rendering code, it still sticks at 100% CPU - the screen rendering code isn't the problem (yet) - it only gets called every 3 or 4 seconds. The machine should certainly be capable of emulating a BBC, but not with the code as is stands (I was hoping a tweak here and a tweak there ... but a bigger job than that.)

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

Re: Beebem on the Raspberry pi (It is too slow)

Postby Rich Talbot-Watkins » Fri Jun 29, 2012 12:44 am

I'm really not convinced a dynamic recompiler is necessary, nor the answer. Nor would I say that implementing opcode emulation in assembler would necessarily give the biggest gain.

I think one problem is that the code tries to be too much by emulating all varieties of Beeb all in the same functions. Take the example of reading a byte from the emulated Beeb memory - this is one of the most basic operations which happens at least every opcode fetch, and potentially up to 4 times more (for an indirect opcode). Emulating a BBC B, this should be no more complex than:

Code: Select all

inline byte ReadMemory(word addr)
{
    if (addr < 0x8000)
    {
        return ramImage[addr];
    }
    else
    {
        return ReadMemoryTranslate(addr)  ; deal with paged ROM + hardware (non-inline)
    }
}

In BeebEm, this is a complicated function which checks every configuration of machine type it emulates, and does the address translation where necessary. For the simple case (direct mapping to emulated RAM), this is a very straightforward function which should be inlined. In the case where it is addressing hardware or a paged ROM, which needs some more complicated translation, this can call a non-inlined function, which will also benefit by (hopefully) still being in the instruction cache.

But the only way to do this is to have separate code for each model emulated, and the only sane way to do this is with C++ templates, at the expense of a bigger executable. Likewise for the CPU emulation. And there is the main problem - BeebEm isn't really architected in a speed optimal way. Unfortunately the problem with using templates to generate optimal code is that the executable potentially becomes bigger than is acceptable.

Take another example, that of ADC. As I demonstrated above, this can be emulated in a very compact way in ARM assembler (by using the fact that ARM and 6502 set their flags in more or less the same way). But BeebEm could still perform a bit better than it does by separating the emulation of ADC in decimal mode (complicated and rare) and ADC in normal mode (simple and common). By inlining the function and jumping to a non-inlined version in the case that decimal mode is on would avoid polluting the instruction cache with rarely executed code.

Surprisingly, GCC seems to do OK with the fact that all the 6502 registers are emulated in global variables. I expected this might cost extra time (by needing to establish the address of the global with a number of expensive operations), rather than having a pointer to a struct on the stack already, but this actually seems to be pretty optimised already, so kudos to GCC on that.

I'll have a browse through the code later and see if I spot anything else. But I haven't seen anything so awful there... Did profiling really reveal the 6502 emulation to be the bottleneck in BeebEm?

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

Re: Beebem on the Raspberry pi (It is too slow)

Postby SarahWalker » Fri Jun 29, 2012 7:44 am

I'd have thought the constant calls to things like PollVIA and PollHardware would have quite an impact on speed. At the very least that's going to kick all 6502 state back to memory, possibly several times per instruction? When I was writing B-em on similar hardware I only updated VIA timers and the like once every 128 cycles, and that had quite an impact on performance.

Rich is right about the flexibility being an issue - the BeebReadMem/BeebWriteMem functions look horrific. At the very least the most common case (< 0x8000 = RAM) should be inlined. In order to keep ROM accesses relatively fast, B-em uses a more complicated lookup system :

(vis20k is related to shadow RAM on B+/Master)

Code: Select all

static uint8_t *memlook[2][256];
static int memstat[2][256];

uint8_t readmem(uint16_t addr)
{
        if (memstat[vis20k][addr >> 8]) return memlook[vis20k][addr >> 8][addr];
        /*IO*/
}

void writemem(uint16_t addr, uint8_t val)
{
        if (memstat[vis20k][addr >> 8] == 1) { memlook[vis20k][addr >> 8][addr]=val; return; }
        /*IO*/
}

That keeps the flexibility, but should be able to inline and perform better.

I agree that a dynamic recompiler is completely unnecessary. Re-implementing opcode emulation in assembler would give a boost (Beebdroid does this with B-em) but if it's just linked to the existing memory + IO routines then the performance increase will be minimal.

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

Re: Beebem on the Raspberry pi (It is too slow)

Postby Rich Talbot-Watkins » Fri Jun 29, 2012 8:33 am

Another potential optimisation would be to try to ensure that all the most commonly executed opcodes' routines are placed together in a contiguous block, as this too will help the instruction cache. I can't see how you could do this with switch/case, but if it were to use an array of function pointers, this could probably be arranged fairly easily. Compiling to THUMB code would also probably improve the instruction cache use.

The biggest bottleneck in small embedded platforms like Raspberry Pi (and other systems such as iOS, Android, Nintendo DS, and even PS3 / Xbox360) is the cost of accessing uncached memory, which can be as much as 500 cycles! Increasingly, developers need to learn to take into account the arrangement of their code and data in memory in order to get the best performance from the caches. You can implement the most optimal algorithms and hand-crafted assembler possible, but ultimately it's the cache misses which will let you down. Here's an interesting presentation from Sony Computer Entertainment on this topic, which expands on it in a bit more detail.

@Tom - yeah, I did something similar way back when I wrote a Sega Master System emulator for RISC OS, of all things. It even ran at a playable speed on my 12MHz ARM250, astonishingly.

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

Re: Beebem on the Raspberry pi (It is too slow)

Postby BigEd » Sat Jun 30, 2012 11:29 am

richardtoohey wrote:Good luck with the telly - I have the same problem!
I just got this cable very cheap and next day, which lets me use my monitor. If your monitor has a previously-ignored DVI input, you might consider something similar.

Cheers
Ed


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 2 guests