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):
Quote
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.
Wanted to see if he could run left and right so I setup a clock to flip the direction every 10 seconds since actionreset isn't working for some reason.
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.
One thing that's kind of odd is that the horizontal clocks alternate between 908 and 907. Strange, but it shouldn't be a problem.
Code
HSYNC LINECOUNTER=259 DATA=0.100000 TIME = 2.109106 ELAPSED=0.00006341668 CLOCKS=908.000000
HSYNC LINECOUNTER=260 DATA=0.100000 TIME = 2.109170 ELAPSED=0.00006334684 CLOCKS=907.000000
HSYNC LINECOUNTER=261 DATA=0.100000 TIME = 2.109233 ELAPSED=0.00006341668 CLOCKS=908.000000
HSYNC LINECOUNTER=262 DATA=0.100000 TIME = 2.109296 ELAPSED=0.00006334684 CLOCKS=907.000000
VSYNC TIME = 2.109353 ELAPSED=0.01660518229
NUMBER OF LINES = 0.016605182, 0.000063347, 262.131201763
IOPORT=(83ff,2300)
HSYNC LINECOUNTER=1 DATA=0.100000 TIME = 2.109360 ELAPSED=0.00006341668 CLOCKS=908.000000
So it's pretty easy to get the crosshair position and translate it to a x and y coordinate.
Then I'll set up a timer to do a m_guninput->write(gunvalue); to set the gun value at the correct time when the gun is sweeping at the appropriate x and y.
outlaw_state(const machine_config &mconfig, device_type type, const char *tag)
: driver_device(mconfig, type, tag)
, m_maincpu(*this, "maincpu")
, m_video(*this, "fixfreq")
, m_guninput(*this, "maincpu:guninput") // input device with tag
{
}
void outlaw_state::outlaw(machine_config &config)
{
NETLIST_CPU(config, m_maincpu, OUTLAW_VIDCLOCK).set_source(netlist_outlaw);
NETLIST_ANALOG_OUTPUT(config, "maincpu:vid0", 0).set_params("VIDEO_OUT", "fixfreq", FUNC(fixedfreq_device::update_composite_monochrome));
NETLIST_ANALOG_INPUT(config, m_guninput, "GUNINPUT.IN"); // input device writing to the .IN
// NETLIST_ANALOG_INPUT(config, "maincpu:guninput", "GUNINPUT.IN"); // input device writing to the .IN (either one should work)
then in the nl_outlaw.cpp file:
Code
ANALOG_INPUT(GUNINPUT, 0)
and testing it out by writing values to it and reading those values with a NLAO (netlist analog output) to see if it indeed works.
Code
DEBUGNLAO(guninputread, GUNINPUT) // note I called it guninputread so it wouldn't conflict with the maincpu:guninput tag
If I put this code in to set the gun input depending on the position of the light gun x coordinate (just as a test to see if I'm actually changing the input):
VSYNC TIME = 0.548470 ELAPSED=0.01660511245
NUMBER OF LINES = 0.016605112, 0.000063417, 261.841409691
IOPORT=(5140,8bff)
UPDATE guninputread: 0.548470 guninputread= 1.586914 delta=0.016605 delta2=0.033210
=================
One thing I found is that you can only have a single "outlet" hooked up to a NLAO. So the VIDEO_OUT gets connected to fixfreq, so how to "snoop" on it?
After much fiddling around, I was able to get the crosshairs and explosion to sometimes track together. I wanted to use the video device's time_until_pos but couldn't get it work quite right.
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:
Code
/ 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)); \
configurer.field_set_min_max(0, 100);
PORT_START("CPUSCALE")
PORT_ADJUSTER_FFFF( 100, "CPU Scale Adjustment" ) PORT_MINMAX(1, 10000) PORT_CHANGED_MEMBER(DEVICE_SELF, outlaw_state, set_clock, 0)
INPUT_CHANGED_MEMBER(set_clock) {
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.
![[Linked Image from i.imgur.com]](https://i.imgur.com/FZ73Dt4.png)
![[Linked Image from i.imgur.com]](https://i.imgur.com/qw7bndV.png)
![[Linked Image from i.imgur.com]](https://i.imgur.com/WhFIYvA.png)
![[Linked Image from i.imgur.com]](https://i.imgur.com/XX5JnCW.png)
