So a few weeks ago I saw a post on Twitter where a Japanese user had what appeared to be some type of PIC microcontroller connected to a CPS2 B board, giving the impression it was loading the decryption key at every boot so there is no battery needed. Unfortunately it seems impossible to re-find random things on Twitter, and it was all in Japanese anyway. However, it got me thinking about trying to implement that same concept using an Arduino Nano since they're fairly small, clones are extremely cheap, and basically just need a mini USB cable to program them. I forked the ArcadeHacker CPS2 Arduino key writer and modified it to work on (assumingly) any Arduino without an LCD shield. You would just put the key on it for the game you install it in, then you could just boot the game battery-less forever with no altered/phoenixed roms, in theory. I used the serial monitor in the Arduino IDE to verify it's outputting the key correctly, but I haven't had time to solder it into a B board to test on actual hardware yet.

One drawback I noticed is that writing the key exactly how the ArcadeHacker program does, it takes roughly 9 seconds for it to write the key. This means basically each time you power on the game it'd take an additional 9 seconds to boot. I assume this can probably be shortened since there are multiple delays in the code, but I don't know if the CPS2 hardware gets fickle if the key is written too quickly. I know the Darksoft CPS2 multikits just rewrite the key at power-on for the last game you loaded, and I was thinking it was nearly instant, but I'd need to go back and check. Last edited by on Thu Oct 11, 2018 3:56 am, edited 2 times in total.

Ok, I got a chance to hook this up today and test it out and it works. I also was able to drastically reduce the key write time so that booting is barely any longer than on battery. I'm uncertain if the much faster key writing might cause issues or not on some B board revisions, but it worked fine on the 93646B-6 revision that I tried.

Here's just a couple of quick basic pics I took of the install:. The Arduino Nano is just mounted with a double sided 3M adhesive pad No more worrying about battery corrosion, changing batteries, or reflashing keys manually Last edited by on Thu Oct 11, 2018 3:56 am, edited 1 time in total. So, one negative thought on this. Is it possible that doing repeated writes to the encryption controller will cause it to become unwritable at some point?

I mean effectively, they were designed to be re-written to maybe once, twice at the most. I don't think capcom predicted that the games would have a lifespan much beyond probably 1 battery failure. It's probably a low likelihood, but just a thought. I suppose the new revision Darksoft kit users who are using the encryption key writing feature would be the case study on this. I've got a nano on order, definitely want to give this a try. So, one negative thought on this.

Is it possible that doing repeated writes to the encryption controller will cause it to become unwritable at some point? I mean effectively, they were designed to be re-written to maybe once, twice at the most. I don't think capcom predicted that the games would have a lifespan much beyond probably 1 battery failure. It's probably a low likelihood, but just a thought. I suppose the new revision Darksoft kit users who are using the encryption key writing feature would be the case study on this. I've got a nano on order, definitely want to give this a try. My guess is since it has to be battery backed normally that it's some type of RAM/SRAM, which wouldn't really have a limited amount of writes to my knowledge.

That's just educated guessing on my part though. I bet Artemio would know more. Would also be interesting to see if this is a potential solution for the folks that have had so much difficulty with rev -4 boards (myself included). Going to use my ST board as a guinea pig, which I had trouble desuiciding at one point. If you've had trouble with the regular ArcadeHacker CPS2 Arduino key writer, you'll probably be in the same boat with this. Mine is basically doing the exact same key writing process (just no menu selection part), with the only real difference being I lowered the delays in the code so it wouldn't add 9 seconds to boot time. I've got 2 other B boards on battery that I intend to mod as well soon, but I don't know what revisions they are until I open them up.

So a few weeks ago I saw a post on Twitter where a Japanese user had what appeared to be some type of PIC microcontroller connected to a CPS2 B board, giving the impression it was loading the decryption key at every boot so there is no battery needed. Unfortunately it seems impossible to re-find random things on Twitter, and it was all in Japanese anyway. This came up recently on my timeline: The same user posted several tweets showing their work on the project. Btw, would this modification also work on a dead/suicided B board? Sorry I am not really up to speed on the latest CPS2 developments.

So, one negative thought on this. Is it possible that doing repeated writes to the encryption controller will cause it to become unwritable at some point? I mean effectively, they were designed to be re-written to maybe once, twice at the most. I don't think capcom predicted that the games would have a lifespan much beyond probably 1 battery failure. It's probably a low likelihood, but just a thought. I suppose the new revision Darksoft kit users who are using the encryption key writing feature would be the case study on this. I've got a nano on order, definitely want to give this a try.

According to Leo, the key is stored in RAM and 'SRAM and DRAM have absolutely no limits on how many times it can be written or read.' ( from ) So should be a non-issue. This is a very imaginative solution for those who don't want to use a battery yet who still want to play the original, unmodified code. Very nice work. Because of the lack of the CN9 header on B board revisions 93646B-3 and 93646B-4 I guess it won't be possible to easily connect up the Nano (wires will need to be soldered to suitable points instead), although the the header is of course present on B board revisions revisions 93646B-5, 93646B-6, 93646B-7, 97691A-3, 97691A-4 so that's nice and easy.

Formerly known here as R-Typer Arcade game board repairer (known as ' Irongiant' and ' Vectorglow' on other arcade forums). Personal preference. To use an analogy, its akin to restoring your 69 Camaro with a new replacement part vs nos or original. Many are now using original code and encryption on the darskoft kit, as key writing was implemented on it some time ago.

To give it some context, check out that thread at arcade projects that iron giant linked. Tons of interest for the next evolution of this concept, which is a preprogrammed board that solders directly onto the appropriate pins. Sent from my SM-G955U using Tapatalk. Personal preference. To use an analogy, its akin to restoring your 69 Camaro with a new replacement part vs nos or original. Many are now using original code and encryption on the darskoft kit, as key writing was implemented on it some time ago. To give it some context, check out that thread at arcade projects that iron giant linked.

Tons of interest for the next evolution of this concept, which is a preprogrammed board that solders directly onto the appropriate pins. Sent from my SM-G955U using Tapatalk I guess perception is reality. I am more a gamer than a collector. An analogy of how I see it is having a choice between two identical 69 Camaros. One has an alarm that causes problems.

The other has had the problematic alarm removed. I get it for collectors though. I'm not sure how running encrypted code.with a battery, or with a nano, or with a infinikey, or with a dark soft kit, is causing a problem. Sure if you want to run on battery then a good maintenance schedule is in order. But at the same time, theres boards still running on original batteries.

This could turn into a lengthy discussion with little value offered. No point arguing one is better than other, but also no point arguing that running original code and encryption is a problem or an issue. At the very least, if your battery has failed, you dont have to remove the original stickers and wipe/reprogram roms, if you dont want to. Sent from my SM-G955U using Tapatalk.

We know that the latest revisions of Wii consoles from 2012 has the best visual clarity compared to the other revisions, but what about the visual clarity of Wii games when played on a Wii U through component outputs? The Wii U has the actual Wii hardware inside of it (unlike say the Xbox One and PS Vita which uses software emulation to run respectively Xbox 360 and PSP games) and actual runs just like a Wii if you use it with a component (480i and 480p) or RGB scart cable (only for PAL units and limited to 480i and 576i). Anybody noticed any difference in quality between playing Wii games on a 2012 Wii (RVL-101) and a Wii U in 480i/p? Wii games using component is not the same as Wii games using HDMI.

For one, with HDMI you will not get a 4:3 aspect ratio, but you will get a 16:9 output with black bars on the left and right sides for the games that are 4:3 such as Opoona, secondly, with component there is no 16-235, this is a digital thing, if you manage to send a 16-235 signal to an analogue display (CRT), the blacks will be grey, 16-235 is for digital display such as LCD. For Wii games running on the Wii U using the Wii component cable or the Wii Scart cable (only released in Europe and only works on PAL Wii/Wii U) will run the same way as they would on a Wii if running in 480i/p. Wii games using component is not the same as Wii games using HDMI. For one, with HDMI you will not get a 4:3 aspect ratio, but you will get a 16:9 output with black bars on the left and right sides for the games that are 4:3 such as Opoona, secondly, with component there is no 16-235, this is a digital thing, if you manage to send a 16-235 signal to an analogue display (CRT), the blacks will be grey, 16-235 is for digital display such as LCD. For Wii games running on the Wii U using the Wii component cable or the Wii Scart cable (only released in Europe and only works on PAL Wii/Wii U) will run the same way as they would on a Wii if running in 480i/p. I'm pretty sure everything Extrems said in that post still apply when using component output, just maybe not the colorspace conversion?

Shmups.system11.org View Topical

And as a side note I'm also pretty sure the 16-235 thing existed in broadcast long before digital displays ever existed, it's wrapped into the whole NTSC blacker than black thing. If you transfer the idea of limited range signals to a DC offset used on analogue component signals, then yes. But what's more important on the consumer end (and what lawfer meant): there aren't two versions in general use. If your display is calibrated using a PS2's component output (or that of a DVD player), then the WiiU won't suddently use a different voltage range to render the brightness levels. I find the use of limited range RGB on HDMI just wrong.

One of the most horrible decisions on the HDMI specs. Full range RGB (as used on DVI) is the way to go and if somebody wants limited range (maybe to stay true to the digital YCbCr compression on DVD/BD/DVB), just use YCbCr 4:4:4 over HDMI in the first place.

I'm pretty sure everything Extrems said in that post still apply when using component output From the way he talks about it seems to indicate that he tested Wii games through HDMI, not component, from what I understand playing Wii games on the Wii U using component the games will run as they would on a Wii. I just tested some Wii games on the Wii U with component cables in 480i/p and I didn't notice any glaring issues compared to how the games look when played on my RVL-CPU-30 US Wii with component in 480i/p, basically it seems the limited range RGB of the Wii U only affects games when ran through HDMI and the other issues such as upscaling stems from HDMI, by restricting it to component without upscaling (so 480i/p only) you can avoid these mentioned issues. Though I don't have the tools to do a more in-depth testing and comparison like this. Just tested some Wii games on the Wii U with component cables in 480i/p and I didn't notice any glaring issues compared to how the games look when played on my RVL-CPU-30 US Wii with component in 480i/p, Then you didn't look close enough.

Wii U does not show pixels 1:1 in 480p or 480i mode. There's a layer of scaling added. It makes everything look blurry and just a little 'off'. I've tested them back to back on my PC CRT monitor, with the same component cable. An original Wii is the only proper way to play Wii games at 480p/i.

Did Nintendo ever get something right/stand on top of what was current when it comes to video quality or backwards compatibility? You generally have to hunt down specific revisions (1CHIP SNES, later Wii's), or outright mod the hardware (NES,N64), or softmod to restore BC (Wii U's Nintendon't, but I'd guess it's bad anyway?). The Gamecube with its digital out is probably the only exception (but we never got to enjoy that in Europe).

Shmups.system11.org View Topics

They did manage to screw up GB/GBA support via botched GBPlayer software though. If someone with the right knowledge looked into this, the vWii video output problems could potentially be fixed. The Wii U has a microcontroller called the DMCU which emulates the Wii's video interface (VI) and it runs its own firmware. I posted this info here:- Its worth noting that cafe2wii loads the DMCU firmware when vWii mode is started, and the DMCU is only used for vWii mode, so in theory it should be quite safe to disassemble/hack the DMCU firmware until you get the desired results without any risk of bricking the Wii U. Nintendo themseleves updated the cafe2wii title (004000) to v1 with system update 4.0.0, although they dont appear to have fixed any of the issues Extrems mentioned. An original Wii is the only proper way to play Wii games at 480p/i Is that so?

Damn, F'ing Nintendo! Anyway thanks for the confirmation, guess i'll stick with my RVL-CPU-30 (even if it doesn't have the best output compared to the RVL-101 models) and maybe I might get a RVL-101 down the line. The best option for Wii is an RVL-CPU-60 since it's the very last revision of the GameCube Wii and has picture quality on par with the RVL-101 models.

Shmups.system11.org View Topic Configuration

I would love to know how it was determined that only the later Wii's have better component output. All the information I have seen doesn't appear to make it clear what motherboard revision was being tested/compared, or what brand/model of DAC/Video Encoder chip was inside the Wii.

I posted some info here:- But nobody really answered Last edited by on Sun May 07, 2017 12:44 am, edited 4 times in total. Did Nintendo ever get something right/stand on top of what was current when it comes to video quality or backwards compatibility?

Yeah, on the Nintendo Switch. It has HDMI output up to 1080p with Full Range RGB being finally available.

Before that, not at all. They cancelled RGB output for Nintendo 64 mid production resulting in Nintendo 64 which had unfinished RGB output board capabilities, locked out analogue RGB output for the GameCube and Wii only for PAL units, released the Wii U locked to limited range RGB, released the Wii which was analogue only and 4:3 SDTV in the age of HDMI/Digital and Widescreen (some Wii games such as Nights: Journey of Dreams apparently supported Dolby Digital, which could never be taken advantage of), removed component output capabilities out of the GameCube, the list goes on. Outside of video capabilities there is the fact that both the Wii U and Nintendo Switch only have about 25Gb of internal memory (they say 32Gb, but you don't get that), so you can basically install 1 game at most on them.