B-Em

[fordp]

Is there anybody out there that can help me get B-Em building on Windows or Linux.

I want to work on adding 32016 CoPro support to B-Em.

Thanks!

From the Future:

Well I a glad B-Em has moved on these days an has turned into a thriving open-source project here:
https://github.com/stardot/b-em

[tricky]

This was my best result viewtopic.php?f=4&t=9252&p=107645&hilit ... ng#p106282

[fordp]

Thanks Tricky,

I hope I can get it building.

I hate that getting it building stage however I just find it dead time.

Cheers.

[davidb]

Do you have the latest source code? Have you tried on Linux yet?

I have a working copy but built from scratch to check. I got the code from my clone of the original repository. The autotools files need to be updated.

First, I did this:

Code: Select all

autoreconf

This complains about various missing files but the following helped fix these:

Code: Select all

touch NEWS README AUTHORS ChangeLog
automake --add-missing

Then the configure script can be run. It will complain about more problems but it might be enough to get you started.

[Kecske Bak]

I haven't had any problems recently getting B-Em to compile on Linux. Provided you've installed the dependencies (Alut and OpenAL are the only ones normally missing) and right clicked on all the linked files to change the version of automake to the correct version (1.15 instead of 1.11 currently), simply typing configure and then make is enough on Manjaro KDE Rolling. Arch and Netrunner also compile it with no problems.

Elkulator is harder though, I invariably have to do:

Code: Select all

export LDFLAGS="$LDFLAGS -lm -ldl"
configure
make

to get it to work.

[richardtoohey]

I got B-Em building and running on OpenBSD, so it should (as others have said) build fine on Linux.

What Linux distro are you trying to build it on?

What issue(s) are you encountering?

[fordp]

I spent a few minutes yesterday, I am pretty sure I can have it building. I a spending all my time on the 32016 soft-core. Myself and Dave (hoglet) have it running Panos and are going on to add floating point support so it can run all Panos software.

[dp11]

I've just run the code though cppcheck. It has thrown up a few possible minor errors that might be worth looking into.

Code: Select all

[32016.c:1253] -> [32016.c:1261]: (performance) Variable 'temp' is reassigned a value before the old one has been used.
[6502.c:801]: (style) Variable 'c' is assigned a value that is never used.
[65816.c:79]: (style) Expression '(X & 0x78000) == 0x4000' is always false.
[65816.c:122]: (style) Expression '(X & 0x78000) == 0x4000' is always false.
[Z80.c:718]: (warning) Redundant assignment of 'bc.b.h' to itself.
[Z80.c:727]: (warning) Redundant assignment of 'bc.b.l' to itself.
[Z80.c:736]: (warning) Redundant assignment of 'de.b.h' to itself.
[Z80.c:745]: (warning) Redundant assignment of 'de.b.l' to itself.
[Z80.c:754]: (warning) Redundant assignment of 'hl.b.h' to itself.
[Z80.c:763]: (warning) Redundant assignment of 'hl.b.l' to itself.
[Z80.c:780]: (warning) Redundant assignment of 'af.b.h' to itself.
[Z80.c:812] -> [Z80.c:812]: (style) Same expression on both sides of '-='.
[Z80.c:829] -> [Z80.c:829]: (style) Same expression on both sides of '&='.
[Z80.c:837] -> [Z80.c:837]: (style) Same expression on both sides of '^='.
[Z80.c:845] -> [Z80.c:845]: (style) Same expression on both sides of '|='.
[adf.c:283]: (style) Clarify calculation precedence for '+' and '?'.
[debugger.c:514] -> [debugger.c:516]: (performance) Variable 'd' is reassigned a value before the old one has been used.
[debugger.c:102]: (error) Uninitialized variable: c
[fdi2raw.c:1008]: (error) Possible null pointer dereference: data
[fdi2raw.c:1825]: (style) Variable 'd' is assigned a value that is never used.
[i8271.c:231]: (style) Consecutive return, break, continue, goto or throw statements are unnecessary.
[i8271.c:437]: (style) Statements following return, break, continue, goto or throw will never be executed.
[ide.c:156]: (style) Consecutive return, break, continue, goto or throw statements are unnecessary.
[ide.c:13]: (style) struct member 'Anonymous0::status' is never used.
[ide.c:16]: (style) struct member 'Anonymous0::fdisk' is never used.
[main.c:74]: (style) Statements following return, break, continue, goto or throw will never be executed.
[resid.cc:149]: (style) Variable 'c' is assigned a value that is never used.
[soundopenal.c:23]: (style) Variable 'error' is assigned a value that is never used.
[sysvia.c:105]: (style) Variable 'temp' is assigned a value that is never used.
[video.c:130]: (style) Variable 'c' is assigned a value that is never used.
[win.c:111]: (error) Common realloc mistake: 'argv' nulled but not freed upon failure
[x86.c:489]: (style) Statements following return, break, continue, goto or throw will never be executed.
[x86.c:3451]: (style) Statements following return, break, continue, goto or throw will never be executed.
[resid-fp\sid.cc:36]: (style) struct member 'cpu_x86_regs_s::ebx' is never used.
[resid-fp\wave.cc:26]: (warning) Member variable 'WaveformGeneratorFP::sync_dest' is not initialized in the constructor.

[bakoulis]

Do you have the latest source code? Have you tried on Linux yet?

I have a working copy but built from scratch to check. I got the code from my clone of the original repository. The autotools files need to be updated.

First, I did this:

Code: Select all

autoreconf

This complains about various missing files but the following helped fix these:

Code: Select all

touch NEWS README AUTHORS ChangeLog
automake --add-missing

Then the configure script can be run. It will complain about more problems but it might be enough to get you started.

At linux Mint 17.3 compiled but don't run.
Exits with errors:
Shutting down Allegro due to signal #11
[1] 30563 segmentation fault ./b-em

Same errors gives the Elkulator:
Shutting down Allegro due to signal #11
[1] 2380 segmentation fault ./elkulator

[davidb]

At linux Mint 17.3 compiled but don't run.
Exits with errors:
Shutting down Allegro due to signal #11
[1] 30563 segmentation fault ./b-em

Same errors gives the Elkulator:
Shutting down Allegro due to signal #11
[1] 2380 segmentation fault ./elkulator

OK, starting with Elkulator, do you have the ROMs? There should be a roms directory alongside the src directory and the elkulator executable. If you don't have them you can get them from one of the archives here.

[richardtoohey]

At linux Mint 17.3 compiled but don't run.
Exits with errors:
Shutting down Allegro due to signal #11
[1] 30563 segmentation fault ./b-em

Same errors gives the Elkulator:
Shutting down Allegro due to signal #11
[1] 2380 segmentation fault ./elkulator

As David says, these emulators crash if they can't find files - so you are very close! They don't print "Can't find file X" - they seg. fault.

[bakoulis]

unfortunately, the ROMs are here. All the files are present.

[davidb]

Just to verify, this is what I get if I don't have the ROMs where Elkulator can find them:

Code: Select all

$ strace ./elkulator 2>&1 | grep open | tail
open("/home/david/.Xauthority", O_RDONLY) = 7
open("/dev/shm/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
open("/dev/shm/pulse-shm-2060124398", O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 7
open("/dev/shm/pulse-shm-3064962992", O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 7
open("/dev/shm/pulse-shm-3177891650", O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 7
open("/dev/shm/pulse-shm-267838616", O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 7
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 6
open("/dev/shm/pulse-shm-3045890080", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0400) = 6
open("/var/lib/dbus/machine-id", O_RDONLY|O_CLOEXEC) = 6
open("os", O_RDONLY)                    = -1 ENOENT (No such file or directory)

Do you get something similar?

[bakoulis]

I get this:

Code: Select all

$  strace ./elkulator 2>&1 | grep open | tail
open("/usr/lib/i386-linux-gnu/allegro/4.4.2/alleg-alsamidi.so", O_RDONLY|O_CLOEXEC) = 4
open("/home/takis/.Xauthority", O_RDONLY) = 4
open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 4
open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 4
open("/usr/share/X11/locale/C/XLC_LOCALE", O_RDONLY) = 4
open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 4
open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 4
open("/usr/share/X11/locale/C/XLC_LOCALE", O_RDONLY) = 4
open("/home/takis/.Xdefaults-takis-desktop", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/takis/ElkulatorV1.0Linux//elk.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
[1]    26762 segmentation fault  strace ./elkulator 2>&1 | 
       26763 done                grep --color=auto --exclude-dir={.bzr,CVS,.git,.hg,.svn} open | 
       26764 done                tail

[hoglet]

Not sure which thread to post this in, but I think this is the best fit.

I've just managed to build B-Em on Windows with the original 32016 code enabled:

I used the MinGW environment that we use for building Atomulator.

I wonder how hard it will be to back-port our shiny new 32016 emulation code?

Dave

[davidb]

Can you create an empty configuration file with

Code: Select all

cd /home/takis/ElkulatorV1.0Linux
touch elk.cfg

in that directory and try again? Does it get any further?

[bakoulis]

No difference.

[fordp]

Not sure which thread to post this in, but I think this is the best fit.

I've just managed to build B-Em on Windows with the original 32016 code enabled:

B-Em.png

I used the MinGW environment that we use for building Atomulator.

I wonder how hard it will be to back-port our shiny new 32016 emulation code?

Dave

You are doing better than me then Dave.

I must admit I have only spent a few minutes and I wanted to use my existing tool chain. I am not a big fan of cluttering my PC up with lots of compilers. I have used visual studio for over 15 years. I am no expert on Windows however I write 99% platform agnostic code.

If I can get B-Em working I am pretty sure I can port the new soft-core back from where it came.

[richardtoohey]

unfortunately, the ROMs are here. All the files are present.

Did you do make install at the end of compilation? (Not saying it will definitely make a difference, this is from vague memory ...)

Also make sure you are running the installed version rather than a just-compiled version.

[hoglet]

I've managed to get the latest 32016 code building in B-Em now, and Panos boots.

It's a shame we made a bunch of small changes to the original Beeb-Em interface:
- dropped ns32016_init and ns32016_close
- ns32016_reset now requires a start address parameter
- ns32016_exec now requires a tubecycles parameter (rather than using a tubecycles global)
- tube_irq changed from int to uint32_t

These seem trivial changes, but B-Em has a standard interface for all of the Co Processors, and we've now made the 32016 slightly different.

I think we should go back to what the original interface was, then the new code pretty much drops in without any significant changes.

Frustratingly, I can't get my ADFS image to work. I just get "Broken directory". Is anyone successfully using an ADFS hard disc image with B-Em?

Dave

[fordp]

Great work Dave

If I can get it building I can soon put the old calls back in as a wrapper.

I need to look up how to share code between git projects.

I am still a git novice

[hoglet]

If I can get it building I can soon put the old calls back in as a wrapper.

Are you still wanting to build it with Visual Studio? If so, I'm afraid I won't be of much help there.

I need to look up how to share code between git projects.

I am still a git novice

This is something I'm still struggling to find an effective approach to.

It get's very complicated very quickly, and you risk polluting the history of the parent project with irrelevant commits to the child project. If you want to see an example of this, look at the history of BeebFpga, where I've pulled in ICE T65 using git subtree. It's a mess!

Given the small number of files involved, I'd recommend just copying them.

Dave

[bakoulis]

unfortunately, the ROMs are here. All the files are present.

Did you do make install at the end of compilation? (Not saying it will definitely make a difference, this is from vague memory ...)

Also make sure you are running the installed version rather than a just-compiled version.

Again, no difference.

[fordp]

Are you still wanting to build it with Visual Studio? If so, I'm afraid I won't be of much help there.

Dave

I have not spent much time on getting B-Em working. I will install what it takes to get it build if push come to shove. I am pretty good at driving Visual Studio, anything else would be a steep learning curve for me. I am however crap at linking static or dynamic libraries as I leave that to others professionally.

[richardtoohey]

unfortunately, the ROMs are here. All the files are present.

Did you do make install at the end of compilation? (Not saying it will definitely make a difference, this is from vague memory ...)

Also make sure you are running the installed version rather than a just-compiled version.

Again, no difference.

I installed Virtual Box, installed (as a VM) Linux Mint 17.3 XFCE, 64-bit version. Bit of faffing around, but ended with:

Code: Select all

autoreconf -i
./configure
make
./b-em

And b-em fired up with no problems. Do you definitely have the right dependencies installed (Allegro 4.4, zlib, OpenAL, ALut?) Any errors show during configure & make steps?

You could build a debug version and then run it through GDB to see where it crashes.

[richardtoohey]

You could build a debug version and then run it through GDB to see where it crashes.

Not sure if this is exactly right, but works for me (on Linux Mint 17.3).

Code: Select all

./configure CFLAGS='-g'
make clean
make
gdb ./b-em
b main_init
r
n
<cr>
<cr>
...etc...
continue

So configure with -g to build the debug version, then run gdb on the new executable. Set a breakpoint on main_init (you don't have to), r for run, n for next, press <cr> to repeat last instruction, and you can step through the code. continue lets it free run (gets out of stepping mode.)

You don't have to step - you can skip the breakpoint instruction, and just hit r to run it and see where it falls over. Then use bt to get a backtrace - that will show where it's been.

[bakoulis]

I have test it, in 3 different computers with Linux mint mate 17.3 32bit OS and the results is always same.
I can't test an 64bit OS on a 32bits host, because virtualbox don't allow it. So my fingers are crossed.
Can you please set up a 32bit linux mint box in virtualbox for testing?
I suspect the problem occurs only at 32 bit OS!

[richardtoohey]

Can you please set up a 32bit linux mint box in virtualbox for testing?

I can give it a go, yes.

[richardtoohey]

Works fine on Linux Mint 17.3, 32 bit, XFCE edition.

Installed LM 17.3 32-bit taking all default options.

Code: Select all

sudo apt-get install build-essential
sudo apt-get install autoconf
sudo apt-get install automake

Run Software Manager:

search for "allegro4" install "liballegro4-dev" and "liballegro4.4"
search for "openal" install "libopenal-dev"
search for "alut" install "libalut-dev" and "libalut0"
search for "zlib", install "zlib1g-dev"

Create a directory b-em, cd into it, pull down the B-em Linux 2.2 tarball, extract with tar xzvf.

Code: Select all

autoreconf -i

Complains about AM_PATH_ALLEGRO, so I got allegro.m4 from another machine, and

Code: Select all

sudo cp allegro.m4 /usr/share/aclocal

Try again:

Code: Select all

autoreconf -i

(About 20 warnings about subdir-objects, I ignored those)

Code: Select all

./configure
make
./b-em

And it works fine.

So not sure what's up on your machine, or the process you are following - but b-em 2.2 works.

If you build and run the debug version I'm sure (well, very hopeful!) we'll find the answer.

Code: Select all

./configure CFLAGS='-g'
make clean
make
gdb ./b-em
r

... and when it crashes ...

Code: Select all

bt

... and tell us what the output is.

CAVEATS - I'm not a Linux user, and my knowledge of the auto tools is weak - so not saying any of the above is recommended or the best way of doing anything. But it builds b-em 2.2 for me.

[bakoulis]

The bt returns:
(gdb) bt
#0 0xb7f63850 in ?? () from /usr/lib/i386-linux-gnu/liballeg.so.4.4
#1 <signal handler called>
#2 0xb7ba878a in putc () from /lib/i386-linux-gnu/libc.so.6
#3 0x080cc19e in ide_init () at ide.c:45
#4 0x080cf1d5 in main_init (argc=argc@entry=1, argv=argv@entry=0xbffff724)
at main.c:257
#5 0x0804a19b in main (argc=1, argv=0xbffff724) at linux.c:68


Of course I have installed all the necessary libs, or else the compiling was impossible!