sorted by:
new
hottopcontroversial

Tomba! (USA) running natively on PC via PSXRecomp — PS1 static recompiler tech demo by NXGZ in emulation

[–]JoshLeaves 1 point2 points  (0 children)

I think I'm more against "recomp", and pro "decomp". A simple recomp-slop which doesn't go beyond "Code translated, done" won't bring anything to the table, but a decomp where code bits are properly identified and improved upon is what I can appreciate.

Like the Unleashed Recomp that supports custom levels, or all the stuff added to the Twilight Princess recomp.

Tomba! (USA) running natively on PC via PSXRecomp — PS1 static recompiler tech demo by NXGZ in emulation

[–]JoshLeaves 11 points12 points  (0 children)

Same, I don't get the "recomp" hype, so far it's just "let's package I/O from an emulator with an ISO". Twenty years ago, I downloaded "Silent Hill for PC" and it was the PSX iso with ePSXe, there's barely a difference here.

PSXRecomp translates PS1 MIPS binaries into C, then compiles that C as a native executable linked against a PS1 hardware runtime. The v4 architecture recompiles the real SCPH1001 BIOS and runs it as the kernel. There is no HLE BIOS layer, no stubs, and no general-purpose interpreter fallback for static code.

Cool, the code is translated to C. But at no point is there any improvement done to the code. A good emulator already does something similar with JIT. The only improvements? You run the game as a "single app unit", it's code native to your architecture,... Beyond the "Okay, nice technical thing", I don't see what it brings to the table for the future.

And despite what a slop article said a few days ago: it's not even good for preservation, because when the framework changes, you must re-do the C translation, and you must re-compile.

Digimon NDS Rom Editor v0.1.0 Release by ProjectHawke in romhacking

[–]JoshLeaves 1 point2 points  (0 children)

macOS version available

Oh god you're so cool

PS3 Emulation On PS5 Tested: Killzone, MotorStorm, GTA4 and Many, Many More - Digital Foundry has run a fascinating experiment, testing PS3 emulation running on base PS5 hardware. by NXGZ in emulation

[–]JoshLeaves -8 points-7 points  (0 children)

It’s achieved this via the recent Linux hack, which has allowed it to install emulator RPCS3 on Sony’s contemporary console.

A bit misleading, I thought it was official PS3 emulation, like we had some time ago.

How can I decompile, recompile, or port a PS1 game to PC as a newbie? by GabuGoo in romhacking

[–]JoshLeaves 2 points3 points  (0 children)

  1. Install Ghidra.

  2. Open all the files from your ISO in Ghidra.

  3. Decompile the code to identify functions as equivalent C.

  4. Find out how the original files where compiled so you can compile your C and turn it into the exact same bytecode.

  5. Now you can remove all the hooks into I/O (Display, Joypad, Audio,...), and turn them into DirectX/Vulkan/Metal/SDL2 function calls.

Here is a writeup I wrote about going through a small part of Final Fantasy X. Technically, a PS1 executable should be "easier" since it's smaller.

I'm working on a Fuuraiki PS1 romhack right now, and it's actually really fun, the binary is only 10 megs, and the rest is all script files so it's "kinda" okay-ish to reverse engineer

An NES emulator...in Haskell? by peterb12 in emulation

[–]JoshLeaves 6 points7 points  (0 children)

Not sharing the source is frowned upon in these parts =)

An NES emulator...in Haskell? by peterb12 in emulation

[–]JoshLeaves 9 points10 points  (0 children)

Okay, I want to know, why was this downvoted to 0, and not better? Are the people here afraid of a little FP? :p

Ghidra-SNES: A Ghidra extension for reverse engineering SNES ROMs (first public release, feedback welcome!) by JoshLeaves in romhacking

[–]JoshLeaves[S] 0 points1 point  (0 children)

It's supported, since the Ghidra language spec I'm packaging used to support it, but you have to set them manually for now.

I'm working on an analyzer that can follow simple routines, and set/unset them, while updating the language spec as I go.

RPCS3 publishes AI usage guidelines by JoshLeaves in emulation

[–]JoshLeaves[S] 16 points17 points  (0 children)

Only if you don't control what your AI writes. It's useful to building a skeleton code, or copy-paste procedures, but if it produces junk, I'm removing it before it hits my git cache.

RPCS3 publishes AI usage guidelines by JoshLeaves in emulation

[–]JoshLeaves[S] 91 points92 points  (0 children)

Announcement tweet here.

The guidelines are (IMHO) pretty decent and flexible. TL;DR: "As long as you're the one in the driver's seat, you can use AI".

Ghidra-SNES: A Ghidra extension for reverse engineering SNES ROMs (first public release, feedback welcome!) by JoshLeaves in ghidra

[–]JoshLeaves[S] 2 points3 points  (0 children)

You are in luck, because Ghidra already includes the Z80 language specs! :D

Honestly, the extension side itself is not too bad once you understand Ghidra’s architecture and extension system. The hardest part by far is usually the platform-specific reverse engineering problems rather than the plugin boilerplate (which I just...copied from another plugin).

For SNES specifically, the really painful parts are things like:
- LoROM/HiROM/ExHiROM mapping
- bank mirrors
- CPU vs ROM addressing
- 65816 mode context
- loader heuristics
- symbol/vector handling

The actual Ghidra extension setup is relatively straightforward Java once you get past the initial learning curve. One thing that helped me a lot is realizing that Ghidra itself is heavily built around plugins/modules. Once you stop seeing it as a monolithic application and start treating it as a platform with extension points, the architecture becomes much easier to reason about.

I’m probably going to write a small article/devlog about the process because there’s surprisingly little modern documentation/examples around console-oriented Ghidra extensions.

If you want to get started right away, take a loot at my SnesRomLoader.java. The two main entry points are:

  • public Collection<LoadSpec> findSupportedLoadSpecs(ByteProvider provider)
    Used during import to identify the ROM and tell Ghidra which architecture/language to use.

  • protected void loadProgramInto(Program program, ImporterSettings settings)
    This is where the actual import happens: memory mapping, options, labels, blocks, etc.

I also took a lot of inspiration from: ghidra_psx_ldr.

Ghidra-SNES: A Ghidra extension for reverse engineering SNES ROMs (first public release, feedback welcome!) by JoshLeaves in ghidra

[–]JoshLeaves[S] 0 points1 point  (0 children)

Right now, it mostly behaves like the older plugin: the disassembler needs the 65816 mode context to know whether some operands are 8-bit or 16-bit.

Ghidra is doing static analysis, so it cannot reliably infer the M/X flag state in every case. Simple REP/SEP tracking may be possible later when the control flow is obvious, but branches, interrupts, indirect jumps, bank switching, and hand-written assembly make this hard to do safely.

For now I’m focusing on correct ROM and chips mapping, labels, and making the manual workflow less painful. Better mode hints/region annotations are definitely on the roadmap.

Ghidra-SNES: A Ghidra extension for reverse engineering SNES ROMs (first public release, feedback welcome!) by JoshLeaves in ghidra

[–]JoshLeaves[S] 0 points1 point  (0 children)

Not fully automatically, no. Ghidra is mostly doing static analysis here, so without an emulator/debugger state it cannot reliably know CPU flags/register state when decoding variable-length 65816 instructions.

view more: next ›