What's new

Makaron WIP thread


New member
This thread is for all the WIP news from Makaron (a Dreamcast emulator for PC).

Double fault
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).


New member
Remember that tune

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...
Last edited:


New member
Shake it, baby

- 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?


New member
Hunting musca domestica

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 :)



New member
Can you try to make it compatible with the NBA 2k and NFL 2k games, that would be a first as no other emulator in existence can do that.;)


16-bit Corpse | Moderator
JKKDARK isn't the developer, dknute is. Talk to him about it. (i.e. post comments on his blog)


New member
Time off
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.


New member
Prima Aprilis

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...


New member
It beeps, IT BEEPS!

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.

It beeps in Japanese

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


New member
fork ()

I was unable to figure out any "smart" method of dumping E-VMU BIOS, so I still need to find the correct entry point to the BIOS procedure I want. Unfortunatelly the only way to do this is a brute-force exhaustive search of all 16384 combinations. Trust me, I've tried out quite a few and the conclusion is: the code in English-based VMUs has been shuffled by the linker and it's layout is completly different from any J-VMU I've seen.

Long story short, if you people hope to get English BIOS for VMU emulation (AFAIK noone has ever dumped it) you better help me :) I will continue my search anyway but it'll take weeks to months. It's not really required you know, Japanese BIOS will work just fine, but without it the simulator would appear somehow... incomplete.

Here's a list of things you need to have to help:

(1) Dreamcast
It's only required for the initial VMU programming. You might need it few more times if the VMU becomes corrupted, but that's it. Any region console will do.

(2) Spare E-VMU
It's a VMU that uses English to communicate via it's LCD. I'm not aware of any other types of VMU but J- and E- ones, but if you know better please tell me.
Important note: that VMU will be completly erased. Backup it first if it contains mini-game or saves you'll want to use in future.

(3) CR2032 button cells
You'll need some of those to power the VMU in standalone mode. Actually, if you have two able hands you can just connect two wires to the contacts (using sticky tape for example) and power it from external battery pack or even power supply. That's what I'm doing. Anything from 5V to 9V is fine, so a 4-pack of AA or AAA cells or one 9F22 battery will do. There is a diode inside the VMU to protect it in case you get the polarity wrong but be careful about that. And in case you decide on a power supply, make sure it's a quality one. The cheap "wall cubes" with unregulated output have a strong ripple which can go as high as twice the nominal voltage!

(4) Free time and some patience
This whole process is quite boring, really. You'll be repeating the same thing hundreds of times and it's important that you do it throughly. Good news is you can pause and continue at any time.

Interested? If so, please download this small package and follow the instructions below. It contains CDI ready to be burned and a binary file for people who would rather use a serial cable or BBA for uploading executables.

- I'm assuming you know how to burn CD-Rs for your Dreamcast to boot. Google it if you don't. The CDI in the archive is self-bootable, but I've also included the unscrambled binary file in case you'd want to make your own CD with a proper dummy file.

- Boot the disc, or upload it via cable, whatever works for you. Your console should be hooked up to a TV, PAL/NTSC mode will be autodetected. In case you need to override this, keep X pressed during boot/upload to force PAL, or Y to force NTSC. VGA box is another story - I'm pretty sure it'll detect and use proper mode but in case it doesn't use X+Y together. Keep in mind this will not work if normal TV cable is attached.

- You should be using standard Dreamcast controller, although anything that has VMU slot will probably do. Any port will do but I'd stick to Port A and slot 1 just in case. After the application starts you should see this:

VMU blind dialer 1.0
Press A to begin, or B to quit

- If you haven't already, insert a VMU into your controller and press A button. Let me repeat this one more time: AT THIS POINT YOUR VMU WILL BE COMPLETLY ERASED. The screen will change and eventually read like this:

Detecting... found VMU @A1
[Version 1.005,1999/10/26,315-6208-05,SEGA Visual Mem
ory System BIOS Produced by ]
Writing to VMU FLASH memory, please wait...
Processing block 256/256

Take note of the version being displayed. If you have VMU version below 1.004 please contact me, as there's a chance it's different from newer models.

- Once you see "Done" you can pull the VMU out. This procedure is so straightforward that you don't even need to use the TV; just wait a few seconds for the CD to boot and keep pressing A until the exclamation (!) icon on VMU LCD shows up. Then wait for it to go away and it's ready.

That covers priming the VMU. You can produce more then one, give it to family/friends :)
Now, for the important (and boring) part:

- Turn on the VMU
- Set up date/time if you're asked to
- Select mini-game mode, press A to run
- This will appear on LCD:


There are 4 hexadecimal digits here. The one blinking is the one selected and up/down on D-pad will increment or decrement it. There is no wrap or carry/borrow, so the lowest you can go is zero, the highest is F.
Left/right on the D-pad will select a different digit for you to play with. You need to set all four to get a unique address. This is why it's called "a dialer" - you pick up numbers to try out. Simple. Each and every possible combination from 0x0000 to 0x3fff has to be tested.
Once all digits are set, press A to test your combination.

At this point several things can happen:
- VMU will freeze. Reset it via hole on it's back or cut and re-apply power.
- VMU will reset itself. Saves you the trouble.
- Control will actually return to the mini-game program - this is rare, though. You'll see something like this:


Every time the VMU doesn't die, the program will test the buffer to see what's in it. If it's not interesting, it'll say "BAD" and print out a value. NOW PAY ATTENTION, THIS IS IMPORTANT: if the value is "77", ignore it and keep trying with different address. If it's "FF", write down the address and once you're done with testing for the time being, send me a list of those addresses. If you see any other number, especially if you see "2A" and/or "BAD" does not show up with the number, tell me about it ASAP. That's what we're looking for.

- On a very rare occasion a small group of addresses will execute BIOS built-in FLASH write routine. This will most likely corrupt the VMU and you'll need to flash it again via Dreamcast. Happens.

That's about it. Don't go over 0x4000, no point. If you want to help, contact me first via mail or comments - I will ask you about your VMU version and will assign you a range of numbers that needs to be tested in the first place. This way we won't have several people doing the same thing in vain.

- Yes, each and every address has to be tested. No skipping. We're hunting for 3 or 4 values out of 16384, we can't afford even smallest gaps in the search pattern.
- Once you set a number, you can press B once and it will be stored in the FLASH and recalled after reset. "FB" will appear on the screen to tell you it has happened. DO NOT USE THIS TOO OFTEN, for FLASH memory can only be written 1000-10000 times before it stops working. I use it every 64 numbers (0x40 in hex) to keep track of my progress.
- Keep notes. If you make a pause and forget what was the last number you've tried, go back to the number you're sure about. Or else you risk skipping something important.
- Because 95% attempts end up in hang or reset, this is really slow and boring thing to do. But if 20 or so people were to help out, we could cover all range in just few days.


New member
Time is of the essence

I've finally completed the new GD-ROM module, though ultimately it turned out to be very similar in design to the last one. With the new code I can freely choose what ATA/ATAPI commands are to be executed immediately and what can be offloaded to helper thread.
Unfortunately a thread is not a very good substitute for a real-time device. In typical multitasking OS there's a sheduler that decides when things will happen, there's no guarantee that the helper will start processing given request right away. Simply put, it can start immediately or only after some tens of miliseconds has passed. I could run the code in a tight loop to reduce this lag but that would waste too much CPU power, always needed elsewhere. Not to mention OS can (and eventually will at some point) interrupt any running process if it's required, so this approach would not solve the problem completly, just reduce the odds of ecountering it. Same thing goes for messing with thread priorities - that's not exactly foolproof and is also very inelegant.

Now, why would mere miliseconds ever pose a problem? In a well-designed system the consumer would just wait a bit for the producer to come up with data and occasional lag wouldn't even be noticable. Some Dreamcast software however (BIOS including) doesn't really check if the data has arrived, rather assume it must be so after a certain amount of time has passed.
This isn't that much of a problem for GD-ROM commands that return small amounts of redily available data - those can be simply executed at the moment they arrive, so there is no lag. Disk reads are another story though, those take time to complete and the whole idea was to run them concurrently so that virtual CPU would not be stalled waiting in the first place.

It gets more interesting at this point. A real Dreamcast GD is not anywhere near as fast as modern hard drives, so why doesn't it work in emulator if it works on an inferior system? The answer, again, is timing. It's simply very crucial to get it right - and you can have accurate emulator, or fast emulator, but not both. And you've guessed it right, I'm aiming for fast at this point. It has to be noted that should the original GD/CD media become too scratched or the laser detoriates beyond certain point, the problems I'm having will manifest themselves on Dreamcast as well - so I still say it's simply bad coding on games part.
What are the options... For starters, I will continue to play with the DMA code and try to mimic Dreamcast behaviour as closely as possible. And if all else fails, there's still the "ideal" DMA mode, that is to make transfers always block to be sure the virtual CPU always gets all the data it asks for. This of course causes jerkiness and audio stuttering, mostly to be felt in games using sequenced music or sound effects very closely timed to video.

This whole re-write took quite some time and didn't really help as much I hoped, but thanks to all that work I'm now much more aware of what has to be done yet. I've a few ideas, it's just that every attempt at fixing one thing breaks other stuff. Sometimes very badly I still need to figure out what upsets so much the MPEG library used on demo GDs and some MIL-CDs.

PS. Why didn't anyone tell me Giana's Return got broken with the addition of MMU-capable recompiler?!
PPS. I'm SOOO behing with testing Yuki's stuff now... I'm going to capture & post few screenshots later today. If I get the games to work with the new GD code that is

No screens yet. I had a bug that prevented most of the images from booting properly, that's fixed now. But there's a bigger problem - the new module is actually even less compatible, timing-wise, than the old one. I'll have to run more tests but now I'm beginning to suspect that some games require GD DMA processing to be done way more often. Which is bad because it seriously affects emulation speed.
At this point one begins to wonder what exactly is good about this new code Well, it is more reliable now. I was hoping that alone would be enough but apparently I was too optimistic...

A bit closer, still not there.



This is starting to seriously annoy me. DMA changes helped with some tiles but not all of them. Then I inserted a few debug statements into the code and even though it reduced emulation speed, it actually made things more stable. And this is the only lead I have so far...


New member
To boot or not to boot

I found and squashed a bug in new GD code. Not only Elemental Gimmick Gear boots again but it also cured Street Fighter Zero 3, which now seems to work just fine.



I've also devised a tweak to GD-DMA code for that accursed MPEG library. It interferes with SH4 main loop, effectively causing a temporary slowdown. This should not be a problem and is only visible during CD boot sequence, as BIOS decrypts the executable on the fly using thousands of 32-byte reads. As a side effect it fixes (or so it seems) those MIL-CDs that required SH4 speed to be reduced in order to load properly. One of these days I'll have to try and verify that on hardware, to see just how much of a slowdown G1 bus DMA transfer in background really is.
However, this is not yet the final solution to the problem. Sofdec library still expects some reads to start in close to zero time and I can't figure out why - still not conviced any code could be that braindead, so I'm not ruling out a bug on my side. For the time being I try to detect situations where DMA is started before GD buffer has anything in it, but every now and then this too fails. It looks awfully suspicious so I'll be investigating this next.
In the meantime, all Dream Preview GDs from Yuki boot now and here's a proof:







And as special bonus, an extra episode of How It's Made: Dreamcast by SEGA :)







By the way, there are games shown here I've never even heard of before...



More to follow soon.



Too bad WinCE games are so slow, but cheap 3GHz C2D are around the corner now :)
Also, some of the titles above require modem and ISP settings stored in the FLASH. Modem is not exactly on the top of my TO DO list.

Okay, last batch for today:



Ever seen VMU-compatible cell phones? :)

UPDATE: Oops, I've uploaded more images, but forgot to post them here. Here I brag about WinCE games and Biohazard 2 screens are missing... Fixed now :p




New member
Boot you long time

I think I've finally got the DMA code working. Well, for me at least :) It needs to be tested further on variety of hardware - and that's where you people come in. Expect T10 soon.

Some loose thoughts I feel like voicing:

1) T10 might be a bit slower than T9 series. It'll most likely affect only low-end systems as there isn't really much of a difference (if any) on my E6600.
2) WinCE games usually crash when emulation speed drops below certain treshold. In other words, if you got fast system you should get stable performance.
3) Due to changes in GD-DMA code loading times are back. It's considered normal behaviour since this is how Dreamcast works. Thanks to those changes compatibility has improved and following titles should now boot and work:
- all Dream Preview discs
- original MIL-CDs
- Street Fighter Zero 3
- SEGA Tetris Online
- Tetris 4D
4) CD-DA (audio tracks) will play, but still use the older method of fetching data. This might cause Makaron to crash but it's very unlikely as data reads and playing audio are mutualy exclusive tasks.
5) There are some minor changes in full-screen setup code (the debug window will be hidden and not forcibly refreshed). No 16:x aspect ratios yet.
6) Changes to sorting/drawing code broke shadows in Virtua Fighter 3tb. I'm not planning on fixing that anytime soon though, as it would break many other things. Late T9 versions have this problem too, by the way.
7) Makaron now disables screen saver when run. It's only going to be a problem if it crashes, as it might not re-enable it on exit. Just so you know.
8) If you manually enable MMU the recompiler will not switch to address translation mode until it's actually requested, so there's no speed penalty in BIOS and most games. Some however (like Ikaruga) use only partial translation and this can be emulated without full-blown MMU support. It'll work either way but will be a lot slower with MMU enabled. Some WinCE games are automatically recognized (this works only for GD images) and MMU will be turned on when necessary. In short: keep it off unless Makaron complains about it.

UPDATE: Few more notes:

There were some last-minute cleanups in the code, I hope I didn't break anything :)
MT version is the one I actively develp, the other is just dumbed down not to support threading. Not tested much so your mileage may vary.
As always, make sure you backup your own INI files if you want to keep them. For GDROM.ini though you should comment out the GDMT setting, or choose one of the following:
-1 is immediate mode. This will block emulator and allow the read to complete. In short: worst performance, but should always work. This is also the default mode for non-MT version.
0 is deffered mode. The read still blocks, just not right away but rather outside SH4 main loop. It might provide smoother emulation (if it works at all :)
1 is threaded mode. Disk reads are scheduled to separate thread for another core/CPU to take care of. Best speed, smooth emulation, should now work with every game. This is the default for MT version.
Threaded mode can't be selected for non-MT version of Makaron - deffered method will be used instead. This limitation was introduced on purpose, and might be lifted in future. Note that unless you have multiple cores/CPUs it will work just like deffered mode anyway.

I'd also like to remind you that there's a frontend to Makaron called mkfro. Highly recommended for people who can't work my INI files.

Anyway, click here to download Makaron T10.

UPDATE2: If you experience random crashes while in-game movies play (or are about to start), or from time to time CD/GD image refuses to boot (but works most of the time) - report this. Give me the title and your PC specs.

Take two

F355 Challenge works again. Turns out it was indeed SH4 recompiler bug - one that crept in with the introduction of MMU support. In short: right now all SH4 modules use common framework for interrupts and exceptions, and while converting TRAPA instruction to use that framework I've made a small mistake. Fixed.


The Skies of Arcadia bug is still there, unfortunately. Sometimes I can go in and out the game menu dozens of times (in rapid succession too) and it works. Then I restart the game, and it hangs on the very first try... You know, this might actually be a game bug, it just never manifests itself on Dreamcast due to much tighter corelation in timings on real hardware. Current PCs are faster but all operations exhibit a certain amount of lag (or should I rather call it "processing overhead") - well, only sometimes, but it happens every now and then and there's no control over it. It might take just a milisecond somewhere, when OS decides to switch threads at different time to balance CPU usage better for example, and there it goes. So... still looking into it.

I've came to belive that the same timing problem plagues GD code. It works for me (most of the time) but breaks horribly for other people. I've spent some time trying to determine the cause and I found out that SoA usually works, but will almost always crash at boot if I lower SH4 speed to some 150 MIPS. Curious, isn't it, especially if you consider GD-DMA speed is now tied to SH4 speed - so why does it even matter how fast it goes?
After a while I've noticed that in MT mode GD buffer becomes empty every now and then and this causes problems. Now, this is very unscientific explanation but my guess is BIOS booting procedure is kinda broken. Oversimplified. Maybe because it had to be short to fit all the code in cheaper and smaller ROM?
Anyway - a real GD drive isn't all that fast but once it starts reading, the data is being constantly streamed from disc to it's internal memory. And from there to Dreamcast main RAM via DMA. Think "hourglass" - constant stream of sand goes through. Now, on a PC it's more like a guy with shovel loading a truck. He can do way better in terms of quantity of sand moved but it's no longer a constant stream. If the truck is full it can supply us with all the sand we want but once it's empty it has to go back to the guy with shovel. If at this point we need more sand we either wait (that's blocking emulator for the read to complete) or go empty handed (DMA will finish later then usual and this might cause crash).

If you're smart you already see two ways to fix that. Either wait, as explained above, or... make the truck so big it will never become empty at the wrong time. In other words, make the GD data buffer at least the size of Dreamcast RAM, which is 16MB. And that's what I did yesterday and that really helped :)
This method isn't 100% fool-proof, as a real GD starts streaming data the moment the first read sector lands in its buffer. In our case loading some few MB might take longer and still fail because of that. This however wasn't a problem so far (or else the whole "offloading to thread" thing would not be possible) and let's hope it stays that way.

Marionette Company boots now, though there seem to be some geometry missing because I don't get text in dialog boxes at all... It's a WinCE game so maybe it's the Sort-DMA thing again?


And c'mon people, new version of Makaron isn't always going to be better than the last one. This is why I call my releases "Test", you know. So that you could TEST things, like new code and such. And report your findings back, maybe? Some people do - and I thank them for that.
Just because I'm not all over your problems when you report doesn't mean I disregard them. Still, I've no intention of answering each and every comment that shows up - this is a place in which I brag about how great I am, not a help desk.


New member

Here's some fast paced action with Puyo Puyo - not exactly something I would play, but I do love the looks & mechanics.
I enjoy watching people play those games for some reason :)


And this is Puzzle Bobble aka Bust-A-Move outside Japan.


This one is actually WinCE game but should work reasonably well on systems slower then my E6600 - there isn't that much processing going on. It gave me some trouble as the Sort-DMA needs to handled in a special way to get correct visuals - but I've managed to make it work.

What's interesting, the USA version screen mask (borders around play area) seems to be somewhat simplified when compared to Japanese original. Well, maybe this depends on the character you choose to play with - but that caught my eye.

I've tweaked my GD code even more and now it seems stable at last. There was also a race condition (found by sheer luck BTW) in the cyclic buffer I use for GD data transfers. I tried to make it safe for one producer/consumer pair but it didn't work out that well, so now it's just blocked via critical sections where necessary.
ARM7 recompiler got fixed too. It was long due, I simply forgot to carry the changes from interpreter and, as luck would have it, I've compiled T10 to use the broken code :)

Oh, by the way - I found out that Evolution does not boot if there's less then some 11 blocks free on VMU at PAS1. Curious. I'll have to see how my DC will handle situation like this.

UPDATE: Seems like all WinCE games report VMUs as having 0 space left. More work for me I guess...
I still got over 200 GDs form Yuki to sort through, so I'm not going to post screenshots from each and every one - but here's a few, I know you like them :p



New member

Evolution will not boot (black screen right after SEGA logo) if there is less than 8 free blocks on Port A/Slot 1 VMU. It's not a bug in Makaron, it does exactly that on my Dreamcast too. Interestingly if you remove the VMU completly at this point it'll unfreeze and show a warning (about there not being enough space to save) and let you continue. On Makaron the only way to avoid this situation is to make sure there's enough space left on VMU before you launch the game.

If you get that Skies of Arcadia bug where it hangs once you leave the in-game menu, it's probably damaged FLASH. Unfortunately Makaron can damage this file as well - this is a bit complicated and so I'll spare you the boring details. Point is, if that happens you need to replace it with a good dump. I consider FLASH image safe if it's not been used with any emulator, so there's no chance it got corrupted. You might still need to set the date & time, mind you, but that's normal and should work from there on.
By the way - I'm always talking GDI images, unless otherwise noted. In this particular case I'd like to remind you people that there are various problems with Echelon's rip of SoA on Dreamcast, and that stays true for Makaron as well. It's not as bad, as Makaron GD emulation is still faster than the real hardware, but you should expects random lags (like those in intro sequence), maybe broken sound and even more graphics glitches.

I've been playing SoA for several hours (and not just me) and not a single hang :) Right now I'm trying to implement VMU sounds - if there's anyone out there who could explain to me where exactly SoA makes use of that, it'd be great. A save file would be even better.

And one more thing - if everything goes well there will be something interesting to show at the end of this week. Stay tuned :)

UPDATE: Never mind that save. There's the face on LCD, the VMU buzzing (yes, it works now), and the controller vibrates as well. You can't possibly miss a Cham now :) Some T10/1 screenshots:



New member
Weekend pasta

Well, this isn't the surprise I was talking about but it's still better than nothing :)
Makaron Test 10/1 is out. You know the drill.

T9/4 and T10 were rather unstable but this time around I'm more happy with both GD and DMA code. It's not just bugfixes though, there are several new features in this version:
- support for VMU sounds
- improved Z-buffering
- fully functional DSP
- experimental anisotropic filtering

DSP is enabled by default. It might slow down things a bit, though (as usual) if you have a fast C2D you won't notice it. I'm really considering running whole AICA on separate thread now by the way, so it should improve in future for multi-core systems.
Please note that there's a slight slowdown noticable (in audio) when sequenced music is being played, in all Makaron versions released so far. This is sort of design flaw (and due to rather demanding hardware setup) and will be someday corrected.

Anisotropic filtering is too enabled by default, to 8x - it will be scaled down if your card can't support such mode. This will only be a problem for those cheap cards that support AFx8 but are very slow at it, in this case you might get quite a performance drop. If this becomes an issuse I'll tell you how to disable AF :)


New member
Makaron Test 10/1 released

Well, this isn't the surprise I was talking about but it's still better than nothing.
Makaron Test 10/1 is out. You know the drill.

T9/4 and T10 were rather unstable but this time around I'm more happy with both GD and DMA code. It's not just bugfixes though, there are several new features in this version:
- support for VMU sounds
- improved Z-buffering
- fully functional DSP
- experimental anisotropic filtering

DSP is enabled by default. It might slow down things a bit, though (as usual) if you have a fast C2D you won't notice it. I'm really considering running whole AICA on separate thread now by the way, so it should improve in future for multi-core systems.
Please note that there's a slight slowdown noticable (in audio) when sequenced music is being played, in all Makaron versions released so far. This is sort of design flaw (and due to rather demanding hardware setup) and will be someday corrected.

Anisotropic filtering is too enabled by default, to 8x - it will be scaled down if your card can't support such mode. This will only be a problem for those cheap cards that support AFx8 but are very slow at it, in this case you might get quite a performance drop.


New member
Breaking triangles

Yesterday I fixed one of the few long outstanding bugs in TA/PVR core. You should have no problems discerning the "before" and "after" from pictures below


There's a new feature in T10/2: degenerated geometry. Usually that is something you'd want to avoid but in this case I'm injecting it into vertex streams on purpose.
Why? On Dreamcast the polygons have to be arranged in short triangle strips for TA/PVR to process them. Very short actually, one strip can have at most 6 triangles in it. If you need to draw something larger you must first partition the data, and then register it as a set of strips. It keeps PVR sorting lists short but for the emulator it means drawing each and every strip as a separate entity. For games with lots of 3D geometry details or objects (like Dead or Alive 2 or Trigger Heart Exelica) that means up to some 8000 Draw calls - per frame! This is very time consuming.
I modified my rendering system - it now creates additional triangles to connect the separate strips together, so they could be drawn all at once with single call. Of course those triangles can't be visible or else the whole scene would become a mess, so I make them degenerated. In the end there's more triangles to process but it all happens faster anyway
This scheme cuts the number of Draw calls down by factor of 2-2.7 for those most intensive 3D scenes. There are still almost 3500 calls per frame in some places but that's more managable than it was up until now. Any further optimizations would require some serious pre-processing of the data, tieing down CPU. I'll think about it but I suspect it's just not worth it.

As for the surprise I promised... here it is (along with some pictures of my new scope). I'd like to thank ElSemi for the help he provided, this would not be possible so soon without him.


Now this opens up some new possibilities​


New member
NAO MI emulate NAOMI

I can boot a few games (both cart and GD-based - assuming I have the GD decryption key), but there are some serious Maple <-> JVS translation issues. This protocol differs a bit from what I found in the JAMMA docs and without access to the hardware there is little chance of me figuring out what exactly is broken.
Not to mention some games require special input devices - like a bat I wonder if it's based on fishing pole hardware (which will be next to impossible to properly emulate anyway)...