Deunan

It beeps in Japanese

Wed, 07 May 2008 14:42:57 GMT

I put my ideas to the test and created a BIOS dumping tool for VMUs. Big thanks go (again) to Yuki who helped me out and run it on several cards.

So far I've collected three BIOSes for J-VMUs: 1.001, 1.002 and 1.005. No luck with my own E-VMU though, I suppose the procedure address is indeed different.
Actually, even J-VMUs have the code shuffled a bit depending on the BIOS revision - luckily the tool worked, more or less, in all cases. Dumps for the oldest versions came out corrupted but were still useful in finding out the correct entry point for the second attempt :)

I'm going to experiment some more on my VMU, but my chances of finding the right address are about 1/16000. No way am I doing an exhaustive search :)

It beeps, IT BEEPS!

Mon, 05 May 2008 12:27:15 GMT

I've got good news and bad news.
Bad is I've not touched Makaron sources for weeks now. Guess it needs to ripen some more :) I got to the point where I have two or three ways to solve a problem, and each has it's pros and cons - and I just can't decide which one to pick. But I will get to it, eventually.

The good news is Yuki bought some VMUs with games on them and it got me pretty interested. I'm going to try and emulate standalone VMU now. Just think, since it's rather simple and low-spec I could easily use SDL to make it work. Hell, ScummVM uses SDL. I'm somewhat familiar with the API too (my old MOD player used SDL for both sound output and visualisation).
That would make a VMU-on-PC emulator. But guess what, there are SDL ports to Dreamcast available too! So the project could be made to compile and run on DC as well. And at this point it would run under Makaron of course. I mean, how do you say no to VMU-on-DC-on-PC emulator? :]

The main problem right now is VMU BIOS. Apparently it's not possible to access ROM memory directly while running from FLASH, so no easy way to dump it. KATANA dev kit comes with VMU BIOS but I'd rather not rely on it. You know, copyright stuff and all. Also, I'd like to have an English one from one of my own VMUs.
Just yesterday I've came up with a plan to hijack one of the system calls to read the BIOS area for me. This is a fragment of BIOS disassembly:

1966- 61 00    | L1966:       PUSH   ACC
1968- c1       |              LDC    
1969- 13 66    |              ST     VTRBF       ;write to work RAM
196b- 71 00    |              POP    ACC
196d- 73 00    |              DEC    ACC
196f- 61 00    |              PUSH   ACC
1971- c1       |              LDC    
1972- 13 66    |              ST     VTRBF       ;write to work RAM
1974- 71 00    |              POP    ACC
1976- 73 00    |              DEC    ACC
1978- 61 00    |              PUSH   ACC
197a- c1       |              LDC    
197b- 13 66    |              ST     VTRBF       ;write to work RAM
197d- 71 00    |              POP    ACC
197f- 73 00    |              DEC    ACC
1981- 61 00    |              PUSH   ACC
1983- c1       |              LDC    
1984- 13 66    |              ST     VTRBF       ;write to work RAM
1986- 71 00    |              POP    ACC
1988- 81 07    |              ADD    #$07
198a- 53 02 d9 |              DBNZ   B,L1966
198d- a1 03    |              SUB    #$03
198f- a0       |              RET

See, by calling 0x1966 with my own TRL, TRH, B and ACC I could use it to LDC any BIOS area into work RAM. The only problem here is I'm assuming the BIOS that is going to be dumped has this procedure at this very address. Seeing how listing comes from 1.004 version and my VMUs are 1.005, it might not be that simple...
By the way - calling into any arbitrary place in ROM is easy, the hard part is getting out :) But that can arranged as well. Included below (may not be so obvious at first glance) is a public syscall entry for FLASH write routine. It's unused, as it does exactly the same as 0x0100 syscall:

0108- 20 2e c5 | writeFlash2: CALLF  L2EC5
010b- b8 0d    |              NOT1   EXT, 0            ;execute code in other bank
010d- 21 01 0b | L010D:       JMPF   L010B

What I need is to push 0x010b address on stack and JMPF to 0x1966 while switching banks to ROM. The BIOS procedure will then read ROM memory, store it in RAM and RET to this NOT1 above, effectively switching back to 0x010b in FLASH, where I'll be waiting for it :) It's brilliant! IT'S SCIENCE :)

The other way to do things is to go HLE. There are only several public entry points in BIOS code, so it's rather easy. Calling anywhere else is pretty risky so I'm betting no game will ever try that.

So far I've determined that Yuki FLASH dumps are good and working, so I can start with that right away.

Prima Aprilis

Wed, 02 Apr 2008 12:36:55 GMT

Originally I intended to "disappear" for a week (just like last time) and have my fun reading the comments, hate mail and cursing. Unfortunately not that many sites picked up on this idea of mine and so I'll have to cut it short. Pity.

I especially enjoyed the threats to move to another emulator. How silly is that? Folks, you're free to do that anytime you want and you don't need my permission. Really.
Let's face it - most of you got angry because you took free Makaron for granted and now I was about to take it away from you. You got all cozy thinking you somehow deserve it. Well... think again.

Having said that - hook, line AND SINKER, people :)

UPDATE: Makaron Test 9/4 for those who like to experiment.
I'd urge you to wait for T10 as this is a bastard mix of current (broken) dev and older T9/2. I got it to compile and run but that's about it - not tested. It does include the DMA changes that should make WinCE games more stable but I make no guarantees.
It's still using old GD code which means (with the DMA changes I've made) it will most likely break Street Fighter Alpha and some other games.
Use the supplied plugins and Maple.ini to get vibration support and use F12 menu to enable VMU LCD overlay. Also, make sure to change sorting mode because it defaults to "Alternate" which turned out not to work for some games.
This release goes beyond experimental, it's downright partisan :) I'm not kiding you - unless you like 'em rough stay clear. I'd like to have some feedback on vibration support for upcoming T10 and that's the only reason it exists.

PS. No changes to full-screen mode in this one, and no support for 16:X aspect ratios. And Yuki, stick to your T9/3 for now :)

UPDATE 2: Okay people, here's what you need to have vibration:
1) T9/3 or T9/4 Makaron executable
2) T9/5 or T9/6 MakaronPAD.dll
3) Maple.ini edited so that MakaronPAD is being loaded instead of MakaronVMU for Slot 1 or Slot 2 on given port
4) Gamepad capable of vibration
5) Game with PuruPuru Pack support (you might still need to enable it in game options)

If you can't get T9/4 to run at all with supplied Maple.ini (crashes with an error), but it does work if you modify it to have VMU (or nothing) instead of MakaronPAD in the Slot1/2, it's a problem with my code not doing the right thing with your pad. Another easy way to check is to use Maple.ini (and plugins too if nothing else helps) from T9/2.
If it does run but you get no FF effects it could be the game doesn't use it or needs to have it enabled first. If you're positive everything is as it should be, it's probably my code again. A fast way to test if the plugin is loaded as it should be:

HOLLY/Maple: 0x20: Makaron controller (0x00270101 / 0x00540905)
HOLLY/Maple: 0x01: Makaron VMU (0x00030201 / 0x00540904)
HOLLY/Maple: 0x02: Makaron controller (0x00270101 / 0x00540905)
HOLLY/Maple: 0x60: Makaron controller (0x00270101 / 0x00540905)
HOLLY/Maple: 0x41: Makaron VMU (0x00030201 / 0x00540904)
HOLLY/Maple: 0x42: Makaron VMU (0x00030201 / 0x00540904)

See, the 0x02 address of port A is using PAD plugin instead of VMU.
BTW, don't try to be too smart and have 2 VMUs and a PuruPuru Pack together. Though it's possible to assign addresses 0x04, 0x08 and 0x10, no real Dreamcast device has more then 2 slots and most games will not recognize such configuration. You can try your luck with homebrew KOS/Linux/BSD software, those usually don't have such limitations.
For those of you who never had a DC controller in their hands - PPP will fit in Slot 1 but it's big and will prevent you from using VMU in Slot 2. Not to mention only Slot 1 VMU LCD is visible (in Makaron too) so it's best to stick PPP into Slot 2.

And another thing - you'd be suprised how broken gamepad drivers can be. I've got two and each had it's nasty suprises (and I've yet to try PS2 Dualshock USB interface). Also, force feedback features can vary from very basic "rumble" ones to a real force working against your moves. It's not that simple to get those more complicated gamepads to do simple vibration it seems...

If I were a rich man

Mon, 31 Mar 2008 18:47:40 GMT

At least some of you must realize that developing Makaron is a time consuming process. Time I could very well be spending doing things that bring me money. I have expenses you know, mostly PC hardware and software but also Dreamcast games and other stuff (like a new oscilloscope, as the old one died on me sometime ago).
I'm happy people use my emulator and find it useful, but I also belive it's only fair I got someting out of it as well.

Having said that I've came up with an idea of Pay to Play system for Makaron - prepaid style. Makaron will be free to download and try out but to play longer you will need to purchase an activation code. Simply put, in exchange for money you'll be given a limited time to use my emulator. Once that time is up you'll need to pay again, very much like you would for a cell phone number.
Payment options will include credit cards and other common money transfer services, but I haven't yet decided on the rates so it'll take a few days to set everyting up. I will be done with the activation code shortly too.

~~This is the last free version: Makaron T10.~~

UPDATE: I've changed my mind - I'm going to start with payment system right now. If you've managed to download the free T10 then consider yourself lucky.

Time off

Tue, 25 Mar 2008 11:29:47 GMT

I knew there was a good reason for not touching the GD-ROM code. But I did, and as it stands now it's pretty broken - I will need to redesign it quite a bit.
There are several major problems to solve, all tied to multithreading. Unfortunately I don't really know how to fix them. Or rather, I do, just haven't come up with an idea I feel like implementing. I'd rather spend some time thinking about it and do it right (well, mostly) than throw a ton of nasty patches in. I might actually have to pull out a drawing block, some pencils, and start designing it on paper first. This is a bit new to me, not being able to easily cover for all possible cases in my head. I guess that's MT for you...

I hope to release something in the first week of April. If the new GD code is not ready by then, I'll revert to the old one. I want to see if vibration works for other people too. By the way, I haven't done a single thing during holidays :) I blame Knurek. And Shin Megami Tensei: Lucifer's Call he told me about. But mostly Knurek.

Goodies! #3

Mon, 17 Mar 2008 20:52:23 GMT

Another batch of pictures. Seems like people enjoy them, and I have to run every GD image at least once to get MD5 and see if it boots at the very least, so why not capture few screenshots along the way?

My Merry May is another one of those titles that go above and beyond simple VMU animation. I have to say SEGA idea behing VMUs was simply brilliant - too bad they had to make them cheap and so two CR2032 lithium cells last only what, 3 months? Assuming you do not play on your VMU or else it's a week tops.
That reminds me - is there a good VMU emulator out there? Preferably one that runs on 2000/XP systems and doesn't look like 16-bit Windows 3.1 application, but I'll settle for anything that works. No KATANA dev utils please, those aren't free, or even legal.

This is Exodus Guilty Neos. Don't ask me. Title aside, it has nice graphics - those sharp edges seem out of place at first but soon you get used to them. I think it gives the game less cartoonish, more comic-like look. Oh, and it seems Exodus doesn't like alternate sorting mode much - some texts go missing. Too bad, I guess only D32_FLOAT_S8X24_UINT format can save us now. But that's DirectX 10 and up. I'd tell you to petition M$ to create DX10 runtime for Windows XP but we all know once you earn some fifty billion dollars or so you just don't care that much about puny hyu-mans anymore :)
These screens also show you can easily switch to and from built-in Internet browser (no actual modem/BBA emulation yet), and that PuruPuru pack is being recognized.

And now time for Giant Gram and some sweating masculine torsos. What's not to like? Feel free to watch, I'll be waiting at the next paragraph.

Not exactly my taste either, but it's a progress :) Canary has one long, boring intro let me tell you... You get served with centered lines of white text on black screen for several minutes - now this would good for building atmosphere in some dark cyberpunk but not this game?!

Some folks dancing. Sort of. Wait, does this prove people walk on their hands on the other side of the planet?
Now this is funny. SF Alpha is called Zero in Japan. Who knew? Not to mention this is a special version (full name Street Fighter Zero 3 - Saikyo-Ryu Dojo for Matching Service) and the plain one won't boot. Some SH4 bug it seems. This should be easy to find, and let's hope easy to fix as well. Won't be so funny if it turns out to be another GD-DMA problem, but at least it's easy to spot and trips Makaron every time.

Hunting musca domestica

Fri, 14 Mar 2008 00:38:26 GMT

First Kiss Story can't be fixed because it's not a bug that it doesn't show overlayed text and images properly. It's simply another case of 32-bit float to 24-bit integer Z-buffer resolution loss. Fortunately it can be worked around - so now sorting mode can be switched to 'alternate' for games that require that. I'm trying to determine if this can be made default setting, or will it break other games.

Another fix and Chocolat - Maid Cafe Curio doesn't cut off bottom part of the picture anymore - well aren't you glad, huh?

Something for soccer fans. Now, these games have some ugly sorting/priority issues but nothing can be done about that right now. Hey, at least they boot and play.

A flight simulator where you don't get to shoot anything down. Now where is the fun in that? :) Anyway, due to slight FPU inaccuracies the plane slowly loses altitude during training mission and might crash before tutorial is over. Should be playable though, because during normal gameplay you have full control and can simply level if necessary.

Baldr Force EXE had same screen size problem as Chocolat. In addition to that there were some DMA issues that caused texture corruption. Fixed.
I've yet to test if this does anything for those unstable Windows CE games.
By the way, vibration works in this game as well. I don't really test for this, but in this case it was obvious since it's used very early in the game and is pretty hard to miss.

Yet another sim - I've got quite a few of those. You'd think those are the easiest to emulate, just some simple 2D/3D. Most of them are like that, true, but some are pretty tough cases :)

UPDATE: Well what do you know, the new sorting mode fixed 18 Wheeler, no more pitch black title screen and such.

And some more goods from Yuki (I'm sooo behind with this stuff now...)

Shake it, baby

Mon, 03 Mar 2008 01:14:19 GMT

- AICA cleanup: done
- Puru Puru Pack (vibration) support: done
- Render to texture: done
- Fixed (again, and for good I hope) missing sound in Project Justice
- Spent 4 hours playing Elemental Gimmick Gear on Makaron :)

Force feedback was tested on Soul Reaver and seems to work. Did I ever mention this game is one of the reasons I moved from simple SH4 recompiler project to full-blow Dreamcast emulator? I simply adore whole series.

Now this is actually Saturn conversion, that's why the graphics look a bit dated. Don't let it fool you into thinking it's old and boring - it's quite the opposite. Runs rock solid too, I've played it on full screen and never had a single problem whatsoever.

And this isn't a game at all, just a movie demo disc - GD though, so Dreamcast exclusive. Kinda sucks they didn't remove the interlace - looks pretty bad on PC monitors. Nothing can be done about that now, it's MPEG stream.

And this apparently is Makaron exclusive for now :) I've only played Interlude for several minutes (can't read kanji, so...) but I've noticed there's lots of nice backgrounds. Plenty of spoken dialogues as well. It's 2003 game so I guess quality is higher compared to similar games for Dreamcast (why, even compressed the image is still almost 1,2G).

I am so sick & tired of cutting every screenshot I make to size... I need a good and free screen capture program. Any suggestions?

UPDATE:

Gunspike seems like a nice 3D shooter - problem is you can't take a decent screenshot, it ends up looking either silly or boring :)

Never7 makes heavy use of VMU LCD. Cool title screen animation aside, it changes displayed face according to game dialogues. Pretty neat.

I've nothing to say about this one. VF3 clone of sorts, fighting games aren't really my area of expertise.

Unfortunately NFL2K is pretty broken right now. It will crash & burn trying to start it's 3D engine - most likely a DMA problem. Guess it's another entry on the TO-DO list...

And yet another shooter. Now, don't get me wrong - I do know a bit about it's unique figthing system. Just not my type of game. Seems like Dreamcast got some pretty original shooters though.

I don't have to tell you the title of this game, now do I? Actually there are two games I know of: Dead or Alive 2 - Shokai Gentei Ban and Dead or Alive 2 - Tsuujou Ban. One is a special edition - unfortunately intro is the same on both and I forgot which is which. Yuki once explained what exactly is different between them but I forgot that too :)

And here's First Kiss Story. Not really playable now as it suffers badly from inadequate polygon sorting. It's not a texture problem - the geometry is there, just not visible right now. If it wasn't for sorting many more games would look like that. Since I'm not doing per-triangle sorting (and I'd rather not do that in any case) I will need to come up with another solution - if only for those few cases that need it.

Thanks for hints on capturing software. I've tried several programs but it seems I'll stick to (Alt-)PrintScreen for now. I've added my own screen capture functionality to Makaron (saves to BMPs) - it captures images before information/LCD is overlayed but will work in both windowed and full screen mode. It's developer-only thingy but if there's a need I'll clean it up and leave it unlocked in the next release.

I've managed to get GDMT code more stable. Not perfect yet, most likely it'll never be and some poorly written games will continue to experience problems. I still want it in though, go watch Gunbird 2 intro with GDMT on and off and you'll understand why :)

Remember that tune

Fri, 29 Feb 2008 19:30:04 GMT

Yuki swamped me with GDs again :) This time I'm going to take it slow and test just a few games a day - it takes way too much time otherwise.

There's a BGM player in Super Robot Wars. And guess what, I found tunes from Gundam W and Evangelion on the list :)

And this little bugger is known as Soukou no Kihei - Space Griffon. Gave me some trouble, trying to execute a write past end of VRAM. That kept crashing Makaron and I had hard time figuring out the cause.

BTW - if you haven't noticed, there's VMU LCD display support now. See, that's the reason why you should wait patienly rather then press me into releasing stuff. Now you'll have to wait for T10 to get that :)
I need to finish GDMT (it's really breaking games now), re-structure AICA a bit to allow for DSP in future, make render to texture work and perhaps add vibration/force feedback. Not to mention DMA engine still has some issues...

Here, fishy fishy...

Tue, 26 Feb 2008 18:13:08 GMT

Folks, there is new version of mkfro frontend to Makaron, courtesy of slrhui.

Fishing controller is something else. In addition to buttons there's analog stick, reel handle, and a full 3D motion sensor. And two vibration motors for the fun of it. I really don't see how that could be emulated with a mouse or a pad :) Even with Wiimote I'd still lack one more analog input to emulate the reel...

Since I'm posting lots of pictures recently I guess it won't hurt to add few more :)

Double fault

Mon, 25 Feb 2008 11:21:01 GMT

With addition of full MMU support I introduced a bug into Makaron - games that were previously playable with simple SQ remapping would now require slower MMU recompiler. Fixed. This means only games based on Windows CE will require proper address translation, the rest will happily run on faster recompiler. I guess there is no "SEGA multitasking OS" for Dreamcast after all :)

As for MIL-CDs, those don't even use address translation at all. They wouldn't work on normal recompiler because it was too fast. Again, due to the bug mentioned I was led to belive MMU was being used - while it was not. Seems like lowering SH4 speed to about 160 MIPS gets those to run, not yet sure why. Could be another DMA issue, all those use the same software MPEG player and it gave me some troubles before on other games as well.

I've tried to investigate the cause of WinCE games breaking TA geometry registration process - without much luck so far. Also many games complain about VMU not having enough free space on it (but some would still create a good save later). Suddenly it seems like a good idea to quickly release T9/2 to just see how frequently it crashes and if that coincides with emulation speed.

I'm done merging the MMU version with the main source branch, seems to work. I've also tried several things to speed up the address translation - again, not much luck there. The lookup tables I'm using now seem to be the limit of what can be done in that aspect. Gee, I almost wish I could make use of x86 paging unit (and yes, I know how complicated that would be - pretty fast though).

In short: unless I discover something obviously wrong for me to fix, I'm going to release T9/2 later today (or so).

UPDATE: Here's Makaron Test 9/2 with MMU support in recompiler.
If you have any problems with it, go back to T9/1. This version is pretty broken (lots of unfinished modifications) but I want to know how badly :)
Again, too many changes to list. Some bug fixes (to SH4 recompiler as well). PAD plugin now enforces 5% dead zone in analog stick center position - this should cure "cursor keeps running away" problem in some games. New AICA/ARM code (back to interpreter for now) sounds much better, no DSP yet. More messages will now appear in English, in future it will be possible to support many languages (via translation files or something like that).

There's new system of identifying GD-ROMs and MIL-CDs - it's main purpose is to enable MMU where necessary. The database is far from complete though, so some GDs will not be recognized. Please report those, but do make sure to provide proper title, MD5 sum computed by Makaron, region, and whether it is Windows CE game or normal one. DO NOT REPORT PIRATED SOFTWARE. I will ignore/delete such reports on sight. Same goes for dubious ones, with spelling errors and such.
If you happen to stumble upon WinCE game that is not recognized you'll need to enable MMU manualy in the ini file. And let me repeat that again - MMU requires a damn fast CPU. 2,4GHz Core2 Duo is the absolute minimum - the faster the better.

The multi-threaded GD reading is not yet finished. You might want to enable it anyway, see GDROM.ini for that, but be advised that some games will refuse to boot or hang with this option enabled. Most should work.

UPDATE 2: Oops. Last minute changes to GD detection code broke it completly. Sorry :) I've posted revised T9/2 so please redownload.

M-m-m-monster Kill

Sat, 23 Feb 2008 23:13:58 GMT

Yuki is trying to kill me :) It took me a whole day to just browse trough this and she keeps sending more?!

Most of these don't require MMU to work. What's interesting is those that do are not necessarily running WinCE kernel, and that goes for MIL-CDs as well. Did SEGA came up with their own multitasking OS?

Ze MMU stuff:

Ze not-so-MMU stuff:

Some games requiring MMU are a bit unstable now. There's something not right with geometry processing and in more severe cases TA state machine chokes up and throws an error. And there's still no picture in Marionette Company whatsoever. I can only hope this is not another of those timing-related bugs, those are major pain in the ass to find & fix.

Goodies! #2

Sat, 23 Feb 2008 14:40:38 GMT

Some textures and geometry are still missing, not to mention YUV decoder is not working properly (or not getting data) - so no movies either. I suppose this will take a moment to fix then... And I really should implement bump-mapped textures one of these days.

Well, my GetBass arrived so I'm off to test that fishing pole :)

UPDATE: "This is a good day to code!"

Goodies!

Fri, 22 Feb 2008 23:00:53 GMT

So... MAME is getting Naomi support... can't let that slip now, can I? :)

I've spent the last few days working hard on getting MMU code to work. Big thanks go to Nathan Keynes, author of lxdream - Dreamcast emulator for Linux. I've managed to iron out several nasty bugs thanks to him and his sources.

More thanks and bows go to Yuki, who supplied me with TONS of Japanese Dreamcast software - both GD and MIL-CD based. And keeps coming back with more!

And last but not least, R. Belmont and kingshriek came up with a very nice AICA implementation, allowing me to improve mine in the process. I'm still a bit short on the DSP side though...

Gee, I wish there were more people that helpful (hint, hint).

Anyway, point is I now have both interpreter and recompiler capable of running with address translation on. This new recompiler is nothing like the non-MMU one, just about every optimization had to go... Right now I forked the project and keep two separate source sets but those will merge eventualy.
There's still some room for improvement (especially if I can think some clever and fast virtual->physical address cache) but I need to state this clearly: E6600 C2D is barely enough to to get 20 to 30FPS in-game. I do realize that Windows CE on Dreamcast was slow to begin with (and perhaps never went over 30) but you'd better get a damn fast CPU if you want to play games based on it. And if you already have a fast one, it's not enough. Get something faster.

Some pictures of MIL-CDs and GDs using MMU:

The next big problem with Windows CE games is that those use Sort-DMA, something I've not yet implemented properly. Many games boot with black screen, I get sound only - guess it's time to look into that.

EDIT: Pff... Sort-DMA be easy. Expect more pictures soon :)

Intermission

Fri, 15 Feb 2008 11:01:40 GMT

I've nothing new to report. Right now I'm busy with other things than Makaron, though you will be seeing some AICA/ARM improvments with next release.

I got some WinCE games to boot but there's no picture. Since TA/PVR interrupts happen as they should I guess it has to do with the way I cache and pick drawing lists. Also, current MMU code will not work with recompiler - and that means you'll have to wait a few more months before any of these will be anywhere near playable. Not to mention the CPU power it takes to run Makaron with address translation on.
Oh, and there's still a bug somewhere which breaks certain DC Linux distributions. It's driving me nuts, seeing how NetBSD seems fully functional.

Well, right now it was pointed out to me that Sakura Wars doesn't seem to detect controller (Love Hina was pretty particular about that too). And I'm waiting for package with Sega Bass to arrive so that I can finally see fishing rod in person, how does it handle and all. Mouse-based emulation of light gun would be pretty neat thing too. And one of these days I really should pick up that modem/BBA emulation again.

So may things, so little time.

UPDATE: What is it with Japanese game makers, did SEGA pay them to support only original accessories? Well, here is a new PAD plugin. Make sure you've "SEGA compatible" selected in configuration window and it should work in Sakura Wars just fine.

Today's experiment... success!

Fri, 18 Jan 2008 22:41:22 GMT

Finished Valkyrie Profile 2 - took me exactly 100 hours. What, I like leveling my characters :) The final form of Nibelung Valesti is fun - who needs nuclear weapons with finishing move like that?

"No." by Tracy Williams
(source is here)

Now the usuall stuff. I'm sure you've noticed how even the MT version gets choppy sometimes, SH4 speed indicator going all red for a split second with sound getting distorted, and so on. If you were paying attention you've noticed your HDD led blinked at the very same moment. Yup, it's not a coincidence. Untill now CD/GD image reads were blocking the main emulator thread - but no more.
I've begun converting GD layer to threaded model and hit few walls (what a surprise, huh?). I mean it's very doable but I have a very specific implementation in mind:
- ATA/ATAPI layer responds according to standards
- INTRQ/DMARQ signals can change asynchronously
- disc reads do not block emulator
- data reads are speed-limited to 12x
- DMA transfers are speed-limited to G1 max. of 10MB/s

I'd also like to move CDDA support from image reader to GD module as a special case of raw sector read. This way I'd have only one place in which the buffers are being refilled from HDD - nice and tidy.
So far I've completed about half of that, that is data reads are not blocking anymore - man, that does make a difference. You will like it :). Still, the limiter on DMA is 10MB/s now and there's none on GD yet. Why would I even need those? Because I like it that way. Sure as hell would make my life easier to just remove them but this is a gauntlet thrown in my face and I will take up that challenge :)
All this and no need for thread blocking other then BSY flag in status register - just like the hardware. But this might not last as I still need to figure out how to convert functions that "open" and "swap" discs - those can be called anytime from main thread (that is, menu that will be there someday). I need to gracefully handle cases like swap requests in the middle of buffer refill for example.

The additional thread doesn't run all the time, it goes to sleep when GD is not being accessed. This means you don't need triple-core (and if you have you will not notice any speedup) beacuse it'll most likely get scheduled to the core doing rendering, once it finishes that of course. I'm sure you realize that on single-core system the read has to block at some point, so non-MT version will have this mechanism disabled and work as they always did.

Oh, by the way, fighters/shooters use fog too:

Exp +1

Fri, 04 Jan 2008 15:47:31 GMT

New technology opens up new possibilities, or so they say. I've decided to read a bit about DirectX 10 - and quite frankly I didn't much like what I've learned.

DirectX 10 was designed with games in mind, not emulators, and definitelly not backward compatibility. It wouldn't be the first time though.
So, what's been deemed obsolete this time? Shader Model 1 for once. I didn't like SM1 much, it was the necessary first step to do away with fixed pipelines, but was still too limited in functionality to be of any real use. I suppose the same fate will befall SM2 once DX 11 is out...
The next thing we'll be parting with are 16-bit textures and this is where it hurts most. Dreamcast uses only those or palletized 4- and 8-bit formats (mostly targeting 16-bit color lookup tables by the way). In future I'll have to convert all of those on the fly - gee, thanks. Yes, that can be potentially done on GPU but without full integer support it's not very convenient. Not to mention I'd have to give up hardware texture filtering completly. Doing 8 lookups plus the necessary MIP level calculations (which I have yet to figure out) is not exactly fast and elegant solution, considering hardware does that in 1-2 cycles.
That's still not the end of it, no, that'd be too easy. All 8-bit formats are now RGBA (instead of ARGB) - de facto standard for shaders, but untill now the hardware did component shifts on it's own. I wasn't kidding when I said all formats will require conversion. Oh, and there are no YUV textures/surfaces. Maybe R8G8_B8G8 will be of some use, unless it's just a leftover to be removed in 10.1.

Right now I'm researching CPU-side format conversion - if there's anyone out there who knows any good sources or code I could freely use, drop me a note. This isn't rocket science but perhaps someone already did MMX/SSE2 optimized routines for that purpose so that I won't have to :)

Happy New Year

Mon, 31 Dec 2007 15:00:59 GMT

First I'd like to dedicate these two picture to people who claim that so-called 2D games should run better and require less resources to emulate than 3D ones. This is Bangai-O:

As you can see, if there is a 3D hardware then 2D games will use it. Why? Because it's faster to have another processor (GPU in that case) rasterize things for you - with alpha blending and transparency, and even filtering if needed. This is full-blown 3D, just that the third dimension is used for composing multiple layers, including background and text messages.
Many such games not only use 3D - they abuse it. Use thousands of small triangles with most of those having individual, unique textures (which are probably not only palletized, but also compressed in some way). And change that a lot every frame - that is 50/60 times per second. Now try to keep up with that!
This is not an 8-bit console calculating and writing every pixel to VRAM (although it does happen, true 2D is still used from time to time; SEGA logo is one example). I may not need to keep things cycle-correct here, but I've my own problems handling graphics.

Okay, now some more fog (you'll find it's used in quite many places actually):

Ah, but that's not all. Here are some more interesting uses of fogging:

Case 1 - fog used as a special effect to light up parts of objects that are being hit by player. And yes, that could've been done in several other (easier?) ways...

Case 2 - now this is grand, Bangai-O uses fogging to show selected buttons :)

There's a special today - a frontend to Makaron donated by slrhui - you can get it here. Please contact the author about it should you need any changes done. And be sure to thank him if you find it usefull.

Here's Makaron Test 9/1. The main purpose of this release it to fix some issues T9 had, but there are other changes as well.
Firstly there's the new AEG code in AICA - not entierly correct mind you, but it will get better in time. I belive I've explained it enough before but just to be sure: It makes AICA module somewhat slower. Nothing is free you know. It should be offset by ARM7 code being recompiled this time.
Second major change is the addition of fog processing. You will need at least Pixel Shader 2.0 for this to work, and it better be fast (worst case scenario, that is palletized & filtered texture with fog and color clamping, is 9 textures lookups + some 50 other instructions per pixel).
This also causes Makaron to lag a bit at startup now, as it has to recreate some 200 PS programs to cover all possible cases.

I tried not to touch SH4 code much, but I did change how HOLLY handles DMA transfers. This might break quite a number of things but was necessary to fix couple of games. Mostly CAPCOM ones, go figure. Some people out there should really learn how to use DMA... There are games that start the DMA and assume it's going to finish before the program advances to the point where it has to use the transferred data - without actually checking that. The easiest way around this problem is to complete the transfers the moment they are started - but of course there are other games that get confused by immediate end-of-transfer interrupt, or miss it, and hang. Yet other games require that the transfer at least advances a bit once started, or the unchaged counter will make them think it's already done. All this is also very timing-related, might work or not depending how fast the emulator goes and when the interrupts actually arrive. Not funny.
I solved this by forcing DMA transfers to take time to finish - just like on the real hardware. The difference is a DMA in progress will slow SH4 (because it's blocking memory bus or HOLLY) and Makaron doesn't account for that. Not to mention I can't exactly check for interrupts every instruction, like SH4, as this would kill performance. I came up with timings that should work well on both slow and fast systems - but it might still need some tweaking.

As a side effect you now get to experience loading times. Just like on your good old Dreamcast. Yay! :) So be patient when staring at blank or "Please wait" / "Now loading" screens. I know this feature will not get good press but I like it. So it stays :)
By the way, fixes to DMA engine (although not timing-related) made "Soul Calibur" and "Dead or Alive 2" dialogs re-appear.

Emulation speed/statistics information is no longer displayed. If you want it, re-enable it in F12 menu.

On a special request from Yuki I've looked into MakaronPAD plugin. It is now possible to assign normal digital buttons to POV directional pad. The plugin version has been bumped up - not a big deal, but it won't work in T8/T9 unless you hex-edit it. You shouldn't be using those anymore :)

Enough Makaron for this year. Silmeria still needs to be rescued and I want some strong monsters to test out triple Nibelung Valesti combo (Hrist->Lenneth->Alicia) :]

Wonders never cease

Sat, 29 Dec 2007 01:31:00 GMT

You folks noticing anyting of interest on the pictures below? :)

This will so not fit into PS 1.4 though. And yes, "Deep Figher" and "Cosmic Smash" show graphics now - I've fixed TA registering process. It should be good up to 8 continuations of any list.

In other news: "Project Justice" has BGM now - although not exactly on every run (I hate timing-related bugs). "Giga Wing 2" shows intro movie, and has more sound as well. All this thanks to FPU fixes on SH4 part - FTRC mostly.

I could release T9/1 as a quick fix to T9 in few days... It would include the new AICA code, but probably not fog support. That's kinda stopgap right now.

Become my Soul Reaver

Wed, 26 Dec 2007 22:18:38 GMT

I found few bugs in T9, here's quick summary:
- T9 actually reports itself as Test 8/3, my bad. The EXE file info should be correct though.
- Due to small changes in SH4 recompiler it may now trip on illegal opcodes, including ones that real hardware would ignore (like 0x0000 in delay slot). That breaks "Tokyo Highway Battle 2" and some "backups". I've already fixed that.
- "Street Fighter Alpha 3" freezes when entering attract mode. Cause yet unknown.
- SH4 fast interpreter is very slow, I was testing something and forgot to undo the changes. And there's a key that will break it even further if pressed :) Fixed.
- ARM7 was set to normal interpreter rather then fast one and this will add a bit to CPU usage. Fixed. Actually, I've finally completed the ARM recompiler - not very sophisticated but it is somewhat faster. And is default now.

Somehow - thanks to the free time perhaps - I was also able to come up with several improvements to the AICA module. I got more things done in past 2 days that in last 3 months... Anyway:
- There are two types of ADPCM streams on DC, and both can be looped even if only one is supposed to be used that way. But that didn't stop people from trying... Long story short, background music in Soul Reaver sounds fine now. Also, ADPCM samples don't like simple linear interpolation it seems so I've removed it. Trust me, it's better this way.
- I've implemented the Amplitude Envelope Generator (AEG in short). There's very little information on how it works, not to mention several special cases that I found got me scratching my head for a while. It has to be recalculated per-sample, though on the bright side I've designed it to use integer math only. Makes "Gundam Side Story 0079" and "Gun Bird 2" BGM nicer.

I think I could now try to add FEG and LFO too, but before I do I might need to redesign the module so it's more clear what's happening and where. In other words: it will take time.

Test 9

Fri, 21 Dec 2007 18:28:02 GMT

Here is Makaron Test 9 for your pleasure. There are lots of internal changes, but nothing revolutionary - so don't expect it to be much better/faster compared to earlier versions. From user point of view, it's almost the same as T8. Quite frankly the only reason I'm releasing it is to test some new stuff inside. For example, it's only thanks to user input that I found the NVidia FX series cards bug so fast (and actually it affected all cards, just that FX couldn't cope with it at all).
There are also people out there who simply have to test anything new that is released, because they love emulating stuff. So this is like a small gift for them, to enjoy for few moments before the novelty wears off :)

Like I said, there are tons of small (and not so small) internal changes to the emulation engine. Some of this stuff is so new it wasn't even tested much yet, so expect bugs. If you find a game that doesn't work now and it used to, please drop me a note - I'd like to find and fix the regressions first.
I won't go into much detail, but here's a list of things I consider interesting enough to explain a bit:

Dynamic Z-buffer range compression
This is a new method of dealing with overblown Z/W values. Most of the work is done in vertex shader so there should be no noticable speed impact. I mean, if there is then your graphics card was too slow to begin with and this is just another drop in the bucket.
Now I can handle geometry more like PVR2 does, which is good because this allows proper shadow casting. Very much like NANs, infinities are now detected and handled CPU-side - so far it appears to work as expected. All this and no Z-precision issuses, not that I'm aware of at least. Unless there's a game out there making a real use of 32-bit floating point HDR in Z-buffer this might just be THE solution :)
Note: There are games that still do not render properly due to other bugs, also this does nothing to cure transparency/ordering problems.

Shader Model 2 is now default
Makaron will now use VS 2.0 and PS 2.x (x being 0, a or b - where available), and fall back to 1.1/1.4 if it has to. What's more, I might be dropping SM1 support sometime in future. There are so many problems with it... I've had VS 1.1 break geometry which VS 2.0 handled just fine. And let me remind you again that palletized textures filtering is disabled on PS 1.4 beacuse it's too primitive for that kind of processing.
It's also about features that older cards do not have - like multiple render targets, or floating-point type surfaces. The Z compression code is considerably shorter compiled for 2.0 profile than it is for 1.1 by the way. Funny thing though, even if SM3 code is shorter it actually executes slower on most cards. That and the bugs I found in the drivers made me choose SM2 as the best perfomer.

Texture caching fixed
At least I hope it is :) Makaron MT version should no longer crash so much or trash textures. That does mean the single-threaded version will be a bit slower though - it's a tradeoff I've made to allow for proper locking. Some bugs still remain, mostly to be seen in Soul Calibur, but that's another story.

Shadows now work
Well, most of the time, and so are enabled by default. There are several ways it can be done - so far I was unable to come up with one method capable of handling all cases. Maybe there isn't one... Well, for now you can switch between different algorithms - you'll need to do that for Crazy Taxi series at least.

You really should be using multiple-core system for Makaron, mind you - this is the target PC I'm aiming for. SH4 speed is very important, but once you can do rendering in parallel most games will happily run full-speed on as little as 70-100MIPS. Seeing as AthlonXP clocked at 2000MHz is just below the required minimum, I'd say any mid-level X2 or C2D system will do fine.

The known bugs you will surely ecounter are mostly in AICA (sound module) code. The volume levels are still wrong - not sure why, I made the tables up to the specs. And yet PCM range often exceeds 16-bit, causing major distortions even if clipped. Also, ARM speed has been reduced to 1.5MIPS - this should make Soul Reaver happy. This is not exactly correct either, and will probably break some other games... I'll keep looking for a better solution.

As usuall, if there are any silly-yet-critical bugs discovered, I'll fix them right away. Other ones will have to wait for next "major" release :P

WARNING! Be careful not to overwrite your VMU or INI files when moving to T9!

It's magic I tell you

Thu, 13 Dec 2007 15:55:13 GMT

This was supposed to be a long (and somewhat boring I guess) reasoning on multi-threading, it's bright and dark sides. However, after writing about half of it, I've realized I'm out of new words to use for "governing access", "maintaining coherency", "shared data", etc. Soo... I'm just going to skip all that and assume you people know what MT is and how to use it :)

Even though I did learn quite a few things about parallel computing back at the university, I now feel it wasn't enough. Sure, nothing beats actual experience, but there are some guidelines to follow when writing a single-threaded application which will make your life much easier trying to convert it to multi-threaded model later. All this wisdom comes from trying to debug Makaron. Some MT-related bugs manifest themselves only in specific circumstances, and that can be for example not being run under debugger. Yeah, ouch. Good thing I prefer old-school printf ("I'm here"); methods of testing :)

So, there's the exclusive locking. A necessary evil, as it both protects our data and takes away the advantage of parallel execution. Something we can't live without but need to keep to bare minimum at the same time. Piece of cake :)

In most cases the real problem is data exchange between concurrently running tasks. While writing single-threaded code we usually don't keep track of how many procedures access a given variable or structure. On the other hand, to avoid unnecessary locking (and possibly deadlocking) in multi-threaded code we need to isolate shared data access points and group them - best tight, in as few places as possible.
What I find lacking is the proper mindset to write the code in a way that would not require total re-write later on. Though it does mean single-threaded execution speed will be somewhat sacrificed, the potential gains of switching to MT version are more than worth it. In other words, I wish I was more aware of it because of what I've learned rather than (re)discovering it by chance after hours spent on debugging.

But that's not all there is to it. Data that's only being read does not need to be exclusively locked during every access - just when it's modified. Still, creating a locking system to allow for that kind of access differentiation might not be much faster.
There are also cases when the data is being modified and still doesn't need locking - because if you're careful enough the dependencies created within that data will prevent you from doing something forbidden. That however still feels more like art to me then science. Spending two days trying to figure out why isn't the code working when it should be, and then realizing it was one variable assigment one line too far, is really not my idea of having a good time...

Anyway... I'm thinking of releasing T9 sometime before Christmas. Not that it's much more advanced than T8, but it will have several bugs fixed that should make it more stable on multi-core systems. Things I was hoping to get done by now are still more in the reasearch than development phase :)

Bandit at your six!

Wed, 28 Nov 2007 13:53:58 GMT

Yes, I'm playing Ace Combat right now :) I've finished AC04 few days ago and now I'm trying to beat AC5. On EASY... or so I thought.
My eye-hand coordination was never that good and my reflex is not exactly improving these days. Also, I don't have that kind of free time I had being a student. I still like playing computer games very much, and I want them challenging, but some get simply too difficult and frustrating for my taste. I mean I play those for fun, not to be reminded just how much I suck at it.
Namco, in it's wisdom, decided that AC5 missions 18, 18+ and 19 just have to be finished in a row. Flying over the fortress for an hour or so was rather tiring but felt nice once over. The 18+ is pretty easy if you prefer afterburner to outnumbered dogfights. And you can always get even later flying free missions. But #19 is a whole different story, at least for me...
I can fly well enough, I can follow, get my plane through cave tunnel. But that last mineshaft? Whose crazy idea was that? So what if enemies are dumber on EASY if you still crash & burn at the slightest touch with the walls?! What, I can take 4 missiles head on but can't even scratch my wing tips a bit? Even AC04 finale wasn't that demanding. And to add insult to injury you can't save before mission 19 (or return to game menu for that matter). All you can do is either repeat last 8 minutes of flying over and over again or press Reset/Power and go to sleep - and start again on #18 next time you load.
After retrying #19 for like dozen times I've finally given up. I got my hands on all-cleared save for AC5 and continued the story doing free missions, watching cutscenes in the viewer. Also, now that I can freely repeat only #19 I can get some practise and maybe one day I'll finish it too, with some luck.

Even if I can clear AC missions on NORMAL, I'd rather stick to EASY so I can just play anytime, even when somewhat tired for example. Funny thing though, I've restarted MGS3 on NORMAL after 30min of playing because EASY was too easy :)
Anyway, the point is I represent a generation of older gamers (or perhaps just not-so-good gamers :) and I feel like I'm no longer being a "target" for game makers. As I'm pretty sure teenagers and students net them most money, I too like to play. Good story-based action games (and the new 'adventure' type) should only be so difficult for people who want them tough. Personally I would not mind - after let's say 10 retries over one hour of gameplay - being able to skip parts or whole missions and continue with the game. This would give me minimal amount of points but obviously I'm not going for high score playing on EASY, right?
Being able to save more often (or at all) is another good idea. And so on... It doesn't take that much work to dumb the game down. It's also worth noting that teenagers are not in position of buying any game they want because they don't earn money and their parents might not be willing to spend more. I don't have that problem as I support myself :)

Nintendo seems to have come up with similar conclusion for their Wii. So if there are any game developers out there reading this, give it a thought.

Well, this isn't exactly Makaron WIP entry but here are some news:
- I know how to get spoken dialogues in Soul Reaver working. Actually it's possible even in T8, but you'd need to hack the EXE file as the required options to change are not exposed in the INI files. Still, it kind of puzzles me... it's not supposed to work that way. Something else is amiss.
- Found another silly bug, in MD5 library. I never saw it crash Makaron but it did that to other apps using same code.
- Restructuring of the main loop and init code is pretty much done now. It was a necessary step in order to implement GUI. Menu itself is not yet ready.

BTW, AC6 on x360 looks great. The trailer simply rocks. Isn't it funny though how all previous games were SONY exclusives and this one isn't...

TAKE ON THE WORLD!

Sun, 18 Nov 2007 11:57:23 GMT

Okay, so most of SEGA Mega Drive (Genesis for you US folks) aren't that playable. Too many graphics bug for one - the emulator makes heavy use of PVR OIT capability. Sound will usually get ugly when heavy action starts even though it's fine in menus. And there are other nasty problems as well, like falling through floors in alternate Prince of Persia.

But some games do work well enough (too bad Lotus 2 RECS is not one of them :)

By the way, I can't shake that crazy idea of connecting a hard drive to Dreamcast off my mind. I'm pretty sure it can be done. Basically all that's needed is some hardware to translate SEGA Packet Interface commands into HDD reads, and that's exactly what Makaron's GD module is doing. Right now there is logical link on register level but I'm confident I can extend it to handle singal layer as well. I do have some experience with ATA/ATAPI hardware.
At first I was thinking of FPGA to handle the ATA part, but perhaps a fast clocked ARM7 would suffice - I need research it some more and see what kind of latency I can expect. I really don't have time for this though... but if there's anyone out there with the money, skills and time and wants to try - contact me. I'll help :)

I feel like I could...

Sun, 18 Nov 2007 00:54:44 GMT

ScummVM works now (except the newest 0.10 version which is known to have sound problems on the Dreamcast port). Thanks to it crashing frequently on T8 I managed to nail down a bug in the MT version of Makaron.

Running emulator inside emulator is fun! Also, FreeSCI 0.3.5 port is actually performing better on Makaron than the native PC version...
SEGA Genesis emu works as well. I'll update tomorrow with some pictures.