Main > Software Forum
Warlords 4 LED (start button) support
<< < (4/7) > >>
2600:
Your knowledge of programming is better then mine, but here's my take.

1. XP, 2000 doesn't allow direct access.  Most likely a dll is required, I would think it would be better then a tsr or driver that allows access.

2. Whether or not MAMEdev accepts it or not is moot.  They may not accept it either way, but is definitely a goal.  But there is already OS specific code in MAME, the best way to get it accepted or general is to keep the OS specific code out of the general code.  Just create general functions and the OS specific code in the OS specific section.  Then all one has to do for another OS is change the OS specific part.  All that OS stuff just goes in the src/Windows directory.  Even the keyboard LEDs are OS specific.  Looks like they are even windows version specific.


But I may be talking out of my arse a bit here, so go ahead and correct as necessary.
Howard_Casto:
Well first off... the mame devs pretty much don't allow dlls, period.  the only one's in mame right now are the one's crucial to core operations.  I don't think they are going to allow one for an optional feature.

Secondly a tsr is a better solution becuase it makes it possible to drop a dll (The tsr would be downloaded seperately and thus would have nothing to do with mame or it's source), which would be os/specific and like I said, probably wouldn't be accepted by the mame devs. What the tsr does is basically call a dll without the dll having to be integrated into a program's code.

 Finally os-specifi code IS the way to go, but that doesn't change the fact that they ren't going to like that dll.  Some os-specific calls would still be necessary, mainly the initilization stage (linux handles ports slightly different I *think*)

Howard_Casto:
Ok I found the program I was thinking of.  It's called Port Talk.  It's more of a wrapper than anything. 

http://www.beyondlogic.org/porttalk/porttalk.htm

The last time I tried it it worked pretty well.  I'll have to get out my old LED rig and see what I can get it to do in respects to mame.

The biggest thing is the stuff sirp was talking about.  IE the headers required to get inp and outp to work in mingw.

SirPoonga:

--- Quote from: Howard_Casto on August 11, 2005, 11:17:02 pm ---The last time I tried it it worked pretty well.  I'll have to get out my old LED rig and see what I can get it to do in respects to mame.

--- End quote ---
I just realized something.  You don't need ot do anything to the drivers, except possibly add more set_led_status calls.
Now, with set_led_status and osd_set_leds the state is an int.  Meaning it is 32bits, hence being able to handle 32 leds, but parallel port can only handle 8.
set_led_status just ands or nots a bitmast (led_status) where each bit represents the state of a led.  osd_set_leds, which is OS dependent as it is implemented in the OS folder, gets called each video_and_audio_update to update the leds.  It only looks at the first three bits.

So in the case of warlords (centiped.c)

--- Quote ---static WRITE8_HANDLER( led_w )
{
   set_led_status(offset, ~data & 0x80);
}

--- End quote ---
The handler takes whatever offset and applies the bit at 0x80 at that memory location.  Note this is a generic handlers that all games in that driver use.
Not that it matters to most people but the memory location of led status for warlords is
AM_RANGE(0x1c03, 0x1c06) AM_WRITE(led_w)

Anyway, an offset of 3 does get set (remember 0 is led 1, 1 is led 2, 2 is led3, and 3 is led4).  But since osd_set_leds only looks at the first three to output to keyoard it gets ignored.

So, someone would just have to put code in osd_set_leds to handle taking the led state and outputting it to the parallel port.  And make sure all the driver set all the leds, some only deal with three even though they have more.  Though it probably would be better if on a per game basis (which can be done with something like ctrlr files) to dictate which pin on the parallel port is going to be used for which led in the game.  And have a command line option to enable the support.   If that happened it might get into mame for the windows port since it would be OS dependant.  Heck, the keyboard leds are OS/keyboard type dependant.  In the windows code for the keyboard leds it needs to know if the keyboard is ps/2 or usb. 


--- Quote ---The biggest thing is the stuff sirp was talking about.  IE the headers required to get inp and outp to work in mingw.

--- End quote ---
Right, in mame source just need precompiler if defines to determine if the port opener is needed or not.  Would have to create an outp function for each platform, powerpc, x86, etc...  The code I found was for x86.  So it would work for any x86 machine no matter what the OS is.

But I am sure the led driver people have figured all this out already.

However, that porttalk might not work.  Well, it will.  Ok, let me explain.
It will definately work if oyu use it to open the ports before running mame.  Though this is the less than ideal solution.  It does provide an interface to use it in code.  However, the question is if mingw supports the functions it uses.  It looks like it just uses CreateFile, which mingw has implemented.  So it could possible work just by adding the the .sys and .c file.
Now, this is what would cause this to not officially be added to mame.  However, it might be possible to look at the source of porttalk and figure out how it is being done, and possibly add that directly in mame and not need the .sys driver.  But that's going to take alot of work and I don;t see it happening :)
Howard_Casto:
Actually, in order to do it right the whole section would have to be completely re-written. 

You see, if we are going to do it right, outputs need to be remappable just like inputs.  If you are wodering why, here's the reason......

Without complicated circuitry, the parallel port only offers 8 outputs.  This isn't enough to dedicate each line to a different type of line.  You see there cna be up to 4 start button lights, up to 4 coin lights, up to six rank lights and i've seen as many as 10 misc lights.  and these are just the games I can thnk of off the top of my head.  Also there's the qbert knocker, the pistons on a rail chaser bench, the recoil in a t2 gun... ect.  Needless to say just letting the driver developer throw out whatever order they want would be just as dangerous. 

So the way we do it is to copy the ctrlr function and use it for output mapping.  And drivers instead of saying "turn on led 1" to set led status would send "turn on start light 1"  or whatever, and the led status would look at the mapping and activate the proper ldata pin. 

This also means that crafty hardware developers could use the remapping to squeeze out some extra pins.  For example they could map misc light 10 to pins 1 and 2 and thus an extra pin is gained since the harware end of things knows that when pins 1 and 2 are both on to activate led 9(depending upon the game code, but that's another story).


Mind you I can't do all this alone, that's why I haven't really attempted it yet, but if we are going to do it, lets do it right.  With such a universal function written, support for serial, usb and other outputs could be added easily later on, similar to back in the day when mame ran in dos mode and the devs had to manually add "drivers" for various joysticks. 
Navigation
Message Index
Next page
Previous page

Go to full version