3 replies to this topic

[SasitornSchneider]

Hi, sorry, 99% this is the wrong place for my questions, but I am somewhat overwhelmed by this Forums.   

I own a Williams Pin Bot machine, and after repairs of mechanical and electronical parts I made copies of my 6 Eproms (27C040-12), for savety reasons and also with the idea to modify the U6 binary, so my Pin Bot would be able to use 4 Balls in Multiball mode, not only 3.

 

If I am right PinMame uses the original binary jb_10r.bin to emulate the behavior of the real Jack Bot machine, right? So altering the jb_10r.bin would e.g. teach VPX Jack Bot and real Jack Bot a 4 Ball Multiball mode (if I am successful). I could test my changes immediately in VPX save environment instead of burning a new Eprom and make a life test. 

 

So now here is my real question: how is the connection done between I/O ports, RAM/ROM addresses... on one hand and  real/virtual switches, solenoids, lamps,.... on the other hand? Somewhere in your scripts/code have to be mapping table with this information for any ROM/Table pair.

 

I am somewhat lost how to find out more about this topic. Can anybody give me a small or big hint where I can get more information about this? Or where would be the right place to ask this? :-)

 

 

[wiesshund]

Hi, sorry, 99% this is the wrong place for my questions, but I am somewhat overwhelmed by this Forums. 

I own a Williams Pin Bot machine, and after repairs of mechanical and electronical parts I made copies of my 6 Eproms (27C040-12), for savety reasons and also with the idea to modify the U6 binary, so my Pin Bot would be able to use 4 Balls in Multiball mode, not only 3.

 

If I am right PinMame uses the original binary jb_10r.bin to emulate the behavior of the real Jack Bot machine, right? So altering the jb_10r.bin would e.g. teach VPX Jack Bot and real Jack Bot a 4 Ball Multiball mode (if I am successful). I could test my changes immediately in VPX save environment instead of burning a new Eprom and make a life test. 

 

So now here is my real question: how is the connection done between I/O ports, RAM/ROM addresses... on one hand and  real/virtual switches, solenoids, lamps,.... on the other hand? Somewhere in your scripts/code have to be mapping table with this information for any ROM/Table pair.

 

I am somewhat lost how to find out more about this topic. Can anybody give me a small or big hint where I can get more information about this? Or where would be the right place to ask this? :-)

 

 

 

I cannot sufficiently answer the VPinMAME part as to how is the ROM mapped out, not the specifics.

 

But as far as how does VPX interact with that
Once the I/O is determined and assigned identities VPX talks to the controller by the identities

 

controller.Switch(10) = 1
Means close switch 10

 

controller.lamp(12)
Means follow the state of lamp 12 (you dont turn lamps on and off the rom does, you just follow with the lamp state

solenoids are another watch and react item
if solenoid is on we do something, if it is off we return the event to the resting state etc
or we only allow a thing to happen if solenoid is on.

 

Gaston could explain how we arrive at determining who is lamp 1 etc in various situations

 

As for your ROM editing
You are only changing a rule, so for the most part, VPinMAME just has to be compiled to recognize the ROM version as valid

A very minor thing.
You may even fly that minor change by, by disabling crc check?

[SasitornSchneider]

 

Hi, sorry, 99% this is the wrong place for my questions, but I am somewhat overwhelmed by this Forums. 

I own a Williams Pin Bot machine, and after repairs of mechanical and electronical parts I made copies of my 6 Eproms (27C040-12), for savety reasons and also with the idea to modify the U6 binary, so my Pin Bot would be able to use 4 Balls in Multiball mode, not only 3.

 

If I am right PinMame uses the original binary jb_10r.bin to emulate the behavior of the real Jack Bot machine, right? So altering the jb_10r.bin would e.g. teach VPX Jack Bot and real Jack Bot a 4 Ball Multiball mode (if I am successful). I could test my changes immediately in VPX save environment instead of burning a new Eprom and make a life test. 

 

So now here is my real question: how is the connection done between I/O ports, RAM/ROM addresses... on one hand and  real/virtual switches, solenoids, lamps,.... on the other hand? Somewhere in your scripts/code have to be mapping table with this information for any ROM/Table pair.

 

I am somewhat lost how to find out more about this topic. Can anybody give me a small or big hint where I can get more information about this? Or where would be the right place to ask this? :-)

 

 

 

I cannot sufficiently answer the VPinMAME part as to how is the ROM mapped out, not the specifics.

 

But as far as how does VPX interact with that
Once the I/O is determined and assigned identities VPX talks to the controller by the identities

 

controller.Switch(10) = 1
Means close switch 10

 

controller.lamp(12)
Means follow the state of lamp 12 (you dont turn lamps on and off the rom does, you just follow with the lamp state

solenoids are another watch and react item
if solenoid is on we do something, if it is off we return the event to the resting state etc
or we only allow a thing to happen if solenoid is on.

 

Gaston could explain how we arrive at determining who is lamp 1 etc in various situations

 

As for your ROM editing
You are only changing a rule, so for the most part, VPinMAME just has to be compiled to recognize the ROM version as valid

A very minor thing.
You may even fly that minor change by, by disabling crc check?

 

Great, thank you, every information helps to get a better understanding.

[SasitornSchneider]

 

Hi, sorry, 99% this is the wrong place for my questions, but I am somewhat overwhelmed by this Forums. 

I own a Williams Pin Bot machine, and after repairs of mechanical and electronical parts I made copies of my 6 Eproms (27C040-12), for savety reasons and also with the idea to modify the U6 binary, so my Pin Bot would be able to use 4 Balls in Multiball mode, not only 3.

 

If I am right PinMame uses the original binary jb_10r.bin to emulate the behavior of the real Jack Bot machine, right? So altering the jb_10r.bin would e.g. teach VPX Jack Bot and real Jack Bot a 4 Ball Multiball mode (if I am successful). I could test my changes immediately in VPX save environment instead of burning a new Eprom and make a life test. 

 

So now here is my real question: how is the connection done between I/O ports, RAM/ROM addresses... on one hand and  real/virtual switches, solenoids, lamps,.... on the other hand? Somewhere in your scripts/code have to be mapping table with this information for any ROM/Table pair.

 

I am somewhat lost how to find out more about this topic. Can anybody give me a small or big hint where I can get more information about this? Or where would be the right place to ask this? :-)

 

 

 

I cannot sufficiently answer the VPinMAME part as to how is the ROM mapped out, not the specifics.

 

But as far as how does VPX interact with that
Once the I/O is determined and assigned identities VPX talks to the controller by the identities

 

controller.Switch(10) = 1
Means close switch 10

 

controller.lamp(12)
Means follow the state of lamp 12 (you dont turn lamps on and off the rom does, you just follow with the lamp state

solenoids are another watch and react item
if solenoid is on we do something, if it is off we return the event to the resting state etc
or we only allow a thing to happen if solenoid is on.

 

Gaston could explain how we arrive at determining who is lamp 1 etc in various situations

 

As for your ROM editing
You are only changing a rule, so for the most part, VPinMAME just has to be compiled to recognize the ROM version as valid

A very minor thing.
You may even fly that minor change by, by disabling crc check?

 

Thanks again, after finding a Debug version of pinmame I am close to understanding the whole process  up to pinmame level.

You are right, VPinMame may only need the new ROM with valid checksum, I will look into that later.