Exodus 2.1 release soon (Now available!)

Official support forum for the Exodus Emulation Platform

Moderator: Nemesis

awye
Newbie
Posts: 5
Joined: Wed Aug 19, 2015 9:06 pm

Re: Exodus 2.1 release soon

Post by awye » Mon Sep 03, 2018 9:23 am

Nemesis wrote:
Wed Aug 29, 2018 12:09 am
So, anything else? :)
Master System support possible? :roll:

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

Re: Exodus 2.1 release soon (Now available!)

Post by tryphon » Mon Sep 03, 2018 1:19 pm

And MegaCD ! Would be great :D

Easier maybe (taken from Gens-r57shell, great for debugging, but far less reliable) :

* a built-in slow mode (I know you gave a way to fake it, but it'd be nice to be able to enable/disable it)

* display FPS / Controls / missed VBlank counter onscreen

* a way to record movies (with counters mentionned above)

* Lua script integration ?

* a history mode, that lets you navigate in a game session (à la Bizhawk, I think Mesen does something similar)

But it's already really very useful.

I noticed a different behaviour between Nemesis and real hw, likely related to the VIntPending flag on VDP Ctrl Port).

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Re: Exodus 2.1 release soon

Post by Huge » Mon Sep 03, 2018 10:10 pm

awye wrote:
Mon Sep 03, 2018 9:23 am
Nemesis wrote:
Wed Aug 29, 2018 12:09 am
So, anything else? :)
Master System support possible? :roll:
This is actually a good question, since the Megadrive VDP has almost all the SMS functions, and Exodus is supposed to emulate the VDP perfectly.

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

Re: Exodus 2.1 release soon (Now available!)

Post by Nemesis » Tue Sep 04, 2018 1:16 am

It's worth noting that my Mega Drive VDP core currently doesn't implement mode 4 support. It requires a whole set of tests to be carried out, which I haven't done so far. Even if I had mode 4 support in the Mega Drive VDP core though, the Master System VDP is actually quite different. Not only does it have support for the older video modes for compatibility with the SG-1000/SC-3000, it has different memory timings and quirks of its own. I would build the SMS VDP as a distinct device assuming everything is different, and I won't be implementing SMS support until I can dedicate the time to do my own hardware tests on the SMS and verify behaviour as I go. That will probably happen in the future, but I'll be focusing on the M68000 cpu core first, with the Z80 cpu core following shortly afterwards most likely. Once I've got the Z80 core in better shape, the SMS will be in closer reach.

In terms of the Mega CD and the 32x, I do want to reach those systems eventually, but note that those addons greatly increase the complexity of the Mega Drive system as a whole, and emulating them accurately absolutely depends on good timing accuracy in particular. There's currently a complete lack of accurate timing information for these platforms though, and even basic hardware features are often not well understood, and have lacking and/or inaccurate documentation. Current accuracy of MegaCD/32x emulation is very poor in all existing emulators, and it's going to require extensive hardware testing to even figure out how to implement them properly. I could probably hack something together and get a lot of games running quickly, but I'm not going to do that. If I tackle those addons, I'm going to do it right, and it will absolutely be years of work to get both of them done. I want to focus first on the basic Mega Drive though. Once it's running with perfect timing, implementing those other systems becomes simpler and easier to verify. The MegaCD in particular should be in closer reach, especially as I'm already somewhat familiar with the low-level hardware. The 32x will take longer, as an SH2 core has to be written, which is a complex little chip. Writing a cycle-accurate SH2 core is not going to be fun, especially with its caching behavior to emulate, but this will open the door to Saturn emulation, so it'll pay off in that regard.

While it's going to take me awhile to do all this by myself, Exodus is of course open source, so it's possible someone will jump on along the way and help out. With the plugin model, it's even possible for someone to develop and release their own devices and extensions separately, to add new graphics chips or CPU cores, or add new debugging features. It's also theoretically possible to try and interface existing CPU cores from other emulators. I'm not expecting that kind of thing to happen anytime soon, but in the future who knows?

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Exodus 2.1 release soon (Now available!)

Post by Sik » Tue Sep 04, 2018 1:23 am

The Master System VDP also has a revisions with rather significant changes (fixes the MAG bit and adds the taller video modes), and there are PAL games relying on those (especially Codemasters stuff), while Mega Drive takes a different path (MAG is outright removed completely rather than fixed), and this before taking into account the Game Gear VDP. That said, I do recall Mega Drive VDP adjusting its timing in mode 4 (since presumably any game doing raster effects relies on this).
Sik is pronounced as "seek", not as "sick".

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Exodus 2.1 release soon (Now available!)

Post by TmEE co.(TM) » Tue Sep 04, 2018 9:59 am

I haven't found any sort of timing difference between VRAM activity and whatnot between MD and SMS mode, all the access patterns are identical, video timings identical (AND different from H256 timings). What is different is the FIFO interface being active and no support for updating only the lower half of the VRAM address (something you can do on real SMS/GG).
There is one thing actually that I don't yet know - how will HV counter correspond to external world, that is an area where there may be some difference.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

flamewing
Very interested
Posts: 56
Joined: Tue Sep 23, 2014 2:39 pm
Location: France

Re: Exodus 2.1 release soon (Now available!)

Post by flamewing » Tue Sep 04, 2018 12:19 pm

Nemesis wrote:
Tue Sep 04, 2018 1:16 am
In terms of the Mega CD and the 32x, I do want to reach those systems eventually, but note that those addons greatly increase the complexity of the Mega Drive system as a whole, and emulating them accurately absolutely depends on good timing accuracy in particular.
When you do get around to that: the bus arbiter in the Sega CD side actually understand the 68k TAS instruction, so that the subcpu can use it successfully on the Sega CD RAMs. So the 68k CPU core should probably implement the instruction correctly and leave to the bus arbiter to break it as needed.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Exodus 2.1 release soon (Now available!)

Post by Sik » Tue Sep 04, 2018 1:39 pm

MD model 3 also handles TAS properly (which is why Gargolyes hangs up - it needs TAS to fail to write), and if I recall correctly one of the goals was to emulate multiple model eventually? So TAS needs to be emulated either way.

Also the reason why that game breaks is... pretty silly (1. it was meant to be TST rather than TAS and 2. it's done to set the Z flag and it does so by testing some fixed values in RAM that have the values $FF and $00... it breaks because $00 becomes $80 after the first TAS on it - had either TST been used or the values put in ROM, it'd never break)
Sik is pronounced as "seek", not as "sick".

awye
Newbie
Posts: 5
Joined: Wed Aug 19, 2015 9:06 pm

Re: Exodus 2.1 release soon (Now available!)

Post by awye » Tue Sep 04, 2018 8:44 pm

Nemesis wrote:
Tue Sep 04, 2018 1:16 am
It's worth noting that my Mega Drive VDP core currently doesn't implement mode 4 support. It requires a whole set of tests to be carried out, which I haven't done so far.
Fair enough. On the other hand implementing Mode 4 at first will be amply sufficient. The only SMS game I am aware of that requires another graphics mode is the F16 Fighting Falcon (F16 Fighter in PAL regions). The title screen is Mode 4, while in-game is the TMS9918A Graphics Mode 2, because it was initially ported from MSX to SG-1000, and then hastily updated for the new system. It was even distributed on Sega My Card Mark III, though there was also a cartridge released in Europe.
I am only aware two VDP+PSG chips revisions used in SMS: the initial one from Yamaha YM2602(Sega 315-5124) with the infamous Tilemap Mirroring bug, and the later one, used in SMS2, UPD9004G(Sega 315-5246) from NEC, which was probably designed separately for these specs, and so does not have the bug. The only commercial game affected by the bug is the Japanese Ys. And there are only 3 PAL games that use the “taller” resolution of the SMS2. The MD implementation stems from SMS2, adding its own quirks, but depending on how it will be implemented in the emulator, it might be irrelevant.
Of course to have a clean architecture, the whole TMS9918A will need to be implemented in the end, and once you go down this slippery road you are doomed. :twisted: First, like you said, there is SG-1000/SC-3000. Once you have them, ColecoVision is within arm’s reach. :) Followed by an obscure Hanimex Pencil II from Down Under 8) , apparently also sold 17 000 km to the north-west.

Don’t you love asking people for suggestions on the forums? :lol:

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Exodus 2.1 release soon (Now available!)

Post by Sik » Wed Sep 05, 2018 4:10 am

My impression was that F-16 stuck to mode 2 for memory reasons - the framebuffer is pretty large (may not have even fit in VRAM if using mode 4), and needing to write only 25% the amount of bytes is a plus for performance. The simpler capabilities of the TMS9918 modes are actually a benefit in this case.
Sik is pronounced as "seek", not as "sick".

KanedaFr
Administrateur
Posts: 1139
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Re: Exodus 2.1 release soon

Post by KanedaFr » Thu Sep 06, 2018 9:03 pm

Nemesis wrote:
Wed Aug 29, 2018 12:09 am
Changes all done and pushed to the repo. The feature is off by default, but you can toggle it on in the settings. System savestates store the debug state (IE, timer progress and partially written text output), and debug savestates store whether the debug feature is activated. Text output goes to the event log. The timer feature didn't seem to work properly in Gens KMod, at least in the version I tried. It kept giving impossible negative numbers, but it's working right in Exodus. The changes will be in the next release.

So, anything else? :)
Timer was a failed attempt to "measure" code timing. A very raw way to profile code.
I had so many problem with my vblank code being too long, interrupted by vint.....that I was looking for a way to time it.
If you find a way to do it, you'll get a new fan ;)

Thanks for adding KDebug stuff anyway...so few people knows it and even less use it so it was basically a "niche"

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

Re: Exodus 2.1 release soon (Now available!)

Post by Nemesis » Mon Sep 10, 2018 4:55 am

flamewing wrote:
Tue Sep 04, 2018 12:19 pm
When you do get around to that: the bus arbiter in the Sega CD side actually understand the 68k TAS instruction, so that the subcpu can use it successfully on the Sega CD RAMs. So the 68k CPU core should probably implement the instruction correctly and leave to the bus arbiter to break it as needed.
This is actually done properly already. The M68000 core in Exodus properly implements the TAS opcode, it's the VDP actually that breaks this. The VDP asserts the LWR, UWR, CAS0, RAS0, and OE0 lines in response to bus operations being initiated, but it doesn't update them during a read/modify/write cycle, it only evaluates the output when the AS line is asserted. As Exodus actually emulates CE line assertion behaviour like this, and the VDP and bus arbiter correctly evaluate and raise their output lines for each bus operation, I'm free to "break" this in the VDP core, without having to mess with the M68000 core. If you wired the RAM to be driven by CE lines from another device which supported TAS, or you wired the 68000 output signals to the RAM directly using another kind of mapping, you could fix TAS on the Mega Drive. You can actually do this just by editing the XML module file for the Mega Drive right now. If I add proper support for other Mega Drive versions in the future, I'll have different module files saved for various system variations that handle quirks like this.

flamewing
Very interested
Posts: 56
Joined: Tue Sep 23, 2014 2:39 pm
Location: France

Re: Exodus 2.1 release soon (Now available!)

Post by flamewing » Wed Sep 12, 2018 9:30 am

Nemesis wrote:
Mon Sep 10, 2018 4:55 am
This is actually done properly already. The M68000 core in Exodus properly implements the TAS opcode, it's the VDP actually that breaks this.
Ah, sorry, I was mixing up my emulators: it is actually higan which does it incorrectly by breaking the tas instruction on the 68k core.

Also interesting is that it is actually the VDP that breaks tas, not the bus arbiter.

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: Exodus 2.1 release soon (Now available!)

Post by HardWareMan » Sun Sep 23, 2018 6:08 am

Hi! Did you planed to add ladder distortion to the YM2612 core output? We already discover it in the "New Documentation: An authoritative reference on the YM2612" thread. Also, what you think about the Nuked-OPN2 core?

My 2 in 1 Battle Toads (and Double Dragon) Sound Trax PD ROM crashes the Exodus 2.1, while normal runs in Exodus 1.x. Didn't check Exodus 2.0. The empty cmd.exe window with "Press any key to continue..." appears twice.

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

Re: Exodus 2.1 release soon (Now available!)

Post by Nemesis » Wed Sep 26, 2018 12:27 am

There's definitely work to do on the YM2612 core. It was already at a pretty advanced state though, so seeing as it's just me working on Exodus right now, I'm going to be focusing on other areas first that are in greater need of attention. I like to independently construct hardware tests to verify new information rather than take it at face value, so it'll take me awhile to incorporate these changes. I will swing back around to this in the future though. The YM2612 core in Exodus is in a good state, and will be easy to improve and change. The Nuked code looks interesting, I'll definitely take a close look at it when I'm doing YM2612 work in the future. I won't be adopting a core like that as-is in Exodus, but I can compare behaviour against it and look for features I don't currently implement. Seeing all the test register behaviour mapped out clearly for example is really useful, and it'll make it simple to incorporate those features in Exodus.

I couldn't download that file you listed, link seems to be dead? I tracked down the ROM from another website, but I'm not sure if it's the same as the one you were linking to. The one I found ran fine in Exodus 2.1 as far as I could see. Could you upload the file to another location?

Post Reply