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

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.

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.

Quote:

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

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.

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 ?

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:

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

Code:

make gdb

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.bz22 ) Rename the file to: insight-7.0.50.tar.bz23 ) 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:

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

Code:

# MinGW# these must point to your sh-elf bfd, not the system oneBFDLIB = -L/usr/sh-elf/lib -lbfd -lintl -liberty -lws2_32 -lwsock32BFDINCLUDE = /usr/sh-elf/include

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

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.

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

Who is online

Users browsing this forum: Bing [Bot] and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum