clownacy / clownmdemu Goto Github PK

The only controllers that are currently supported are the 3-button ones.

The CPU interpreters currently do not support delays of any form. However, I know of many that occur on real Mega Drives:

• Work RAM delays
• 68k being delayed when accessing its memory bus during a VDP Transfer.
  • Z80 accessing the 68k bus during this.
• 68k writing to the VDP while its FIFO is full.
  • 68k reading from the VDP while its FIFO is empty?
• The mysterious so-called "DRAM refreshes" (I think the Overdrive II document explains this one).
• Z80 cycle-stealing.

As a simple usability improvement, the emulator should change region to suit the loaded game. This would prevent games with region locking from being unplayable until the user changes the emulated console's region in the settings.

I live every day of my life in fear of implementing the H/V counter. Fortunately, there are some good test ROMS for it here: https://sonicresearch.org/community/index.php?threads/clownmdemu-the-greatest-mega-drive-emulator-ever-someday.6571/page-3#post-89616

... But I made a fork of it that is.
... And I even fixed a latent bug on other platforms.

https://github.com/jfolker/tinyfiledialogs

The original author doesn't update frequently, can you use my version instead? I managed to build clownmdemufrontend (FreeBSD, Clang) and even play Sonic 2 XL on it successfully.

The Window Plane was implemented in a really hacky way that isn't even correct: when drawn on the same line as Plane A, Plane A will appear behind the Window Plane. This is dumb, and is easily shown in the Sonic Clean Engine:

This is the post that mentioned this.

This may not be your fault, but Windows 10 H2 will detect clownmdemu as Trojan:Win32/Wacatac.H!ml, I haven't tested Windows 11

This is something that Vladikcomper has brought up a few times: Gens KMod and BlastEm support the KDebug API, which allows emulated software to call into the emulator for a handful of uses, such as debug logging. On a real Mega Drive, using this API is harmless since it is done by accessing unused VDP registers. Though, I wonder about buggy games and homebrew that just access these registers accidentally: the last thing I need is to try to print garbage data as a zero-terminated string.

Some documentation can be found here: https://github.com/vladikcomper/md-modules/blob/master/modules/errorhandler/docs/how-to/Use_KDebug_integration.md

Every audio sample in the game plays too slowly. Noticeable as soon as the Sega logo.

Couldn't find a real hardware video, but this emulator capture seems about right: Video

This also affects Earthworm Jim 2, and probably other GEMS games?

So you remember that fix you did for Jim Power? This is basically that for CRAM, but with no commercial examples as far as I'm aware.
For a text printing routine I've made, I used a longword decrement write to CRAM via the data ports, to save a few bytes. Abbreviated code below:

	lea	vdpctrl,a5
	lea	(a5),a4		; dec to data port
	move.l	#vdpComm(0,CRAM_WRITE),(a5)
	move.l	d2,-(a4)	; dec to data port (written values are word-inverted)

On real hardware and all other emulators I've tested, this results in the word values in d2 being written out of order, or "word-inverted". The only other thing I know that shares this behaviour is the AtGames Firecore of all things. Here's a rom to test this on

As pointed out by Vladikcomper, Window Plane emulation is broken in H32.

This is the last one, I promise!

this post seems to be an explanation of the issue.

They're there most of the time, but they drop out every few frames. I checked on real hardware, and they stay visible the whole time.

To quote Malachi...

I found the problem code. Basically at the end of my H_Int routine I had this
; a5 = vdp control reg
-    move.w    (a5),d0    ; wait until it's out of Hblank
    andi.w    #1<<2,d0
    bne.s    -
-    move.w    (a5),d0    ; now wait until it's in
    andi.w    #1<<2,d0
    beq.s    -

The first one was the problem, my assumption is that the register is always set to be in Hblank. Thankfully, that check was actually useless for this routine, so now you can play Sonic 2 as god inten-

vladikcomper — Today at 18:21
Hi, I have another bug report on Clownmdemu, this time quite serious~

Looks like timing of Z80 interrupts is quite buggy. From my observations, your emulator may trigger Z80's VInt mid-frame or even by the end of the frame; at any moment in time really, if interrupts were previously disabled or if Z80 was stopped. This should never happen and it may mess up some Z80 drivers in unexpected ways.

On real hardware, there's a time window of ~171 Z80 cycles since the start of VBlank when interrupt will be acknowledged. If Z80 is stopped during this time or interrupts are disabled, VInt should be missed. In Clownmdemu, however, interrupt request "sticks" and will fire whenever interrupts are re-enabled or Z80 starts again, which may happen mid-frame.
vladikcomper — Today at 18:28
... This is somewhat related to my issue with Z80<->68k access delays. You see, I attempted to implement a "calibration" check by measuring 68k ROM vs Z80 RAM access time (number of reads before VBlank) to detect and calibrate Mega PCM 2 loops for inaccurate emulators.

In inaccurate emulators ROM and RAM read count per frame match (while on real hardware ROM access is 24% slower), so it mostly worked well... Expect for Clownmdemu, which often refuses to properly calibrate, because it fires the first VBlank at arbitrary times :)

vladikcomper — Today at 18:57
There isn't much information available on the interrupts, so I gained some of this knowledge from various people or emulator's source code.

That 171 cycle window for VBlank I originally discovered in Blastem's source code. I then found it in at least one more source, so it should be really accurate:
#define Z80_INT_PULSE_MCLKS 2573 //measured value is ~171.5 Z80 clocks

When VBlanking period starts, INT pin is triggered on Z80 for roughly 171 cycles. If interrupts are enabled, Z80 disables them and executes VInt routine at 38h (I won't mention other modes useless on the MD).
If your VInt routine is shorter than 171 cycles or you re-enable interrupts (ei) immediately, the interrupt will be triggered again in the very same frame. This is why INT signal only lasts for 171 cycles and not the entire VBlank.

I know it's not implemented but i through this info will help.

This is the output of Sonic 1

ERROR: Unimplemented instruction IM used at 0x23
ERROR: 68k attempted to access Z80 memory/YM2612 ports without Z80 bus at 0x72776
ERROR: 68k attempted to access Z80 memory/YM2612 ports without Z80 bus at 0x7278E
ERROR: 68k attempted to access Z80 memory/YM2612 ports without Z80 bus at 0x72740
ERROR: 68k attempted to access Z80 memory/YM2612 ports without Z80 bus at 0x72758

Do you think it would be possible for you to port these three Sonic games:

Sonic 3 A.I.R
Sonic Nexus
Sonic Robo Blast 2
The Sonic 3 A.I.R has its source code on github, just google it and I think there is a port for Switch.

The Sonic Nexus decompile is in the Rubberduckycooly repository and is also based on RSDK so it can be ported to the Wii U.

Sonic Robo Blast 2 has its source code on its website and it would be interesting to see the port of the latest version of SRB2 on Wii U.

Finally, I wanted to ask you if it is possible if you can compile and adapt to Wii U, the movian application. It is a multimedia center that is for PS3 and PC and an attempt was made a long time ago to make a port for Wii. Maybe you can use the Wii port source code to make the Wii U port, especially since streaming services on Wii U are going to end soon.

You can find the Movian Wii source code in the wikiblog0 github repository. And the original source code on the movian website.

Link: https://github.com/wikiblog0/movian-wii-wiiu
I appreciate your contributions to the Wii U scene.

Greetings

What it says on the tin.

Hello! Great emulator, here I am playing on a Linux-based OS running Debian 11, and I built manually the 0.5.1 version.

As I was testing several games, I came across Hellfire (USA) version that, for some reason, has invisible sprites for both the ship and the enemies!

I am leaving a savestate, though it seems any version may encounter this bug during emulation? (ignore the .zip naming, that was just a way for me to upload the file containing the relevant info surrounding this game)
hellfirebug.zip

I didn't test every EA game - there are lots - but here's what I happened to run into:

• Crue Ball - boots to black screen with music
• The Immortal, Jungle Strike, Marble Madness (US) - EA logo has corruption but otherwise fine.
• Road Rash, Road Rash II, Road Rash III, Skitchin' - EA logo has corruption, game crashes once a race starts. Pretty sure all of these games use the same engine so it should be the same fix for all of them.

At one point, m68k.c references m68k/gen.c, which does not appear to exist. I take it m68k/generator.c was meant?

Waiting on the title screen will show a demo, then the title screen again, and finally an intro with a text scroll. This video shows what it's supposed to look like.

In clownmdemu, no text shows up:

This SpritesMind post partially describes what causes this.

Used by Malachi's hack. The 68k should indeed stop, but interrupts should resume it. STOP can be used for implementing WaitForVInt.

Hi, I have a problem when I launch any game from SGDK or sample assembly :

ERROR: Attempted to read invalid Z80 address 0x55EA
ERROR: Attempted to read invalid Z80 address 0x55EB
ERROR: Attempted to read invalid Z80 address 0x55EC
ERROR: Attempted to read invalid Z80 address 0x55ED
ERROR: Attempted to read invalid Z80 address 0x55EE
ERROR: Attempted to read invalid Z80 address 0x55EF
ERROR: Attempted to read invalid Z80 address 0x55F0
ERROR: Attempted to read invalid Z80 address 0x55F1
ERROR: Attempted to read invalid Z80 address 0x55F2
ERROR: Attempted to read invalid Z80 address 0x55F3
ERROR: Attempted to read invalid Z80 address 0x55F4
ERROR: Attempted to read invalid Z80 address 0x55F5
ERROR: Attempted to read invalid Z80 address 0x55F6
ERROR: Attempted to read invalid Z80 address 0x55F7
ERROR: Attempted to read invalid Z80 address 0x55F8
ERROR: Attempted to read invalid Z80 address 0x55F9

The problem occurs when restarting the Z80:

move.w $000,($A11200)

I hope you can fix this issue.

This is an odd one. Any inputs (even in the menu) are extremely sluggish and buggy. It's like the game only successfully reads the controller 10% of the time. The success rate seems to vary depending on CPU load - you can at least move between menu options, but once the game starts you're functionally immobile.

Supposed to look like this.

I can see the correct colors for the speedometer are present on Plane B, but they're not being shown behind the window plane. Probably a duplicate of #24?

The first scene of the intro cutscene features graphics that don't load in correctly:

Compared to real hardware and most emulators: Video

Stage 2 is missing the entire foreground layer, and one sprite palette gets corrupted as you walk to the right. There's also some graphical corruption in the HUD:

Further stages are not any better:

There's a code to warp to the next stage, should be useful for testing: Start, B, A, Down, B, A, Down, Left, Up, C.

Debug viewer shows that sprites are being loaded... but they don't show up.

• Ms Pac-Man (on boot)
• Star Cruiser (on boot)
• Demolition Man (on boot)
• Lemmings 2 (on boot)
• Ultracore (on boot - has music, at least)
• Shadow of the Beast (immediately after EA logo)
• El Viento (after hitting "Game Start")
• Super Street Fighter II (a red screen on boot. Almost certainly related to its special 5MB mapper)

Yesterday I decided to try this game, and did a video showing it on YouTube, and I decided that I'd bring it here since another person also found the same issue;

The title card on levels bug out, it causes dots on World 2s background in attractions, and it causes some of the tether graphics to become black squares which carry over into the field stages (though they show up fine there if you start on them via "SELECT".)

The Z80 sound driver also doesn't seem to cause the game to crash (the problematic line) Ala inaccurate emulators.

A weird strip of 3 white squares will also show up in the "SELECT" menu if you can manage to trigger the alternative SEGA screen as shown in this screenshot; [screenshot]
(found out it was in the original game, disregard this part.

Here's a video comparison of the title card..

Bugged:

The intended result (using BlastEm):

Options menu - shown after pressing start on title screen - shows graphical corruption:

After starting the first level, none of the sprites show up and the game freezes:

Video of a full playthrough: Here

I'm sorry to post this here since it has nothing to so with Clowndemu :P
I did leave a msg on your Blog bit it didn't display after I sent it?

I just want to thank you for looking into N64 for the WiiU. your Blog post was an interesting read. You seem to have gotten really far even getting the Core to compile and run something :)
While I'm less than useless when it comes to coding and things like that M4xw could have saved you some time debugging, he's the maintainer of the Retroarch Mupen64 Core :)

How far are you planning on taking this N64 core? I see you primary goal is the OpenGL ES 2.0 renderer?
but honestly I hope you can make the N64 Core a reality. We have a reasonable PS1 Core 90% of games are running perfectly fine but some are still under performing, I'm hoping the OpenGL ES 2.0 will help there if you continue your work.

I see your work on the Core is with Aroma in mind? Tho I think it should be able to work on the Tiramisu environment too (that's what Retroarch currently runs on)
You mention that the Retrorach port is going through a messy refactor (which is true) but the old Tiramisu Isn't broken, your Core should be able to run on that just fine.

I hope you continue your port, even just for the OpenGL ES 2.0 work, I know Gary is still working on his ANGLE port but the more the merrier :D
M4xw is working on an aot recompiler that likely can be reworked to run on WiiU so if combined with your work could produce a working (fullspeed hopes) N64 Core for WiiU.

Again sorry for posting this here, I would have posted this on you Blog, but my last message didn't got through and you don't seem to be a member of GBAtemp and I couldn't find you on Discord.. I did find you on Sonic Retro but I couldn't send a PM :p
I'll delete this if its inappropriate.

Thank you for even looking into brining new (3D) Cores to WiiU. Its very much appreciated.

Funnily enough, it's there when the screen is fading in, but once that's done, it's like this.

Compare to this.

As explained here, Echo the Dolphin and its sequel both have distorted sound effects. These games might be using SSG-EG or LFO, which are both currently unemulated.

A video showing this problem can be found here.

It doesnt compile on windows mingw msys2

Haven't had a chance to verify if the fix to Jim Power also fixes this.

The intro cutscene scrolls a graphic on Plane A up and down, as seen in this video.

However, this is what happens in the emulator:

Note that this intro is different in the Japanese version.

I booted up a bunch of games and looked into anything that sounded off. (I also knew beforehand of a few games that tend to give emulators trouble in the sound department.) A lot of these have to do with known unemulated YM2612 features (SSG-EG, extended CH3 mode, LFO, CSM). I know you said sound emulation wasn't a priority at the moment, but I figured it was better to document all this in advance, rather than just sit on it. Hopefully this doesn't keep you up at night.

(By the way, I want to commend you for writing your own sound emulation. A lot of projects just use the Nuked cores - which is fine, but it's neat to see someone do it the hard way. The PSG noise emulation already seems to be a better match for Sega's SN7 clone than BlastEm, which sounds more like a main-brand one.)

I also found quite a few non-audio bugs while testing random games' audio... expect more bug reports to be made soon. Sorry about that.

SSG-EG

• Beavis and Butthead - the music track "Yogurt" and the sound effects "CHANSAW" and "ZAP" use it.
• Xeno Crisis - I'm told this game uses it but I don't know what for. This is a recent aftermarket game so my guess is "a lot".
• Tanglewood - another recent game that uses it a lot. Note that the game will actually disable SSG if it thinks it's running on a clone console.

Extended CH3

• Streets of Rage 1 and 2 - a bunch of sound effects use it.
• Devilish - Track 05 (Waterfalls) uses it on the lead instrument to play three notes across two channels.
• Gauntlet IV - "Sortie" and "Retribution" use it according to this
• Demolition Man - supposedly uses it a lot for percussion (according to this) but the game doesn't boot so I can't check.

CSM
As far as I know, only tech demos have used this.

• Aly James' CSM Test ROM
• GENATARi made a Vocaloid using CSM called Niro Ichini. (The .fur files are meant for Furnace Tracker.)

Misc
Most of these will probably fix themselves as the FM emulation gets built out, but I thought I'd include them just in case they turn out to be unique bugs:

• Scooby-Doo Mystery - Hi-hat in intro sounds obnoxious. I checked on real hardware, and it's almost inaudible.
• Comix Zone, track 5 - Same deal.
• Rocket Knight Adventures - FM patch used throughout OST sounds like a hihat instead of a bass drum.
• Mega Turrican - Tracks 03/05/09/11/21 all have what sounds like the same wrong instrument. I know this game uses SSG-EG somewhere, but I don't know if this is that or something else.
• Boogerman - The toms in Stage 1 (about :30 in).
• Ecco 1 and 2 - #25. Also, both games sound slightly wrong on boot (Ecco 1 has an overly brash instrument for the first notes of the intro, and Ecco 2 has some scratching noises).
• Mick & Mack - SFX used in the intro cutscene, as well as the one that plays when you start the level.
• Greendog - Sound effect used in the intro when he kicks his legs around.
• Contra Hard Corps - FM kick drum used in most tracks sounds like a wet "glug".
• Wiz n' Liz, Alien 3 - Basically every instrument is weird. Some sounds have the wrong timbre, while some sound like they're getting cut off too early. Some sound fine for one note and wrong for the next.
• Earthworm Jim - First level's music has a weird instrument about 20 seconds in. The explosion sound (plays when you die or use a gun powerup) sounds like a hiss rather than a rumble.

Most of these are less "audio bugs" and moreso "bugs that affect the audio":

• #18; affects both Earthworm Jim games, Cool Spot, Mick & Mack, Greendog, and others. Doesn't affect Comix Zone for some reason, even though it uses the same sound driver.
• Beavis and Butthead - Samples don't play.
• After Burner II - Plays samples by writing to the PSG channels, which doesn't work. Mutes the percussion and most sound effects.
• Zoop - Whole game is silent.
• Jim Power - The Piko Interactive logo has a glitchy sample playing over it; it's silent on real hardware.
• Fantastic Dizzy - Audio glitches can occur when opening and closing the ingame menu.

===

If you're ever looking to check a music track against real hardware without pulling out the real thing, DUSTINODELLOFFICIAL and Random VGMs on YT are good sources.