He might not feel comfortable about publicly releasing it. So atleast these findings would be put to use.
Lets not start a flamewar, but I agree with the above. Very few people on this forum have any technical know how. Especially halo3. So make it public and problem solved.
Your starting a flame war and wtf how do I have no knowlege on technology? I didn't see you find that info and without the info i posted and found, dark wouldn't even be able to read the chip.
Not me, not you, not most people on this forum. Stop crying. Also as for dark not being able to read the chip, it clearly says in big letters JTAG PROGRAMMING.
I beg to differ, I have made thousands of dollars repairing computers both hardware and software. And yes it does say Jtag but no1 seemed to notice/say anything about it before. Also if they did notice before don't you find it a bit odd if so that they would post that here in this thread a week or two after I posted the info; I don't think its a coincidence.
Ahem ... Programable devices (micro controllers, CPLDs, FPGA, GAL, PAL and similar chips) do have special lock bits or fuses to prevent people from reading it's program or function tables/VHDL/bitstream. So you guys might be arguing about something that might not even be readable to begin with ... :shrug:
Ahem.... Everybody who thinks this is for glitching because it says "Xilinx" please stop wasting your time NOW. Go play somewhere else. You don't have a clue - sorry. This is an FPGA, not a CPLD. Xilinx FPGAs are SRAM-based. There is an external ROM that configures the FPGA. This can be dumped over the JTAG header (there's the XCF and the FPGA in the chain). We dumped it, we also sniffed the JTAG transaction that the Titan is doing. Problem is: They only work on CPUs with the fuses being zero - for example the beta devkits. All of this happened in 2007/2008 by the way. JTAG only works very limited on Retail CPUs. While the TITAN can peek and poke (and it is possisble to dump the bootloader with that mechanism, or - in theory - the fuses, which are all zero), it doesn't work on retail (or devkit) CPUs. It only works on Beta CPUs (and another special class of devices - but if you do know which ones, you probably do already know what this is about, so nothing new here either). In short, these devices have been used to "fix up" the boot flow on early CPUs because they need some fixups in order to boot correctly. These fixes have been integrated into the CPU so that non-beta CPUs can boot on their own.
Probably the MS internal only system debuggers used to test and debug the System software before it's tested on normal systems. (educated guess, FYI)
So then what of the dip switches? Also how come 008/009s can be upgraded vs. 007/006 XeDKs? Btw it would be awesome if you shared the file(s) you got from the dump