v0.6.0 — False Color / EL Zone toggle with the EL Zone scale (test release)

SIGMA fp, firmware Ver.5.02 only. Not the fp L.

fp-fc-scale-card.zip contains AutoRun.txt and a README.txt. No VSHL.BIN and no USB shell: the code is carried in the AutoRun and lives in RAM. Nothing is flashed.

Setup

1. Menu → Custom → button settings → assign False Color to a button.
2. Copy AutoRun.txt to the SD card root (only one AutoRun.txt on the card).
3. Battery out for 10 s, battery in, power on with the card. Boot takes ~30 s longer than stock.

Use

On the button assigned to False Color:

press	result
1	False Color / EL Zone on, and it stays on
2	the EL Zone scale across the bottom of live view
3	both off

EL Zone or False Color follows your own False Color Style setting.

What it is

• Scale geometry and colours are the firmware's own: FalseColorBarDrawer band table 0xC0D1B74C (15 bands, half-stop bands 70 px, others 68), palette 0xC0D1B34C (A,Y,U,V, converted with the firmware's matrix), label glyphs from the ElZoneScale scene.
• Drawn on the 16-bit main OSD layer inside the display submit (0xC02E8A08), once per frame; a press paints the front buffer directly.
• Press and release of the assigned button are the two CameraIF methods 0xC03722E8 / 0xC0372330, replaced so the mode latches.
• Emulator verification: tools/verify_fcscale.py, 21 cases; render in builds/fcscale/scale.png.

Known

• The order of the three colour nibbles in the main layer's 16-bit pixel is not established from the firmware; the build uses A-R-G-B. If the -4/-3 bands show orange instead of blue on your camera, report it.
• Not tested: HDMI output, playback/menu/record transitions while latched.

Changing builds, reverting

A soft power cycle does not clear RAM on this camera. Pull the battery for ~10 s whenever you change to a different AutoRun.txt, and to revert: remove AutoRun.txt, battery out, cold boot.

RAM-only and reversible, but a RAM change can still spoil a take. Do not use it on a paid job.

v0.5.0 — test release

sigma-fp-lab — test release

SIGMA fp, firmware Ver.5.02 only. Not the fp L.

Two cards. Both load from the SD card at boot and live in RAM: nothing is
flashed, and pulling the battery puts the camera back exactly as it was.

Download	Who it is for
fp-menu-card.zip	Everyone. The on-camera menu.
fp-menu-card-dev.zip	Development: same menu plus the USB shell and the SEL diagnostics.

Extract the zip to the card root, so the card holds AutoRun.txt and
VSHL.BIN. Cold boot with the card in. Both files are required and they are a
matched pair (the code lives in VSHL.BIN), so never mix files between zips.

Before you use it

Unmap UP and RIGHT. In the camera: Menu → Custom → button settings, and
make sure nothing is assigned to UP or to RIGHT. The card uses both keys while
you are in live view, so anything mapped there will not fire.

In the camera's own menu and in playback the keys stay the camera's, so you can
navigate normally.

Using it

RIGHT moves down the list, UP switches the highlighted option on. Everything
boots OFF and Stock clears it all. The panel is drawn top right, hides after
about four seconds, and comes back on the next key.

Option	What you get
Open Gate	Full-sensor 3032×2012 (3:2) CinemaDNG instead of the 16:9 crop
M98 30P / M98 60P	Alternative readout at 30p / 60p
M130, M130 Fast	3968×2640 cropped RAW12
M6 4K	4176×2174, 14-bit full readout
Gyro-Gate	Open gate together with the gyro metadata build
2K120	2016×1344 at 120 instead of 60 (mode 56)
672 240	2016×672 at 240 instead of 60 (mode 12)
FALSE COL	False colour as a latch, instead of a button you hold
SEL	A readout, not a switch (dev card only)

Turning an option on also selects the framerate it needs, which is what makes
the camera adopt it. You should not have to switch the preset by hand.

Credits

This is a menu and a loader around work other people did first. The recording
modes are not our discovery:

• ijigen/fpSup — worked out how to run
  code on this camera at all, the AutoRun loader, the USB shell, the gyro
  metadata build, and the sensor mode table these options are selected from.
  Open gate was submitted back as fpSup#2.
• FP3K — the display accessor (0xC0437E98) the standby green fix is
  built on.
• magiclantern
  — reference for how this kind of thing is done, no code used.

No SIGMA firmware is included; you supply your own copy.

What is proven, and what is not

Confirmed on hardware: open gate records and the files are correct; the menu,
Stock, the busy guard; FALSE COL; the auto re-latch; the key gate.

Not confirmed, and where help is wanted:

• 120fps and 240fps cadence. 2K120 and 672 240 select the faster sensor
  readout for a cell that keeps its resolution, so they need a fast USB-C SSD
  and nobody has confirmed the files really run at the rate the sensor is
  clocked to. Shoot a clip and read the DNG FrameRate tag and the frame count.
  This is the single most useful thing anyone can report back.

  Only swaps whose target mode is not already in the camera's picker table
  are offered. 3032×1708@120 (mode 58) and 2088×1174@120 (mode 103) are not in
  the menu for that reason: switching them off would rewrite the cells that were
  genuinely 58 or 103. They remain available as the standalone fhd120 and
  2k120 cards.

• M130 / M6 / M98 in real use. They record, but rolling shutter, banding
  and highlight behaviour have had almost no real footage through them.

• Other bodies. Everything was worked out on one camera.

Known limits

• Focus magnification and false colour cannot be had during a take.
  Measured, not guessed: magnification is a distinct sensor readout mode
  (selector 0x11–0x28, e.g. 6064×2022) and recording runs a different one.
• Open gate's preview greens while recording. The files are fine.
• No firmware-version guard in the card. Using it on anything but Ver.5.02 is
  on you.
• The dev card's USB shell replaces the normal PTP interface, so SIGMA Camera
  Control will not see the camera while it is loaded.

Safety

RAM-only and reversible, but a RAM change can still spoil a take. Do not use it
on a paid job, do not record anything you cannot afford to lose, and to go back
to stock remove AutoRun.txt and cold boot with the battery out ~10 s.

v0.4.2 — test release

sigma-fp-lab — test release

SIGMA fp, firmware Ver.5.02 only. Not the fp L.

Two cards. Both load from the SD card at boot and live in RAM: nothing is
flashed, and pulling the battery puts the camera back exactly as it was.

Download	Who it is for
fp-menu-card.zip	Everyone. The on-camera menu.
fp-menu-card-dev.zip	Development: same menu plus the USB shell and the SEL diagnostics.

Extract the zip to the card root, so the card holds AutoRun.txt and
VSHL.BIN. Cold boot with the card in. Both files are required and they are a
matched pair (the code lives in VSHL.BIN), so never mix files between zips.

Before you use it

Unmap UP and RIGHT. In the camera: Menu → Custom → button settings, and
make sure nothing is assigned to UP or to RIGHT. The card uses both keys while
you are in live view, so anything mapped there will not fire.

In the camera's own menu and in playback the keys stay the camera's, so you can
navigate normally.

Using it

RIGHT moves down the list, UP switches the highlighted option on. Everything
boots OFF and Stock clears it all. The panel is drawn top right, hides after
about four seconds, and comes back on the next key.

Option	What you get
Open Gate	Full-sensor 3032×2012 (3:2) CinemaDNG instead of the 16:9 crop
M98 30P / M98 60P	Alternative readout at 30p / 60p
M130, M130 Fast	3968×2640 cropped RAW12
M6 4K	4176×2174, 14-bit full readout
Gyro-Gate	Open gate together with the gyro metadata build
FALSE COL	False colour as a latch, instead of a button you hold
SEL	A readout, not a switch (dev card only)

Turning an option on also selects the framerate it needs, which is what makes
the camera adopt it. You should not have to switch the preset by hand.

Credits

This is a menu and a loader around work other people did first. The recording
modes are not our discovery:

• ijigen/fpSup — worked out how to run
  code on this camera at all, the AutoRun loader, the USB shell, the gyro
  metadata build, and the sensor mode table these options are selected from.
  Open gate was submitted back as fpSup#2.
• FP3K — the display accessor (0xC0437E98) the standby green fix is
  built on.
• magiclantern
  — reference for how this kind of thing is done, no code used.

No SIGMA firmware is included; you supply your own copy.

What is proven, and what is not

Confirmed on hardware: open gate records and the files are correct; the menu,
Stock, the busy guard; FALSE COL; the auto re-latch; the key gate.

Not confirmed, and where help is wanted:

• 120fps cadence. The high-fps cards hit ~389–441 MB/s and need a fast
  USB-C SSD. Nobody has confirmed the files really run at 120. Shoot a clip and
  read the DNG FrameRate tag and the frame count.
• M130 / M6 / M98 in real use. They record, but rolling shutter, banding
  and highlight behaviour have had almost no real footage through them.
• Other bodies. Everything was worked out on one camera.

Known limits

• Focus magnification and false colour cannot be had during a take.
  Measured, not guessed: magnification is a distinct sensor readout mode
  (selector 0x11–0x28, e.g. 6064×2022) and recording runs a different one.
• Open gate's preview greens while recording. The files are fine.
• No firmware-version guard in the card. Using it on anything but Ver.5.02 is
  on you.
• The dev card's USB shell replaces the normal PTP interface, so SIGMA Camera
  Control will not see the camera while it is loaded.

Safety

RAM-only and reversible, but a RAM change can still spoil a take. Do not use it
on a paid job, do not record anything you cannot afford to lose, and to go back
to stock remove AutoRun.txt and cold boot with the battery out ~10 s.

v0.4.1 — panel stays down after the camera's menu (test release)

sigma-fp-lab — test release

SIGMA fp, firmware Ver.5.02 only. Not the fp L.

Two cards. Both are RAM-only: they load from the SD card at boot, nothing is
flashed, and pulling the battery puts the camera back exactly as it was.

Card	Who it is for
fp-menu-card.zip	Everyone. The on-camera menu, nothing else.
fp-menu-card-dev.zip	Development: same menu plus the USB shell and the SEL diagnostics.

Extract the zip straight to the card root, so the card holds AutoRun.txt and
VSHL.BIN. Cold boot with the card in. Both files are required, and they are
a matched pair: each card has its own VSHL.BIN (the menu code lives there,
AutoRun.txt is only the loader), so never mix files between the two zips.

About UP and RIGHT

The card uses UP and RIGHT while you are in live view: RIGHT moves down the
list, UP switches the highlighted option on. There is no shortcut to open the
menu, the panel is simply there.

In the camera's own menu and in playback the keys are the camera's, so you
navigate SIGMA's menu normally and anything you have assigned to those buttons
still works there. The card decides by reading the camera's screen state
(snapshot +0x1F8: 2 live view, 4 playback, 5 menu), measured on hardware.

If you have a custom function on UP or RIGHT that you use in live view, it
will not fire while this card is loaded.

What it does

An on-camera menu, drawn top right. RIGHT moves down the list, UP turns the
highlighted option on. Everything starts off. Stock turns everything off again. After
switching an option, change the recording mode away and back once so the camera
re-latches the geometry, otherwise the current take keeps the old one.

The panel lists every option at once with the current row highlighted. It has
its own thread, so it repaints about seven times a second, hides itself after
roughly four seconds of nothing changing, and reappears on the next key. It also
notices changes made anywhere else in the camera rather than only on a keypress.

Turning an option on now makes the camera adopt it. The menu writes geometry
cells, and nothing re-reads those on its own, which is why earlier builds needed
you to switch the recording preset away and back. Each option now also selects
the framerate it needs, and that write is what forces the re-latch. It is
drawn by our own code into the OSD layer, not by the firmware's one-line debug
text, which is fixed at the top left and could not be moved.

Recording modes the stock firmware does not offer:

Option	What you get
Open Gate	Full-sensor 3032×2012 (3:2) CinemaDNG instead of the 16:9 crop
M98 30P / M98 60P	Alternative readout at 30p / 60p
M130, M130 Fast	3968×2640 cropped RAW12
M6	Full-readout 14-bit class mode
Gyro-Gate	Open gate together with the gyro metadata build
SEL	A readout, not a switch (dev card only)
FALSE COL	False colour as a latch, not a held button

False colour without holding a button. The camera only exposes false colour
while an assigned function key is held down: the key calls CameraIF +0xCC on
press (rec-manager event 0x21) and +0xD0 on release (0x22). Nothing is stored,
which is why it never showed up in a diff of the settings store. The FALSE COL
row calls those two methods itself, so it stays on until you turn it off. It
writes no geometry cell, so unlike every other row it needs no re-latch.

The menu writes the camera's own geometry cells. It refuses to act while the
camera is busy, and it never changes a recording already in progress.

What is proven, and what is not

Proven on hardware:

• Open gate records and the files are correct; other modes stay untouched
  (the record hook is gated on selector r5==175).
• The menu itself: options apply, Stock clears them, the busy guard holds.
• The standby live-view green fix, on the camera it was fingerprinted against.

Not proven, and where help is wanted:

• The panel's thread, the auto re-latch and the FALSE COL readout are new.
  The offline emulator models the OSD surface, the display calls, the task
  creation and the framerate write, and asserts the panel really paints at
  780,60 and that a toggle really queues the re-latch. A model is still not a
  camera.

• The drawn panel is new on the card. It ran for weeks pushed over USB, and
  it now travels in VSHL.BIN like everything else. The offline emulator paints
  it into a modelled 1024x682 OSD surface and passes, but a model is not a
  camera. Test on the dev card first; if it locks up, pull the battery,
  nothing is written to flash.

• FALSE COL was confirmed working on a card. It is the one row that changes
  no geometry, so it needs no preset re-latch.

• High-fps cadence. The 120fps experiments hit ~389–441 MB/s and need a fast
  USB-C SSD. Nobody has independently confirmed the recorded files really run at
  120fps. Shoot a clip, read the DNG FrameRate tag and the frame count.

• M130 / M6 / M98 in real use. These are firmware-table modes that the stock
  menu never names. They record, but rolling shutter, banding and highlight
  behaviour have had almost no real-world footage put through them.

• The record-time monitor. Open gate's preview greens while recording. The
  files are fine. The standby fix does not cover the record path.

• Other bodies. Everything here was worked out on one camera. The display fix
  in particular checks a fingerprint and safely does nothing if it does not match.
  If it does nothing on yours, that is the expected safe path, please say so.

Known limits, stated plainly

• Focus magnification and false colour cannot be had during a take. This is
  measured, not guessed: magnification is a distinct sensor readout mode
  (selector 0x11–0x28, e.g. 6064×2022), and recording runs a different one. See
  docs/overlay/README.md.
• There is no firmware-version guard in the card. Using it on anything other
  than Ver.5.02 is on you.
• The dev card's USB shell replaces the camera's normal PTP interface, so
  SIGMA Camera Control and tethering tools will not see the camera while it runs.

Safety

Read cards/README.md before using a card. In short: RAM-only and reversible,
but a RAM change can still spoil a take. Do not run these on a paid job, do not
record anything you cannot afford to lose, and remove AutoRun.txt plus a
battery-out cold boot returns the camera to stock.

Built on ijigen/fpSup, which worked out how to
run code on this camera. No SIGMA firmware is included; you supply your own.

v0.4.0 — the camera's menu is the camera's again (test release)

sigma-fp-lab — test release

SIGMA fp, firmware Ver.5.02 only. Not the fp L.

Two cards. Both are RAM-only: they load from the SD card at boot, nothing is
flashed, and pulling the battery puts the camera back exactly as it was.

Card	Who it is for
fp-menu-card.zip	Everyone. The on-camera menu, nothing else.
fp-menu-card-dev.zip	Development: same menu plus the USB shell and the SEL diagnostics.

Extract the zip straight to the card root, so the card holds AutoRun.txt and
VSHL.BIN. Cold boot with the card in. Both files are required, and they are
a matched pair: each card has its own VSHL.BIN (the menu code lives there,
AutoRun.txt is only the loader), so never mix files between the two zips.

About UP and RIGHT

The card uses UP and RIGHT while you are in live view: RIGHT moves down the
list, UP switches the highlighted option on. There is no shortcut to open the
menu, the panel is simply there.

In the camera's own menu and in playback the keys are the camera's, so you
navigate SIGMA's menu normally and anything you have assigned to those buttons
still works there. The card decides by reading the camera's screen state
(snapshot +0x1F8: 2 live view, 4 playback, 5 menu), measured on hardware.

If you have a custom function on UP or RIGHT that you use in live view, it
will not fire while this card is loaded.

What it does

An on-camera menu, drawn top right. RIGHT moves down the list, UP turns the
highlighted option on. Everything starts off. Stock turns everything off again. After
switching an option, change the recording mode away and back once so the camera
re-latches the geometry, otherwise the current take keeps the old one.

The panel lists every option at once with the current row highlighted. It has
its own thread, so it repaints about seven times a second, hides itself after
roughly four seconds of nothing changing, and reappears on the next key. It also
notices changes made anywhere else in the camera rather than only on a keypress.

Turning an option on now makes the camera adopt it. The menu writes geometry
cells, and nothing re-reads those on its own, which is why earlier builds needed
you to switch the recording preset away and back. Each option now also selects
the framerate it needs, and that write is what forces the re-latch. It is
drawn by our own code into the OSD layer, not by the firmware's one-line debug
text, which is fixed at the top left and could not be moved.

Recording modes the stock firmware does not offer:

Option	What you get
Open Gate	Full-sensor 3032×2012 (3:2) CinemaDNG instead of the 16:9 crop
M98 30P / M98 60P	Alternative readout at 30p / 60p
M130, M130 Fast	3968×2640 cropped RAW12
M6	Full-readout 14-bit class mode
Gyro-Gate	Open gate together with the gyro metadata build
SEL	A readout, not a switch (dev card only)
FALSE COL	False colour as a latch, not a held button

False colour without holding a button. The camera only exposes false colour
while an assigned function key is held down: the key calls CameraIF +0xCC on
press (rec-manager event 0x21) and +0xD0 on release (0x22). Nothing is stored,
which is why it never showed up in a diff of the settings store. The FALSE COL
row calls those two methods itself, so it stays on until you turn it off. It
writes no geometry cell, so unlike every other row it needs no re-latch.

The menu writes the camera's own geometry cells. It refuses to act while the
camera is busy, and it never changes a recording already in progress.

What is proven, and what is not

Proven on hardware:

• Open gate records and the files are correct; other modes stay untouched
  (the record hook is gated on selector r5==175).
• The menu itself: options apply, Stock clears them, the busy guard holds.
• The standby live-view green fix, on the camera it was fingerprinted against.

Not proven, and where help is wanted:

• The panel's thread, the auto re-latch and the FALSE COL readout are new.
  The offline emulator models the OSD surface, the display calls, the task
  creation and the framerate write, and asserts the panel really paints at
  780,60 and that a toggle really queues the re-latch. A model is still not a
  camera.

• The drawn panel is new on the card. It ran for weeks pushed over USB, and
  it now travels in VSHL.BIN like everything else. The offline emulator paints
  it into a modelled 1024x682 OSD surface and passes, but a model is not a
  camera. Test on the dev card first; if it locks up, pull the battery,
  nothing is written to flash.

• FALSE COL was confirmed working on a card. It is the one row that changes
  no geometry, so it needs no preset re-latch.

• High-fps cadence. The 120fps experiments hit ~389–441 MB/s and need a fast
  USB-C SSD. Nobody has independently confirmed the recorded files really run at
  120fps. Shoot a clip, read the DNG FrameRate tag and the frame count.

• M130 / M6 / M98 in real use. These are firmware-table modes that the stock
  menu never names. They record, but rolling shutter, banding and highlight
  behaviour have had almost no real-world footage put through them.

• The record-time monitor. Open gate's preview greens while recording. The
  files are fine. The standby fix does not cover the record path.

• Other bodies. Everything here was worked out on one camera. The display fix
  in particular checks a fingerprint and safely does nothing if it does not match.
  If it does nothing on yours, that is the expected safe path, please say so.

Known limits, stated plainly

• Focus magnification and false colour cannot be had during a take. This is
  measured, not guessed: magnification is a distinct sensor readout mode
  (selector 0x11–0x28, e.g. 6064×2022), and recording runs a different one. See
  docs/overlay/README.md.
• There is no firmware-version guard in the card. Using it on anything other
  than Ver.5.02 is on you.
• The dev card's USB shell replaces the camera's normal PTP interface, so
  SIGMA Camera Control and tethering tools will not see the camera while it runs.

Safety

Read cards/README.md before using a card. In short: RAM-only and reversible,
but a RAM change can still spoil a take. Do not run these on a paid job, do not
record anything you cannot afford to lose, and remove AutoRun.txt plus a
battery-out cold boot returns the camera to stock.

Built on ijigen/fpSup, which worked out how to
run code on this camera. No SIGMA firmware is included; you supply your own.

v0.3.1 — fixes the double-click crash (test release)

sigma-fp-lab — test release

SIGMA fp, firmware Ver.5.02 only. Not the fp L.

Two cards. Both are RAM-only: they load from the SD card at boot, nothing is
flashed, and pulling the battery puts the camera back exactly as it was.

Card	Who it is for
fp-menu-card.zip	Everyone. The on-camera menu, nothing else.
fp-menu-card-dev.zip	Development: same menu plus the USB shell and the SEL diagnostics.

Extract the zip straight to the card root, so the card holds AutoRun.txt and
VSHL.BIN. Cold boot with the card in. Both files are required, and they are
a matched pair: each card has its own VSHL.BIN (the menu code lives there,
AutoRun.txt is only the loader), so never mix files between the two zips.

Before you boot it: clear your UP and RIGHT assignments

This card takes the UP and RIGHT keys for itself the whole time it is
loaded. There is no shortcut to open the menu, the keys are simply ours.

So, in the camera: Menu -> Custom -> button settings, and clear anything you
have assigned to UP and to RIGHT. Whatever is mapped there will not fire while
the card is in.

Known bug, being worked on: because the keys are taken globally, pressing
UP or RIGHT while you are inside SIGMA's own menu also moves our cursor in the
background. Nothing is written until you press UP on a row, but it is untidy and
it is the next thing on the list.

What it does

An on-camera menu, drawn top right. RIGHT moves down the list, UP turns the
highlighted option on. Everything starts off. Stock turns everything off again. After
switching an option, change the recording mode away and back once so the camera
re-latches the geometry, otherwise the current take keeps the old one.

The panel lists every option at once with the current row highlighted. It has
its own thread, so it repaints about seven times a second, hides itself after
roughly four seconds of nothing changing, and reappears on the next key. It also
notices changes made anywhere else in the camera rather than only on a keypress.

Turning an option on now makes the camera adopt it. The menu writes geometry
cells, and nothing re-reads those on its own, which is why earlier builds needed
you to switch the recording preset away and back. Each option now also selects
the framerate it needs, and that write is what forces the re-latch. It is
drawn by our own code into the OSD layer, not by the firmware's one-line debug
text, which is fixed at the top left and could not be moved.

Recording modes the stock firmware does not offer:

Option	What you get
Open Gate	Full-sensor 3032×2012 (3:2) CinemaDNG instead of the 16:9 crop
M98 30P / M98 60P	Alternative readout at 30p / 60p
M130, M130 Fast	3968×2640 cropped RAW12
M6	Full-readout 14-bit class mode
Gyro-Gate	Open gate together with the gyro metadata build
SEL	A readout, not a switch (dev card only)
FALSE COL	False colour as a latch, not a held button

False colour without holding a button. The camera only exposes false colour
while an assigned function key is held down: the key calls CameraIF +0xCC on
press (rec-manager event 0x21) and +0xD0 on release (0x22). Nothing is stored,
which is why it never showed up in a diff of the settings store. The FALSE COL
row calls those two methods itself, so it stays on until you turn it off. It
writes no geometry cell, so unlike every other row it needs no re-latch.

The menu writes the camera's own geometry cells. It refuses to act while the
camera is busy, and it never changes a recording already in progress.

What is proven, and what is not

Proven on hardware:

• Open gate records and the files are correct; other modes stay untouched
  (the record hook is gated on selector r5==175).
• The menu itself: options apply, Stock clears them, the busy guard holds.
• The standby live-view green fix, on the camera it was fingerprinted against.

Not proven, and where help is wanted:

• The panel's thread, the auto re-latch and the FALSE COL readout are new.
  The offline emulator models the OSD surface, the display calls, the task
  creation and the framerate write, and asserts the panel really paints at
  780,60 and that a toggle really queues the re-latch. A model is still not a
  camera.

• The drawn panel is new on the card. It ran for weeks pushed over USB, and
  it now travels in VSHL.BIN like everything else. The offline emulator paints
  it into a modelled 1024x682 OSD surface and passes, but a model is not a
  camera. Test on the dev card first; if it locks up, pull the battery,
  nothing is written to flash.

• FALSE COL was confirmed working on a card. It is the one row that changes
  no geometry, so it needs no preset re-latch.

• High-fps cadence. The 120fps experiments hit ~389–441 MB/s and need a fast
  USB-C SSD. Nobody has independently confirmed the recorded files really run at
  120fps. Shoot a clip, read the DNG FrameRate tag and the frame count.

• M130 / M6 / M98 in real use. These are firmware-table modes that the stock
  menu never names. They record, but rolling shutter, banding and highlight
  behaviour have had almost no real-world footage put through them.

• The record-time monitor. Open gate's preview greens while recording. The
  files are fine. The standby fix does not cover the record path.

• Other bodies. Everything here was worked out on one camera. The display fix
  in particular checks a fingerprint and safely does nothing if it does not match.
  If it does nothing on yours, that is the expected safe path, please say so.

Known limits, stated plainly

• Focus magnification and false colour cannot be had during a take. This is
  measured, not guessed: magnification is a distinct sensor readout mode
  (selector 0x11–0x28, e.g. 6064×2022), and recording runs a different one. See
  docs/overlay/README.md.
• There is no firmware-version guard in the card. Using it on anything other
  than Ver.5.02 is on you.
• The dev card's USB shell replaces the camera's normal PTP interface, so
  SIGMA Camera Control and tethering tools will not see the camera while it runs.

Safety

Read cards/README.md before using a card. In short: RAM-only and reversible,
but a RAM change can still spoil a take. Do not run these on a paid job, do not
record anything you cannot afford to lose, and remove AutoRun.txt plus a
battery-out cold boot returns the camera to stock.

Built on ijigen/fpSup, which worked out how to
run code on this camera. No SIGMA firmware is included; you supply your own.

v0.3.0 — the panel gets a thread, and toggles now stick (test release)

sigma-fp-lab — test release

SIGMA fp, firmware Ver.5.02 only. Not the fp L.

Two cards. Both are RAM-only: they load from the SD card at boot, nothing is
flashed, and pulling the battery puts the camera back exactly as it was.

Card	Who it is for
fp-menu-card.zip	Everyone. The on-camera menu, nothing else.
fp-menu-card-dev.zip	Development: same menu plus the USB shell and the SEL diagnostics.

Extract the zip straight to the card root, so the card holds AutoRun.txt and
VSHL.BIN. Cold boot with the card in. Both files are required, and they are
a matched pair: each card has its own VSHL.BIN (the menu code lives there,
AutoRun.txt is only the loader), so never mix files between the two zips.

Before you boot it: clear your UP and RIGHT assignments

This card takes the UP and RIGHT keys for itself the whole time it is
loaded. There is no shortcut to open the menu, the keys are simply ours.

So, in the camera: Menu -> Custom -> button settings, and clear anything you
have assigned to UP and to RIGHT. Whatever is mapped there will not fire while
the card is in.

Known bug, being worked on: because the keys are taken globally, pressing
UP or RIGHT while you are inside SIGMA's own menu also moves our cursor in the
background. Nothing is written until you press UP on a row, but it is untidy and
it is the next thing on the list.

What it does

An on-camera menu, drawn top right. RIGHT moves down the list, UP turns the
highlighted option on. Everything starts off. Stock turns everything off again. After
switching an option, change the recording mode away and back once so the camera
re-latches the geometry, otherwise the current take keeps the old one.

The panel lists every option at once with the current row highlighted. It has
its own thread, so it repaints about seven times a second, hides itself after
roughly four seconds of nothing changing, and reappears on the next key. It also
notices changes made anywhere else in the camera rather than only on a keypress.

Turning an option on now makes the camera adopt it. The menu writes geometry
cells, and nothing re-reads those on its own, which is why earlier builds needed
you to switch the recording preset away and back. Each option now also selects
the framerate it needs, and that write is what forces the re-latch. It is
drawn by our own code into the OSD layer, not by the firmware's one-line debug
text, which is fixed at the top left and could not be moved.

Recording modes the stock firmware does not offer:

Option	What you get
Open Gate	Full-sensor 3032×2012 (3:2) CinemaDNG instead of the 16:9 crop
M98 30P / M98 60P	Alternative readout at 30p / 60p
M130, M130 Fast	3968×2640 cropped RAW12
M6	Full-readout 14-bit class mode
Gyro-Gate	Open gate together with the gyro metadata build
SEL	A readout, not a switch (dev card only)
FALSE COL	False colour as a latch, not a held button

False colour without holding a button. The camera only exposes false colour
while an assigned function key is held down: the key calls CameraIF +0xCC on
press (rec-manager event 0x21) and +0xD0 on release (0x22). Nothing is stored,
which is why it never showed up in a diff of the settings store. The FALSE COL
row calls those two methods itself, so it stays on until you turn it off. It
writes no geometry cell, so unlike every other row it needs no re-latch.

The menu writes the camera's own geometry cells. It refuses to act while the
camera is busy, and it never changes a recording already in progress.

What is proven, and what is not

Proven on hardware:

• Open gate records and the files are correct; other modes stay untouched
  (the record hook is gated on selector r5==175).
• The menu itself: options apply, Stock clears them, the busy guard holds.
• The standby live-view green fix, on the camera it was fingerprinted against.

Not proven, and where help is wanted:

• The panel's thread, the auto re-latch and the FALSE COL readout are new.
  The offline emulator models the OSD surface, the display calls, the task
  creation and the framerate write, and asserts the panel really paints at
  780,60 and that a toggle really queues the re-latch. A model is still not a
  camera.

• The drawn panel is new on the card. It ran for weeks pushed over USB, and
  it now travels in VSHL.BIN like everything else. The offline emulator paints
  it into a modelled 1024x682 OSD surface and passes, but a model is not a
  camera. Test on the dev card first; if it locks up, pull the battery,
  nothing is written to flash.

• FALSE COL was confirmed working on a card. It is the one row that changes
  no geometry, so it needs no preset re-latch.

• High-fps cadence. The 120fps experiments hit ~389–441 MB/s and need a fast
  USB-C SSD. Nobody has independently confirmed the recorded files really run at
  120fps. Shoot a clip, read the DNG FrameRate tag and the frame count.

• M130 / M6 / M98 in real use. These are firmware-table modes that the stock
  menu never names. They record, but rolling shutter, banding and highlight
  behaviour have had almost no real-world footage put through them.

• The record-time monitor. Open gate's preview greens while recording. The
  files are fine. The standby fix does not cover the record path.

• Other bodies. Everything here was worked out on one camera. The display fix
  in particular checks a fingerprint and safely does nothing if it does not match.
  If it does nothing on yours, that is the expected safe path, please say so.

Known limits, stated plainly

• Focus magnification and false colour cannot be had during a take. This is
  measured, not guessed: magnification is a distinct sensor readout mode
  (selector 0x11–0x28, e.g. 6064×2022), and recording runs a different one. See
  docs/overlay/README.md.
• There is no firmware-version guard in the card. Using it on anything other
  than Ver.5.02 is on you.
• The dev card's USB shell replaces the camera's normal PTP interface, so
  SIGMA Camera Control and tethering tools will not see the camera while it runs.

Safety

Read cards/README.md before using a card. In short: RAM-only and reversible,
but a RAM change can still spoil a take. Do not run these on a paid job, do not
record anything you cannot afford to lose, and remove AutoRun.txt plus a
battery-out cold boot returns the camera to stock.

Built on ijigen/fpSup, which worked out how to
run code on this camera. No SIGMA firmware is included; you supply your own.

v0.2.0 — the menu is drawn by us now (test release)

sigma-fp-lab — test release

SIGMA fp, firmware Ver.5.02 only. Not the fp L.

Two cards. Both are RAM-only: they load from the SD card at boot, nothing is
flashed, and pulling the battery puts the camera back exactly as it was.

Card	Who it is for
fp-menu-card.zip	Everyone. The on-camera menu, nothing else.
fp-menu-card-dev.zip	Development: same menu plus the USB shell and the SEL diagnostics.

Extract the zip straight to the card root, so the card holds AutoRun.txt and
VSHL.BIN. Cold boot with the card in. Both files are required, and they are
a matched pair: each card has its own VSHL.BIN (the menu code lives there,
AutoRun.txt is only the loader), so never mix files between the two zips.

Before you boot it: clear your UP and RIGHT assignments

This card takes the UP and RIGHT keys for itself the whole time it is
loaded. There is no shortcut to open the menu, the keys are simply ours.

So, in the camera: Menu -> Custom -> button settings, and clear anything you
have assigned to UP and to RIGHT. Whatever is mapped there will not fire while
the card is in.

Known bug, being worked on: because the keys are taken globally, pressing
UP or RIGHT while you are inside SIGMA's own menu also moves our cursor in the
background. Nothing is written until you press UP on a row, but it is untidy and
it is the next thing on the list.

What it does

An on-camera menu, drawn top right. RIGHT moves down the list, UP turns the
highlighted option on. Everything starts off. Stock turns everything off again. After
switching an option, change the recording mode away and back once so the camera
re-latches the geometry, otherwise the current take keeps the old one.

The panel lists every option at once with the current row highlighted. It is
drawn by our own code into the OSD layer, not by the firmware's one-line debug
text, which is fixed at the top left and could not be moved.

Recording modes the stock firmware does not offer:

Option	What you get
Open Gate	Full-sensor 3032×2012 (3:2) CinemaDNG instead of the 16:9 crop
M98 30P / M98 60P	Alternative readout at 30p / 60p
M130, M130 Fast	3968×2640 cropped RAW12
M6	Full-readout 14-bit class mode
Gyro-Gate	Open gate together with the gyro metadata build
SEL	A readout, not a switch (dev card only)
FALSE COL	False colour as a latch, not a held button

False colour without holding a button. The camera only exposes false colour
while an assigned function key is held down: the key calls CameraIF +0xCC on
press (rec-manager event 0x21) and +0xD0 on release (0x22). Nothing is stored,
which is why it never showed up in a diff of the settings store. The FALSE COL
row calls those two methods itself, so it stays on until you turn it off. It
writes no geometry cell, so unlike every other row it needs no re-latch.

The menu writes the camera's own geometry cells. It refuses to act while the
camera is busy, and it never changes a recording already in progress.

What is proven, and what is not

Proven on hardware:

• Open gate records and the files are correct; other modes stay untouched
  (the record hook is gated on selector r5==175).
• The menu itself: options apply, Stock clears them, the busy guard holds.
• The standby live-view green fix, on the camera it was fingerprinted against.

Not proven, and where help is wanted:

• The drawn panel is new on the card. It ran for weeks pushed over USB, and
  it now travels in VSHL.BIN like everything else. The offline emulator paints
  it into a modelled 1024x682 OSD surface and passes, but a model is not a
  camera. Test on the dev card first; if it locks up, pull the battery,
  nothing is written to flash.

• FALSE COL was confirmed working on a card. It is the one row that changes
  no geometry, so it needs no preset re-latch.

• High-fps cadence. The 120fps experiments hit ~389–441 MB/s and need a fast
  USB-C SSD. Nobody has independently confirmed the recorded files really run at
  120fps. Shoot a clip, read the DNG FrameRate tag and the frame count.

• M130 / M6 / M98 in real use. These are firmware-table modes that the stock
  menu never names. They record, but rolling shutter, banding and highlight
  behaviour have had almost no real-world footage put through them.

• The record-time monitor. Open gate's preview greens while recording. The
  files are fine. The standby fix does not cover the record path.

• Other bodies. Everything here was worked out on one camera. The display fix
  in particular checks a fingerprint and safely does nothing if it does not match.
  If it does nothing on yours, that is the expected safe path, please say so.

Known limits, stated plainly

• Focus magnification and false colour cannot be had during a take. This is
  measured, not guessed: magnification is a distinct sensor readout mode
  (selector 0x11–0x28, e.g. 6064×2022), and recording runs a different one. See
  docs/overlay/README.md.
• There is no firmware-version guard in the card. Using it on anything other
  than Ver.5.02 is on you.
• The dev card's USB shell replaces the camera's normal PTP interface, so
  SIGMA Camera Control and tethering tools will not see the camera while it runs.

Safety

Read cards/README.md before using a card. In short: RAM-only and reversible,
but a RAM change can still spoil a take. Do not run these on a paid job, do not
record anything you cannot afford to lose, and remove AutoRun.txt plus a
battery-out cold boot returns the camera to stock.

Built on ijigen/fpSup, which worked out how to
run code on this camera. No SIGMA firmware is included; you supply your own.

v0.1.0 — on-camera menu + false colour latch (test release)

sigma-fp-lab — test release

SIGMA fp, firmware Ver.5.02 only. Not the fp L.

Two cards. Both are RAM-only: they load from the SD card at boot, nothing is
flashed, and pulling the battery puts the camera back exactly as it was.

Card	Who it is for
fp-menu-card.zip	Everyone. The on-camera menu, nothing else.
fp-menu-card-dev.zip	Development: same menu plus the USB shell and the SEL diagnostics.

Extract the zip straight to the card root, so the card holds AutoRun.txt and
VSHL.BIN. Cold boot with the card in. Both files are required, and they are
a matched pair: each card has its own VSHL.BIN (the menu code lives there,
AutoRun.txt is only the loader), so never mix files between the two zips.

What it does

An on-camera menu. RIGHT moves down the list, UP turns the highlighted
option on. Everything starts off. Stock turns everything off again. After
switching an option, change the recording mode away and back once so the camera
re-latches the geometry, otherwise the current take keeps the old one.

Recording modes the stock firmware does not offer:

Option	What you get
Open Gate	Full-sensor 3032×2012 (3:2) CinemaDNG instead of the 16:9 crop
M98 30P / M98 60P	Alternative readout at 30p / 60p
M130, M130 Fast	3968×2640 cropped RAW12
M6	Full-readout 14-bit class mode
Gyro-Gate	Open gate together with the gyro metadata build
SEL	A readout, not a switch (dev card only)
FALSE COL	False colour as a latch, not a held button

False colour without holding a button. The camera only exposes false colour
while an assigned function key is held down: the key calls CameraIF +0xCC on
press (rec-manager event 0x21) and +0xD0 on release (0x22). Nothing is stored,
which is why it never showed up in a diff of the settings store. The FALSE COL
row calls those two methods itself, so it stays on until you turn it off. It
writes no geometry cell, so unlike every other row it needs no re-latch.

The menu writes the camera's own geometry cells. It refuses to act while the
camera is busy, and it never changes a recording already in progress.

What is proven, and what is not

Proven on hardware:

• Open gate records and the files are correct; other modes stay untouched
  (the record hook is gated on selector r5==175).
• The menu itself: options apply, Stock clears them, the busy guard holds.
• The standby live-view green fix, on the camera it was fingerprinted against.

Not proven, and where help is wanted:

• FALSE COL is brand new and untested on a card. It has only ever run from
  the USB-deployed overlay, where it worked. On the card it runs from the key
  path, which is where the camera's own function key runs it, but that has not
  been through a camera yet. Test it on the dev card first, and if the
  camera locks up, pull the battery: nothing is written to flash.

• High-fps cadence. The 120fps experiments hit ~389–441 MB/s and need a fast
  USB-C SSD. Nobody has independently confirmed the recorded files really run at
  120fps. Shoot a clip, read the DNG FrameRate tag and the frame count.

• M130 / M6 / M98 in real use. These are firmware-table modes that the stock
  menu never names. They record, but rolling shutter, banding and highlight
  behaviour have had almost no real-world footage put through them.

• The record-time monitor. Open gate's preview greens while recording. The
  files are fine. The standby fix does not cover the record path.

• Other bodies. Everything here was worked out on one camera. The display fix
  in particular checks a fingerprint and safely does nothing if it does not match.
  If it does nothing on yours, that is the expected safe path, please say so.

Known limits, stated plainly

• Focus magnification and false colour cannot be had during a take. This is
  measured, not guessed: magnification is a distinct sensor readout mode
  (selector 0x11–0x28, e.g. 6064×2022), and recording runs a different one. See
  docs/overlay/README.md.
• There is no firmware-version guard in the card. Using it on anything other
  than Ver.5.02 is on you.
• The dev card's USB shell replaces the camera's normal PTP interface, so
  SIGMA Camera Control and tethering tools will not see the camera while it runs.

Safety

Read cards/README.md before using a card. In short: RAM-only and reversible,
but a RAM change can still spoil a take. Do not run these on a paid job, do not
record anything you cannot afford to lose, and remove AutoRun.txt plus a
battery-out cold boot returns the camera to stock.

Built on ijigen/fpSup, which worked out how to
run code on this camera. No SIGMA firmware is included; you supply your own.