When I get a chance, I'll do some hardware tests again to check the behaviour of Xmen and Eternal Champions. If I can reproduce it on the hardware, I can find the difference in behaviour and emulate it.
tryphon wrote:Thanks, I missed this checkbox. And id it possible to force the resolution window to 320x224 (like in version 1) ? Or is forced to fit the width of the panel ?
There's no option to force a fixed resolution, it uses as much space as is available while maintaining the aspect ratio (unless you turn fixed aspect ratio off). There's no actual resolution that's an accurate representation of the video output anyway. Even ignoring the fact that horizontal scanlines are analog, and there's some transition time between pixels, the Mega Drive generates non-square pixels in most video modes, and interlacing makes things much more complex too. It's best just to view it with as much screen space as you have available, with filtering either enabled or disabled. You wouldn't want fixed pixel size windows with high DPI screens anyway, which are becoming the norm. I have a 24" 4K monitor on my desk at work, and I can tell you that a 320x224 pixel window isn't playable at that DPI, and most people are going to be using monitors like that in the near future (3-5 years probably). Exodus fully supports high DPI modes, which means sizes are based on the physical display size on the screen based on the DPI, not fixed pixel sizes.
Stef wrote:Awesome release, thanks Nemesis !
I noticed the simple 68000 <--> Z80 communication can make the emulator to slowdown a lot. I just tested my sound driver test rom which almost does nothing with the display and while some drivers are running at 60 FPS on my i5 @ 1.8 Ghz others hardly raise 30 FPS. I wanted to use Exodus to test the problem of DMA bus retention when Z80 access the main 68000 bus, currently i need to test against real hardware for that... I guess Exodus handle that case correctly but still currently even if Exodus is faster than before it remains a bit slow for my system and unfortunately it is very hard to judge about the sample quality in this case :p I guess i will have to upgrade my notebook at some point (among the dying battery, that may another good reason to do it)
Yes, it is quite an expensive operation to call across the Z80 to 68000 bus bridge. This operation is actually generating a bus request on the 68000, and going through the normal bus request/acknowledge process. The bus changes I'm planning will help to accelerate this process. Also note, there's actually more delay in bus requests from the Z80 to 68000 buses than there should be right now. In the real hardware, the 68000 can grant the bus between any bus operations, but until I have a cycle-accurate 68000 core, it can only grant the bus between opcodes right now. This means the Z80 has a much bigger delay than it should when requesting the 68000 bus, so you should be aware of this fact when you do any testing in this area.
And a tip: If you want to test audio quality, use the audio logging features! If you output the audio to a wav file, it writes it out at the actual native sample rate. Even if the game execution is lagging, the logged audio file will be perfect. You can then play the wav log back in any player to hear how it sounds. In fact, a good thing about doing this is that if you play it back in a professional program like Adobe Audition, I've noticed that the high quality filtering process they use for sample rate conversion makes things sound better than they do through the emulator sometimes.
Stef wrote:Just one note Nemesis, i don't know if you emulated this but i observed this behavior while developing the XGM driver: if you access the VDP ports from the Z80 while a DMA is occurring then the Z80 is stuck as it was accessing the 68000 BUS, i though the Z80 was directly connected to the VDP so i was a bit surprised... I wanted to use the VCounter from Z80 (to detect possible period of DMA) but meet that problem then, that is also the case then when you access the PSG from Z80. I had hard time to figure that while i was testing the XGM driver on real hardware (very difficult to sort the DMA contention issue when Z80 is playing music *and* the samples because of that reason).
Exodus emulates this accurately. The VDP goes through the same bus request/acknowledge process as the Z80 when requesting the bus. If the VDP has bus ownership, the Z80 bus request has to wait for the VDP to release the bus.
Shadow wrote:I found a bug, if you run emulator without the game (System -> Run System) and wait a minute, the frame counter stops and the emulator hangs.
Yeah, I should do something about that. The emulator isn't actually hanging, just running very slowly. It happens when the M68000 starts hitting the VDP memory block and trying to execute code by reading from its ports. There's an edge-case timing issue in the VDP core that's triggered in this case, and the VDP starts rolling back the system like crazy, and spurting out debug messages to the debug console (which you can see if you turn on the console in platform settings, but be warned, just enabling the console impacts performance). I haven't narrowed down the timing issue yet, and when I improve the bus system, the 68000 will correctly hang when DTACK isn't asserted, which will halt it long before it reaches the VDP in the memory map anyway.
And yet, emulator randomly hangs during gameplay, in any case, it happened to me on two games Comix Zone and Super skidmarks.
Can you give me more information about this? If it's reproducible or fairly consistent, I'd love a savestate just before it appears to hang, or steps to reproduce it.