DCEmulation

So have any of you guys got it working with no errors?

I got a shit ton of them, trying again from scratch.

Lemme guess - the ARM failed gcc pass 1... it's a known bug of gcc-core4.x.x. Use gcc-4.5.2 instead of gcc-core-4.5.2 and it will make it through the makefile in dc-chain just fine.

Aha, that was it yeah it compiled perfectly now, thank you.
It took 8 hours for my 3ghz single core cpu to compile gcc... amazing.

On another topic, I've tried lib wildmidi for some port and it wouldn't work, the sounds just wouldn't play. I've tried several things but either SDL takes control of the audio drivers or does the mp3lib ( yes I've tried that ) and even converting the music to mod or s3m or xm so SDL plays them but still it woulnd't play. Using the mp3 makes the bgm work but not the sfx...

Wow, that's oddly slow. My 1.66 GHz CoreDuo compiles the whole shebang in less than two hours. Oh well, at least it works.



You need to point wildmidi to your own buffers. Look at this bit of the sound callback from Doom:



I ask wildmidi to fill a buffer called musout with NUM_SAMPLES 16-bit stereo samples (that's why it's NUM_SAMPLES*4). Then I mix that buffer with any pcm for the final buffer to send to whatever is playing the sound.

WildMidi isn't too hard to use - look at Mus_Register() for how to get ready to play a midi file, at Mus_Unregister() how for to clean up, and fill_buffer() on how to get samples. There's very little to it.

Thank you again I will try that, I thought that the play function did all that like some others do. My bad.

Back on topic again, now that seeing that this works for all who have tried what's left to start thinking about iso r5 ?

Yeah, having gcc 4.5.2 and the rest for r5 would be a real boon to folks who can't or don't want to compile it all themselves.

I'm following the instructions of the original post to a T but still having issues. First of all, got a failure right from the opening moments, as the make is now looking for newlib-1.19.0. Alright fine, downloaded and placed newlib-1.19.0 where it goes. Make wanted to repatch, this is illogical so I tried skipping it. It won't take no for an answer and refuses to continue. Fine... delete directories and re-copy them. Make again. Now, I get this:



Not sure where to take it from here.

_________________
We are but shadows and dust, Maximus. Shadows and dust!

That most likely means that newlib's configure script couldn't actually find sh-elf-gcc. Usually, that means that the first pass of building the sh-elf compiler broke somewhere along the line.

What a surprise... something gcc-related broke. I'm used to it. Oh well... guess I'll just wait for a binary release...

_________________
We are but shadows and dust, Maximus. Shadows and dust!

Actually, it usually means you forgot to assign yourself write privileges to where it was supposed to save the compiler.

Still, something in the first stage of gcc building is broken in that case (also in binutils, but that's another story).

Look at that source directory

/usr/kos/kos/utils/dc-chain/build-newlib-sh-elf-1.19.0/sh-elf/newlib/libc/machine/sh

I can't help but think that's part of the problem.

Putting the source in /usr/kos? I think it would be better just in the regular projects directory. It seems to be set for the default directory to save to... look at this error



That's the default, but they haven't made an /opt/toolchains/dc directory, or don't have permissions for /opt.

As a rule, if something isn't explicitly stated in the instructions, I don't do it... and that includes doing things like creating /opt/toolchains/dc or other such details. Otherwise, problems that arise from straying always come back on the user as being an incompetent ass. I updated newlib only because it was obvious that it needed to be done, but everything else was done verbatim. I'm willing to give it another shot just because I'd like to get this going (and SliTaz's gcc4.5.2 requires GLIBC_2.11 and there's no package for that so gcc is useless there, hence I can't do a damn thing with it... SliTaz is the ONLY Linux I will EVER use, without argument or exception).

EDIT: I said to hell with it and just found the old R4 instead... that was a piece of cake to get going, since I already have cygwin installed due to an earlier install of psxsdk. Using this, I was able to finally build a working binary... just one of the examples for now, but a step in the right direction. Now to figure out what to do with the elf file... time to find some docs.

EDIT2: It seems R4 comes with something called BootDreams which appears to be what I need to make a working disc image... now to try it out in an emulator.

EDIT3: Got nullDC installed and running, and ran the .cdi... ran without problems, though the console seemed to spit out tons of messages about "Excepts"... don't know if that's normal or not, but hey, it's running. Looks like I have a working toolchain now. Having an updated one would be nice, but this will do the trick for now. Dreamcast development, here I come.

_________________
We are but shadows and dust, Maximus. Shadows and dust!

So, after a few tries I finally managed to install GDB and Insight succesfully with this toolchain on MinGW Win32. Furthermore, it works OK with dc-tool-ip 1.0.4 in MinGW and I can debug lots of things now

The steps are not so trivial, but if you managed to compile this toolchain, then you will have succeed with that one.

PREPARATION AND INITIAL NOTES

1 ) Check that 'wget' is installed in your system. In MinGW, you can download binaries here: http://downloads.sourceforge.net/mingw/ ... RT.tar.bz2
2 ) GCC 4.5.2 needs GDB 7.0.50 or above by specifications. If you try to compile GDB 6.7.1 (default version)... it will fail

If you only want to compile GDB (for hard guys!):
a ) Open Makefile and change GDB version to 7.0.50 (tested and worked), or 7.2.

Go take a cofee / beer / drink of your desire, and wait to compile it. If everything is OK, you will have a new sh-elf-gdb.exe file.

If you want to compile Insight (recommended):
1 ) When you compile Insight, you will compile also GDB + Tcl/Tk (a graphical library that Insight uses).
2 ) The Insight version is in pair with GDB version (i.e. Insight 7.2 means that it has GDB 7.2).
3 ) Any clean version of Insight will fail to compile in a MinGW environment.
4 ) The 7.0.50 version of Insight (snapshot) worked for me. I tried latest CVS 7.2 but it gave me errors. So, I'll use this version in this mini How-to.

COMPILE INSIGHT

1 ) Download manually this version of Insight: insight-weekly-CVS-7.0.50-20091130.tar.bz2 . You can get from here: ftp://sourceware.org/pub/insight/snapsh ... 30.tar.bz2
2 ) Rename the file to: insight-7.0.50.tar.bz2
3 ) Uncompress everything in dc-chain folder (so, there should be a new src folder inside dc-chain).
4 ) Download the MinGW patch (see attachments), extract the content in dc-chain folder, and apply it:

5 ) Now, rename the 'src' folder to: 'insight-7.0.50'
6 ) Open Makefile and change the Insight version to: 7.0.50
7 ) Create the following fake file to cheat Makefile:

8 ) Finally, time to compile! (and cross fingers hehe).


The process is quite slow (less than building toolchain, but enough to go out and take a walk). If everything is fine, you will have two new exes: sh-elf-gdb.exe and sh-elf-insight.exe.

COMPILE DC-TOOL

This GDB will only work with latest SVN version of dc-tool. I remark the SVN because it won't work for any of the 1.0.4 binaries that I found on the Internet. You need to compile dc-tool-ip (or dc-tool-serial) with your new and shiny toolchain, and then burn into a CD the Dreamcast binary (make-cd) folder.

1 ) In Makefile.cfg, I had to add one more library to compile dc-tool (and change paths). It should be like this


2 ) Remember to check other configs (like the Dreamcast IP in the IP version). When ready, 'make' and 'make install'

3 ) If you want to use BootDreams to burn the Dreamcast binary, you have to use the scramble utility first on the 1st_read.bin: http://mc.pp.se/dc/files/scramble.c

In this post I won't explain how to use these tools (there is a good tutorial in the DDEr4 package), but if anyone needs help I'll explain a bit about them. Happy debugging!!

After spending a few hours (read: lots of hours) I finally managed to squash an important bug that, unfortunately, affects all the users that used this system.

NOTICE: DO NOT USE the custom gcc-4.5.2-kos.diff that comes inside mingwpack.zip !!! The patch file is outdated and your binaries will crash because there were changes into KOS thread system. Instead of it, please, use the updated gcc-4.5.2-kos.diff that comes with the KOS SVN.

If you already have your toolchain, I'm afraid you will have to rebuild it using the new patch...

Here I list my updated version of the components that I used to build a succesfull toolchain:
- gcc-core-4.5.2.tar.bz2
- gcc-objc-4.5.2.tar.bz2
- gcc-g++-4.5.2.tar.bz2

- mpfr-2.4.2.tar.bz2
- mpc-0.8.2.tar.tar
- gmp-5.0.2.tar.bz2

- binutils-2.21.tar.bz2
- newlib-1.19.0.tar.gz

I attach my Makefile (utils/dc-chain) with latests versions and doc changes, and ready to work with latest KOS svn. You can use this instead of the Makefile that comes in the package.

Have fun!!

Hello,

Thanks for all your infos in this very intersting thread.

I have just a question, because I'm completly outdated... GDB works under dc-tool/dc-load? How can we works with GDB to debugging Dreamcast binaries ???

_________________
[big_fury]SiZiOUS, http://sbibuilder.shorturl.com/

Warning : This person speak english very badly

Hey SiZiOUS, nice to see you here again

Yes, GDB should work OK with dc-tool/dc-load. If I'm not wrong, when you upload the binary (ELF) using -g with dc-tool, it waits for a connection (just after uploading and before executing). In short words, the DC is the GDBserver (server part).

Your computer, then, connects to the DC and it works as a GDBclient. After a succesfull connection, you control the GDBserver (start execution, breakpoints...).

Same applies to dctool-serial, but without IP's.

Hi Indiket

But how it can works ? Do I need both BBA and Serial Cable in order to use GDB? Or only BBA is enough ?

Thanks for the reply

_________________
[big_fury]SiZiOUS, http://sbibuilder.shorturl.com/

Warning : This person speak english very badly

No no, only one of them is needed (BBA or Serial Cable).

I don't know exactly the technical details, but Wikipedia is a great start:
http://en.wikipedia.org/wiki/Gdbserver

OK!! Thanks for the info!

I'm just trying to compiling this KOS environment with the Dreamcast(tm) tutorial and your improvements, and everything is doing well for the moment (compiling the toolchain)!

I'm so happy to see that KOS and the DC is supported in 2011! I'm just remember when I discovered the DC scene in 2002... and i'm still here!! 10 years !! Incredible

_________________
[big_fury]SiZiOUS, http://sbibuilder.shorturl.com/

Warning : This person speak english very badly