Welcome =]

All the following will work on all black & white models, under all official OS & boot codes.
I'd say the optimisation ratio is something around 90%/10% (speed/size).
Each routine is pretty deeply documented, but don't hesitate to ask any question if something is unclear.
I ASSUME YOU KNOW WHAT YOU'RE DOING, AND ARE FOLLOWING THE RULES (INPUTS).
Unless specified otherwise, everything not listed in the outputs is unchanged.



flashunlocka & flashunlockb :

Unlocks the flash chip.
Based on thepenguin77's code, i extended its universality, and made it a bit safer.
flashunlocka is the one you'll typically use, compatible in both a prgm or app environement.
flashunlockb works the same way, but uses a custom buffer in case you have some valuable data where the OS writes.

flashlocka & flashlockb :

Locks the flash chip, way faster than with using the actual bcall.
flashlocka is the one to use from a prgm.
flashlockb is the one to use from an app.

flashsize :

Returns the actual rom size.
I see you coming, why not just use port $21 ?
Simply because that port isn't read-only, so there are some situations where trusting it is dangerous, especially if you're coding something like a shell.

flasherase1 :

Erases one sector.
Handles physical corruption.

flashwrite1 :

Writes one byte to rom.
Handles attempts to write 1 over 0, and physical corruption.

flashwritex :

Basically behaves like LDIR, but writes to rom.
For flexibility (and safety) purpose, it automatically halts the copy upon reaching a bank's edge.
So it's designed to be chained, as long as you handle the potential address adjustments and page mappings.
Handles attempts to write 1 over 0, and physical corruption.



edit history :

> Added a few clarifications on some comments, code unchanged.

Those are pretty neat especially the last one! I wish I had an excuse to use them.
Why don't you include a faster version of the flash to ram bcall while you are at it? It should be pretty easy since all you have to do is swap the flash bank into $4000-$4FFF and ldir it to ram and swap the page when needed.

Yeah, the day i coded the last one, i truly fell in love with conditionnal ret instructions, as a freakin' fast way to exit very low level loops.
About the routine you're talking about, it's not what i would exactly call flash-related, since you're writing to ram, so i'm not sure if it fits in this thread.
Also, i'm pretty sure plenty of routines like that can already be found.

Thanks a bunch, I might think a way to use this! @E37 : there are some pretty decent existing flash-to-RAM routines.
A classic way to increment HL through RAM pages is to do something like:
    inc l
    call z,incHLmem1
...
...
incHLmem1:
  inc h
  ret po
  ld h,a
  in a,(6)
  inc a
  out (6),a
  ld a,h
  ld h,40h
  ret
That method averages between 14cc and 15cc and advances the page as needed. You need to initialize by swapping in the correct page, though.

Here is my take on a flash-to-RAM routine, though:
FlashToRAM:
;Inputs: Same as LDIR, but A is the page number.
;Outputs:
;    Same as LDIR, except A is the ending page.
;
;Speed:
;RAM: 21+21n
;ARC, but no boundary: 114+21n
;Arc, on two pages: 21n+269
;Arc, on three pages: 21n+355
  or a
  jp z,ReadRAM
  out (6),a
  add hl,bc
;  jr c,read_from_Arc_blocks   ;if you need this, you probably need a different routine. This implies that writing will eventually reach the 0x0000 to 0x3FFF range.
  jp p,read_from_ARC_noboundary
read_from_Arc_blocks:
;If we make it here, we know that we cross a page boundary (or in one case, we just reach it and need to return on the next page).
;We will read in blocks to avoid checking page boundaries
;To do so, we first read up to 0x8000 - HL bytes
  xor a
  sbc hl,bc
  sub l \ ld l,a
  ld a,$80 \ sbc a,h \ ld h,a
  ;now we will subtract BC-HL  -> BC
  ld a,c \ sub l \ ld c,a
  ld a,b \ sbc a,h \ ld b,a
  push bc
  ld b,h
  ld c,l
  xor a \ sub l \ ld l,a
  ld a,$80 \ sbc a,h \ ld h,a
  ;now we read the first block
block_loop:
  ldir
  ;now we increment the page and continue reading from $4000
  in a,(6)
  inc a
  out (6),a
  ld h,40h
  pop bc
  ;if BC<$4000, just LDIR the rest
  ld a,b
  sub h
  jr c,read_from_RAM
  ld b,a
  push bc
  ld b,h
  ld c,l
  jp block_loop
read_from_ARC_noboundary:
;  or a     ;already reset
  sbc hl,bc
read_from_RAM:
  ldir
  in a,(6)
  ld b,a
page_restore = $+1
  ld a,0
  out (6),a
  ld a,b
  ld b,c
  ret
ReadRAM:
  ldir
  ret
It needs to run in RAM and uses SMC.