[UPDATED! 2026-02-25] C64emu new release with revisited SIDemu and Wine compatibility
.: Download link :.
C64emu releases
.: Hotfix :. [UPDATE! 2026-02-25]
- The new mipmap generation method not just faster, but slightly more detailed, and because of this in some cases a stronger moiré effect may visible on the screen. If you prefer the old method, just set CRT_LEGACY_MIPMAP_GENERATION to 1 in the C64emu.cfg file located in the C64emuData folder.
.: Bugfixes :.
- Since the last rewrite of the SIDemu subsampler, the pulse output was not pulled up by the TEST bit, so the digi did not work in Chimera and The Last V8 (fixed - Thanks to eLK for pointing out that there is a problem with The Last V8, and to Abynx, for noticing that the same thing happens with Chimera)
- Wine only supports GLSL version 1.2 on macOS, so the renderer did not work properly with it, but the shaders were backported to version 1.2 (the shader version is detected at startup and the corresponding shader is loaded), so from now on C64emu runs properly under Wine as well
.: Improvements :.
- SIDemu in 6581 mode sounds even better due to the completely re-written 6581 filter and the revisited DAC lookup tables
.: New features :.
- Experimental video signal to audio signal leakage simulation (PREFERENCES > AUDIO SETTINGS > VIDEO LEAK)
- SIDemu custom config data is now saved in the config file, so the 3 custom templates in addition to the 5 default templates can now be edited with the SIDemu config program (you may try to recreate the sound of your own beloved SID by changing the cutoff offset)
.: Minor changes :.
- OSD messages can be disabled (PREFERENCES > VIDEO SETTINGS > OSD MESSAGES)
- Tape sounds can be disabled (PREFERENCES > AUDIO SETTINGS > TAPE SOUNDS)
.: Known bugs/limitations :.
- Tape/disk changes and reset are not yet handled by the gameplay recorder
- Disk states currently not being saved to state files so if you save state (or close the emulator) while loading from disk, it will be corrupted (when loading from tape, it is safe to save)
- Not every sprite mode-split situation handled correctly
- Sprite collision flags not half-clock accurate (spritevssprite.prg)
- In 100Hz video mode, forced VSYNC could be 50Hz if a VIC-II frame were displayed only every two frames, but instead, emulation is currently running at double speed
- There is no full 1541 emulation yet
.: To-do list :.
- Complete the implementation of command line options for the VICE testbench
- Finetune 6581 biases to improve the filter distortion accuracy, especially when more than one oscillator routed to the filter
- Joystick customizations
- Add frameskip option to the image sequence recording
- T64 file format support
- Write debugger steps to .csv file optionally
- VIC-II PHI1 description for the debugger
- Corrent handling of 100Hz video modes in forced VSYNC mode
- Save disk/tape changes into gameplay recordings
- SID template customization from the menu
- Rewrite the sprite renderer to correctly handle sprite mode-split situations
- Implement pixel clock-based sprite collision (spritevssprite.prg)
- 1541 full emulation
- Native linux/macOS versions
As always, feel free to leave a comment.
Cheers,
DaemonPig
Hi guys,
ReplyDeleteSorry for disappearing for months, a lot has happened, which meant I had less time to work on the emulator, and I was also trying to make progress on my SIDemu Board SID replacement so that I could make it available as soon as possible. I had planned to include more things in the next release than what actually ended up in it, but I don't want to delay it any longer, so I uploaded it in its current state so that you can finally use what is already finished.
Thank you all for your many tips and suggestions. I have added many of them to my to-do list, and some minor requests have already been implemented. Even though I haven't made many changes, I hope you will be happy with these small improvements.
DaemonPig
I started a separate blog for the SIDemu Board, check it out too: sidemuboard.blogspot.com
ReplyDeleteWohoo! New version! ..I'm on it! 😊
ReplyDeleteSlow motion (50% speed) looks good. Now to get in some serious testing.. and listen for the audio-leak emulation. I remember what that was like! 😄
Okay, so I've done my first bit of testing. Trap Door played well on my work laptop, though my recording of it got messed up by a pop-up message and some choppy sound when the laptop went into energy-saver mode, so I'll re-record that.
DeleteI did a full cassette-load recording of "Sentinel" on my PC with the 3440x1440 ultra-wide display. That game has some neat border effects that reflect well in the simulated monitor bezel. So that one's here:
https://www.youtube.com/watch?v=nTEiuUUV5tY
I'm enjoying the video-leak feature.. I'll work out a cool game to record at 50% speed now that that's working well, and I've rendered some frames to make a gif. I'll report back on all that. No game-stopping bugs so far. 👍
I haven't recorded gameplay for a while. So this was Uridium, where I took a snippet of the title screen and demo gameplay and rendered it as a GIF. (Mastodon will have recompressed it as mp4 video, but you get the idea.) 😊
Deletehttps://oldbytes.space/@level106/116100652654703011
I wonder if you're making life a little hard for yourself the way you're doing recording? Like, instead of creating a save-state at the beginning of recording, recording all the keyboard/joystick inputs (but pausing input when entering the C64emu menus), then trying to replay the emulator from that save-state when rendering out the input... Would it not be easier to just record live? ie: when recording is on: output a simple bmp/gif/png frame every 50.1245 seconds (PAL) and record the sound to a buffer. Then, when recording is stopped, stop writing frames to disk, and write out the sound buffer to a wav file.
If the user wants high quality CRT-simulated frames, the "Render Last Recording" option only needs to walk through the directory with those simple PNG frames and convert them to high quality JPG/PNG frames.
Then the user doesn't lose their whole recording if they forget to render before quitting (I've done that) 😊 and recording is, for the most part, a simple start, then stop process, rather than start, stop, and then render (and wait while it's rendering.) Or the rendering step can even be done the next day, if you have to shut-down the PC to sleep. 🤣
Anyway, not trying to tell you how to design your product. Just thinking out loud on how I would do it. Feel free to ignore. haha. 😄
Thank you for the new video!
DeleteI'm always amazed that you don't just give us an overview of the game you've picked out, but actually play through it. I really enjoy watching them. I'm sure I've said it before, but I'll say it again in the future 😊
And, as always, you send immediate feedback, thank you 🫡
I thought about it a lot, tried many things, and finally decided to implement the recording function like this for the following reasons:
Delete- On slower PCs, on-the-fly recording causes the emulator to lag, and the rendering speed can even be halved (this can happen even with simple PNGs), which makes it impossible to play.
- Direct recording could be an optional feature, but many problems can occur during continuous writing to disk (the disk fills up, the emulator randomly freezes for seconds because the OS is forcing it to wait, etc.). plus, if you don't get what you want to record on the first try, you just record another gameplay session and render the one you're most satisfied with in the end.
I apologize, but not only is the emulator not very well documented yet, it also doesn't have a file manager, so it's not entirely clear when using the program, but every single gameplay recording is saved in the C64emuData/Gameplays folder, from where you can reload any of them at any time.
Feel free to create countless gameplay recordings, as these files will be small in size, and you can safely exit the emulator and render them at another time.
I'm glad you bring up this topic, because I haven't written about how it works yet, and it's good to know.
I'm glad you like seeing the videos. C64emu is the first emulator I've tried that makes the C64's 320x200 50Hz display look good at 1080p 60Hz, so it's really been fun to revisit my favourite games. (And that's been the trick: I only make videos of games I can play well.. Though, these days, I will sometimes slow the emulator down to make up for my slowed reactions, so it looks good when the sped--up version is uploaded.) 😊
DeleteReally good choice of C64 colour palette too. I don't like the VICE defaults: looks too muted. As someone who had an original breadbin C64, the C64emu palette looks more 'correct' somehow.
You make a fair point on why you've chosen the recording method you have. I suspected performance-when-recording would be a key point and, at the end of the day, it works well. So I can't disagree with your implementation.
I tend to do full recording with OBS, and use the C64emu recording engine for gifs. And the png-every-frame output has been excellent. So much easier than getting screentogif to grab every second frame from the emulator window. 👍
I'll get my next recording ready.. I went for green screen this time. Looks so cool. 😎
Yeah, surprisingly, higher screen resolution actually improves the quality of the CRT filter, rather than causing annoying errors. The colors appear more vivid mainly due to the CRT glow effect and the fact that the intensity of the RBG components is visible individually, making the overall picture less washed out. BTW, I will be uploading a fix for mipmapping quality degradation later today. It might be worth waiting for before you make a new video.
DeleteI made it optional whether the emulator uses the new or old mipmap generation method (see the Hotfix section at the top of the page). Have a look at which one you like better before making a new recording.
DeleteThank you for implementing a C64 emulator with sane defaults. Like starting fullscreen with proper CRT emulation.
ReplyDeleteLooking forward to the macOS version in the future.
Thank you so much! 🫡
DeleteWill be there customised filter values in the Android app?
ReplyDeleteYes, definitely. Probably in a simplified form, but there will be a 6581 cutoff offset adjustment option, hopefully soon.
DeleteThe latest version has an unpleasant moire pattern in the CRT emulation. The previous version looked much better. Seen most clearly on light colors.
DeleteOh, sorry and thank you! I noticed that myself, but then I forgot about it. This is because there is a deprecated mipmap generating OpenGL function, which causes the emulator to start very slowly, so I replaced it with the "recommended" function, which is much faster, but unfortunately produces lower quality results. I just want to left it temporarily because it was useful during development to have it start up faster, then I focused on the SID and it stayed that way.
DeleteTomorrow I will fix it. 🫡
Now that I've taken a closer look, the new mipmapping method is a little bit detailed, not necessarily worse in quality, in fact maybe even better when the moiré effect is not visible, but it does moiré more in certain cases (depending on screen resolution and window size) than the old method, so I made it optional, so everyone can decide which one they like better (see the Hotfix section at the top of the page).
Delete