Print

[madmab]

You can get a working Bounty Bob ROM from here.

As for the others I'm not really sure.  There is a small possibility they are bad dumps.  But I would suggest going into the menu after loading the game (press down on right analog stick) and rotating the pre-config joystick type until it gets back to (5200 stick).

Chances are you carried over a configuration from another game when switching to the ones you are having problems with.

As for Boogie, Castle Crisis, Koffi - Yellow Kopter.  I would suggest downloading a version of them from the above said site to make sure you have a current version.  Boogie is more of a prototype than an actual playable game.  The other two should be playable but I'd suggest getting from the above site (atariage) since there are probably a few versions (from beta testing) floating around.

Lemme know how it goes.  Did they have preconfigs for those three?  If I had a CRC I could probably tell you more.  I tried to label any bad/unplayable dumps as such but it's possible I missed some.

[ressurectionx]

Thanks madmab.  Great advice.  I got all 4 of the completely non working roms going now and I changed to 5200 joystick for some of the others and they work fine too.  I figured I was doing something wrong and I should just ask.  I didn't see anybody else complaining about any of this.

Great work.  This emu is actually playable on more than just half the games now.  I'll have to mess around with the analog on Castle Crisis and some other tweaking, but it's really a fully put together emu now.  Thanks of course as well to XPORT, even though this emu was the red-headed stepchild of the bunch and in need of the extra config features that many of hte other emus had (Like the ability to scroll through your artwork).

Thanks again man.

BTW... if you would be interested in my 5200 pic collection let me know.  When it's done it will have every available boxart 1st, titleshot (if available) 2nd, gameplay screenshot 3rd, cartridge 4th, and any alternate boxes and carts in the 5th, 6th, 7th positions.

It's not complete yet, but It really looks great on your emu.  If you know how to make a datfile of a rom collection, I can also make a datfile for your roms so you could just change the names plug the artwork in and fire it up.

Later man,
~Rx

[ressurectionx]

Hey madmab,

Don't know if it's just me or what man, but when I change the screen size it doesn't save my settings.  I want to do the general screen size fix for all games, but it never takes.  I can do them individually, but for all games it doesn't work.

Was wondering if you could try it yourself and see if you're having the same problem.

~Rx

[madmab]

I got a question for x-port.  I've been fooling with the code that allows access to VAPI (.atx) disk images.  At this point the code has to rely on a vapi.dll file in order to run.  I have all the .c, .h, files as well as a .lib and the .dll file.  Is this possible?  I have a feeling the answer is no, but I thought I'd ask.

The author says he plans on releasing the source for the .dll so at some point I'll be able to do everything off of that.  But for now the above is all I have access too.

[XPort]

QUOTE(madmab @ Aug 17 2008, 10:58 AM)

I got a question for x-port.  I've been fooling with the code that allows access to VAPI (.atx) disk images.  At this point the code has to rely on a vapi.dll file in order to run.  I have all the .c, .h, files as well as a .lib and the .dll file.  Is this possible?  I have a feeling the answer is no, but I thought I'd ask.

The author says he plans on releasing the source for the .dll so at some point I'll be able to do everything off of that.  But for now the above is all I have access too.

If you look at the code for XBMC you'll see how they handle DLLs.  However, the DLL code must contain only things that would normally appear in the XDK.  For example, if the DLL makes calls to any GDI or MFC functions, it probably will not work.  I suspect it's probably much more work than is warranted, although I have not eyeballed the XBMC code myself.

[madmab]

QUOTE(XPort @ Aug 28 2008, 11:40 AM)

If you look at the code for XBMC you'll see how they handle DLLs.  However, the DLL code must contain only things that would normally appear in the XDK.  For example, if the DLL makes calls to any GDI or MFC functions, it probably will not work.  I suspect it's probably much more work than is warranted, although I have not eyeballed the XBMC code myself.

ok thanks.  I'm hoping the guy will release the source for the .DLL buy the time I can get around to looking at it.  As far as I know I don't think it makes any GDI or MFC calls.  So I might just wait till the .dll soure is released  anyways.

[ressurectionx]

I'm here for testing if you have anything new madmab.  I'm kinda procrastinating on starting a new project.  I'm getting burned out.  

[madmab]

QUOTE(ressurectionx @ Aug 29 2008, 12:45 AM)

I'm here for testing if you have anything new madmab.  I'm kinda procrastinating on starting a new project.  I'm getting burned out.  

I understand what you mean.  Those big projects can wear sometimes.  Believe it or not the Atarixlbox needs a bit of work done on it.  The idea was to make my todo list smaller, but for some reason it keeps getting bigger.    Since I've gotten to AdamX I've changed around alot of things in commonfuncs that would requires some reworking of the atarixlbox code.  As well as I've noticed some functionality in the x-port code that I didn't originally realized was there.  When I started working on atarixlbox I didn't know as much about this stuff (and C programming) like I do now.

Then there is some new nonlinear pokey driver I was thinking of trying out, although the odds of it being worthwhile to keep (for my purposes) are kinda small.

But anyways I've been trying to stay focuses on getting Adamx done.  Just have not been to succesfull with that.  I'm on vacation next week so not much is gonna be happening on my end.

This post has been edited by madmab: Aug 29 2008, 08:31 AM

[Atarimimo]

Hey Mab,
any chance of getting Stelladaptor support on this (and other) Emus?

[madmab]

Well I modified all the keypad code so it can work for more than one emu (presumably atarixlbox, adamx, and blissx).  Required ALOT of code changes so hopefully it will compile with no major issues.

I also fixed up the keyboard code so the emu can be paused or unpaused when the keyboard is up (just like the keypad can be).

That should be the last of any major changes to atarixlbox outside of the things I want to add.

[madmab]

Was fooling around with atarixlbox today.  Just basically going thru and making sure all my configs are set properly before creating the new config file.  Anyways I noticed certain games were really eating into the memory to the point that the menu graphics were disappearing.  

So I whipped out some xbox memory program that displays how memory is allocated and came to the conclusion that the REWIND system is a huge memory hog.  I'll have to think about it a while to determine how to best handle it (if there is a way).  What is really odd is it only happens with certain games.

[ressurectionx]

That's strange.  No loss to me if you leave it out, or put a warning that using it might hose up the system.  That's like the ultimate form of cheating and I never use it.  My bro was using it for a while on other systems and stopped because it would screw up his games sometimes.  I know he doesn't play the 7800 so this isn't specific just to 7800.

[madmab]

lol.  I live and die bye the rewind system.  Handy for testing/checking out later levels without having to worry about messing with savestates or playing a perfect game.

I created some code that will hopefully do something.  I'll test it tomorrow.

[madmab]

hehe.  I forgot that I only ran into memory issues with the rewind when running in debug mode.  But the memory usage is pretty tight.

I might eventually just create some type of auto framerate system that will increase the number of frames (upto a certain amount) between rewind "savestates" when memory gets low.  That oughta do the trick.

As for sound loudness.  I think I found a good trick.  By turning stereo off the pokey volume increases.  So I default it to off.  The user can turn it on for those few titles that use 2 pokeys so they wont lose anything.

[madmab]

It will be in the next release of atarixlbox, whenever that may be...

Well I whipped up some autoframeskip rewind code to hopefully relieve the issues that rewind causes in atarixlbox when in XL_XE mode.  Hopefully it will work as intended and may even come handy for other emu's.  We will see.