Master System support possible?

Moderator: Nemesis
Master System support possible?
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.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.
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.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.
Timer was a failed attempt to "measure" code timing. A very raw way to profile code.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?![]()
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 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.
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.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.