B-Em

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
tricky
Posts: 1924
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: B-Em

Postby tricky » Thu Feb 23, 2017 1:56 pm

Context:
I do not use Git, nor GitHub other than downloading whole .zip files, nor do I use a diff tool other than the one that comes with Perforce, which I only use graphically.
I do not use bash or any other shells other than the Windows/DOS command line, I do not use Python or any other scripting language, only DOS .BAT files.
I do program in many languages and assembler for some processors.

ThomasAdam wrote:...
Thanks, Tricky. Some of the changes you're suggesting look good, but rather than paste the code, can you please submit a pull-request or at least email me a unified diff? It's tricky (:-)) to handle code changes in the way you're suggesting, directly in forum posts.

Sorry, I just wanted to show it was possible, I will try and make a diff file with Perforce's diff tool.

ThomasAdam wrote:...
What I am surprised by is the direction the conversation has taken. It's nice to talk about UI toolkits, etc., but on the point about my not being able to support Windows development, no one has mentioned to me that they're concerned, or that they want to help maintain that, etc. In fact, what I'm hearing is that it's not a problem...

I would definitely want windows development supported, but I would just do it locally if it wasn't "out of the box".
I am happy to help with a Windows build, but it doesn't sound like the people who are likely to do most of the work naturally work the way I do (just VS).
Regardless, I am happy to take snapshots and do what I can when I can.
Whatever system is used to develop, I think we must consider Windows users.

Coeus wrote:...
2. Move your implementation of x_fopen into win.c so it is only compiled on Windows ...

Sorry, I did move it into win.c but didn't post it in my "dump" of changes!

Coeus wrote:...
Presumably it is not a co-incidence that the caps lock key, referred to in those keybindings, is in the same physical location as the control key is on a real BBC micro. I don't know for sure if you are changing things to the control key on the PC keyboard performs the control function or other other way round, i.e. making the caps lock key on the PC keyboard perform control. If the former I'd bet that someone set the bindings up that way deliberately so someone used to the BBC micro keyboard would be at home. BeebEm apparently has the option to switch between logical, i.e. functions match keycaps, and physical, i.e. keys perform according to the equivelent key on the BBC's keyboard, mappings.

I'm not sure, maybe they should be the other way around, I only use the beeb layout in the emulator, but probably didn't use CONTROL or CAPS LOCK, I just did it to allow you to choose without compile warnings.

Coeus wrote:...
Are they actually spelt that way? I think they should be alutInit and alutExit.

I'm not sure, I will check later, but it seems to work and I vaguely remembered not finding them last time I built from source.

ThomasAdam wrote:...
Another way of handling this is to try and do away with #ifdef all over the place, and have a set of compatibility files between Windows/Linux/BSD which are detected at ./configure time. That way, we can build up a set of function calls which work for both as required. I'll add this to the TODO file.

For the current UI requirements on Windows, personally I think any cross-platform library (other than maybe Qt) would be a significant backwards step.
I do accept that if something like a GUI debugger was added that using a single UI library would be much easier.

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

Re: B-Em

Postby fordp » Thu Feb 23, 2017 2:04 pm

tricky wrote:Context:
I am happy to help with a Windows build, but it doesn't sound like the people who are likely to do most of the work naturally work the way I do (just VS).
Regardless, I am happy to take snapshots and do what I can when I can.
Whatever system is used to develop, I think we must consider Windows users.


I have been using Visual Studio since the 90's and yes I am a fan. I am an embedded guy at heart so I have used many other IDEs and tools.

My first preference would always be to debug on my Windows 10 machine using Visual Studio.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby Coeus » Thu Feb 23, 2017 4:54 pm

ThomasAdam wrote:Thanks all for your comments and ideas around different GUI toolkits, etc.

What I am surprised by is the direction the conversation has taken. It's nice to talk about UI toolkits, etc., but on the point about my not being able to support Windows development, no one has mentioned to me that they're concerned, or that they want to help maintain that, etc. In fact, what I'm hearing is that it's not a problem.

I find that rather interesting.


I guess I have been "sitting on the fence" to a certain degree but that isn't from simple apathy.

Personally, I run Linux at home and that is what I am most comfortable developing on. Some of that is for historical reasons because I spent some time developing on Unix workstations when things like a proper 32bit processor, proper virtual memory etc. made things easier than trying to work within the restrictions that applied to Windows and PCs at the time. The other half of the picture is that I do like the free (open source) software philosophy so, with these two combined, of course I installed Linux on a PC when that became a workable system and I don't see myself changing that anytime soon.

On the other hand I don't hold to free software as "the one true religion" and I have done odd bits and pieces as a developer on Windows in the past. That doesn't mean that I can match the skills of someone with 20 years experience with Windows as their preferred platform, and anyway this is free time/for pleasure, so I don't believe I am the right person to volunteer as the maintainer for the Windows side of B-Em.

On the other hand, when I first started looking at BBC Micro emulators and found BeebEm and B-Em I liked the way B-Em has tried to limit OS dependencies to a few modules with most of the core in ANSI C. This contrasts sharply with BeebEm where someone has decided to port it to Windows in a way that sacrifices the ability to run on Unix-like systems. Yes, BeebEm has been ported back again, but the port seems unofficial and always playing catchup and when you're on the receiving end of this approach it doesn't feel good to effectively be told "You don't matter" or "It's fine for you to put up with second best".

So that's how I come not to be saying the opposite of "I volunteer", i.e. "Don't worry about Windows, just go ahead."

My approach to this to try to write as much of the new code as possible in a way that does not unecessarily depend on the OS and, where such dependencies are unavoidable, have alternative implementations for just that bit. That doesn't necessarily mean I'd want to write the Windows implementation but the less work is involved in that, because most of the code is universal, the more likely it is that someone else may be able to find the time to do it.

So, for me, that was the driver behind the toolkit discussion - is there way we can get as much of the work put in to implement a feature on Unix-like systems to be equally applicable to Windows?. So, if not a toolkit, what about a text description and a means of building widgets from that? In fact, the Windows resource file, the old way of doing things before C++ and MFC, seems to be just that, though whether that is suitable I don't know.

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

Re: B-Em

Postby fordp » Thu Feb 23, 2017 6:37 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.

Snip ....

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


I have just posted the above on the Wiki. We can then improve it over time.

I hope that is OK Tricky and thanks for your contribution!
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby tricky » Thu Feb 23, 2017 6:47 pm

Yes, that's fine by me.

I do feel sometimes that I just dump things here, but there are so many things that I want to do that doing the minimum to hopefully make something useful or interesting is all I allow myself to do.

I'm happy to answer questions about anything, but I'm not good at writing tutorials or documentation :oops:

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

Re: B-Em

Postby ThomasAdam » Thu Feb 23, 2017 8:38 pm

tricky wrote:Context:
I do not use Git, nor GitHub other than downloading whole .zip files, nor do I use a diff tool other than the one that comes with Perforce, which I only use graphically.


Then, I'm sorry to say, I suspect you'll struggle to contribute to this project. I just (personally) don't have the time to pick through whole files posted here, or sporadic code changes which aren't diffs. I'm fine with email and being given diffs to apply, and even more pleased with pull-requests, but I'm unclear why you couldn't use Github. If it's a question of learning, I'd be happy to help you with that.

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

Re: B-Em

Postby fordp » Thu Feb 23, 2017 8:42 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.


Well I tried and failed so far with:

Code: Select all

1>------ Build started: Project: b-em, Configuration: Debug Win32 ------
1>csw.obj : error LNK2019: unresolved external symbol _uncompress referenced in function _csw_load
1>soundopenal.obj : error LNK2019: unresolved external symbol _alutInit referenced in function _al_init_main
1>soundopenal.obj : error LNK2019: unresolved external symbol _alutExit referenced in function _al_close
1>C:\Users\Simon\Documents\b-em\src\Debug\b-em.exe : fatal error LNK1120: 3 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


Close but no cigar!
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby fordp » Thu Feb 23, 2017 8:58 pm

ThomasAdam wrote:
tricky wrote:Context:
I do not use Git, nor GitHub other than downloading whole .zip files, nor do I use a diff tool other than the one that comes with Perforce, which I only use graphically.


Then, I'm sorry to say, I suspect you'll struggle to contribute to this project.
Snip ..


Well I agree and disagree Thomas.

I would say it would be very awkward to contribute code for the reasons you say. Yes I agree.

There are however other ways to contribute like testing, writing the wiki and so on that would not need git knowledge. I am still a git novice so excuse me but I am learning fast and am sold on the benefits. When you see what others like Dominic and Hoglet can do with it I am not sure how you could fail to be impressed.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby fordp » Thu Feb 23, 2017 9:42 pm

Well I give up for now. I thought the working 32016 version was in the stardot version but it does not seem to be and I cannot get the current snapshot working. I am on holiday next week but I will be back just like Arnie ;)
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby Coeus » Thu Feb 23, 2017 9:58 pm

fordp wrote:Well I give up for now. I thought the working 32016 version was in the stardot version but it does not seem to be and I cannot get the current snapshot working. I am on holiday next week but I will be back just like Arnie ;)


There was some discssion between hoglet and ThomasAdam earlier about including some code from hoglet. One possible reason for a delay is that the stardot github repository is not a fork of the fresh0r one so some git trickery is needed to be able to submit a pull request.

I've followed the incantation concerned and have duly submitted a pull request. That includes some code I had integrated from a repository of hoglet's some time back and, as far as I know, that does include a working 32016 implementation, though Simon Ellwood is looking at some compiler warnings in one module. That's not to say that hoglet doesn't have a yet better version.

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

Re: B-Em

Postby fordp » Thu Feb 23, 2017 10:00 pm

Just so you know Simon Ellwood is my real name and fordp is my alias.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby hoglet » Thu Feb 23, 2017 10:27 pm

Coeus wrote:I've followed the incantation concerned and have duly submitted a pull request. That includes some code I had integrated from a repository of hoglet's some time back and, as far as I know, that does include a working 32016 implementation, though Simon Ellwood is looking at some compiler warnings in one module. That's not to say that hoglet doesn't have a yet better version.

Steve, I was waiting for your pull request to get integrated before submitting mine (otherwise they would overlap, as you have included part of what I was preparing to submit). But there will be several further 32016 related commits:
- https://github.com/hoglet67/b-em/commits/test-32016

One of these: 32016 Co Pro: fixes for 64 bit and fix all warnings: 73e13d7b does address all the warnings and makes the code 64-bit safe.

Ford, I just noticed earlier you volunteering to fix some warnings in NSDis. You might want to wait until all this merging of existing work is finished. And actually, in the latest code that file is no longer used by B-Em (although it could easily be re-instated in the future).

I think I will re-name my existing repo, re-fork from stardot/b-em and prepare the pull request there. But I'll only do this once Steve's pull request has been merged, or there is too much in-flight code.

Dave

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

Re: B-Em

Postby fordp » Thu Feb 23, 2017 10:35 pm

Yes , I read the Ndis issue at work. I remembered later it was fixed in your codebase.

Dave, which audio library are you using on Windows as the one tricky links to does not seem to match the code?
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby tricky » Thu Feb 23, 2017 10:38 pm

fordp wrote:...
Well I tried and failed so far with:...

I only posted up what I had found to give others a head start.
I think I did mention it, but I deleted the two alut function calls and you seem to have a missing function in gzip, no idea why.

I know I should learn git and I did say I would provide diffs if I could get perforce to cooperate ;)

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

Re: B-Em

Postby hoglet » Thu Feb 23, 2017 10:43 pm

fordp wrote:Dave, which audio library are you using on Windows as the one tricky links to does not seem to match the code?

These are the DLL's that I'm currently running against:

Code: Select all

$ ls -l *.dll
-rwxr-xr-x 1 David Banks 197121 3959941 Mar 14  2016 alleg44.dll*
-rwxr-xr-x 1 David Banks 197121   32768 Jan 11  2015 alut.dll*
-rwxr-xr-x 1 David Banks 197121  119296 Mar 14  2016 libgcc_s_dw2-1.dll*
-rwxr-xr-x 1 David Banks 197121 1024014 Mar 14  2016 libstdc++-6.dll*
-rwxr-xr-x 1 David Banks 197121  126995 Mar 14  2016 OpenAL32.dll*
-rwxr-xr-x 1 David Banks 197121   72192 Feb  9  2014 zlib1.dll*

I have no idea what versions these actually are, or where they came from!

The LIBS in the Makefile are:

Code: Select all

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

Dave
Last edited by hoglet on Thu Feb 23, 2017 10:47 pm, edited 1 time in total.

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

Re: B-Em

Postby ThomasAdam » Thu Feb 23, 2017 10:44 pm

hoglet wrote:Steve, I was waiting for your pull request to get integrated before submitting mine (otherwise they would overlap, as you have included part of what I was preparing to submit). But there will be several further 32016 related commits:
- https://github.com/hoglet67/b-em/commits/test-32016

One of these: 32016 Co Pro: fixes for 64 bit and fix all warnings: 73e13d7b does address all the warnings and makes the code 64-bit safe.


Steve -- given my comment on your pull-request, is it feasible at this point to elide David's changes? That would then mean he could submit his pull-request without relying on your code.

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

Re: B-Em

Postby fordp » Thu Feb 23, 2017 11:26 pm

hoglet wrote:
fordp wrote:Dave, which audio library are you using on Windows as the one tricky links to does not seem to match the code?

These are the DLL's that I'm currently running against:

Code: Select all

$ ls -l *.dll
-rwxr-xr-x 1 David Banks 197121 3959941 Mar 14  2016 alleg44.dll*
-rwxr-xr-x 1 David Banks 197121   32768 Jan 11  2015 alut.dll*
-rwxr-xr-x 1 David Banks 197121  119296 Mar 14  2016 libgcc_s_dw2-1.dll*
-rwxr-xr-x 1 David Banks 197121 1024014 Mar 14  2016 libstdc++-6.dll*
-rwxr-xr-x 1 David Banks 197121  126995 Mar 14  2016 OpenAL32.dll*
-rwxr-xr-x 1 David Banks 197121   72192 Feb  9  2014 zlib1.dll*

I have no idea what versions these actually are, or where they came from!

The LIBS in the Makefile are:

Code: Select all

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

Dave


Looks like your version is doing dynamic linking while there is some static linking on VS2013. If it is still an issue after I get back from my holidays then I may ask you to do more digging on the libraries.

Thanks for looking so far.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby Rich Talbot-Watkins » Fri Feb 24, 2017 3:18 pm

ThomasAdam wrote:Thanks all for your comments and ideas around different GUI toolkits, etc.

What I am surprised by is the direction the conversation has taken. It's nice to talk about UI toolkits, etc., but on the point about my not being able to support Windows development, no one has mentioned to me that they're concerned, or that they want to help maintain that, etc. In fact, what I'm hearing is that it's not a problem.

As an exclusively Windows developer, I don't think it's particularly significant that nobody has commented much on maintaining the Windows build. The ideal thing is that, with appropriate cross-platform libraries in place, it should always be fairly easy to generate a working Windows build. Using a more Unixy type build environment such as MinGW+MSYS, it should be possible to build with GNU Make - adding a Visual Studio solution at a later stage is relatively trivial. The problem comes when the project necessarily contains platform-specific code which needs to be maintained as the project evolves; this is currently the case with B-Em, and hence the comments about finding cross-platform libraries which can handle GUI etc.

Incidentally, today I came across IUP, which may just be the lightweight GUI library I've been looking for, and which is apparently still being developed. The only problem is that Mac doesn't get proper native support. But I'm gonna check that out soon. Has OpenGL canvas support too! (which not all of them do).

User avatar
ctr
Posts: 94
Joined: Wed Jul 16, 2014 2:53 pm

Re: B-Em

Postby ctr » Fri Feb 24, 2017 8:02 pm

Apart from file selection, none of the UI needs to be native. Instead of targeting Windows or Linux, why not make it BBC Micro style?

One could go the whole hog and give the emulator the ability to run more than one beeb at a time. The configuration UI could then be an actual beeb program communicating with the emulator through some custom interface.

Or a simpler idea would be to implement an interface that merely looks like it is running on the beeb.

Coeus wrote:So, for me, that was the driver behind the toolkit discussion - is there way we can get as much of the work put in to implement a feature on Unix-like systems to be equally applicable to Windows?. So, if not a toolkit, what about a text description and a means of building widgets from that? In fact, the Windows resource file, the old way of doing things before C++ and MFC, seems to be just that, though whether that is suitable I don't know.


To mock this up I wrote a beeb program to run Windows menus. The attached ssd contains MENU, the program, and MENURES, which is the compiled menu resource pried out of beebem.exe. (There is also MENUBEM, the menu from B-Em, which can be renamed to MENURES to try out.) It's a bit slow to load because it reads the resource one byte at a time using OSBGET.

Navigate with the arrow keys or hotkeys. Select using Enter. E.g. type "wbm" to select a Master 128.

I'm still not sure if this isn't a completely daft idea.
Attachments
beebmenu.ssd.zip
(4.47 KiB) Downloaded 16 times

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

Re: B-Em

Postby Coeus » Sat Feb 25, 2017 12:45 am

ctr wrote:One could go the whole hog and give the emulator the ability to run more than one beeb at a time. The configuration UI could then be an actual beeb program communicating with the emulator through some custom interface.


It is an interesting idea.

We had some discussion last year about communication between the emulated BBC (guest) and the host when I discovered initially sprow, and later J.G. Harston, had been working on something called VDFS, originally for use in BBC emulator that ran on RiscOS whose name I have forgotten, which exposed the host filesystem to the BBC as another selectable filing system, i.e. an alternative to DFS, ADFS, ROM, TAPE etc. Some people thought that was an odd thing to do and I can certainly see a security issue such that in my opinion the host does have to keep the guest in a sandbox, so in the case of exposing the filesystem it would have to be a designated part of the filesystem, not the whole of it.

With that provisio I went ahead anyway with an implementation for B-Em and, when I last checked J.G.Harston has started a similar effort for BeebEm. My VDFS implementation is subject to a git pull request so hopefully will be part of the mainstream soon.

In the original VDFS implementation the guest/host communication was done by adding behaviour to CPU instructions that are undocumented on a real 6502. Some of them do strange things on a real 6502, though, and some people have written programs to make use of that so I opted instead for some I/O ports, i.e. when the emulated BBC CPU writes to one of a pair of ports, just like a real hardware interface, the host then does something. In this case it is access some file or files on the host or, reboot, or quit etc.

So, this mechanism could be extended to enable some of the things that are currently on menus to be controlled from the BBC. That doesn't necessarily mean you'd want to, though. One of the attractions of an emulator is the nature of the sandbox. I can, for example, set write-protect on a disk from the menu in the emulator and there is nothing code running on the emulated BBC can do to defeat that. If all these options were opened up to be controlled from the BBC that goes away. On the other hand maybe it is worth, for example, making it possible to control the speed from the BBC itself - one could have it run fast until such time that you load a game and then it slows down to the right speed and this could all be integrated into a menu on a disc.

As far as a general alternative to a menu of the host goes there is also the issue that the BBC may be busy doing something at the time you want to change some feature of the emulation. Your multiple machines idea would get round this, though they'd have to be multiple machines running inside the same emulator and in both BeebEm and B-Em that would mean some work to make what are currently global variables into something else. As both of these originally started out on Linux this may not have been done because it was always taken for granted you can run more than one copy of the same program at the same time - see this screenshot:

Screenshot from 2017-02-25 00-39-03.png

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

Re: B-Em

Postby SarahWalker » Sat Feb 25, 2017 8:05 am

ctr wrote:Apart from file selection, none of the UI needs to be native. Instead of targeting Windows or Linux, why not make it BBC Micro style?

Probably worth noting that B-em had a non-native UI prior to v0.8, largely due to DOS still being the primary target. The general feedback I got was that people hated it...

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

Re: B-Em

Postby ThomasAdam » Sat Feb 25, 2017 9:37 am

So, Steve Fosdick (Coeus) and I have been working hard, and his VADFS (and associated) changes have now been merged to the master branch on stardot/b-em. I know that Hoglet has been wanting to finish off your 32016 changes. There's some of your work already on master which now includes 32016 emulation. I presume that's incomplete, David? Either way, the floor's yours. If you want a hand with anything, do please let me know.

Kindly,
Thomas

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

Re: B-Em

Postby tricky » Sat Feb 25, 2017 9:44 am

ThomasAdam wrote:...Incidentally, today I came across IUP, which may just be the lightweight GUI library I've been looking for, and which is apparently still being developed...

It looks promising, but I can't find a GUI builder for it; have you?
Last edited by tricky on Sat Feb 25, 2017 9:52 am, edited 1 time in total.

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

Re: B-Em

Postby hoglet » Sat Feb 25, 2017 9:50 am

ThomasAdam wrote:So, Steve Fosdick (Coeus) and I have been working hard, and his VADFS (and associated) changes have now been merged to the master branch on stardot/b-em. I know that Hoglet has been wanting to finish off your 32016 changes. There's some of your work already on master which now includes 32016 emulation. I presume that's incomplete, David? Either way, the floor's yours. If you want a hand with anything, do please let me know.

Great, I'll have a go now.

Can you have a quick read of the comment I added to:
https://github.com/stardot/b-em/pull/3

Dave

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

Re: B-Em

Postby hoglet » Sat Feb 25, 2017 11:28 am

Thomas,

Here's a pull request for the updated version of the 32016 Co Pro emulation:
https://github.com/stardot/b-em/pull/4

Dave

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

Re: B-Em

Postby hoglet » Sat Feb 25, 2017 12:14 pm

Steve,

I'm trying to get the Windows (MinGW) build running again and have some issues with vdfs.c:

Could you take a quick look and give my your thoughts:
https://github.com/stardot/b-em/issues/5

Dave

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

Re: B-Em

Postby hoglet » Sat Feb 25, 2017 12:47 pm

Another update. With the changes here, B-Em is compiling and running on Windows again:
https://github.com/stardot/b-em/issues/5

Dave

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

Re: B-Em

Postby Coeus » Sat Feb 25, 2017 3:54 pm

hoglet wrote:Thomas, any thoughts about this build issue?
[code]
checking for Allegro - version >= 4.0.0... no
*** Could not run Allegro test program, checking why...


Dave, since you wrote this I have found that the GCC setting -Werror breaks the configure script used by autoconf.

Essentially the tests in autoconf for various features are not good enough code to avoid compiler warnings and the success or failure of the test is determined by whether the compiler exists with an error code. -Werror caused it to exit with an error even if there are only warnings and autoconf takes that to mean the feature isn't present.

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

Re: B-Em

Postby Coeus » Sat Feb 25, 2017 4:49 pm

hoglet wrote:Another update. With the changes here, B-Em is compiling and running on Windows again:
https://github.com/stardot/b-em/issues/5

Dave


Dave,

I did try to see if I could build it on Windows myself in MingW but it is not finding the direct X header file and the previous MS download site seems to have gone away. Do you have either an ZIPable build environment or a crib sheet that would get me started? I was thinking to start with MingW first. Windows 7 or 10 are fine for the target, I don't have access to 8 or 8.1.

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

Re: B-Em

Postby ThomasAdam » Sat Feb 25, 2017 6:00 pm

Coeus wrote:
hoglet wrote:Thomas, any thoughts about this build issue?
[code]
checking for Allegro - version >= 4.0.0... no
*** Could not run Allegro test program, checking why...


Dave, since you wrote this I have found that the GCC setting -Werror breaks the configure script used by autoconf.

Essentially the tests in autoconf for various features are not good enough code to avoid compiler warnings and the success or failure of the test is determined by whether the compiler exists with an error code. -Werror caused it to exit with an error even if there are only warnings and autoconf takes that to mean the feature isn't present.


If the test program for allegro is still failing, I want to know why, with -Werror enabled. It's not good enough to just blindly disable it at this point -- so can you add it back in, hoglet, run ./autogen.sh and send the config.log my way if it's still failing for you, please?

I'll get to looking at the rest of your code in just a moment.

Kindly,
Thomas


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 1 guest