I took a look at the datasheet, to understand things better.
Also, while i was thinking of a way to optimize the code, i found something worth mentionning (still in the wikiti code example).
First, let me put it there again :
   ld a,b
   xor (hl)
   bit 7,a
   jr z,programdone
   bit 5,(hl) !!!
   jr z,programwaitloopAs you can see, the code actually does 2 separate readings (XOR (HL) & BIT 5,(HL)).
The thing is, that if the chip happens to switch from "status" to "data" mode right before the second reading, bit 5 of actual data will be tested, potentially leading to an unwanted abort instruction.
To avoid that, i guess there is no other choice but to read only once, save the reading into a register, to be sure that you read bits 7 & 5 from the same byte.
Am i right about that potential breach ?

#####

As i said earlier, i decided to optimize the code in favor of fast & successful writings.
Here is what i intend to use :
;b = byte
;de = address

   ld hl,$0AAA
   ld (hl),l

   ld hl,$0555
   ld (hl),l

   ld a,$A0
   ld ($0AAA),a

   ld a,b
   ld (de),a

read

   ld a,(de)

   cp b ; yep, cp the fastest option for fast & successful writings (using xor directly would add 4 cycles for the backup)
   ret z

   ld c,a ; backup, to be sure to read bit 5 of the same byte later

   xor b
   ret p

   bit 5,c
   jp z,read

   ld a,$F0
   ld ($0000),a

   scf

   ret

;cf = 0 (success) | 1 (failure)Thx in advance for letting me know if something is wrong or if you think it could be optimized more...

The thing is, that if the chip happens to switch from "status" to "data" mode right before the second reading, bit 5 of actual data will be tested, potentially leading to an unwanted abort instruction.
Am i right about that potential breach ?

That can happen, and in fact probably happens a lot, but it's not a problem unless your routine also returns an error status. Issuing the reset command in read mode does nothing, so there's no reason to go out of your way to prevent that.

Yes, my code will specify if an error occured.
Thx for your time, again =]

In that case, have the error handler check the data to see if it's actually different, which will be slightly faster.

Is the error handler system-dependant ?

No, I mean, in your flash write routine, when you see an error, double check if the data is in fact different than what was intended to be written, and only report an error if it's different. This will save you from the logic of retaining the status read value in a register.

No, I mean, in your flash write routine, when you see an error, double check if the data is in fact different than what was intended to be written, and only report an error if it's different. This will save you from the logic of retaining the status read value in a register.

Oh, my bad (thought you were talking about using the OS error handler).
I think i'll use that then :
;c = byte
;de = address

   ld hl,$0AAA
   ld (hl),l

   ld hl,$0555
   ld (hl),l

   ld a,$A0
   ld ($0AAA),a

   ex de,hl
   ld (hl),c

check

   ld a,c

   xor (hl)
   ret p

   bit 5,(hl)
   jp z,check

   ld a,c

   xor (hl)
   ret p

   ld a,$F0
   ld ($0000),a

   scf

   ret

;cf = 0 (success) | 1 (failure)

That sounds interesting. You have my attention.

I honestly don't know if that project will see the light, but i'll do my best =]

EDIT :

DrDnar, You said earlier that the calc would probably crash if batteries are low during a flash operation.
Isn't DQ5 (bit 5) supposed to handle that ?
Anyway, i already intended to check the batteries before starting any operation, but i guess it would be hard to detect batteries becoming low enough right in the middle of an operation...

It's me, again.
So, does anybody know how i am supposed to handle batteries becoming low in the middle of a writing operation ?
I mean, is it necessary to check them before every single write attempt ?
If yes, that would slow down large writings quite a lot...