B-Em

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
bakoulis
Posts: 294
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece
Contact:

Re: B-Em

Post by bakoulis » Wed Mar 30, 2016 1:52 pm

Can you send me your source file to try?
Also send me a ready compiled 32bit b-em file with a full b-em directory zipped ready to go.
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

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

Re: B-Em

Post by richardtoohey » Wed Mar 30, 2016 6:52 pm

bakoulis wrote:Of course I have installed all the necessary libs, or else the compiling was impossible!
I'm no expert on the auto tools etc. so just trying to make sure you have the same set-up as me. I don't know if there are newer versions (e.g. Allegro 5) that might allow compilation to work, but causes failure at runtime. We need to eliminate everything, even the "obvious".
bakoulis wrote:Can you send me your source file to try?
Don't know what you mean by this. I go to http://b-em.bbcmicro.com/B-emv2.2Linux.tar.gz, tar xvzf that file, and follow the steps I've listed. I don't have any source other than that.
bakoulis wrote:Also send me a ready compiled 32bit b-em file with a full b-em directory zipped ready to go.
Yep, I'll zip up the lot and attach it here later.

From the backtrace:

Code: Select all

#2 0xb7ba878a in putc () from /lib/i386-linux-gnu/libc.so.6
#3 0x080cc19e in ide_init () at ide.c:45
ide.c line 45:

Code: Select all

 32 void ide_init(void)
 33 {
 34         char s[256];
 35         ide.pos2 = 1;
 36         ide.atastat = 0x40;
 37         ide_count = 0;
 38         if (!hdfile[0])
 39         {
 40                 sprintf(s, "%shd4.hdf", exedir);
 41                 hdfile[0] = fopen(s, "rb+");
 42                 if (!hdfile[0])
 43                 {
 44                         hdfile[0] = fopen(s, "wb");
 45                         putc(0, hdfile[0]);
It is trying to write to a hard disc file (?) and failing - so that seems to be where the fault is. That putc is failing. Not exactly sure what it is trying to do - might be worth you digging in there. e.g. put a breakpoint on line 45 and see what path it is trying to write to and make sure it has write permission, etc.

poink
Posts: 963
Joined: Tue Mar 01, 2011 10:27 am
Contact:

Re: B-Em

Post by poink » Thu Mar 31, 2016 12:38 am

richardtoohey wrote:Not exactly sure what it is trying to do - might be worth you digging in there. e.g. put a breakpoint on line 45 and see what path it is trying to write to and make sure it has write permission, etc.
What it looks like it's trying to do is open hd4.hdf and if it can't, create hd4.hdf and open that. It doesn't check that the create and open (at line 44) was successful though, so if it doesn't have write permission to the directory the executable is in, hdfile[0] will be a null pointer, so putc will deference a null pointer (I'm not sure why it blindly writes a zero into it - it doesn't do a seek before hand, so it's doesn't look like it's creating a sparse file)

The workaround would be to ensure that directory b-em is running from has a writable (by the user who's running B-em) hd4.hdf file in it (or the directory is writable), but it's definitely a bug in B-em, which should ideally be fixed.

If you're just looking for the path it's writing to, then you can find that out without recompiling by printing out file open system calls using strace (gdb can do this too, I believe), something like:

Code: Select all

strace -e open <executable>

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

Re: B-Em

Post by richardtoohey » Thu Mar 31, 2016 4:31 am

^^^^ what he said :lol:

You can reproduce the crash on another system (in this case OpenBSD) by something like this:

Code: Select all

$ /usr/bin/su root 
Password:
# chown root hd4.hdf                                                                                                     
# ^D
$ ./b-em 
B-em v2.2
Abort trap (core dumped) 
I'll look at changing b-em but someone might beat me to it.

So on your 3 Linux Mint systems - why can't b-em write the file? (There might be other files after this one, too, that it wants to create/write to.)

Change the file permissions back to my user account - b-em works fine:

Code: Select all

$ /usr/bin/su root 
Password:
# chown richard.toohey hd4.hdf
# ^D
$ ./b-em                                                                                                                 
B-em v2.2
$ 

User avatar
bakoulis
Posts: 294
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece
Contact:

Re: B-Em

Post by bakoulis » Fri Apr 01, 2016 12:19 am

poink wrote:
richardtoohey wrote:Not exactly sure what it is trying to do - might be worth you digging in there. e.g. put a breakpoint on line 45 and see what path it is trying to write to and make sure it has write permission, etc.
What it looks like it's trying to do is open hd4.hdf and if it can't, create hd4.hdf and open that. It doesn't check that the create and open (at line 44) was successful though, so if it doesn't have write permission to the directory the executable is in, hdfile[0] will be a null pointer, so putc will deference a null pointer (I'm not sure why it blindly writes a zero into it - it doesn't do a seek before hand, so it's doesn't look like it's creating a sparse file)

The workaround would be to ensure that directory b-em is running from has a writable (by the user who's running B-em) hd4.hdf file in it (or the directory is writable), but it's definitely a bug in B-em, which should ideally be fixed.

If you're just looking for the path it's writing to, then you can find that out without recompiling by printing out file open system calls using strace (gdb can do this too, I believe), something like:

Code: Select all

strace -e open <executable>
This advice gave me the solution!
The problem was the Greek letters into my home folder. So, the program hasn't the proper write permissions!
I have moved the emulators directory out of a Greek-font-name directory and both b-em and elkulator works just fine!
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

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

Re: B-Em

Post by richardtoohey » Fri Apr 01, 2016 12:48 am

Hurrah! =D> :D

That's good - b-em is pretty good, so glad you can now use it.

poink
Posts: 963
Joined: Tue Mar 01, 2011 10:27 am
Contact:

Re: B-Em

Post by poink » Fri Apr 01, 2016 2:47 am

bakoulis wrote:This advice gave me the solution!
The problem was the Greek letters into my home folder. So, the program hasn't the proper write permissions!
I have moved the emulators directory out of a Greek-font-name directory and both b-em and elkulator works just fine!
I'm guessing that it wasn't that the directory didn't have write permission (otherwise, you'd not have been able to extract or build it), but that b-em (and elkulator?) were trying to write to the wrong path? If so, that'd suggest another bug, this time in their handling of Unicode strings (...or lack of it).

That means it's either mixing Unicode and non-Unicode aware functions, or, more likely, directly interpreting character values (probably where it works out the exepath (given that's the current directory plus the path to the executable, minus the last element of that path).

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

Re: B-Em

Post by richardtoohey » Fri Apr 01, 2016 7:25 am

Line 40 - above - may be the culprit? Building a string of exedir + hd4.hdf into a char array - guess that is not going to work too well in a non-ASCII world (but might be talking out of my rear end, too.)

Might not be the best code but I appreciate b-em and it being released as open source. =D>

Gives us a chance to work on it. :D

User avatar
fordp
Posts: 1000
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Fri Apr 01, 2016 7:35 am

I think we need a single master repo on Github.

Dave (hoglet) has contributed an almost working 32016 CoPro in his branch.

We need to pull it all together.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
bakoulis
Posts: 294
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece
Contact:

Re: B-Em

Post by bakoulis » Fri Apr 01, 2016 7:54 am

To the Greek Version of Linux Mint, at the home folder uses Greek names for the common folders.

Desktop = Επιφάνεια Εργασίας
Documents = Έγγραφα
Downloads = Λήψεις
Pictures = Εικόνες
Music = Μουσική
Video = Βίντεο
...

As expected, downloads goes inside Λήψεις (Downloads) folder.
First place for extraction zipped files is this folder.
At most times is perfect for extracting and compiling without problems or warnings.
But few programs maybe have problems with Unicode.

Acorn emulators are not Unicode friendly (not expected) and with help of 'strace' command returns:

open("/home/takis/\303\216\302\233\303\216\302\256\303\217\302\210\303\216\302\265\303\216\302\271\303\217\302\202/ElkulatorV1.0//elk.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)

The solution is to move the new created folders out of Λήψεις folder (Downloads) and the emulators will works fine!
Thank you all for the help, advices and ideas.
:D
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

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

Re: B-Em

Post by richardtoohey » Fri Apr 01, 2016 8:53 am

Thanks for the additional information. :D

Would be nice to get b-em (and other Acorn emulators) working with this sort of thing (and as fordp says, get any fixes in a shared repository, so everyone can benefit.)

I might have a crack at it myself (making b-em handle this situation better), but I'm already well behind on other projects I want to be involved in! Too much stuff to do (work, home & just for fun) and not enough time.

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

Re: B-Em

Post by BigEd » Fri Apr 01, 2016 9:13 am

On Linux the unicode thing ought to just work - I get a similar strace when I wc a test file:

Code: Select all

open("/tmp/experiment/\316\233\316\256\317\210\316\265\316\271\317\202/hello/x.c", O_RDONLY) = 3
I wonder if the double slash // in the path is part of the problem, or at least a clue.

Code: Select all

open("/home/takis/\303\216\302\233\303\216\302\256\303\217\302\210\303\216\302\265\303\216\302\271\303\217\302\202/ElkulatorV1.0//elk.cfg", O_RDONLY) = -1 ENOENT (No such file or directory) 
ElkulatorV1.0//elk.cfg
should have been normalised, perhaps??

Edit: ah, looks like the unicode has been double-encoded, there are twice as many bytes in the problematic path component compared to what there should be.

Code: Select all

$ mkdir -p /tmp/experiment/Λήψεις/hello
$ echo hello > /tmp/experiment/Λήψεις/hello/x.c
$ strace wc /tmp/experiment/*/hello/x.c

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

Re: B-Em

Post by richardtoohey » Sat Apr 02, 2016 4:23 am

Don't know if anyone has tried, but I've compiled & run b-em on Raspberry Pi 3, Raspian Jessie. Seems to run fast enough (haven't done anything clever re. performance measurements, just run a couple of games and they seem to be running at normal speed.)

User avatar
trixster
Posts: 798
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

Re: B-Em

Post by trixster » Wed May 25, 2016 12:35 pm

Yeah B-Em runs really well on an rpi2 or rpi3, as does beebem (if using the desktop).
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

Stainy
Posts: 24
Joined: Sun Apr 15, 2012 9:07 pm
Contact:

Re: B-Em

Post by Stainy » Sat May 28, 2016 6:13 pm

richardtoohey wrote:Don't know if anyone has tried, but I've compiled & run b-em on Raspberry Pi 3, Raspian Jessie. Seems to run fast enough (haven't done anything clever re. performance measurements, just run a couple of games and they seem to be running at normal speed.)

Hi, would you be willing to share your binary? :) please..

poink
Posts: 963
Joined: Tue Mar 01, 2011 10:27 am
Contact:

Re: B-Em

Post by poink » Sat May 28, 2016 7:09 pm

BigEd wrote:ElkulatorV1.0//elk.cfg
should have been normalised, perhaps??
Just seen this - in case it helps anyone in future: multiple consecutive slashes in a POSIX path are equivalent to a single slash. (This is convenient because it allows constructs like cd "$PREFIX"/lib/ to work, regardless of whether $PREFIX is end with a slash or not.)

The only exception is at the start when "the first component following the leading <slash> characters may be interpreted in an implementation-defined manner, although more than two leading <slash> characters shall be treated as a single <slash> character"

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

Re: B-Em

Post by richardtoohey » Thu Jun 09, 2016 2:47 pm

Stainy wrote:Hi, would you be willing to share your binary? :) please..
Will do, just got to repeat my build instructions on a RPi3 and then I'll upload the binary.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Sun Feb 12, 2017 2:54 pm

Hi all,

Sorry to perhaps bring up an old thread, but some of the discussions in here are relevant to some of the ideas I've currently got for stardot/b-em.

At the moment, I've taken a look at b-em and I can see a few things (mostly bug-fixes) which I'd like to address before I look at making any coding changes for features. I feel as though it's important to do that first.

Whilst doing this, I want to make it clear that I will always be transparent in my changes. I appreciate that at the moment there's no requirement for anyone who has commit-bit rights to necessarily solicit feedback before making code changes, but I will at least keep people up-to-date with any changes I'm making so at least it's clear what I'm doing.

I would like to know if there's people out there who can help test these changes. My development environment is BSD at home, and Linux at work so those are the two OSes I've access to. What I don't have access to is a Windows machine, so I won't have any idea, necessarily, whether any changes I make will even compile on Windows, so any feedback there would be very welcomed.

There's one thing I would like feedback on -- currently there's a lot of chatter about having to copy around a copy of allegro,m4 from somewhere such that aclocal can find it, etc. Not only that, but a bunch of files are missing (because the project via configure.ac thinks it's GNU when it's missing half the files; that's OK). So what I've done is rationalise all of this. It's not necessary to copy allegro,m4 anywhere; we can use the copy I've added to the repository.

If someone can test the following branch:

https://github.com/stardot/b-em/tree/ta/configure.ac

That would be good. I haven't (yet) updated any of the documentation, but it should be enough to just run:

./autogen.sh && ./configure && make

(If you've previously had a copy of allegro.m4 in /usr/[local]/share/aclocal then remove it first).

Feedback and suggestions welcome.

Many thanks,
Thomas
Last edited by ThomasAdam on Sun Feb 12, 2017 6:40 pm, edited 1 time in total.

User avatar
fordp
Posts: 1000
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Sun Feb 12, 2017 5:04 pm

Hi,
I hope to get round to improving some back waters of b-em at some point.

I would just like to point out that Dave ( hoglet) has a branch with some improvements in particular a working 32016. There have been other changes mentioned on this forum too. It may be best to fold these changes in to your version before proceeding.

Cheers.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Post by tricky » Sun Feb 12, 2017 7:09 pm

I'm happy to test the windows build, but don't use git, other than to download a zip of everything on my not so fast connection.
I had to make a few changes to the source to build on Windows, so it might take a little time.
I will see if either repository has a Windows build that works for me. Getting all the libs together was a real pain on Windows and took days.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Sun Feb 12, 2017 7:12 pm

tricky wrote:I'm happy to test the windows build, but don't use git, other than to download a zip of everything on my not so fast connection.
I had to make a few changes to the source to build on Windows, so it might take a little time.
I will see if either repository has a Windows build that works for me. Getting all the libs together was a real pain on Windows and took days.
Great -- I'd really appreciate that, thank you. :) No rush though.

-- Thomas

User avatar
fordp
Posts: 1000
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Sun Feb 12, 2017 8:34 pm

tricky wrote:I'm happy to test the windows build, but don't use git, other than to download a zip of everything on my not so fast connection.
I had to make a few changes to the source to build on Windows, so it might take a little time.
I will see if either repository has a Windows build that works for me. Getting all the libs together was a real pain on Windows and took days.
If you could make some notes on the windows build that would be great.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
hoglet
Posts: 7919
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: B-Em

Post by hoglet » Mon Feb 13, 2017 8:41 am

Hi Thomas,

I see you have just normalized all the line endings across the whole repository:
https://github.com/stardot/b-em/commit/ ... 4a1beb5cf9

I think this will make it impossible now to merge all the different forks back together, as all you will get is conflicts (unless git's merge is far smarter than I give it credit for).

I wonder if it's worth doing a test to confirm this (or not) before more work is done.

I also have some concerns about relying on core.autocrlf (if this is indeed your plan). Is there a way to set this at the repository level?

Dave

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 9:27 am

hoglet wrote:Hi Thomas,

I see you have just normalized all the line endings across the whole repository:
https://github.com/stardot/b-em/commit/ ... 4a1beb5cf9

I think this will make it impossible now to merge all the different forks back together, as all you will get is conflicts (unless git's merge is far smarter than I give it credit for).

I wonder if it's worth doing a test to confirm this (or not) before more work is done.

I also have some concerns about relying on core.autocrlf (if this is indeed your plan). Is there a way to set this at the repository level?

Dave
Hi Dave,

Yeah, I tested this. The .gitattributes file will be responsible for ensuring consistency -- so assuming you merge from that point of view you'll be fine.

So for example:

Code: Select all

git clone git@github.com/stardot/b-em
cd b-em
git remote add some_other_bem_for git@github.com/user/foo-bem
git fetch foo-bem
git merge foo-bem/some_branch
The very presence of the .gitattributes file means that it'll use those settings over anything in ~/.gitconfig, for instance.

Kindly,
Thomas

User avatar
hoglet
Posts: 7919
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: B-Em

Post by hoglet » Mon Feb 13, 2017 9:45 am

I'm just trying to test this myself (on Linux), and something seems to be going wrong with the autocrlf stuff on initial checkout.

Any ideas?

Code: Select all

git clone git@github.com:stardot/b-em.git
Cloning into 'b-em'...
remote: Counting objects: 383, done.
remote: Compressing objects: 100% (166/166), done.
remote: Total 383 (delta 33), reused 0 (delta 0), pack-reused 214
Receiving objects: 100% (383/383), 959.64 KiB | 1.18 MiB/s, done.
Resolving deltas: 100% (71/71), done.
Checking connectivity... done.
dmb@quadhog:~/atom/stardot$ cd b-em/
dmb@quadhog:~/atom/stardot/b-em$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   COPYING
	modified:   Makefile.am
	modified:   README.md
	modified:   configure.ac
	modified:   src/Makefile.am
	modified:   src/Makefile.mingw
	modified:   src/b-em.vcxproj.user
	modified:   src/resid-fp/AUTHORS
	modified:   src/resid-fp/COPYING
	modified:   src/resid-fp/ChangeLog
	modified:   src/resid-fp/INSTALL
	modified:   src/resid-fp/Makefile.am
	modified:   src/resid-fp/Makefile.in
	modified:   src/resid-fp/NEWS
	modified:   src/resid-fp/README
	modified:   src/resid-fp/README.VICE
	modified:   src/resid-fp/aclocal.m4
	modified:   src/resid-fp/configure
	modified:   src/resid-fp/configure.in
	modified:   src/resid-fp/siddefs-fp.h.in
Dave

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 12:03 pm

hoglet wrote:I'm just trying to test this myself (on Linux), and something seems to be going wrong with the autocrlf stuff on initial checkout.

Any ideas?

Code: Select all

git clone git@github.com:stardot/b-em.git
Cloning into 'b-em'...
remote: Counting objects: 383, done.
remote: Compressing objects: 100% (166/166), done.
remote: Total 383 (delta 33), reused 0 (delta 0), pack-reused 214
Receiving objects: 100% (383/383), 959.64 KiB | 1.18 MiB/s, done.
Resolving deltas: 100% (71/71), done.
Checking connectivity... done.
dmb@quadhog:~/atom/stardot$ cd b-em/
dmb@quadhog:~/atom/stardot/b-em$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   COPYING
	modified:   Makefile.am
	modified:   README.md
	modified:   configure.ac
	modified:   src/Makefile.am
	modified:   src/Makefile.mingw
	modified:   src/b-em.vcxproj.user
	modified:   src/resid-fp/AUTHORS
	modified:   src/resid-fp/COPYING
	modified:   src/resid-fp/ChangeLog
	modified:   src/resid-fp/INSTALL
	modified:   src/resid-fp/Makefile.am
	modified:   src/resid-fp/Makefile.in
	modified:   src/resid-fp/NEWS
	modified:   src/resid-fp/README
	modified:   src/resid-fp/README.VICE
	modified:   src/resid-fp/aclocal.m4
	modified:   src/resid-fp/configure
	modified:   src/resid-fp/configure.in
	modified:   src/resid-fp/siddefs-fp.h.in
Dave
I missed some files. Should be fixed now.

Thanks!
Thomas

User avatar
fordp
Posts: 1000
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Mon Feb 13, 2017 12:17 pm

Is it possible to open up the wiki?

https://help.github.com/articles/changi ... for-wikis/

Cheers.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 12:27 pm

fordp wrote:Is it possible to open up the wiki?

https://help.github.com/articles/changi ... for-wikis/

Cheers.
Done.

-- Thomas Adam

User avatar
hoglet
Posts: 7919
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: B-Em

Post by hoglet » Mon Feb 13, 2017 1:16 pm

ThomasAdam wrote: I missed some files. Should be fixed now.
Thanks for sorting that.

I've just tried doing a test merge of my own fork, and get a huge number of conflicts, mostly on files I have not changed.

I think this is because the stardot B-Em project was create afresh, rather than by forking the existing parent project:
https://github.com/fesh0r/b-em/network

This is going to be true of all the outstanding work on the different forks.

I don't know why the stardot b-em project was created this way, especially as the initial commit pre-dated the stardot github organization.

Code: Select all

dmb@quadhog:~/atom/stardot/b-em$ git merge hoglet67/master 
Auto-merging src/x86.c
CONFLICT (add/add): Merge conflict in src/x86.c
Auto-merging src/win.c
CONFLICT (add/add): Merge conflict in src/win.c
Auto-merging src/win-keydefine.c
CONFLICT (add/add): Merge conflict in src/win-keydefine.c
Auto-merging src/wd1770.c
CONFLICT (add/add): Merge conflict in src/wd1770.c
Auto-merging src/video.c
CONFLICT (add/add): Merge conflict in src/video.c
Auto-merging src/vidalleg.c
CONFLICT (add/add): Merge conflict in src/vidalleg.c
Auto-merging src/via.h
CONFLICT (add/add): Merge conflict in src/via.h
Auto-merging src/via.c
CONFLICT (add/add): Merge conflict in src/via.c
Auto-merging src/uservia.c
CONFLICT (add/add): Merge conflict in src/uservia.c
Auto-merging src/uef.c
CONFLICT (add/add): Merge conflict in src/uef.c
Auto-merging src/tube.c
CONFLICT (add/add): Merge conflict in src/tube.c
Auto-merging src/tapenoise.c
CONFLICT (add/add): Merge conflict in src/tapenoise.c
Auto-merging src/tape.c
CONFLICT (add/add): Merge conflict in src/tape.c
Auto-merging src/sysvia.c
CONFLICT (add/add): Merge conflict in src/sysvia.c
Auto-merging src/ssd.c
CONFLICT (add/add): Merge conflict in src/ssd.c
Auto-merging src/soundopenal.c
CONFLICT (add/add): Merge conflict in src/soundopenal.c
Auto-merging src/sound.h
CONFLICT (add/add): Merge conflict in src/sound.h
Auto-merging src/sound.c
CONFLICT (add/add): Merge conflict in src/sound.c
Auto-merging src/sn76489.c
CONFLICT (add/add): Merge conflict in src/sn76489.c
Auto-merging src/serial.h
CONFLICT (add/add): Merge conflict in src/serial.h
Auto-merging src/serial.c
CONFLICT (add/add): Merge conflict in src/serial.c
Auto-merging src/scan2bbc.h
CONFLICT (add/add): Merge conflict in src/scan2bbc.h
Auto-merging src/savestate.c
CONFLICT (add/add): Merge conflict in src/savestate.c
Auto-merging src/resources.h
CONFLICT (add/add): Merge conflict in src/resources.h
Auto-merging src/resid.cc
CONFLICT (add/add): Merge conflict in src/resid.cc
Auto-merging src/resid-fp/wave.h
CONFLICT (add/add): Merge conflict in src/resid-fp/wave.h
Auto-merging src/resid-fp/wave.cc
CONFLICT (add/add): Merge conflict in src/resid-fp/wave.cc
Auto-merging src/resid-fp/sid.h
CONFLICT (add/add): Merge conflict in src/resid-fp/sid.h
Auto-merging src/resid-fp/sid.cc
CONFLICT (add/add): Merge conflict in src/resid-fp/sid.cc
Auto-merging src/resid-fp/samp2src.pl
CONFLICT (add/add): Merge conflict in src/resid-fp/samp2src.pl
Auto-merging src/resid-fp/filter.h
CONFLICT (add/add): Merge conflict in src/resid-fp/filter.h
Auto-merging src/resid-fp/filter.cc
CONFLICT (add/add): Merge conflict in src/resid-fp/filter.cc
Auto-merging src/resid-fp/envelope.h
CONFLICT (add/add): Merge conflict in src/resid-fp/envelope.h
Auto-merging src/resid-fp/envelope.cc
CONFLICT (add/add): Merge conflict in src/resid-fp/envelope.cc
Auto-merging src/resid-fp/convolve-sse.cc
CONFLICT (add/add): Merge conflict in src/resid-fp/convolve-sse.cc
Auto-merging src/resid-fp/ChangeLog
CONFLICT (add/add): Merge conflict in src/resid-fp/ChangeLog
Auto-merging src/pal.c
CONFLICT (add/add): Merge conflict in src/pal.c
Auto-merging src/mouse.c
CONFLICT (add/add): Merge conflict in src/mouse.c
Auto-merging src/model.h
CONFLICT (add/add): Merge conflict in src/model.h
Auto-merging src/model.c
CONFLICT (add/add): Merge conflict in src/model.c
Auto-merging src/mem.h
CONFLICT (add/add): Merge conflict in src/mem.h
Auto-merging src/mem.c
CONFLICT (add/add): Merge conflict in src/mem.c
Auto-merging src/main.c
CONFLICT (add/add): Merge conflict in src/main.c
Auto-merging src/linux.c
CONFLICT (add/add): Merge conflict in src/linux.c
Auto-merging src/linux-keydefine.c
CONFLICT (add/add): Merge conflict in src/linux-keydefine.c
Auto-merging src/linux-gui.c
CONFLICT (add/add): Merge conflict in src/linux-gui.c
Auto-merging src/keyboard.c
CONFLICT (add/add): Merge conflict in src/keyboard.c
Auto-merging src/ide.c
CONFLICT (add/add): Merge conflict in src/ide.c
Auto-merging src/i8271.c
CONFLICT (add/add): Merge conflict in src/i8271.c
Auto-merging src/fdi2raw.c
CONFLICT (add/add): Merge conflict in src/fdi2raw.c
Auto-merging src/fdi.c
CONFLICT (add/add): Merge conflict in src/fdi.c
Auto-merging src/disc.c
CONFLICT (add/add): Merge conflict in src/disc.c
Auto-merging src/debugger.c
CONFLICT (add/add): Merge conflict in src/debugger.c
Auto-merging src/ddnoise.h
CONFLICT (add/add): Merge conflict in src/ddnoise.h
Auto-merging src/ddnoise.c
CONFLICT (add/add): Merge conflict in src/ddnoise.c
Auto-merging src/csw.c
CONFLICT (add/add): Merge conflict in src/csw.c
Auto-merging src/config.c
CONFLICT (add/add): Merge conflict in src/config.c
Auto-merging src/cmos.c
CONFLICT (add/add): Merge conflict in src/cmos.c
Auto-merging src/bbctext.h
CONFLICT (add/add): Merge conflict in src/bbctext.h
Auto-merging src/b-em.vcxproj.filters
CONFLICT (add/add): Merge conflict in src/b-em.vcxproj.filters
Auto-merging src/b-em.vcxproj
CONFLICT (add/add): Merge conflict in src/b-em.vcxproj
Auto-merging src/b-em.rc
CONFLICT (add/add): Merge conflict in src/b-em.rc
Auto-merging src/b-em.h
CONFLICT (add/add): Merge conflict in src/b-em.h
Auto-merging src/acia.c
CONFLICT (add/add): Merge conflict in src/acia.c
Auto-merging src/65816.c
CONFLICT (add/add): Merge conflict in src/65816.c
Auto-merging src/6502tube.c
CONFLICT (add/add): Merge conflict in src/6502tube.c
Auto-merging src/6502.c
CONFLICT (add/add): Merge conflict in src/6502.c
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Auto-merging .gitattributes
CONFLICT (add/add): Merge conflict in .gitattributes
Automatic merge failed; fix conflicts and then commit the result.
Dave

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 1:28 pm

hoglet wrote:I think this is because the stardot B-Em project was create afresh, rather than by forking the existing parent project:
https://github.com/fesh0r/b-em/network
OK, Dave. I don't think it's going to be a problem. When I get home tonight, I'll take a look to see what's going on and how we can fix this.

Kindly,
Thomas

Post Reply