Super SD System 3

[waiwainl]

Plus I assume that it’s basically impossible for a GMT-8 person to own 2 Deunan products.

So true, So true

[strygo]

It wasn't clear to me in reading the thread, but it seems like the following cable would do the right thing:

https://retro-access.com/collections/fr ... nc-version

Am I missing something? I'm not an EE, so I'm a bit unsure.

[Fudoh]

it's not ideal, since it uses composite video for sync AND it has caps and resistors on the RGB lines.

It will work, but you can do better.

[strygo]

I would have asked in the other thread, but I've been threatened with a ban as well.

Fudoh: Got it, makes sense. I misread your reply.

[hyrulebr]

I’m still stoked to get it. The NeoSD is really good and I expect the ODE aspect of this will be stellar as well. And don’t mind opening it up to mod the resistors/caps to meet specs.

But yeah. I don’t understand why I was banned either. It sounds like they have a couple more days to make non-PCB design changes. And seeing as how making it fit spec should just be a matter of changing some smd values (I think). So why not jump on the chance to increase compatibility before it becomes an issue in the wild?

Plus, surely it must be cheaper to swap out smd’s Than make a whole cable.

was also banned for nothing. I've just linked a Rene's article about MD 2 cables....

The ban criteria is: Are you are new comer and comment anything about MD cables? Banned forever!.

[hyrulebr]

Retrogamingcables.uk just release a new version of MD 2 cable to use with Super SD System 3:

Available with no resistors or Capacitors inside the cable for use
+ on the Super SD System 3. Please select from sync type.

https://www.retrogamingcables.co.uk/seg ... packapunch

Well, one more cable to buy.

[strygo]

Cool. I'm sure Retro Access will do the same. I do wonder what they think when they see us buying so many of these cables.

[Fudoh]

I'm wondering if that isn't a little bit bold. No one has yet measured the actual output on the SSDS3 yet, right?

[ASDR]

I'm wondering if that isn't a little bit bold. No one has yet measured the actual output on the SSDS3 yet, right?

I hope those two parties were actually talking, right now it seems more like the actual components on the board are still up for discussion. What a confusing mess.

[DirkSwizzler]

I'm wondering if that isn't a little bit bold. No one has yet measured the actual output on the SSDS3 yet, right?

I hope those two parties were actually talking, right now it seems more like the actual components on the board are still up for discussion. What a confusing mess.

Yeah. I’m betting Rob is being proactive about meeting their outputs without direct contact. And if they call it good enough then where does that leave HD Retrovision?

Overall I would be happier if I could route the special audio back through my rgb modded port internally. But I’m assuming that is not possible without installing a switch since the supercd seemed to require its own output as well.

[SamIAm]

Is TTL Csync generated from the H & V a good thing?

The PCE outputs a slighlty off-spec c-sync - If I remember correctly there's a missing horizontal sync pulse after the vertical blank interval, which can cause bending/skew on the upper part of the picture on some monitors. SamIam made a thread about this sometime ago, and to solve the issue I think he ended up modding his PCE to extract the internal h. and v. sync, as documented by some unkown japanese guy he posted about.

So it is a very good thing

Hallelujah!

Yes, feeding the PCE's internal H and V sync digital signals into an Extron yields good C sync output and a stable picture. In fact, nothing else is necessary: the Japanese guy's mod to reshape the signals is redundant to an Extron. All I'd recommend is 600-800 ohm resistors in series on both lines to limit current.

I probably should have updated that old thread with this news, but it turns out that an Extron 160xi can turn the PCE's bad composite video sync into good sync, at least as far as an Ikegami monitor is concerned. All it takes is turning on the SERR dip-switch, which is supposed to erase the h-sync serration pulses in the v-sync pulse altogether.

Bizarrely, an Extron SS 200, which is similarly modern and has the proprietary ADSP (Advanced Digital Sync Processing) along with a SERR dip-switch, does not fix the problem. It's possible that other Extron xi boxes do not fix the problem, either.

[ASDR]

Yeah. I’m betting Rob is being proactive about meeting their outputs without direct contact. And if they call it good enough then where does that leave HD Retrovision?

The HD Retrovision guys have made adapters for other consoles to use their Genesis cable, maybe they can make one here as well.

[Xer Xian]

Hallelujah!

Indeed I remember you worked quite a bit on this matter, so I'm glad that you managed to sort it out!

I wonder if the SSDS3 really taps into the internal H and V sync signals as NeoSD wrote on the NeoGeo forum. Kinda strange imho that the developers had the foresight to ditch the troublesome but readily available c-sync but then didn't conform to the MD2 RGB output specs. I don't really care though, the SSDS3 single-handedly pushed me towards buying a Coregrafx and the Hori PCE fighting stick already

[Milspex]

ugh I just got the packapunch cable for use with the dbgrafxbooster. Now I need another cable for the super sd system 3

[mickcris]

They have said to not buy a cable yet as they are unsure of what they are going to do.
http://www.neo-geo.com/forums/showthrea ... ost4256847
"Please, wait a few days, we are deciding if removing the AC coupling from the cart and use a proper MD2/genesis2 cable or leaving it as is and using a passive cable. We'll have a decision in a couple of days. "



but like i mentioned before, most likely either way its probably going to be 75 ohms coming off of the THS7374 so you are going to have to mod the cable either way if you want proper brightness.

[Neodev]

Hi, this is Neodev from the neosd team.
We are currently looking into the way to provide the best output with the less user trouble. After consulting with some people from the console scene, it seems the best solution is removi AC coupling from the cart, so it uses the one in the proper md2 cable. It seems all our cablds just have the rrsistors in there but no capacitors. That was an overlook from my side, but we are still in time to replace components on the pcb.

I would also like to know your opinion on that solution. The other one is leaving it as is and providing passive cables with the cart.

[SmokeMonster]

Off-spec RGB is going to temper peoples' enthusiasm. Hopefully they'll decide to put on the brakes and revise the board to fix the problem instead of any small stop-gap measures. I imagine that a lot of people would like to be able to use their MD HD Retrovision cables with it.

[Fudoh]

@Neodev:

if the cables you've been using while testing your protos are stock MD2 cables and don't have a cap on the sync line, then they're configured for composite video as RGB sync anyway.

If you're going to include a cable it should be configured for CSYNC instead of composite video and it would have to be attenuated for 75 ohm sinks, so it's not only suited for PVMs and other high-end monitors (which don't care about the sync level you pump into them), but it has to be safe for consumer CRTs and video processors like the Framemeister or OSSC. Meaning: as long as you provide TTL level sync on the SSDS3's output including a completely passive cable isn't a good idea.

And there's the problem that mickcris mentioned above. Using a THS7374 you probably cannot simply mimic the MD2's RGB output behaviour which means that a stock MD2 cable won't give you the calibrated output levels you'd expect. For that reason (and because I don't use a MD2 anyway) I would prefer a perfecty adjusted onboard RGB signal (including 75 ohm CSYNC, not TTL) and then (and ONLY then) use a completely passive cable without any components on either the RGB or the sync line.

But for convenience reason I can - of course - understand people asking for compatibility with stock (and custom CSYNC) MD2 RGB cables. I just think that's much harder to accomplish than it seems. And also: do people really share RGB cables between systems ? Most users want to have their systems hooked up and ready at the same time, so sharing a RGB cable isn't very convenient to start with.

[strygo]

neodev: Thanks for reaching out here. Welcome! I've been admiring your NEO SD product but haven't had a Neo Geo so I haven't picked one up. So when I saw this new product, I jumped right away. Knowing that you've got a few more products in the pipeline, I'm quite excited for the community and for you.

My suggestion would be pursue a solution that doesn't require you to create and ship cables. There are widely varying needs out there and it would seem quite difficult for you to please everyone.

For me, once the specs are known, I plan to ask Retro Access (http://www.retroaccess.com/) to make one to spec. She can produce cables in various configurations, so for example, I'd probably get a longer (~7 ft) shielded cable that works well with my Hydra SCART switch. I've found that if I don't use shielded cables, I do experience unwanted interference. So I'm much less sensitive to needing a special cable, since I would like to use a custom cable anyway.

For other folks, if you had compatibility 100% compatibility with MD2 / Genesis 2 cables, that would be simplest for them. They could easily reuse their existing cables and not worry about confusing things since the system side of the cable would be identical. Separately, if you are 100% compatible with the HD Retrovision cables, you will appeal to another set of (likely mostly North American) customers who don't use RGB and want to go straight to YPbPr component.

That's my two cents. Thanks for listening!

[strygo]

I would prefer a perfecty adjusted onboard RGB signal (including 75 ohm CSYNC, not TTL) and then (and ONLY then) use a completely passive cable without any components on either the RGB or the sync line.

I definitely agree with this.

[DirkSwizzler]

But for convenience reason I can - of course - understand people asking for compatibility with stock (and custom CSYNC) MD2 RGB cables. I just think that's much harder to accomplish than it seems. And also: do people really share RGB cables between systems ? Most users want to have their systems hooked up and ready at the same time, so sharing a RGB cable isn't very convenient to start with.

I don’t share cables between systems in quick succession. But we’re already in a state where almost every console connector type has a really stable output spec to adhere to. With the exception of PlayStation 1&2, and ntsc vs pal Nintendo multiout.

Which makes it basically impossible to plug the wrong cable into the wrong console most of the time. Keeping it that way seems hugely beneficial over a quick fix of requiring a new spec.

Now, if it’s too late to fit the mega drive 2 spec, then it’s too late and I’ll shut up. But if it’s not too late. For the love of god don’t complicate the cabling space

[SmokeMonster]

I would prefer a perfecty adjusted onboard RGB signal (including 75 ohm CSYNC, not TTL) and then (and ONLY then) use a completely passive cable without any components on either the RGB or the sync line.

I definitely agree with this.

I do too. This would be ideal since it sounds like MD-exact RGB isn't possible anyways.

[strygo]

but like i mentioned before, most likely either way its probably going to be 75 ohms coming off of the THS7374 so you are going to have to mod the cable either way if you want proper brightness.

I'm very likely missing something, so please bear with me. Your earlier photo mentioned 75ohm, 220mf. This seems to match what Tim has documented here:



Wouldn't this imply that it already matches MD2 at least for R, G and B? Or is Tim's diagram out of date?

[svensonson]

I would prefer a perfecty adjusted onboard RGB signal (including 75 ohm CSYNC, not TTL) and then (and ONLY then) use a completely passive cable without any components on either the RGB or the sync line.

I definitely agree with this.

me too.
I want the best possible picture instead of the most convenient one.

[ASDR]

neodev: Good that you're here!

I'll join the choir and say that my ideal solution would certainly be compatibility with a stock MD2 cable wired for video level csync. I'd be happy to wait a bit longer to get that result.

If that's not an option for reasons like the one Fudoh pointed out, I'm not sure how I'd feel about an included cable. Like some others here, I'd need a cable that's a bit longer (at some point you've got enough consoles that they inevitable move father away from the SCART switch ) and I'd also go for a fully shielded cable as I find the non-shielded ones suffering from a bit of audio buzz, at least with my consoles and setup. I'm planning to get mine from RGC UK.

[DirkSwizzler]

Speaking about the 7374 amp. I sure hope the low pass filter is set to off.

[LDigital]

I agree 100% I have been in touch with rob from retro gaming cables since the announcement. He is watching and waiting for things to be finalised.
I agree 100% with the above comments from fudoh.

[cr4zymanz0r]

I'm the oddball that makes my own RCA break-out boxes for each system, so I kinda prefer all the required components be in the console/device so that it keeps the cable/breakout box simple. (Seems like I recall hearing it's better for the signal to be properly spec'ed before leaving the console than it is to be going out over spec on the cable then fixed at the other end of the cable, usually being the SCART hood in most people's case.

[mickcris]

but like i mentioned before, most likely either way its probably going to be 75 ohms coming off of the THS7374 so you are going to have to mod the cable either way if you want proper brightness.

I'm very likely missing something, so please bear with me. Your earlier photo mentioned 75ohm, 220mf. This seems to match what Tim has documented here:



Wouldn't this imply that it already matches MD2 at least for R, G and B? Or is Tim's diagram out of date?

The diagram is fine. Its that the Genesis/MD outputs the standard 0.7vpp and the PC Engine outputs 0.8vpp. So you cannot simply use the same cable and have the same results. I had posted a link in there to where Viletim had figured this out:

https://nfggames.com/forum2/index.php?t ... 1#msg34061

"Unfortunately the RGB signal the PC Engine is not 0.7 Vpp, it's actually 0.8 Vpp (I know because I bought a PC Engine a few months ago). To compensate for this I suggest attenuating the output slightly. Instead of a 75 ohm resistor in series with the output, you could use 86 ohms in series and 586 ohms to ground. This way it still looks like a 75 ohm output to the outside world. For E24 resistor values try 91 in series and 470 to ground. Not perfect but good enough - 0.67 Vpp is much better than 0.80 Vpp."


and I could have been wrong since Noedev says they are using a cable with resistors in it so maybe those are jumpers on their board and not 75 ohm resistors. Or they may have been testing with 150 ohms on the outputs.


I think if they removed the caps and would instead put a 15 ohm resistor (instead of a 75 ohm) and a 470 ohm to ground on the board, then a normal genesis cable would work fine. I have not tested this but I would think that would be electrically equivalent.

15 ohms would make it 90 ohms (instead of 91) and would make it closer to 0.7vpp.

[strygo]

Got it. Thanks for the explanation - I missed the subtly of 0.7 vs. 0.8V. It makes sense now.