B-Em

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
hoglet
Posts: 7768
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: B-Em

Post by hoglet » Tue Feb 21, 2017 9:23 am

My personal view, on reflection, is that it would be better to re-fork from https://github.com/fesh0r/b-em and then re-apply your changes (possibly with the exception of the line endings change unless you are 110% sure this is not going to cause merge conflicts).

I appreciate this is quite a lot of work, but it should be possible to automate the generation of a set of patches from your current repository. There may be better ways, but that's what I would do I think.

The concerns (again on reflection) I have with where we are currently are the loss of the history of previous b-em releases, and the loss of history of changes on various forks. It also means everyone abandoning their existing forks and starting afresh. All because the initial repository on stardot (before your time) was accidentally created in the wrong way.

Dave

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

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 9:28 am

OK -- leave it with me. I'll let you know when it's done.

Kindly,
Thomas

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

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 12:47 pm

Right, all done.

See: https://github.com/stardot/b-em

This is all of my changes on top of Andrew McRae's (fesh0r) repository.

As a test, I took hoglet's repository and did the following:

Code: Select all

git clone git@github.com:stardot/b-em.git
cd b-em
git remote add hoglet git@github.com:stardot/b-em.git
git fetch hoglet
git checkout -t hoglet/master -b hoglet-master
git rebase -i master
This gave me a set of patches I could then apply. I shall leave this up to those individuals who want to ensure their changes are working before submitting code changes, etc. I'm fully expecting there to be code conflicts given the changes I have made since a lot of these patches were made.

Note that I have only verified the result of this compiles under Linux/BSD. I cannot speak about Windows at all, so if someone wants to test that, please do -- and if you could let me know the instructions, I can add that either to the README.md file, or the wiki.

Incidentally, the wiki will need to be moved across from stardot/bem-ARCHIVE -- I can look at that later on if no one wants to do that.

Any problems, let me know.

Kindly,
Thomas

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

Re: B-Em

Post by fordp » Tue Feb 21, 2017 12:52 pm

Many thanks Thomas.

Having said that I am short of time at the moment so will not get round to contributing for a couple of weeks.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Post by BigEd » Tue Feb 21, 2017 1:10 pm

Great to get the history in there Thomas, but I notice the repo doesn't look like a fork from GitHub's tooling perspective:
https://github.com/stardot/b-em/network/members

I think the right answer to this may be to delete the repo from GitHub and recreate it by forking, then apply your changes... somehow. Perhaps do this on another copy, just in case? Or wait for other inputs.

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

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 1:12 pm

BigEd wrote:Great to get the history in there Thomas, but I notice the repo doesn't look like a fork from GitHub's tooling perspective:
https://github.com/stardot/b-em/network/members

I think the right answer to this may be to delete the repo from GitHub and recreate it by forking, then apply your changes... somehow. Perhaps do this on another copy, just in case? Or wait for other inputs.
It's not a fork though -- that "members" page is for people who've forked the stardot/b-em repository and contributed back. I'm expecting this is what people will end up doing over time.

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

Re: B-Em

Post by BigEd » Tue Feb 21, 2017 1:15 pm

Beg to differ - it shows the full tree of all parents and children, like this:
https://github.com/stardot/beebem/network/members

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

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 1:18 pm

BigEd wrote:Beg to differ - it shows the full tree of all parents and children, like this:
https://github.com/stardot/beebem/network/members
Oh, that. Well, how important is this? I really do not want to do this work again. I'm not sure I see the benefit, especially since the former b-em repository only listed one other member, so that was already out of date.

Kindly,
Thomas

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

Re: B-Em

Post by BigEd » Tue Feb 21, 2017 1:22 pm

I can understand you wouldn't want to redo a bunch of work. On the other hand, this is the starting point of something which is hoped to be definitive, so I'd say it's worth doing right. This is the family I think you should be joining:
https://github.com/fesh0r/b-em/network/members

Having said which, it's not me doing the work!

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

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 1:26 pm

BigEd wrote:I can understand you wouldn't want to redo a bunch of work. On the other hand, this is the starting point of something which is hoped to be definitive, so I'd say it's worth doing right. This is the family I think you should be joining:
https://github.com/fesh0r/b-em/network/members

Having said which, it's not me doing the work!
Well, see: https://help.github.com/articles/listin ... epository/

So that "timeline" you're referring to isn't what you think it is, as far as I can tell. So as and when people decide to work the repository, this map will get updated. Does it matter whether I take some other b-em repository as a starting point to retain that? No, I don't believe it is. It's the people who contribute back to the repository now which is the more important thing to track, and only time will see if that happens. I hope it will.

Am I going to change this? No. I don't believe it adds anything.

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

Re: B-Em

Post by hoglet » Tue Feb 21, 2017 2:41 pm

Thomas, thanks for your efforts on this.

As I understand it, forks are a github level concept rather than a git level concept. i.e. the information that indicates B is a fork of A is held in a github database, rather than in the git repository B. At least, I think that's how it's done.

To be able to successfully merge to branches, all that git requires is a both branches share a common ancestor, which they currently do, e.g.
https://github.com/fesh0r/b-em/commit/0 ... 9658707a6a
and
https://github.com/stardot/b-em/commit/ ... 9658707a6a

I'm trying to get the 32016 work ready for inclusion, and I've been able to create a test branch in my own repository with just the 32016 commits, and then merge the latest commit from stardot into this.

That said, if github doesn't know stardot is a legitimate fork, then I'm not sure how one would go about creating a pull request.

I think it is possible to add the fork relationship after the fact, but it would involve (in hand wavy terms):
- save a copy of the startgit b-em repository with all current commits
- delete the repository on github
- fork from fesh0r using the github UI
- push the saved copy back again

I wonder if it's possible to get github tech support to manually add the fork relationship?

I'm going to carry on working on the 32016 stuff this afternoon, see if I can get it running in the new build environment, then try to create a pull request.

Thomas, any thoughts about this build issue?

Code: Select all

checking for Allegro - version >= 4.0.0... no
*** Could not run Allegro test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means Allegro was incorrectly installed
*** or that you have moved Allegro since it was installed. In the latter case, you
*** may want to edit the allegro-config script: /usr/bin/allegro-config
configure: error: building B-em requires Allegro to be installed
dmb@quadhog:~/atom/b-em$ which allegro-config 
/usr/bin/allegro-config
dmb@quadhog:~/atom/b-em$ /usr/bin/allegro-config --version
4.4.2
Should it not build against 4.4.0?

Dave

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

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 2:52 pm

hoglet wrote:Thomas, any thoughts about this build issue?

Code: Select all

checking for Allegro - version >= 4.0.0... no
*** Could not run Allegro test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means Allegro was incorrectly installed
*** or that you have moved Allegro since it was installed. In the latter case, you
*** may want to edit the allegro-config script: /usr/bin/allegro-config
configure: error: building B-em requires Allegro to be installed
dmb@quadhog:~/atom/b-em$ which allegro-config 
/usr/bin/allegro-config
dmb@quadhog:~/atom/b-em$ /usr/bin/allegro-config --version
4.4.2
Should it not build against 4.4.0?
It should be fine. Can you tell me:

* What your environment is (Linux version, GCC version, etc.)
* What version of autotools you're using
* What the contents of config.log is

I presume you ran autogen.sh first of all?

Kindly,
Thomas

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

Re: B-Em

Post by hoglet » Tue Feb 21, 2017 3:03 pm

ThomasAdam wrote: Can you tell me:
* What your environment is (Linux version, GCC version, etc.)
Ubuntu 14.04

gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
ThomasAdam wrote: * What version of autotools you're using
How do I find this out?
ThomasAdam wrote: * What the contents of config.log is
Here's the last part...

Code: Select all

configure:4175: checking for allegro-config
configure:4193: found /usr/bin/allegro-config
configure:4206: result: /usr/bin/allegro-config
configure:4215: checking for Allegro - version >= 4.0.0
configure:4318: gcc -o conftest -g -O2 -Wall -Werror -Wno-format-security -D_GNU_SOURCE -I/usr/include   -L/usr/local/lib conftest.c -L/usr/lib/i386-linux-gnu -lalleg  >&5
conftest.c: In function 'main':
conftest.c:24:9: error: ignoring return value of 'system', declared with attribute warn_unused_result [-Werror=unused-result]
   system("touch conf.allegrotest");
         ^
cc1: all warnings being treated as errors
configure:4318: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "B-em"
| #define PACKAGE_TARNAME "b-em"
| #define PACKAGE_VERSION "0111abb"
| #define PACKAGE_STRING "B-em 0111abb"
| #define PACKAGE_BUGREPORT "thomas@xteddy.org"
| #define PACKAGE_URL ""
| #define PACKAGE "b-em"
| #define VERSION "0111abb"
| /* end confdefs.h.  */
| 
| #include <stdlib.h>
| #include <stdio.h>
| #include <string.h>
| #include <allegro.h>
| 
| int
| main()
| {
|   int allegro_major_version, allegro_minor_version, allegro_micro_version;
|   int major, minor, micro;
|   char *tmp_version;
| 
|   system("touch conf.allegrotest");
| 
|   /* Capture allegro-config output via autoconf/configure variables */
|   /* HP/UX 9 (%@#!) writes to sscanf strings */
|   tmp_version = (char *)strdup("4.0.0");
|   if (sscanf(tmp_version, "%d.%d.%d", &major, &minor, &micro) != 3) {
|      printf("%s, bad version string from allegro-config\n", "4.0.0");
|      free(tmp_version);
|      exit(1);
|    }
|    free(tmp_version);
| 
|    /* Capture the version information from the header files */
|    allegro_major_version = ALLEGRO_VERSION;
|    allegro_minor_version = ALLEGRO_SUB_VERSION;
|    allegro_micro_version = ALLEGRO_WIP_VERSION;
| 
|  /* Compare allegro-config output to the Allegro headers */
|   if ((allegro_major_version != 4) ||
|       (allegro_minor_version != 4))
| 
|     {
|       printf("*** Allegro header files (version %d.%d.%d) do not match\n",
|          allegro_major_version, allegro_minor_version, allegro_micro_version);
|       printf("*** allegro-config (version %d.%d.%d)\n",
|          4, 4, 2);
|       return 1;
|     }
| /* Compare the headers to the library to make sure we match */
|   /* Less than ideal -- doesn't provide us with return value feedback,
|    * only exits if there's a serious mismatch between header and library.
|    */
|    	/* TODO:
| 	 * This doesnt work!
| 	 */
|     /* ALLEGRO_TEST_VERSION; */
| 
|     /* Test that the library is greater than our minimum version */
|     if ((4 > major) ||
|         ((4 == major) && (4 > minor)) ||
|         ((4 == major) && (4 == minor) &&
|         (2 >= micro)))
|       {
|         return 0;
|        }
|      else
|       {
|         printf("\n*** An old version of Allegro (%d.%d.%d) was found.\n",
|                allegro_major_version, allegro_minor_version, allegro_micro_version);
|         printf("*** You need a version of Allegro newer than %d.%d.%d. The latest version of\n",
|            major, minor, micro);
|         printf("*** Allegro is always available from http://alleg.sf.net.\n");
|         printf("***\n");
|         printf("*** If you have already installed a sufficiently new version, this error\n");
|         printf("*** probably means that the wrong copy of the allegro-config shell script is\n");
|         printf("*** being found. The easiest way to fix this is to remove the old version\n");
|         printf("*** of Allegro, but you can also set the ALLEGRO_CONFIG environment to point to the\n");
|         printf("*** correct copy of allegro-config. (In this case, you will have to\n");
|         printf("*** modify your LD_LIBRARY_PATH enviroment variable, or edit /etc/ld.so.conf\n");
|         printf("*** so that the correct libraries are found at run-time))\n");
|     }
|   return 1;
| } END_OF_MAIN()
| 
configure:4337: result: no
configure:4365: gcc -o conftest -g -O2 -Wall -Werror -Wno-format-security -D_GNU_SOURCE -I/usr/include   -L/usr/local/lib conftest.c  -L/usr/lib/i386-linux-gnu -lalleg >&5
conftest.c: In function 'main':
conftest.c:18:2: error: 'ALLEGRO_TEST_VERSION' undeclared (first use in this function)
  ALLEGRO_TEST_VERSION; return 0;
  ^
conftest.c:18:2: note: each undeclared identifier is reported only once for each function it appears in
configure:4365: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "B-em"
| #define PACKAGE_TARNAME "b-em"
| #define PACKAGE_VERSION "0111abb"
| #define PACKAGE_STRING "B-em 0111abb"
| #define PACKAGE_BUGREPORT "thomas@xteddy.org"
| #define PACKAGE_URL ""
| #define PACKAGE "b-em"
| #define VERSION "0111abb"
| /* end confdefs.h.  */
| 
| #include <allegro.h>
| #include <stdio.h>
| 
| int
| main ()
| {
|  ALLEGRO_TEST_VERSION; return 0;
|   ;
|   return 0;
| }
configure:4390: error: building B-em requires Allegro to be installed
ThomasAdam wrote: I presume you ran autogen.sh first of all?
Yes.

Dave

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

Re: B-Em

Post by hoglet » Tue Feb 21, 2017 3:26 pm

It seems to be to do with warnings being promoted to errors.

This lets me work around it:

Code: Select all

dmb@quadhog:~/atom/b-em$git diff
diff --git a/configure.ac b/configure.ac
index 11ce772..f3a0107 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ AC_MSG_CHECKING([whether to enable debugging])
 AC_ARG_ENABLE(debug,
              AC_HELP_STRING([--enable-debug], [build debug executable]))
 
-CF_WARNINGS="-Wall -Werror -Wno-format-security"
+CF_WARNINGS="-Wall -Wno-format-security"
 if test "$enable_debug" = "yes"; then
    CFLAGS="$CFLAGS $CF_WARNINGS -O0 -ggdb -D_DEBUG -D_GNU_SOURCE"
    LDFLAGS="$LDFLAGS -L/usr/local/lib"
Dave

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

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 3:39 pm

hoglet wrote:

Code: Select all

configure:4175: checking for allegro-config
configure:4193: found /usr/bin/allegro-config
configure:4206: result: /usr/bin/allegro-config
configure:4215: checking for Allegro - version >= 4.0.0
configure:4318: gcc -o conftest -g -O2 -Wall -Werror -Wno-format-security -D_GNU_SOURCE -I/usr/include   -L/usr/local/lib conftest.c -L/usr/lib/i386-linux-gnu -lalleg  >&5
conftest.c: In function 'main':
conftest.c:24:9: error: ignoring return value of 'system', declared with attribute warn_unused_result [-Werror=unused-result]
   system("touch conf.allegrotest");
         ^
cc1: all warnings being treated as errors
configure:4318: $? = 1
Heh -- I love -Werror, it's so much fun.

I can't say for sure, but I think I've fixed this correctly by changing allegro's test program. If you git pull now and try my change, does that help?

Kindly,
Thomas

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

Re: B-Em

Post by hoglet » Tue Feb 21, 2017 3:43 pm

ThomasAdam wrote: I can't say for sure, but I think I've fixed this correctly by changing allegro's test program. If you git pull now and try my change, does that help?
Yes, that fixed is.

Dave

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

Re: B-Em

Post by hoglet » Tue Feb 21, 2017 4:29 pm

I've got my 32016 branch to the point now where it has the latest 32016 Emulation from PiTubeDirect, and it builds and runs (on Linux at least) under the new build system:
BEmPanos0.png
BemPanos1.png
BEmPanos2.png
I've pushed the code back to a branch my in my B-Em fork:
https://github.com/hoglet67/b-em/commits/test-32016

Now I've gone to try to create a pull request, and (as expected) the stardot repository is not present in the dropdown list:
BEmPull.png
I then tried to manually create one, on the stardot/b-em page, but this doesn't seem possible either:
BEmPull2.png
Now, I could send you and email with the commit ID, and you could fetch and merge this manually. But this does seem to be missing one of the nice features of github, being able to manage and merge incoming pull requests, and this be visible to the whole community.

Any thoughts?

Dave

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

Re: B-Em

Post by Coeus » Tue Feb 21, 2017 5:54 pm

ThomasAdam wrote:So I noticed that BeebBm ships with a copy of the Acorn ROMs in its source.

I happen to work with Rebecca Gellman (whom some of you may have known as Richard Gellman) who told me that it's generally a bit of a minefield as to the copyright, but she's told me that as long as we don't charge for the ROMs, the distribution of the ROMs is considered "fine".

So would anyone object to my adding the ROMs to the git repository? Assuming I'm not about to open up a can of legal worms, that is! It would make releases a tonne easier on my part (when I change autotools to do that for us...)

Kindly,
Thomas
Bear in mind I am not a lawyer but the legalities of "abandonware" are interesting. I don't think there is any doubt that the ROMs are covered by copyright that will not have expired due to time. On the other hand for anyone to be prosecuted for infringement someone who claims to own the copyright or be acting on their behalf has to initiate the action. As I understand Acorn are no longer in business they are hardly likely to do that. Technically, if a company is wound up, the copyright should pass to someone else as the assets of the company are sold but whether that person or company knows they now have the benefit of it, or would see any point in sueing for infringement is another matter.

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

Re: B-Em

Post by BigEd » Tue Feb 21, 2017 6:17 pm

That matches my understanding. It seems reasonable to proceed, and to take down the offending material in the very very unlikely event that the copyright holder objects.

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

Re: B-Em

Post by Coeus » Tue Feb 21, 2017 6:31 pm

ThomasAdam wrote: Heh -- I love -Werror, it's so much fun.

I can't say for sure, but I think I've fixed this correctly by changing allegro's test program. If you git pull now and try my change, does that help?

Kindly,
Thomas
I have just found another compilation issue on Linux related to this:

Code: Select all

6502.c:496:33: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
                                 if (p.c) temp|=1; if (p.z) temp|=2;
                                 ^~
and many more similar cases.

Not sure what to do with this in the short term. I suppose we could disable that warning for that file (and 6502tube.c) or we could fix the formatting, i.e. change it such that GCC doesn't generate the warning. Feeding each of 6502.c and 6502tube.c through GNU indent results in files that do compile.

How attached are people to code formatting?

chrisn
Posts: 409
Joined: Sat Apr 19, 2014 11:31 am
Location: UK
Contact:

Re: B-Em

Post by chrisn » Tue Feb 21, 2017 7:04 pm

hoglet wrote:Now I've gone to try to create a pull request, and (as expected) the stardot repository is not present in the dropdown list:
For this to work, the stardot repo would have to be a genuine fork of the fesh0r repo.
Coeus wrote:I have just found another compilation issue on Linux related to this:

Code: Select all

6502.c:496:33: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
                                 if (p.c) temp|=1; if (p.z) temp|=2;
                                 ^~
and many more similar cases.
This was the change I was planning to contribute - putting each "if" on its own line fixes the warnings and keeps GCC 6 happy.

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

Re: B-Em

Post by tricky » Tue Feb 21, 2017 9:29 pm

I have just downloaded the b-em-master.zip from github (I have never used git) and this is the story of what I had to do to make it build using VS2013 community on windows 7.

Where I use ... in the following, I mean the path to where you have your files.

Download and extract http://download.gna.org/allegro/allegro ... -4.2.2.zip

add ...\allegro-msvc80-4.2.2\include to the [Additional Include Directories] of both configurations

add ALLEGRO_HAVE_STDINT_H to [Preprocessor Defines] of both configurations

In ...\allegro-msvc80-4.2.2\include\allegro\platform\almsvc.h comment out the following two lines:
//#define int64_t signed __int64
//#define uint64_t unsigned __int64

Download and extract http://www.zlib.net/zlib1211.zip

add ...\zlib-1.2.11 to the [Additional Include Directories] of both configurations

Download, extract and run the OpenAL installer https://www.openal.org/downloads/OpenAL11CoreSDK.zip
On Win64 the default location is C:\Program Files (x86)\OpenAL 1.1 SDK

In soundopenal.c change the two OpenAL includes to be:
#include <al.h>
//#include <AL/alut.h>

Add ...\allegro-msvc80-4.2.2\lib to [Additional Library Directories]

Build Project:zlibvc Configuration: ReleaseWithoutAsm Platform:Win32 using ...\zlib-1.2.11\contrib\vstudio\vc12\zlibvc.sln

In [Additional Dependencies], swap zlib.lib with ...\zlib-1.2.11\contrib\vstudio\vc12\x86\ZlibDllReleaseWithoutAsm\zlibwapi.lib

Add ...\OpenAL 1.1 SDK\libs\Win32 to [Additional Library Directories]

Remove alut.lib from [Additional Dependencies]

At the top of uef.c and csw.c, add:
#define ZLIB_WINAPI
#define NOGDI

At the end of win.c, just before the #endif, add these lines:
FILE *x_fopen(const char * file, const char * mode)
{
return fopen(file, mode);
}

Then to run b-em you will need to copy the following files to the directory where b-em.exe is:
...\allegro-msvc80-4.2.2\bin\alleg42.dll
...\zlib-1.2.11\contrib\vstudio\vc12\x86\ZlibDllReleaseWithoutAsm\zlibwapi.dll

Finally, copy b-em.cfg and the following folders from a current install of b-em to the folder where b-em.exe is:
ddnoise
discs
roms
src
tapes

I'm not sure how much of an existing install is required, but I am out of time.

This is not how I did it last time, but I think it is near the minimum amount of changes required!

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

Re: B-Em

Post by Coeus » Tue Feb 21, 2017 10:01 pm

tricky wrote:I have just downloaded the b-em-master.zip from github (I have never used git) and this is the story of what I had to do to make it build using VS2013 community on windows 7.
Thanks. I have not tried those instructions (yet) but it seems a like quite a long-winded process compared to the Linux compile process.

Does Windows have a generally accepted place to install things - you mentioned that for one of the downloads, but could there be a standard place to put the others? Is Program Files\Vendor\Product a kind of standard? I am thinking if that was the case could a "project" file be included in the distribution so all you'd have to is:

1. Download the dependencies to the correct place.
2. Open the project file.
3. Build the project.

Likewise I think we need to get any code changes to B-Em back into the repository, though I would like to improve upon that x_fopen wrapper first.

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

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 11:04 pm

hoglet wrote:I've pushed the code back to a branch my in my B-Em fork:
https://github.com/hoglet67/b-em/commits/test-32016
Excellent. That sounds great. One thing you can do now is move your current b-em repo out of the way (I did this on Github by renaming), fork the stardot/b-em repo, and then clone that fork. Then, from your local clone of your *original* b-em repository:

Code: Select all

git remote add old-b-em /path/to/old/b-em/repository
git fetch old-b-em
git checkout -t old-b-em/some-local-branch-name -b some-local-branch-name
git push origin HEAD
Submit your pull request.

HTH,
Thomas

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

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 11:10 pm

Coeus wrote: I have just found another compilation issue on Linux related to this:

Code: Select all

6502.c:496:33: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
                                 if (p.c) temp|=1; if (p.z) temp|=2;
                                 ^~
and many more similar cases.

Not sure what to do with this in the short term. I suppose we could disable that warning for that file (and 6502tube.c) or we could fix the formatting, i.e. change it such that GCC doesn't generate the warning. Feeding each of 6502.c and 6502tube.c through GNU indent results in files that do compile.

How attached are people to code formatting?
I'm attached to the formatting -- and blanket-bombing indent(1) over the source tree won't work -- indeed, for me, indent(1) mangles quite a bit of the files such that the code no longer compiles -- this is a separate issue though.

As for the warning, my toolchain is such that I don't have access to GCC6. Having read up on the warning, it's not enough to just trust a reindent will solve potential problems. If you're able, can you send me a diff which fixes the errors? If not, you can always temporarily add " -Wno-misleading-indentation" to CF_WARNINGS in configure.ac

Kindly,
Thomas

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: B-Em

Post by paulb » Tue Feb 21, 2017 11:17 pm

ThomasAdam wrote:
Coeus wrote: I have just found another compilation issue on Linux related to this:

Code: Select all

6502.c:496:33: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
                                 if (p.c) temp|=1; if (p.z) temp|=2;
                                 ^~
I'm attached to the formatting -- and blanket-bombing indent(1) over the source tree won't work -- indeed, for me, indent(1) mangles quite a bit of the files such that the code no longer compiles -- this is a separate issue though.
I guess it is warning that the author might have written "if (p.c)" and then expected the rest of the line to be covered, whereas the "if (p.z)" is a separate statement that doesn't depend on the preceding one.

Of course, the author didn't intend that, most likely, but someone reading the code might not immediately see what's really going on.

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

Re: B-Em

Post by tricky » Tue Feb 21, 2017 11:44 pm

Coeus, it is a bit long winded!
I have built it before with less hassle building, but much more hassle finding the exact version of the supporting libraries from internet cache sites, this time I went with versions suggested by the housing sites.

They are all very old versions, built with old compilers and don't really install/build in a very Windows like way.

When you wrote an app on Windows for about the last 15 years, you were expected to use directx for input, sound and graphics and win32 for the rest.

Program files is for applications, but not their data and not for source code or libraries.

I guess if I wanted to go cross platform, I would try QT, but then probably wouldn't want to use the newer versions. A visual studio cross platform project using angle internally would give hardware accelerated graphics, but not much else and I don't know how useful that would be anyway.

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

Re: B-Em

Post by hoglet » Wed Feb 22, 2017 7:50 am

Building B-Em on Windows is an interesting discussion topic....

I think the way this was originally done by Sarah Walker, the original B-Em author, was using a standard MinGW environment (the same that is used to build Atomulator). Not being a fan of Microsoft compilers, this is the way I have always done it as well.

I've just tried this with the latest code base, and eventually succeeded:
BEmPan1.png
For the record, here's what I needed to do.

Add a cleanbm.bat script:

Code: Select all

@echo off
PATH=C:\mingw\bin;c:\mingw\msys\1.0\bin
c:
cd \mingw\B-Em\src
make -f Makefile.win clean
cd..\..
Add a makebem.bat script:

Code: Select all

@echo off
PATH=C:\mingw\bin;c:\mingw\msys\1.0\bin
c:
cd \mingw\B-Em\src
make -f Makefile.win b-em.res 
make -f Makefile.win
cd..\..
Re-instate the src/Makefile.win file that just got deleted: :shock:

Code: Select all

VPATH = . resid-fp NS32016
CPP  = g++.exe
CC   = gcc.exe
WINDRES = windres.exe
CFLAGS = -O3 -DBEEBEM  -DVERSION=
OBJ = compat_wrappers.o 6502.o 6502tube.o 32016.o Decode.o mem32016.o Trap.o Profile.o NSDis.o 65816.o acia.o adc.o adf.o arm.o cmos.o compact_joystick.o compactcmos.o config.o csw.o ddnoise.o debugger.o disc.o fdi2raw.o fdi.o i8271.o ide.o keyboard.o main.o mem.o model.o mouse.o pal.o savestate.o serial.o sn76489.o sound.o soundopenal.o ssd.o sysvia.o tape.o tapenoise.o tube.o uef.o uservia.o via.o vidalleg.o video.o wd1770.o win.o win-catalogue.o win-keydefine.o x86.o z80.o resid.o b-em.res
SIDOBJ = convolve.o envelope.o extfilt.o filter.o pot.o sid.o voice.o wave6581__ST.o wave6581_P_T.o wave6581_PS_.o wave6581_PST.o wave8580__ST.o wave8580_P_T.o wave8580_PS_.o wave8580_PST.o wave.o

LIBS =  -mwindows -lalleg -lz -lalut -lopenal32 -lgdi32 -lwinmm -lstdc++

all : b-em.exe

b-em.exe: $(OBJ) $(SIDOBJ)
	$(CC) $(OBJ) $(SIDOBJ) -o "b-em.exe" $(LIBS)

clean :
	del *.o
	del *.exe
	del *.res

%.o : %.c
	$(CC) $(CFLAGS) -c $<

%.o : %.cc
	$(CPP) $(CFLAGS) -c $<

b-em.res: b-em.rc
	$(WINDRES) -i b-em.rc --input-format=rc -o b-em.res -O coff
Make one code change to src/compat_wrappers.c, as asprintf() is not supported in MinGW (at least, not in the version I have). Could we possibly avoid making further use of asprintf in the future?

I'm just putting this out there as an idea for one way to get a Windows executable. It clearly won't meet everyone's needs, but it matches the way the we build Atomulator for Windows.

I'd like the code base to retain this as an option if at all possible.

Dave

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

Re: B-Em

Post by fordp » Wed Feb 22, 2017 8:01 am

hoglet wrote:Building B-Em on Windows is an interesting discussion topic....

I think the way this was originally done by Sarah Walker, the original B-Em author, was using a standard MinGW environment (the same that is used to build Atomulator).

I'd like the code base to retain this as an option if at all possible.

Dave
Great, thanks for this. I agree we should keep the code compatible and I will have a go at getting all three sets of instructions on the Wiki when it is all set up and working as it should. I will even install MinGW. I will probably still use Visual Studio but then I have years of experience on that. I have used many other IDEs and can drive most things at a push ;) I can even roll my own GNU Make scripts as I have done that too.

May seem like tiny steps but compiling in three different ways and hopefully soon having an official place to bring peoples efforts together should ensure the future of B-Em as a collaborative project.
Last edited by fordp on Wed Feb 22, 2017 8:14 am, edited 1 time in total.
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 » Wed Feb 22, 2017 8:07 am

There is the rather unfortunate point that, I personally, have no way of developing B-em for Windows. Any changes I make will likely break that platform.

This also means I can't make too many changes.

Post Reply