Questions about emulating different Genesis models

Official support forum for the Exodus Emulation Platform

Moderator: Nemesis

Post Reply
Trivial Man
Newbie
Posts: 3
Joined: Tue Sep 22, 2015 7:54 pm

Questions about emulating different Genesis models

Post by Trivial Man » Wed Sep 30, 2015 4:26 am

I've been following this project for some time, and though I don't know much about programming or actual console hardware, I have some questions about precisely those two things. Please correct me if I make any mistakes in my assumptions.

As I understand it Exodus has programming written to simulate components of consoles, like the various chips and processors and whatnot inside it. To actually emulate a console it then has a separate bit of settings written to explain how these components are connected to one another and what information is communicated between them. The settings file is thus analogous to the wires and solders physically linking the components in a real console. But the programming itself doesn't give a hoot what information it gets or outputs, so these settings could be written to connect any which way. This makes sense because the wires and whatnot could also theoretically be connected any which way, even though most of these wrong ways would just result in a fried console.

So if that all is true, then how will/does Exodus handle emulation of the different models of Genesis/Mega Drive? I have been under the impression that the Genesis has had numerous rereleases with differing hardware, not to mention weird variants like the Nomad or the LaserActive that can play Genesis games but probably do so differently than the base console. Will there be multiple versions of the console emulated in Exodus, or is this simply too time and cost prohibitive to pursue? Furthermore, would any differences in these console variants/rereleases even be noticeable to an end user either in real life comparing consoles or through Exodus?

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

Re: Questions about emulating different Genesis models

Post by Nemesis » Thu Oct 01, 2015 11:48 am

A very astute question. Let me answer it first of all, by letting you know it's even more complex than you think. In reality there are a lot more "versions" of a given system than just the ones that are somehow marked or named differently. There are often hundreds of components that make up these systems. These components go through their own revisions. Hitachi might make a chip used in a Sega console for example, and they will have their own fabrication runs of that chip. Between fabrication runs, that chip may be "tweaked". Sometimes the part number may be changed, other times not. Sega will be buying these chips in batches, but when they get a new batch, the new chips might not be quite the same as the previous ones. Even when a company is actually making their own chips for a device, the same thing happens. Also, companies often manufacture in different regions concurrently. Different brands or versions of a given component may be used in the different production facilities, depending on what's cheaper/easier to source in a given region at that point in time, and what's already on hand. All these different combinations of components are really their own "versions" of a system in their own right. For a system like the Mega Drive, there are probably hundreds of different combinations of parts that have been produced, and this is just the logical components.

So, with all these different hardware versions, how does it all come together and still work like a Mega Drive is supposed to? It comes down to the distinction between a physical system, and a logical system. A Sega Mega Drive is a physical device, which is build to implement a logical model in hardware. Exodus is a virtual device, which is built to implement logical models in software. The logical model is what is important, because that produces the end result. The physical or virtual model is just a "means to an end". A physical system can use any set of components it wants, and work in any way it wants. As long as it accurately produces the correct logical model for the system, it doesn't matter. The overwhelming majority of revisions to a system are at a physical level, but don't affect the logical operation of the system.

The way this all works is the idea of compatibility, where two given devices may not be exactly the same, they're considered compatible if they're able to perform their task in emulating the logical model of the system in the intended manner. Of course, there are times that differences in components DO produce differences in the logical model. Performance for example. If a newer revision of a chip makes code execute faster for example, or a component to be able to process input more quickly, it's not considered a breaking change, since it's unlikely any existing code relied on things being slower in order to work correctly. Minor bug fixes to components are often welcomed too, without worrying about compatibility problems. There are also often a lot of differences in "corner-cases", especially in undefined behaviour or things that weren't safe to do on the system at all. These kinds of changes are accepted, because nobody should have been doing anything like that in the first place, and ideally these are things that wouldn't have passed testing or certification processes. For most emulators, these kinds of differences wouldn't be seen as important, but for Exodus, they are considered very important.

There are also analog properties to consider, where the logical model is the same, but a component produces, or processes, an analog signal with a different level of quality, or different properties. The audio output filtering/amplification circuitry would be an example here. There can also be differences in video output quality.


So, what does all this mean for Exodus? Exodus still aims to emulate the logical model rather than the physical model, so changes to the physical model, that don't in any way produce observable changes to the logical model, are unimportant. Changing a memory chip from one part number to another for example, where the timing of that memory chip may actually differ, but it's still within tolerance to work the same way with the bus driving it, is an example here. If there is any visible change in the logical model though, IE, something which can be measured or observed to be different by code executing on the system, should be emulated. Also, differences in analog output should aim to be "emulated" as much as possible. I put the word emulated in quotes there, because as soon as we're talking about analog properties, we're really talking about simulating or approximating the result. Usually, this will simply be supported through "filters", IE, video filters and audio filters, usually configurable, to allow the user to adjust the output to something they feel is "right". The TV they were using as a kid was as much a part of this as the system itself was, so everyone has a different idea about what is right in this area.

As a baseline, Exodus primarily tries to emulate the "reference hardware" for a given platform. This would usually mean the first model. This is the one developers got, or close to, when they started writing the first titles for the system. This is the one the documentation was written to describe. This would normally remain the one the development kits are based on for a long time, if not the life of the system. It's often the one to sell the most units (or at least, major revisions are unlikely until later). It's the one you would normally consider to be the authoritative reference for how the hardware was intended to be, and so, that's the one you should generally aim to be emulating. Beyond that, it's good to try and support variations though, as much as they're deemed to be important. How you go about doing that depends greatly on what the difference is. The PAL and NTSC variants of the Mega Drive for example are different hardware. They have master clocks running at different rates, and some hard-wired control lines for several chips are set differently. Exodus supports that by allowing "system settings", where some basic properties of the system can be changed dynamically at runtime. If a difference is that a given chip went through several revisions, and there are some internal differences in the way it operates based on the version, you would normally aim to define a "setting" for the chip, where you can select the revision mode for the chip to operate in. This can be specified in the system xml file, and if it's a change that can be applied dynamically, you should be able to change it at runtime through a debug panel for the chip. If the difference is major, for example, it involves entire chips being added or removed from the logical model (note that two physical chips being merged together doesn't necessarily change the logical model), or if it alters in some major way the connections between components, or the external connections to the system itself, this would involve creating a separate system xml file for that variation.

Right now, Exodus is written to emulate the first revision of the hardware. Ideally, we can expand that over time to support any revision of any chips in the system, and the system itself as a whole. You could produce separate system xml files for each and every named model revision, (IE, MD1600, MD1601, etc), and it would probably be worth doing that if things got to that level. Even without that though, major differences in compatibility could usually be incorporated into the one system, by adding modes to relevant devices that had changes between revisions. This gives the advantage of being able to switch at runtime, while debugging or testing code for example, and check code against a particular revision of a device more easily. All of this takes a lot of time and effort though. First of all, differences between revisions need to be identified and documented. This in itself is very difficult and time consuming. Implementing multiple modes into an emulation core can also potentially be very difficult and time consuming, depending on what the difference is, and the way the emulation core has been written. It's a lot of hours to implement this support, so I'd usually expect if there was enough motivation to do this kind of work, it'd be directed towards something with a bigger payoff, such as emulating devices or systems that are currently completely unemulated. If there was an army of programmers working on this though, you'd certainly have a few working on this. It'd be great to have, just takes a lot of work to get there.

Trivial Man
Newbie
Posts: 3
Joined: Tue Sep 22, 2015 7:54 pm

Re: Questions about emulating different Genesis models

Post by Trivial Man » Thu Oct 01, 2015 3:56 pm

Fascinating. I had no idea there were so many potential undocumented changes within the same advertised console model. And by fascinating I mean, what an archival nightmare. I really began wondering about this because I recalled you were interested in accurately emulating the undocumented corner-cases, but I wasn't sure how one would go about doing this when there were so many (more than I thought even) different hardware revisions. I sort of knew that emulating each named model revision was too time consuming without enough payoff, but I also wasn't sure how else you could reconcile those possible differences in behavior.
Nemesis wrote:Right now, Exodus is written to emulate the first revision of the hardware.
So this leads into my next questions. Are there any well known performance enhancements or bug fixes from later models not present in the first revision? I mean, logic suggests that later versions are technologically superior, but are there any outstanding examples of this? If so, will any of these differences find their way into Exodus despite not being based on the first revision of the hardware?

ComradeOj
Interested
Posts: 27
Joined: Sun Jun 28, 2015 4:18 pm
Contact:

Re: Questions about emulating different Genesis models

Post by ComradeOj » Thu Oct 01, 2015 7:22 pm

Trivial Man wrote: So this leads into my next questions. Are there any well known performance enhancements or bug fixes from later models not present in the first revision? I mean, logic suggests that later versions are technologically superior, but are there any outstanding examples of this? If so, will any of these differences find their way into Exodus despite not being based on the first revision of the hardware?
Not nemesis, but the VA2 (but not the VA1) model 3 fixed a bug in the 68k's "TAS" instruction. The Test And Set instruction checks if a given byte of memory is all 0s, and sets a 1 if it is. At least I think that's how it works.

On every other version of the Genesis, TAS doesn't do anything. On the model 3 VA2 however, it works as intended.
Visit my web site at http://www.mode5.net/!

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

Re: Questions about emulating different Genesis models

Post by Nemesis » Fri Oct 02, 2015 6:25 pm

So this leads into my next questions. Are there any well known performance enhancements or bug fixes from later models not present in the first revision? I mean, logic suggests that later versions are technologically superior, but are there any outstanding examples of this? If so, will any of these differences find their way into Exodus despite not being based on the first revision of the hardware?
One thing to understand is that revisions of a console are rarely about making the system better. Hardware revisions are usually about making the system cheaper to manufacture. Lower manufacturing costs = more profit. We've seen exceptions to that rule in recent years, with high failure rates from some consoles requiring revisions to ensure the viability of the platform, and prevent further losses from failures within warrants periods, but that was never a problem "back in the day", when systems were passively cooled, had simpler power requirements, and often had no moving parts. Actual hardware failures aside, if there are limitations, bugs, or flaws with the first release of a console, it doesn't really matter if you fix them in a later revision, because the simple fact is that most people will have bought the first version, and any game you release has to work on the first revision too, so fixing a bug doesn't really change anything for anyone. If a feature was buggy on release, you've got to work around that for the lifetime of the system.

As ComradeOj mentioned, the TAS instruction for the M68000 didn't work properly for anything other than the second revision of the Genesis 3. It wasn't fixed intentionally though. The TAS instruction was never "supported" on the Mega Drive platform, nor was it important to do so. The TAS instruction is designed for a shared bus situation, where you have two or more processors who want to synchronize access to a common resource. The TAS instruction allows you to do an atomic read-modify-write operation to a boolean semaphore in memory, similar to the CMPXCHG opcode in x86. The thing is, this opcode uses a unique kind of bus operation not used by any other opcode. The way the VDP was involved in generating some control lines for the system RAM prevented the TAS opcode from performing its write step, because the VDP didn't support that bus operation. It would have been fixed by accident in that model of the Genesis 3 when all the chips had been integrated into one mega-chip, probably because the embedded VDP core was no longer used to drive any control lines and the M68000 was driving them directly, making this work again. At any rate, this opcode was never useful in the Mega Drive, because even though the Z80 was a second processor, and it could share the bus with the M68000, it didn't have a corresponding opcode to perform a read-modify-write, so there was never any way to use the TAS instruction to achieve its intended purpose, which was efficient synchronization between multiple processors.

Apart from the TAS instruction, there are differences in the delay times for the YM2612 chip, and its embedded YM3438 counterpart, which was used in the Mega Drive 2 for example. The delay timing hasn't been fully documented for either chip at this stage, so the numbers aren't known, but there are differences there. The audio output also has different quality and properties, due to a different DAC used for these two chips. I suspect there's also differences in the timing of calls from the Z80 bus to the M68000 bus and vice versa on the Model 2, and probably some variations between other systems too. This is untested and unknown though. We do know that the VDP (315-5313) had at least one marked revision, with the 315-5313A, but I've never confirmed a difference between the chips so far. The Mega Drive also gives different results when reading from unmapped memory regions. I've also seen different variants of the M68000 and Z80 chip used between system revisions, and I'm sure there's some timing differences in them. The Z80 in particular is a chip with an abnormally large amount of undocumented behaviour, which can, and does, differ between manufacturers and revisions (of which there are many). I know of differences in the way the CRAM in the Nomad responds to port access in the Sega Nomad. There are also differences around the size of the internal VSRAM in some of the integrated versions. There are also relevant variations with peripherals too, which form as much a part of the system as anything else. The 6-button controllers have major variations in their delay times for switching which groups of buttons are being read. I've seen variations of almost 50% within the same model of controller from memory, and between models, all bets are off.

I've asked others in the past about known variations between hardware revisions. There's a topic about it here:
viewtopic.php?t=977
Not many answers back in the end. The simple fact is, there are still a lot of unknowns, and getting the answers often requires a lot of time, patience, skill, and specialized hardware.

Trivial Man
Newbie
Posts: 3
Joined: Tue Sep 22, 2015 7:54 pm

Re: Questions about emulating different Genesis models

Post by Trivial Man » Fri Oct 02, 2015 7:34 pm

Very interesting indeed. I had no idea this hardware was still so full of mysteries. Sounds like you have all the equipment and knowledge to solve them, you just need the time. Shame that that's the one thing I'm unable to send you.

In any case thanks for explaining this all. It's been enlightening. Here's hoping one day someone will ask similar questions and you can just point them to the source code and tell them to read the comments to see the differences.

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

Re: Questions about emulating different Genesis models

Post by Huge » Sat Oct 03, 2015 11:54 pm

Perhaps I am being presumptuous here, but there should be a test program that looks for all these details that differ between hardware. Sure, there are a million and one things to test, but it could start with implementing the known differences, and give back numbers that could be used to implement the differences between models (and board types, and internal chips). New test cases could be added as they are found.
There is a huge number of MD owners who could most certainly help with testing all of these, you'd just need to create a way to distribute the workload. C64 emulators managed to implement different SID filters that way (the filter changed pretty much every week of the manufacturing date, someone made a test case that users could record, post back, and new per-revision filters were added to emulators based on that information).

However this is assuming that the differences in question are major enough that they show up on the programming side, and not just under an oscilloscope.

Plus from what I recall, you already have multiple shelves full of Megadrives, so I imagine you already have most if not all board versions - at which point running a quick & dirty tests for yourself on all models would be faster, than to write a polished up code that would return values that can be easily submitted by users. Sometimes automating a task may take longer than manually finishing the task, as all programmers should be aware of.

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

Re: Questions about emulating different Genesis models

Post by Nemesis » Fri Oct 09, 2015 8:56 am

That would be a great test program to have. Part of the problem though is knowing which questions to ask in the first place. As you said, there are a million and one things to test, and unless you already know there's a difference in a particular area, it's likely things would be missed in a test program like this. There is something along these lines that can do the same kind of job though. We need more comprehensive test programs to measure and verify the behaviour of the system based on a set of expected results. These programs can be used to test emulators, as well as hunt for differences between models. I've written a test program for verifying lots of aspects of VDP port access here for example:
viewtopic.php?p=20975
This test ROM showed up a couple of points of difference between hardware revisions. If we had more test ROMs like this, covering all kinds of aspects of the hardware, it becomes much easier to hunt for differences between hardware revisions.

As you mentioned, I do have a large set of hardware at my disposal, but I certainly don't have all the models. I actually don't even have the VA0 Japanese hardware (IE, the very first version) at all, I'd still like to get a hold of that one some day. It's always important to get results from other people for projects like this.

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

Re: Questions about emulating different Genesis models

Post by Huge » Sun Oct 11, 2015 3:48 pm

Oh, I have one of those. Pretty low serial too, 88M 01190. I collect odd hardware for testing too, but I don't have the knowledge to make any, but superficial tests on it, so a test app would be welcome.

Post Reply