Announcing Johnny Castaway PS1

Introduction

This has been a project well over a year in the making. I’m proud to announce version 1.0 of Johnny Castaway PS1, a port of Johnny Castaway to the Playstation 1 console, with enhanced features and options like freeplay/sandbox mode. It’s the version of Johnny I always wished existed, and my most ambitious port to date.

TLDR;

If you’re less interested in the history and development of this project (which is an interesting case study in modern development, debugging, and optimization techniques), you can find the download and full website here: hunterdavis.com/johnny-castaway-ps1

History

I’ve ported the jc_reborn codebase to a few platforms over the years. I find porting enjoyable work, creative at times and necessitating compromise and cleverness. It was five years ago now when I released Johnny for the Dreamcast. It was a bit of a slapdash port, back-porting jc_reborn to SDL1 for the DC. A year or two after it released, I receive an email from a game store owner who enjoyed it, but found that it crashed after about a half an hour (likely due to memory pressure from a large scene on the 8mb dreamcast)

I let them know I’d take a look. Truth is, I hadn’t touched a DC toolchain in the years since, and re-creating it was a mountain to climb for someone with just an hour or two per week sometimes of free project time. Though I didn’t find the time, I thought about that email a lot.

Fast forward to 2025. It was (ironic, I know), AI coding agents that got me back into programming in my spare time. The ability to parallelize my work with another developer (in this case an agentic one) brought some fun back into it for me. I guess after all these years as an executive I’m a social butterfly. At any rate, I started to think about that email again. I decided the best thing to do was write a version of jc_reborn with an extremely low memory footprint, then I could simply re-port to DC with SDL1 calls and solve the issue (if memory truly was the issue.)

That effort went very well and through research, hard work and an agentic partner we proved we could get the memory well below 8mb. And that’s when that thing happens. You know, that thing engineers do where they skip an easy problem for a harder one? Yeah, I started to think about my large collection of gaming handhelds throughout the years. How many of them could run a dreamcast game? Only the newer ones, and not all of them. How many though, could run a Playstation 1 game? Almost all of them, actually: from my first psp way back in 2004 to my steam deck and every phone for the past 15+ years.

Then it clicked for me, hard. The PS1 could do 640x480 interlaced. That’s Johnny’s native resolution. It had 600mb+ of space for assets. It’s been emulated, FPGA’d, and directly ran via chipset compatibility in the first four generations of playstation. Heck, maybe it could even run on the dreamcast via bleemcast?

So it began, in 2025. First locally, as part of the jc_reborn project. Then it grew in scope. I wanted freeplay mode, background music, scene skipping, chapter selection, seed pinning, closed captions, memory card support. Everything anyone could possibly want in a version of Johnny for the playstation. Something that actually could have come out at the time (maaaybe).

The Journey Here

As with any major project, this one came in fits and starts. A straight port failed, with constant memory issues and minor bugs. I spent months refining, before pivoting a few times into a methodology that actually worked. A combination of host-pre-processing (essentially trading space for complexity) and relentless optimization.

I found it though. That magical flow state that all software developers crave. After months and months of pain, custom tooling, hacking, AI after AI, I settled on a flow that brought me great joy and huge gains.

• Window 1: Dunking Bird, double dunking on OpenAI Codex and Anthropic Claude
• Window 2: Claude, in an infinite editorial loop documenting progress on website/blog.
• Window 3: Codex, in an infinite refinement loop regressing scenes against micro-optimizations in code and technique using headless docker containers.
• Window 4: Fresh editor (used to use vim), for direct coding and code browsing
• Window 5: Bottom monitor, keeping an eye on CPU, Memory, and Temperature
• Window 6: Duckstation Emulator, running a visual regression for me

All of this running on an old surface laptop (quite beat up, bought at thrift store), running KDE Neon, remote desktop’d in from my laptops/tablets/etc. A dream coding desktop always at my fingertips from anywhere.

I mean, think about it. I’m coding up new features or fixing small bugs while two AI agents spend every minute of every day refining speed and documentation. This is all running on a machine costing less than 100$ and the pro tier of codex and claude. Bonus: while I’m at home I connect a bluetooth controller to it and test freeplay mode and menus directly. While I’m far remote those get tested via headless session instrumentation.

It feels incredibly futuristic, and the proof is in the result. In this single year I’ve been able to complete my most ambitious port yet, all while maintaining a full time job and significant family responsibilities.

The Realness

There’s some AI slop/crap in the website. It’s true. A LOT. I would never allow such a thing on my personal blog (these are all my words, my feelings, I’m trying to convey something real). For a project site though, it’s really about presenting information and marketing. Very little emotion, much less need for the human touch. It’s also 100x better than the site I would have written for it. You know my project sites: blog post, header image, links to download, credits. That’s about it. This has feature articles, guides, how-tos, real documentation, technical articles that are actually kind of interesting and sometimes put an insightful spin on the technical challenges I faced. These are not things I have the time to do nor the inclination most days. Yet here we are with a really fun and informative project site. I’ll review what I can, write when I can, but when I can’t, I think this is a pretty interesting workflow for technical documentation. An agent writes it as you struggle, not when you’re finished. It’s the struggle I find interesting, the challenge, the setbacks. That’s the good part.

The Desktop

Here’s said workflow in action:

Full Version

Getting It Over The Finish Line In An Emulator

This past couple of months, I’ve actually engaged in an even more aggressive triple-dunking setup. You see, performance and correctness are often at odds with each other. Throw in memory pressure, and you have a real iron triangle situation. Any change to one affects the other two significantly. My strategy to get this over the finish line was essentially a phased re-prioritization of efforts. In the beginning, my focus was purely on getting things running at all. Towards the end of the project, I rotated that iron triangle in phases. Correctness, then speed, then correctness again. Once I had all scenes working perfectly, I rotated that triangle and focused on speed. Once I had the speed optimized for all scenes, I rotated back focused on correctness again. Bouncing back and forth, regressing stray pixels and timing issues. All the while, my third dunker worked on longevity testing. The memory pressure side of the triangle. Even a single byte leaked per scene will eventually build up to disaster. It must run for days, if not weeks on end. No 26-minute rule this time, no shortcuts.

Applicability to Larger Projects and Emulation

It strikes me that I’ve over-engineered this one. Big surprise right, an engineer spending a year working on a passion project with no commercial value or intent reflects back on how it was over-engieneered. I’ve sang that song too many times. Here’s the thing though that I think is both novel and valuable: the metaphor. The analogue. The next problem this can help solve. My mind goes to the field of emulation. You see, in one sense I hyper-optimized code on a scene-by-scene basis for one game. Well, that’s less a sense and more a literal interpretation. Fuzz your eyes a little though. 63 scenes, each one with it’s own compression algorithms, loading schemes, techniques for memory pressure, saturizing the CPU, ensuring smoothness and correctness. Keep fuzzing, but now imagine they are 63 individual games, all running within a shared emulator. Keep looking. Now start to expand the picture. Github as the central repository for coordination. Expand a bit more, now start to include more than a single developer and their AI agents. What if it was hundreds, thousands of developers? You see, the scaffolding I built for Johnny PS1 works equally as well for N64 games, or Dreamcast, or CDO. Except in those instances, there are thousands (millions) of folks willing to contribute. And this scaffolding, it’s self-starting. You need zero knowledge of development, docker, cross-compilers. It can all be AI driven. What if thousands of developers were dunking on improvements to emulation? The possibility are endless, but the technique is straightforward. Ensure you have a harness that works not just in the visual domain, but on a systems and pressure level. There’s something incredible here, and I’m circling it, underlining it, and bolding it with yellow.

Further Parallelization And The Pursuit of Perfection

It was Memorial Day weekend 2026 when I finally got every scene into the 99%+ green speed category. I had been struggling to get a few animation-heavy scenes over the finish line, and realized I was essentially running the same tests over and over again with small tweaks. I had parallelized across agents, but I hadn’t saturated my local processing ability. Turns out a surface laptop 4 has no trouble running 20 simultaneous headless PS1 emulators for timing runs. So, naturally I wrote a script to generate worktrees in parallel and test small code changes tweaked via a predicate json config. You can see that script and the results in the worktree.

Will this port ever be at the point where I call it 100% perfect? I don’t honestly know. As I’m drafting this post we’re less than 0.3% slow for 20% of the scenes. A third of a percent. Acceptable? Probably. Perfect? No, and I’ll continue to refine and update as I get the time. Maybe someone else will too. That’s my hope with this mountain of documentation and FAQs and regression suites etc etc. It should be straightforward for anyone with interest to set up a development environment and try something out, and know exactly how that’s affected the runtime. Pretty cool, I think. In the meantime we’ll see how close to 100% I get this port for my planned V1 release mid-June. (Update from July, read on!)

Real Hardware, Real Problems

The first week of July 2026 I was ready to do hardware testing. I picked up a chunky OG PS1 from the local gamestop for 60$ (somehow the cheapest option at the time.) I was determined to soak test Johnny on real hardware… and I did! The first time a scene loaded it was glorious. However, there were real problems to fix that didn’t manifest on an emulator.

1. The SPU (audio) init code wasn’t working correctly (timing) on the real hardware.
2. Text rendering was missing (gpu pipeline and textures).
3. Disk read failures regularly froze the game in a stall loop, a very common occurance with a burned CD and 30 year old hardware.
4. The scene explorer preview image was garbled and would crash the game after a few previews.
5. Some high-memory scenes would have paintover due to memory exhaustion (failure to pre-allocate background swap buffers.)
6. Read failures during scene loads would cascade as issues in other systems.
7. CD spin-up timing different on real hardware, leading to mis-timings.

The truth is, I had designed this with the constraints of the hardware specifications of the PS1 in mind, but not the real world constraints of slowly degrading 30-year old hardware. I’ve since hardened the read and retry code significantly. Hard fails will eventually cause a scene swap or reload, but shouldn’t crash the system. I’ve got decent performance out of a V1 PS1 and a burned CD launched from tonyhax/unirom boot, that’s the floor. Sometime this year I’ll try installing an ODE and see if that alleviates all of the read concerns and brings the performance in-line with emulators and FPGAs. Until then, we do what we can with the world we live in.

Not to say it wasn’t fun. I did enjoy finding measures to alleviate these real world issues. Those can be the most fun beacuse they tend to be the most interesting problems. I started this holiday weekend with a stack of 50 blank cds (AZO ink) and they’re almost gone: sacrificed to the feiry pit of my burner. It’s been years since I could say that and without reservation it brought me no small amount of joy. This release doesn’t mark the end of Johnny on the PS1, but the true beginning. There’s a world of fixes and improvements that could be made, and I’ve no doubt in a few years LLMs (or better yet, a human with the time and drive) will be able to re-write the janky sprawling per-scene hackfest that is my codebase into something elegant and more performant. Until that time I’ll keep chipping away at bugs and small improvements. This project and indeed this past year in total have given me back my love of building things. My next game engine will for sure be on the PS1.

For now, please enjoy Johnny Castaway on the PS1. I hope his story touches your heart as it did mine, I hope this gives you a reason to dust off your PS1 again, and I hope this project brings you a moment of quiet joy in this loud crazy world.

Try It Out

GitHub Repository: You can find the complete source code, installation instructions, .bin/.cue files and documentation on GitHub: huntergdavis/johnny-castaway-ps1

Project Website: You can find all the above, and so much more on the official project website. hunterdavis.com/johnny-castaway-ps1

Have Some Fun

This is designed to run forever (or as long as your machine can take it), perfect for emulators, virtual CD drives, FPGAs etc. My tests run for a week+ on emulators; no promises your PS1 won’t explode after being on that long.

Why Johnny, Really?

Johnny Castaway was the software I couldn’t afford on the computer I couldn’t afford in 1992. By the time I had one that could run screensavers, they were far out of vogue. Still, when I was able to I ran Johnny on whatever I could. The story really resonated with me. Here’s someone trapped (perhaps a parallel to how you feel trapped in poverty), finding a way to have adventures and live life with very limited resources. Making friends, finding love, and realizing what’s really important in life. By the time he’s rescued and back to his programming job, he’s dreaming of the place he found happiness, back on that island. The struggle wasn’t the only thing he found on the island, he found himself and the way he wanted to live. That’s always stuck with me, and the ending scene where he’s happily back on the island, that’s powerful. Jeff Tunnell created this little silly screensaver that’s also somehow profound. I’m thankful for his efforts, and every port is an homage to the original, and his vision.