I keep adding a little bit more and a little bit more, and now it shows the "outlaw" as a block that moves and shoots (the flickering square). For some reason, the rom isn't reading properly yet to get the proper outlaw picture. I do like the smooth motion of the block.
Super exciting, I know... 8-)
It kinda baffled me how the lightgun worked, but after watching a video of outlaw you can see the whole screen flash when the trigger is pressed. I still have to hook up the FLASH.
My strategy is to add a section of the circuit at a time and "alias" the parts that aren't actually hooked up since it's easier to get it compiling and running that way. It's so easy to make typos and since netlist exits after a single error, you have to fix, compile, and run for each one.
My favorite error is when I invert the order of ALIASES, putting the second part first. I seem to do that a lot.
As it gets properly hooked up, I comment out the aliases, usually after netlist says "you've already defined that."
Kept looking at why I wasn't getting any images out of the rom.
I copied JD's MK28000 function and made a SIGNETICS_8205 512 byte rom, and changed a bunch of stuff around. For the tristate outputs I changed the variable names and the logic around, but didn't update the variable that controls the tristate output, so it was never outputting any data.
For some reason, netlist hates a tristate output that isn't connected to anything (actually it is connected to 74194 shift registers):
Netlist CPU Device device 'maincpu': netlist ERROR: Tristate output J4.O8 on device J4 is not connected to a proxy. You need to set parameter FORCE_TRISTATE_LOGIC for device J4 if tristate enable inputs are all connected to fixed inputs. If this is not the case: Review your netlist. Something is wrong.
My workaround is to hook it to a "dummy" resistor with high resistance connected to ground or 5v. That seemed to quiet the errors.
I'm glad that I initially connected the dummy resistor to GND instead of 5V, because without the tristate rom working I could see a black rectangular block where the graphics data should be. Changing that to 5v made the rectangular block invisible.
Hooked up a trigger, now you can see gun flashes and an explosion. The explosion appears in the same spot in the upper left since I'm just hooking the GUNOUTPUT to the trigger for testing. Now I've gotta figure out how PORT_CROSSHAIR inputs work, so I'm studying operation wolf.
Adding the logic for the start button and this seems to have sped up the action clock for the outlaw.
Here's a video of shooting the outlaw a couple of times, with a little bit of tweaking it should be able to make it track the crosshairs more closely (I see that I should probably have divided m_gunx by 908 instead of 800):
One thing that's been perplexing me is why the number of clocks changes from line to line, and what I've found is that if you have a 7493 connected to another 7493, the second 7493 won't actually respond to a change in the first 7493's high bit output until the next clock cycle.
It led me to experiment with trying different cpu clocks, multiples of 14.318e6 being most visually appealing:
/ PORT ADJUSTER 16 BIT MASK since default mask is 0xff, not big enough for a MINMAX of (1,10000)
#define PORT_ADJUSTER_FFFF(_default, _name) \
configurer.field_alloc(IPT_ADJUSTER, (_default), 0xffff, (_name)); \
PORT_ADJUSTER_FFFF( 100, "CPU Scale Adjustment" ) PORT_MINMAX(1, 10000) PORT_CHANGED_MEMBER(DEVICE_SELF, outlaw_state, set_clock, 0)
m_maincpu->set_unscaled_clock_int(ioport("CPUSCALE")->read() / 100.0 * 14.318e6);
machine().popmessage("Clock Scale = %f clock= %f",ioport("CPUSCALE")->read() / 100.0, m_maincpu->clock());
Sometimes it seems like the higher the clock, the more visual artifacts.
Looks very pixelated at a .25 scale:
going slightly over the even multiple seems to cause "ghosting":
I could also use the -cheat parameter which enables the overclock slider and allows me to set an over/underclock up to 400% but I wanted to go higher than that, do PORT_MINMAX(1, 10000) for up to a 100x multiple.