(PS1) Mayumi 4.0 12F683, 12F675, 12F629

So recently I ported MM3 for PICs 12F675 and 12F683, now I'm pleased to present Mayumi v4.0 for PICs 12F683, 12F675 & 12F629.

I tested the NTSC-U versions of each PIC on SCPH-9001 and SCPH-5501 and they worked perfectly (including stealth). I can't test them on each model as I don't have them all. I also don't own any PAL or NTSC-J consoles so I applied the same code changes to these versions, but am unable to actually test those versions, so I'm hoping they will work.

Limited testing has been done before release, use at your own risk.

Thanks to Zer0-2k11 for linking me to the PIC disassembler (PIC-Disasm v1.6).

Please leave a comment if you tried it out.

Compatibility:
12F675 Hex: 12F629, 12F675
12F683 Hex: 12F683

Hex files, source code (.asm), and install diagrams included.

Download link:
http://www.mediafire.com/download/hnvyowfez93w6d1/Mayumi+v4.0+12F683+12F675+12F629.zip

Enjoy!

 

May I ask the point of porting every old modchip variant to semi-recent devices? The source appears to be clumsily written so why not just start over, cobbling the algorithms into a single firmware supporting all PS revisions? The cost difference for devices under $1 is pretty negligible. Some of the faster PIC can probably even do BIOS patching and more.

 

You answered your own question.

It's mostly as the disassembler made it. If it works, what's the problem?

If you want to undertake such a task, feel free. Mayumi v4 supports all revisions except for 100x.

Regardless of the price differences, some people may have newer PICs already on hand.

Again, if you want to undertake that task, feel free.

If this port helps out even a few people, then I feel it was worth it.

 

The point is to solve an availability issue? There are >17k 12F508 @ Digikey.

The disassembler should yield the exact assembly (minus labels, macros and comments etc) so it's the program itself that I'm calling sloppy which lowers my confidence in it. Your effort to directly port old firmwares gives the old firmware pretense, which it possibly doesn't deserve in this more enlightened age, in my opinion. Still the algorithm(s) could serve as a base for a unified firmware, which is more likely lead to more critical analysis and improvement.

It doesn't have much educational value, and it may not work as well as it could; there is likely non-ideal timing, and some output drivers may be stressed more than necessary from prolonged overriding etc.

Great, so it definitely has room for improvement.

 

In my tests it performed just as the original one - which was the goal.

Not at all. Read my point again:

Besides, I don't see the bad in porting code to different/newer PICs. It's a good thing to make it available on more devices.

If you disassemble the original Hex and compile it again, it will produce the exact same Hex file again... I've even MD5'd it and it was the same. So it does what it's supposed to.

If someone can gain educational value from it, that's great. However, that wasn't the intention.

Want support for 100x? Use MM3, Stealth 2.8, or many of the others that work in it.

If you want to add all sorts of improvements then again, feel free to do it. This was not my goal. In fact, I'd probably even help you test it.

I'm not sure why you're being such a hater about the whole thing.

 

I don't think Calpis is being a hater here, but is raising a fais point : playstation protection has been widely explained thanks to various people like nocash, and having an universal modchip working on recent pic would be great. But of course, it requires advance knowledge on Playstation and PIC/AVR.

 

You mean like this?

 

You still need to have one hex for each region, so it is not universal

 

Each region has a different SCEx string.

 

It's absolutely useles adding 3 string regions SCEx in the hex code for the only pupose of universal mochip. If it was removed on the new mayumi (multimode it's a "less precise" copy\paste of the mayumi with int osc) codes there's a reason

I don't see why criticize mord.fustang operate with useless requests...

 

thanks for the release, the more ports the better , one never knows what kind of PIC he has available to mod a console , there are people that can't order from digikey or other huge stores without paying a 25-30eur shipping fee (me for example) and in reality the only source is eBay which means 2-3 weeks waiting time... so ports are good in my book

 

It is not criticizing, just saying there is room for improvement for a Playstation modchip : better timing, etc...

mord.fustang said himself it wasn't his goal, and this thread may interest people who want to have a new project.

 

Not that it has anything to do with my point but of course it does, you're porting between two identical architectures.

It's not bad bad, but I see it as unnecessary since the original devices are widely available if someone decides they want to use old firmware.

From my perspective it seems like you're sort of both endorsing and revitalizing these firmwares that IMO should stay in the past because of their scene connotations, and by left in the past I meant left in their original form, locked away in some WinACE archive. Maybe then the pretension could be forgotten and better engineering could take their place.

Also I was curious about the reason behind (redundantly?) porting multiple firmwares to these PICs since as you say they're each mostly compatible with every PS revision. If you have a crapton of these specific PICs that you need to use, I can understand why you are doing it, but from the standpoint of a project that you're "pleased to present" to people, it doesn't make much sense to me since IMO you're solving a non-problem as far as I can tell because the select few target PICs don't seem to be any more available than '508s, and the code is identical.

Maybe if you concede that it's always better to redistribute prior work, but it's still not terribly useful to anybody without those specific PICs, or even necessarily useful to people with them since if someone's into PS modding they probably also have '508s which needn't any modification.

If you instead disassembled the firmware and distributed the source with a MPLAB project file, anybody could then use that to build object files for a huge selection of PICs since they all have the same timing. That might also lead to improvements, whereas redistributing the same firmware 14 years? later could give people the impression that these are actively developed.

I very well understand. We're having a problem communicating.

This can be solved numerous ways: preprocessor directives could unify the codebases so the region is chosen at build time, or for a universal object file a PIC with EEPROM or self-programmability could change the string in-system or via manual setting at installation, or it could probably be dynamically detected with enough effort.

I kind of disagree, but I hope you could understand the benefit of unifying the assembly code at least... Unifying the hex/object can be beneficial organizationally if any improvements are to ever be made because it keeps the regions and features synchronized and it allows you to keep one programmed chip on hand for whatever hardware you come across. Sure it's not necessary, but none of this is. Plus it would show users that the code has been touched in the last decade.

I didn't make any requests, I was trying to understand the motivation and explain my reasoning behind questioning it. Mord.Fustang shared the reasoning, and I still don't understand, but I'm moving on, no point in sinking more time into this and I don't mean to cause more offense.

 

Calpis, you're repeating many of the same points that I've already replied to.

You're welcome!

 

I appreciate this! Something to note on the 12F629 installed in a PU-23 (900x), you might want to use the alt Pin 1 (Vcc).

I posted here regarding it: http://www.eurasia.nu/modules.php?op=modload&name=Forums&file=viewtopic&topic=6758&forum=82

But the technical notes from my findings are:

 

djelaba@ can you tell me what are these timing problems for example please? I don't see what someone can improve from last HEX code of mayumi for example...

I know very basic of asm, but unyfing the tre string code in one hex would be useles because the stealth modchip don't work anymore (IIRC the AMod routine check if the chip send the tree different strings )

Maybe a can someone cann add cosmetic feature like old led state on first hex (mm2.x o mayumi v.1x\2.1) maybe removed from v3 codes for pic pins problem?

 

I personally haven't had any trouble using pin 1 instead of alt pin 1.

The 12F629/12F675 & 12F683 datasheets both state:

I can't find anything that specifically states that it needs 5V. That being said, I'll give alt pin 1 a try and see if the results are the same next time and it's still good advice for others to try if pin 1 isn't working for them. Thanks for the info!

 

MM3 doesnt work on 100x with stealth. Stealth 2.8a doesnt work on them all either fyi.

 

I haven't tested it myself but in this thread some users reported that using TriMesh's diagram, you can get partial stealth with MM3 on 100x.



I thought that Stealth 2.8a worked on all models but only provided partial stealth?

 

wow, it will sure help me, thanks
may i ask if you plan on releasing the ONEchip hex for newer pics ? that would be nice