Post by: XPort on September 03, 2006, 01:06:00 PM
http://xport.xbox-scene.com/
http://www.mess.org/
What's New:
- Selectable palette
- MESS-NTSC
- MESS-PAL
- New Stella NTSC
- Old Stella NTSC
- Z26 NTSC
- New UI feature: Garbage Directory
Press "BACK" on the game selection menu to move games you don't
like into a garbage directory. The default for this is
E:\SAVES\<EMULATORNAME>\GARBAGE. You can change this location
by going to Configuration -> Change Default Directories
Stella, Gnuboy, SMSPlus, FCEUltra, HUGO, NeoPop, DGen, Bochs, HUGO-CD,
FMSXBox, Bliss, WinSTon, Gens, Z26X, StepmaniaX, PCSXBox, XBoyAdvance,
DOSXBox, AtariXLBox, MirrorMagicX, KoboX, MaelstromX, MarblesX, Vice64X,
Vice20X, VicePETX, KegsX, XPired, AdamX, WonderSwanX, BeatsOfRageX,
PowermangaX, LynxBox, BlueMSXBox, GladiatorX, AmphetamineX, StarfighterX,
PachiX, BlobWarsX, OdysseyX, ArnoldX, X68000X, WinUAEX, MekaX,
MednafenX-NES, MednafenX-PCE, MednafenX-Lynx, AbuseX, PokemonMiniX,
Classic99X, SoftVMUX, VirtualBoyX, SuperVisionX, Chip8X, Atari7800X
what's next?
Enjoy!
Post by: madmab on September 03, 2006, 02:01:00 PM
As for the sound thing I think in V1 it was actually sticking after the save, but in V2 it would only play while saving so that ain't so bad.
The garbage directory will come in real handy when sifting thru multiple versions of stuff!
Thanks for the answer on the volume thing. I think I'll just run the menu mp3 file or whatever it is thru some tool to lower it's volume.
This post has been edited by madmab: Sep 3 2006, 09:01 PM
Post by: Toon_Army on September 03, 2006, 02:59:00 PM
QUOTE(XPort @ Sep 3 2006, 08:13 PM) 
Atari7800X - Atari 7800 Emulator for XBox v3
- New UI feature: Garbage Directory
Press "BACK" on the game selection menu to move games you don't
like into a garbage directory. The default for this is
E:\SAVES\<EMULATORNAME>\GARBAGE. You can change this location
by going to Configuration -> Change Default Directories
Enjoy!
thank you, wanted this for a while.....
Post by: yankefish on September 03, 2006, 04:22:00 PM
(IMG:style_emoticons/default/rolleyes.gif)
Post by: sicknasty413 on September 03, 2006, 11:02:00 PM
man o man.. atari pwnz0rs
Post by: sxxxe83 on September 04, 2006, 07:03:00 AM
Thanks
Post by: madmab on May 08, 2008, 12:37:00 PM
QUOTE
ROMS loaded via Samba/Relax now work properly.
Fixed fast forward so you can actually see what is happening. All it really does is set frameskip to 9. Anything higher causes display issues. I'm hoping to find a better way than frameskipping for fastforward. Seems unlikely though. I think the thing is pretty close to maxxed out.
Fixed rewind so it doesn't crash the emu on gameload. Seems mess doesn't like to do savestates while it is still "initializing". (IMG:style_emoticons/default/laugh.gif)
Fixed fast forward so you can actually see what is happening. All it really does is set frameskip to 9. Anything higher causes display issues. I'm hoping to find a better way than frameskipping for fastforward. Seems unlikely though. I think the thing is pretty close to maxxed out.
Fixed rewind so it doesn't crash the emu on gameload. Seems mess doesn't like to do savestates while it is still "initializing". (IMG:style_emoticons/default/laugh.gif)
There is also some weird issue with the savestates. Have not completely nailed it down, but mess seems to "schedule" state saves so they do not actually "occur" until the user exits back into the game. (IMG:style_emoticons/default/rolleyes.gif)
That's it for now. I really don't expect to do a whole lot for a7800x like I did with atarixlbox. Maybe yet another palette change and a database (from the prosystem emu) for .bin files. I'm also hoping to figure out how to map the "pause" button on the 7800. But alot of stuff from atarixlbox should carry over. (IMG:style_emoticons/default/happy.gif)
This post has been edited by madmab: May 8 2008, 07:40 PM
Post by: run088 on May 08, 2008, 12:56:00 PM
QUOTE(madmab @ May 8 2008, 03:13 PM)
Well I'm working on a7800x now. Atarixlbox is pretty much done now and should be on xbins soon and I'll create a new thread for that one. Here is a small list of what I've done so far.
There is also some weird issue with the savestates. Have not completely nailed it down, but mess seems to "schedule" state saves so they do not actually "occur" until the user exits back into the game.
That's it for now. I really don't expect to do a whole lot for a7800x like I did with atarixlbox. Maybe yet another palette change and a database (from the prosystem emu) for .bin files. I'm also hoping to figure out how to map the "pause" button on the 7800. But alot of stuff from atarixlbox should carry over.
Good to hear! Have you given any thought to adding streaming screenshots to the new releases?If not thats cool.
Post by: madmab on May 08, 2008, 01:27:00 PM
It's just a matter of taking the time to set-up some test samples on my networked pc. (IMG:style_emoticons/default/smile.gif)
Post by: XPort on May 09, 2008, 06:36:00 AM
QUOTE(madmab @ May 8 2008, 03:13 PM)
Well I'm working on a7800x now. Atarixlbox is pretty much done now and should be on xbins soon and I'll create a new thread for that one. Here is a small list of what I've done so far.
There is also some weird issue with the savestates. Have not completely nailed it down, but mess seems to "schedule" state saves so they do not actually "occur" until the user exits back into the game.
That's it for now. I really don't expect to do a whole lot for a7800x like I did with atarixlbox. Maybe yet another palette change and a database (from the prosystem emu) for .bin files. I'm also hoping to figure out how to map the "pause" button on the 7800. But alot of stuff from atarixlbox should carry over.
There are a few emulators that behave like this (schedule save states). The reason it's done is because typically save states are triggered by user interaction which is usually handled by an interrupt in the console the emulator is emulating. These "read joystick" type interrupts can happen in lots of different places during code execution. Scheduling the save/load states ensures that they only happen at one place in the code to ensure that things work correctly every time. In theory, if you save every single variable and then load it back it shouldn't be a problem, but practicality and implementation-wise it's not always easy to do this.
Basically, I don't recommend trying to change this behavior. What problem is it causing?
Post by: run088 on May 09, 2008, 07:07:00 AM
Post by: madmab on May 09, 2008, 07:57:00 AM
QUOTE(XPort @ May 9 2008, 09:12 AM) 
There are a few emulators that behave like this (schedule save states). The reason it's done is because typically save states are triggered by user interaction which is usually handled by an interrupt in the console the emulator is emulating. These "read joystick" type interrupts can happen in lots of different places during code execution. Scheduling the save/load states ensures that they only happen at one place in the code to ensure that things work correctly every time. In theory, if you save every single variable and then load it back it shouldn't be a problem, but practicality and implementation-wise it's not always easy to do this.
Basically, I don't recommend trying to change this behavior. What problem is it causing?
To be honest I have not completely figured it out but what was originally happening was I would save a state in the menu, and then go to the "load state" menu to confirm the file was there. The screenshot would be there but no savestate. Obviously, as I found out later, because mess was "scheduling" the saves. So for example if a user saves a state and then immediately exits the game they can kiss their save state goodbye. (IMG:style_emoticons/default/laugh.gif)
So once I discovered this I pretty much came to the conclusion that you mentioned, that chances are MESS needed the save/load to occur at a certain point in the emulation. So what I did (in the interm) is just modify it to kick the user back into the game after a save or load (only if a #MESS emu is running).
But then I noticed while playing the "Pacman Collection" that after playing for a certain period of time the save states did not appear to be taking. The "Pacman Collection" I think is a 32k bankswitched cart so I'm wondering if that has something to do with it cause after playing a while presumably some bankswitching would have occured.
So that is pretty much the issue that is occuring now. After playing that particular game for a period of time the save states do not seem to kick in. I was gonna just run in debug mode sometime and play it for a while and then trace thru the "handle_save" routine and see if it kicks out an error. There are a few sections in that routine that call ui_popup to report errors.
I did have another question, though about the command line section of the properties box. Is there any way for me to change any of those parms if I wish? There does not seem to be any way to edit it. Oh and I'm just curious, but is it your experience that MESS is running pretty close to the limit? It sure seems to get flakey while running in debug mode with rewind enabled.
Run088... the reason I'm gonna map the "pause" button is because some 7800 titles (like the homebrew Froggie) look for it to be pressed to perform certain functions.
This post has been edited by madmab: May 9 2008, 03:09 PM
Post by: madmab on May 09, 2008, 09:22:00 AM
Now that I think about it I might do reset as well. I'll have to see how many games do not let you exit back out to the menu.
Post by: madmab on May 09, 2008, 07:06:00 PM
So I just put in a little check to make sure that don't happen. 
Don't forget about my other two questions in the post two posts above this one.
Post by: XPort on May 10, 2008, 07:46:00 AM
Yeah there's a lot of overhead in MESS. Debug has no optimizations and rewind is very taxing because it's always saving. A save state is essentially performed each frame. I did change this behavior for certain ports (I forget which) so that it would only save a state every 4th or 5th frame or something. It resulted in stuttering while rewinding, but the game ran more smoothly while rewind was on.
Post by: XPort on May 10, 2008, 09:23:00 PM
Post by: XPort on May 11, 2008, 08:40:00 AM
I'm glad you mentioned the commonfuncs.cpp though - I've been meaning to ask if you have been keeping it free of emulator-specific code. Ideally, anything that is applicable to every other emulator will be in there and anything that is not applicable to every other emulator will not. You're of course free to do as you wish, but it would make it slightly more maintainable for you and anyone else who picks up after you're done with your changes.
Post by: madmab on May 12, 2008, 11:46:00 PM
I'll have to mess (pun intended) around a little more but seems the sound issues in "release mode" only crop up when I use a combination of rewind after using fast forward so I'm not sure if anything can be done. Going into the menu and then back into the game clears it up.
Post by: Antiriad on May 13, 2008, 01:00:00 PM
Post by: madmab on May 19, 2008, 07:51:00 AM
I'll have to keep looking...
Post by: XPort on May 20, 2008, 08:11:00 AM
Post by: sotu on May 21, 2008, 03:18:00 AM
So I'm asking is there a way to get the joystick function working on 7800x like it does on 5200 atarixlbox?
thanks
Post by: XPort on May 21, 2008, 06:20:00 AM
QUOTE(madmab @ May 20 2008, 04:26 PM)
I found it. I just misunderstood your previous comment about the "hook" into commonfuncs.cpp. The code is located in xbox_savestatemem() which is in the gba.cpp file.
Sometimes I just get into duh, huh mode.On afterthought I suppose I coulda just made up something myself. I just usually try to make everything as similar as possible to other emu's for consistency. Thanks.
I take it that this...
CODE
xbox_mfwrite( "aaadefggggglmnopqrstuuuuyz222221-597278659", 1, 42, sm );
Serves as nothing but a placeholder (aka dummy/blank/empty state) right? It looks like the xbox_loadstatemem() skips over anything less than 50 bytes in size.
Ya - something needed to be saved so that the load state would not crash. The rewind stuff in general is somewhat kludgey - I think the lz compression algorithm is screwed up in some manner because it seems to leak under various circumstances. I think the whole "compress-into-memory" section needs an overhaul. It's why rewind fails to work on the ones noted in the docs that save states are supported but rewind is not.
Post by: madmab on May 21, 2008, 07:58:00 AM
On a side note I'm gonna add Joy 2 up/down/left/right options to the mapping screen so those who wish to map robotron for dual stick can do so.
Post by: sotu on May 21, 2008, 08:49:00 PM
Post by: madmab on May 31, 2008, 02:05:00 AM
What was throwing me off was the lack of correlation between the cart_type as defined in prosystem.dat and the cart_type defined in the header of A7800 ROMS. So once I got that straightened out things began to make more sense.
Prosystem uses the following cart types...
CODE
prosystem type 0 -> 0 Normal Cart
prosystem type 1 -> 2 Supercart
prosystem type 2 -> 10 Supercart with additional ROM at $4000 (Large)
prosystem type 3 -> 6 Supercart with additional RAM at $4000
prosystem type 4 -> 02 Supercart no additional RAM/ROM
prosystem type 5 -> 512 F18 Hornet
prosystem type 6 -> 256 Activision Cart
add 1 if pokey=true
prosystem type 1 -> 2 Supercart
prosystem type 2 -> 10 Supercart with additional ROM at $4000 (Large)
prosystem type 3 -> 6 Supercart with additional RAM at $4000
prosystem type 4 -> 02 Supercart no additional RAM/ROM
prosystem type 5 -> 512 F18 Hornet
prosystem type 6 -> 256 Activision Cart
add 1 if pokey=true
The number on the left is the prosystem internally defined number. The number after the -> is the actual header value of the ROM. The text on the right is the actual description. That being said I should be able to narrow the user configuration for headerless ROMS down to two options..
Cart Type (as defined by prosystem)
Pokey Supported (yes/no).
That being said. I noticed all homebrews (that I've tried so far) are cart type 0. With pokey either being true or false.
The two prototypes (Sirius and Plutos) that came out recently are type 2 (I believe, going from memory here).
So in 99% of the cases the user can just pick cart_type 0 with pokey on/off and let her fly. For future newly released prototypes it would be just a matter of trying each cart_type until it works.
Or just manually adding it to the prosystem.dat file.Other things that threw me off.
1. My Commando ROM has the wrong header, so no pokey sound.
2. My Sentinel had a bad header and didn't work as a result. (wrong cart_type and PAL)
3. My Summer Games has a wrong header thus the graphics were scrambled.
4. My Winter Games had the same issues as Summer Games.
5. The two Frogger ROMS with headers have invalid header. Hence impromper music (no pokey).
None the less I have it all figured out now.
Oh and the emulator now displays a message when you change the difficulty level on switch A or B.
I'm debating on whether to display a message when the "Pause" button has been pressed and still "active".
Post by: madmab on June 03, 2008, 10:09:00 AM
Post by: XTecuterX73 on June 03, 2008, 10:23:00 AM
QUOTE(madmab @ Jun 3 2008, 12:45 PM)
lookin good madmab!
You have really put some work into this. I can't wait to try it out! Damn you just keep on going and going!! 
XT-
Post by: madmab on June 09, 2008, 05:28:00 PM
CODE
typedef struct _cheatdbentry
{
char gamename[100];
char CRC32[9];
unsigned int numcodes;
char *filepos;
} CHEATDBENTRY;
CHEATDBENTRY m_cheatDB[5000];
{
char gamename[100];
char CRC32[9];
unsigned int numcodes;
char *filepos;
} CHEATDBENTRY;
CHEATDBENTRY m_cheatDB[5000];
Lowering the size of m_cheatDB seemed to do the trick but then it started creating conflicts with the rewind code so I had to lower it even more. Oddly enough putting the same entry in Z26 created the same issues except it seemed even pickier than a7800x about the final size allowed.
Now granted 5000 probably is way more than I need but that number did not seem to pose any issue with Atarixlbox, or Pcsxbox (which I would think would take up far more memory than either z26 or a7800x). But it still strikes me as odd, especially with Z26 which I would think should be smaller. But then it does quadruple buffer the screen (or is that triple?).
Anyways, regardless when I do get a7800x running it seems to report having plenty of memory available. Is the xbox_get_freemem function lying to me or something? I know the xbox does not have a whole lot of memory, but freemem seems to report plenty ( 37064704 bytes).
Any info would be greatly appreciated. I'm kinda new to dealing with memory issues.
Thanks!!
Post by: madmab on June 09, 2008, 09:23:00 PM
Pretty frustrating since I don't have a clue where to start.
Post by: XPort on June 10, 2008, 06:31:00 AM
Post by: madmab on June 10, 2008, 07:40:00 AM
But it still locks when in release mode when exiting out of the "search gameshark" screen, but works perfectly fine in debug mode. Which kinda makes it hard for me to figure out why it is doing that...
Thanks..
Post by: madmab on June 10, 2008, 09:07:00 AM
Post by: XPort on June 11, 2008, 06:31:00 AM
QUOTE(madmab @ Jun 10 2008, 11:43 AM)
Looks like it is locking up somewhere after I exit the gameshark menu to the cheat menu and the loop goes back into the "rendertextmenuwrapper" at which point it freezes.
Have you tried bumping up the stack size significantly to make sure that it's not the issue?
If that still doesn't work, then it sounds like memory is getting corrupted somewhere - e.g. memset( buf+5000, 0, 1000) with buf being "char buf[4500]". It's very possible that the precise place that it's failing is not related to the failure at all - it's probably the result of an errant write to memory. Debug mode has memory laid out differently and initializes all you variables to zero for you - which is not done in release mode - so check that all your vars are properly initialized as well. You should eyeball your new code to look for where data could be written to the wrong places in memory.
Post by: madmab on June 11, 2008, 12:40:00 PM
I usually catch those because something is usually missing, but in this case the way I was using that variable the lack of a terminating character didn't affect it.
Post by: XTecuterX73 on June 12, 2008, 12:03:00 PM
QUOTE(madmab @ Jun 11 2008, 03:16 PM)
Got it!! Seems I made the same mistake as mentioned above. Had a char variable defined 1 character to small. I keep forgetting that even though char's count from zero that I need to add 1 for the terminating character.
I usually catch those because something is usually missing, but in this case the way I was using that variable the lack of a terminating character didn't affect it.
good work madmab, im lovin this release brother!!
XT-
Post by: madmab on June 18, 2008, 10:07:00 AM
Gameshark style Database added (just like Atarixlbox) so you can search it for cheats, save any cheats you added to an external file for sharing, etc.
Cheats are deactivated on game load. Seems this can cause the 7800 to hang on the Atari logo boot screen.
Games that use two buttons now work properly. Buttons one and two were mapped backwards (in mess) so I fixed that. So in "Dark Chambers" you can now use bombs, "Desert Falcon" you can use special items, and Hyperspace now works when you press button two in "Asteroids (and hacks)". Just to name a few.
**************
Internal changes
**************
moved all the stuff at the beginning of commonfucs.cpp to "commonchecks.cpp". It was getting kinda large with my additions. I still need to clean that up a little.
Modified the a7800 specific rewind so it uses mame's "scheduled" state load/save like it is supposed to. This allows rewind (mostly) to work in games like Commando where it didn't before.
-----------------------------
Savestates are not exactaly 100% correct. For example in games like Dark Chambers that use character mode. Somehow the character sets get messed up. Oddly enough savestates in the a7800 driver for MESS always lock up on my PC. So I suppose we are lucky they even semi work.
Post by: madmab on June 18, 2008, 03:01:00 PM
I didn't wanna say anything about Gensx until I had a chance to try and compile it. I still need to set up assembly stuff before I can even compile it.
Oh and I've been running my stuff on a 1.6 since day one and running the debug bios on the same 1.6 since sometime in February. Debug BIOS sure helps out alot when it comes to doing things. Alot of things would have taken me alot longer to figure out otherwise.
Post by: XTecuterX73 on June 18, 2008, 03:05:00 PM
QUOTE(madmab @ Jun 18 2008, 05:37 PM)
I meant done with this guy as in done with the changes I was planning on making to a7800x.
I didn't wanna say anything about Gensx until I had a chance to try and compile it. I still need to set up assembly stuff before I can even compile it.
Oh and I've been running my stuff on a 1.6 since day one and running the debug bios on the same 1.6 since sometime in February. Debug BIOS sure helps out alot when it comes to doing things. Alot of things would have taken me alot longer to figure out otherwise.
really??
i had read that the chances of a 1.6 box working with debug was very slim so i didnt want to take the chance and brick it.
no worries about the gensx thing man, it's cool whenever/if you want to get around to it just let me know and ill send it or you can add the line of code i have in the thread. i just wanted to try it out before i leave.
good to hear i read it wrong, lol,
i wasnt sure if i had done something or not. to stay on topic with atari though, im not sure how much sense things make but i tried out wizard of wor yesterday and couldnt get the controls to work on it.
shoot wait a min that's z26 i think though..
XT-
Post by: madmab on June 18, 2008, 07:02:00 PM
Silly I know, but what can I say...
Post by: XTecuterX73 on June 18, 2008, 07:19:00 PM
QUOTE(madmab @ Jun 18 2008, 09:38 PM)
For some dumb reason the programmers of Wizard Of Wor choose to stay true to the original arcade and have player 1 mapped to joystick 2 and player 2 to joystick 1.
Silly I know, but what can I say...
lol. now that makes sense, i actually had that problem with towering inferno as well so i will go back and check that too. lol
I was wondering about it, i know you're not working on z26, i just thought it was funny at first that i could play mk trilogy for ps1 on xbox but not wizard of wor! lol i have not had any issues with atarixlbox. your last release was awesome! most people shoot straight for "newer" older consoles but you went way back in the time machine, i seemed to be stuck in 1985 nes and 1991 genesis right now.
my two things im looking at are overclock cpu for nes (which would GREATLY improve alot of games) and that standalone soldiers of fortune neogenesis. i had no idea that you had to have assembly set up to compile that though. but that's cool im a patient guy.
thanks for the info on the wizard of wor madmab!
XT-
Post by: madmab on June 20, 2008, 12:11:00 AM
QUOTE(XTecuterX73 @ Jun 18 2008, 09:55 PM)
lol. now that makes sense, i actually had that problem with towering inferno as well so i will go back and check that too. lol
I was wondering about it, i know you're not working on z26, i just thought it was funny at first that i could play mk trilogy for ps1 on xbox but not wizard of wor! lol i have not had any issues with atarixlbox. your last release was awesome! most people shoot straight for "newer" older consoles but you went way back in the time machine, i seemed to be stuck in 1985 nes and 1991 genesis right now.
my two things im looking at are overclock cpu for nes (which would GREATLY improve alot of games) and that standalone soldiers of fortune neogenesis. i had no idea that you had to have assembly set up to compile that though. but that's cool im a patient guy.
thanks for the info on the wizard of wor madmab!
XT-