PSNee further development

[rama3]

Hope you can see everything:

[EmteCoke]

Hope you can see everything:

Thank you so much...

[coops375]

Hi,

I decided to use an arduino pro mini as the chip. It programmed fine as I used an arduino uno.

I have a PS1 PU-22 and now finished with the soldering to the points on the PCB/Arduino.

I've just burnt a back-up game and it doesn't work so clearly I've done something wrong.

Can anyone spot anything wrong with my installation?

https://ibb.co/jzkEsp
https://ibb.co/hV19Q9
https://ibb.co/neFsdU
https://ibb.co/hZxG59

Thanks.

[rama3]

If you followed the installation picture, then there's not much room for error.
The only problem with the installation is those long wires.
It's better to decide on a resting spot for the Arduino and then cut the wires just as long as necessary.

Your real issue is probably something else.
- Is this a Japanese PSX by chance?
- Did you prepare the code (sketch) for your Pro Mini?
- Does the LED flash / do anything?
- Did you try an original disk of the correct region, then an original of the wrong region?

[aarkay14]

I mostly lurk (sorry!) but I was wondering if someone had a wiring diagram for PU-20 US/NTSC board? I've probed and figured out where the gate/data signals are, but I'm not sure where to start to find the SUBQ/SQCK signals required for the arduino sketch.

As you probably worked out, the GATE/DATA pins are the same as the PU-18. Best place to pick off the subcode signals are the test points that are just next to the mechacon CPU:

Heyy!

Can you tell me where is VCC, GND and GATE on PU-20? I am so lost!

-Rama

[aarkay14]

OK I found it! in the link below:

http://modchip.aeug.org/install/508-pu20-stealth-2.html

[superg]

According to the CD Subchannel Q documentation, the last two bytes of 12-byte subcode packet are crc16. However my observations and SubQ dumps I've seen in this topic indicate that the last two bytes are something else.

Code: Select all

41000198372500000200 9F7F
41000198372600000200 FCFF
41000198372700000200 9F7F

Can anybody clarify, am I missing something?

[rama3]

I haven't studied subcodes enough to tell you what this is (didn't have to for this mod ;p), but I think these bytes don't always have to be CRC.
One other thing was, iirc, just a volume level readout for CD audio.

[superg]

I haven't studied subcodes enough to tell you what this is (didn't have to for this mod ;p), but I think these bytes don't always have to be CRC.
One other thing was, iirc, just a volume level readout for CD audio.

Yeah, it does look like the volume when I use audio CD, getting 0 interleaved with 0x8000.

[rama3]

Funny thing:
Check out the readings on a PU-20 or later when it boots up.
You can see the controller faking subcodes, to encode the unlocking symbols in them!

[superg]

Funny thing:
Check out the readings on a PU-20 or later when it boots up.
You can see the controller faking subcodes, to encode the unlocking symbols in them!

Oh, I'll get to my other PSX boards later, I started with PU-18 for now.
I'm currently designing a PCB for psnee based on ATtiny, nothing fancy, the controller (SOIC), decoupling cap, ICSP and solder points. Want to have something similar to what they manufactured for PS2, minimal clean PCB with components only on top layer to be able to use two side tape and attach it to the mainboard. Want to have it simple like it was in PIC times, using arduino is fun for debug but IMO it's overkill for the permanent installation. Also the plan is to make nice hi-resolution installation diagrams for all revisions, I have 7 different revisions so far. And "port" PM-41 bios patching to ATtiny, shouldn't be hard, just need to have 12V hi voltage programmer ready.
Currently I forked psnee and made some hysteresis calculation changes. Basically it's all the same but I defined SubQ structure and reorganized the code branching which made it more readable I think and also saved some firmware bytes. If you're curious, everything is here: https://github.com/superg/PsNee
I also have other plans but that's for later.

[rama3]

Awesome, I love it!
It's looking like the readouts would be much nicer with this. The code is definitely much more readable

Someone suggested a good simplification for the console region selection.
This goes on top:

Code: Select all

//#define FIXED_REGION 'e' // Set PSNee to only work with the specified region. Slightly improves boot times. Values: 'e' (SCEE, PAL), 'a' (SCEA, US) or 'i' (SCEI, JP)

And then:

Code: Select all

#ifndef FIXED_REGION
	inject_SCEX('e'); // e = SCEE, a = SCEA, i = SCEI
	inject_SCEX('a'); // injects all 3 regions by default
	inject_SCEX('i'); // optimize boot time by sending only your console region letter (all 3 times per loop)
#else
	inject_SCEX(FIXED_REGION); // injects user defined region
	inject_SCEX(FIXED_REGION); 
	inject_SCEX(FIXED_REGION);
#endif

I think it'd still be best to force users to make a decision on the board used.
My version had the board unset to do this, with an error define that tells users what to do.
I don't know any more automatic way that surely works, but maybe you do? :p

It's great someone picks this up. The project definitely needed some shine and polish.
I never had custom PCBs made but I will try yours, if you go that route

[superg]

Awesome, I love it!
It's looking like the readouts would be much nicer with this. The code is definitely much more readable

Someone suggested a good simplification for the console region selection.
This goes on top:

Code: Select all

//#define FIXED_REGION 'e' // Set PSNee to only work with the specified region. Slightly improves boot times. Values: 'e' (SCEE, PAL), 'a' (SCEA, US) or 'i' (SCEI, JP)

And then:

Code: Select all

#ifndef FIXED_REGION
	inject_SCEX('e'); // e = SCEE, a = SCEA, i = SCEI
	inject_SCEX('a'); // injects all 3 regions by default
	inject_SCEX('i'); // optimize boot time by sending only your console region letter (all 3 times per loop)
#else
	inject_SCEX(FIXED_REGION); // injects user defined region
	inject_SCEX(FIXED_REGION); 
	inject_SCEX(FIXED_REGION);
#endif

I think it'd still be best to force users to make a decision on the board used.
My version had the board unset to do this, with an error define that tells users what to do.
I don't know any more automatic way that surely works, but maybe you do? :p

It's great someone picks this up. The project definitely needed some shine and polish.
I never had custom PCBs made but I will try yours, if you go that route

What is the consensus on how many times we want to inject? I ask because for my tests I have only one inject line inject_SCEX('a'); (e.g. runs twice) and never had a problem.
Ideally to keep it generic I'd do something like this:

Code: Select all

#ifdef FIXED_REGION
	static const char regions[] = {FIXED_REGION}; // or {FIXED_REGION, FIXED_REGION, ...} etc
#else
	static const char regions[] = {'e', 'a', 'i'};
#endif

and then this:

Code: Select all

    for (byte loop_counter = 0; loop_counter < 2; loop_counter++)
    {
      inject_SCEX('e'); // e = SCEE, a = SCEA, i = SCEI
      inject_SCEX('a'); // injects all 3 regions by default
      inject_SCEX('i'); // optimize boot time by sending only your console region letter (all 3 times per loop)
    }

becomes this:

Code: Select all

for (byte loop_counter = 0; loop_counter < 2 * sizeof(regions); loop_counter++)
    inject_SCEX(loop_counter % sizeof(regions));

2 * sizeof(regions) is compile time constant, we remove two extra function calls in the generic case but add 3 bytes in static.
Might be overkill though. I'm not particularly happy about % sizeof(regions) operation, usually it gets optimised by logic shift and logic and (at least on MIPS architecture I've seen that constantly), not sure about AVR. Or even remove that 2 *
and define it twice: static const char regions[] = {'e', 'a', 'i', 'e', 'a', 'i'};
Really I didn't look into inject_SCEX details yet, maybe that also can be simplified.

[rama3]

The Mechacon has some rough timing windows in which it expects each unlock symbol to arrive, according to the limitations of the CD drive.
It's easy to unlock it on early consoles (<= PU18), because the symbols can be sent directly.
On later models, they need to be "modulated" onto a tracking error signal.
We can't improve the injection method (easily anyway), so it's best to send the unlock string several times.
I think this is also similar to what a real CD would give. It keeps decoding the wobble for a short while, even after the Mechacon is satisfied (Mechacon just ignores them now).
So... 3 times is pretty much optimal from my tests.

It's not necessary to optimize the injection part for speed, and size is not an issue either, from what I remember.
It's really your choice how you'd like to code it, if you want to change it at all.
I like the readability and simplicity of my suggestion :p

[superg]

The Mechacon has some rough timing windows in which it expects each unlock symbol to arrive, according to the limitations of the CD drive.
It's easy to unlock it on early consoles (<= PU18), because the symbols can be sent directly.
On later models, they need to be "modulated" onto a tracking error signal.
We can't improve the injection method (easily anyway), so it's best to send the unlock string several times.
I think this is also similar to what a real CD would give. It keeps decoding the wobble for a short while, even after the Mechacon is satisfied (Mechacon just ignores them now).
So... 3 times is pretty much optimal from my tests.

It's not necessary to optimize the injection part for speed, and size is not an issue either, from what I remember.
It's really your choice how you'd like to code it, if you want to change it at all.
I like the readability and simplicity of my suggestion :p

Got it, in this case I won't change the structure.
Another question, what is the encoding of SCEx symbols?

Code: Select all

//SCEE: 1 00110101 00, 1 00111101 00, 1 01011101 00, 1 01011101 00
//SCEA: 1 00110101 00, 1 00111101 00, 1 01011101 00, 1 01111101 00
//SCEI: 1 00110101 00, 1 00111101 00, 1 01011101 00, 1 01101101 00
//SCEW: 1 00110101 00, 1 00111101 00, 1 01011101 00, 1 00010101 00 // Net Yaroze? Found in some psnee fork

It's definitely not ASCII.

[rama3]

Ehr, I'm sure this is some mangled ASCII somehow. You may find it here: http://problemkaputt.de/psx-spx.htm
I already had this table from the earlier PsNee.

That Net Yaroze string can be ignored, by the way. It doesn't serve any purpose.

[superg]

Ehr, I'm sure this is some mangled ASCII somehow. You may find it here: http://problemkaputt.de/psx-spx.htm
I already had this table from the earlier PsNee.

That Net Yaroze string can be ignored, by the way. It doesn't serve any purpose.

Figured it out, that was helpful, thanks!
This was the hint:

Code: Select all

  A20 = the normal SCEX signal (inverted ASCII, eg. "A" = BEh)   ;all boards
  A21 = uninverted SCEX signal (uninverted ASCII, eg. "A" = 41h) ;PU-7..PU-20

Letter "S", ASCII 0x53 or 01010011 in binary -> reverse bit order: 11001010 -> negate: 00110101

[superg]

Rewrote inject_SCEX, removed static inject sequences and platform dependent code (AVR PROGMEM stuff), implemented FIXED_REGION as discussed. IMO readability is so much better now.
Was a good evening!

[rama3]

Ah, so that's how it worked. I didn't think to try inversion ;p
Though I don't fully understand what nocash meant with "PU-7 .. PU-20". Then again, I always have trouble parsing his docs ><

Readability is definitely improved, and removing the AVR only code is a good touch as well.
I'll try the result sometime soon!

[superg]

Readability is definitely improved, and removing the AVR only code is a good touch as well.
I'll try the result sometime soon!

It could have been even simpler with SoftwareSerial Arduino class if Sony wouldn't change things in PU-22:

Code: Select all

#include <SoftwareSerial.h>
SoftwareSerial ss(-1, 2, 1); // no RX, only TX and invert logic
ss.begin(<whatever_the_baud_rate_is>, SERIAL_8N2); // 8 bit data, 2 stop bits
ss.write("SCEA"); // that's it!

That would remove inject_bit() and inject_byte() functions but introduce a dependency to Arduino SoftwareSerial. Unfortunately it's not possible for PU-22+ because of that WFCK modulation, the nature of which I can't explain other than Sony trying to invalidate the older modchips.

Meanwhile I ordered a few ATtiny84, these have more pins but similar core as ATtinyX5 and I want to use it to make sure bios patching works on PM-41 (timings etc.) and have some serial logging capabilities before I attempt to reassign reset pin on my 85, should be here this weekend. If all goes good I'll add ATTINY_X4 defines block and will move debugtx pin there as I'll have to use that pin in X5 for one of the BIOS_ pins.