shmups.system11.org

IMO it should be addressed externally.

Consequentially updated my previous post with more screenshots. I actually noticed what might be another problem factor.

My Batsugun arrives soon, while my Dogyuun is no longer in my possession. I can look at the sync signals shortly after.

What sets Batsugn and Dogyuun apart is that they have two GP9001s working in tandem. I do not know how they are synchronized; they could be in lockstep, or a register could let one GP9001 accept sync pulses from another instead of generating its own. I do know from some conversion experiments that Dogyuun and Batsugun have different mixing and synchronization.

Apologies for not replying to your last post, but I didn't see where you called out the VP50 pro specifically as the only solution. In fact, you seemed to steer me back towards the XRGB-2, which doesn't fix this issue entirely. My intent was not to be impolite, so sorry if you took it that way. However, the rest if your commentary is not needed. Let's leave it at that.



Interesting. Happy to loan Fixeight and V-V to check if they follow the same format on sync generation.

Next time just be attitude for gains.

Both have only one GP9001 VDP each:
MAME: [1] [2] compare e.g Dogyuun: [3]
PCBs: [4] (square chip at center right, below "TP-027") [5] (chip of same appearance), compare Dogyuun: [6]

That's an interesting aspect - will put V-V on the scope tomorrow for comparison.

Any game with just one GP9001 should be pretty "normal" as far as sync is concerned - ending with Battle Bakraid. However, I don't know if the CRTC is configurable, to change the number of vertical lines (and refresh rate) or the sync pulse length, etc.

That looks like there is significant variation on hsync period at some of the first scanlines. If the accumulated variation (by the time the period stabilizes) is near-zero, then OSSC might be able to lock to the signal if H-PLL post-coast and Hsync tolerance are adjusted suitably. The coast setting could need higher adjustment range than what is currently allowed by fw (5 lines), though.

just to put the picture is relation: a PC Engine looked the same on the XRGBs without heavy AFC adjustment.

I've seen a lot of pcb's doing that, most not mine tho, too bad I never took notes.

I gave up doubling/scaling arcade boards maybe around 2013 because there were too many issues.
Approximately the same time I got a VP50 Pro which seemed to be the best machine for that and the end of my quest...
...but then pcb prices were beginning to go absolutely crazy and I quit buying them, lacked time for going to meets with my hardware either.

EDIT: I think my dusty Turbo Force does it too, it's a 352x240@61.31Hz game, will drop a couple pictures today.

I should be able to see that variation on the scope, or am I just overlooking something? Or could this be something that could differ for every specimen of the game PCB?

I hooked up V-V and tried every available H-PLL postcoast step on the OSSC, adjusting Hsync tolarance accordingly and couldn't get the picture to show up.
There's a quirk that I can reproduce consistently, where the red LED goes out after switching from 320x240 optim. to generic 4:3, specifically (even so, no picture with any of the displays available to me at the moment).
After that, the red LED stays out for all output modes. The LED only lights again when power cycling the OSSC and stays on until I switch from 320x240 optim. to generic 4:3.

With H-PLL pre at 1, post at 0 lines and H tolerance at 0.92μs (default), the OSSC displays the following video parameters in my case: AV1: RGBS 263p, 15.61kHZ 59.37Hz. Firmware is v0.84a.


The sync signal of V-V looks very similar to Dogyuun. It has the spike after the falling edge of Vblank, and the noise between the Hsync pulses (albeit a bit less of it), which is always subdued for about 1ms after Vblank. H and V frequencies, and Vp-p are pretty much identical too:

Have you tried also adjusting "Analog sync Vth" together with H-PLL coast settings?

Do you get a partial and distorted picture from V-V with OSSC samplerate at 1100 like I do with Dogyuun?

Another round of OSSC tinkering, with a smidge of success this time, thanks for both your suggestions.

Indeed, increasing H.samplerate greatly, starting with 1153, manages to tease out a picture. Quality gets better up until around 1250 - higher values just shift the picture further to the left, which is then (even more so) prematurely cut off there. At that point everything was still very unstable and regular cutouts occured.

I then set H.backporch from 47 (default) to around 10, which led to the whole picture being shown on screen. Adjusting sampling phase from here does not lead to any improvements.

Note that this is all with H-PLL pre- & postcoast, and H.sync tolerance kept at their defaults. Increasing H-PLL postcoast just shifts the "waves" in the picture down but does not visibly reduce them. Adjusting H.sync tolerance doesn't change anything that I can see. Increasing analog sync Vth from the default of 123mV likewise doesn't change anything that I can see, while decreasing it leads to worse image quality.

With that settings the OSSC display reads the following: AV1: RGBS 263p 15.62kHZ 59.41Hz
Cutouts ceased at this point, though I don't know if they could still happen if waited long enough.

Here's a video showing the best result I could get for now:
https://www.youtube.com/watch?v=4udopjOd0XU (watch in 1080p60 if possible)

My capture card quits service with "Invalid signal", so I can't provide a direct capture currently.
These waves on top of the picture correspond to the effect Xyga observed for sure.

While it's still not satisfying of course, it's at least a start and might give hints on how to improve it.

That looks just awful, it's like the sampled pixel rate is about half of the GP9001's actual dot clock...

Next week when I have my Batsugun I'd like to take a look at this.

Could you measure the period between falling edges for p262, p263, p1-5, p6, ..., p20? I'm fairly confident there's some variation at some point. One unusual thing is vsync length which is 4 lines instead of typical 3, but that shouldn't affect stability if its length is exactly 4 times normal line length.

marqs:
I'm fairly confident that an increased range for pre/post coast can fix the issue.
I think the 7002 is confused where VSync is positioned, possibly due to period deviation you mentioned, and possibly due to that single spike right at the start of the VSync pulse.
Coasting up to -10 .. +10 could bring this condition in order.

In μs:

p262 64
p263 64
p1-5 324
p6 64
p7 64
p8 64
p9 64
p10 64
p11 64
p12 64
p13 64
p14 64
p15 64
p16 64
p17 64
p18 64
p19 64
p20 64

For what it's worth, have repeated the series a second time a few minutes later which reproduced exactly the same values.
Divergences >= 0.2 μs I would have noticed.

Assuming that 64us is close to 64.0us, accumulated sync and first backporch line lengths (p1-5) do not equal to 5 times normal line length (5*64=320). That 4us deviation can be bad enough to make it hard for a H-PLL to maintain lock, and increasing coast is likely to just make things worse (increased skew which also gets moved down). There's a few ways I can think of which should mitigate or fix the issue, but they need external sync processing (e.g. via CPLD) and possibly modification of the board:

1. Vsync length reduction to 1 lines would minimize the coast time a PLL in digital receiver must run without reference, making sure the frequency divergence due to coast is kept at minimum. Sync for the lines until first visible line would be then created either using:
a) fixed 64us period after 64us+4us vsync "line". Assuming PLL is able to keep lock despite that 4us deviation (and a receiver capable of accepting resulting jittery signal), the skew could normalize by the time first visible line is scanned out.
b) fixed 64.25us period for first 16 lines, or increasing + decreasing period for those 16 lines to match that total 4us extra delay. This approach would maximize the chance PLL stays locked and ensure output pixel clock doesn't have too high short-term jitter.

2. Stopping the board oscillator(s) for 60us to generate 264th line. This method would enable generation of perfect sync but may not be as practical as the previous ones or even work reliably if there are multiple oscillators on board.

Yes, I had just double-checked and wanted to edit all numbers to end on .0

I'm doing this with the cursors since measurement mode does not update when sampling is stopped. I could trigger on Vsync instead but measuring the running signal does not make much sense.
Maybe there's an easier way to measure this that I haven't discovered yet.

Hm, so this seems indeed a little harder to fix then...

The other systems where I've seen period length exceptions after Vsync (e.g. some MVS models or F3) have evened itself out, but there no compensating 60us line here that would make it easy to solve the issue by just increasing coast.

The assumed problem highlighted, for clarity:

It's worth pointing out that latter cursor is not aligned to falling edge as it first seems.

Exactly: cursor would have to align if p1-5 had been 320us. So you can see the overshoot.

Would zoom in further but next zoom level (H=20us) is already too much and cursors cannot scroll offscreen & stay fixed on screen instead of time offset.

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.

Is there any other known hardware with this anomaly that's not an expensive / rare piece of kit?
I'd love to work on this..
Or is there a good simulator for this maybe?

Some more shots.

XRGB-2 skew default like before but slightly clearer photo (uh, not really better pic actually lol, well)


And now better tuned AFC, more like what I remember (DTC type is PS/playstation)
This is rather sensitive and quirky, sometimes it'll do better, sometimes worse, probably affected by a number of small factors like pcb & xrgb power, or sync auto-hooking from the display


Micomsoft XC15 DISPL for reference. No AFC available so it can't do better than this



PS: also I remembered wrong about Turbo Force; just tested it again and it was okay on both doublers.

You could recreate the signal with an arbitrary waveform generator, I suppose.

Having said that, I'm always up for trying out a custom-built firmware image - doesn't hurt to investigate that option too.
I was happy to read that the 7002 indeed seems to support what you have in mind ("Sync Control 1" and "H-PLL and Clamp Control" registers)

Instead of lots of custom firmwares, maybe there's a more direct way to change 7002 registers on the fly.
Testing all the possible sync extractor option combinations takes long enough as it is. It would be annoying to always have to build and flash entire firmwares :p

Note:
I didn't see the options I had in mind in those regs, but sometimes they're named differently, or an unrelated option has the desired effect.
It really needs a few hours of dedicated bit flip testing.

Granted, I wouldn't have imagined testing all possible combinations and seeing what sticks would be a viable way to go about this Your idea sounded more like something concrete to try.
While it doesn't evoke a comfortable gut feeling for me, I don't have much experience with the chip, so if that's more likely to uncover a solution, so be it.

E.g. "HSYNC polarity override" - doesn't that come into consideration? If not, why?

The problem with these all in one frontend chips is that there's so many variables to consider for everything.
It makes it hard to work out how a particular input sync will affect each subunit in the chip.
That's why I think it's easier to just test it out and see whether we can't find a working processing mode.

As an example, the CS decoder could trigger on rising or falling flank.
It could have a sync ignore window (Macrovision filter) that may apply to VSync EQ pulses (or not), and if it does, it may be configured to apply to narrow EQ pulses only, or including wide ones.
The combinations and effect there alone are maddening :p

Now the decoded HSync may be the input to the H-PLL to recover a display clock.
But the H-PLL may also use a further filtered, or totally unfiltered HSync for that.
Here the inversion would be important, if the H-PLL source HSync is from a CS decoder with active high (misconfigured) polarity.
This depends on how the hardware for the H-PLL works.
On my frontend (GBS8200 TV5725 chip), a misconfigured CS decoder can be fixed by swapping the decoded HS polarity.

I think with all the possible combinations, there might be one that works with these incompatible arcade boards.

What's needed is a way to directly access all the 7002 registers on the fly.
Maybe the OSSC control software could be stopped, and the I2C bus be freed to allow an external controller?
Unfortunately I don't have an OSSC to check this.