Running code on the Dreamcast
Sunday March 10, 2013 18:14:00

Awhile ago I talked about how to build the Dreamcast development tools on Windows which allowed you to compile Dreamcast code. Today, I'll be going over how to execute that code on the Dreamcast itself.

Prerequisites

First, start up the Cygwin.exe setup installer. Run through it until you get to “Select Packages” and search for “cdrecord” and “mkisofs”. Select them both and continue with the installer.

Next up, we'll need a tool called “scramble.” We'll need to build it from source. Thanks to this tutorial on dotdotcomorg.net for pointing out where this was.

$ cd ~/Tools/dreamcast/
$ mkdir scramble
$ cd scramble/
$ wget http://mc.pp.se/dc/files/scramble.c
$ gcc scramble.c -o scramble
$ mv scramble.exe /usr/local/bin/

Check that you have “cdrecord”, “mkisofs”, and “scramble” available on the command line.

Building Dc-Tool / DcLoad-IP

Next, we're going to build the tools that allow the PC and Dreamcast to communicate over the oh-so-expensive BBA.

The PC tool is called “dc-tool”, while the actual CD we create that runs on the Dreamcast is “dcload-ip.” Because places to find binaries of this stuff is becoming rare, we'll build from source.

Start a Cygwin prompt, and source your kos script (I called mine dcdev_environ.sh). After that, follow these steps:

$ cd ~/Tools/dreamcast
$ git clone git://cadcdev.git.sourceforge.net/gitroot/cadcdev/dcload-ip
$ cd dcload-ip

Now open up the file Makefile.cfg.
Remove the comments in front of “HOSTCFLAGS= -O2 -D_WIN32” and “EXECUTABLEEXTENSION” since we'll be compiling on Windows.
After the line “# sh-elf-stuff”, add “TARGETCCVER = 4”.

Now, execute “make” and dcload-ip should build.

Next, we need to burn the CD that the Dreamcast will play. This entails actually burning a CD and is the worst part of the process, since throwing away a screwed-up CDR each time something goes wrong is no fun. But alas, there is no other way.

Before we proceed, I want to point out some things. First, the program we're supposed to use is called “cdrecord”, but in Cygwin “cdrecord” is just a symlink to “wodim”, the man pages for which you can read here. Certain commands are different in wodim than cdrecord- in particular, I had to use the xa flag instead of xa1 to burn anything useful.

If you want to know exactly what goes into burning a Dreamcast CD, Marcus Comstedt's site on Dreamcast programming has a great write-up on the topic.

The dcload-ip source directory has a sub directory called make-cd with a makefile in it. This uses the programs cdrecord, mkisofs and scramble that we downloaded earlier.

First, open up the makefile in the makecd directory and look where the variable “CDRECORD” is defined. It'll have an argument “dev=0,0,0” which tells cdrecord which device on your system to use. You probably don't want that to be pointing to your main hard drive (although I think nothing bad happens; feel free to research that if you must!). To figure out the correct arguments, run “cdrecord -scanbus” from the Cygwin prompt. You want to select the three numbers which are before the name of your CD drive. For me, I get this:

$ cdrecord -scanbus
scsibus0:
        0,0,0     0) 'ASUS    ' 'DRW-24B3ST   c  ' '1.01' Removable CD-ROM
        0,1,0     1) *
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) *
        0,5,0     5) *
        0,6,0     6) *
        0,7,0     7) HOST ADAPTOR

This says 0,0,0 (the default) is correct on my system. If your numbers vary, update the makefile where it says “wodim dev= 0,0,0”.


Next, if you're on Windows like I said earlier you're actually using wodim, not cdrecord, so look for the flag “-xa1” and change it to “-xa” (update: looks like the makefile was updated to do this recently). xa1 in wodim expect 2056 bytes per sector, not 2048. See Marcus Comstedt's write-up and the wodim docs for more info.

Another note about drive speed. Burning Dreamcast discs at high speeds makes it harder from the Dreamcast to read the resulting CD and wear down the motor. Because of this, the “speed” argument to cdrecord in the makefile should be taken down to as low as you can get it. I've had success with 2- if I try “1” the disc never plays. However, if you can go to 1 try that as well. The speed argument is defined on the first line of the makefile.

Aside from speed, the next thing you'll need to make sure of is CDR quality. Cheap crappy CDRs will be less likely to work. I've had instances where I've had to burn multiple discs before getting the Dreamcast to read it (figuring that out wasn't exactly intuitive). This old DC emulation topic has more info on that.

Now, insert a blank CDR (make sure you're in a properly ventilated room before you blow the dust off first - after all, assuming you have CDRs, when was the last time you used one?) and then run the makefile by typing “make” in the make-cd directory. If everything goes well, you should hear the CD getting written and be able to play it on the Dreamcast, where you'll be greated with a screen showing the Dreamcast's IP info.

If it doesn't work:

Unfortunately, you're dealing with an old system and an outdated form of media, so it's highly likely you can hit problems. I burnt discs before that I thought were 100% broken, only to find they did work… 1 out of three times (or worse). Most of these “semi-working” discs were made before I cranked down the burning speed to “2”.

Understand that if you burn discs too fast, or recognize your Dreamcast is having issues reading them, be sure to retire the CD. Reading poorly burned homebrewed CDs can tire the Dreamcast's motor and eventually make it difficult to ever read a homebrew disc. This happened to my original Dreamcast which is why I now own a second one just for homebrew.

Running Code with dcload-ip

Now, we need to figure out what the Dreamcast's IP is on from the PC. In other words, we need to ensure we can ping the Dreamcast before we get any further.

To do that, the PC and Dreamcast need to be in the same IP range. To do that, you'll need to make your PC's ethernet IP static.

Go to Control Panel -> Network Connections. Find your ethernet (mine is “Local Area Connection.”) Right click and select properties.

In the box in the middle, select “Internet Protocol Version 4 (TCP / IPv4)” and select properties.

By default, the setting will be “Obtain an IP address automatically.” Change it to “Use the following IP Address:” I changed this to 10.0.0.2.

Reading through a past tutorial on how to do this, I said to execute “arp -h” to clear arp. But this time it didn't seem to do anything.

Anyway, execute “ping 10.0.0.2” and make sure something comes back and your PC can ping itself from that address.

Next, we need to assign the Dreamcast an IP from our machine.

The Dreamcast should be on and you should see the blue screen with the words “dcload-ip 1.0.5” etc. The second line is the Dreamcast’s MAC address. For me, its 00:d0:f1:02:9a:f3.

You need Admin privileges to do this, so hit the start button, in the Run box type “cmd” and then hold CTRL and Shift while pressing entre to get an admin console.
To assign the DC an IP, type:
arp -s 10.0.0.1 00-d0-f1-02-9a-f3
(where the last argument is your Dreamcast's IP).

After this, pinging 10.0.0.1 should work.

Finally, go back to the Cygwin prompt. You're going to run the “pvrmark_strips_direct” example that was compiled in the previous tutorial.

From the dcload-ip route directory (the root of the git clone) do this:

$  ./host-src/tool/dc-tool.exe -x ~/Tools/dreamcast/KallistiOS/examples/dreamcast/pvr/pvrmark_strips_direct/pvrmark_strips_direct.elf -t 10.0.0.1

Congrats! You're now running code on the Dreamcast!



Homebrew for Sale on the MSX
Friday February 15, 2013 00:50:36

Somehow got sucked into a rabbit hole this weekend while looking up information on Konami's Gradius games for the MSX and ended up discovering Matranet, a company creating and seeling new MSX games as well as books and other stuff. They seem to be the MSX equivalent of Atari Age.

I only have the YouTube clips to go off of but I'm shocked the how high quality of the MSX games for sale. Most of them seem to be original adventure games and compared to Atari Age or RetroUsb there are relatively few ports (although I'm not really up on my 1980's European PC culture so I may be wrong about that). It's a testament to the MSX's popularity that such passionate fans exist to produce this stuff.

Here's some of the stand outs:

Ink : Exxon Surfing - This is probably the prettiest looking game. It's a really simply game, the kind I wish I'd tried creating as a kid when all I had at my disposal was Q-Basic.

Zombie Near - What I like about this one is that it has the split screen concept from Spy vs Spy, but instead is a cooperative adventure game where both players work together to infiltrate a complex of some kind, with each player being able to move independently.

Mecha 8 - Looks too Euroshmup for my taste, but its technically impressive how nicely everything scrolls. Its interesting that in some levels the Mecha is walking, Knightmare style.

Matranet also has created a cool looking book called the "Legend of Konami" which details Konami's history on the MSX computer. It's great to see people preserving such a great time in videogame history.



Silent Hill Live Action Spoof
Sunday February 3, 2013 21:45:19

I discovered this video by Andres Borghi the other day and thought it was pretty funny. Anyone who's a fan of Silent Hill 1 and remembers the cutscenes will enjoy it.



Don't Switch from Cmd
Monday January 14, 2013 03:40:31

People make a compelling argument that Microsoft stops innovating the moment it's locked people in, and point to Internet Explore 6 as a great example. Progress on Internet Explorer ceased for years until Firefox gained traction and lulled Microsoft out of complacency, at which point they turned the lights back on at IE HQ and got to work again.

The built in Windows console, also known as Command Prompt, makes Internet Explorer look like as innovative as a bleeding edge Linux distro. Based on the harm it does, it might be the worst piece of software pushed by Microsoft.

Why is it so bad? There are a few reasons, but my main beef is its failure to behave like every other modern computer application regarding copy and past. Copy and paste in the Windows console requires dragging over blocks of text, which is antiquated and no longer makes any sense. There is no option for selecting text line by line.

However, there are replacements.

  • Power Cmd - This looks real nice, and a few years ago I bought a license. It doesn't work well on newer versions of Windows though.
  • Console 2 - This has tabs and copy and paste. It also lets you have use background images, and looks like the terminals seen in Linux and OSX.
  • ConEmu - Like Console 2, but seems to be the new heir to the cmd prompt throne.

Time for the bad news: most of these replacements don't work very well or slow down the programs they run. I wanted to write up the reasons I don't think they should be bothered with.

Let's start with PowerCmd, which I used on my laptop years ago. This was the first Cmd Prompt replacement I tried which seemed to be generally endorsed. Like all of these tools, it felt a bit wonky, but I'd accepted the quirks and switched to it for awhile until I switched back to Cmd briefly and discovered it was running programs much quicker. In other words, whenever I kicked off long running processes with PowerCmd, they ran glacially slow compared to the real Windows console. Years later, when my Netbook gave Windows XP a second life, I tried it again and found the problem to be more noticable than before.

I would have liked to write up a real speed measurement of PowerCmd, but these days it's so outdated it simply shouldn't be installed or considered. It's 32-bit, requires admin privileges, and even then failed when executing Boost Build.

Next up, there's ConEmu, described by Scott Hanselman as “The Windows Terminal/Console/Prompt we've been waiting for?” I started using this a week ago and it looked like the fully loaded real hot dog Cmd Prompt suffers had been waiting for. It offers line-by-line text selection, the ability to integrate with Cygwin, and loads upon loads of special features. I was very impressed by it, and spent half a day configuring the options to suite me.

However, when I ran the Macaroni build process with ConEmu, it went from 69 seconds to 172. What's worse is that despite the extreme slow down, the CPU stayed at 100% the entire time! I was so shocked by this I ran the tests again, this time taking care to not touch or do anything at all on my computer. But the results were the same. ConEmu strikes me as the PowerCmd successor, in that it looks pretty but cannot be used for anything serious.

Finally, I installed Console 2.

First, the good news: Console 2 runs programs at the same speed as the real Windows console. So it's worth consideration.

Personally, though, I didn't suite me. First off, it failed to move around correctly with Aero snap, and would constantly get stuck partially off screen when I moved it across monitors. These days I work in Windows, OSX, and Linux, and use some kind of “snap to grid” key bindings for all of them. Not cooperating with those bindings is a kiss of death! Second, Console 2 didn't copy and paste easily or correctly! Maybe I didn't sacrifice enough time to get that feature to work right but at this point I don't understand why Console 2 is so highly recommended given how unpleasant I found it. I guess there's no accounting for taste.

In summary, my recommendation is that you learn to deal with the Windows console's broken copy and paste. I can sympathize with you if you have to switch, in which case try Console 2 (at least the other shoe will drop quickly). Don't use ConEmu unless you want to waste your time, and don't even think of installing Power Cmd.





<---2013-06-15 18:07:35 history 2013-01-02 03:01:23--->



-All material © 2007 Tim Simpson unless otherwise noted-