Smart card mod addon for PSX project



Edit: Truman here, just to let u know I’ve splitted this from new psx thread, since it’s a different subject.

Today I will attach a smartcard reader unit @ my “lab - rat - psx” :wink:

Its easier I thought before, just 3 wires must been connected in the way the diagram below shows:

16F84 Smart Card Connection

       N/C    4 --+ 4   |    |   8 +-- 8    N/C
                  +-----+    +-----+
       RB6  Clk --+ 3   |    |   7 +-- I/O  RB7  Modpin6 SCEx output
                  +-----+    +-----+
       MCLR Rst --+ 2   |    |   6 +-- nc.  N/C
                  +-----+    +-----+

Modpin1 VCC +5V --+ 1 | 5 ±- Gnd VSS Modpin8 PSX Ground

PIC 16F84

                   _______  _______
                  |       \/       |
            RA2 --+ 1           18 +-- RA1
                  |                |
            RA3 --+ 2           17 +-- RA0
                  |                |
           RTCC --+ 3         >>16 +-- OSC1/CLKIN
                  |                |
          !MCLR --+ 4 <<        15 +-- OSC2/CLKOUT
                  |                |
            Vss --+ 5 <<      >>14 +-- Vdd
                  |                |
            RB0 --+ 6           13 +-- RB7
                  |                |

SCEx output RB1 --+ 7 << 12 ±- RB6
| |
RB1 --+ 8 << 11 ±- RB5
| |
RB3 --+ 9 10 ±- RB4
| |

(best viewed with notepad font terminal standard, insert dropped spaces)

After that modification I can program every SCEx test strings onto a Goldwafer.

I have already the code for the 16C84 chip, which you can find here:

(format ASM and hex)

The 16C84 is as good as compatible with the 16F84, even the connections over the smartcard is OK.

The only thing is:

I/O pin = pin 7 = RB 1 = SCEx output line
! PIC 16F84 uses i/o Pin 13 (RB7),
Mochchip Code for PIC 16C64 or 12C508 uses i/o Pin 7 (RB1)

Therefore the only thing must be done ist changing Pin7 (RB1) into Pin 13 (RB7), because thats the (only connectable) Goldwafer Input / Output Pin.

I hope I can manage to edit the ASM sourcecode and then compile the whole stuff successful on my own, but every help is really welcomed! thx. If you have experience with modchip-programming, please download the zip above and change the SCEx output simply from RB1 to RB7.

If we can get it to work, which shouldnt be such big problem, we have a new great way for testing the psxs hardware structure, and check out all the compressed SCEx and repeat patterns!

CU, Sam


Come on, fellows, I know that protection blasts your borders of “hacking motivation”, but if we are though enough we will fight til the very end!

Its frustrating if Im the only one who still remains, but I dont care, I even will go as far as possible all by myself.

But think about our very special goal, its absolutly exclusive!
Is anyone else still tough enough and motivated for beating that protection or has everybody already resignated and given up!?

Not me!
Now I have the chipcard connection, and next I’ll do what it take for programming it for outputting SCE!!!
Even if I have to learn noe the complete assembly language for PIC 16x series.

CU, Sam


Sorry Sam that I cannot be of more help as I am not electronically inclined nor do I know much about CDR drives to assist in creating a PSX copier via hardware. About the best I can do is try the piezo speaker on an external writer to force the writer to “encode” the SCEx signal. I am willing to try, however, I do not know how to hook a piezo to my computer’s sound card. I know you tried it do you have any information that I could use? I now have an unmodded PSX that I can try my copy on.

Anyway, I can’t be of too much help, as I do not have the setup that you do, nor the knowledge of CDR internals as others who have contributed. I can provide you with moral support and hope that you continue on this quest.

:bow: :bow: :bow: :bow: :bow:


Hi Saruman,

thx for your support, and its great you didnt forget the fun part, we also really will need for getting through all this kind of abstract and often frustrating hi-technical stuff! :wink:

A few minutes ago I’ve downloaded MPLAB v6.30 full which is 's free PIC programming suite, including programmer software (I have already one), PIC circuit construction and testing programs and importantst, the PICstart assembly compiler.

For luck I could repair that 25 megs large file, downloaded from with pkzipfix!

No idea why it was corrupted, it had the correct size, but it was compressed by an old DOS 2.0 zip version. Well, it seems its now installed without any failures. Great, so I havent to download it again! Fantastic, I was lucky! Puh!

btw if I am right informed, Andrew already is very good at chip programming (check out the WHOLE-MESS.jpg on his page there you can see a chip programming software running on the PC in the background), so lets hope there arent so many differences between 12C508 and the 16F84 oer 16C84 series and Andrew M will help us again. Andrew, are you still here on this forum?

(if Andrew or noone else from here knows how to change the code for our purposes, I also could ask some “16F84 blink LED experimentating” students, usually they know the command for adressing the LB7 pin, so we can send our bitstreams over the smartcards In/out port.)

And: Our smartcard chip doesnt need a very complex “stealth-timing” layout etc., it just has to send repeatedly the SCEx strings. If we are experienced enough, we even could create a recording option, because our 16F84 Goldwafer contains the 24C16 EEPROM (16 kilobit / 2048 bytes) which we could use as “datrecorder”.
Our smartcards I/O pin is attached at Modchip Pin6 SCEx —> CPU line, so perhaps we can grab there the original CDs scex pattern digitally and evtl. can find any clues.

Saruman, maybe you also can “smardcardchip” your PSX, and we can make our tests together. Its not that complicated.

In the next time I will do my best getting those chip perfect programmed, but dont lets forget our “second option”, its the Lead-in special burning improvments and test sessions, including felt-tip pattern, timing error sector creating and SCEx compressing tests.

I even had a new idea, beating the psx by his own weapons, but I throw it away already:

If we could speed up / slow down the PSXs motor in the right SCEx fitting way, the PSX would create his own SCEx signals! Because lets assume the PSX recognises the 22khz ATIP wobble mainly at 1x speed, every different speed would create a “zero” - you understand the idea behind - if the sectors have different lenghts or reading/unreadable quality the motor will start to speed up or slow down, which would creates the wobble on off pattern. But I guess that motor-reaction-timing is far to slow for our purposes, thats the only problem.

CU, Sam


@Sam, hmm, you mentioned that Samsung DVD drive does not work with the leadin generation. The thing is I didn’t implement the software just for LiteOn, I tried many drives and they did not have any problems. The problem is that I don’t have access to Samsung DVD drive, so can’t fix this unless you can help - its better if we talk over on email or something.

Anyway, about your smartcard modchip addon. I’ve modified and compiled the code for you, but I haven’t tested it.

By the way, I have a feeling it’s not going to work straight away. I know quite a bit about smartcards and I noticed you missed out a few points…

Point 1:
The 16C84 modchip code requires a CPU freq of 4MHz or 4.45MHz by using an external oscillator, either a quartz crystal+bypass capacitors, ceramic crystal or resistor/capacitor. The 16F84 in the smartcard is also powered in the same way, also by a frequency, which is part of the circuit inside the smartcard - yes that’s right it doesn’t just contain the PIC and the EEPROM. The problem is, we don’t know that frequency. Once you’ve found out and it’s not correct, the code will have to be modifed again to correct the delays.

Before you say, ‘but RB6 is the clock signal’, no it’s not it is actually a higher layer only for smartcard standard specification. The 16F84 circuit in the goldcard which you’re referring to is actually the lower layer - lower than the specification.

Point 2:
The modchip uses RB2 as high state to block the original SCEx signal from the CD. Actually, you can use RB6 on the smartcard. If you want I can modify the code again to make RB6 act the same as RB2.

One question… why would you want a smartcard addon anyway?

Its far better to have a PIC chip on a ZIF socket if you want to play PICs.

Link to modified asm:


My and I hope also >our< big thanx for still helping us out that fantastic! Without your multitalents we could stamp in the whole project! ggg

OK, thx for the osc. frequency info, I thought it only would be necessary for programming those smartcards. So if the 16F84 hasnt an internal mhz clocking, we need to feed in that signal from outside? Or is there another way and the 16F84 generates outgoing signals without that tact-frequency? Is there such pin at the PSX pcb somewhere we could use? For programming the Goldwafer uses 6Mhz, I guess it also operates at that speed.

eventually blocking of CDs orig. SCEx @ RB6:
thx for the offer, but for the moment, when we just use CD-Rs, its really not necessary.

Here now the newest testresulats with your hex file:

Sorry, but it didnt worked.

btw, a nice side-effect occured:
Even if the smardcards power is off,
(I havent added it in the actual connection circuit plan jpg, but I did connect the modchip switch on/off as “flip flop”, if the modchip is on the chipcard isnt and vice versa)
the “smartcard power LED” starts blinking very weak if the internal Modchip sends the SCEx strings. Seems there flows some very low voltage over the always connected Modpin6 chipcards input (there its C7 / RB7) to the +5V (C1/VCC) input, in this case “output” and into the LED. But as I tested now, it occures on every Goldwafer and has nothing to do with the hex file.

Well, we have the clock connector still unconnected, on the diagram its connected not only at RB06 but also at Osc.1/clock-in (Pin16). I have still 2 wires free, so perhaps we can get that frequency from the PSX, maybe Andrew can “scan some psx platine pins” with his oscilloscope? The psxs main processor, a 32 bit RISC R3000 at 33,92 Mhz is to fast, but perhaps other parts use lower tacts.
But where from the 12C508 gots his tact-frequency? Its possible just connect it in 3 wire fashion: Ground, +5Volt and SCEx output

Why I wanna use a smartcard instead of a zip socked PIC platine?
Its because yet it was just the beginning and very easy to attach. btw we dont just need to use the 16F84 goldwafer, if its easier for you or anyone else and our purposes - I also have AVR, 16F876 and 16F877 smartcards and can program them.

Does has any of them an internal oscillator? And personally I think the efford is good enough with those cards, because for the moment we only wanna make some SCEx pattern tests, not worth buying expensive additional equipment. Maybe later if we wanna chip CD-recorders. :wink:
And I hope that “lower layer, higher layer” problems wont confuse me completly in the end! :wink:

About the Samsung DVD:
Never mind, because in principe it just has to read from and work with the supported CD-burners. Perhaps the Samsung wasnt able reading properly the sucodes raw or something like that, some older drives have problem with that, and this was a possible reason.

For now I was able to install MPLAB successfully, ok, I miss the grafical pcb layout demonstration program, but at least it works. And I will check the infos about what differences is between 16C84 and 16F84, seems they are very few.

Anyway, thank alot for your support and feel free to experiment and code all kind of PC test hexs, I have no problems in burning and testing all of them out! Perhaps its even possible emulating the complete 12C508 with the 16F877 or such high sophisticated stuff, but for the moment we just would need to get those chips outputtin just anything! :wink:

I forgot it yesterday: I wouldnt recommend any tweeter experiments for the moment, because they are far too unreliable and unredoable for others.

CU, Sam


@Sam, you misunderstood me. You do only need to program the smartcard (goldwafer), but with the correct code for the freq.

Nope, we don’t need to feed a freq from outside. The smartcard already generates it’s own internal freq. How is this done? Well, it’s simply because the PIC’s OSC IN (pin 16) is actually already connected inside the smartcard circuit to an oscillator mentioned before. That is what I’m talking about - unfortunately we don’t know what that freq is.

Sorry, I missed out 1 more point. The smartcard (goldwafer) might need the master clear pin in a high state. This means that the program in the PIC doesn’t run until you connect (pin 2 on the smartcard) to the positive rail, VCC (pin 1 on smartcard).

Maybe in your case when you powered on the smartcard the program was held in a reset state and it never ran.

I had a little spare time and I’ve written a code that is intended to blink an LED connected to any RB pins. The idea is that you can test with this. Just program the smartcard and tie pin2 to pin1 as mentioned before and connect a LED with a suitable resistor (e.g. 100 ohm) in series to limit 5V and connect between RB7 and the positive supply (or pin 1 on smartcard). It was written for a 4MHz freq. If LED is blinking too fast then freq is above 4MHz.


Modified for 20MHz:


Great, I’m happy and reliefed because of your new info about the internal clock! And it was a super idea from you with the LED test, so we can proof it very easily if the goldi sends something out at all into the PSX! I will test both hex files asap.

In the meanwhile I even got the detailed circuit plans of the old 16C84 modchip connections layout for the 5502 PSX I have:

Clock-In, pin 16 gets there approx. 4.45MHz. This clock is derived from the video master clock oscillator (53.69MHz NTSC, 53.20MHz PAL)

That nowadays rare info I found via goooooooogle at:

Is this correct connecting the LED between Pin7 and +5v and not Pin7 -> Ground ? But however, I can test both possibilties, because the LED <–> smartcardconnection already is 300 ohm protected so there is no big risk.
I just have to attach the LED with the correct polarity. :wink:

Thx also for the ‘reset state’ info, I also will check this out.

Exciting, we get closer and closer to success with this kind of experiments, and with your help superfast! And now for luck I havent to open the PSX for the hundredst time, risking to destroy all that wire-mess already inside, for soldering that 4.45 MHz connection! :wink:

Truman, if we get that Goldi to work, you deserve the patent for inventing the first programmable PSX “keycard” and smartcard-game-console ever ! btw pretty nice future-prognosis: Smartcard protected gameconsoles in all living rooms… ggg


first tests show that if the LED is connected like you mentioned it, the light alway is on. The current just flows from the +5v into chipcard pin7 which is always connected with PSX modpin6 which works also almost as “ground”, no matter if smartcard is or isnt into the slot. Its just the PSXs +5V output I can switch off for the smartcard for the moment, or do I have to cut off the RB7->Pin6 cable or make that con. switchable to get your code working?

Or better: Can you configure the blink.hex that way the smartcard sends out interrupted currents on Pin7 so we can put the blinking LED between Pin7 and Ground? I tested this also already with your new hex, but of course yet it didnt work.

CU, Sam

yesterday I wrote down a short 16C84 VS 16F84 infofile, but I think for the moment its not that important anymore:

16C84 vs 16F84


16C84 - set PWRTE (Power Up Timer) to off
16F84 has been inverted - set PWRTE to on

16F84 has 28 more bytes of data memory (RAM)
16F84 has code protect function, 16C84 doesnt

16C84 means 16CMOS84 - electrically reprogrammable
(but normal C means: One Time Programmable)
16F84 means 15FLASH84 - electrically reprogrammable

PIC Name…Program…Data…Max…Voltage…Typical

PIC16C84…1024 EE…36.+.64.EE.13…10…2.0-6.0…2


  • 14-bit core ?!
  • 1 Kbit EEPROM
  • they are pin-compatible
  • they work with the same code
  • they work with same programmer
  • 13 pins available for general-purpose I/O
  • ca. 2.5 MIPS @ maximum clock frequency of 10MHz


Sorry, stupid me. The LED is supposed to be connected to RB7 and ground. Also, did you connect pins 1 & 2 (i.e. MCLR RST & +5V) together on the smartcard during the whole time? This should put it in non reset state. And yes, you do need RB7 to be free from mod pin 6 - need to cut or make switch.


OK, Truman, everything modificated like you said, new results, still didnt blink;
I added a switch between 1 (5v) and 2 (rst), so we have both states whenever its needed.

But because of the reset line also was soldered on the metal-housing of that switch, i made an interresting discovery: if the switch is off (no connection between pin 1 and 2) and you touch the metal with finger or fingerconnected screwdriver just very softly and very short, the LED lights vor a very short time. If you touch the metal/reset pin just a 1/10 sec longer, the LED light remains on, as long as you touch it again.
Seems the “antenna” function of the human body injects the fitting energy into Reset pin so the 16F84 opens the Pin7 like a transistor sometimes if touched at the basis.

But that has nothing to do with your program, every of my 3 completly different programmed goldis showed that reaction.

But this doesnt happens if Pin2/reset gets the full 5Volt power. btw first I thought I have a shaky/loose connection somewhere and disassembled the PSX. :wink:

However, I hope you have some ideas how we can get at least that LED blinking. Perhaps the easier the better for the first tests. Maybe simple a code where the LED lights without touching the Pin2 and a second hex where the LED should remain intended off or something like that.

CU, Sam


Sam, the behaviour you’re experiencing is normal on PIC chips when the reset line is left unconnected - I mean it does the same thing on the PICs I have: 16F628, 12F675 and 16F876.

On these chips as well as for all PICs with MCLR (RST) pin, the code does not run until RST pin has been connected to +5V (+ supply I mean).

The RST pin cannot be ignored by the code on the 16F84 - it’s hardware based only. On the newer PICs, e.g. the ones I have mentioned, the RST pin can be disabled and software will run regardless of the RST pin.

It’s strange that connecting RST to +5V didn’t work on the smartcard. Anyone have any ideas why it doesn’t work?

Ok, here’s my thoughts:

  1. Maybe they added a circuit that inverts the reset pin - this means we have to connect RST to ground instead of to +5V
  2. Maybe the RST pin isn’t the MCLR (reset) pin of the 16F84 chip - but I don’t think so
  3. Maybe the RB7 pin is made as open drained (OD). If so, you need to connect a resistor from +5V to RB7 pin. The rating of resistor should allow just a little current to flow for LED to be on, I have used a 46K ohm on OD circuits with no problems before.

Unfortunately I have only a fun card (a different smartcard). I will try to get hold of a goldcard. Or, if you like, I can write the same code for the 16F876 smartcard that you have - I can test the code on my stand alone chip that I have.

Anyway, here’s 2 more codes with no blinking - just states where the LED is either off or on.



Good idea to put this into an extra thread. And its fantastuc you also do have a 16F876 (inclusive programming device etc) - and because my 16F876 chipcard is an old pcb one which has soldered the original 28 pin chip on it, its even better, now we both can make our tests on the exactly same hardware structure!

For insurance and coordinating with your connections I upped the 16F876 smartcard connection circuit plan along with some other infomaterial, and I’m shure that layout is the same on every ‘silver card’.

First again just a blinking LED, and after this we just need get the 16C84 asm code working on our 16F876, no matter if smartcard connected or socket. I’m excited! :wink:
Do you know if there are big differences, otherwise I’ll do all the tests or suggestions getting those 16F84 smartcard to work, but I think with the 16F876 at least we do have alot more possibilities.

CU, Sam


from microchip’s 16F84A datasheet pdf:

Power-on Reset (POR)
A Power-on Reset pulse is generated on-chip when
VDD rise is detected (in the range of 1.2V - 1.7V). To
take advantage of the POR, just tie the MCLR pin
directly (or through a resistor) to VDD. This will
eliminate external RC components usually needed to
create Power-on Reset. A minimum rise time for VDD
must be met for this to operate properly.

  • I tried this out, also with your new hex files, connected a 100 ohm resistor between VDD and reset, but it still didnt start blinking etc.

btw the exactly sequence of this “touchscreen goldwafer” is the following:

  1. Power on
  2. Connect reset with +5V
  3. insert smartcard
  4. disconnect reset and + 5V
  5. touch reset pin, LED lights, remains on or switches off again


Breaking News! :slight_smile: !

Truman, 1000thanx for “transcoding” the MOD84V53_RB7.HEX that perfect, now with your file Goldwafer really acts as SCEx keycard!

Finally, or better just an hour ago, I disassembled the PSX (I hope now really for the last time :wink: and connected the cardslotunit with the reset and clock pins shown on the detailed 16C64 / 5502 boards b5502_4.jpg @:

Now it works!

Thx for your fantastic help! I still cant believe it. :slight_smile:

CU, Sam


Great, sam, glad to help out :). I had another look at the goldwafer card layout and I noticed that the clock pin (16) is actually connected to pin 3 on the smartcard. So I was wrong about internal clock - that’s why the LED didn’t work. The smartcard requires a clock feed as well as the reset on +5V. Well, it was a bit difficult to write code without having the chip or smartcard on hand.


Great, the forum loads now faster than ever, and a lot of new stuff from me in those few days! :wink:
Already I made the first SCEx tests, by editing the ASM source code before compiling with microchip mplab mpasmwin. Check out the test-results below at the annex.

What big luck: I found another 2 nowadays rare 16C84 codefiles (at the …index of… of: ), one of them uses the hex representation of SCEx (09 A9 3D 2B A5 74 etc.) and the second, one of the very first PSX modcodes from Old Crow ever, uses some very special RAW pattern!

And yippie-yeah, I could manage to transcode both of them successfully, so now we have 3 working keycard codes, SCEx in ASCII, HEX or RAW! I had really big luck, because in the “scex-RAW” code I had to find out that the:

dy_0 movlw -125
has to be changed into:
dy_0 movlw -130
After changing it the “RAW-keycard” also worked. :slight_smile:

Please get all those 3 fantastic code files (including the original sources and new ASM info headers with great goldwafer info and diagram etc.) here:

Neverthless your keycard file is still the modernst! :wink: Do you see a change to modify one of those 3 ASMs (perhaps the “RAW code”) this form, the chip will use simply the ultra RAW plain 0 (off/low/false) and 1 (on/high/true) representations of the scex-string? Then at my new tests I can change directly the 0 and 1s in the source-string, would be absolutly perfect! Cause I have no clue what that momentary RAW pattern means (perhaps some more complex form of timing?!) - look at this little preview:

; Data block.
lines addwf PCL,F ;Get index into table
dt 0xff,0x41,0x3d,0x2b,0xa6,0x20,0x26,0xa4,0xf4,0xae,0x96,0xd0
dt 0x09,0xa9,0x3d,0x2b,0xa5,0xf4,0x3a,0x87,0x2c,0xae,0x97,0xd0
dt 0x0d,0x09,0x74,0x2b,0xa5,0x74,0x26,0xa4,0xf4,0xae,0x95,0xd0
dt 0x09,0xa9,0x3d,0x2b,0xa5,0x etc. etc.

Perhaps you can define your “ULTRA RAW” string at best as complete string:

00000000 00000000 000010 01101010 01001111 01001010 11101001 01011101

( 100110101001001111010010101110100101011101 take 170msec
00000000000000000000 Pause = 20 zeroes take ~80 msec )

Please can you define it including those pause zeroes? That would be fantastic for our best SCEx selfboot tests ever!!

If RAW its to complicated, I have a second suggestion:
Change the “SCEx-HEX” version of the 3 files in a way so we get an uninterrupted 3 x 8 bytes input table. 2 bytes represent the pause, the rest the data, would look like:

dt      0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0xF4
dt      0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0x74
dt      0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0xB4

Because we need to create uninterrupted compressed patterns, I could simulate it with such a table by editing it. The CDs pattern has no start or end if we can compressed it into that limited space of around “34 bits” or 0.125 seconds.

In annex a you will find already the newest “HEX”, shifting the bits is no problem, and also inserting a pause of ca. 25 milliseconds between the boot characters!

Perhaps also that will help us with our CD techniques! Because now we have the proof, its possible to shift the laser (as long it doesnt create some 1 signals) for a long time (25 msec) for searching the next character somewhere else, perhaps on a different track.

For going further with our compressed string test, I urgently would need to edit the Pause hex data variables. For the moment the modchip doesnt uses those, because it was easier just to define the pauses by some counter, but now that counter is really obsolete and we need the access over all the time (and all the PSX :wink:

If I have the pause editable, I can try the “endless” SCE test. For the moment the pause is to long, but then I can write the SCESCESCESCE with just 8-25 msec pauses and we will have the next proof - if its would work at least for all PAL countries felt-tipping just the SCE (SCESCESCESCE) into the lead-in.

The SCE (10011010100 10011110100 10101110100 - remember, 1 of the raw S C E x characters consists of 11 bits including 1 start & 2 stop bits) needs just 33 x ca. 4 milliseconds which is 132, just 7 milliseconds more than the CD 1x spin with 125msec/revolution! If the PSX tolerates just 0.21 msec per 4 msec bit, we have it!

CU, Sam

  • Annex a) *


HEX boot string tests using pal console

00001001 10101001 00111101 00101011 10100101 01110100
dt 0x09,0xA9,0x3D,0x2B,0xA5,0x74 ;mod original

00000010 01101010 01001111 01001010 11101001 01011101
dt 0x02,0x6A,0x4F,0x4A,0xE9,0x5D ;SCEE
dt 0x31,0x31,0x20,0x27,0x30,0x33 ;11 '03
dt 0x54,0x72,0x75,0x6D,0x61,0x6E ;Truman
(2 bits shifted)

10011010 10010011 11010010 10111010 00000001 01011101
[10011010 100=S] [10011 110100=C] [10 10111010=E(1)] 0000000[1 01011101=E(2)]
dt 0x9A,0x93,0xD2,0xBA,0x01,0x5D ;SCE-E longer pause between E’s
this means: an additional space of 6 zeroes
(6 x 4msec time = 24msec) between the characters is still OK


01001101 01001111 01001110 10011100
dt (0x9C),0x4D,0x4F,0x4E,0x9C,(0x4D) ;compress 1

00100110 10100111 10100111 01001110
dt (0x4E),0x26,0xA7,0xA7,0x4E,(0x26) ;compress 2

10 01101010 01001110 10010101 11010010 10111010
0x02,0x6A,0x4E,0x95,0xD2,0xBA ;one 1 missing

00000000 00000000 01001101 01001001 11101001 01011101
10101110 10000000
dt 0x00,0x00,0x4D,0x49,0xE9,0x5D ;-SCE
dt 0xAE,0x80,0x00,0x00,0x00,0x00 ;E—
(a pause of 16x4= 64 msec between characters is too large)

  • Annex b) *

ASCII boot string tests using pal console

dt ‘S’,‘E’,‘L’,‘F’
dt ‘B’,‘O’,‘O’,‘T’
dt ‘S’,‘C’,‘E’,‘E’

dt ‘X’,‘S’,‘C’,‘E’
dt ‘E’,‘X’,‘X’,‘S’
dt ‘C’,‘E’,‘E’,‘X’

dt      'S','C','E','I'
dt      'S','C','E','A' 
dt      'S','C','E','W'

dt      'S','C','E','W'
dt      'S','C','W','W' 
dt      'S','C','W','W'

dt      'S','C','E','X'
dt      'X','X','X','X'   
dt      'X','X','X','E'

dt      'S','C','E','X'
dt      'E','E','E','E'    
dt      'E','E','E','E'

dt      'S','O','N','Y'
dt      'Y','N','O','S'
dt      'P','S','X','W'

dt      'S','S','C','C'
dt      'E','E','E','E'    
dt      'E','E','C','S'

dt      'S','E','E','E'
dt      'C','E','E','C'    
dt      'E','E','E','S'


Truman, I think I can modify that code for further tests on my own, just adding a few more variables at the as HEX defined datablock should work, so you can concentrate working on the CD-Tool if you want.

Another question: Anyone interested if I create some easy understandable smartcard<---->PSX all kind of different board diagrams? Just 5 wires have to be soldered between platine and smartcardreader. I’m shure for a lot guys out there it would be cool if they can show there friends that the consoles of them are hacked by a smartcard, which they can use before their eyes.

and: a lot satellite shops wont sell their many goldwafers anylonger, cause everyone buys Matrix, Fun5 or Greencards etc. But now they can sell them inclusive cheap smartcardslots to console freaks. :wink:

edit: Marvellous, thats the way of motivated assembly learning - 30 minutes later and we have:

dy_0 movlw -130
sl_0 movlw 20
movlw 12
dt 0x00,0x00,0x00,0x00,0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0x72
dt 0x00,0x00,0x00,0x00,0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0x73
dt 0x00,0x00,0x00,0x00,0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0x74

enjoy :smiley:

CU, Sam

Oh boy, its very late now, but I was curious and so made a few tests:

sad news:

10011010 10010011 11010010 10111010 01001101 01001001 11101001 01011101

But now with the 12 editable hex variables I could try how much time between two characters are possible:
10011010 10010011 11010010 10111010 00000000 00000001 01011101

This means, we can forget about the repeated SCE at the lead in felttip tries.
But thats anyway better, because I extremly doubt it, even if 1 of 100 people could paint it with felt-tip successfully, no one other could recreate it, at least because every PSXs laser has differences, sometime very big ones.

But we have until 16x4msec time between two characters, over that it doesnt work any longer. That long the PSX listens for the next character, its a long time, but can we ever take advantage of it ???


Just like to present some support to you guy’s, and the hard work u’ve been putting in. It can be beaten!
I’m a mechatronic engineer, and intend to put some work into
beating this, although I intend to do some reading first.
Keep up the good work!


Good work Sam. :slight_smile:

I had a look at the ‘ultra raw’ codes. Actually I think they are not perfect. What I mean is (quite a long time ago) I recall that old crow mentioned (on webpage) that he hacked the code from an original (first ever psx mod chip). The original person thought that those extra bytes were part of the protection, but in fact they’re not. I think a mistake was made during the conversion from analog osc signal to digital bits. Anyway, old crow found out and fixed that in his later versions. This leads to the only 3 sequences.

Your latest 3 sequences are the real ‘ultra raw’ codes - good work Sam.

Paramekia, it’s good to have more people on board.

I really think the only way is to hack a CDR writer to be able to write over ATIP wobble. I don’t think there are any skilled enough people for that, except of course people like andrewm and alex, but they seem to have given up.


Thanx alot for your compliment Truman.
First I want to kept it secret for not to endanger the whole project, but now as you said it conincidentional, i will preveal it:

Your right, Truman about: “I think a mistake was made during the conversion”

compressed SCEE test strings.txt:

10011010 10100111 10101010 11101010 10111010

Thats SCEE, but with just one stop bit instead of two inbetween the rest, and it still boots! Yes, I have crazy test ideas! :wink:

Truman, what do you mean with “this 3 lines now are the real codes”?

dt 0x00,0x00,0x00,0x00,0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0x72dt 0x00,0x00,0x00,0x00,0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0x73dt 0x00,0x00,0x00,0x00,0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0x74

only the line 3: 0x09,0xA9,0x3D,0x2B,0xA5,0x74, works. I made this to test if the bytes 7 to 12 are in function, and they are, with perfect timing. I did first tests with assembly value 30, and it also booted, but just until the “black screen”. Seems the second scee check has a slightly different time checkout than the first, but thats also a secret, because I have no idea why there should be any difference, but it is! I have already 2 hex codes where it boots just til the black screen, but the 25XY now is the perfect working.

Truman, I think Alex and Blame never wont give up, afaik now they work on a special project, but of course it would be better if they would show more precense here, now where we have that ultra raw direct access. Its like an implantation now, we can inject almost every signal now into the protection lock. eg

I wonder what other “inpossible” structures now we will find out with our newest ultra RAW code-combination hacking possibilities! Lockpicking fun! :wink:

thx for your support, your welcome! If you like to smartcard hack your PSX great! :wink:

CU, Sam


Sorry I meant for all PSX consoles the real raw codes with delay embedded at front are:

  1. dt 0x00,0x00,0x00,0x00,0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0xB4 (SCEI, for japanese console)
  2. dt 0x00,0x00,0x00,0x00,0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0xF4 (SCEA, for american console)
  3. dt 0x00,0x00,0x00,0x00,0x00,0x00,0x09,0xA9,0x3D,0x2B,0xA5,0x74 (SCEE, for european console)

Naturally only (3) is needed for your console because it is a UK console. But if you had say an american console you will need code (2).