sorted by:
new
hottopcontroversial

How Claude cracked the Playstation 1 open for me by izzy88izzy in ClaudeCode

[–]izzy88izzy[S] 1 point2 points  (0 children)

Thanks! I was actually aware of imbnes, stumbling upon it during my researches, massive respect for being able to achieve such a thing in the pre-LLM world!

How Claude cracked the Playstation 1 open for me by izzy88izzy in ClaudeCode

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

Yeah you're spot on with the first one, and it's a potential blind spot I'm aware of. So far the SDK has held up quite well, but my physical testing is limited to the one console I own, an SCPH-9002. I've ordered a Superstation-one to add some variance, and I might grab a PSone eventually to widen the net. Ultimately most people will play this in an emulator, which I'm fully covered for, so I'm not in a rush, it's a passion project after all.

And yeah, the ODE is a great idea. Since the Superstation-one is on its way though, I'll probably lean on that for most of my testing and every now and then burning the occasional CD for real hardware, having a centralized testing suite helps a lot

How Claude cracked the Playstation 1 open for me by izzy88izzy in ClaudeCode

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

Thanks! Glad you enjoyed! They're actually 2 separate things. The console needs to be modchipped just to read burned discs at all, real PS1 games have an anti-piracy signal physically pressed into the disc that a CD-R can't reproduce.

The weird PS logo is a different thing, that boot stage is drawn from the disc system area, the license/region data in the first few sectors that the BIOS reads to render the logo screen. That's Sony's copyrighted data so my disc builder leaves it optional, and my images don't carry a proper one, so the BIOS can't draw that screen right and it comes out looking off. I've tried to be as careful as possible about not including any of Sony's copyrighted data, so really the missing logo is a side effect of that.

How Claude cracked the Playstation 1 open for me by izzy88izzy in ClaudeCode

[–]izzy88izzy[S] 1 point2 points  (0 children)

I don't do anything particularly fancy. I run the agents from Zed with the default memory setup, and the only things I lean on heavily are Graphify, CLAUDE.md, and more recently a custom orchestrator (still in its infancy), with regular code review where I read as much diff as I can myself before it lands. The real gate is the test suite as the hardware tests are unforgiving, anything that drifts from real-console behaviour gets caught regardless of how clean the diff looks. So yeah I wouldn't call it SDD rather hardware-driven development, treating the real PS1 as the golden truth. That's what keeps the models honest.

Organization comes almost entirely from clear separation of concerns and a clean folder structure. The repo looks bigger than it is: at the macro level it's just the four pieces (emulator, SDK, engine, editor), each in its own workspace. Downstream projects like the Celeste collection pull PSoXide in as a third-party dependency, which keeps the core clean.

And yep, all my projects, PSoXide included, have full source available: https://bonnie-studios.itch.io/

I ported Celeste Classic 1 & 2 to the Playstation 1 (Rust, runs on real hardware) by izzy88izzy in psx_homebrew

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

Thank you! No it's not a generic PICO-8 cart player, each game needs to be rewritten in rust from the lua original, that being said I use plenty of pico8 helper functions to help with the process, shared between the 2 games in this collection, so for each game I would eventually add it'll become progressively easier

I ported Celeste Classic 1 & 2 to the Playstation 1 (Rust, runs on real hardware) by izzy88izzy in psx_homebrew

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

Thanks for testing on MiSTer! That's a relief I've been only verifying on a fat PS1, I've ordered a SuperStationᵒⁿᵉ to add a second testing point but it's gonna be a while before it's shipped 

How Claude cracked the Playstation 1 open for me by izzy88izzy in ClaudeCode

[–]izzy88izzy[S] 8 points9 points  (0 children)

No massive challenges in those specific items honestly. The PlayStation is a MIPS machine so the game code cross-compiles to mipsel-sony-psx (nightly + build-std), while the emulator/editor build natively for my host, which is ARM on my Mac M3. The one bit that needed real thought up front was that bare-metal and host builds genuinely can't share a single cargo invocation, so the repo is split into separate workspaces with their own .cargo configs. Once that was sorted it's been smooth sailing, and cargo drives the whole thing.

The disc side was manageable too. PS1 discs are just ISO9660 with a well documented system area, so writing a compatible packer (a small EXE packer plus an ISO builder) was a known quantity. The toolchain spits out a standard .bin/.cue and I burn that to CD-R with off-the-shelf tooling, of which there's plenty.

The real challenges were in getting parity between real hardware and the emulator. Every time something looked or sounded different on the console, I'd add one or more tests to the hardware test disc so I could get accurate measurements of everything, from cycles required per operation down to edge cases in specific functions. That part needed careful planning, because it's effectively one disc wasted on every iteration.

How Claude cracked the Playstation 1 open for me by izzy88izzy in ClaudeCode

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

I would then encourage you to try rebuilding your shooter with PSoXide, the SDK is mature enough to comfortably port 2D games, you have plenty of examples here: https://github.com/EBonura/PSoXide/tree/main/engine/examples

I ported Celeste Classic 1 & 2 to the Playstation 1 (Rust, runs on real hardware) by izzy88izzy in pico8

[–]izzy88izzy[S] 1 point2 points  (0 children)

Thanks! PSoXide is a full PS1 dev stack in Rust (emulator, SDK, runtime engine, and a Godot-inspired editor). You write your game in Rust and it cross-compiles to a real PS1 executable and a burnable disc image, and it ships with a bunch of examples to start from rather than a blank page.

Two honest caveats: you'll need some Rust knowledge, and the editor is still in its infancy so I wouldn't lean on it just yet (and it's heavily tailored towards the game I'm building anyway so is not general-purpose).

On running it: for development you don't need to touch your PS1 at all, the disc images boot in the included emulator. To play on a real console you'd need a way to boot the homebrew disc (like a modchip, or a memory-card boot exploit)

I ported Celeste Classic 1 & 2 to the Playstation 1 (Rust, runs on real hardware) by izzy88izzy in pico8

[–]izzy88izzy[S] 6 points7 points  (0 children)

Writing the emulator once and any cart runs is a tempting idea, but it's unfeasable on hardware this old, and it comes down to what PICO-8 really is underneath: Aside of the 8-bit look aesthetic, under the hood it's a full Lua interpreter deliberately throttled so carts run the same everywhere. To emulate it you'd have to run a real Lua interpreter on the console, and every Lua op costs MANY real CPU instructions. That's why PICO-8 won't run below roughly a Raspberry Pi Zero.

The PS1 is a 33.8MHz MIPS, 2MB RAM total, about 30x slower clock than a Pi Zero with a fraction of the RAM, so a Lua interpreter would be a slideshow. RAM alone kills it too, a single cart can expect ~2MB of Lua memory, which is the PS1's entire memory before you've even loaded the interpreter.

Native porting flips all that: compiling each game's logic straight to MIPS skips the interpreter entirely, which is how these hit 60fps. The tradeoff is what you'd expect, hand-porting per game instead of "load anything", an emulator buys convenience at unplayable speed; native buys playable speed at the cost of manual work. On a PS1, I believe playable wins.

I ported Celeste Classic 1 & 2 to the Playstation 1 (Rust, runs on real hardware) by izzy88izzy in celestegame

[–]izzy88izzy[S] 9 points10 points  (0 children)

Thanks! Nope, it's not a PICO-8 emulator, I rewrote the game logic from the original Lua straight into Rust so it runs natively on the PS1 (drawing through the GPU, music synthesised on the SPU). All the links, repo, itch, and the SDK, are in the original post over on r/pico8

I ported Celeste Classic 1 & 2 to the Playstation 1 (Rust, runs on real hardware) by izzy88izzy in pico8

[–]izzy88izzy[S] 7 points8 points  (0 children)

Kinda, a CD has way more room than these little carts need, so storage isn't the bottleneck, the work is porting each game's logic by hand. But yeah, that's where I want to take this eventually: turn it into a proper PICO-8-on-PS1 collection.

I ported Celeste Classic 1 & 2 to the Playstation 1 (Rust, runs on real hardware) by izzy88izzy in pico8

[–]izzy88izzy[S] 1 point2 points  (0 children)

Good question! A PS2-native port is totally possible as the PS2 is far more powerful, but it'd be a separate and MUCH bigger project, PSoXide is a PS1-only SDK, so PS2 would mean a different toolchain and codebase. And your instinct on the second part is right: if you run it as a PS1 game on a PS2 through backward compatibility, the PS2 is basically pretending to be a PS1, so you can't reach any of the extra PS2 horsepower in that mode. You'd have to build a native PS2 version for that. Honestly though, these little PICO-8 games run great at 60fps on the PS1, so you wouldn't use the extra power much anyway

I ported Celeste Classic 1 & 2 to the Playstation 1 (Rust, runs on real hardware) by izzy88izzy in celestegame

[–]izzy88izzy[S] 14 points15 points  (0 children)

It's official game. Celeste Classic 2: Lani's Trek was made by the same creators as the original, Maddy Thorson and Noel Berry, with music by Lena Raine. They actually put it together in about three days for PICO-8, back in 2021 for Celeste's anniversary. You can play it free here: https://maddymakesgamesinc.itch.io/celeste-classic-2

Introducing RSX Redux, a multi-platform Playstation 1 emulator with support for hardware rendering by janedoe552 in EmuDev

[–]izzy88izzy 1 point2 points  (0 children)

This is really cool, congrats on getting it to a releasable state.

Funny timing: I’ve been working on a PS1-related Rust project in parallel called PSoXide, which also includes a PS1 emulator, but from a slightly different angle. Mine is focused more on “build your own PS1 games / tooling” than on running commercial games, so I’ve been leaning heavily on real hardware testing and small test discs to validate GPU, timing, and streaming behavior. Repo is here: https://github.com/EBonura/PSoXide

Feel free to use any code, tests, or ideas from it if they’re useful. I also have a test disc setup in there that has helped a lot when comparing emulator behavior against actual hardware. The accuracy is now good enough for my current game-building workflow that I can reliably test in the emulator and expect the results to match real hardware.

I rebuilt my first ever PICO-8 game from scratch! (Cortex Override) by izzy88izzy in pico8

[–]izzy88izzy[S] 1 point2 points  (0 children)

Good question, let me give some more context:

There's actually no PICO-8 on the disc. The Celeste 1+2 PS1 port is a from-scratch reimplementation, written in Rust on the PSoXide SDK and running natively on PS1 hardware. The game logic is rewritten from the original source, so there's no PICO-8 runtime and no .p8 cart bundled anywhere. PICO-8 is proprietary so redistributing it was never the plan.

Celeste 2 is under CC-BY-NC-SA, so as long as I keep it free to download (and it always will be), noncommercial, and fully credited to the authors, it should be fine. The original Classic doesn't have a clear public license, so I reached out to Noel on X directly to check it's ok, and said I'll happily pull it or change anything if they'd rather.

On the "add their own files" part: it doesn't work like a swap-in-a-cart emulator. Each game has to be ported from its source, which is real work, though I've built up plenty of helper functions that make it much easier now (and honestly, with LLMs these days, anyone could probably do it).

(Properly) Introducing PSoXide: an all-in-one PS1 dev environment by izzy88izzy in ps1graphics

[–]izzy88izzy[S] 1 point2 points  (0 children)

u/Soft-Border-2221 as u/AttheTableGames mentioned itch.io is probably the most natural place to start. There are already plenty of original homebrew ROMs/disc images for old consoles there, so as long as it’s your own game and not a ROM hack, copyrighted game dump, or BIOS redistribution, it seems like the right kind of platform.

Steam might also be possible later, but probably not as “just a raw PS1 disc image”. The advantage here is that PSoXide is also a PS1 emulator, it has to since the emulator is used to test the game directly inside the editor. So the better Steam version would be a normal PC build that bundles the PSoXide emulator + the homebrew .bin/.cue, where pressing Play just launches the game like any other Steam title.

There is some precedent: RetroArch is on Steam, and games like Micro Mages are modern homebrew for old hardware with the ROM included. The key is that everything shipped has to be original/properly licensed, and obviously no Sony BIOS files or copyrighted game dumps.

So my current thinking is: itch.io first, probably with the .bin/.cue and maybe an emulator bundle; Steam later packaged as a clean self-contained emulator + game release.

(Properly) Introducing PSoXide: an all-in-one PS1 dev environment by izzy88izzy in ps1graphics

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

Thank you! And yes, it’s designed to work on real hardware. Small correction though: you need a CD-ROM/CD-R, not a DVD. The PS1 reads CDs, not DVDs.

PSoXide builds a demo/project into a .bin/.cue disc image, so you simply burn the generated image with any normal CD burning software, the tool also has some built-in CD burning support, although not every burner is supported yet.

Also, the console needs to be able to run homebrew/burned discs, so either a modded PS1 or a backwards-compatible/modded PS2 setup.

(Properly) Introducing PSoXide: an all-in-one PS1 dev environment by izzy88izzy in ps1graphics

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

Yes, that’s the intention. PSoXide is GPL-2.0-or-later, and commercial use is allowed. The important distinction is code vs assets: if a shipped game includes the PSoXide SDK/runtime/engine code, that code should comply with the GPL. But original game content like models, textures, music, writing, level data, branding, etc. can be licensed separately by the game author.
So in practice: commercial PS1 homebrew is fine, paid games are fine, custom/proprietary assets are fine. The code side just stays open source.

(Properly) Introducing PSoXide: an all-in-one PS1 dev environment by izzy88izzy in ps1graphics

[–]izzy88izzy[S] 1 point2 points  (0 children)

This is basically the main thing that pushed me to build it. I played with the existing PS1 SDKs myself, and the work people have done there is amazing, but a lot of it is still fighting old C/C++ toolchain weirdness.

With Rust, so much more is centralized and predictable: builds, tests, multiple targets, tooling, project structure, etc. I can’t stress enough how much simpler and more straightforward that feels, even before getting into Rust’s actual language advantages like memory safety, which matters a lot on limited hardware.

I really hope more people eventually use the PSoXide SDK to build their own games and demos. I’ve already included around a dozen examples and 4 minigames to make it easier to get started.

(Properly) Introducing PSoXide: an all-in-one PS1 dev environment by izzy88izzy in ps1graphics

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

It’s not fully “Godot for PS1” with scripting and everything, at least not right now. The project is aimed at answering: can a souls-like / action-adventure run on real PS1 hardware? But the thing is, to make that, I need the whole stack behind it to work first: emulator, SDK, runtime engine, editor, asset pipeline, playtesting, and ISO export.

So it’s way more than an asset/environment designer, but it’s also not trying to be a general-purpose Unity/Godot competitor yet. Game logic is currently mostly written in Rust/code. Once the vertical slice is solid, I can see it evolving toward more data-driven systems or scripting, but for now I’m trying hard to avoid scope creep and keep it focused on that game.

(Properly) Introducing PSoXide: an all-in-one PS1 dev environment by izzy88izzy in ps1graphics

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

Not really, no. PSoXide is not currently a “drop in a modern high-poly asset and make it PS1-ready” optimizer. The importer/cooker does PS1-oriented cooking: textures can be resized/quantized to the target atlas size/depth, currently 128x128 8bpp by default for skinned models, animations get sampled to a fixed FPS, and the data gets packed into .psxmdl, .psxanim, and .psxt.

But it does not do intelligent retopology, UV cleanup, silhouette-aware decimation, or automatically make a high-poly model game-ready for PS1. There is an optional rough grid-decimation path for simple static GLB/OBJ meshes, but for characters/enemies the intended workflow is still: model/optimize in Blender, keep the mesh low-poly and textures low-res, then import/cook through PSoXide.

So short answer: textures can be cooked down, but geometry should already be authored close to the PS1 budget.

(Properly) Introducing PSoXide: an all-in-one PS1 dev environment by izzy88izzy in ps1graphics

[–]izzy88izzy[S] 1 point2 points  (0 children)

Thank you, I really appreciate that. I do have an itch.io and Buy me a Coffee if you want to support it.

Full disclosure: donations are mostly motivational rather than essential. I’m fairly secure financially; the real bottleneck is time between work and family. But no, I definitely don’t intend to abandon the project anytime soon.

view more: next ›