What's next

[MikeQ]

Okay, I'm  running low on things to do.  I've got a lot of what "I" want done, finished.  Need help prioritizing our proposed features and expanding the proposed list with new ideas.

Also, on the Wiki, when a proposed feature gets implemented, do we move it to the "next release" section.  Once we release it, do we move it again to the current features? 

Let me know.

[Howard_Casto]

I don't mean to insult your efforts in any way, but up until now your powermame build, while flashy, doesn't really add anything to the accuracy of mame. 

Making blinky lights go off when you insert a coin generically is cool and all but why not use all the light outputs on the ledwhiz to power outputs in emulated games (lights solenoids, actuators, step motors, ect...)?

I've made several threads on the subject but I don't have time to maintain a build myself.  I would be willing to help you get it started, however.  The key is to copy mame's input cfgs ad use them to make output cfgs, so different outputs can be mapped to different channels on the led whiz.  Games that come to mind that need this are warlords (has 4 lights so keyboard leds aren't enough)  gorf (has 6 lights)  t2 (has a solenoid and light for each gun) and several others I am forgetting. 

Also support for output methods other than the ledwhiz would be nice.  Don't get me wrong, the ledwhiz is cool and all, but not really worth the price if you don't need more than 11 lights.  Manipulation of the keyboard leds and the parallel port (the 8 data pins can be used to control leds or what have you) would probably do it. 

I'll have to dig up a link to a thread I did a few weeks ago explaining the functions that need built. 

In the meantime, keep up the good work.

[JoyMonkey]

Making blinky lights go off when you insert a coin generically is cool and all but why not use all the light outputs on the ledwhiz to power outputs in emulated games (lights solenoids, actuators, step motors, ect...)?

Correct me if I'm wrong, but isn't this what the lighting events engine is for? It only supports the Q*bert solenoid right now, but is still in its early stages.

[MikeQ]

I don't mean to insult your efforts in any way, but up until now your powermame build, while flashy, doesn't really add anything to the accuracy of mame. 

Stated in a non pissy manor (I seem to have a problem coming off sounding pissy).

The lighting stuff was something I wanted for my cabinet and is what started the whole project to begin with.  Many of the features that PowerMAME will support have nothing to do with accuracy.  That has never been my goal.  If there are games that don't play well because mame doesn't have support for their controllers, then I'd like to address them but accuracy isn't my personal primary goal.  Many of the Wiki items do address accuracy and  playability but I'm more than willing to do things that fly in the face of accuracy.   Of course this will be configurable for those that want accuracy. 

Making blinky lights go off when you insert a coin generically is cool and all but why not use all the light outputs on the ledwhiz to power outputs in emulated games (lights solenoids, actuators, step motors, ect...)?

Nothing prevents this now.  Just as easily as you can light and led, you can fire solenoids, etc.  The event lighting needs more work and needs to be extended to in game events.  Once this is done, these features can be more fully supported.

I've made several threads on the subject but I don't have time to maintain a build myself. 

Neither do I.   

I would be willing to help you get it started, however.  The key is to copy mame's input cfgs ad use them to make output cfgs, so different outputs can be mapped to different channels on the led whiz.  Games that come to mind that need this are warlords (has 4 lights so keyboard leds aren't enough)  gorf (has 6 lights)  t2 (has a solenoid and light for each gun) and several others I am forgetting. 

Can you explain this in more detail.  I was under the impression that most of the game specific lighting is controlled via the game code (ROM) and would require intercepting memory writes to specific addresses.  I'm finding less and less time to actually read this forum so I apologize if I've missed some threads.  Sometimes I just scan over them and if it doesn't pertain to what I'm currently working on, I just ignore them.

Also support for output methods other than the ledwhiz would be nice.  Don't get me wrong, the ledwhiz is cool and all, but not really worth the price if you don't need more than 11 lights.  Manipulation of the keyboard leds and the parallel port (the 8 data pins can be used to control leds or what have you) would probably do it. 

I don't know of any other devices and no one has asked me to add support for any.  I'd be willing to if there are a lot of people using other specific devices.  In my own research on adding lighting (I was looking into this before the LEDwiz existed) I found other devices but they were far more expensive and had other commercial applications that made them so.   I've asked buddabing about his controller and if I could support it but got no response.

I'll have to dig up a link to a thread I did a few weeks ago explaining the functions that need built. 

Please do.  One issue with implementing this stuff is that I need to have a test rig.  If people can provide me with the hardware, I'd love to work on it.   However, I don't have the time to go build solenoid circuits etc.   If you want to implement this stuff, cool too.  I'll merge things in or I can give you access to the Perforce server. 

In the meantime, keep up the good work.

Thanks,

Mike

[Howard_Casto]

Too many quotes for me to manage let me just go down the list:

I know that it's possible (an output is an output) I meant it's time to start supporting it.  Blink patterns would mean nothing for non led output as they would't be linked to gameplay. 

Yes it's actually in the driver code, but luckily in many cases it's already linked to set_led_status, a null input (for documentation purposes) or the artwork code (to turn on "lights" on false bezels).  Getting the data from the driver is actually quite easy, it's just a function needs to be written to take the data and use it to turn on/off the outputs (just like set_led_status does now). 

Heh, you must not know what I mean.  What interfaces?  I mean direct connections to keybaord lights and the parallel port.  The Keyboard leds are easy,  the set_led_status function is already written in mame, but the drivers are hardcoded in that they choose which keyboard light represents which game output.  That needs to be changed to something generic.  As for the parallel port, it's a straight shot.  There are 8 pins on the parallel port (I don't have them off hand but it's easy enough to find)  each pin represents a different output port that can be turned on and off with a simple write to the parallel port.  The "interface"  consists of some wire, 8 220 ohm resistors (actually not needed, but for safety's sake) and some sort of terminal block to take the wires from a lpt connector and patch them into your leds/relays/whatever.  The cost is about 1.50 to 5 bucks, so that's a non issue. 


The beauty of adding solenoid/actuator/whatever support is that you don't need the hardware to write the code.  You just need a led to test with as all of these devices are simply digital on/off devices with a few exceptions.  Since only people using the actual arcade hardware would be using anything other than lights anyway, they would alredy possess the necessary pcbs to ramp up the signal. 

To give you an example: I have a gorf machine with the 6, 12-volt, rank lights.  The lights are on their own controller pcb seperate from the game boards.  Upon close inspection of the pcb it's merely a bank of 12v relays that are actived by a ~5- volt signal.  Most games with output are like this so that high-voltage doesn't have to go through the logic boards.  The singal is 5 volts, which means I could wire my gorf light pcb directly to an ledwhiz, parallel port, or even the keyboard led output block on an ipac to the pcb. 

Qbert is the one notable exception, but most stick to this low voltage principal. 

[Howard_Casto]

Making blinky lights go off when you insert a coin generically is cool and all but why not use all the light outputs on the ledwhiz to power outputs in emulated games (lights solenoids, actuators, step motors, ect...)?

Correct me if I'm wrong, but isn't this what the lighting events engine is for? It only supports the Q*bert solenoid right now, but is still in its early stages.

I wouldn't know, but afaik mike just took the old qbert led hack and modified it to work with his interface.  I don't know if the original qbert hack actually uses a memory address in the rom's driver or not.  If not then it's not arcade accurate and needs fixed.  Not that I necessarily know how to do that mind you, I'm just saying. 

[Howard_Casto]

I think this is my clearest rant/explaination.... check out the last entry:

http://forum.arcadecontrols.com/index.php?topic=41092.0

[Silver]

Okay, I'm  running low on things to do.  I've got a lot of what "I" want done, finished.  Need help prioritizing our proposed features and expanding the proposed list with new ideas.

Also, on the Wiki, when a proposed feature gets implemented, do we move it to the "next release" section.  Once we release it, do we move it again to the current features? 

Let me know.

You have been busy! Looking at the wiki proposed features, I'm sure different people will want different things implimented next. For example, I am very keen on dual mouse support - this has never working (in windows) in mame, only analogmame/advancemame. Analogmame last worked back in v0.8, and advancemame has other issues (for me). Other peoples view may differ....

However, I have no idea how hard an addition it would be. I'd also give a vote for sorting out the gear change inputs - I suspect they have a high annoyance factor though as it will be looking at individual drivers. As is Offscreen Lightgun Reload I suspect...

EDIT: I think the ssf patch would be pretty easy to add...

[JoyMonkey]

EDIT: I think the ssf patch would be pretty easy to add...

Speaking of the SSF patch, did you read the article by SA Dev (the guy that originally made the ssf patch) on RetroBlast last week?
http://www.retroblast.com/articles/winmamemon_1.html
He mentions a lot of video tweaking ...er... tweaks that are included in his collection of patches. I wasn't aware of them before and they might be worth looking into. Actually, maybe we should  ask SA Dev if he'd be interested in putting a little time into PowerMAME.

Seeing as how Mame is going under some major changes right now, it wouldn't surprise me if the standard ssf patch won't work with the next few builds. And if save states are about to be fixed on all games, ssf will become redundant soon enough anyway.

[MikeQ]

Too many quotes for me to manage let me just go down the list:

I know that it's possible (an output is an output) I meant it's time to start supporting it.  Blink patterns would mean nothing for non led output as they would't be linked to gameplay. 

Yes it's actually in the driver code, but luckily in many cases it's already linked to set_led_status, a null input (for documentation purposes) or the artwork code (to turn on "lights" on false bezels).  Getting the data from the driver is actually quite easy, it's just a function needs to be written to take the data and use it to turn on/off the outputs (just like set_led_status does now). 

Heh, you must not know what I mean.  What interfaces?  I mean direct connections to keybaord lights and the parallel port.  The Keyboard leds are easy,  the set_led_status function is already written in mame, but the drivers are hardcoded in that they choose which keyboard light represents which game output.  That needs to be changed to something generic.  As for the parallel port, it's a straight shot.  There are 8 pins on the parallel port (I don't have them off hand but it's easy enough to find)  each pin represents a different output port that can be turned on and off with a simple write to the parallel port.  The "interface"  consists of some wire, 8 220 ohm resistors (actually not needed, but for safety's sake) and some sort of terminal block to take the wires from a lpt connector and patch them into your leds/relays/whatever.  The cost is about 1.50 to 5 bucks, so that's a non issue. 


The beauty of adding solenoid/actuator/whatever support is that you don't need the hardware to write the code.  You just need a led to test with as all of these devices are simply digital on/off devices with a few exceptions.  Since only people using the actual arcade hardware would be using anything other than lights anyway, they would alredy possess the necessary pcbs to ramp up the signal. 

To give you an example: I have a gorf machine with the 6, 12-volt, rank lights.  The lights are on their own controller pcb seperate from the game boards.  Upon close inspection of the pcb it's merely a bank of 12v relays that are actived by a ~5- volt signal.  Most games with output are like this so that high-voltage doesn't have to go through the logic boards.  The singal is 5 volts, which means I could wire my gorf light pcb directly to an ledwhiz, parallel port, or even the keyboard led output block on an ipac to the pcb. 

Qbert is the one notable exception, but most stick to this low voltage principal. 

So it looks like each game would need a cfg file for this approach since some games might do a set_led_status(0, on) for a start button but another game might consider led 0 to be some other led/whatever.  Is this right?

It seems that they way the set_led_satus is written, the first parameter is just a number that represents an LED.  If you considered this a virtualized enumeration, then each game could have a map file that maps this virtualized enumeration to a specific physical ouptut.  This way virtual enum 0 could be a start button on one game while being some other light on another game.  The only drawback is someone needs to go figure out what all these lights really did.

[Howard_Casto]

Yeah cfgs are a must... let's say you have a qbert knocker installed as input #1.  You don't want it constantly on when you start a 1 player game in warlords or thumping 50 times a second when starting a round of t2.  If nothing else, the ability to turn on/off various inputs is almost a requirement. 

I agree, the detective work is the hardest part.  Some of it is well documented though right in the driver itself.  For others it's quite obvious once you get a look at the cabinet.  Take digdug for example......  it has two lighted, volcano-style start buttons.  It also has two light memory addresses defined in mame.  Gee I wonder what those are for? 


Now harder games would be games like afterburner and powerdift, who's outputs borderline on directx force feedback in their complexity.  But starting with much simplier games and working up would be a solid plan. 

[MikeQ]

Yeah cfgs are a must... let's say you have a qbert knocker installed as input #1.  You don't want it constantly on when you start a 1 player game in warlords or thumping 50 times a second when starting a round of t2.  If nothing else, the ability to turn on/off various inputs is almost a requirement. 

I agree, the detective work is the hardest part.  Some of it is well documented though right in the driver itself.  For others it's quite obvious once you get a look at the cabinet.  Take digdug for example......  it has two lighted, volcano-style start buttons.  It also has two light memory addresses defined in mame.  Gee I wonder what those are for? 


Now harder games would be games like afterburner and powerdift, who's outputs borderline on directx force feedback in their complexity.  But starting with much simplier games and working up would be a solid plan. 

This sounds like a good next task.  I'll start looking into it.  I was looking at gorf and it looks like gorf is in the astrocade driver and that the leds are associated with seawolf lights? 

static WRITE8_HANDLER( seawolf2_lamps_w )
{
   /* 0x42 = player 2 (left), 0x43 = player 1 (right) */
   /* --x----- explosion */
   /* ---x---- RELOAD (active low) */
   /* ----x--- torpedo 1 available */
   /* -----x-- torpedo 2 available */
   /* ------x- torpedo 3 available */
   /* -------x torpedo 4 available */

   /* I'm only supporting the "RELOAD" lamp since we don't have enough leds ;-) */
   set_led_status(offset^1,data & 0x10);
}

[Silver]

Speaking of the SSF patch, did you read the article by SA Dev (the guy that originally made the ssf patch) on RetroBlast last week?
http://www.retroblast.com/articles/winmamemon_1.html
He mentions a lot of video tweaking ...er... tweaks that are included in his collection of patches. I wasn't aware of them before and they might be worth looking into. Actually, maybe we should  ask SA Dev if he'd be interested in putting a little time into PowerMAME.

Seeing as how Mame is going under some major changes right now, it wouldn't surprise me if the standard ssf patch won't work with the next few builds. And if save states are about to be fixed on all games, ssf will become redundant soon enough anyway.

Just read the article - his patch for autosync refresh is great! In fact, lots of his patches look extremely good. I agree - lets ask if he wants to contribute his patches to Powermame. Or rather, ask if he would mind us including them - he already releases up to date diffs....

[SirPoonga]

By the way, has anyone looking into LED outputs for Atari Football?

[Howard_Casto]

Yeah cfgs are a must... let's say you have a qbert knocker installed as input #1.  You don't want it constantly on when you start a 1 player game in warlords or thumping 50 times a second when starting a round of t2.  If nothing else, the ability to turn on/off various inputs is almost a requirement. 

I agree, the detective work is the hardest part.  Some of it is well documented though right in the driver itself.  For others it's quite obvious once you get a look at the cabinet.  Take digdug for example......  it has two lighted, volcano-style start buttons.  It also has two light memory addresses defined in mame.  Gee I wonder what those are for? 


Now harder games would be games like afterburner and powerdift, who's outputs borderline on directx force feedback in their complexity.  But starting with much simplier games and working up would be a solid plan. 

This sounds like a good next task.  I'll start looking into it.  I was looking at gorf and it looks like gorf is in the astrocade driver and that the leds are associated with seawolf lights? 

static WRITE8_HANDLER( seawolf2_lamps_w )
{
   /* 0x42 = player 2 (left), 0x43 = player 1 (right) */
   /* --x----- explosion */
   /* ---x---- RELOAD (active low) */
   /* ----x--- torpedo 1 available */
   /* -----x-- torpedo 2 available */
   /* ------x- torpedo 3 available */
   /* -------x torpedo 4 available */

   /* I'm only supporting the "RELOAD" lamp since we don't have enough leds ;-) */
   set_led_status(offset^1,data & 0x10);
}

Nope, those are just the seawolf lights.  Note it says seawolf2_lamps and not gorf.


The gorf memory address is defined in the driver, but used in the video driver (to control the bezel).  They both have the same amount of lights though... not sure if they use the same memory address. 


this is taken from the vidhw driver for astrocade:

READ8_HANDLER( gorf_io_2_r )
{
   UINT8 data = offset >> 8;
   offset &= 0xff;

   offset = (offset << 3) + (data >> 1);
   data = ~data & 0x01;

   switch (offset)
   {
   case 0x00: artwork_show("lamp0", !data); break;
   case 0x01: artwork_show("lamp1", !data); break;
   case 0x02: artwork_show("lamp2", !data); break;
   case 0x03: artwork_show("lamp3", !data); break;
   case 0x04: artwork_show("lamp4", !data); break;
   case 0x05: artwork_show("lamp5", !data); break;
#ifdef VERBOSE
   default:
      logerror("%04x: Latch IO2 %02x set to %d\n",activecpu_get_pc(),offset,data);
#endif
   }

Notice the "io_2_r" part....
that tells us that the port is from an i/o port in the second bank of gorf inputs as defined by the standard driver. 


Going back to the gorf section of the standard astrocade.c we find:


PORT_START_TAG("IN2")
   PORT_BIT( 0x01, IP_ACTIVE_LOW, IPT_JOYSTICK_UP ) PORT_8WAY
   PORT_BIT( 0x02, IP_ACTIVE_LOW, IPT_JOYSTICK_DOWN ) PORT_8WAY
   PORT_BIT( 0x04, IP_ACTIVE_LOW, IPT_JOYSTICK_LEFT ) PORT_8WAY
   PORT_BIT( 0x08, IP_ACTIVE_LOW, IPT_JOYSTICK_RIGHT ) PORT_8WAY
   PORT_BIT( 0x10, IP_ACTIVE_LOW, IPT_BUTTON1 )
   PORT_BIT( 0x20, IP_ACTIVE_LOW, IPT_UNKNOWN )
   PORT_BIT( 0x40, IP_ACTIVE_LOW, IPT_UNKNOWN )
   PORT_BIT( 0x80, IP_ACTIVE_HIGH, IPT_UNKNOWN )   /* speech status */


We have two unaccounted ports.... luckily we know from the comments in the vidhw driver that gorf uses two ports for random generation.  The first port is for drawing the starfield and various effects, the second is for the lamp dirver.  And since we have a 20 offset, we know that 0x20 is the starfield and 0x40 is the lamp port. 

The function to handle the lamps in the vidhw section is perfect for our purposes.  It takes the 8 bits of data and spreads it into a simple 0 or 1 value for each of the 6 lamps.  Simply add to the case statment a function call to whatever function we decide upon to control lamps and you are done. 

Seawolf will be similar, but as you noticed, it's data is NOT in the vidhw section.  This is because it doesn't have an artwork bezel to deal with and simply controls the keyboard led.
Again, it's a simple matter of taking the existing function and adding in a call to our function.  A nice thing to do while you were at it would be to move the seawolf stuff to the vidhw file and go ahead and define some artwork layers to control.  Then people without lights can use some sort of false bezel like you can with gorf. 

Sorry to ramble, but you seemed confused.  I thought a working example would help you learn how to navigate the i/o ports in mame. 

[Howard_Casto]

By the way, has anyone looking into LED outputs for Atari Football?

Yeah again if you go into the driver it's well documented

At the top if the driver it has a list of memory maps.  About halfway down we see:

        2003        (OUT 3)
                    D0-D3 = LED Cathodes
                    D4-D5 Spare


Going down to the actual memory handlers defined we see:

AM_RANGE(0x2003, 0x2003) AM_WRITE(atarifb_out3_w) /* OUT 3 */


So we know that's where the led data gets stored and we know that like gorf it has 6 outputs (only 4 are used though) assumingly with the same 8 bit chunk of data. 

Now the problem is nobody is exactly sure the data format of that 8 bits, which is is why it isn't defined anywhere in the input_ports function. 

We are only dealing with 4 lights though, so a person could hook it up and just play around until it's figured out which lamp is which. 

MY problem is I don't understand assembly enough to be able to properly link that region to a port.  Heck, it could already be mapped, there are two unknown ports in the football input port section.  I'm just too dumb to figure out which one it is without any documentation.

[Kremmit]

Okay, I'm  running low on things to do.  I've got a lot of what "I" want done, finished.  Need help prioritizing our proposed features and expanding the proposed list with new ideas.

Some of the features in the Wiki can be rolled in with little effort; like the Z-axis fix- the required code is right there in the Wiki.  Re-enabling the dial input for 720 shouldn't be that tough.  The Calibration fix for 720, U_Rebel had that working, I don't know if the code he used is totally obsolete with today's MAME.  Several of the other features have been implemented in other builds before, maybe the code just needs harvesting.

I guess what I'm saying is, maybe the next step is to see which features can be added easily.  Might as well get those out of the way first. 

Personally, and I don't think I'm alone, I'm a lot more interested in the input features, rather than the output stuff.  That said, it's your baby, if you wanna play with the output stuff first, well, hey, I suppose I do have this set of T2 guns that's waiting for some solenoid action...

[MikeQ]

Okay, I'm  running low on things to do.  I've got a lot of what "I" want done, finished.  Need help prioritizing our proposed features and expanding the proposed list with new ideas.

Some of the features in the Wiki can be rolled in with little effort; like the Z-axis fix- the required code is right there in the Wiki.  Re-enabling the dial input for 720 shouldn't be that tough.  The Calibration fix for 720, U_Rebel had that working, I don't know if the code he used is totally obsolete with today's MAME.  Several of the other features have been implemented in other builds before, maybe the code just needs harvesting.

I guess what I'm saying is, maybe the next step is to see which features can be added easily.  Might as well get those out of the way first. 

Personally, and I don't think I'm alone, I'm a lot more interested in the input features, rather than the output stuff.  That said, it's your baby, if you wanna play with the output stuff first, well, hey, I suppose I do have this set of T2 guns that's waiting for some solenoid action...

Like I mentioned earlier.  I started modifying MAME to do things for my cabinet.  The things I've been working on so far have been for me and my cabinet.  If others can use them fine.  If people don't like them, fine.   I'm at a point with my cabinet that I'm ready to shift gears and start looking at broader issues.  The 49way stuff was the beginning of this.  Not everything is going to get done in an order that makes sense.  Sometime I work on something because I have a block of time that fits that task.  Sometimes I just want to see something working.  Also, just because some code is sitting there and can be plopped in, doesn't mean that is what should be done.  One reason I'm interested in doing this project is to learn as much as I can about MAME.  If I just start harvesting code and throwing it in, I'm not learning much and if something gets broken, I'm not going to know why. 

There is a lot to do and it isn't going to get done overnight.  I've had this stuff available for less than a month so far.  I can only work so fast.  I've got another person working with me now and we are going to start looking at the analog stuff.  I've talked to u_rebelscum and he indicated that most of analogMAME needs a rewrite due to upheavals with MAME.  We are going to be looking to him for help/support. 

So be patient everyone.

[slycrel]

As far as suggestions go, I'd love an xbox port.  Currently there isn't a build of MAME that even supports a trackball or spinner on a modded xbox.

Yeah, I know.  Sorry, I don't have an extra xbox to send you.  =)  Really, this is just to express some interest in your project and dream about an xbox port that in reality will never happen.

[Howard_Casto]

As far as suggestions go, I'd love an xbox port.  Currently there isn't a build of MAME that even supports a trackball or spinner on a modded xbox.

Yeah, I know.  Sorry, I don't have an extra xbox to send you.  =)  Really, this is just to express some interest in your project and dream about an xbox port that in reality will never happen.

That's probably because the xbox has so little memory that the classics can barely be played without the added overhead of having to add in the debug functions to activate a mouse. 

[MikeQ]

As far as suggestions go, I'd love an xbox port.  Currently there isn't a build of MAME that even supports a trackball or spinner on a modded xbox.

Yeah, I know.  Sorry, I don't have an extra xbox to send you.  =)  Really, this is just to express some interest in your project and dream about an xbox port that in reality will never happen.

That's probably because the xbox has so little memory that the classics can barely be played without the added overhead of having to add in the debug functions to activate a mouse. 

Not to mention it has crappy Nvidia hardware in it.   

[Howard_Casto]

Well I wouldn't go that far.... the "crappy nvidia hardware" still blows away anything that can be done on the ps2 or gamecube.  The problem is nothing from that generation is powerful enough to do mame right.  Now the 360, that might be another story. 

[MikeQ]

Well I wouldn't go that far.... the "crappy nvidia hardware" still blows away anything that can be done on the ps2 or gamecube.  The problem is nothing from that generation is powerful enough to do mame right.  Now the 360, that might be another story. 

I work for ATI.  I'm paid to say bad things about NVidia. 

Of course the 360 can do it.  It has an ATI chip inside. 

[Silver]

Well I wouldn't go that far.... the "crappy nvidia hardware" still blows away anything that can be done on the ps2 or gamecube.  The problem is nothing from that generation is powerful enough to do mame right.  Now the 360, that might be another story. 

I work for ATI.  I'm paid to say bad things about NVidia. 

Of course the 360 can do it.  It has an ATI chip inside. 

Haha - theres something for the future then: Full screen 1600x1200 4xFSAA 3d-acceleration for all those 10fps 3D mame games - but only on ATI... 

  (anti-mame, non-authentic speed-up hacks ahoy!!) 

[Tiger-Heli]

Haha - theres something for the future then: Full screen 1600x1200 4xFSAA 3d-acceleration for all those 10fps 3D mame games - but only on ATI... 

But backwards compatible so they run fine on a Radeon 7000 (or at least the 9250 that I use) 

[Howard_Casto]

Well I wouldn't go that far.... the "crappy nvidia hardware" still blows away anything that can be done on the ps2 or gamecube.  The problem is nothing from that generation is powerful enough to do mame right.  Now the 360, that might be another story. 

I work for ATI.  I'm paid to say bad things about NVidia. 

Of course the 360 can do it.  It has an ATI chip inside. 

I think you misunderstand.... my hatred for nvidia knows no bounds.  Unfortunately my love for the xbox and all things m$ is just that much greater.  The fact that the gamecube *almost* rivals the graphics quality of the xbox is saying just how much an ati chipset can do. (Of course the fact that the cube has a crappy controller and severely limted storrage capacity pretty much negates the good graphics chipset.) Fortunately one bad cog isn't enough to slow the iron will of the great machine that is microsoft. 


This is all too apparent now that m$ has "aquired" the services of ati for future projects. 

Resistance is futile, you will be assimilated, all will become one with the m$. 

[mahuti]

ms *yawhn*

I use their stuff. But I sure can't get passionate about it.

[MikeQ]

Well I wouldn't go that far.... the "crappy nvidia hardware" still blows away anything that can be done on the ps2 or gamecube.  The problem is nothing from that generation is powerful enough to do mame right.  Now the 360, that might be another story. 

I work for ATI.  I'm paid to say bad things about NVidia. 

Of course the 360 can do it.  It has an ATI chip inside. 

I think you misunderstand.... my hatred for nvidia knows no bounds.  Unfortunately my love for the xbox and all things m$ is just that much greater.  The fact that the gamecube *almost* rivals the graphics quality of the xbox is saying just how much an ati chipset can do. (Of course the fact that the cube has a crappy controller and severely limted storrage capacity pretty much negates the good graphics chipset.) Fortunately one bad cog isn't enough to slow the iron will of the great machine that is microsoft. 


This is all too apparent now that m$ has "aquired" the services of ati for future projects. 

Resistance is futile, you will be assimilated, all will become one with the m$. 

Getting taken over by Microsoft wouldn't be the worst thing that could happen.  Intel, not so good.  I use to work for a company they took over.  Notice I say "use to".

[GoPodular.com]

I'd love to see net play.

http://www.kaillera.com
"We do have a Kaillera-enabled version of MAME called MAME32k and its source code available for download on the Kaillera website." (http://www.kaillera.com/download.php)

It looks like MAME 0.67 was the last one.  I'm sure it's possible to point it to a new server system for just PowerMAME users.  Kind of like the gamespy thing.

[mccoy178]

I'd love to see net play.

http://www.kaillera.com
"We do have a Kaillera-enabled version of MAME called MAME32k and its source code available for download on the Kaillera website." (http://www.kaillera.com/download.php)

It looks like MAME 0.67 was the last one.  I'm sure it's possible to point it to a new server system for just PowerMAME users.  Kind of like the gamespy thing.

I second that notion.

[RetroBorg]

I'd love to see net play.

http://www.kaillera.com
"We do have a Kaillera-enabled version of MAME called MAME32k and its source code available for download on the Kaillera website." (http://www.kaillera.com/download.php)

It looks like MAME 0.67 was the last one.  I'm sure it's possible to point it to a new server system for just PowerMAME users.  Kind of like the gamespy thing.

I third that notion. 

[MYX]

ms *yawhn*

I use their stuff. But I sure can't get passionate about it.

Yeah, me either. I use the Adobe video suite for my work. If I did not have so much time invested into knowing the product, I would be on a mac in a heartbeat. I use a mac as an email machine at work and as you have seen, macfolk get almost religious about their computers.

* MYX starts talking out his arse

As for net play, could that even work? The games are written for 1 & 2 (sometimes up to 4) players but it is all based on the local hardware. Stuff like the xbox live and internet pc games are written to be networked and played. Some of the newer driving games and stuff like TMEK were designed with network interface. But to play NBA Jam...I don't know.

* MYX realizes that he just spoke his arse. Stops. Makes sure no one was watching, and walks away

[GoPodular.com]

As for net play, could that even work?

Yep:
http://forum.arcadecontrols.com/index.php?topic=11561.0
http://forum.arcadecontrols.com/index.php?topic=11143.0

Couple interesting discussions re: Kaillera.  Sounds like it's kind of a PITA though.  I myself have never used it.

[MYX]

As for net play, could that even work?

Yep:
http://forum.arcadecontrols.com/index.php?topic=11561.0
http://forum.arcadecontrols.com/index.php?topic=11143.0
Couple interesting discussions re: Kaillera.  Sounds like it's kind of a PITA though.  I myself have never used it.

* myx realizing he has been seen, hides under a table and pretends he is invisible.

[mccoy178]

*We can still see MYX

[Howard_Casto]

For the record, that is exactly why kaillera died.  For some games it works, for others it doesn't.  Also it had SERIOUS issues with routers and such.  All in all it was always more trouble than it was worth. 

[GoPodular.com]

Is it possible to get *some* games working correctly?  I would think games like Blasteroids & Joust would be easiest.  Some lag is tolerable, each player has their own controls, etc.

For routers, isn't it just a matter of how the code is written?  ( I don't code, but do know networking principles)

Could there be a filter for the games that work online?

[JoyMonkey]

Adding any kind of networked multiplayer support directly into MAME would just be a huge waste of time and effort (and another thing to piss off the MAMEdevs).

What you need is a seperate application that launches common applications on several networked PC's and allows keyboard/mouse/joypad inputs to be passed between each user. Kind of like a networked front-end. If done correctly, an app like this could be used with any program, not just MAME, and I'd imagine it could be done with less lag than Kaillera had.
Is there anything like this out there already?

[SirPoonga]

What you need is a seperate application that launches common applications on several networked PC's and allows keyboard/mouse/joypad inputs to be passed between each user.

And the keypresses would control the game??  That is a horrible idea.  Lag will cause things to lose sync, especially if the game has any randomness to it.

[JoyMonkey]

What you need is a seperate application that launches common applications on several networked PC's and allows keyboard/mouse/joypad inputs to be passed between each user.

And the keypresses would control the game??  That is a horrible idea.  Lag will cause things to lose sync, especially if the game has any randomness to it.

You think so? Okay then, back to the drawing board. How does Xlink Kai communicate between different console systems?