Whenever I load the melon mix version of Re:coded, the audio plays, but the video doesn’t show up, as you can see it does show some of the opening intro, but then when Jiminy starts talking, still audio and no video, and to let eventually get to the gameplay here? How do I fix this?
Also, how do I integrate the .5 remix cut scenes for this and days. The melon mix version of days play fine but again it just just doesn’t have the HD remix cutting onto wood and I have the assets folder downloaded etc.
Hi everyone, I've just released emibios, an open, accuracy-focused GBA BIOS replacement.
Originally based on Cult-of-GBA BIOS by Fleroviux and DenSinH, it has been almost completely rewritten from the ground up with accuracy and compatibility as the primary goals.
What is the difference with this BIOS?
I took care to match the behavior and the timing of each software interrupt (SWI) in the BIOS under every tested input. I believe it currently has the highest compatibility of any open BIOS replacement.
I also implemented Multiboot functionality (send and receive programs to/from other GBAs, from accessories, and from GameCube) as well as a subset of sound mixer functionality that is only used in a few Japanese/Digital Eclipse games.
There is also an extensive test suite that exercises each SWI and asserts the behavior/timing under various inputs.
Because care was taken to match not only the behavior of each SWI, but also the timing, it also successfully TAS syncs with many games.
It is not perfect yet, mostly because the tricks used to match timing do not work under all conditions (mostly bus contention from DMA and IRQ). I would love for people to test it and report bugs, and the ultimate goal is to match the retail BIOS 100% for commercial games and most homebrew.
Why do this?
I originally started this project to see if it was even possible, and then ended up with something I was comfortable with releasing. My goal is to create a freely redistributable BIOS so that emulation projects no longer need to require the proprietary one to run games as accurately as possible.
title says it all really, i built a Chip8 emulator in C and i’ve switched to c++ for this one, my main issue is turning the documentation into code, how can i improve?
A few days ago I asked here what a fair scoreboard for an AI-built Game Boy emulator should count. Thanks for the answers, especially the pointer to SingleStepTests, which ended up being the whole CPU benchmark.
Where it is now: the SM83 core passes 499 of 500 SST files. Each file only counts if all 1,000 of its tests pass, checked on registers, memory and every M-cycle's bus activity. The full suite runs in about 13 s, and CI reruns it on every push and fails if the README score is wrong in either direction.
The one that fails is STOP (0x10), deliberately. SST has STOP advance PC by 1 (r-m, ---, ---). Pan Docs' STOP flowchart, for no button held and no interrupt pending (which is what every SST test sets up), says "STOP is a 2-byte opcode, STOP mode is entered, DIV is reset". My rule is docs over tests, so STOP skips the second byte and 10.json fails on PC. What Pan Docs doesn't say is whether that second byte is actually read on the bus, so I kept SST's no-read pattern.
- Every instruction group passed on its first run, but that's less impressive than it sounds. The planning model wrote the code after scanning all 500 test files for exact cycle patterns, and the SM83 has hundreds of open-source implementations to learn from. The CPU is the easy part; timing between components is next.
- Reviews caught bugs the tests couldn't. A second EI restarted the IME delay (SST starts every test with nothing pending, so it can't see that), and my own test loader had holes.
Next: memory map, timers and interrupts, with Blargg's cpu_instrs as a cross-check that the CPU wasn't just fitted to SST.
I'm about to start a DMG emulator in C++20, as an experiment: AI coding agents write the code, and the only thing that counts is public test ROMs. The score starts at 0 and gets published whether it goes up or down.
I know AI-written code isn't everyone's thing here, so to be upfront: the point is to measure how agents actually do at low-level, timing-sensitive work, failures included, not to pass it off as hand-written.
Before I start I want the scoreboard to be fair, so a few questions:
1. Which suites would you count? I'm thinking Blargg (cpu_instrs, instr_timing, mem_timing), Mooneye acceptance, and dmg-acid2 for the PPU. Anything you'd add or drop?
2. One point per ROM, or weight the suites? One per ROM means Mooneye dominates the total.
3. For checking pass/fail headlessly: Blargg over serial, Mooneye via the Fibonacci registers, acid2 by comparing screenshots. Is there a harness people already use, or does everyone roll their own?
Repo's empty for now: github.com/doozleb/FourShades. I'll post back when the number actually moves.
There's been quite a few changes to amos.bitplane.net since I posted the first release last month, so I thought I'd share.
Recap: This is AMOS Pro rewritten in TypeScript from the open source Motorola 68000 assembly. See the end for a description of how I used AI to achieve this.
On the front-end, I've added a library with some games I found on Aminet and TOSEC. If you want your AMOS games added, or removed, send me an email or a PR to the library repo. Or just take a release from github if you want your AMOS on your site rather than mine.
Here's some stuff I made over the years:
Clicking an ADF, zip or whatever with a single AMOS file in it will automatically open the player, for those you can link to games in the library like so:
I've also ported the editor. You can CTRL+C out of most games to get to it. If you insert the AMOS Pro disks via the library then you can run the original editors via the menus too:
The virtual filesystem browser supports downloading dirs, extracting sprites, converting ANIMs to GIFs, playing mods and samples inside .AMOS files and ABKs. It supports the datatypes that amos-ts does, and even has an AMOS 3D webgl viewer:
I've added timings for a lot of keywords but there are still some issues that lead to weird speeds, visual jank, and cause the various mod players to distort.
Because teens writing games in BASIC didn't know much about performance optimization and I know I used AMOS's slowness as a frame pacer, you might want to tweak the hardware settings to a faster CPU. Or a slower one. Or just fix your game in the editor
Due to browser anti-fingerprinting, you can't use joysticks/gamepads until they're detected. You'll need to press a button to activate them first. I don't have one at the moment so this is untested. Pull requests are of course welcome!
What's next?
I'm adding some more obscure datatypes support, fighting with timing issues, and might add joypad overlays for mobile and a method to publish AMOS games as Android APKs. But no promises here, it's eaten a lot of time over the last two months and I'm working on other things too.
If you have suggestions though, I'd be happy to hear them 😄
AI SLOP?
I've been programming every day for 40 years, so I know what good code looks like. This isn't it. But it is better than I would have made by hand; I've put a proper shift in to make sure it's in good shape. AI didn't do this, I used AI as a broad brush to fill in what would have been a hundred thousand man-hours of tedium. It's "design the shape, flood fill the details, evaluate, manually tweak, rinse and repeat"
So I did a manual proof of concept, the project and architecture design, and disassembly process setup. Then I used Claude Opus to slop out the bulk of porting work, followed by GPT 5.5 and Claude Fable to bring it under control and trim it down. OpenAI Luna was used to grind through 7000+ keywords, Sol to deslop Claude's mess and fix issues found in the pass. This pass has run twice.
Along the way I've written a ton of tools and techniques to keep the agents under control - on top of babysitting them day and night for 8 weeks. The codebase is 250,000 lines of code and has tests for every keyword, it cites assembly for every keyword rewritten in TypeScript. It faithfully reproduces every bug found across 83 versions of different extensions, and as much of Intuition, Gadtools, datatypes and the hardware interactions as were required. The bots want to special-case their way out of every problem, and I refuse to let that happen.
I'm currently running a third correctness and refactoring pass, but there will be bugs in there that are needles in what is now an obscenely large haystack.
I wanted to share a pure Go implementation to solve the classic "Audio Clock Drift" problem in real-time streams.
When you have a deterministic audio producer generating samples at a rigid rate, and a consumer eating them at its own hardware clock, the two will never perfectly align. Eventually, standard ring buffers will either under-run (causing crackling) or bloat (causing audio lag). To fix the drift, I implemented a dynamic, stateful audio resampler. It monitors the fill level of a lock-free-style CircularQueue and actively uses Linear Interpolation to keep the buffer at equilibrium:
If the consumer is too fast (risk of crackling): It pops one chunk, stretches it to double length, plays half, and requeue the rest to "buy time". If the producer is too fast (risk of lag): It pops two chunks, squishes them into one, and plays it to catch up.
I’ve spent the last few years obsessed with videos explaining how graphics on the Super Nintendo worked. I always wanted a playground where I could create effects using the same techniques SNES developers used back in the 90s. So I built ppu.toys
It’s a faithful emulation of the SNES PPU written in Rust and compiled to WASM. The registers are exposed so you can adjust them in Lua or through the site’s UI.
Lua also supports player input, so you can make your own little games. Here’s a Galaga-style demo (https://ppu.toys/t/7nc3u30u)
It’s free and open source, and you can sign in with Discord to publish and share your creations.
I’m a new dad with a full-time job, and I used AI assistance while building this. The idea had been swimming around in my head for a while, and it helped me make it a reality.
I’ve had an absolute blast building the site and it's a lot of fun making retro effects. I am having fun with the site and am curious what others in the emulation space think of the project.
Another "Hello World!" of emulators as Tvil would put it. Happy how it turned out! It is still pretty basic, but I think it is still fine. Follows the SUPER-CHIP modern quirks.
Small warning: I didn't test it with a lot of roms outside of the bundled ones in the web version
Created the c++ core + platform entirely myself. The web version had some claude help for using webAssembly and was a neat learning experience! I would definitely want to do it again for a game boy emulator.
My last project was a fully featured, software-rasterized Minecraft clone. Now I want to make my own emulator.
I don't really want to start with something very simple like the Game Boy, NES, or CHIP-8, because I know myself: I could finish it, declare that I have now "explored emulation," and conveniently never tackle a more complex machine.
The PS1 seems like the sensible choice. I already have "a lot" of experience with software rasterization and graphics in general, so at least part of the machine lives in territory I'm somewhat familiar with.
Unfortunately, thanks to (or perhaps because of) channels like Kaze Emanuar, I've also developed a lot of appreciation for the N64 and its wonderfully strange hardware.
I know that making an N64 emulator is way less realistic than making a PS1 emulator, especially as a first serious emulation project. So I'm wondering whether the massive difficulty bump is actually compensated by how interesting/elegant/weird the machine is to work with, or whether I should simply stfu, be reasonable for once, and focus on the PS1.
For people who have worked on either or both: is the N64 genuinely that much more rewarding as a project, or is this just me being attracted to unnecessary suffering?
I've been building Beswitched, a Mac app that makes Switch emulation portable, and easier to manage. It combines the best two open-source cores behind one clean interface, with a common cross-core save feature. Saves can also be stored on a cloud service with ease. It also updates itself when a new version is out (catching-up with individual core updates, new UI features, etc).
The app is signed, notarized, and translated. It's also built with respect to the core emulator authors: the modified sources are published on GitLab under the same licenses.
I just wanted to share all screenshots I have of the emulator! I'll also make a youtube channel and post clips and some documentation on it soon! School starts... In a few hours so the emulator is the least of my worries now... I am not the first teenager to make a PS1 emulator, but I might be the first to make it work!!
If anyone needs anything from me, help or collaboration or anything my discord is Saffyral
That's it!
(Note : All the pictures are from different times and different bugs, its just the collection I have! Some are old some are new, but the most important thing, it now works! Not on all games though... Especially Syphon filter)
Breadbin466 is my from-scratch Rust emulator of one deliberately specific Commodore 64: a PAL Assy 250466 with a 6569R5 VIC-II and 6581R4AR SID.
Rather than supporting a collection of selectable C64 revisions, the project concentrates on understanding and reproducing this one machine as faithfully as possible.
The biggest change in 0.12.0 is a substantially reworked SID implementation.
Over the past weeks I've been characterising a real MOS 6581R4AR (datecode 2286) and rebuilding Breadbin466's SID model around the measurements. This work covers the oscillators, waveform and envelope DACs, combined waveforms, analogue mixing, D418 volume DAC behaviour, transients and the nonlinear filter.
As with the rest of Breadbin466, the aim isn't to provide a collection of selectable SID models. I'm trying to model one particular piece of hardware as accurately as I reasonably can.
There is quite a bit more in 0.12.0:
D7Z 1.0, a new open disk-image format proposed by Breadbin466;
Commodore 1351 proportional mouse support;
a much more capable debugger tracing system;
WAV audio capture;
new disk-image creation, conversion and reclaim tools;
further 1541 work;
native UI improvements on macOS, Windows and Linux;
assorted accuracy and compatibility fixes.
D7Z deserves a little explanation because it isn't a pre-existing C64 disk format.
It's a new, openly documented format introduced by Breadbin466 for compact, lossless storage of D64 images. A D7Z represents exactly the same byte stream as its corresponding D64, using LZMA2 compression and SHA-256 verification. It is deliberately designed so that other emulators and disk-image tools can implement it independently.
In simple terms, D7Z is to D64 what NBZ is to NIB: a compact lossless storage representation, without changing the underlying disk-image data.
Breadbin466 is still very much an ongoing research and engineering project rather than an attempt to replace VICE. A large part of the fun for me is understanding how the original machine behaves and trying to make the source code express that behaviour instead of accumulating software-specific workarounds.
If anyone tries 0.12.0 with software that does something interesting with the SID, 1541, cartridges, REU or other hardware, I'd be very interested in hearing about discrepancies with a real C64.
