LibretroAdmin 54fe4f3754 Savestates: format V4, 25.5 MB down to 6.6 MB
A state stored the whole 22 MB DRAM allocation -- sized for the
largest memory configuration and the high-resolution VRAM copies --
plus both ROMs, whatever the game used, and the DSP's 70 KB of decode
tables. V4 keeps everything else as it was and changes two chunks:

- MEM2 replaces MEM. It holds the memory configuration, then only the
  RAM that configuration uses (DRAM, VRAM and VRAM's three high-
  resolution copies), then NVRAM. The copies are kept whether or not
  high resolution is on, because it can be switched mid-game and the
  state size must not change under a frontend that sized its buffers
  once; the configuration itself is fixed for a session. The ROMs are
  left out: they are the BIOS and font loaded for the session and
  never change. For the stock 2 MB/1 MB configuration that is 6 MB of
  RAM instead of 22 MB, and 2 MB of ROM gone.
- DSP2 replaces DSPP. INSTTRAS, REGCONV and BRCONDTAB are decode tables
  opera_dsp_init() builds and nothing changes, so they are not stored;
  a load keeps the running core's.

V3 states still load: MEM and DSPP are still read, and the tables a
DSPP chunk carries are stepped over. A core without this change
refuses a V4 state as an unknown version.

Measured with a libretro driver, stock configuration, together with
the array I/O change before this:

             size        serialize   unserialize
  before     25550222    3.8 ms      4.2 ms
  V4          6605970    0.5 ms      0.6 ms

Checked: a V3 state saved by the previous core loads and plays the
next 240 frames with audio and video identical to the original run; a
V4 state does the same; save-load-save is byte-identical; a replay of
60 frames from a loaded state matches; a sweep flipping 9721 bytes
never lets a refused load change the running state; and the changed
files build big-endian (PowerPC).
2026-10-28 20:58:23 +01:00
2026-08-04 22:55:20 -05:00
2020-02-17 12:05:08 -05:00
2020-02-17 12:05:08 -05:00
2020-02-17 12:05:08 -05:00
2021-10-21 00:03:51 -04:00
2023-12-31 12:14:34 -06:00
2026-10-12 19:17:46 -05:00
2020-02-17 12:05:08 -05:00

opera-libretro

Opera is a fork of 4DO, originally a port of 4DO, itself a fork of FreeDO, to libretro. The fork/rename occurred due to the original 4DO project being dormant and to differenciate the project due to new development and focus.

ROMS

Filename Hash
opera-boot.bin Build-dependent (external ROM)
panafz1.bin md5:f47264dd47fe30f73ab3c010015c155b
panafz1j.bin md5:a496cfdded3da562759be3561317b605
panafz1j-norsa.bin md5:f6c71de7470d16abe4f71b1444883dc8
panafz10.bin md5:51f2f43ae2f3508a14d9f56597e2d3ce
panafz10-norsa.bin md5:1477bda80dc33731a65468c1f5bcbee9
panafz10e-anvil.bin md5:a48e6746bd7edec0f40cff078f0bb19f
panafz10e-anvil-norsa.bin md5:cf11bbb5a16d7af9875cca9de9a15e09
goldstar.bin md5:8639fd5e549bd6238cfee79e3e749114
sanyotry.bin md5:35fa1a1ebaaeea286dc5cd15487c13ea
3do_arcade_saot.bin md5:8970fc987ab89a7f64da9f8a8c4333ff

For certain Japanese games a second "Kanji" ROM is necessary.

Filename Hash
panafz1-kanji.bin md5:b8dc97f778a6245c58e064b0312e8281
panafz1j-kanji.bin md5:c23fb5d5e6bb1c240d02cf968972be37
panafz10ja-anvil-kanji.bin md5:428577250f43edc902ea239c50d2240d

opera-boot.bin

Opera includes Opera Boot (Built-in) as its first BIOS setting and default (opera-boot-internal). Its compressed ROM is embedded in the core, so no external BIOS file is required.

Supported BIOS ROMs placed in the RetroArch / libretro System Directory appear after the built-in option and can be selected normally. This includes opera-boot.bin, shown separately as Opera Boot (System). "norsa" versions have the RSA encryption check disabled, allowing unsigned software to run.

More details about the opera-boot boot ROM can be found at: https://github.com/trapexit/opera-boot

S
Description
Port of 4DO/libfreedo to libretro.
Readme
9.1 MiB
0 Stars 1 Watchers 0 Forks
Languages
C 94.7%
C++ 3.2%
SourcePawn 1.3%
Makefile 0.6%
Python 0.1%
Other 0.1%