Questions & Discussion Of Mame Compile Notes & Tutorials, You've got your Debug box. Now what? Options

[ressurectionx]

Questions & Discussion of MAME Compile Notes & Tutorials

Here is the place for any discussion for any notes or tutorials posted on the Helpful MAME Compliling Hints thread. You can find that thread here:

HELPFUL MAME COMPILING HINTS: http://forums.xbox-scene.com/index.php?showtopic=644759

(Please keep questions and comments in this thread and do not clutter up the hints thread with questions.)

This thread can also be used to discuss or ask any questions about compiling on MAME that aren't brought up in any notes or tutorials. Even questions about compiling in general are welcome. They may not directly relate to MAME, but it might help answer more questions about compiling basics that can help with MAME porting.

I'm not an expert... I'm just a complete novice, but I'm figuring new things out every time I sit down with it. There are others out there that know a lot more than I do and perhaps they will have something to add. Maybe we can help answer each other's questions.

I encourage us all with an interest in porting MAME to work together and teach each other how to do this.

This post has been edited by ressurectionx: Mar 17 2008, 12:36 AM

[ressurectionx]

Anybody know anything about editing options in MAME?

The source I have has the "Sort by Category" function removed. It's impossible to see if my catver.ini file is working properly since I can't display category on any of the games.

[ressurectionx]

The DrawROMListPage section in MAMEoXLauncher\Source Files\Screens is identical in both my debug version and in MAMEdOX_1.1_080305_src . It looks like this:

//---------------------------------------------------------------------
// DrawROMListPage
//---------------------------------------------------------------------
void COptionsScreen::DrawROMListPage( void )
{
static WCHAR *sortMode[] = { L"By name",
L"By ROM status",
L"By manufacturer",
L"By year",
L"By parent ROM",
L"By number of players",
L"By favorite status",
L"By number of times played",
L"By genre" };

static WCHAR *displayMode[] = { L"Verbose list",
L"Simple list",
L"Detailed single item" };

I need to find out where this was changed in the source. It must be somwhere in MAME or MAMEox instead of MAMEoXLauncher, which makes sense to me now because I got the MAMEoXLauncher files from MAMEdOX_1.1_080305_src . Big brainfart there. I'll probably find it first, but if anybody knows where this might have been changed, I'd appreciate the input.

[ressurectionx]

Got the debug box up and working. Haven't messed with it yet though so I don't know if it's REALLY working or not yet. I do still get some output with the symbols that I don't like, but nothing that brings up a pop up box warning me about it. Everything could be alright and it's supposed to look like this:

'default.xbe': Loaded 'c:\builds\mamedox ver3 source\mameox\release\MAMEoXLauncher.exe', Symbols loaded.
'default.xbe': Loaded 'xboxkrnl.exe', No symbols loaded.
'default.xbe': Loaded 'xbdm.dll', No symbols loaded.
'default.xbe': Loaded 'vx.dxt', No symbols loaded.
'default.xbe': Loaded 'X_RTEnvS.dll', Symbol information corrupt.
'default.xbe': Loaded 'X_cgbe.dll', Symbol information corrupt.
'default.xbe': Loaded 'X_cgrfin.dll', Symbol information corrupt.
'default.xbe': Loaded 'vt_cgrf.dxt', Symbol information corrupt.
'default.xbe': Loaded 'vtunetbs.dxt', No symbols loaded.
'default.xbe': Loaded 'XB_CM_.dxt', No symbols loaded.

If anyone can confirm this or similar output on debug start, or if it's supposed to be fixed and you might know how, that would be great.

[ressurectionx]

Everytime I alter code and build it takes forever for the "Generating Code" part to finish.

------ Build started: Project: SharedResources, Configuration: Release Xbox ------
Project up-to-date
------ Build started: Project: libsmb, Configuration: Release Xbox ------
Project up-to-date
------ Build started: Project: MAME, Configuration: Release Xbox ------
Compiling...
williams.c
wardner.c
Creating library...

Build log was saved at "file://c:\Builds\MAMEdOX ver3 Source\Mame\release_obj\BuildLog.htm"
MAME - 0 error(s), 0 warning(s)
------ Build started: Project: MAMEoXLauncher, Configuration: Release Xbox ------
Project up-to-date
------ Build started: Project: MAMEoX, Configuration: Release Xbox ------
Linking...
Generating code

In that example, I had just altered code in both williams.c and wardner.c and wanted to test them out. It just kind of hangs there for about 10 minutes while it's working. Does it take that long for anyone else using Mame? With Debugging on, shouldn't I be able to see the changes without having to rebuild and wait again? I thought that was the point.

[ressurectionx]

Hey ekszbox,

From ekszbox: The sound chip frequency for cps1.c driver is not right in arcades, it has been corrected in newer versions of mame:

Great to know. Thanks man. I'll mess around with making that change on Sunday when I get off work.

By the way you might want to tag your changes i.e. // Rx
That way you can easily track them down with a search later on.

That is an awesome suggestion. Right now, I've been using a word document to document all of my changes in detail. (As I keep working though, the detail probably won't be nearly as extensive. It's pretty much what I've been posting in the other thread). I might not abandon that documentation, but having the ability to do a Find for the changes I've made in the source is really cool.



Other than that, I've got two things on my plate now. The first is properly mapping Pyros/Wardner. I did a successful switch already to make A jump and X fire (like how Teenage Mutant Ninja Turtles I is). I'd like to make that the standard for all games as it's by far the most comfortable in my mind. Plus on games like Robocop II, A will be jump and then X can shoot left while B shoots right, so even in abnormal cases like RCII, the standard will not change.

The problem with Pyros came when I tested two players. The way that it's set up now, the player one controller controls both players so you have to keep giving the controller to the other person when you die. (I have not tried this in the last official build of Arcades, so I don't know if the official build had this problem). Trying to change this, I've only been successful in two different outcomes:

1) I get a romcheck failure right where the title screen would show up.
2) I get it mapped so the first and second player controllers control both the first and second player. Making the unsuspecting player walk right into a lava pit would be funny the first time, but I'd imagine that it would get old pretty quick.

I don't have the code for it in front of me now at work, but I can say that it's set up kind of weird compared to other games I've looked at. On The Simpsons, there is a seperate section for each of the 4 players controls. (I really like the way Simpsons is mapped and remapping all games would be a breeze if they followed that logic) On Pyros though, it looks like the mapping only gets one section and it's called for twice by whichever player is currently active. This doesn't seem to be working right though. I think when I get back to it on Sunday, I will take a look at the controller mapping for Rolling Thunder and see if it's similar since it's a 2 player alternating game as well (Maybe Rolling Thunder has the same problem in 2 player mode). Maybe all the alternating games are written that way, instead of having 4 separate instances like The Simpsons which is 2 or 4 players simultaneous.


The second and much more important thing I'm trying to get a handle on, and I assume you already know the answer to at this point, shouldn't I be able to quickly test out any small changes in code with the debug feature without having to rebuild the entire project? I kinda thought that was the point. Right now every time it seems I need to recompile the build and it takes about 13 minutes for the entire process before I can test the small changes I made.

All I've been able to do with Debug pretty much is attach the debug to the .xbe or reset the .xbe from my computer and have debug running along side it when it restarts. As soon as I start a game or try to compile I loose the debug on my PC and have to reattach when I've exited the game or the compile is done. So bottom line is, I really don't have a clue what debug does. All of my work so far has been just making changes in the driver.c files and then compiling them and sending the entire build over to the XBox.

I'd love it if I was able to test changes I've made several seconds after I've made them instead of only being able to make changes on average of 4 times per hour. I think everything is set up right now. There may just be a function that I'm not aware of that will get the job done for me.

Thanks in advance if ya know the answer to that one ekszbox.
~Rx

This post has been edited by ressurectionx: Mar 28 2008, 03:46 AM

[obcd]

Hi,

normally, if you select build instead of rebuild all, it should only recompile the sources that have changed. It will still need to link them all together, which will probably take a while as well.

The purpose of debugging is the fact that you can insert breakpoints in your sources. When the code reaches a breakpoint, it will stop it's execution. At that moment, you can examine the contents of variables in the code and alter them. You can resume the execution afterwards.

There is no way of changing some of the sources and seeing the result in the code execution immediatly. The altered sources need to be recompiled.

Mame is a pretty huge emulator (as it emulates a lot of platforms), so it's normal it takes a while to compile.

regards.

[ressurectionx]

Hello obcd,

Thanks for the reply.

The purpose of debugging is the fact that you can insert breakpoints in your sources. When the code reaches a breakpoint, it will stop it's execution. At that moment, you can examine the contents of variables in the code and alter them. You can resume the execution afterwards.

This is interesting. At this point, I don't know enough about what I'm doing to realize just how valuable this feature may or may not be to me for my purposes. I'm assuming you've coded before since you seem to know quite a bit about it. Any great benefits you can think of off the fly that might sway me to research this feature more extensively and add those skills to my aresenal?

There is no way of changing some of the sources and seeing the result in the code execution immediatly. The altered sources need to be recompiled. Mame is a pretty huge emulator (as it emulates a lot of platforms), so it's normal it takes a while to compile.

Damn.... lol. That would have been perfect. It seriously takes 12 to 15 minutes every time I make a change and want to test it out. Maybe it's time to upgrade to a new computer. Mine is relatively fast, but it's not even a dual core processor. In the mean time, I'll just have to make sure that when I'm working on a difficult little bugger like Pyros, I will make quick and easy changes to 10 or 20 other games at the same time so that 12-15 minutes downtime isn't completely wasted if the code change I put in didn't fix the problem.

Oh well. At least I know now that I can't do it the way that I thought it was supposed to work. I won't be wasting any time trying to figure out how to do that now.

Thanks again for your time obcd,
~Rx

[ressurectionx]

Thanks for the code fixes in the other thread ekszbox. They rock. I love being able to pause just by pressing the right joystick down.

I didn't understand what you sent me really when I first looked at it, but when I sat down with the emu and just did searches on the first lines of each of the code changes, I knew exactly what to do.

Thanks again,
~Rx

[ressurectionx]

As you are mentioning size, I remembered I made a change to the project when I got it, which took the size of 'MAMEoX.xbe' from 39.2MB down to 34.3MB.

Project -> C/C++ -> Optimization -> Optimization -> Minimize Size (/O1)
Project -> C/C++ -> Optimization -> Favor Size or Speed -> Favor Small Code (/Os)

I have not had time to test the speed difference myself, but apparently the speed can be as just as good by optimizing for smaller size instead of for speed; here is a quote from an expert:

"Yes. /O1 is the better all around choice, because most code isn't
time-critical, and minimizing size helps reduce cache misses and page
faults. In many cases, /O2 doesn't produce code which is significantly
faster than /O1, and ironically, smaller code can actually be faster
due to the memory effects just mentioned."

KM

Hey ekszbox,

Saw this post in the other thread and it sounds interesting (and also makes me think that there may be more benefits to come out of removing unnecessary code from the build other than faster rebuilds). Now when you say:

Project -> C/C++ -> Optimization -> Optimization -> Minimize Size (/O1)
Project -> C/C++ -> Optimization -> Favor Size or Speed -> Favor Small Code (/Os)

What is this? Is this a setting I can choose in .NET to automatically optomize some of the code? Right now, the MAME .xbe I got from the Arcades source comes out to be over 40MB, so to immediately knock it down to 35MB would be great.

Is this something I should have done before I started removing clone code or does that not matter?

[ekszbox]

What is this? Is this a setting I can choose in .NET to automatically optomize some of the code?

Yes, and you can change the settings for each project.

Is this something I should have done before I started removing clone code or does that not matter?

Doesn't matter, make sure to change these settings only for the release build though.
You should have the project in debug mode most of the time, build time should be faster this way.

[ressurectionx]

Thanks for the tips ekszbox,

I got a lot of work ahead of me before I get to that, so I'll ask you when I'm done if I can't figure that part out myeslf. It will probalby cut less code out when I've already removed so much but any little improvement is worth it. I'll have to verify that I'm in debug mode now. I believe I am, but I'm still a dumb n00b so I might not know anything yet and be making it harder on myself. Don't be afraid to pass on knowledge to me if you think of anyting else. I'll talk to you when I'm on. I think I'm going to pass out for a while.

Later,
~Rx

[ekszbox]

I've created a version of arcades which has an xbe size of 2.32MB (release version).
Basically I ripped out all drivers except for CPS1 and neogeo, all non used cpu/sound/video drivers and chd/vector files were also removed.

The reason I did this was mainly because the 30min compile time was putting me off experimenting/coding in new functions.

Note: As a side effect ROM load speed has increased as well.

Next thing I will try using precompiled headers on the xbox projects, as this will further improve build time.
If you want the code for this build, give me a shout.

KM

This post has been edited by ekszbox: Mar 31 2008, 12:11 AM

[ekszbox]

Not sure if you noticed the following warning message:

Mame\src\fileio.c(1237): warning C4013: 'vsnprintf' undefined; assuming extern returning int

This can be fixed by adding a line (the one starting with extern) into the fileio.c file, I put it here:

/***************************************************************************
PROTOTYPES
***************************************************************************/

/* External */
extern int vsnprintf( char *buf, size_t count, const char *fmt, va_list lst );
/* Internal */
static mame_file *generic_fopen(int pathtype, const char *gamename, const char *filename, const char* hash, UINT32 flags);
static const char *get_extension_for_filetype(int filetype);
static int checksum_file(int pathtype, int pathindex, const char *file, UINT8 **p, UINT64 *size, char* hash);


It's just a warning, the program works without this change, but it looks so much better when they are taken care of.


KM

[ressurectionx]

I didn't notice that message before, but that's only because there were tons of warnings with the first build. Now I don't get them because it doesn't rebuild sections that I haven't changed. If it bothers me in the future, I'll use your notes. Thanks.

And I'd love to do anything to increase build time. If the precompiled headers works for you, let me know what you did.

I feel for you if you have a 30 minute build time. That's rough. Hopefully when I make these edits it will be a lot faster for you without having to remove code for the good games. I'll give you what I've got when I take care of it.


It was mentioned that also making the VMM code leaner would be beneficial. You wouldn't know anything about that, would you?

Later