Karbuncle

Rudy threatened me with violence and I had to block him on Facebook. He had a history of EXTREMELY self-centered behavior combined with cyber-bullying. I knew he was an asshole, but I didn't think he would end up murdering someone. Just terrible.

Guides for this and the RGB bypass mod: Neo Geo AES 3-3 & 3-4 Audio Restoration Guide Neo Geo AES 3-3 & 3-4 RGB Bypass Guide (works on other revisions too)

You're just full off piss-poor excuses today. Do you REALLY think you can speak for Krikzz and claim he switched just to appease someone YOU personally believe to be full of shit? Do you really think that? Fucking amazing, dude.

Here's the simple response to that: Krikzz wouldn't have changed to level shifters in newer revisions had it simply been a case of "who are we to say they are wrong?" Remember that applied physics like this isn't up for debate. When someone shows how it's actually an inferior method compared to level shifters with simple math and demonstrations of what happens to the leftover energy, it can't be reasonably blown off as an 'opinion'. Math is not an opinion.

Rene doesn't care what you think. I however, won't let BS slide when I see it.

That's a piss-poor cop-out after making an out-of-line remark that has no basis in reality. Rene has explained many times now (on Youtube in fact), that the law of thermodynamics PROVES the heat will be generated in the flash cart without level shifters. So if anything, it causes a shortened life-span of the flash cart itself, not the console. (Edit: Actually there is stress to the console as well, based on excessive current the digital out lines have to feed) The only point speculation comes in is on how much of a shortened life span the flash cart will cause. It may last 30 years or it may last only 10 years, and even that entirely depends on how much you use it every day. The key point though, is you can totally avoid even worrying about this problem by using level shifters in the first place. Hence why Krikzz started implementing them in later revisions. Had Rene been 'maliciously' making shit up, NOBODY would be even bothering to use level shifters. Now everyone that has half a brain and makes flash carts uses them. So how was that debunked again?

RGC decided to go with composite video and a sync stripper for the way they do 'csync' now. I do not understand why he went that route when all you need is 680 ohms and a 220uF cap on the actual csync line. I was able to get Retro-Access to switch to the 680 + 220uf combo, so at least there you can get a proper csync cable if you're inclined to give them a try.

Open both ends and check to see if he put a resistor and cap on the csync line, if not, you should add it yourself if you're able to use a soldering station. If not, don't use it any more, inform the seller he needs to add series 680 Ohms resistor and series 220uF cap on the csync line for proper attenuation. If he tries to argue, then he's someone not to do business with again. This has been thoroughly 'vetted' information.

Yeah the csync line needs 680 Ohms resistor and 220uF cap, which I mentioned in the other thread on that subject. But yeah, you can get amazing picture quality from the Jaguar with optimal timing in the OSSC. Here are some lossless screen caps I took while developing the OSSC timings: https://i.imgur.com/WLrZGSk.png https://i.imgur.com/PU5WG3L.png https://i.imgur.com/GUZL71s.png

An absolutely ridiculous stance to take. What he's actually saying is "I don't want to feel like I could have saved $200 if I had just waited a couple years". He's had plenty of time to enjoy the benefits of shelling out $400+, but to expect nobody else to EVER see the same features because the system is sold out is as I said, ridiculous.

Ste from HD Retrovision did some thorough testing both at load and internal, and also ran SPICE simulations for pin 5B. Here's what he had to say: "Finally got this knocked out. Derived simulation model results and bench oscilloscope results attached for both the signals at the load and internal to the console to verify it still operates properly. Series 680ohm resistor w/ 100uF to 220uF series capacitor. Actual capacitor is pretty loose as per the same reasons Bob talks about in that Saturn clip I linked earlier. 220uF probably makes more sense for cable manufacturers because they'll have that on hand. Therefore, I ran the attached simulation and bench tests using that. CSYNC levels internal to the console remain at the proper voltages as well. No need to add logic buffers and such. This should be sufficient." Below are screenshots of the scope and SPICE measurements: Scope at load: https://i.imgur.com/7J6u8eX.png Scope internal: https://i.imgur.com/6C6XYFi.png SPICE at load: https://i.imgur.com/xLalZbU.png SPiCE internal: https://i.imgur.com/WlTyYOJ.png So there you have it, folks. Just add series 680 Ohms with series 220uf cap and csync is good to go!

Did a video on Jaguar for the OSSC: Watch in 1080p full screen for best results. Cheers!

Cool thanks for the info. I know looking at the schematic and inside the console there is an FB inductor (L13) on the csync line for AC decoupling, but of course this does nothing to attenuate the signal. One question though: Does it really have to be 1.2K Ohms resistance? My understanding was that TTL csync typically just needs 470 Ohms resistance. Does the Jag need more because of the 2mA? Also while sync on luma works great, there are some displays and devices that will only allow csync. I know a sync stripper can be added to the luma line in those cases, but if the Jaguar has csync readily available, then it would be easier to just make a SCART cable that uses it with proper attenuation.

According to my optimal timing results with the OSSC, Tempest 2000 runs at a bizarre 351x227. Not 350, but 351. Here's a pic of my work for proof (RGB sync on luma feed) line4x OSSC optimal timing: https://i.imgur.com/H7rOO2X.png

I got sent several RGB cables to try out with the Jaguar while I develop OSSC optimal timing for it. One of the cables was RGB sync on luma, and I'm using that for now for safety concerns. Why safety concerns you may ask? Well because another RGB cable sent was wired for csync (pin 5B), but I found it didn't have any attenuation on the line. I contacted the maker of the cable and he swears he remembers measuring less than a volt under load for that output on his PAL console. At any rate, I decided to start doing research and come to find out this line is actually "VSL" (vertical sync) and yet somehow also works as a csync line (no clue how that works). The 1995 Atari Jaguar technical reference document on page 8 actually claims the "VSL" pin is in fact csync TTL +5V. I need to know resolutely: What is the load measurement of pin 5B for PAL and NTSC consoles? Is it truly a TTL csync output? If so, then RGB csync cables need to attenuate this line with a 470 Ohm resistor. Also, how is it the vertical sync pin doubles as a csync pin? Much appreciated to those experts in this field for their help on this!

Again, the 8:7 used in Super Nt isn't useful for any game. As I said the "8:7" everyone refers to in emulation for example is square pixels for games like SMW and SMW2. However, THAT 8:7 is based on horizontal inetergers (i.e. 1024 in 4x scale mode). The 8:7 found in the Super Nt is 1097 at 4x scale, which makes no sense at all. It's simply wrong for any game. Simple breakdown of proper "8:7": 256x224 active graphics = 8:7 At 4x scale = 1024x896. On the super Nt, "8:7" at 4x scale = 1097x896 (active graphics area). Thus, it is simply wrong.

Although Kevtris hasn't posted in a while, I'd like to request a couple of things for the next Super Nt firmware: 1. Get rid of the "1:1" and "8:7" modes in the "Screen Size" Menu. They are both not useful. Instead, add in "Sharp Square Pixels". This would base itself on the vertical being set to a perfect integer, so 4x would set this to 1024 with interpolation turned off, while 5x would set this to 1280 with interpolation turned off). The second option would be "4:3 for 16:9", which again is based on vertical being set to a perfect integer, making this 1170 with interpolation turned on for 4x, and 1462 with interpolation turned on for 5x. These are the 4 main modes anyone with attention to proper detail would want. 2. Extend vertical scaling up to 7x so that Super Game Boy active area can be scaled with square pixels to fill the screen. Much appreciated for considering these changes/additions!

You might be confusing 8:7 with 256* 8:7. The latter is the formula for CRT correction, while 8:7 by itself is the 'square pixel' ratio (as in 256x224 res is 8/7 ratio). The problem I think is that the "8:7" on Kevtris's usage is neither square pixels NOR proper aspect correction. It's simply coming up with a new res mode that doesn't match either scenario, so it has to be a mistake. Edit: Double-checked it, and it most definitely is wrong. When you use 8:7 with 4x for vertical, the active output area is 1097x896. That doesn't match square pixels OR proper CRT aspect correction. Square pixels is 1024x896 and CRT aspect correction is 1170x896, so what the heck is 1097x896? It has to be a mistake because it makes no sense.

Hey just wanted to mention my followup video to my recommended Super Nt settings, which shows a heck of a lot easier way to quickly change the resolution depending on what you want to play. It also discusses the bizarre 1:1 and 8:7 modes that Kevtris put in the simplified "Screen Size" menu that (at least in my opinion) seem to have no value or reason behind them. Neither mode gives you square pixel options, and it seems to me if you're going to have a simplified Screen Size menu, you'd want to include square pixel options. That's just me anyway, and perhaps someone could shed some light on what purpose they have. Now before people jump on me and claim the 8:7 mode is square pixels or that the 1:1 mode is, they are not. square pixels on a digital display would mean 1024x960 on the Supet Nt, or 1280x1200 on the Super Nt. Neither 1:1 or 8:7 make sense in this context. But anyway, here's the followup video:

Question for Kevtris concerning the new Super Nt 4.4 firmware: I noticed on the new firmware the ability to set dimensions like "4x" for vertical for example. However, even when setting these, if you go into advance mode's width/height, it won't be updated to the other settings. So for example you can set the system to 4x vertical, but in width/height, the vertical will still be at default 1080 when it should be updated to 960. Is it possible to interlink these settings, or does turning on advance mode simply override the previous settings? Just curious about this. Cheers and thanks so much for your continued work on this awesome system.

So I know it sounds like tooting my own horn (and maybe it is in a way), but I've been trying to get the "Smooth" palette put on more modern NES solutions. When you hook a machine like the Nt Mini or NESRGB with the "Smooth" palette into a PVM, it will look nearly identical to an NTSC NES composite feed at center dial settings. I tried to take a photograph of the two feeds show how close they are, but it looks even closer in person (click image to see full detail): I recall once asking Kevtris if he might be interested in adding it to hi-def NES firmware, but I don't think he was interested at the time. I know that RGBsource managed to get his own Hi-def NES firmware palette released, but I don't know how he pulled that off. At any rate, getting back to MSU1, I just want to state that is does serve an invaluable purpose for preserving Broadcast Satellaview games. I worked very hard on restoring the original broadcast soundtracks to BS zelda, which was released as an MSU1 game, and also my SFX work can be heard on AST MSU1 release as well. So while MSU1 is often just used to make fan soundtrack hacks, it has far more value than that, and I'm grateful for its existence.

I don't intend to do ANY modding of my Super Nt. I'm only interested in fidelity results. If it turns out that using a 1CHIP SNES console results in superior sound quality for MSU1 games, I want to make certain that's the case. It's purely for posterity, and possibly on the off chance that Kevtris has any sort of control over cart audio filtering in the Super Nt. If he doesn't, then it may just be a simple case where 'technically' the best experience for MSU1 audio quality is Higan or a 1CHIP console. Not a major issue though, but more a curiosity at this point.

:-)

Borti and I are in agreement that the amp effectively replaces the filtering circuit such that it it not needed, especially since the signal is being sent to internal SNES mixing/filtering anyway. However, testing has revealed that the sound output is nearly perfectly intact in a SNES junior when compared to digital playback in Higan. See the two graphs below showing the sound signature of the same track in both: Now compare the same playback in the Super Nt: Note the filtering in the upper rage seems much more aggressive. These pic are courtesy of Qwertymodo, but I'm going to be comparing direct capture results on my own SNES systems. I'm using a revision "F" SD2SNES that I upgraded with the sound amp myself as seen below: I will be doing a volume diagnostic test using the following: 1. Revision "APU" Super NES 2. Revision "1CHIP-03" Super NES 3. Revision "Junior" Super NES 4. Super Nt. revision 4.3 I'll also be measuring relative volume levels between all 4 devices to determine what setting the "Cart Volume" should be ideally set at for the Super Nt. I'll let you know how it all turns out, but for now, I thought those sound spectrum images were interesting to compare against.

Kevtris, if you don't mind me asking: Why did you go with a hard limit of 254 on the SNES color output? I notice your ramp starts at decimal 7 for the first non-black color and ends at 254-254-254 for pure white. Higan goes from 8 to 255 in comparison. The menu font for the Super Nt is set at 255-255-255, so of course the system is capable of using full range. Just thought it was curious. Also do you know if there's any sort of high-pass filtering going on in the Super Nt when it comes to MSU1 audio? We've been (me and Qwertymodo) have been doing some comparative sound test recordings of MSU1 played from revision H SD2SNES hardware in real SNES consoles like the Junior and 1CHIP, and noted there seems to be more filtering going on in the Super Nt than these systems. I've got more testing to do myself to make certain of this, but I'd thought I'd ask to see if you know anything about how the cart audio is managed in the Super Nt compared to real SNES consoles. Cheers!