Great, the forum loads now faster than ever, and a lot of new stuff from me in those few days!
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: www.algonet.se/~pir8 ), 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.
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! 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 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:
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
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!
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
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)
ASCII boot string tests using pal console