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

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

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

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.

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.

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!

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.

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

New version awaits you on SendSpace :)

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

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

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


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


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

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

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