I was waiting with blog update for some good news - but those will be delayed so I guess I will do another boring status update.

New Makaron version not ready yet. I know, I promised a release some time ago but there is little point in fixing bugs in what is essentially a broken design.
The test versions released so far were only supposed to tell me what works and what does not. Now that I know more about what I really want and how, I will need to re-write some parts of the emulator. This takes time and is often boring since I have to break things first and make them work again...

In the meantime I've run some tests on my new NAOMI2 box. Suffice to say I can dump cart games now without having to desolder anything, and that also includes the secure FLASH which stores the serial number. This method has not yet been extensively tested (only one game dumped) so hold the champagne :)

Well, not really much to say but I figured a status update would be nice :)

Yuki dumped more GDs and again I find myself so behind with testing... It simply never ceases to amaze me just how many games were released for Dreamcast in Japan. Sadly, only for that very region, never to be translated and sold worldwide. It's true that so called dating sims are not very popular anywhere else but you can't go wrong with titles like Happy Breeding.
Asked about it Yuki decided to be somewhat cryptic and replied "Game that does love as girls".
NOW I JUST GOTTA SEE IT, PERIOD :P

This was supposed to wait 'till the next release but quite frankly, with things as they are now, I'm not sure when exactly that will be. So I'm happy to annouce that I got some help from TOSEC project guys (okay, Maddog mostly) and in future Makaron will recognize all TOSEC GDI dumps for the purpose of having per-game settings.
It's really great that projects like these exist. It'd be pretty much impossible for me to get my hands on so many games - because secondhand or not, I simply can't afford to buy all those GDs myself.

The VMU emulator is now moving to the final pre-release phase. This is how it will look like:





And this just in, Alex gave me heads up on his new blog page.
Not only he dumped a cart game, he got it working with Makaron too :)

It's really nice to see that people find Makaron useful, especially that there are other emulators out there as well. With GUI and all :P

There's a small update to the PAD plugin, which can be found here.
It fixes a problem with Acquire call failing on certain systems and causing the config window to close immediately (pretty obscure foreground-only access vs window creation sequence issue). More importantly though there was a crash reported by some users, happening when OK button was pressed. Turns out this would prevent the new configuration from being written to the INI file.
If anyone's interested, this is a piece of code equivalent to the offending one. See if you can spot the problem :)

  vector<Box>::iterator i;

  for (i = boxes.begin (); i != boxes.end (); i++)
    if (!i->valid)
      i = boxes.erase (i);

I've been trying to add some preliminary GUI for configuration purposes and I have to say I'm not doing so great. It's really annoying to have to fix various random pieces of code every time I change my mind about how the GUI should look/work. At this point I belive I'd be better off creating an empty project with only the GUI and then merging the thing with Makaron once I'm happy with it. Though actually it'd probably end up the other way around, that is moving emulator internals to the GUI project :)

Anyway, I've also been experimenting with various things including SH4 recompiler. That last idea didn't quite live up to my expectations, I guess I would have to rewrite it whole in order to gain any significant speedups - and I've neither time nor motivation right now.
One of my ideas was to introduce the ability to change dics in the GD drive without having to open the GUI menu. I gave Yuki a modified version where you can choose one of 4 "GD slots" by pressing keys 1 through 4 - at any time really. Kinda neat and for now saves me the trouble of implementing the switch between window and fullscreen mode - though it will be possible in future of course.

So... what do you guys think? GD slots a good idea? It will interfere with the "classic method" a bit (and you need to assign images to slots first) so having both at once might be difficult to do and/or understand. Also, how many slots and how to switch between those? Keep in mind some games require keyboard emulation so it's best to either limit the key usage, or figure out a clever system which would allow to lock the keyboard exclusively for emulation or GUI - and again, how to switch between those modes?

If there are any good ideas for the GUI functionality then I'm all ears. Menu layout, key mappings, stuff like that. I have to say I don't much like how nullDC menu works. It's great if you need to change only one or two options but for anything more you have to constantly revisit the menu bar and navigate from there. I find that all-in-one config window in pSX more... ergonomic? Though it can be a little confusing with so many things in one place.
With a decent GUI there would be no need for the on-screen F12 menu I suppose?

Oh and BTW there is provisional support for save-states now. With all the changes I make it's not stable enough to be used, but this functionality too will require key mappings or something for easy access.



UPDATE: I've only now realised that the last screenshots posted were made in December...
Some people are working on Pandora port, some are trying to get Atomiswave working, and I've been busy with this :)
Once again, great many thanks to Yuki for hunting rare VMUs and special savefiles, and to all those people who helped me out with VMU BIOS dumping (you know who you are). Took me a while :P

VMU-E and VMU-J BIOS:




"Cho Hatsumei Boy Kanipan - Asonde Kid DC DC":



"Zen Nippon Pro Wres - Giant Channel":




"Atsumete Godzilla - Kaiju Dai Shuugou":



"Gamera Dream Battle" and "Mothra Dream Battle":




"Atsumare! GuruGuru Onsen - Chiisana Kotori Uranai":



"Pinta Quest" - Skies of Arcadia minigame:




And there's more where this came from :)

I'm busy. If you want a more detailed explanation you will have to come up with something on your own :)

Work on Makaron is progressing, albeit somewhat slowly these days.
Most noteworthy bug squashed lately: Skies of Arcadia and getting stuck in narrow places - should not happen (so often?) anymore. Finally got around to fix FLASH erasing commands as well, this should make BIOS boot games even if you fail to set the clock properly. For those less fortunate who find Dreamcast BIOS menu just too confusing.

Today I bring you another input plugin - this one is meant only for X360 controllers and uses/requires XInput. Unlike DirectInput (broken by design by Microsoft), XInput allows both triggers to be independent and have full range readout.

Download it here.

No support for hot-plugging - basically you need all controllers (that you wish to use) have their respective IDs assigned before you launch Makaron.
There is no setup or configuration of any kind. All you need to do is put X360PAD.dll in "Wtyczki" folder and edit Maple.ini to use it instead of MakaronPAD.dll.
Controls are mapped to follow original Dreamcast layout. BACK, LB, RB, right analog stick and buttons under the sticks are simply ignored. Triggers and analogs have suggested deadzones - tell me if it's too much (especially triggers).

Since I have no control over how Windows will assign the IDs, I made it like this: the first port in Maple.ini to be assigned the X360 plugin will use first available controller. And so on - in theory, not tested with wireless or multiple devices :)

No force feedback yet. If you've used FF before with another controller you might want to switch back to double-VMU configuration for now.

By the way, one of the features I'd like to have next is the ability to map unused controller buttons to specific emulator functions - like pause on BACK and stuff like that. If you have any other ideas, tell me.

More screenshots. Never enough of those :P






I finally figured out what prevented SQ remapping from working on NAOMI games - it's no longer necessary to set MMU=1 and use full address translation.

Yuki dumped another NAOMI game, Moeru Casinyo. I had some problems getting it to run at first - I chased a non-existing bug in the TA core because I hadn't realized it needs full MMU for address translation :)
Doesn't look like it's Windows CE based though and that is a good thing, it runs faster than typical Dreamcast games based on multitasking CE kernel.




In other news: I've built 33,8MHz crystal oscillator for the GD project. It works but the output is rather ugly. I suppose 74HC series is simply not fast enough at 3,3V... lets hope 74AC will perform better. If not then I'll have to experiment with drive limiting resistor.


UPDATE: Seems there are more NAOMI games like this. Strange. I'll need to investigate, maybe it'd be enough to remap some of the memory space (this will at least help Ikaruga).





Oh yeah, I forgot to mention there is a bug in the INI parser: it skips the very last line of the file. One of the effects of this bug is not being able to boot any images if the "image =" entry is on the last line. The workaround for now is to always end the INI file with an empty line.

New version awaits you on SendSpace :)

This time the package includes NAOMI emulator as well. And I've modified the code a bit, let's hope this will make the Data Execution Prevention exception go away.
Both executables can now reside in the same directory, but because of that there are some minor changes:
* Dreamcast BIOS/FLASH filenames must now start with Dreamcast_ prefix.
* NAOMI BIOS filenames must start with NAOMI_ prefix.
* The main configuration file for NAOMI emulator is now called NAOMI.ini

And yes, you still need to extract and decrypt any NAOMI games you wish to run from the GDI image. It's also possible to extract them from CHD files.

Remember to install the runtime libraries for MSVC 2008 SP1 if you get those silly "not installed correctly" errors.


UPDATE: It seems I forgot to put the newly compiled Makaron executable into the package. Sorry :)
Redownload, I've updated the link. Also, if you add "aniso = 0" to the Settings section it should disable anisotropic filtering. Not really tested.


UPDATE 2: To clear some confusion - executables in the package are the MT (multi-threaded) ones, even if the names don't suggest it. I don't think I will be making separate ones for single core/CPU systems anymore. There are several reasons behind it:
1) More and more people have multi-core PCs now (they don't even sell E6600 anymore!)
2) MSVC links against MT libraries by default (probably because of (1), not to mention single-threaded versions are kinda frowned upon)
3) MT executables can still be run on single-core systems (the performance drop due to locking used isn't that big and frankly older PCs struggle with Makaron anyway)
4) I have 2-core CPU myself so obviously I want to use its full potential whenever possible (I actively develp Makaron that way, so testing non-MT version is a waste of my time)

If in doubt, check the debug output window or the logfile. It should say "Version Test 11/1 (MT)".

Also, there is a silly bug that causes the FLASH files to be written back to disk without the "Dreamcast_" prefix. Keep that in mind in case you're unable to set the clock properly - you will need to rename the file yourself. I already fixed this so it will work as expected in next version. And yes, the digital filering isn't yet perfect as it seems to mute BIOS menu sounds too much.

Still busy. Good news is I've been forced to add FEG emulation to AICA recently and now I dare say it's finally complete. Filtering isn't really used much but Shenmue needed it for the in-game music.
Since I'm still in the woods with other changes I suppose I could release another test version of Makaron with what I have now. Not much of that I'm afraid:

- Fixes to TA I've already wrote about (ie Excelica)
- Revised VMU plugin, it is now possible to save in WinCE games
- FEG/digital lowpass filter emulation in AICA

Stay tuned.

Also, some random pictures. If you know what it is you can start drooling now :) This will take time mind you, but maybe I'll have something working before 2009. Still waiting for the Altera board to arrive...





UPDATE: Makaron T11/1 is out.
You can grab it from RapidShare. It seems they now have a download limit system - so in case it kicks in you can try SendSpace as an alternative.

Now, pay attention:
* It's only the Dreamcast version for now.
* It has been compiled with Microsoft Visual C++ so you might need to install the runtime libraries to get it to work. It's only 4MB and you can download it from Microsoft.
* Hit F8 to exit the emulator at any time
* You can now use Pause/Break key to pause/resume the emulation

Minimum hardware requirements have also changed:
* Processor must have SSE support
* Graphics card must be at least Shader Model 2.0 compatible

By not having to support ancient Pentium 2s and Durons, and Radeon 8500, I can make the code simpler and maybe a bit faster too. That old hardware wasn't going to run Makaron at any acceptable speeds anyway :)

I've moved Makaron project to Microsoft Visual C++ 2008. Express edition for now as it's free and has about all the tools I need (resource editor would be nice though). Too bad I won't be using a profiler anytime soon - it's only present in the Team suite and that's a bit out of my price range :) Maybe I could use CodeAnalyst, though on Intel hardware it can only do timer-based analysis. But hey, this is still about as good as gprof and it's also free, whereas VTune prices start at 700$ - and that's just a licence for the basic module.
You know, it's funny but I also liked GPU ShaderAnalyzer better than NVidia tools. It's not as sophisticated but also easier to install and use. Get a hint, Intel and NVidia :)

There weren't too many problems with moving to MSVC. Mostly I had to switch to different alignment and structure packing semantics. That and some inline assembly had to give way to more generic C code - it was only worthwhile when using AT&T syntax with clobbered register hints. The YUV converter is now using MMX/SSE2 intrinsics (as it was meant to but I had no choice but to use assembly under MinGW 3.4.5).
All in all, it compiles and works. I'm still using controller and keyboard plugins done with MinGW but that will soon change as well.

I've also moved to Unicode - that was done even before I switched compilers though. The INI files can now be encoded as ANSI (that's ASCII plus current Windows code page character set), UTF-8 or (preffered) UTF-16. Little endian of course, as all x86 architecture is. The format will be autodetected based on the BOM and so Unicode files must start with one. Notepad will take care of that for you.

So far there are only two downsides to MSVC: it comes with standard STL headers only (so no slist for example) and running the executable requires one to download and install a redistributable package from Microsoft. The latter is only 4MB so it shouldn't be a problem.
As for STL, I've been experimenting with it for some time now. My own classes are not that universal and not really faster either. I did port some of that code back to plain C to use on Dreamcast, but that doesn't mean I need to keep Makaron STL-free forever. There wasn't much point in switching to STL under MinGW, but I did anyway, and I got rewared for that in MSVC. It's debug build helped me find some deeply buried bugs in the way I handled texture lists. Nothing major but still.

What else is new? The YUV->RGB texture conversion performance on NVidia cards should be a bit higher now. It also turns out using PUREDEVICE is not the best idea considering how many state changes I do per frame (even if I do try to limit the most costly ones).

Oh, and thanks to new compiler Makaron is now a tad bit faster. Not much, not always, but I'm getting up to 120 MIPS out of SH4 in full MMU mode where I was getting 90 before. Unfortunately the slower your CPU is the less boost you will see - but still, that's an improvement.

I'm working on something :) I've spent quite some time making changes that don't introduce any new functionality to the emulator but were simply necessary. It's actually rather refreshing to go over all of the sources and evaluate what has been already done and what needs more attention.
There are a few ideas I want to try out. Problem is, they sound simple but require a lot of internal changes. Still I belive it's important to test those new ideas because in the past some of those turned out rather nicely, allowing new cool fatures to be implemented. Sometimes you hit a dead end though, like it was with the layer peeling renderer (still it was worth it, I've learned a few things).

Basically I figured out, while trying to implement pausing, that the whole timing system could work in a different way. Both approaches (current and the new idea) have its merits but I can't tell which one is better until I actually try both. I should be done with these tests in a month or so. I'll update this entry should something interesting come up.


UPDATE:
Some long due screenshots, from both NAOMI and Dreamcast. Pretty rare titles :)








UPDATE 2:
Jingi Storm The Arcade is now playable. I'm not so sure the fix I made is what the hardware really does, but hey - it works.





UPDATE 3:
In other news, GCC/MinGW is starting to annoy the hell out of me. I found another case of __attribute__ ((aligned (16))) not being honoured (or rather, it has found me) - and in version 3.4.5 no less. Until a few days ago I belived 3.4.x branch to be virtually flawless, especially after all the trouble that series 4 gave me. Not anymore.

At this point I'm seriously considering Microsoft compiler. Again. Those alignment bugs and GCC go way back and most of them have still open (not to mention "new") status. I'm pretty tired of waiting for the GCC team to show some love for Win32 platform. It's their choice not to and so mine will probably be to change sides.


UPDATE 4:
Boobs! Er, I meant to say Slashout. You gotta love those undocumented hardware registers...