Wrong again, you need to physically apply +12V on one pin of the flash chip to erase the boot sector, and doing that would likely fry the calc anyway. As long as the boot sector is intact, it's impossible to totally brick it.

The Tari is right. Unless something physically fails on the mainboard, you're not going to end up with a completely inoperable calculator.

yah so why could you explain me i have fritened a pic16f8x last year on the boot sector with no turn on power pin.... humm let me guess ups the program cointaned a bug... and in similar ways we can do it on z80....

You can enable config flags that disable writing and code execution in various sectors in the chip on a hardware level - including the PIC18F4550 chip that I have. (so all I have to do is enable the boot code protect, and the range 0-00799 is executable but not writable - boom, no bricking possible)

However, I fail to see how you can compare a PIC16Fxx and a Z80 - they are a *tad* different

Since it doesn't look like anyone's going to paste any code, I'll throw this in for some closure in this thread: http://www.brandonw.net/calcstuff/unlock.zip

Now you can unlock on all calculators...don't do anything dumb.

It says OS 2.41 only...

That on boot code 1.02 calculators, combined with the boot code 1.00 method on Detached Solutions, gets you all calculators.

Right, but the stuff in the zip you posted relies on os 2.41 and the flash write bcall...

How can I do it on 2.30?

Man, after reading through this thread, I REALLY wish I knew about Cemetech back when I messed my calculator up.

I could still get to the boot screen to load the OS, but it didn't do any good.

I had to send in my other calc to get my new one, so otherwise, I could play around with all of this stuff.

@calc84maniac: just what are you planning on doing with this unlocking routine? You can PM/email me if you don't want to make it public - I won't tell anyone.

Also, sorry for being a real n00b, but what does DDCBnn08 do anyway?

I thought machine code was all in hex and that certainly is not all in hex...

nn is a placeholder for a 2-digit hex representation of one of the z80's registers.

It is often stored as hex on things like the calc (can you imagine how big it would be if it was binary?), it is quickly translated to binary and run. (Someone correct me if I'm wrong)

It doesn't rely on the flash write BCALL...

It exploits a really dumb flaw in some code on page 7Dh of OS 2.41. I don't know how long it's been there, but I don't think it exists on very old (1.x) OSes. You'll just have to search around until you see something similar. Sorry for being vague, but that's the way it is with this stuff.

I posted it partly because of rayden, because from what I can tell, he seems to be putting everyone down when he hasn't shown anything.

Gladly. You are wrong. Completely. See, the thing is, it *IS* stored in binary on the calc. You can't store something in hex, it isn't possible (yet). You can *only* store stuff as binary, as thats all computers, etc... understand. It can be DISPLAYED however the programmer wants. It is fully possible, however mind-numblingly stupid it may be, to have it represented as, say, octal (base-. It is often displayed as hex because hex and binary are easy to convert between, as 4 binary digits == 1 hex digit, so everything lines up correctly and easily with the whole 1 byte == 8 bits thing

Oh, and it would be the same size, regardless of how it is being represented

Unless it's ASCII hex, of course

yeah, cause we all know it makes a whole lot more sense to use 1 byte to store 4 bits worth of information