The topic title is maybe misleading though : I don't want to program for these boards. My goal would be closer to an emulator. So programming notes like Charles McDonald's genvdp, but for CPS-1/system16 (and I can add X68000) is closer to what I'm looking for.

I doubt you'll be able to find such notes. I'd recommend to learn MAME emulator structure.

for example CPS1:
src/mame/drivers/cps1.cpp - this is base CPS1 driver, you may find where:
void cps_state::main_map(address_map &map) - main CPU memory map
void cps_state::sub_map(address_map &map) - sound CPU memory map
MACHINE_CONFIG_START(cps_state::cps1_10MHz) - all the CPS1 hardware components
and other parts, most of them is not hard to understand if you a bit familiar with emulator development in general.

I'm digging into MAME source code. It's really interesting. But file locations are sometimes weird. Why is the Megadrive VDP code (315_5313.cpp) in devices subdir and not in video ? Header files can be anywhere and some of them contains code...

I'm assuming Tomahomae wasn't referring to the programmer manual (and yeah, some of the branch options often are skipped).

BPL = branch if plus (if result is positive)
BMI = branch if minus (if result is negative)

They don't fall under the obvious comparison stuff (=, ≠, <, >, ≤, ≥) so I can see how guides may glance over them, but they're extremely useful in practice, especially after a MOVE or TST (as it's basically a faster way to check the MSB).

Quite right. EQ and MI give a quick way to discern three states for any integer - zero, positive (and not zero), and negative. That's often enough for many flags without needing an actual comparison against constants. Of course, the 6502 BIT instruction was even more handy as it gave you instant checks on both bit7 and bit6, as well as zero/non-zero. I used that quite a bit back on my old Atari.

Not so long time ago I disassembled Riot City (System 16) using internal disassembler of MAME debugger. But there is a some strange thing in main CPU program code rom disassembly - it remains a real code at least a little bit at the separate sections (003154~0034DE, 0035E2~0036C6, 0037CA~003C78, etc.) only, and noticeable its part is a giant "walls" of ori.b #$x, D0 commands at the beginning, nops in the middle, and move.l -(A0), D0 or dc.w $ffxx; opcode 1111 command at the end.

I hope, the disassemblation passed correctly, I choosed the right memory sections, and there is no undecrypted code left?