Xport Says "hi" Options

[s_0]

Hi Xport, just want to state the obvious - that you are GOD and that Madmab is JESUS

All joking aside, you trully have been amazing (and still are in whatever youre doing im sure), many many many thanks for all your GREAT work which have made so many people happy!

[neil222]

Hi Xport, just want to state the obvious - that you are GOD and that Madmab is JESUS

Very funny
Nice to see you around here again Xport.

[sbpaabck]

Thanks XPORT! I know at least 20 people that are loving your emulators!

I know because I did their softmods

you helped to transform the xbox into a retro gamers dream. It is great to have such a handy compendium/archive for all the great games that were starting to be forgotten and lost and without the work you did that wouldn't have happened!

So thanks again, its great to be able to actually speak to you, thought you had gone forever. Hope you're keeping well and putting those coding talents to good use!

[ressurectionx]

Wow.... the Big Man himself.

Thanks for all the great emus man, and you should definitely try the new stuff out. Please PM me if you need help getting on the Xtras site. We're going to have to get you hooked up with all the latest stuff so you can give it a try for yourself instead of reading boring release notes. All of the Xtras were originally collected to work with your final releases, and then more was added as new features were being made for the XPORT platform. First NES6502 got the video preview working, and then madmab pretty much made anything else that we could imagine come true. His feature additions certainly have kept a lot of us busy collecting the content that makes the features worthwhile, and now that I'm done there are a lot of people continuing to work on getting this stuff all collected and working for other emus you released.



I know you're probably not interested anymore in doing any work here in the future, and from where I'm sitting I can more than empathize with that. But..... if you ever do decide to make one last emu port, my vote is for the Vectrex. If we could get XPORT code wrapped around that emu, I believe it would be possible to play the games with artwork of the screen overlays on top of the game play using transparency like the pop-up keyboard.

I've only been asking for this for about 18 months in your absence. It's great to see you back around, even if you decide that you don't want to do it.

Thanks for everything,
~Rx

[DarthMingus]

Wow, you're back! Good to hear you are doing well! Thanks again, your emulators are definitely still in use and very much appreciated!

This post has been edited by DarthMingus: Jun 1 2010, 01:57 AM

[competes2win]

Great to see you Xport... I echo everyone else's comments... Your work is very much appreciated!

[XPort]

First, thanks to all the well-wishers. It's nice to be remembered.

It's also nice to hear that development is still going strong. I checked out the videos/content and they look really slick. The online database is neat, too.

re:threads - you've probably read things like "they can be tricky" - especially when you need two threads to communicate with each other (e.g. passing data back and forth), but they're really not so bad. I'm not sure if I can give an adequate overview of threads in a single, concise post. The main thing you need to worry about is ensuring any variables you read/write from are "thread-safe" - meaning you need to ensure that they are not being read/written simultaneously by more than one thread You do this by using mutexes (and/or critical sections in Windows API). There are tons of examples on the net for working with Windows threads. Also be mindful of having a way to easily disable them when launching a game. You can use the mp3player class as an example upon which to build. It plays the mp3s in the background using a separate thread. (The thread is either in the class or somewhere else - I forget now...)

re:WinUAEX - not familiar with the lockup bug being discussed. Alas, even if I did, I would not have time to fix it. It took me several days just to return to these forums to check up on my original post! The odd screen resolution is actually the native screen size (or rather, what WinUAEX defines it to be). I can't give any more of an explanation than that.

re:freedo - I still have the source somewhere, but it's not mine to distribute. I promised him I wouldn't give it to anyone and he hasn't open-sourced it himself, so I'm afraid that's that. I seriously doubt that anyone would be able to make it run at an acceptable speed, though, so don't lose any sleep over it.

As far as doing any other XBox projects, it's very unlikely. I'm actually more interested in backporting the projects to Linux. (Sorry to the Windows users out there!) This is primarily because I'm very interested in this handheld that runs Linux:

http://www.openpandora.org/

It's probably about on-par with the XBox1, but the wrinkle is that it's running ARM, so certain ports will not be possible without recoding the ASM cores (which is a daunting task to say the least.) These ports include Z26, GENS and I think at least one or two others. It would be neat having all of the others running on a handheld like this, though. I'm still waiting to hear back from the manufacturers about getting a unit, though.

Oh and madmab - I forget - did I ever give you write-access to the sourceforge project? If not, then shoot me a PM (mailbox no longer full).

Thanks again for everyone's kind words!

[madmab]

re:threads - you've probably read things like "they can be tricky" - especially when you need two threads to communicate with each other (e.g. passing data back and forth), but they're really not so bad. I'm not sure if I can give an adequate overview of threads in a single, concise post. The main thing you need to worry about is ensuring any variables you read/write from are "thread-safe" - meaning you need to ensure that they are not being read/written simultaneously by more than one thread You do this by using mutexes (and/or critical sections in Windows API). There are tons of examples on the net for working with Windows threads. Also be mindful of having a way to easily disable them when launching a game. You can use the mp3player class as an example upon which to build. It plays the mp3s in the background using a separate thread. (The thread is either in the class or somewhere else - I forget now...)

Thanks. I was hoping to do threads with the preview movies and possibly any copying across the samba share to reduce interface lag. Like you said I think the thing I need to be most mindful of are "thread-safe" variables and stopping the thread when a game is launched. Freak Dave pointed out some stuff in the SDK documentation.

I was also highly considering porting in the SAMBA code from XBMC since it is a bit more robust and the code used now seems to have been abandoned by it's author.

re:WinUAEX - not familiar with the lockup bug being discussed. Alas, even if I did, I would not have time to fix it. It took me several days just to return to these forums to check up on my original post! The odd screen resolution is actually the native screen size (or rather, what WinUAEX defines it to be). I can't give any more of an explanation than that.

I did manage to fix a few lock-up bugs but the biggest thing that is eluding me now is the core seems to not release memory so each execution of a game eats up RAM. I've traced about as much as I can but everything I've seen seems accounted for. So I'm at a loss about where it is losing the RAM. Most is released on exit and the ones that aren't are "re-used" on the next run. But something is slipping thru. What I did was set a checkpoint on the RAM allocate and deallocate functions. Still no luck, though.

re:freedo - I still have the source somewhere, but it's not mine to distribute. I promised him I wouldn't give it to anyone and he hasn't open-sourced it himself, so I'm afraid that's that. I seriously doubt that anyone would be able to make it run at an acceptable speed, though, so don't lose any sleep over it.

Some guy actually sent a PM claiming he'd be able to get the code to me but I doubt I'd have the skills to get it running at a better speed. I'm scraping by as it is.

It's probably about on-par with the XBox1, but the wrinkle is that it's running ARM, so certain ports will not be possible without recoding the ASM cores (which is a daunting task to say the least.) These ports include Z26, GENS and I think at least one or two others. It would be neat having all of the others running on a handheld like this, though. I'm still waiting to hear back from the manufacturers about getting a unit, though.

I think WinstonX uses some as well with it's 68000 cpu core. When I tried to modify the TOS routines to redirect memory read/writes to save memory the cpu core went bonkers...

Oh and madmab - I forget - did I ever give you write-access to the sourceforge project? If not, then shoot me a PM (mailbox no longer full).

I honestly don't remember yet. I'm not quite ready to put the changes out there yet. But I mostly got the code to where I want it. Pending any samba and multi-thread attempts I may make.

Only other thing I was curious about is if there was any particular method you used to determine the buffer size to use for emu's. This question crossed my mind while I was working on getting PAL ROMS to run in Snes9xbox.

Thanks!

[hcf]

Wow, it's amazing to read this post with the comments of the heavyweights of the Xbox scene. In fact, I'm embarrassed for posting here now

Xport, I only wanted to wish you luck with your new projects. I didn't know Pandora, it seems amazing!! And please, don't remember that we will be here, and we will be very glad to see you here every time that you visit these forums.

In fact, don't forget that, even although you will be developing for another plattform now, we still can cooperate. I mean, if Pandora is similar in power to the Xbox, I'm sure that every progress made in one console can be reflected in the other. For example, if Madmab in the future manages to make a Vectrex emulator, probably Pandora can run it. The same can be said for Pinmame, and so on...

Even, I remember that I posted a thread where I asked for emulation of the Sega Pico. It is a console very similar to the Genesis, and in fact the Neogenesis emulator loads the Sega Pico roms, but you cannot play because the special controls of the Pico are not mapped. Or even, if someone has a super-idea and manages to make FreeDO work in Xbox or Pandora, it will be feasible to port it to the other console. Well, this is dreaming... I only mean that I hope that we keep contact, because you are a very important person to the Xbox emulation, and I'm sure that Pandora has a big luck to have Xport between their developers

[Likklebaer]

I'm not one for requesting projects but I'd like to see an XPort update to MAMEoX. Not because I'm in any way unhappy with the current port but it would just be nice to see CoinOPS and BP's obnoxious ego blown out of the water!

[XPort]

I was also highly considering porting in the SAMBA code from XBMC since it is a bit more robust and the code used now seems to have been abandoned by it's author.

Sounds like a good idea - I'm sure a lot of people still come by the forums and say samba doesn't work for them.

I did manage to fix a few lock-up bugs but the biggest thing that is eluding me now is the core seems to not release memory so each execution of a game eats up RAM. I've traced about as much as I can but everything I've seen seems accounted for. So I'm at a loss about where it is losing the RAM. Most is released on exit and the ones that aren't are "re-used" on the next run. But something is slipping thru. What I did was set a checkpoint on the RAM allocate and deallocate functions. Still no luck, though.

Are you checking WinUAE's version of alloc routines that actually make the alloc/malloc calls or the alloc/malloc calls themselves? You can also search for "new"/"delete" pairs to see if there is a discrepancy. Another thing you can try is to use the profiling tools that are included with the XDK. It's been forever, so I don't remember the specifics, but there is a program that you can run on your Windows machine that will start the XBE in profiling mode. Then right before you start a game, you invoke another command in Windows to take a snapshot of memory/variables. Then start the game, play with it, and exit the game back to the point you were at before you started the game. Take another snapshot and then compare the two logfiles to see where the difference is.

Some guy actually sent a PM claiming he'd be able to get the code to me but I doubt I'd have the skills to get it running at a better speed. I'm scraping by as it is.

Beware you don't invoke the wrath of the original developer if you get it from a guy in the back of his van.

Only other thing I was curious about is if there was any particular method you used to determine the buffer size to use for emu's. This question crossed my mind while I was working on getting PAL ROMS to run in Snes9xbox.

You'll have to refresh my memory - what buffer size are we talking about and how is it used? If it's the frame buffer, then it should be large enough to hold enough data to store double the game screen size, and the height/width need to be a power of 2. You need double the screen size to account for people wanting to use software filters that can effectively double the screen size. The height/width need to be a power of 2 because that's how the xbox hardware allocates video buffers - by powers of 2. So if the emulator resolution is something like 160x144 (gameboy) then double would be 320x288. The closest power of 2 to enclose that area is 512x512 (next power of 2 that is lower than 512 is 256). 512x512x(number of bytes per pixel) = number of bytes to allocate. I actually allocate a bit more to accommodate a few more lines of resolution because some of the filters write past the 2x mark. Hope this is the buffer you're talking about or else that was a pointless ramble!

[flux2k]

I was also highly considering porting in the SAMBA code from XBMC since it is a bit more robust and the code used now seems to have been abandoned by it's author.

Wow, Madmab - don't tease me like that. I'd love to see XMBC's SAMBA code in the emus.

There is still one last group continuing work on XMBC for Xbox:
http://sourceforge.net/projects/xbmc4xbox/

[madmab]

Sounds like a good idea - I'm sure a lot of people still come by the forums and say samba doesn't work for them.
Are you checking WinUAE's version of alloc routines that actually make the alloc/malloc calls or the alloc/malloc calls themselves? You can also search for "new"/"delete" pairs to see if there is a discrepancy. Another thing you can try is to use the profiling tools that are included with the XDK. It's been forever, so I don't remember the specifics, but there is a program that you can run on your Windows machine that will start the XBE in profiling mode. Then right before you start a game, you invoke another command in Windows to take a snapshot of memory/variables. Then start the game, play with it, and exit the game back to the point you were at before you started the game. Take another snapshot and then compare the two logfiles to see where the difference is.
Beware you don't invoke the wrath of the original developer if you get it from a guy in the back of his van.

I was checking the alloc/malloc calls themselves.

I'll try looking into that. I noticed that some emu's had a "profile" build.. is that what you are referring to?

You'll have to refresh my memory - what buffer size are we talking about and how is it used? If it's the frame buffer, then it should be large enough to hold enough data to store double the game screen size, and the height/width need to be a power of 2. You need double the screen size to account for people wanting to use software filters that can effectively double the screen size. The height/width need to be a power of 2 because that's how the xbox hardware allocates video buffers - by powers of 2. So if the emulator resolution is something like 160x144 (gameboy) then double would be 320x288. The closest power of 2 to enclose that area is 512x512 (next power of 2 that is lower than 512 is 256). 512x512x(number of bytes per pixel) = number of bytes to allocate. I actually allocate a bit more to accommodate a few more lines of resolution because some of the filters write past the 2x mark. Hope this is the buffer you're talking about or else that was a pointless ramble!

Sorry to make you pointlessly ramble with my ramble. I kinda got ahead of myself and forgot to say it was the sound buffer that I was referring too...

This post has been edited by madmab: Jun 5 2010, 07:14 AM

[madmab]

Wow, Madmab - don't tease me like that. I'd love to see XMBC's SAMBA code in the emus.

There is still one last group continuing work on XMBC for Xbox:
http://sourceforge.net/projects/xbmc4xbox/

Yeah I'm not sure when I'm gonna attempt it. But I was able to compile the samba code included with XBMC and create the library file. So it's just a matter of recoding the samba sections to use the new data structures and commands.

Hopefully it won't be too difficult.

Like X-port says it seems like alot of people have trouble getting samba to work properly and I'm not particularly comfortable with some of the steps one has to take to even get it to work (change from USER mode to SHARE mode). Plus XBMC's samba code seems to work much better.

I guess one major motivating factor is that my NAS doesn't like the samba code in the emu's.

Although run088 did stumble across a semi solution with a program called xbms which is a compilable unix program that lets on run XNS shares (aka Relax) off a unix box.

I would like to make some type of youtube "tutorial" going over setting this stuff up. Possibly with the RessurectionXtras as an example.

[XPort]

I was checking the alloc/malloc calls themselves.

I'll try looking into that. I noticed that some emu's had a "profile" build.. is that what you are referring to?

Sorry to make you pointlessly ramble with my ramble. I kinda got ahead of myself and forgot to say it was the sound buffer that I was referring too...

That might be part of it - for some reason I only have memory of needing to run the utilities on the windows box to launch the XBE in profiling mode. I thought the debug symbols would be enough, but perhaps it needs some additional settings. The details are probably somewhere in the XDK help file.

As for the sound buffer - yeah that required some fine-tuning to avoid crackling/gaps/overflows. Some emulators were very good about outputting the correct amount of sound each frame, while others required some voodoo. There is no real formula - you just have to play with it and experiment if it's not working quite right.