Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Well, your measurements already completely shed any doubt that both HSync flanks are skewed by a large amount.
There isn't much you can do with this condition.
If the H-PLL could lock to the new position within VBlank, you may get some kind of a picture, at best :/
If you want to try this route:
While watching the image quality / stability, lower the H-PLL charge pump current + gain until
you either start getting it working, or totally loose any lock.
There isn't much you can do with this condition.
If the H-PLL could lock to the new position within VBlank, you may get some kind of a picture, at best :/
If you want to try this route:
While watching the image quality / stability, lower the H-PLL charge pump current + gain until
you either start getting it working, or totally loose any lock.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Yeah, it might be a desperate endeavour I'm afraid
Will try your suggestion and a few other things in a bit.
With gain you mean VCO gain, right? (everything in the "H-PLL Control" register)
The TVP registers "HSYNC Output Width", "HSYNC Output Start" and "VSYNC Alignment" come to mind as well.
Will try your suggestion and a few other things in a bit.
With gain you mean VCO gain, right? (everything in the "H-PLL Control" register)
The TVP registers "HSYNC Output Width", "HSYNC Output Start" and "VSYNC Alignment" come to mind as well.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Yep, the keywords are H-PLL, VCO, together with gain and charge pump current (or icp).
This basically controls the H-PLL bandwith.
The output parameters shouldn't affect this problem, but it won't hurt to test them.
This basically controls the H-PLL bandwith.
The output parameters shouldn't affect this problem, but it won't hurt to test them.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Alright, some progress
Starting with 0xf8, decreasing the H-PLL control register in steps of 8 did not lead to any notable improvements by itself.
I then proceeded to fiddle with H.samplerate again; it does make it worse after 1250, so I didn't go much further than that previously. But to my surprise, there's another "good" region roughly between 1380 and 1420.
1409 is the sweetspot in my setup, it's a notable improvement over the previous result which used 1250, I'm sure the exact value could differ depending on the PCB and supergun however.
Unfortunately, the image was not at all stable, cutting off constantly. I looped through the H-PLL control register again and found one value which manages to stabilize it: 0xc8.
I also looped through HSOUTSTART, HSOUTWIDTH and VSOUTALIGN (0x0..0xff), which had no notable effect.
With H.backporch at 10 and sampling phase at 168 deg, this is the new result.
It looks like the shimmering (when the game scrolls) could be evened out via sampling phase, but it cannot.
The pixel dither while being much weaker is still there, as are the "waves" at the upper edge, so it still doesn't look particularly edifying..
Starting with 0xf8, decreasing the H-PLL control register in steps of 8 did not lead to any notable improvements by itself.
I then proceeded to fiddle with H.samplerate again; it does make it worse after 1250, so I didn't go much further than that previously. But to my surprise, there's another "good" region roughly between 1380 and 1420.
1409 is the sweetspot in my setup, it's a notable improvement over the previous result which used 1250, I'm sure the exact value could differ depending on the PCB and supergun however.
Unfortunately, the image was not at all stable, cutting off constantly. I looped through the H-PLL control register again and found one value which manages to stabilize it: 0xc8.
I also looped through HSOUTSTART, HSOUTWIDTH and VSOUTALIGN (0x0..0xff), which had no notable effect.
With H.backporch at 10 and sampling phase at 168 deg, this is the new result.
It looks like the shimmering (when the game scrolls) could be evened out via sampling phase, but it cannot.
The pixel dither while being much weaker is still there, as are the "waves" at the upper edge, so it still doesn't look particularly edifying..
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Would you try 0x60 or so?
With C8 you have maximum gain and almost minimum ICP.
The waves you get are from the weak charge pump current, by the way, but you'll have to go with anything that allows the H-PLL to lock after the VSync desaster.
With C8 you have maximum gain and almost minimum ICP.
The waves you get are from the weak charge pump current, by the way, but you'll have to go with anything that allows the H-PLL to lock after the VSync desaster.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
0x60 leads to an image being shown only for a split second, every few seconds (for H.samplerates 1409/1250/431) - if you blink you could miss it.
For the last post, I already went through all possible values; none facilitate a stable image for samplerates other than 1250, except 0xc8. Most even lead to the red LED being lit and my monitor quitting with "no signal".
For 1250, there are a few more values that produce a stable image.
(all H.samplerates are to be read as sweetspots at the center of a small range of "better" values)
You're right that charge pump current and gain affect the "waves". 0x50 for example completely straightens the image and the waves are gone, but the image is again missing in action most of the time. Goes without saying that that's worse than the waves.
Here's a still frame from a video showing that the waves are completely gone:
I've found that 0xc8 even manages to deliver an intermittent image for H.samplerate=439 (which I did not achieve before) which looks even better than the 1409 linked in the post above (probably how it would look, barring the waves, had the game a good sync signal like e.g. Tatsujin Oh). If only there was a way to stabilize it...
It's unpredictable when the image appears, so I couldn't manage to show the same scene as I did up until now. For the same reason, it's sharper in reality than here, as the camera didn't have time to adjust to the sudden flash.
Some random unsorted thoughts:
I've been thinking about a circuit that would buffer sync and the colors for a certain amount of time in the μs magnitude, i.e. implement a look-ahead from the viewpoint of the sink. That would give it the time to correct certain malformations a sync signal can have. You would select yourself which problem should be accounted for, meaning you would select between something like (Passthru, Taito F3, Master System, ToaplanV2, and so forth). The size of the buffer would have to vary depending on the sync problem that is to be corrected. I cannot imagine that this would require a particularly complex logic. For ToaplanV2, my impression is that it's already quite obvious what would have to be done.
I think it would be best designed as a standalone device such that the number of source x sink combinations it could cover is maximized. A counter argument would be to simply use a buffered scaler that's known to be compatible, but seeing that these could simply not be available (anymore) or be too expensive, I think an (open source!) standalone device would be the logical conclusion. This could get rid of so much pain we have in the analog video realm (especially for arcade). Paired with a voltage level control circuit, it would even moreso become a sorely needed accessory. Unfortunately, I lack the background to design such a device or even evaluate the idea of it competently. I've seen rudiments of it, but nothing that's dedicated to this problem and solves it comprehensively.
Is it outrageous? Is it soaked in misconceptions?
For the last post, I already went through all possible values; none facilitate a stable image for samplerates other than 1250, except 0xc8. Most even lead to the red LED being lit and my monitor quitting with "no signal".
For 1250, there are a few more values that produce a stable image.
(all H.samplerates are to be read as sweetspots at the center of a small range of "better" values)
You're right that charge pump current and gain affect the "waves". 0x50 for example completely straightens the image and the waves are gone, but the image is again missing in action most of the time. Goes without saying that that's worse than the waves.
Here's a still frame from a video showing that the waves are completely gone:
Spoiler
Spoiler
Some random unsorted thoughts:
I've been thinking about a circuit that would buffer sync and the colors for a certain amount of time in the μs magnitude, i.e. implement a look-ahead from the viewpoint of the sink. That would give it the time to correct certain malformations a sync signal can have. You would select yourself which problem should be accounted for, meaning you would select between something like (Passthru, Taito F3, Master System, ToaplanV2, and so forth). The size of the buffer would have to vary depending on the sync problem that is to be corrected. I cannot imagine that this would require a particularly complex logic. For ToaplanV2, my impression is that it's already quite obvious what would have to be done.
I think it would be best designed as a standalone device such that the number of source x sink combinations it could cover is maximized. A counter argument would be to simply use a buffered scaler that's known to be compatible, but seeing that these could simply not be available (anymore) or be too expensive, I think an (open source!) standalone device would be the logical conclusion. This could get rid of so much pain we have in the analog video realm (especially for arcade). Paired with a voltage level control circuit, it would even moreso become a sorely needed accessory. Unfortunately, I lack the background to design such a device or even evaluate the idea of it competently. I've seen rudiments of it, but nothing that's dedicated to this problem and solves it comprehensively.
Is it outrageous? Is it soaked in misconceptions?
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
One potential route with OSSC would be hooking video / DAC clock from the PCB to EXT_CLK pin of TVP7002. That would fix sampling, but then clock & sync generation via FPGA would get more complicated. Depending on how many pixels are on the normal lines and on the short one, a suitable output mode and FPGA PLL setting might be found. Then again, the process involves some HW modification and firmware customization so it wouldn't be an universal solution.
Sync and RGB could be buffered and reprocessed by external circuitry, but I'm afraid that making it both robust and universal (and inexpensive) would be quite a challenge.
Sync and RGB could be buffered and reprocessed by external circuitry, but I'm afraid that making it both robust and universal (and inexpensive) would be quite a challenge.
-
- Posts: 484
- Joined: Wed Jun 22, 2005 9:20 am
- Location: Liberal cesspool
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
There is a man designing a scaler called the A1. He apparently is making an arcade based line doubler focused on compatibility. I am curious to what extent he considered these boards.6t8k wrote:0x60 leads to an image being shown only for a split second, every few seconds (for H.samplerates 1409/1250/431) - if you blink you could miss it.
For the last post, I already went through all possible values; none facilitate a stable image for samplerates other than 1250, except 0xc8. Most even lead to the red LED being lit and my monitor quitting with "no signal".
For 1250, there are a few more values that produce a stable image.
(all H.samplerates are to be read as sweetspots at the center of a small range of "better" values)
You're right that charge pump current and gain affect the "waves". 0x50 for example completely straightens the image and the waves are gone, but the image is again missing in action most of the time. Goes without saying that that's worse than the waves.
Here's a still frame from a video showing that the waves are completely gone:I've found that 0xc8 even manages to deliver an intermittent image for H.samplerate=439 (which I did not achieve before) which looks even better than the 1409 linked in the post above (probably how it would look, barring the waves, had the game a good sync signal like e.g. Tatsujin Oh). If only there was a way to stabilize it...Spoiler
It's unpredictable when the image appears, so I couldn't manage to show the same scene as I did up until now. For the same reason, it's sharper in reality than here, as the camera didn't have time to adjust to the sudden flash.Spoiler
Some random unsorted thoughts:
I've been thinking about a circuit that would buffer sync and the colors for a certain amount of time in the μs magnitude, i.e. implement a look-ahead from the viewpoint of the sink. That would give it the time to correct certain malformations a sync signal can have. You would select yourself which problem should be accounted for, meaning you would select between something like (Passthru, Taito F3, Master System, ToaplanV2, and so forth). The size of the buffer would have to vary depending on the sync problem that is to be corrected. I cannot imagine that this would require a particularly complex logic. For ToaplanV2, my impression is that it's already quite obvious what would have to be done.
I think it would be best designed as a standalone device such that the number of source x sink combinations it could cover is maximized. A counter argument would be to simply use a buffered scaler that's known to be compatible, but seeing that these could simply not be available (anymore) or be too expensive, I think an (open source!) standalone device would be the logical conclusion. This could get rid of so much pain we have in the analog video realm (especially for arcade). Paired with a voltage level control circuit, it would even moreso become a sorely needed accessory. Unfortunately, I lack the background to design such a device or even evaluate the idea of it competently. I've seen rudiments of it, but nothing that's dedicated to this problem and solves it comprehensively.
Is it outrageous? Is it soaked in misconceptions?
A camel is a horse designed by a committee
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
^ Ah, was not aware of that project - this must be it, right? https://irkenlabs.com/retro-scaler-a1/introduction
First few thoughts:
• It does not output digital video, or am I just overlooking it?
• As a fully fledged scaler, it would kind of replace the OSSC and the like. I was more thinking of something more specialized that would enable us to get more out of our existing devices.
Nonetheless interesting and will keep track of it, so thanks for the mention!
Well i'm aware a device catering to the above idea probably wouldn't be very cheap - to demand it being robust, universal and inexpensive in the same breath would sound a bit arrogating for sure. I was more expressing a wish for a sustainable solution, the price/performance ratio of which doesn't get (that much) worse over time, when supply gets scarce. I'm sure this could be obviated depending on the approach (compare e.g. OSSC and Framemeister)
As for a pure software OSSC solution, since we're seeing diminishing returns now, and it feels like a satisfying result will stay out of reach, I think I might now reduce efforts on this end. Unless there are some new groundbreaking ideas, I'd like to focus on more promising hardware solutions now (although I feel like I can't contribute as much to that myself). Assuring that I went into the analysis in an open-ended way, notwithstanding that it was kind of foreseen, this would be a perfectly acceptable (albeit sobering) result.
At least we've been documenting pretty obscure yet potentially useful stuff for years to come
I've already exhausted all settings that are accessible via OSD (in combination with the TVP registers that I've checked until now).
As for the registers, I feel like I went through the low hanging fruit by now. Are there any more that could be worth a try?
Maybe the H-PLL Feedback Divider or VBLK Field-related registers?
First few thoughts:
• It does not output digital video, or am I just overlooking it?
• As a fully fledged scaler, it would kind of replace the OSSC and the like. I was more thinking of something more specialized that would enable us to get more out of our existing devices.
Nonetheless interesting and will keep track of it, so thanks for the mention!
Thank you for the suggestion - that would be one enterprising option (and maybe solution) for sure!marqs wrote:One potential route with OSSC would be hooking video / DAC clock from the PCB to EXT_CLK pin of TVP7002. That would fix sampling, but then clock & sync generation via FPGA would get more complicated. Depending on how many pixels are on the normal lines and on the short one, a suitable output mode and FPGA PLL setting might be found. Then again, the process involves some HW modification and firmware customization so it wouldn't be an universal solution.
Sync and RGB could be buffered and reprocessed by external circuitry, but I'm afraid that making it both robust and universal (and inexpensive) would be quite a challenge.
Well i'm aware a device catering to the above idea probably wouldn't be very cheap - to demand it being robust, universal and inexpensive in the same breath would sound a bit arrogating for sure. I was more expressing a wish for a sustainable solution, the price/performance ratio of which doesn't get (that much) worse over time, when supply gets scarce. I'm sure this could be obviated depending on the approach (compare e.g. OSSC and Framemeister)
As for a pure software OSSC solution, since we're seeing diminishing returns now, and it feels like a satisfying result will stay out of reach, I think I might now reduce efforts on this end. Unless there are some new groundbreaking ideas, I'd like to focus on more promising hardware solutions now (although I feel like I can't contribute as much to that myself). Assuring that I went into the analysis in an open-ended way, notwithstanding that it was kind of foreseen, this would be a perfectly acceptable (albeit sobering) result.
At least we've been documenting pretty obscure yet potentially useful stuff for years to come
I've already exhausted all settings that are accessible via OSD (in combination with the TVP registers that I've checked until now).
As for the registers, I feel like I went through the low hanging fruit by now. Are there any more that could be worth a try?
Maybe the H-PLL Feedback Divider or VBLK Field-related registers?
Feel free to go ahead (in before you have to return it!)mikejmoffitt wrote:I do have a Ghox on loan and can try it.
Last edited by 6t8k on Wed Nov 27, 2019 7:14 pm, edited 2 times in total.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Dunno, reverse-engineer the XRGB-2's AFC and see if that can fit somewhere in an improved version lol.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
The inherent problem with an universal solution (which doesn't extract signals outside of standard JAMMA/AV connector) is that sampling clock is generated from hsync. With such skews/irregularities, the same clock is no good for generating stable output pixel clock. You have to then generate pixel clock independently and either a) keep it framelocked to avoid latency (not easy, but possible) b) take the easy route and use triple buffering. The first option needs dynamically adjustable clock generator but little memory while the second one needs some memory but only simple clock circuitry.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Well the XRGB-2 sure is pretty unique even if outdated. Still personally I like universal and generic solutions, I understand they're harder to do right tho.
PS: how about a sync plug-in in OSSC v2 ?
PS: how about a sync plug-in in OSSC v2 ?
Strikers1945guy wrote:"Do we....eat chicken balls?!"
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Has anyone tried connecting these boards via XRGB-2 -> OSSC chain to a monitor that has very little tolerance to TMDS clock variation (e.g. does not accept SNES without de-jitter mod)? The point is to get some insight whether XRGB-2's output sync has jitter that is just attennuated (could be good enough for many displays) or if sync is fully regenerated.Xyga wrote:Well the XRGB-2 sure is pretty unique even if outdated. Still personally I like universal and generic solutions, I understand they're harder to do right tho.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Er...no never tried that, not sure I have the required display here but I will check tomorrow anyway.
I'm afraid all those I have here are pretty tolerant in that area.
IIRC the Sony W6 was a bitch so maybe I could try with it (it's at my old people's place now tho so later)
I'm afraid all those I have here are pretty tolerant in that area.
IIRC the Sony W6 was a bitch so maybe I could try with it (it's at my old people's place now tho so later)
Strikers1945guy wrote:"Do we....eat chicken balls?!"
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
So I've tried, with both the XRGB-2 and th DISPL...
All I could do is passthrough the XRGB-2, resulting in the whole picture to be wobbly, and I can't use the AFC anymore to correct the flagging or I lose the picture.
¯\(°_o)/¯
All I could do is passthrough the XRGB-2, resulting in the whole picture to be wobbly, and I can't use the AFC anymore to correct the flagging or I lose the picture.
¯\(°_o)/¯
Strikers1945guy wrote:"Do we....eat chicken balls?!"
-
mikejmoffitt
- Posts: 629
- Joined: Fri Jan 08, 2016 7:26 am
- Location: Tokyo, Japan
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
I do have to ask... why does the MS9 not have these problems? The usual throwaway answer is "oh it's a CRT of course" but that doesn't really mean anything. It still has to detect a valid sync edge and act upon it; being a CRT doesn't magically imply a functioning filter.
What does the MS9 do for sync processing and edge detection?
What does the MS9 do for sync processing and edge detection?
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
It's probably simply that it doesn't rely on a PLL for clock recovery and / or general sync processing.
The CRT will simply use even a skewed HSync such as this.
The CRT will simply use even a skewed HSync such as this.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
And I (stubbornly) went through the remaining, above-mentioned TVP registers, to no avail, now concluding for the time being.
So would you support the idea that instead of specifically trying to rectify sync on the fly, going with one of the these two approaches would be more sound?
While nothing can recover information that isn't there in the signal, I was assuming something akin to a fixed (per-source) correction matrix could perhaps do the job, as ideal (design intended) video/hardware parameters are, or can be known.
But thinking over it, with all the quirks of the analog and the plethora of different source device (sub-)revisions that could have different characteristics, I'm probably underestimating it.
While the Framemeister would be a type b solution, a type a solution would be the cps2_digiav, if I'm not mistaken.marqs wrote:The inherent problem with an universal solution (which doesn't extract signals outside of standard JAMMA/AV connector) is that sampling clock is generated from hsync. With such skews/irregularities, the same clock is no good for generating stable output pixel clock. You have to then generate pixel clock independently and either a) keep it framelocked to avoid latency (not easy, but possible) b) take the easy route and use triple buffering. The first option needs dynamically adjustable clock generator but little memory while the second one needs some memory but only simple clock circuitry.
So would you support the idea that instead of specifically trying to rectify sync on the fly, going with one of the these two approaches would be more sound?
While nothing can recover information that isn't there in the signal, I was assuming something akin to a fixed (per-source) correction matrix could perhaps do the job, as ideal (design intended) video/hardware parameters are, or can be known.
But thinking over it, with all the quirks of the analog and the plethora of different source device (sub-)revisions that could have different characteristics, I'm probably underestimating it.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
If you're really lucky, the timer generator on the arcade board is configurable.
This would go well with the fact that other games using the same chipset don't have the problem.
Are there schematics / pinouts to guess pin functions from? :p
This would go well with the fact that other games using the same chipset don't have the problem.
Are there schematics / pinouts to guess pin functions from? :p
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
If possible, that would be cool indeed.
We briefly addressed this route here.
I left with the question whether it is at least controllable by the game ROMs themselves; it seems implicated, but there could of course be more to it.
It's kinda stretching my abilities to look further into it, at least I would need much more time etc.
As for schematics, of what I know the Knucke Bash ones linked earlier are what comes closest .
We briefly addressed this route here.
I left with the question whether it is at least controllable by the game ROMs themselves; it seems implicated, but there could of course be more to it.
It's kinda stretching my abilities to look further into it, at least I would need much more time etc.
As for schematics, of what I know the Knucke Bash ones linked earlier are what comes closest .
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Sorry if I'm being redundant here, but I remember seeing the phenomenon happen on a CRT too, that was a cabinet and the owner had to adjust directly on the chassis (don't remember the cabinet details sorry)rama wrote:It's probably simply that it doesn't rely on a PLL for clock recovery and / or general sync processing.
The CRT will simply use even a skewed HSync such as this.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
I think Framemeister could be both depending on its framelock setting. As for cps2_digiav, it's not exactly option a as it uses board's video clock instead of an unrelated clock source.6t8k wrote:While the Framemeister would be a type b solution, a type a solution would be the cps2_digiav, if I'm not mistaken.
Simple sync rectification will only help with certain displays at best as you can see from Xyga's test results - the sync would need to be generated from scratch with video data aligned to it for best compatibility. Even if the sync generation could be made with relatively simple HW, the video alignment part would need ADC+DAC which would increase cost and complexity possibly beyond what makes sense for a box-in-between type of device. That's why I think the functionality would be best integrated on either end (arcade PCB or scaler) when possible.6t8k wrote:So would you support the idea that instead of specifically trying to rectify sync on the fly, going with one of the these two approaches would be more sound?
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
^ Again thanks for the valuable insight (about cps2_digiav, I somehow managed to lose sight of that aspect again).
Note to myself in the future: check which PCBs have a "vertical line counter" circuit just like Knuckle Bash does. I have an idea.
Note to myself in the future: check which PCBs have a "vertical line counter" circuit just like Knuckle Bash does. I have an idea.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Tried to scout the listed PCBs but could only find Teki Paki at decent price, and it's yet not known whether that has deranged sync or not. I'll keep an eye on these for a while but if that doesn't work out, then I might consider doing cps2_digiav install for someone else's board.
-
- Posts: 484
- Joined: Wed Jun 22, 2005 9:20 am
- Location: Liberal cesspool
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Thank you for the update and would be happy to donate towards this cause.
A camel is a horse designed by a committee
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Exciting!
shmupsrocks, could you maybe add the list at the bottom of this post to your initial post? Seems it would get a bit buried otherwise.
shmupsrocks, could you maybe add the list at the bottom of this post to your initial post? Seems it would get a bit buried otherwise.
-
mikejmoffitt
- Posts: 629
- Joined: Fri Jan 08, 2016 7:26 am
- Location: Tokyo, Japan
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Finally got access to my capture hardware again... so maybe I can actually get data now.
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Found this in the MAME source the other day.
What's notable is that all games known to have the sync problem (up until now), write the same values to the 0Eh scroll register of the first GP9001 (0202, 0203, 4200).
This could indicate that Knucke Bash and Snow Bros. 2, which we don't have empirical info about so far, would be bad as well.
Of the games known to be working, Truxton 2 and Pipi & Bibis are listed. Both write the same values, which are different from the above, "OSSC incompatible" ones.
What's notable is that all games known to have the sync problem (up until now), write the same values to the 0Eh scroll register of the first GP9001 (0202, 0203, 4200).
This could indicate that Knucke Bash and Snow Bros. 2, which we don't have empirical info about so far, would be bad as well.
Of the games known to be working, Truxton 2 and Pipi & Bibis are listed. Both write the same values, which are different from the above, "OSSC incompatible" ones.
-
- Posts: 597
- Joined: Mon Aug 13, 2018 3:53 pm
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
Good idea, done.6t8k wrote:shmupsrocks, could you maybe add the list at the bottom of this post to your initial post? Seems it would get a bit buried otherwise.
-
- Posts: 635
- Joined: Fri Apr 20, 2018 9:22 am
- Location: Washigton DC
Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
I have two Knuckle Bash PCBs (Japanes and Korean) and a Snow Bros. 2 on the way from overseas. I'd be happy to test, but I'd need some info on what you're looking for exactly. As I posted before, I think my Outzone works with my HAS to an OSSC... but maybe I was crazy before.6t8k wrote:Found this in the MAME source the other day.
What's notable is that all games known to have the sync problem (up until now), write the same values to the 0Eh scroll register of the first GP9001 (0202, 0203, 4200).
This could indicate that Knucke Bash and Snow Bros. 2, which we don't have empirical info about so far, would be bad as well.
Of the games known to be working, Truxton 2 and Pipi & Bibis are listed. Both write the same values, which are different from the above, "OSSC incompatible" ones.