shmups.system11.org

Use each others rom files then report back. Probably a bad dump.

Correct, all the way through, I even let it play twice, US version. Since the in-game trigger isn't functioning for me it kind of makes sense why I'm not seeing the crash that you see. I'm using the bin/cue rip of Ys 3 from archive.org if it makes any difference.

Same controllers?

I mainly use the Avenue Pad 6 button but I tried the SSDS3 on a friends TG16 yesterday with the standard TG16 controller and I still couldn't get the in-game trigger to work. I wonder if there is a way to reset the SSDS3 back to defaults, like a factory reset. It's really not that big of an issue for me but it would be cool to figure it out. Loving the SSDS3 so far.

Hello,

Yes, there is a way to reset it, just put a reset.cfg file (any file named like that, the arm just looks if there is a file called like that there) on the root of the microsd and it will get back to factory defaults.

BTW, have you tried to hold the trigger for long time ? 3 secconds may not be enough for some games and others may just reset the unit, if this happens just keep holding the trigger, don´t release the buttons ....

Alex,

The intention was to give a clean 5V TTL sync that could be feed to devices supporting TTL level sync, and also (attenuated) to ones using video levels sync, but it seems that some devices aren't recognizing it.

You are right, they are combined using an XOR gate, that gives positive sync pulses, and then inverted with a NOT gate to make it negative again (that NOT gate was missing in the first prototypes sync didn't work properly). They are fast CMOS gates, so they shouldn't add any noticeable delay to the sync.

I'm investigating more to see what's wrong with it and if it can be fixed with the current HW. I'll try to capture more signal data, although my scope is not very good. I should get a better one soon and hopefully will be able to better see what's going wrong.

In order to make the button checking code as small and less intrusive as possible (as it steals cycles from the main game code), the button checking is intentionally very simple so it may fail with some gamepads or multitaps.

Hopefully, after Neodev is able to provide measurement of the sync signal, a specific SSDS3 cable (or modding an existing one for the MD2) should be enough to solve the issue. It was always going to be the best solution anyway, given that the 0.8Vpp video output of the PCE was not addressed at the hardware level (if I understood correctly). This simply makes the awesomeness of the SSDS3, only slighly less awesome, so I'd say everyone should still be happy to own it

Btw, looks like owners of picky monitors (like myself) will still have to channel the output through an Extron interface to avoid the PCE upper skew issue..

I believe this issue was addressed by putting 22 ohm resistors on the SSDS3 board, so the inline 75 ohm resistors in a standard mega drive cable will bring it down to the correct level (but with an impedance mismatch that should not cause any issues).

For my RetroGamingCables cable I had to go to Vsync Threshold 11.84. Picture seems stable now and really good, with only that tiny hint of extra brightness/white that my PC Engine always seems to have at the top of the image. It's actually kind of a relief to see that the RGB problems were entirely down to the old crappy RGB mod and not some other issue with my console.

For great PC Engine justice!

I backup that suggestion. Krikzz and Darksoft have done the same. Works out great!

Has anyone tried using HD Retrovision's component cables with this device and/or in combination with OSSC? Wondering if you'll encounter similar issues as these various SCART cables.

Thanks for this, I wasn’t sure where to begin with tuning the ossc last night so ended up dialling in random settings and getting nowhere. At least I can potentially give this things main functionality a test tonight.

Also, the heat in this thread is really uncharacteristic of the forum. It’s not nice. The Neosd team have clearly made a mistake and acknowledged the fact. knowing how they supported their other product they will make it right somehow or another. Can we please take the intensity down a notch and direct attention to a workable solution instead. I say this as an affected 1st batch customer myself

I just tried the reset.cfg file and that def reset the settings back to what they were when I received the SSDS3. I went ahead and enabled the in-game trigger but still can't get it to work. I've tried holding select+run for upwards of one minute for some games. Is there a specific game the trigger works 100% with? I can use that for future testing.

I have just about every PC Engine gamepad made. So far I've tested with the Avenue Pad 6, the USA Turbografx with Turbografx Gamepad, and the USA TurboDuo gamepad.

Just to be clear do you press select+run or run+select(allowing a reset of the system) and continue holding past the reset? I've thoroughly tried both combos.

A big thanks to the NeoSD team for their transparency and support!

Hello,

Could you please send us an email at contact@neosdstore... with your serial number ? so we can prepare you a firmware update to force the trigger,
this will help us discarding things


Alex,

Done! Thank you!

Firmware update sent

BTW, you have to enter into the menu go get the update prompt to show (i forget to tell you about that on the email)

Thanks

Guys, this is the type of exemplary service you can expect from the NeoSD team and why I made no hesitation when ordering as soon as I heard this product was available. I'll test this once I get home, which won't be until 6PM EST at the earliest. Thanks guys!

Lets get it shorted before sing victory, but thanks for your words, i really apreciate this. Sometimes we are faster, others we are slower.

Alex,

I just got mine;
composite sync cable works OK on bvm no issues
csync cable does not

composite cable is 75R & 220uf on RGB lines, nothing on sync pin feed fed with composite din pin
csync cable is stock packapunch cable with 75R & 220uf on RGB lines & 220uf & 470R on sync line

I also cannot get back to the in game menu :/
Not so - works fine hold select down continuously then run...

Hi there Alex,

Is there a way for us to register our Super SD System 3's at this point? I tried creating an account on the NeoSD store but it keeps telling me I have an invalid serial # when I enter the one from my Super SD System 3's menu.

I also am looking forward to a fix to allow me to use my BVM & Framemeister. Is it safe to use either at this point?

Here is what I have occurring at the moment when using the Framemeister:
https://www.twitch.tv/videos/219371596?t=1h5m35s

During any screen scrolling colors & brightness fluctuate across the screen.

Here is what it looks like directly to my BVM through my gscartsw lite as well:
https://drive.google.com/drive/folders/ ... sp=sharing

I also had the system freeze up a couple times on me when using the default exFAT format on a 128gb Samsung SD card but I think the card was goofed up so I reformatted it to FAT32 recently.

Out of curiosity what was R35's original purpose? I noticed it is missing / removed.

I received one of my csync MD2 cables today. Opened it up, all four capacitors and five resistors are there, values & polarity all good, everything nicely shrink wrapped and isolated, cable looks fine

I tried with the SSDS3 on two LCD HDTVs, one gets no sync, the other one works. OSSC also gets no sync until I increase the VSync threshold to 11.84 like it has been helpfully suggested before (thanks!). Yeah, seems like there's something is not quite on point with the csync output. I have a dozen+ other consoles that all work with these two TVs and the OSSC with stock settings.

What I'm currently trying to figure out is why both audio & video are so poor compared to the internal RGB mod and standard audio output of my PCE. The video has *a lot* more noise than the 7316 based RGB mod. Looks like analog TV during a thunderstorm on the compatible TV and a good bit better going through the OSSC. The latter clearly has better filtering. The audio has a much higher volume whine. I know that all PCE consoles have that annoying audio whine. I recorded mine directly into an audio interface (https://soundcloud.com/user-961563879/coregrafx-whine), so I have a pretty good idea what that sounds like on the stock console through the standard stereo out. I haven't done any recording of the SSDS3, but when volume matching the two outputs by ear and listening to the whine it's significantly louder from the SSDS3. From the stock stereo out it's mostly noticeable in pauses between the music and since the audio level out of the PCE is quite solid I can turn down my amp a bit and it's not that obvious. Through the SSDS3 it's tinnitus sound the second I turn the system on. Stock AV-out is pretty quiet in the SSDS3 menu.

So, obviously I'm not just comparing two different AV-outs but also two different cables. The DIN8 cable for my RGB mod is pretty basic, not individually shielded and carries composite video, so I expected that to be the baseline at best. I quickly hooked up audio directly to the MD2 out from the SSDS3 and a unscientific first listening test without any video hooked up seems to confirm it's still sounding noisier than the stock stereo out.

I'll have a fully shielded cable from RGC ordered, that should hopefully eliminate any possible issues caused by the cable, but I wonder if there's any more troubleshooting I can do in the meantime? I have a decent size collection of consoles and over the years used AV cables ranging from 5$ china crap to fully shielded stuff from RGC and I've never seen picture & audio as bad as what I currently get out of SSDS3 with this MD2 cable I just got. It's pretty bad :/

I too am seeing some wavy noise in the video signal. Tested on both a PVM and OSSC setup with the same results.

I was waiting on a new scart cable to arrive before bringing it up.

Well, seeing that increasing the vsync threshold fixes the issue, it seems clear that the cause is that hsync pulses are too wide, over the default ossc value, and thus, it can't tell apart hsync pulses from vsync. Increasing the value above the hsync value (in my scope they seem between 10 and 11us, hard to tell as my scope resolution is low) makes it properly detect vsync.

About the video and audio quality, I can tell it looked quite good for me, except for the jailbars but there is noise. Maybe an internal mod is better because it takes the rgb right at the video chip, and avoids long path from the chip to the external connector, and then from the connector to the amp. The same for audio, the internal output is closer and probably cleaner. PCEs seem quite noisy inside and so, the longer the track, the more noise it picks.

Still not, i hope to get some time over the weekend to insert the serial numbers on the database and add the new product. Its a short task but everything takes time.

Alex,

Excellent. Thanks for letting us know Alex.

In regards to the video signal I would highly recommend taking any advice Voultar & Tim send your way. They are both highly experienced with RGB bypass amps and getting proper attenuation from various devices.

Not to sound rude but if I were trying to resolve an issue like this I would probably see if one of them would be interested in working temporarily on the problem to get it fixed up as quickly as possible for a bit of cash money. The trouble it could save would certainly be worth the investment.

From one newbie on this forum to another..I'm not sure this is helpful dialogue. Everyone is well aware of Voultar and Tim's expertise and they have already provided help in this very thread (that neodev took) on other aspects of the RGB implementation.

I have done internal mods on various white PCEs and on a couple occasions attached the RGB lines to the solder side of the expansion port connector rather than directly to the Hu chip.

And there was little to no noise in the video output.

And I have seen people put PCE RGB amps externally in small boxes that then plug into the expansion connector. Then a scart cable plugs into the box. Also, there was little to no noise there.



I think you guys might want to investigate this closer rather than dismiss this as being a signal length issue.

So you are saying use an internal mod instead of the Super SD System 3 for rgb?