Deunan

I belive I can fly

Sat, 31 Oct 2009 18:34:43 GMT

Presenting Airline Pilots. Strangely enough Makaron seems able to run both single and multi-monitor version just fine. I havent tried the dedicated BIOS though, it's possible it would try to establish multi-board sync (just like the F355 one) and hang on that.

The framedrop is due to heavy debug output, game should work full speed.

UPDATE: More games.

I heard SEGA Tetris is pretty nice game but it sure doesn't look like much:

Samba de Amigo 2000 - yeah, I'm usually running JP BIOS dumped from my box so this is why most of you can't read the title :P

Still working on few other games, I'm seriously hoping this is the last batch for now or the next Makaron update will be in 2010...

Crazy

Tue, 20 Oct 2009 17:16:58 GMT

As I said before, I deal with the problematic cases here. And sure enough this is one Crazy Taxi:

Not that it differs much from Dreamcast version...

UPDATE: Just for the fun of it:

Resized textures be ugly though. Still, at least now I can fix that silly aspect ratio problem.

UPDATE 2: Unfortunately F355 Twin only goes this far before dying. The "protection" here is pretty much it's unique BIOS, it doesn't work well with normal one.

Patience challenge

Wed, 14 Oct 2009 20:45:48 GMT

Busy with the whole cart dumping thing I've been neglecting Makaron lately. Well, there's only so much one man can do. When other people got interested in the cart dumping trojan, I was happy. I hoped to just pass the baton and finally have some more time for coding. Little did I know it's going to be exactly the opposite...

For some reason all the "easy" games have already been covered and the remaining ones present all sorts of problems. Take Mushiking for example.

Step one. Not only a bad dump, it doesn't even show the ROMs properly.

Fortunately I pretty much already knew what was the cause, thanks to prior work done on Oh! My Goddess. Step two:

Okay, not sure what goes on here but there is a way to dump this game. Step three:

Yup, this is how it looks like on real hardware:

And yet... no joy so far.

This is hard work, I tell you.

Dreamcast not dead

Tue, 15 Sep 2009 14:18:09 GMT

Rush Rush Rally Racing looks like fun.
Hmmm... 15 EURO? Now where did I put my card :)

Dual In-Line Memory Module

Tue, 01 Sep 2009 19:07:46 GMT

More goodies arrived a few days ago, thanks to Robero Malone. Being cheap I decided not to buy a ZIF socket and ended up desoldering and resoldering the firmware FLASH twice. Did I ever mention how much I hate TSOPs? The end result was worth it though:

In other news, a friend of mine visited recently and brought Nintendo DS with him. And now I want to buy one even more... pray that I don't :)

UPDATE: Thanks to ANY, who shared some crucial piece of information with me, I present these photos. Sorry for quality, LCD vs daylight problems, not to mention these games hardly have any static screens :)

Oh, by the way, don't insert the PIC key wrong. It'll get hot. VERY HOT. Even though I was careful not to make that mistake it still happened (mostly because I inadvertedly rotated the chip when I assembled the holder - so for the final version I didn't use the holder at all). Luckily both DIMM and PIC survived :P

Who needs emulators when you can run any game you want on NAOMI2 box? :)

UPDATE 2: This game I got from Yuki looong time ago, before I even got Makaron to emulate NAOMI. Now at least I can run it to see how it looks like :)

Naze nani Makaron

Sat, 22 Aug 2009 21:29:43 GMT

After seeing - yet another - question on why doesn't Makaron support games in so-called "MAME format" I felt I need to explain this somewhat - yet again.

First of all, there is no hidden agenda here. In fact it's all pretty simple, you just have to try and see things from my perspective:

- I'm not affiliated with MAME in any way
- MAME dumps are not my only, and not even my primary, source of games
- I'm capable of dumping the games on my own, using different methods
- since I'm pretty much Dreamcast-oriented I prefer GDIs over the generic CHDs
- until recently I've been under the impression I can't use CHD-related algorithms without breaking MAME license

The ROMs:

The dumps I make are in different format to begin with, in my opinion easier to use. I need no prior knowledge of how to assemble my files to make them work, they just do. I fully intend to support any valid Dreamcast or NAOMI image, whether it's a dump of a game, or a hack/fansub, or maybe a homebrew of some sort. In other words if it works on the hardware I hope to have it working in Makaron. MAME can only run official and supported games (that also includes any BIOS images) since the code needs to know how to handle various files. Seeing how my approach suits me better I find little motivation to support another - and in my eyes inferior - format...

While I don't condone software piracy I'm not going to look down on so-called "ROM collectors". It's really not my place to judge, not to mention in many countries it's illegal to have copies of the software even if you are in possesion of the original media (EULA aside). The only issue I have is with, how should I put it, computer-illiterate people who have absolutely NO IDEA on what Dreamcast / NAOMI is and how to use it, and expect to just play free games. Full-speed in HD of course. If you are one of said people PRETTY PLEASE have at least some decency and learn a thing or two first, and then you can come here with your questions and ideas.

The CHDs:

Again, I see little benefit of having the images compressed. Really, when you think about it, you can get higher compression ratio with solid 7z or RAR archives and faster emulation with uncompressed files. This is not that important for NAOMI where the game is loaded whole into memory at startup - though with CHDs it would still be slower due to necessary decompression and decryption steps - but would have much higher impact on Dreamcast games. To make this simple:

* My approach, that is plain files are stored compressed with 7z or RAR:
PROS:
- better compression ratio, less disk space used
- faster loading times, less lag (important for Dreamcast)
- the code is already there, well tested and working
- both GDIs and NAOMI images are plain files and easily created/modified
- tools, that people who dump games for me use, create GDIs/plain files
- Makaron will load and run any valid file you choose
CONS:
- games have to be manualy decompressed first (and then deleted eventually)
- can't load MAME dumped games natively (though conversion is possible)
- MAME (MESS?) can't run plain images (conversion is possible but only for recognized games)

* MAME approach
PROS:
- dumped games can be used as-is, just download (har har) the files and run
CONS:
- see my approach PROS, reverse :)
- CHDs could change format in future breaking compatiblity (unlikely but not impossible)
- AFAIK even MAME guys dump GDs as GDI first and then make CHD out of them

So unless you jump from game to game every 5 minutes you won't much mind having to decompress a file every now and then. Also, all NAOMI needs is decompressed game image, having to repeat this step (even if automatically) every time you load a CHD seems kinda... unnecessary. Maybe one day MAME will fully emulate the DIMM unit, then it will make much more sense to have CHDs around. Still, I keep GDIs of NAOMI games so I can make CHDs anytime I want.
Oh, and about that "you can replace a faulty ROM thanks to MAME dump" - you can as easily extract that data from files that Makaron uses. Trust me, when it actually comes to replacing anything on NAOMI carts, finding the right data will be the least of your problems :)

To sum this up, I have nothing against MAME but I think the "standard" argument is debatable. As long as conversion is possible there is nothing wrong with a little variety, it's not like I try to enforce proprietary formats here. It's a pain for some people, true, but if you can't get it to work then perhaps you should look for a different emulator. If you want to run MAME dumps, get MAME - duh :)
These formats will be supported eventually I guess but thats future for you. You lot should know by now I don't exactly make ease of use my priority at this point :P

New age of heroes

Wed, 19 Aug 2009 09:27:32 GMT

This is how you do it properly :)
Many thanks go to Alex for running my experiments on his carts.

Random pictures (again)

Sun, 02 Aug 2009 14:33:29 GMT

Rainbow Cotton apparently thinks it's possible to hook up coin acceptor to a Dreamcast:

And here's another NAOMI cart game running:

UPDATE: Aaand another game :)

Same old, same old

Wed, 29 Jul 2009 23:32:35 GMT

Dreamcast side of Makaron is now available for download.

It's pretty much the same code as NAOMI version released earlier, with some minor modifications. From the top of my head:
- "clockmin" is now 100 by default
- accepted clock values are now in 10 to 400 range
- "pixelcenter" is zero by default (ATI users with problems please set it to -0.1)
- first gamepad can be configured by selecting "Settings" in the menu (this is just a hack for now, and let me remind you that X360 controllers don't need configuration)

As usual, keep copy of of your INI files from earlier versions (Maple.ini, MakaronPAD.ini and MakaronVMU.ini). You'd be surprised just how many people overwrite these and then come here complaining about gamepad / memory cards related issues.
These INI files will be removed soon anyway, once I get the GUI more functional.

If you spot a game that has worked in T11 but not in T12 please report it. There are some bugs that I'm already aware of:
- "Stupid Invaders" not booting (I know how to fix it just not sure if I should, it could be a side effect of another bug somewhere else)
- "Looney Tunes Space Race" sound issues (still need to find the real source of this problem)
- "Shenmue II" not booting (should work on SSE2 capable systems, works on mine but it was reported broken on some AMD CPUs)
- some games require a certain video cable to work properly (mostly JP/USA games, doing weird stuff or hanging with RGB cable)
- "Yu Suzuki Game Works Vol. 1" (sorta works but the way this is coded really upsets Makaron)
- some WinCE games like "Marionette Company" have really broken graphics (mostly extreme cases of Z-buffer abuse)
- demo/attract modes on some games are broken due to imperfect FPU emulation, the most serious case being "Aero Dancing" where the tutorial crashes the plane
- and tons of other stuff :)

Please do not report any problems with broken visuals. While some of those could be real bugs it's mostly imperfect Z-buffering and/or sorting - nothing can be done about that with the renderer I'm currently using.
Also, if you're going to report a bug then please either do it properly or don't bother. At the very least describe the problem and provide game title and your system specs. And keep in mind I only care about games run from GD images, if you have a problem with ripped game you're on your own.

Incoming

Wed, 22 Jul 2009 12:46:42 GMT

I'm about to release Makaron Test 12 soon, though only the NAOMI side for now. I still have mixed feelings about it seeing how many problems were initialy reported and how some of those still remain unsolved. I guess I better explain a few things first.

The way T12 handles flow of time is fundamentally different compared to previous versions. It allows for much tighter synchronization between emulated components but comes with a price: it's slower. It's not even so much the new system itself but the parameters it uses are not fine-tuned yet.
I figure some more feedback could help so that's why I'm going to release it anyway. You can always go back to T11 series if it's too slow or too buggy to be used.
It pretty much just works on Core2 CPUs but some older AMDs are struggling. There is a good chance changing some INI entries will make it work but that is exactly what I need you people to find out :)

So what's new? There is a simple GUI but it's not very functional yet. DIMM.ini file is gone, you can just load the game you want through GUI or command line. There is X360 gamepad support, in fact it's what I use mostly these days. Keyboard can still be used (with the obvious limitations in the analog department) but the mapping format and key codes have changed. And I'm still not sure this will be the final version. Sorry but that's WIP for you. It won't be that much of a problem once it can be fully configured from UI.
Pads other than X360 ones (or in other words: XInput based) are not supported. There is XInput emulation layer, you could try that if you wish.

Even if I can now run some protected cart games I will disable that functionality in the public version. This is still mostly incomplete and I don't want to deal with any "bug reports" about that. You can play GD-based games just fine.

UPDATE: There seems to be some confusion about this - it's not that I don't want to support DirectInput devices. It's just much more difficult and not a priority at this moment.

You can download NAOMI T12 here. The ReadMe became somewhat obsolete so I didn't include it. The INI files are commented.
Please make sure you understand how the new JVS.ini works before you submit a bug report about controls being broken. For keyboard-only replace it with the included example file. As for the key codes, 0-9 and a-z use ASCII, the rest is standard Win32 virtual keys.

Oh and you can only run one game and then you have to close Makaron. This is a simple bug but since I'm not done testing I want results from clean runs - so it stays for now :)

UPDATE 2: For X360 pads you can also assign LB/RB shoulder buttons and LT/RT triggers (only as digital and analog inputs respectively). Most games run happily with one just coin acceptor so don't presume you have to assign COIN2 input, just try adding credits and that should let Player 2 join in. For multiple pads add another X360 section, the number is the pad ID as displayed by the LED indicator. Remember to edit the controls to P2! Mixed X360/keyboard input is also possible but duplicate entries will not work.

Shooting games have no additional pointer to help with targeting but someone said this is how real players do this :) Let's see if that's true. I'm going to add it as an option anyway to next release. And while on the subject, you should enter game's test mode and calibrate the controls first. This is a bit tricky since X360 analog area is circular but it's possible to extend the corner reach a bit if you do this right.
The "out of sight" signal means the gun is not pointed at the screen (it's a separate signal from the gun position) and it's used for reloading. Most games have it wired to second digital input so it works like BUTTON2, just press B on X360.

If T12 is too slow for you but T11 worked fine then try to lower SH4 clock (first thing you should try is lowering clockmax - read the comments in NAOMI.ini). If that works for you then please report your system specs, game name and settings used.
You can also try relaxed timing mode but that should be last resort.

And one more thing: since F12 is used by MSVC debugger I moved the menu key to F11.

UPDATE 3: Use F8 to close Makaron in full-screen mode :P

Plane equations and other assorted fun stuff

Tue, 14 Jul 2009 20:23:18 GMT

All the news lately are about NAOMI progress but that doesn't mean I'm not working on the Dreamcast side of Makaron as well.

Screens below came from Twinkle Star Sprites which is broken on all (*) current Dreamcast emulators. Thanks go to Billy who tested the new version on several ATI cards and also submitted a few bug reports. As you can see I fixed the visual bug, and also another one that crashed SH4 recompiler.

(*) EDIT: The ones I have and tested anyway :)

Oh and as a side effect of DMA and Maple changes GameShark now works too. Haven't actually used it but at least it boots :)

Well, shoot!

Sat, 11 Jul 2009 22:07:41 GMT

I know the screens I captured aren't that impressive but you try to press Alt+Print Screen and shoot at the same time :) Targeting is done via X360 analog stick - works pretty well except I could use a pointer telling me what I'm shooting at... On my TODO list.

Oh and did I mention that Monkey Ball works as well?

Someone asked if it's possible to push 3M triangles through Dreamcast-based system in real-time. See the pictures below? The first two values shown in the second line are vertex (w) and triangle (tr) counters. That's per-frame so multiply by 60 to get per-second figures. So what do you think, possible?
Trigger Heart Exelica can do over 30000 vertexes and 44000 triangles per frame as well :)

Drafty

Sat, 04 Jul 2009 16:21:55 GMT

Roberto Malone strikes again! More goodies have arrived and I dare say I've made a good use of them :)

2MB worth of decrypted data and I got to see this:

But since I wasn't satisfied I've swapped the EPROM for Millenium version. This is still WIP so there are slowdowns all over the place but thanks to that I've made an interesting discovery. The boobs...? They actually do bounce :)

Protection violation

Fri, 19 Jun 2009 19:04:47 GMT

This is how Oh! My Goddess Quiz looks like when dumped and run in Makaron:

Obviously it's broken. The textures on Bellandy are wrong and the texts are unreadable.
Yesterday I figured out how the ROM banking protection works on this cart. Turns out OMG doesn't use it... but it gave me an idea I've tried just now. Bingo, another form of protection was present - and after dumping the necessary data and patching the cart image I got this:

Much better, wouldn't you say? :)
It still won't work reliably in Makaron due to a bug in the game code but I will work that around soon. Protection on this particular cart is rather easy to defeat, others might be more challenging...

Peek & Poke

Mon, 15 Jun 2009 10:26:55 GMT

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

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

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

Fully operational

Sat, 23 May 2009 20:58:10 GMT

Behold, my own JVS I/O interface. Being a cheapskate I decided that 150$ is not a good price for an MCU with a serial link and some inputs.

Even if just a prototype it's already good enough to fool games. Oh! My Goddess happily boots now.

None of this would be possible without Roberto Malone. This guy found me a NAOMI2, bought it, shipped it to me, and covered all the expenses himself. Now that is dedication people, an example to follow (hint, hint) :)

Random pictures

Mon, 18 May 2009 20:55:55 GMT

A few new toys arrived - the biggest one today :)
I still need ear plugs. That or new fans for the system.

This box might very well be cursed you know. Let's just say it took the scenic route on it's way here :)

It beeps!

Fri, 01 May 2009 18:48:39 GMT

Visual Memory Simulator BETA is out for testing. You can download it here.

There is a ReadMe.txt provided, should cover the basics. If you got Makaron working you should have no trouble running VMS :)

Now I can switch my focus back to Makaron.

Improving the hardware

Fri, 24 Apr 2009 23:50:28 GMT

Serial link: poor man's answer to broadband adapter shortage (and pricing). It's a cheap way to transfer data between PC and Dreamcast (including dumping your own BIOS and FLASH) and pretty much the only option if you're considering homebrew software. Sure, demos and emulators can be burned onto CDs but for testing your own code you'll need a more robust delivery method :)

Some time ago I mentioned that most serial link projects out there are overly complicated. Perhaps it's because many were conceived years ago when every PC had at least one RS232 port and USB chips were expensive. I'm about to show you it can be made really simple.

I'm going to skip all the technical details and going to assume you already know:
- what is RS232 and it's limitations
- why we should stick to low-voltage signaling
- what is USB and why use it

First you'll need FT232 chip from FTDI. It's exactly what we want, a simple yet fast USB to serial converter with low-voltate I/O. And by "chip" I actually mean a ready-made interface like this one:

It can be powered from USB line and has internal 3.3V low drop regulator - so all it takes to make it work is two short wires: one to route power supply, one to connect LDO output with voltage reference pin for I/O.

Now for the Dreamcast part. I found it impossible to purchase a connector that would fit the serial port so it had to go. You won't miss it, trust me.
First cut the connector assembly in two, with a small saw blade or a file. Take your time, you don't want to damage anything on the board (hence the black tape by the way). Pay attention to where exactly are you placing the cutting point, you will want both sides of the video connector intact so that the screws will hold it well in place.

Cut the connector legs with precise cutters. And I do mean precise, too big will rip them off the board, possibly damaging the traces as well. The alternative is to insert a small, flat head screwdriver (or something like that) under the pin and pry it up as you heat the soldering point with iron tip. Again, do not apply any force before melting the solder. The pins on right were cut, ones on the left were lifted.

Now desolder the shield and remove unwanted connector part completly. Don't throw it away yet, you'll need to cut off the other side mounting wing too, to provide a proper spacing for metal heat exchanger. Well you can always use a couple of small washers for that if need be.

And here's a picture of the pads cleaned, with any leftover pin remains removed.

Now you just need to solder 5 wires (RxD, TxD, RTS, CTS and ground) to the pads. I used one of the shield pads for ground, that makes it easier to fit the other four. That can be somewhat challenging with thicker wire but it pays off to have it durable and safe to twist around. Glue gun does the rest, just don't overdo it or you'll have problems fitting the covering plate/heat exchanger.

Ready to rock :) You can even see the wire I used to route USB power and I/O reference. All you need to do now is put it all back together and get friendly with dcload-serial tool.

So, does it work? Hell yes, on 3 Dreamcasts already. Same technique in every case. Works like a charm up to 1.5Mbps too. Just keep the wires to FT chip as short as possible (already long board traces and protective RC elements not helping any). If you have problems with higher speeds you can try using 5V instead of 3.3V for I/O. I belive this to be pretty safe (run it for hours on my Dreamcasts) but make no guarantees.
Some people say even 3Mbps can be achieved when protection RCs are removed but that will open a direct line to SH4 pins and you risk permanent damage to it. Obviously, no 5V in that case.

There's no galvanic separation here, wouldn't make much sense with common ground, so even if DC power supply is floating (I think) make sure you connect everything to the same AC phase. Or suffer the consequences.

Oh, and yes, the wires just stick out of the back of Dreamcast. Hey, it's cheap and works :)

UPDATE: Few more details, should be more useful now :)

First, here's a simplified pinout (only the required signals shown):

And just in case someone needs this extra bit of info, the whole serial port carries these signals on B10 down to B1 (looking at the picture above that's left to right): 3.3V, /RESET, GND, CTS, RTS, TxD, RxD, GND, SCK, 5V. And as you can see the big pads on both sides (connector shield) are also tied to ground.

This particular serial to USB converter was bought here: http://www.propox.com/products/t_93.html
It's a pretty common design but there's a manual with schematics for download on that page if you need them.

Pins VPO, VEX and VIO are connected together in my photo. That's PORTVCC, EXTVCC and IOVCC - and that means 5V on the I/O pins. This is actually by mistake, I'm short on these modules and when I swap it around I often forget to re-wire it properly for Dreamcast. As I said, it will work like this but that's unsafe.
You should connect IOVCC to 3V3OUT instead. With this module you'd just put a jumper on pins 24 and 23 and connect 22 with 18 using a short, insulated wire.

And don't forget it's a null-modem so TxD from the board goes to RxD pin on the FT chip and vice versa. Same for RTS/CTS control signals.

Hope that helps!

Cruise Speed

Tue, 07 Apr 2009 14:06:13 GMT

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

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

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

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

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

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

Bits and pieces

Wed, 18 Mar 2009 13:03:04 GMT

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

  vector<Box>::iterator i;

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

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

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

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

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

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

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

VMU-E and VMU-J BIOS:

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

"Zen Nippon Pro Wres - Giant Channel":

"Atsumete Godzilla - Kaiju Dai Shuugou":

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

"Atsumare! GuruGuru Onsen - Chiisana Kotori Uranai":

"Pinta Quest" - Skies of Arcadia minigame:

And there's more where this came from :)

500 - Too Busy

Sat, 31 Jan 2009 19:32:26 GMT

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

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

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

Download it here.

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

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

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

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

Countdown

Mon, 29 Dec 2008 23:43:31 GMT

The GD-EMU project has advanced a bit. Not without a fight though :)

Quartus SOPC Builder allows user to change component names to something more suitable than the default ones - so you can name JTAG UART anything you like but unless it's "jtag_uart" there's a very high chance it won't work as NIOS IDE terminal.
There is a FAQ on that on Altera website, true, but it took me 2 days to find the information I was looking for...

I had some trouble figuring out a way to create a register stack that could be accessed for read/write operations from two separate interfaces - one synchronous (Avalon bus) and one asynchronous (GD ATA). It finally worked today, so now I can intercept ATA/ATAPI commands sent by Dreamcast on NIOS side, using C code.

33.8688MHz clock generator is finally complete. I've used 74AC04, though with short connections a HC part should do too. Output is clean enough for a clock, the only thing that worries me a bit is the voltage swing. Even if powered from 3.3V the generator manages to output a whooping 5Vp-p - probably due to parasitic capacitances that create a pump. I could put a small resistor in series with the output but that will form an unwanted low-pass RC filer... Looking at the specs the FPGA should be able to handle this kind of abuse. I hope.

Lastly I've wasted a better part of the day chasing bugs, before I realized I'm trying to control a memory-mapped I/O via cache. Not such a great idea :) Kinda funny seeing how just a few days ago I wrote a simple memory testing routine that bypasses the data cache, for the same purpose I/O accesses should.

I've already a pretty good idea of how the whole data exchange system should look like. On PC every operation could block the main emulation thread (if needed). That won't work on the hardware - I need to deliver the data on time in every case. Including situations where audio playback has been started and a PIO/DMA request comes up as well.

UPDATE: To be on a safe side I've added a 100 ohm resistor to my generator output, to protect the FPGA. The signal still registers fine. I guess 50 ohm would be better but frankly there is no proper termination on the Altera board (only a 1k pulldown to prevent the trace from catching any nearby RF emissions) so I won't bother with matching impedance.

There's some bad news too - it seems that dual-clock FIFO is not as great as it seemed to be at first. There is a latency between writes/reads and assertion of full/empty signals. Can't have that.
So I guess I'll need to use single-clock FIFOs but this means I have to provide my own latches to prevent unintended multiple reads and writes. What a bother...

UPDATE 2: I finally got some of the data transfer path working - in loopback mode for now. Apparently NIOS 2 can do byte/halfword/word writes but not reads. The read sequence is always a 32-bit transfer, starting with the part that is aligned to word boundary. My somewhat simplified address decoder was not properly handling the "empty" reads from locations nearby the actual one, hence the problems. Fixed now using byteenables.
I've also used the begintransfer signal to prevent multiple reads/writes on Avalon side, when bus waitstates are used. For the GD side I've come up with a simple state machine that will disable the read/write requests after the first clock cycle, seems to work.
Now I'm going to focus on FAT handling, I need that before I can port Makaron GD code.

Enter Altera

Tue, 16 Dec 2008 00:13:34 GMT

Here's a little something I just cooked up:

On the left - Dreamcast. On the right - Cyclone II Development Kit from Altera. What it does right now is mostly this:

The idea was to have FPGA handle the ATA interface, including DMA burst transfers, while external MCU will run part of Makaron GD code and take care of all the high-level stuff. 2GB Secure Digital card will provide necessary GD data.
I realized that EP2C20 can easily host both the interface and a soft-core NIOS II CPU with all the supporting logic for onboard memory chips. Now this is neat, I can actually run the NIOS faster than my ARM7 and it has more memory too (I mean, just the SDRAM is 8MB vs 64kB on-chip SRAM on ARM). The only problem is I don't have license for that IP core so the USB programming cable needs to be attached at all times, or the board will freeze eventually. Both ARM and Cyclone boards have SD slots so I can change my mind anytime :)

Anyway, SPI<->SD communication works both on ARM and NIOS now (it's the same C code, save the low-level I/O stuff). Now I need to handle FAT. There is a free library for that but I want to write my own with a bit more buffering as an option. Since it's read-only it shouldn't be much of a problem, it's just that both target CPUs can only do aligned memory accesses and that needs to be worked around for the FAT structure parsing.

VHDL code for ATA i/f is progressing, but slowly. I haven't done any of this before - I doubt programming GAL devices counts :)

UPDATE: There is a new MKFro available for download. It's a GUI for Makaron T11/1 - both Dreamcast and NAOMI versions.
MKFro requires NET Framework 2.0 or higher. Please direct any questions you might have to it's author slrhui.

Also, there are more interesting hardware projects on this page: JJ10DM. Though I have to say that the USB-based serial uplink to Dreamcast doesn't have to be that complicated - if anyone is interested I can provide more details.

UPDATE 2: To those who reported the following problems in the comments:
- Games crashing with Internal error -1005 on STARTRENDER
- DirectSound error in UzupelnijBufor/Lock
Please download this file. Inside you'll find updated executables to replace the T11/1 ones. Try those out and tell me if it helps.

~~And one more thing: the person who reported Border Down demo mode being played wrong - please provide me with a save for this game.~~
Nevermind, just found a working one myself :P

Virtual victory

Tue, 02 Dec 2008 22:47:37 GMT

More screenshots. Never enough of those :P

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