Everyone the code for the new fix

[gee-man]

The 16F84 is a physically larger chip and it requires an external oscillator. The 12C508 by itself is more than capable of doing this task, so I wouldn't discard it. Besides, I've got a rail of 508's left over from my PS1 modchip days so I'm determined to prove the chip is usable

To do the T0CKI thing, You don't have to change the code necessarily... almost all of it can stay the same. Instead of using a BTFSx function to sample the interrupt line directly, check TMR0 to see if it isn't zero (a pulse was counted). Then clear the register immediately afterwards.

example code:


//// old code
BTFSC GPIO,x
CALL branch


//// new code
MOVF TMR0,1
BTFSS STATUS, ZERO
CALL branch
<other stuff>

branch: CLRF TMR0
<other stuff>

Or alternate software idea: the V12_DEAD_BEEF shows the interrupt running at 50Hz. You could probably run a simple wait/check/wait/check routine in the PIC at 30Hz which checks the TMR0 register value (then clears it afterwards)

- If the timer register holds 1 or 2, everything's fine.
- If it's 0, mechacon crash, mute the RS2004.
- If it's something high like 10, then something's obviously wrong with the mechacon, mute the RS2004.

I think it's simpler

I think i'll rewrite the software for this, just for fun. One feature I think I'll add is the ability to connect a red/green bicolor LED across the two unused GPIO pins for a status LED. This way, depending on the faint glow you see within your pstwo you know wether you've got a mechacon crash or not.

[Albert35]

Don't forget the PStwo will switch off in 200ms so you will have to watch the led verry closely if you will see it flash from one color into an other.. Hope i'm not wrong..

What you are telling about the INT signal.. I can say this.. The signal is not a steady signal of a fixed freq.. The freq. is changing the moment the console is reading a disk..

[comsoft]

The 16F84 is a physically larger chip and it requires an external oscillator. The 12C508 by itself is more than capable of doing this task, so I wouldn't discard it. Besides, I've got a rail of 508's left over from my PS1 modchip days so I'm determined to prove the chip is usable

To do the T0CKI thing, You don't have to change the code necessarily... almost all of it can stay the same. Instead of using a BTFSx function to sample the interrupt line directly, check TMR0 to see if it isn't zero (a pulse was counted). Then clear the register immediately afterwards.

example code:


//// old code
BTFSC GPIO,x
CALL branch


//// new code
MOVF TMR0,1
BTFSS STATUS, ZERO
CALL branch
<other stuff>

branch: CLRF TMR0
<other stuff>

Or alternate software idea: the V12_DEAD_BEEF shows the interrupt running at 50Hz. You could probably run a simple wait/check/wait/check routine in the PIC at 30Hz which checks the TMR0 register value (then clears it afterwards)

- If the timer register holds 1 or 2, everything's fine.
- If it's 0, mechacon crash, mute the RS2004.
- If it's something high like 10, then something's obviously wrong with the mechacon, mute the RS2004.

I think it's simpler

I think i'll rewrite the software for this, just for fun. One feature I think I'll add is the ability to connect a red/green bicolor LED across the two unused GPIO pins for a status LED. This way, depending on the faint glow you see within your pstwo you know wether you've got a mechacon crash or not.

It will do the same. since it's not so critical ad ripper team claims. the proof for that is the 1ms delay between each test from the matrix code.

but i don't mind to make a new version upon u'r idea.

about the leds, i was thinking about it, but didn't add it to make one wire less for install.

[gee-man]

A PS2 can run all day with a crashed mechacon if the RS2004 chip is muted, so there's no rush to turn the power off. The code I'm working on won't even have that wire.

The LED won't be a "oh shit, jump off your couch and pull the power plug because your PS2 is about to catch fire" indication; it will be a "your mechacon crashed for some reason so the RS2004 was muted - that's why your system locked up." indication.

And if bad modchip installs (or bad modchips to begin with) lead to mechacon crashes, then it's helpful to the user to know if their modchip isn't working right.

I never knew the /INT signal changed frequency; perhaps the 30Hz or "1 or 2" thing can be relaxed. But thanks for the information. Got any more to share?

Before I release any code, I'm going to borrow a scope from work and make sure that every signal is the way I expect it to be... I want to be able to explain "here's the deal, here's the code, and this is why it works" instead of "i put it in 100 playstations and it works great!" - people said the latter about diode fixes, ffs...

[comsoft]

U'r doing all the changes in the code to catch a 5ns pulse on the INT line, and that is duo to what team ripper wrote on there site.

but after reading the PIC datasheet , i'm sorry to tell u that u'r idea wount work

this is from the datasheet:
"Therefore, it is necessary for T0CKI to be
high for at least 2TOSC (and a small RC delay of 20 ns)
and low for at least 2TOSC (and a small RC delay of
20 ns). Refer to the electrical specification of the
desired device."

in short it says that the TOCKI signal should be at least 20ns to trigger the counter (correct me if i'm wrong).

[gee-man]

20ns + 2*Tosc is 520ns, which is 0.520uS, which is way shorter than 5us.

[Verbal Kint]

It's Just and idea, but why not connecting the pic to reset led and let it flashing red/green instead of adding another led

Also, the "test mode" of Albert35 hex code can make problem with multidisc game, I think this function need to be modified with longer delay or completly rewrote in another way

[gee-man]

It's Just and idea, but why not connecting the pic to reset led and let it flashing red/green instead of adding another led

Also, the "test mode" of Albert35 hex code can make problem with multidisc game, I think this function need to be modified with longer delay or completly rewrote in another way

Flashing the reset LED would look slick, but it would be annoying to implement - you'll most likely need to cut traces and add 3-4 wires to do it, which the '508 PIC doesn't have the I/O to do anyway.

Question time: I've got a test version of my code written, and its operation is simply "if between 1 and 10 mechacon interrupts occured in the last 33ms, and the PS2 itself doesn't want the rs2004 chip muted, then enable the rs2004." - there's no sort of turn-on sequence or anything. It's dirt simple, but think I'll run into any startup issues on the console?

If nobody can spot anything obviously wrong with this method, I'll toss a chip into my V12 and see if it works.

[comsoft]

20ns + 2*Tosc is 520ns, which is 0.520uS, which is way shorter than 5us.

My mistake, i thought i remember 5ns insted of 5us.
forgive me i was realllllll tyred

Ok, today i'll work on it (at evening ...)

[gee-man]

My mistake, i thought i remember 5ns insted of 5us.
forgive me i was realllllll tyred

Don't worry about it, I've made stupider mistakes in my lifetime