What's new
Yup, the Japanese one is the newer and with most fixes and balance changes.
Weird, this quote was meant for the wtf sales post thread. Not sure why it quoted this instead and it got here. Disregard.
 
Last edited:
So here's something I've been wondering about the dash board. It seems like the line most people draw at is SF2CE where it was introduced. The C board on it is CPS-B-21. The King of Dragons, Captain Commando and Knights of the Round came out before SF2CE however they use the CPS-B-21 with suicide battery. Mame denotes these 3 games as 10MHz boards however it doesn't make sense in my mind.

If you're producing a new revision of boards it would make sense to standardize at the base level which to me would be when CPS-B-21 was introduced with regards to the dash A board. Has anyone ever been able to confirm if these 3 boards came with 10MHz or 12MHz A boards?


One thing I notice with regards to the A board revisions in SF2CE/HF is if you use the 10MHz board the startup rom checks are always garbled before completing and then show properly. On a dash board the text is always correct. That to me seems to be a good indicator of which board should mate with which however I don't have any other games to verify this theory.
 
If you're producing a new revision of boards it would make sense to standardize at the base level which to me would be when CPS-B-21 was introduced with regards to the dash A board.
they probably "standardized" on the short a-board, and then when CE came out and they wanted more speed they changed to 12MHz . the PCB is the same between the short and the dash board, it's literally just a change in the value of some components.

given the number of revisions to SF2 Capcom really isn't about standardization so much as they are about incremental improvements.
 
they probably "standardized" on the short a-board
Totally, this is was around the time of the short 10mhz A-board's.
Long was first, then short, then dash, then q-sound/1.5 and finally CPS2.

It was a slow evolution if you look at it as incremental hardware changes on the A side.
 
Just tested few more games on a DASH motherboard and found 1941 plays overspeed.
It obviously means a multi would need two different A boards (10MHz and 12MHz) to play games correctly OR a way has to be found to switch between the two frequencies (by modding the A board to accept an external CPU clock for instance).
 
One thing I notice with regards to the A board revisions in SF2CE/HF is if you use the 10MHz board the startup rom checks are always garbled before completing and then show properly. On a dash board the text is always correct. That to me seems to be a good indicator of which board should mate with which however I don't have any other games to verify this theory.
Do you have a photo/video of what you mean?

Hyper Fighting on my dash board always starts a bit weird for me. My video capture card does weird things initially.
 
Just tested few more games on a DASH motherboard and found 1941 plays overspeed.
It obviously means a multi would need two different A boards (10MHz and 12MHz) to play games correctly OR a way has to be found to switch between the two frequencies (by modding the A board to accept an external CPU clock for instance).
SIgh, I was hoping this wasn't the case, but, yeah, there it is.

Anyway, you just need two oscillators, one at 12Mhz and one at 10Mhz and a switch or, better, a relay. Then the multi can send an impulse to switch the relay on 10Mhz or 12Mhz oscillator depending on the ROM loaded.
 
SIgh, I was hoping this wasn't the case, but, yeah, there it is.
Anyway, you just need two oscillators, one at 12Mhz and one at 10Mhz and a switch or, better, a relay. Then the multi can send an impulse to switch the relay on 10Mhz or 12Mhz oscillator depending on the ROM loaded.
I was thinking of generating two clocks with the ARM on the multi and send the clock signal corresponding to the game.
No oscillator, no relay or switch, all made with logic.
 
I was thinking of generating two clocks with the ARM on the multi and send the clock signal corresponding to the game.No oscillator, no relay or switch, all made with logic.
If the ARM is on the B board and the oscillator is on the A board how are you going to accomplish that ?

Some of the newer oscillators have a enable/disable pin where you could make a small replacement PCB with two oscillators and then enable the one you need with a simple switch. The advantage with the enable/disable signal is that then the clock pins can both be routed to the 68K and you can move the switch wherever you want.

Of course we need to find a 5V oscillator with a nice low PPM and an enable/disable signal.

Speaking of which does anyone know what the PPM spec is on the existing one used on the A board ?
 
I was thinking of generating two clocks with the ARM on the multi and send the clock signal corresponding to the game.No oscillator, no relay or switch, all made with logic.
If the ARM is on the B board and the oscillator is on the A board how are you going to accomplish that ?
Of course A board would have to be slightly modified (like cutting the trace from the OG oscillator and reroute it to the B board).
This or another solution where OG oscillator would be moved on a small daughterboard at the same place and connected to the B board. In this case the A board could still be used as a "normal" A board if disconnected form the B board.
This should be the only hardware modification needed.
 
I'd be ok desoldering the osc and soldering a wires or a connector in place. I would NOT be ok with cutting a trace. The ability to "Undo" the modification like nothing happenes is important to me, and I'd suspect others as well.
 
One question/concern I have is whether moving the crystal physically off of the A-Board will have any affect on the signal it produces? I know with some components their physical distance from the chip they are serving can impact the performance, so i don't know if that's something that needs to be taken into account.
 
I'd be ok desoldering the osc and soldering a wires or a connector in place. I would NOT be ok with cutting a trace. The ability to "Undo" the modification like nothing happenes is important to me, and I'd suspect others as well.
Yup that's also what I prefer.
One question/concern I have is whether moving the crystal physically off of the A-Board will have any affect on the signal it produces? I know with some components their physical distance from the chip they are serving can impact the performance, so i don't know if that's something that needs to be taken into account.
We're talking about only 12Mhz, of course an insanely long distance could be an issue but in this case I was thinking of moving the oscillator by only a centimetre as the daughterboard would fit at the place the oscillator was.
 
Cool. Yeah, I'm not too familiar with clock signal generators and their specifics. I didn't know if the location change would affect it. E.g. cause other unforseen errors due to signals generated off of that, etc. Glad that's not the case. :thumbsup:
 
One thing I notice with regards to the A board revisions in SF2CE/HF is if you use the 10MHz board the startup rom checks are always garbled before completing and then show properly. On a dash board the text is always correct. That to me seems to be a good indicator of which board should mate with which however I don't have any other games to verify this theory.
Is this what you are talking about? My Hyper Fighting does this for the briefest of moments on boot up. You need to frame scrub to even catch it. Tested on a couple of boards that have 12Mhz A boards and it seems to be normal.
 

Attachments

  • WhatsApp Image 2018-03-25 at 10.12.46 PM.jpeg
    WhatsApp Image 2018-03-25 at 10.12.46 PM.jpeg
    58.7 KB · Views: 142
  • WhatsApp Image 2018-03-25 at 10.12.49 PM.jpeg
    WhatsApp Image 2018-03-25 at 10.12.49 PM.jpeg
    29.7 KB · Views: 144
I've got some input that may or may not be useful, that ties in with talk of relocating the crystal and with the above images.

I found some cables that allow separation of the A and B board, so I can more easily work on troubleshooting a no audio issue on a 10mhz A board. The cables are about 2 feet in legth. I've checked continuity on every single pin of the 4 connectors and all are good. Powering the board gets stuck at the screen on the left, with the upside down character sprites (no text).

Not looking for help on my problem, and I haven't taken it past confirming connections are good on all pins, but wanted to offer the observations since it seems applicable to the discussion.
 
I've got some input that may or may not be useful, that ties in with talk of relocating the crystal and with the above images.

I found some cables that allow separation of the A and B board, so I can more easily work on troubleshooting a no audio issue on a 10mhz A board. The cables are about 2 feet in legth. I've checked continuity on every single pin of the 4 connectors and all are good. Powering the board gets stuck at the screen on the left, with the upside down character sprites (no text).

Not looking for help on my problem, and I haven't taken it past confirming connections are good on all pins, but wanted to offer the observations since it seems applicable to the discussion.
Same board, swap in CE ROMs and it boots perfectly.

I don't think this garbled text denotes an incorrect A board if this is what @sammargh is referring to. Seems to be something Hyper Fighting does maybe. I haven't been able to capture those images on my CRT either, only through a video capture card.
 
Last edited:
I've got some input that may or may not be useful, that ties in with talk of relocating the crystal and with the above images.

I found some cables that allow separation of the A and B board, so I can more easily work on troubleshooting a no audio issue on a 10mhz A board. The cables are about 2 feet in legth. I've checked continuity on every single pin of the 4 connectors and all are good. Powering the board gets stuck at the screen on the left, with the upside down character sprites (no text).

Not looking for help on my problem, and I haven't taken it past confirming connections are good on all pins, but wanted to offer the observations since it seems applicable to the discussion.
Cables shouldn't be an issue. I've built a set (4 flat cables with connectors at the ends) myself to help me in my repairs, lenght is ~50cm and never had any issue.
 
Back
Top