Exodus 2.0 + Open Source Release

Official support forum for the Exodus Emulation Platform

Moderator: Nemesis

User avatar
Huge
Very interested
Posts: 171
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Fri May 01, 2015 7:12 pm

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).
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.

deargodwhatisthat
Newbie
Posts: 9
Joined: Mon Mar 10, 2014 11:55 am

Post by deargodwhatisthat » Fri May 01, 2015 8:39 pm

WHOO! It's finally out and everything runs at full speed with a decent little filter too. Awesome job, dude :D

As for Eternal Champions, every time I load my copy up, it shows the wizard spinning his staff.

User avatar
Shadow
Very interested
Posts: 257
Joined: Wed Sep 16, 2009 7:13 am
Location: Russian Federation
Contact:

Post by Shadow » Fri May 01, 2015 10:38 pm

Eternal Champions, Hard reset: every time, it shows the wizard spinning his staff. Soft reset: every time, dude draws energy from the logo Sega.
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?
Yes, I confirm, speed constantly jumping near 58-62fps and animation looks like the game is not in NTSC, approximately 52-54 frames visually.

User avatar
King Of Chaos
Very interested
Posts: 268
Joined: Fri Feb 29, 2008 8:12 pm
Location: United States

Post by King Of Chaos » Sat May 02, 2015 2:21 am

AFAIK, Kega is the only emulator that has random characters for X-Men 2 on power on/hard reset and soft reset. And it also has random character Sega logos for Eternal Champions on soft reset.

User avatar
Shadow
Very interested
Posts: 257
Joined: Wed Sep 16, 2009 7:13 am
Location: Russian Federation
Contact:

Post by Shadow » Sat May 02, 2015 12:39 pm

I have a dream, that Eke, Stef and other authors of emulators will be part of the team and will find a little time for Exodus. Sadly, I'm not good at programming. But, i will help you with tracking bugs in all games, if it needed.

mickagame
Very interested
Posts: 208
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Sat May 02, 2015 1:01 pm

If u want play games with emulator 100% compatibility i told u play With retroarch and genesis plus core. Is perfect !

User avatar
Shadow
Very interested
Posts: 257
Joined: Wed Sep 16, 2009 7:13 am
Location: Russian Federation
Contact:

Post by Shadow » Sat May 02, 2015 1:47 pm

mickagame wrote:If u want play games with emulator 100% compatibility i told u play With retroarch and genesis plus core. Is perfect !
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.

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) :)

User avatar
Huge
Very interested
Posts: 171
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Sat May 02, 2015 7:09 pm

mickagame wrote:If u want play games with emulator 100% compatibility i told u play With retroarch and genesis plus core. Is perfect !
If you want 100% compatibility, build your own socketed carts!

User avatar
Shadow
Very interested
Posts: 257
Joined: Wed Sep 16, 2009 7:13 am
Location: Russian Federation
Contact:

Post by Shadow » Sat May 02, 2015 10:12 pm

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.

And yet, emulator randomly hangs during gameplay, in any case, it happened to me on two games Comix Zone and Super skidmarks.

User avatar
Nemesis
Very interested
Posts: 670
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Sat May 02, 2015 10:53 pm

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) :D
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.

tryphon
Very interested
Posts: 231
Joined: Sat Aug 17, 2013 9:38 pm
Location: France

Post by tryphon » Sat May 02, 2015 11:31 pm

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).
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).

What graphics library do you use for rendering ? OpenGL ?

User avatar
Nemesis
Very interested
Posts: 670
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Sun May 03, 2015 12:52 am

tryphon wrote:
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).
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).
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.
What graphics library do you use for rendering ? OpenGL ?
Yep, I'm using OpenGL for all the windows that push raw pixels to the screen.

User avatar
Shadow
Very interested
Posts: 257
Joined: Wed Sep 16, 2009 7:13 am
Location: Russian Federation
Contact:

Post by Shadow » Sun May 03, 2015 2:28 am

Nemesis 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.
Emulator really stops working, CPU load is 0% and I can't stop process without Task Manager. I recorded video http://dropmefiles.com/OSZFu
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.
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. :(

tryphon
Very interested
Posts: 231
Joined: Sat Aug 17, 2013 9:38 pm
Location: France

Post by tryphon » Sun May 03, 2015 7:13 am

Nemesis wrote:I hadn't thought about that kind of use.
I think Nemesis will become incredibely popular in MD hacking scene :)
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.
I was precisely dreaming of such a window (no kidding) :D :D :D
Yep, I'm using OpenGL for all the windows that push raw pixels to the screen.


Thanks.

User avatar
Stef
Very interested
Posts: 2616
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sun May 03, 2015 10:20 am

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.
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.
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.
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 :p
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 :D
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.
Glad to hear that, it will really use that WAV log feature to make my futures tests !

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest