PSNee further development
Hope you can see everything:
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.
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.
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?
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?
Heyy!TriMesh wrote: ↑August 28th, 2017, 2:13 pmAs 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:Angelworks wrote: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.
Can you tell me where is VCC, GND and GATE on PU-20? I am so lost!
-Rama
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.
Can anybody clarify, am I missing something?
Code: Select all
41000198372500000200 9F7F
41000198372600000200 FCFF
41000198372700000200 9F7F
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.
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.
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!
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.
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:
And then:
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
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)
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
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.rama3 wrote: ↑September 25th, 2018, 12:44 am 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:And then: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)
I think it'd still be best to force users to make a decision on the board used.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
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
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
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)
}
Code: Select all
for (byte loop_counter = 0; loop_counter < 2 * sizeof(regions); loop_counter++)
inject_SCEX(loop_counter % sizeof(regions));
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.
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
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.rama3 wrote: ↑September 25th, 2018, 11:15 am 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
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
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.
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!rama3 wrote: ↑September 26th, 2018, 7:49 am 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.
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
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!
Was a good evening!
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!
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!
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!
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.
Who is online
Users browsing this forum: No registered users and 1 guest