Eternal Champions also loads random SEGA logos upon booting. I did not test how it behaves in Exodus, but it might be worth a look.Nemesis wrote:You know, I did actually add support for this, and I was banging my head against the wall as to why this wasn't working, and then when I did hardware tests, I found that on the systems I tested on at least, the character also wasn't random on the hardware either. Never diagnosed past that. It'd be worthwhile going back and testing on your system, and if it is random for you, I'll need to know the specs of the unit you're using (region and board/chip revisions).
Exodus 2.0 + Open Source Release
Moderator: Nemesis
-
deargodwhatisthat
- Newbie
- Posts: 9
- Joined: Mon Mar 10, 2014 11:55 am
Eternal Champions, Hard reset: every time, it shows the wizard spinning his staff. Soft reset: every time, dude draws energy from the logo Sega.
Yes, I confirm, speed constantly jumping near 58-62fps and animation looks like the game is not in NTSC, approximately 52-54 frames visually.King Of Chaos wrote:All games seem to be running at full speed but I notice the FPS maxes out at around 62 to 63 FPS, any reasoning for this on a 60Hz monitor?
-
King Of Chaos
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States
Well.. I have a Genplus GX (Wii version) and i use it in the emulator Dolphin. Yes, for games - perfect solution. Eke a great programmer, he is trying to make emulator as accurate as possible (based on the limits of the processor Wii) For example, Genplus GX emulator can display color bars, and perform illegal operations M68, etc.mickagame wrote:If u want play games with emulator 100% compatibility i told u play With retroarch and genesis plus core. Is perfect !
But, I feel a huge interest in the Exodus, because its main task - emulate hardware with no limits and no temporary workaround fixes for games. I admit, I am sick to emulate a real hardware (as be a audiophile, rather than just listening to the music itself)
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.
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.
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.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 ?
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.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)
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.
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.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).
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.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.
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.And yet, emulator randomly hangs during gameplay, in any case, it happened to me on two games Comix Zone and Super skidmarks.
The thing is that I don't use Nemesis for playing, but for debugging / hacking. And it's very handy to know exactly the position of a given pixel (for example, measuring the width of a dialog box in an RPG can make it easier to find the code drawing it). A snapshot can help too, but I didn't find how to take one (I haven't used it a lot yet to be honest).Nemesis wrote: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).
What graphics library do you use for rendering ? OpenGL ?
I hadn't thought about that kind of use. Seems there's scope for another debug window here. How about a window which shows the output image, but when you move the mouse over the window, it shows a floating window that tells you the active scan pixel index, palette row and index, source layer, and pattern/mapping entry that was used to determine that value? That'd give you not only a way to determine pixel position, but effectively a way to reverse the rendering pipeline and determine what source data was used to produce it. The VRAM pattern viewer uses floating window similar to what I'm thinking of.tryphon wrote:The thing is that I don't use Nemesis for playing, but for debugging / hacking. And it's very handy to know exactly the position of a given pixel (for example, measuring the width of a dialog box in an RPG can make it easier to find the code drawing it). A snapshot can help too, but I didn't find how to take one (I haven't used it a lot yet to be honest).Nemesis wrote: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).
Yep, I'm using OpenGL for all the windows that push raw pixels to the screen.What graphics library do you use for rendering ? OpenGL ?
Emulator really stops working, CPU load is 0% and I can't stop process without Task Manager. I recorded video http://dropmefiles.com/OSZFuNemesis wrote: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.
Quite difficult to repeat, this is very unpredictable. Sometimes I just leave the emulator to work in the background and it suddenly happens, in log also nothing is displayed.Nemesis wrote: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.
I think Nemesis will become incredibely popular in MD hacking sceneNemesis wrote:I hadn't thought about that kind of use.
I was precisely dreaming of such a window (no kidding)Seems there's scope for another debug window here. How about a window which shows the output image, but when you move the mouse over the window, it shows a floating window that tells you the active scan pixel index, palette row and index, source layer, and pattern/mapping entry that was used to determine that value? That'd give you not only a way to determine pixel position, but effectively a way to reverse the rendering pipeline and determine what source data was used to produce it. The VRAM pattern viewer uses floating window similar to what I'm thinking of.
Yep, I'm using OpenGL for all the windows that push raw pixels to the screen.
Thanks.
-
Stef
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Yeah i observed the Z80 delay is more expensive than it should, no emulator get it perfect but strangely Fusion is close enough here (while it has a bit off Z80 speed by default). But that is not a big deal, i observed the usual delay is about 3 cycles penalty when getting a byte from 68000 bus so now i just apply it :p Strangely with my previous drivers i observed less by reading a word from stack pointer but well, maybe my Z80 cycles counting is a bit off.Nemesis wrote: 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.
The wav logging is a good idea, i forgot about it and was already using that feature to perfectly log audio while doing fast forwarding (with Gens), nice way to quickly record a music :pAnd 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.
As you said, many music player tends to apply many filters which make the sound a lot better than it should, then you are really disappointed discovering how it should through emulator / real hardware
Glad to hear that, it will really use that WAV log feature to make my futures tests !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.