Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

The place for all discussion on gaming hardware
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

I think I'm getting a clearer picture now over all the complexity involved. Thanks for the explanation. :)

Changing the 7002 registers on the fly should be possible via debug build & UART. Though I don't know if a small change to the firmware would be a precondition, most certainly yes (also possibly jettison some functionality for more code space).
I may actually try that and see how far I can get (though I may ask for advice at some point). If somebody else wants to try as well, feel free to say so, so we can avoid redundant work.
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by rama »

What a coincidence. Doesn't this first Rigol capture look familiar?
https://www.hdretrovision.com/blog/2019 ... ling-short

(Just noticed they have this update to the CSync series out :) The first part is great as well!)
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

rama wrote:Can the 7002 flip the CSync decoder polarity (so it triggers on rising edge) + flip the decoded HS polarity that goes into the H-PLL?
If so, doing that and fiddling with coast + HS runt pulse ignore values (and possibly Macrovision protection) could fix the problem.
It might accept inverted csync (as it supports both hsync polarities), but I don't think it could completely fix the underlying issue of uneven line length. As with my proposal 1, the resulting pixel clock would be still more or less jittery at the start of the frame so only some displays would accept the generated HDMI signal. I'd prefer testing suggestion 2 first, or even try hooking cps2_digiav board on Toaplan which could be able to create perfectly stable digital signal.

According to my arcade PCB testing notes (from 2015) Batraider and Pipi & Bibis worked ok with OSSC so the issue seems to be limited to certain Toaplan V2 games only (Dogyuun, Batsugun, Fixeight, V-Five have been mentioned).
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by rama »

marqs:
Yes, the uneven line length is peculiar.
It's so weird that I wonder if the capture shows what's happening correctly.
Wouldn't a regular (arcade) TV / monitor have problems with this as well?

If it's really doing that though, then a pure software solution will indeed be difficult...
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

rama wrote:What a coincidence. Doesn't this first Rigol capture look familiar?
https://www.hdretrovision.com/blog/2019 ... ling-short

(Just noticed they have this update to the CSync series out :) The first part is great as well!)
Actually thanks a lot for linking this article :shock: Very helpful for getting a grasp on this stuff.

The Master System quirk is one of the things the gscartsw's sync regeneration feature can fix. But it doesn't help in this case (see my first post in this thread) ...
rama wrote:Wouldn't a regular (arcade) TV / monitor have problems with this as well?
For what it's worth, the image is displayed completely fine on my PVM 2053MD - I know these are very tolerant.
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

rama wrote:marqs:
Yes, the uneven line length is peculiar.
It's so weird that I wonder if the capture shows what's happening correctly.
Wouldn't a regular (arcade) TV / monitor have problems with this as well?
That's not really a problem for CRT.
rama wrote:If it's really doing that though, then a pure software solution will indeed be difficult...
Both 6t8k's line length measurements (64us and 324us) seem to be performed with 1GSa/s sampling rate so it doesn't look like a measurement error. It might still be worth double-checking that 324us by zooming in and counting X tick marks (while panning) as I recall some cursor-based time extraction accuracy problems with Rigol scopes.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Now I've zoomed in to H=200ns and just took note of the horizontal position gauge (D=xxx) when measuring p1-5. Don't know why I didn't arrive at that method earlier. Easier and much more precise. Guess that's your scope greenhorn here.

1.609848ms - 1.284824ms = 325.024μs

64.0μs was exactly correct for the others.
Spoiler
Falling edge of Vsync:

Image

Next falling edge:

Image
Last edited by 6t8k on Tue Nov 12, 2019 9:57 pm, edited 1 time in total.
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

marqs wrote:According to my arcade PCB testing notes (from 2015) Batraider and Pipi & Bibis worked ok with OSSC so the issue seems to be limited to certain Toaplan V2 games only (Dogyuun, Batsugun, Fixeight, V-Five have been mentioned).
I just checked some Toaplan PCB photos here and they seem to use 5-bit R2R DAC for RGB lines which would make it possible to hook up on cps2_digiav:
Spoiler
Image
I also traced c-sync back to SN74LS08N (quad-AND) on Fixeight and V-V boards which is likely to have hsync on some pin. Measuring that should confirm if there indeed is variance on line length.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

^ That's awesome news!

Man this thread is ALIVE now :lol:

Will try finding and measuring that HSYNC line tomorrow.
User avatar
mikejmoffitt
Posts: 629
Joined: Fri Jan 08, 2016 7:26 am
Location: Tokyo, Japan

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by mikejmoffitt »

Just about every '90s STG uses 5bpc RGB with a discrete DAC, so digitizing them should be trivial.

The Hsync and Vsync signals are available from the GP9001.
Image
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

I've measured all pins of the SN74LS08N now, and I think we can see some interesting things here.

The predicted variation in Hsync is there. Or is is more like a glitch? This must also cause the spike after the Vsync falling edge visible in the earlier screenshots.
The SN74LS08N then expectedly creates a bad Csync out of that and Vsync. It looks to me like the source of the problem lies in the proprietary logic of the GP9001?
You can see that Vsync at SN74LS08N is shifted by our familiar 5μs in comparison to final Csync output.

(Now I realize it could be a good idea to record Hsync and Vsync on one screenshot for direct comparison and retracing the quad-AND)

Pin 8: csync (looks almost identical to csync output from jamma)
Pin 9: vsync
Pin 10: hsync

Screenshots:
(Channel 1 is always Csync from jamma out, channel 2 is SN74LS08N pin)
Spoiler
Pin 10 Hsync glitch and closer look:

ImageImage

Pin 10 Hsync glitch periods:

ImageImage

Pin 9 Vsync offset:

Image
What I'm asking myself now is, as I'm not that familiar with the cps2_digiav yet, would it be able to cobble together a proper clock rate from that, i.e. what sets it apart from the OSSC here?
Last edited by 6t8k on Wed Nov 13, 2019 10:10 pm, edited 2 times in total.
User avatar
mikejmoffitt
Posts: 629
Joined: Fri Jan 08, 2016 7:26 am
Location: Tokyo, Japan

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by mikejmoffitt »

That might have something to do with the GP9001 acting in tandem with another, but that wouldn't apply to Fixeight or V-V.

H-Sync and V-sync come out of pins 206 and 207 of the GP9001, respectively. I believe Hblank comes out of pin 208 as well. Do the signals look weird there, too?
Image
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Yeah, these are still V-V measurements.

Do you have advice on how to properly connect to a GP9001? These pins are tiny :o It would simply be impossible with the probe I'm using.
User avatar
mikejmoffitt
Posts: 629
Joined: Fri Jan 08, 2016 7:26 am
Location: Tokyo, Japan

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by mikejmoffitt »

Some 30AWG or finer fly wires would do it, or you can follow the traces to see what is immediately connected to it.
Image
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Will see what I can do about it.

Removed superfluous info from above post to stay focused (the other pins are just noisy DC at various levels, i.e. unused).
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by rama »

That HSync is really bad, yeah.
Since they seem to double one HSync, and never correct for it, both signal flanks are skewed.

I suppose a hardware modification really is the best (maybe only) solution to that.
A sync processor with PLL would have to recover 5uS skew otherwise, and that's probably just too much.
Macrovision protection and coast are useless for this as well :/
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

I've traced GP9001 pins 205,206,207,208 to the directly adjacent chips/pins and connected the probe there.
Measured plain 5V on 208 then dug up some documentation.

According to this (page 4-4), if I interpret these abbreviations correctly, these should be the relevant GP9001 pins:
205 = Vsync
206 = Hsync
207 = Hblank

Traced these to:
205 -> U41 (SN74LS244N) pin 3.
206 -> U41 (SN74LS244N) pin 15
207 -> U36 (SN74LS374N) pin 3

Used the photos marqs linked because it's much easier that way.

But I don't trust myself about that 100% and would be glad if a second pair of eyes could reproduce that,
primarily because the three signals don't look at all like I would have expected.

Only U36 pin 3 looks similar to Hsync (the pulses line up with the Hsync component of jamma Csync out). But what about that big "gap", extending even beyond Vsync before it and afterwards?
I have no clue about the two other ones currently...
Spoiler
U36 pin 3

Image

U41 pin 15

Image

U41 pin 3

Image
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

6t8k wrote:What I'm asking myself now is, as I'm not that familiar with the cps2_digiav yet, would it be able to cobble together a proper clock rate from that, i.e. what sets it apart from the OSSC here?
Unlike OSSC, cps2_digiav's output doesn't need to be line-locked (while still being framelocked) thanks to precise PLL and additional line buffers. Basically you feed arcade PCB's master/video clock into the PLL's reference, and get out suitable pixel clock for 1080p or another output resolution. The number of anomalities in hsync doesn't matter as long as frame time is constant.
6t8k wrote:Only U36 pin 3 looks similar to Hsync (the pulses line up with the Hsync component of jamma Csync out). But what about that big "gap", extending even beyond Vsync before it and afterwards?
That looks more like a combination of vblank and hblank, i.e. an enable signal.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

^ thanks for the clarifications marqs!

So I found the missing two V-V signals, simply by measuring all U36 pins, my previous tracing was mistaken. In the end you just can't see if the lines change angle below a chip without desoldering it.

Correct is:
205 (Vsync) -> U36 pin 17
206 (Hsync) -> U36 pin 18
207 was already correct then I suppose? (carrying both V- and Hblank)

And as we can see, if we look at U36 pin 18, the bad Hsync pulse is there, showing that the signal the GP9001 puts out is already busted:
Spoiler
Image
However, as RGB helpfully remarked earlier, Tatsujin Oh works fine with the OSSC. Tried it, and indeed, it does.
But why is that - Tatsujin Oh as well uses a single GP9001. Then Hsync must be bad there too, right? Wrong.

Let's look at Jamma Csync output first:
Spoiler
Image
And indeed, accumulated sync and first backporch line lengths (p1-5) do equal to 5 times normal line length (5*64=320) :)
Is the error caused by something different, or - it has that characteristic spike - does it miraculously get "corrected" somewhere in the path between the GP9001 and Jamma out?
Here are the relevant adjacent pins for easier measurement:

205 (Vsync) -> U81 (SN74LS08N) pin 1
206 (Hsync) -> U81 pin 2 (or single via directly between GP9001 and U81)
207 (blank) -> couldn't identify it definitely, at least found nothing that looks like V-V's U36 pin 3.

And, here is Hsync:
Spoiler
Image
Tatsujin Oh's GP9001 doesn't have the problem :o
It looks like there are variants of the chip which differ in behavior.

For what it's worth, the imprints on mine are:
Spoiler
Tatsujin Oh:
L7A0498
GP9001
TOA PLAN
9044

V-V:
Only the number in the last line is different: 9150
V-V came after Tatsujin Oh, so one would expect that normally, if anything, bugs like that get fixed. Here on the other hand, it seems like a bug was newly introduced. I guess they simply didn't notice it back then, because they naturally only tested on CRTs.

So I think this shows that the problem lies indeed within the GP9001 (but it appears to be only (a) specific revision(s) of the chip), and that an easy solution is likely out of reach, as was already pointed out.
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

6t8k wrote:So I think this shows that the problem lies indeed within the GP9001 (but it appears to be only (a) specific revision(s) of the chip), and that an easy solution is likely out of reach, as was already pointed out.
Are you sure it's the chip revision and not the way it's connected or controlled? For example, the overall schematic from Knuckle Bash document shows SEL-VCOUNT signal driven by 68k through 74LS138 demux that seems to enable outputting line count to data bus (which may occur at different time depending on game and thus possibly affect sync generation).
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Thanks for the vigilant scrutiny, I was not aware of that! (at one point Mike even hinted at such a possibility)

For Tatsujin Oh, I've measured U64 (SN74LS138N) pin 5 (which is shown here), which I confirmed is conducting the same signal as pin 6 on the 68k:
Spoiler
Image
Image
Moving on to pin 7 on U64, which should be outputting said SEL-VCOUNT signal.
There, activity only occurs around Vsync, as is shown on the screenshots:
Spoiler
Image
Image
Looking at the second image, I might be seeing 8 bytes, with values in decimal: 7, then 255 seven times thereafter. Might 7+255 be V_ACTIVE (line count), which is indeed 262 for Toaplan2, or am I seeing a fata morgana? :)

Before looking at the same signal on V-V, if possible I'd appreciate a quick second opinion if I'm looking at the right thing at all or not.

Update: on V-V, pin 6 of the 68k is connected to U64 pin 10, which is a SN74LS20N (dual 4-input positive NAND). The corresponding output pin 8 is always low. SEL-VCOUNT, assuming it exists on V-V, might function in a different way there. If above is not completely wrong, it might just come down to luck that Knuckle Bash schematics are transferable to Tatsujin Oh like that. Unfortunately, I can't find similar schematics for V-V (or another Toaplan2 game, for that matter).
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

I've tested Mahou Daisakusen - it works fine with the OSSC.
Most notably, my exemplar has '9150' as the last line of the GP9001 imprint, just like V-V.
So if that's anything to go by in terms of revision/batch number, it was probably a red herring I admittedly jumped too quickly to (this hardware-y stuff is actually not my métier, you see Image - all the better that I have helping hands here).

For what it's worth / to think it through, there would of course be one definitive and relatively easy way to see if it's different GP9001 revisions or not: swapping the GP9001 of a game which has the problem, with the GP9001 of a game that doesn't (or vice-versa) [A].
This wouldn't even have to be done explicitly for this purpose; I'm sure there are many people out there who had their GP9001 replaced for repair purposes.
One person owning a PCB for which [A] holds true would have to be contacted (a starting point for this could be repair logs (e.g. this would suit)), and politely asked to do one of the following things:
- Test if their PCB works on the OSSC
- Or, Inspect the Vsync area of JAMMA Csync out under an oscilloscope

It's for science ;D
So, assuming the GP9001 is ruled out, the cause must be in the game ROMs then, in the way how they drive the GP9001?

By the way, there's a whole "Vertical Line Counter" diagram on page 4-6 in the Knuckle Bash schematics, which should be interesting as well, but I'm still struggling to extract any info out of it that would perhaps take us further here.

Here's a quick overview on which Toaplan2 games the OSSC has problems with, and which are fine, from the info gathered here so far:
Spoiler
incompatible:
- Batsugun
- Dogyuun
- Fixeight
- V-V / Grind Stormer

compatible:
- Armed Police Batrider
- Battle Bakraid
- Battle Garegga
- Mahou Daisakusen / Sorcer Striker
- Tatsujin Oh / Truxton II
- Whoopee!! / Pipi & Bibis

unknown:
- Ghox
- Knuckle Bash
- Otenki Paradise / Snow Bros. 2
- Shippu Mahou Daisakusen / Kingdom Grandprix
- Teki Paki
Last edited by 6t8k on Tue Nov 19, 2019 11:02 am, edited 3 times in total.
thchardcore
Posts: 481
Joined: Wed Jun 22, 2005 9:20 am
Location: Liberal cesspool

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by thchardcore »

I can comment that both Garegga and Bakraid work without issue on my Micomosft units and the OSSC.
Last edited by thchardcore on Tue Nov 19, 2019 8:51 am, edited 1 time in total.
A camel is a horse designed by a committee
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

Batrider and Pipi & Bibis worked ok too when I tested them a few years ago.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Thanks, all four noted accordingly.
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by Xyga »

I'll bet Kingdom is okay and Ghox isn't. :p
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
mikejmoffitt
Posts: 629
Joined: Fri Jan 08, 2016 7:26 am
Location: Tokyo, Japan

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by mikejmoffitt »

I do have a Ghox on loan and can try it.
Image
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Image

I'm not not sure yet what the chances of success (even partial) are - I'm definitely preferring a clean solution if nothing else helps, which includes hardware modification.
Using the cps2_digiav would certainly be awesome and I'll be there supporting it, but I'd still like to explore this route and see what's possible (or not).
Doesn't hurt to check if we could have more options :)
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

6t8k wrote:I'm not not sure yet what the chances of success (even partial) are - I'm definitely preferring a clean solution if nothing else helps, which includes hardware modification.
Using the cps2_digiav would certainly be awesome and I'll be there supporting it, but I'd still like to explore this route and see what's possible (or not).
Doesn't hurt to check if we could have more options :)
Yes, it'd be great if there's a solution that doesn't require modifying the HW, even if that'd be compatible with limited number of displays.

Toaplan's sound circuitry (at least Knuckle Bash) seems to be very close to CPS1 so cps2_digiav plus recent cps1_adapter should be directly compatible with just a few code changes. I'll have to check if I can get any of those 4 problematic boards at a decent price. Some members have also offered to borrow their boards for testing, but shipping back from here would cost quite a lot so it probably makes more sense for me to acquire own board.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Yeah, I think having these run on the OSSC would be a considerable benefit. There might be alternatives (although scalers do not replace the OSSC's feature set), but in light of the Framemeister for example, whose production came to an end this June, one can certainly hope that the OSSC, being open source in both software and hardware design, will stay available and be further refined for a longer period of time. As a consequence it'll probably stay relatively affordable too.

About cps2_digiav: that sounds very nice! Well I'm quite sure shipping would be cheaper, but they're excellent games so can't blame ya Image

In other news, I have implemented a very rudimentary interface for sending "commands" to the OSSC via UART/nios2-terminal.
For being indeed my first time working on an FPGA, it was quite a smooth ride until now, much owing to the succinct readme.
I've pushed the branch here, suggestions, in prose or in the form of a merge request, are always welcome!

I wanted to read nonblockingly from stdin, but didn't succeed just yet, so I used an ugly workaround which works for now, but is one shortcoming I can think of.
In principle everything is testable on-the-fly now, so we can be adventurous now - feel free to post ideas on what to try :D

Some things I've already tried without success (i.e. no change or worse image):
- setting H-PLL pre/postcoast to 10 lines and above
- increasing the Macrovision window
Post Reply