[zoom33]

My explanation would be that when you power the NANDs with progskeet or else you power other stuff too ... and those stuff are connected to the NANDS.
If you look at NOR PS3 you have to connect NOR tristate to make sure no one else is using the NOR.

I think isolating NANDS 3v3 VCC should solve the reading problems.
But again you have to be free of bad block within coreos.

[DVPTeam_Hacks]

Originally Posted by zoom33 My explanation would be that when you power the NANDs with progskeet or else you power other stuff too ... and those stuff are connected to the NANDS. If you look at NOR PS3 you have to connect NOR tristate to make sure no one else is using the NOR. I think isolating NANDS 3v3 VCC should solve the reading problems. But again you have to be free of bad block within coreos.

Not when you use a zif48 socket and put the nand inside

[Sarah1331]

Originally Posted by DVPTeam_Hacks Not when you use a zif48 socket and put the nand inside

Your not getting a good enough connection that's why I made my adaptor

[DVPTeam_Hacks]

Can you still make them ? Cause I would be intrested in buying one

[Sarah1331]

Check the link in my sig buddy

[DVPTeam_Hacks]

Ok I found the problem, it's with the sl bitstream,

I just re programmed the progskeet to regular default bitstream and after I switched around the wires so they match the default bitstream I got it to work correctly on sem001, tested after on a cok002 too and works perfect

If I go back to sl bitstream and put back the wires to match SL, works with cok002 but then on sem001 i get again the verification errors

Tests were made on cok001 and sem001

This means there is a bug someplace in the sl bitstream only on sem001 ecf1009540 and this doesn't heppen on other boards

[Sarah1331]

Originally Posted by DVPTeam_Hacks Ok I found the problem, it's with the sl bitstream, I just re programmed the progskeet to regular default bitstream and after I switched around the wires so they match the default bitstream I got it to work correctly on sem001, tested after on a cok002 too and works perfect If I go back to sl bitstream and put back the wires to match SL, works with cok002 but then on sem001 i get again the verification errors Tests were made on cok001 and sem001 This means there is a bug someplace in the sl bitstream only on sem001 ecf1009540 and this doesn't heppen on other boards

No sl is for clip it changes where the command lines are read if you get one of my adapters you can use
clip on retail bit stream
Solder direct to my adaptor using retail bit stream too

[device7]

Originally Posted by zoom33 Welcome to dual nand PS3 downgrade ... Have you tried the AWG28 wire soldering way ?

Do you mean soldering lots of wires from Progskeet to motherboard directly?
************* [ - Post Merged - ] *************

Originally Posted by Sarah1331 100% wires too long or bad connection of a sort to get bad dumps

AWG24-28 taken from JUMPER wire. Tried very short 7cm. The same.
************* [ - Post Merged - ] *************

Originally Posted by zoom33 well from my experience 8 SEM001 i had : 2 of them with 0 bad block --> downgrade OK 2 of them only one bad block --> downgrade OK 1 with 8 bad blocks --> downgrade OK 3 of them with 4 bad blocks --> downgrade KO Bad blocks are normal we just don't know how to handle them ... yet

What configuration do you use?
X360CLIP + PCB ADAPTOR + Progskeet 1.1 ?

[zoom33]

i use progskeet 1.1 and pcb adapter.

[DVPTeam_Hacks]

I was using progskeet 1.1 + nand adaptator + 360clip

It always worked with all motherboards except with sem001, always random verification error.

I changed the bitstream from SL to default and re-wired correctly the progskeet and 360clip and now everything works fine.

Don't use SL bitstream and adaptator if you wana do SEM001 boards or you will randomly have verification errors! and if you try to downgrade the ps3 you highly risk a brick!

Best way is to use regular bitstream and if you wana use a 360clip use the tool from Sarah1331