Which emulator to use: developing on Windows (VS2017)...

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Post Reply
VectorEyes
Posts: 153
Joined: Fri Apr 13, 2018 1:48 pm
Contact:

Which emulator to use: developing on Windows (VS2017)...

Post by VectorEyes » Tue May 08, 2018 4:51 pm

Hello all,

I have a half-formed plan to start doing some Beeb 6502 development, but because I'm new to the field, instead of becoming a 6502 opcode expert, I thought it might be more interesting to start by enhancing an existing emulator to support advanced debugging features. A sort of "learn by doing" approach.

What I have in mind is something where you can mark up sections of code as belonging to a particular function, and then be able to step into / over / out of the function and see the results. Would also like to be able to watch sections of memory, that sort of thing.

I'm used to Visual Studio, so I had a look at the sources for B-Em, BeebEm, and BeebEm-Windows on github. It looks like they'd all need quite a bit of work before I was able to build and make use of them on Visual Studio 2017.

The biggest issue I can see right now is that they all make use of DX9 and D3DX9, which are so old they haven't been shipped as part of a Windows SDK for many years! (Nothing wrong with DX9 of course... it was the right tech to use when the emulators were first implemented! ... but I'd rather not have to download and install old SDK versions just to be able to build the emulator).

So I'm wondering if this is something anybody has come across or might be working on? Any upgrades to later DX versions being worked on? If not, is everybody basically getting hold of old SDK versions and building the emulators using the old SDKs?

As a final question: Are there any tools that currently exist that provide advanced debugging features? Both the B-Em and and the BeebEm debuggers seemed to handle the basics (breakpoints, dissassembly from one address to another, memory dumping of specified ranges, etc) but not much more than that. It's perfectly possible I've missed some advanced features of course.

Thanks all!

User avatar
Elminster
Posts: 3089
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Which emulator to use: developing on Windows (VS2017)...

Post by Elminster » Tue May 08, 2018 8:47 pm

Have you looked at B2? That is a much more recent emulator on Windows, i dont use windows so I wouldnt like to say.

https://github.com/tom-seddon/b2/releases

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

Re: Which emulator to use: developing on Windows (VS2017)...

Post by tricky » Tue May 08, 2018 9:24 pm

I build beebem with vs2017, although I always have dxsdk2010june installed.
It is very easy to mod to add the type of features you describe.
I have also hacked importing of the labels that beebasm can export as well as auto saving break and watch points relative to those labels.
I was thinking of adding any scopes that immediately follow a label and any local labels that they contain for profiling etc.
Step over and step in/out only need to look for interrupts, jsr, RTS and rti to be very useful.
Good luck.
PS, I also use 2017 for developing my games, although I do prefer vs6 ;)

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

Re: Which emulator to use: developing on Windows (VS2017)...

Post by Coeus » Tue May 08, 2018 10:44 pm

VectorEyes wrote:So I'm wondering if this is something anybody has come across or might be working on? Any upgrades to later DX versions being worked on? If not, is everybody basically getting hold of old SDK versions and building the emulators using the old SDKs?
I can only comment for B-Em. B-Em has no direct dependency on any version of Direct X - it uses a library called Allegro though Allegro almost certainly does depend on Direct X but that means B-Em doesn't choose the version of Direct X, Allegro does. B-Em version 2.2 and the current master use Allegro 4 which is very old. There is a branch that uses Allegro 5 instead (https://github.com/stardot/b-em/tree/sf/allegro5) which should not be so problematic. When making the Windows executables for the pre-releases for that branch I simply grabbed pre-built Allegro 5 from their GitHub and compiled/linked against that (though in MingW rather than Visual Studio but it has been mentioned in here before that Allegro 5 has a Visual Studio Nuget - would that include/install the necessary dependencies for you?)

I don't know what you call advanced vs. basic debug features. The B-Em debugger has watchpoints as well as breakpoints and can also step over rather into a subroutine (n rather than s). It doesn't do "step out". The other thing it can't do at the moment is load symbol table so as to give symbolic labels rather than addresses. If you did want to add features to it one complication is that the B-Em debugger works with all the 2nd processors that B-Em supports so too so that's the main 6502, tube 6502, Z80, 65816, 80816, ARM and 32016.

VectorEyes
Posts: 153
Joined: Fri Apr 13, 2018 1:48 pm
Contact:

Re: Which emulator to use: developing on Windows (VS2017)...

Post by VectorEyes » Wed May 09, 2018 9:57 pm

Thanks for all the replies! So far I'm leaning towards B2 simply because I was able to grab the sources, build, and get up and running inside an hour, with no need to install the June 2010 DXSDK. (I'm going to see whether there's any way I can also build B-Em and BeebEm without having to install older SDK versions -- perhaps making use of the Allegro 5 branch of B-Em, for instance -- but I think that'll be a longer-term back-burner project.)

What I had in mind for 'advanced' debugging features was stuff like being able to mark up sections of code as belonging to a specific function, and other sections of memory as data blocks, and then being able to do stuff like step into and out of functions 'by name' and see that particular memory accesses are reading/writing specific (named) offsets into (named) data blocks. Essentially a wrapper around the existing debuggers that makes it a bit easier to see what's going on. It's rough ideas at the moment and I've no idea whether it's feasible (especially given that code is at liberty to trample over arbitrary memory whenever it feels like it).

The reason for this is that I wanted to debug a specific piece of Exile code a few weeks ago, but realised that I was running a version whose memory map was different from the dissassembly I was looking at. I wanted to be able to find a specific sequence of bytes, mark it as "the beginning of function foo", then mark another sequence as "the end of function foo", then step through the function, see where it jumped to, and mark those code paths as belonging to other functions, etc... essentially a way to mark up a running program with metadata, and use it to inform subsequent debugging.

Tricky, I like the sound of what you've done with marking up the BeebEm debugger with labels from BeebAsm source files. Might need to ask you more about it in a few weeks if I ever get to the point that I feel I'm ready to actually add new functionality to one of the existing emulators!

Coeus, the B-Em debugger's ability to debug all of the different processors sounds fantastic! Probably a lot more functionality than I'm ready to engage with right now, but awesome nonetheless.

Post Reply