shmups.system11.org

Shmups Forum
 
* FAQ    * Search
 * Register  * Login 
It is currently Sun Dec 15, 2019 4:50 am View unanswered posts
View active topics



Post new topic Reply to topic  [ 121 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Fri Nov 22, 2019 1:00 pm 



Joined: 08 Mar 2017
Posts: 1162
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Sun Nov 24, 2019 4:37 pm 


User avatar

Joined: 14 Aug 2019
Posts: 136
Location: BW, Germany
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Sun Nov 24, 2019 6:20 pm 



Joined: 08 Mar 2017
Posts: 1162
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Tue Nov 26, 2019 12:09 am 


User avatar

Joined: 14 Aug 2019
Posts: 136
Location: BW, Germany
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..


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Tue Nov 26, 2019 10:08 am 



Joined: 08 Mar 2017
Posts: 1162
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Tue Nov 26, 2019 9:44 pm 


User avatar

Joined: 14 Aug 2019
Posts: 136
Location: BW, Germany
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:
Spoiler: show
Image


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: show
Image

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? :P


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Tue Nov 26, 2019 11:00 pm 


User avatar

Joined: 15 Dec 2012
Posts: 699
Location: Finland
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Wed Nov 27, 2019 3:40 am 



Joined: 22 Jun 2005
Posts: 201
Location: Communism's New Home (CA, USA)
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:
Spoiler: show
Image


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: show
Image

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? :P


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.
_________________
I enjoy jamma games more than anything on console.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Wed Nov 27, 2019 6:46 pm 


User avatar

Joined: 14 Aug 2019
Posts: 136
Location: BW, Germany
^ 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!

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.

Thank you for the suggestion - that would be one enterprising option (and maybe solution) for sure!

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 :P

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?

mikejmoffitt wrote:
I do have a Ghox on loan and can try it.

Feel free to go ahead (in before you have to return it!)


Last edited by 6t8k on Wed Nov 27, 2019 7:14 pm, edited 2 times in total.

Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Wed Nov 27, 2019 7:08 pm 


User avatar

Joined: 05 Nov 2013
Posts: 7074
Location: block
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?!"


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Wed Nov 27, 2019 7:35 pm 


User avatar

Joined: 15 Dec 2012
Posts: 699
Location: Finland
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Wed Nov 27, 2019 7:46 pm 


User avatar

Joined: 05 Nov 2013
Posts: 7074
Location: block
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 ? :mrgreen:
_________________
Strikers1945guy wrote:
"Do we....eat chicken balls?!"


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Wed Nov 27, 2019 7:58 pm 


User avatar

Joined: 15 Dec 2012
Posts: 699
Location: Finland
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.
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Wed Nov 27, 2019 8:16 pm 


User avatar

Joined: 05 Nov 2013
Posts: 7074
Location: block
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)
_________________
Strikers1945guy wrote:
"Do we....eat chicken balls?!"


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Thu Nov 28, 2019 3:21 pm 


User avatar

Joined: 05 Nov 2013
Posts: 7074
Location: block
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)/¯
_________________
Strikers1945guy wrote:
"Do we....eat chicken balls?!"


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Thu Nov 28, 2019 6:05 pm 


User avatar

Joined: 08 Jan 2016
Posts: 560
Location: San Jose, CA
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?
_________________
Making Gimmick! exAct * Mix
Image


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Thu Nov 28, 2019 7:21 pm 



Joined: 08 Mar 2017
Posts: 1162
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Fri Nov 29, 2019 7:16 pm 


User avatar

Joined: 14 Aug 2019
Posts: 136
Location: BW, Germany
And I (stubbornly) went through the remaining, above-mentioned TVP registers, to no avail, now concluding for the time being.

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.

While the Framemeister would be a type b solution, a type a solution would be the cps2_digiav, if I'm not mistaken.

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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Fri Nov 29, 2019 9:26 pm 



Joined: 08 Mar 2017
Posts: 1162
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


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Fri Nov 29, 2019 10:42 pm 


User avatar

Joined: 14 Aug 2019
Posts: 136
Location: BW, Germany
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 .


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Sat Nov 30, 2019 12:01 am 


User avatar

Joined: 05 Nov 2013
Posts: 7074
Location: block
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.

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)
_________________
Strikers1945guy wrote:
"Do we....eat chicken balls?!"


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Sat Nov 30, 2019 12:03 am 


User avatar

Joined: 15 Dec 2012
Posts: 699
Location: Finland
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.
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:
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?
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Sat Nov 30, 2019 5:20 pm 


User avatar

Joined: 14 Aug 2019
Posts: 136
Location: BW, Germany
^ 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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Sun Dec 01, 2019 8:53 pm 


User avatar

Joined: 15 Dec 2012
Posts: 699
Location: Finland
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Mon Dec 02, 2019 4:18 am 



Joined: 22 Jun 2005
Posts: 201
Location: Communism's New Home (CA, USA)
Thank you for the update and would be happy to donate towards this cause.
_________________
I enjoy jamma games more than anything on console.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Mon Dec 02, 2019 2:23 pm 


User avatar

Joined: 14 Aug 2019
Posts: 136
Location: BW, Germany
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Mon Dec 02, 2019 10:34 pm 


User avatar

Joined: 08 Jan 2016
Posts: 560
Location: San Jose, CA
Finally got access to my capture hardware again... so maybe I can actually get data now.
_________________
Making Gimmick! exAct * Mix
Image


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Sun Dec 08, 2019 4:30 pm 


User avatar

Joined: 14 Aug 2019
Posts: 136
Location: BW, Germany
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.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Mon Dec 09, 2019 5:23 pm 



Joined: 13 Aug 2018
Posts: 301
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.


Good idea, done.


Top
 Offline Profile  
 
 Post subject: Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC
PostPosted: Mon Dec 09, 2019 7:11 pm 



Joined: 20 Apr 2018
Posts: 49
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.


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.


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 121 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: DarkAries, Google [Bot], Lawfer, maxtherabbit and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Space Pilot 3K template by Jakob Persson
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group