The HIRES drawing screen ends in BF3F.
The 3 TEXT lines at the bottom range from BF68 to BFE0.

What happens between BF40 and BF67? Is this wasted RAM space?
Is this line invisible because something like it holds an attribute to switch from HIRES to TEXT?
Do you think thiese bytes can be used to store some routine, knowing it might be affected by TEXT/HIRES/CLS commands?

I've not tested, but I would assume that these 40 bytes are free to use, like the bytes from BFE0 to BFFF

It seems so! It's initialized as the following TEXT lines, just not displayed. This rings a bell with one of your pages where you explain the TEXT/HIRES mix mode and in an example, the higher line of the TEXT characters is not displayed by the ULA.

Actually that's funny. That means that by adding and saving a JMP $BF40 right before the Hires screen (in 9FFD), you can make a Hires screen self-executing some code. For instance loading the next part, which avoids a small loader.
Other option, adding this JMP at the start of the Hires screen (4C 40 BF in $A000) only displays a small glitch of two white pixels (that you can fix when executing the code in $BF40) and leaves the rest of the 1st line black.

I tried to fix the glitch with attibutes (10 00 for black paper and ink translating into BPL 00 which is neutral), but 40 and BF are graphically the exact opposite so when one is invisibe, the other appears in inverse video mode

What an interesting coincidence that this space is exactly one text mode line long.

I wonder if this has to do with how the video scanning addresses are generated by the ULA.
Do mi-screen mode changes modify the behavior of the address generation? That is, do HIRES and TEXT addresses continue to increment normally even when changing mode mid screen or are there additional offsets added at each switch?

It could also be that the machine designers initially wanted to have 4 lines of text at the bottom of the screen but realized that this would be too many pixels to render, and that it was simpler for them to simply insert an adder of +40 Into the address generator at the hardware HIRES/TEXT boundary than to modify the circuitry dedicated to determining the end of address generation. Intuitively, though, this seems like this would have been harder but maybe the ULA was so badly designed that this was a simpler solution.

Actually that's funny. That means that by adding and saving a JMP $BF40 right before the Hires screen (in 9FFD), you can make a Hires screen self-executing some code. For instance loading the next part, which avoids a small loader.
Other option, adding this JMP at the start of the Hires screen (4C 40 BF in $A000) only displays a small glitch of two white pixels (that you can fix when executing the code in $BF40) and leaves the rest of the 1st line black.

I do not understand what would be gained by using these 40 bytes as code rather than as simply for data. Could you elaborate on the advantages of jumping to these 40 bytes? I kinda like the idea but I fail to picture how this helps.

Actually that's funny. That means that by adding and saving a JMP $BF40 right before the Hires screen (in 9FFD), you can make a Hires screen self-executing some code. For instance loading the next part, which avoids a small loader.
Other option, adding this JMP at the start of the Hires screen (4C 40 BF in $A000) only displays a small glitch of two white pixels (that you can fix when executing the code in $BF40) and leaves the rest of the 1st line black.

I do not understand what would be gained by using these 40 bytes as code rather than as simply for data. Could you elaborate on the advantages of jumping to these 40 bytes? I kinda like the idea but I fail to picture how this helps.

That was just me having no-so-good ideas late in the night.
The idea for instance, is a slideshow. If you load a HIRES screen that self-contains the loading command for the next one, then you don't need a loader.
Except you have to be sur to be in Hires mode, so a loader is required anyway for the 1st screen

This table above does not cover all interrelations between opcodes and Oric graphic attributes but we can still learn a few things from the first 32 ones:

All the KIL! opcodes must be avoided at all costs since they stop the CPU dead and require a power off/on cycle.
This means that one color can never be used for paper nor ink : green (values $02 and $12).

There is one branching instructions in the "non pixel" serial attributes: BPL.
This means that it could be used to allow graphical data which comes right after the branch to be freely used for graphics without restrictions.
This could be useful to protect some areas of the HIRES ram to not be executed, though the instruction is a conditional so one would need to make sure the negative flag is not set to ensure the branch is taken.

The BRK instruction maps directly to "set ink to black" and will obviously jump to the interruption vector so careful modification of the return pointer on the stack could also allow to skip some graphical data untouched.

Overall, the first 32 opcodes do very little: only one conditional branch, BRK but no register loading or storing, so they could be used as graphic data and code without too much damaging consequences as long as the KIL instructions are carefully avoided.

The fact I find the funniest about a mixed code/HIRES screen is that it requires to avoid the green color or to be quite clever with branches to allow it intermittently.

Now, dealing with pixel data is probably a much more difficult and perilous task. I will leave it to others.

There are also all the "invert" bytes values that could be used... But I mean, technically it can be achived, but for a human brain this seems a bit complicated
To anyone willing to dig this subject, another way to begin with could be checking existing known HIRES pictures, and see if they already hold some bytes sequences that could be considered as valid executable as code (or could be with little changes not affecting the picture).

There are also all the "invert" bytes values that could be used... But I mean, technically it can be achived, but for a human brain this seems a bit complicated
To anyone willing to dig this subject, another way to begin with could be checking existing known HIRES pictures, and see if they already hold some bytes sequences that could be considered as valid executable as code (or could be with little changes not affecting the picture).

Good luck with that

Finding actionable executable code inside arbitrary data - here an Oric HIRES picture, is actually a technique commonly applied in Return Oriented Programming (ROP: see this for an example and the Wikipedia ROP page for the general explanation).

There are already tools used to find and extract usable pieces of code inside some existing executable code that one can chain to execute almost any possible action (as long as the existing data offers enough variety) and they would just need to be adapted slightly to look for usable 6502 sequences of instructions inside Oric graphic data.

Back to the "ghost line"... I was thinking it could be used to save/restore, on ROM 1.0, the line that is destroyed by the status line (displayed in the middle of the HIRES screen, when Loading/saving for instance).
This brought a thought... Could all this be the remains of an old memory map?

This would explain the ROM 1.0 status line display bug in HIRES: initially, the line right after the HIRES screen would have been hidden by the ULA in HIRES, thus hiding the status line, so there was no need to handle the status line display in HIRES.

But after the ULA was designed, they decided to change the memory map, to avoid wasting the unused TEXT memory in HIRES, or HIRES memory in TEXT. So they implemented the moving of the whole HIRES display and chars areas according to the display mode.

Consequences: the "ghost line", managed by the ULA, couldn't be changed and remained after the HIRES screen, useless... And here comes the statuts line display bug in HIRES!

I've stopped trying to figure out how they came up with a bunch of ideas in the machine, mostly because I don't know enough about the background story, how they designed stuff, the budget constraints, etc...