Warlords 4 LED (start button) support

[KrawDaddy]

I am building a Warlords cocktail and have everything worked out except the I-Pac and Mame only support 3 LEDS from the keyboard.  Warlords uses these LEDS perfectly but the forth is not supported.  Is it possible to change the driver for Warlords to output all 4 LEDS (start bottons) to the parallel port and then build an LED driver board?  I currently have a dedicated machine that I am getting measurement from.  I am placing these in a CADD file for everyone.  If I can set the software up I would like to build a website.

Is anyone available to do something like this?

[2600]

There are a couple of projects, software and hardware, but you are a tad early.  You'll have to wait for them to be released.  Then of course for there may be a couple of changes to the source for warlords specifically, I haven't looked at the source.  Others I'm sure will add it or help you, but not till the base software and hardware are around.

Out of curiosity, as I've never seen a real Warlords, what do the leds do?  Are they always on, blink at a constant rate, or ?

Can't wait to see your finished plans and your project once it's done.

[KrawDaddy]

Thanks for the info.  I can complete the project and upgrade the leds then.

the buttons all begin to flash at a contant rate when a coin is inserted.  when the player presses the start button it remains lit.  If there are enough coins the remaining buttons flash until more player join and use up the credits.  right now it works well in mame up until the third player.  If i hook 2 start button leds to the same output the last players button wouldnt flash any longer but would still allow him to start.

Krawdaddy

[Buddabing]

Is it possible to change the driver for Warlords to output all 4 LEDS (start bottons) to the parallel port and then build an LED driver board?

Yes, there are circuit diagrams available for a cheap parallel port hack that will support 8 LEDs.

Here's an example I found for googling "parallel port LED".

You will need to change the driver to support this.

Or you can purchase one of the forthcoming LED driver boards, but I think that will be overkill in your case.

[Howard_Casto]

The hardware definately isn't the issue here.  A "parallel port circuit"  can be as simple as 8 leds wired straight into the data lines of a connector. 

The problem is software.  While you definately can hack in support, atm it would be very "picky."  Some examples of what I am talking about.

Dos Mame:  You'd have to use very very old and very convoluted calls to send a straight binary signal to individual lines.  Strangely enough, this method probably won't work in the windows builds. 

Mame running in 98:  To do it easily you have to use an external dll.  It's a straight shot as far as coding is concerned, but it probably won't work in 2k/xp.  The dll gives the added "bonus" of figuring out if mingw and it's odd, dos-like compatability will accept the dll.  I think par-io.dll has been confirmed to work by the pinmame guys.   

Mame running in 2k/xp:  See above.  You can use the same dll but there are limitations.  For one the leds are stuck in the "on" position until a program changes them.  This would be ok for your application but a real bother if you were to install a rumble motor or a knocker.  Also an additional dll/app would be required to open the port's permissions because xp is security crazy about that stuff.  (Why?  When's the last time you heard of someone being hacked by a parallel connection?)


Things are being worked on, but atm, there isn't an easy two or three lines of code you can change. 

[SirPoonga]

What HowardC said is not 100% accurate.

In dos it is supper easy, outp(), inp() are the functions.
98 exact same code, no dll.  You get direct access to the ports.
In any NT based OS (WinNT, Win2k, WinXP, etc...) as a programmer you don't have direct access to the ports unless you use a special dll (which, if you are picky, creates a security hole).

To get them to go on an off in mame is easy, it's built into the driver.  The LEDs flash because the ROM told them to.  It controlled when they went on and off.  On those events is where you put the code in the driver.

To adjust what HowardC said, there is no easy way crossplatform in a couple lines of code to do this.  You can do it in a couple lines of code that is specific to an OS.

[KrawDaddy]

What HowardC said is not 100% accurate.

In dos it is supper easy, outp(), inp() are the functions.
98 exact same code, no dll.

[Howard_Casto]

What HowardC said is not 100% accurate.

In dos it is supper easy, outp(), inp() are the functions.
98 exact same code, no dll.

[Buddabing]

What HowardC said is not 100% accurate.

In dos it is supper easy, outp(), inp() are the functions.
98 exact same code, no dll.

[SirPoonga]

What HowardC said is not 100% accurate.

In dos it is supper easy, outp(), inp() are the functions.
98 exact same code, no dll.  You get direct access to the ports.
In any NT based OS (WinNT, Win2k, WinXP, etc...) as a programmer you don't have direct access to the ports unless you use a special dll (which, if you are picky, creates a security hole).

To get them to go on an off in mame is easy, it's built into the driver.  The LEDs flash because the ROM told them to.  It controlled when they went on and off.  On those events is where you put the code in the driver.

To adjust what HowardC said, there is no easy way crossplatform in a couple lines of code to do this.  You can do it in a couple lines of code that is specific to an OS.

Have you actually tested those method though?  Last time I tried they kinda didn't work.

Yeah, have a direct port open source program for slot car race timing that interfaces with parallel port via outp and inp, in 98.

[Howard_Casto]

cool.... could you send it over to me?

I might be willing to write a generic i/o funciton for the parallel port into mame if someone else were to take it the extra mile and start modifying the individual drivers. 

[SirPoonga]

Man, I have to find the cd I burned it too.... that could take awhile.

Anyway, it just used standard outp() function calls.  In VB you have to use the dll.  But mame uses C.  Is there a version of mame that uses the parallel port for something, I thought there was.  I'm not sure how to make mingw compiler see outp() for windows. I don't see outp implemented for mingw

Found a C++ example
http://www.logix4u.net/parallelport1.htm
Note the note at bottom, it should work with 98.
But  yeah, if you want to use direct access in nt based you need a dll.


Neat, found VB code from microsoft!
http://support.microsoft.com/kb/q154078/
The kb article doesn't say if it will work with what OS.
But the article was written in 2004.

Edit: Nevermind on the kb article, read all the way through the article.  It doesn't give you DIRECT direct access as you can't control individual data pins


Tons of info here
http://www.lvr.com/parport.htm


Edit:
outp would be in conio.h for whatever compiler.
MingW's conio.h does not have it.
conio.h in \Microsoft Visual Studio .NET 2003\Vc7\include doesn't
conio.h in \Microsoft Visual Studio .NET 2003\Vc7\crt\src does
conio.h in \Microsoft Visual Studio\VC98\Include does

But that's just  aheader file, need to know which lib it is implemented in to see if I cna use that outp().

[SirPoonga]

I might be able to access the port directly using assembly.
Found this mingw sample
http://my.execpc.com/~geezer/osd/pnp/pnp.c

I will have to see if I have some LEDs laying around.  However, I don't know if this will work with xp as I don't have 98 installed anywhere.

Edit:
Shhhh, downloaded mingw at work and tried compiling.  It compiled, have no way of testing it though
When I get home I will put it in the centiped.c driver (which is where warlords is). 
Shhh again, slow day at work   Downloaded mame source.

-----------------------------------------------------
Exception at EIP=01591ED7: PRIVILEGED INSTRUCTION
-----------------------------------------------------
EAX=00000008 EBX=00000008 ECX=77C418BF EDX=00000378
ESI=00000003 EDI=0000012E EBP=0022EC30 ESP=0022EBC0

So yeah, it's privileged.  Need the dll.  Not sure how to do dlls in mingw.


How is one of those LED drivers accessing the parallel port?

[2600]

Hence the reason I said wait till the HW and SW for those is done. Don't think the SW is currently released, and there is no reason to reinvent the wheel. 

That being said from my understanding, Buddabing is using the same dll as Daphne.  You could take a quick glance how Daphne is using it.  I think PinMAME-HW is using the same dll as well, but don' t quote me on that.

[Howard_Casto]

Yeah... the problem with that dll is, since it's windows specific, the mame devs won't accept any code that uses it afaik.  This needs to get in an official build of mame.  (Newer games tend to use i/o more than older ones, so a consistantly updated build is required.)  The low level inp / outp that sirp is suggesting, along with an optional "port opener" for 2k/xp is the preferred solution.  I beleive it even works in linux and mac os.  (Initilization is sketchy but other than that.)

There used to be a tsr that ran in xp which you told it the exe name, and what port you needed opened, and it told xp to give the app permissions.  I don't remember the name though.  Anyone know?

[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]

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.

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)

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

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. 

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

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. 

[SirPoonga]

howard, right, you expanded on what I said.
"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. "

Again, wait until the LED stuff is out.
You could get mor than 8 from a parallel port.  There's control pins that can be set.
If you make a simple PIC circuit and use the ctrl pins like a shift you can create more TTL level outputs.

[Buddabing]

No need to reinvent the wheel. Gl.tter has already worked all this out in his Light Signal Engine.

[SirPoonga]

No need to reinvent the wheel. Gl.tter has already worked all this out in his Light Signal Engine.

Right, isn't he just working on a way to signal to the LEDS.  IE a software interface to the leds?

How mame is going to do it needs to be figured out to.  Like I said, best thing to so is probably write an add-in that works in the osd_set_leds that detects the game, looks up something like the ctrlr files but define what led does what, and use glitter's stuff to actually light the led.

[Howard_Casto]

Well the thing is....  the only reason to use the parallel port over the serial or usb ports is the cost factor.  Using the straight data pins the cost is about 3 bucks tops.  The more complicated the circuit, the greater the cost. 

I for one would rather spend all my money on super bright leds and solenoids/relays rather than a 50 dollars for an "ipac-like" interface board.   Although there are definately more than 8 possible output costants, I seriously doubt that any one game (or one mame cab)  uses more than 8 controllable outputs.  Plus you still have the keyboard leds if you are a glutton for punishment, so that's 11.

[Buddabing]

Well the thing is....

[DarkKobold]

Actually, at CAX this year, a guy had a presentation on restoring his Professor Pacmame machine. If I can find it, I'll get his contact info. PM me so I remember.

[KrawDaddy]

Any thoughts....

[KrawDaddy]

Bump...

[SirPoonga]

yes, wait until led driver board stuff comes out.

[KrawDaddy]

Just wondering if there are any options out there for the support of the 4th LED yet?

_KrawDaddy

[Howard_Casto]

I haven't had time. 

I really wish someone would do this for me, and by "do this" I mean do it properly.

This is how mame should be modified. 

Step1:

Remove any and all references to the numlock/scrolllock/capslock still left in the individual drivers and reroute those calls to a led-controlling function.  (I beleive this is already done. 

Step2:

Instead of drivers passing "turn on capslock" modify them to a more generic "turn on virtual output #1"

Step3:

The led status function needs to be modified to allow more methods of output... the easiest being the "cheap" parallel port  method.  Also adding in support for randy's new interface and any others that are to become a standard. 

Step4:

Look at the code mame uses to read in ctrlr files and copy it, only this time make it an output file.

This file should have the following "virtual outputs":

CoinLight1
CoinLight2
CoinLight3
CoinLight4

Light1
Light2
Light3
Light4
Light5
Light6
Light7
Light8
Light9
Light10

Solenoid1
Solenoid2
Solenoid3
Solenoid4
Solenoid5
Solenoid6
Solenoid7
Solenoid8
Solenoid9
Solenoid10

Motor1
Motor2
Motor3
Motor4
Motor5
Motor6
Motor7
Motor8
Motor9
Motor10

Misc1
Misc2
Misc3
Misc4
Misc5
Misc6
Misc7
Misc8
Misc9
Misc10

Of course which driver uses which types of inputs is pretty self-explainatory.

Virtual outputs are useless without the proper "real life" outputs to bind them to.

Initially I suggest the following constants:

CapsLock
NumLock
ScrollLock

Parallel1
Parallel2
Parallel3
Parallel4
Parallel5
Parallel6
Parallel7
Parallel8

LedWhiz1
(there's no way I'm listing all 50 inputs)

Also including any other input methods available. 

For windows I would also suggest The force feedback motors, which have a specific usb name I don't know of off hand. 


Final Step:

Bring everything together.  Drivers would now send the proper virtual output type to the led function (in most cases coin1 coin2, ect..)  the modified ctrlr files woudl have already binded said constant to a real output and thus the led function would manipulate the proper device.


This is a lot of coding sure, but if done this way, when a new fangled light driver like randy's pops up, support in mame can be added literally in a day or so. 

I know how to do the modifications in sheer logic, but in all honesty my C skills aren't up to the chllenge of dong so many code changes to the core.  I however would be willing to help someone else, as I know how to write most of the input/output functions in a way mingw can handle.