Questions about Installing KOS

[UndeadDC]

Hello, I was thinking of trying some dreamcast dev again. It's been over ten years (I've gotten so old) since I fooled around with it, and in that time I've switched from being a windows user to linux. I'm still a little green about some aspects of Linux, though, and in the installation guide on the KOS website it talks about GCC needing to be patched. Anyway, I was wondering just what this was about and if it would affect my Linux installation in any way, and if it would mess up the patch if I ever updated GCC. I'm using Linux Mint btw. Thanks in advance.

[BlueCrab]

You won't be patching your system's GCC, but rather the one you'll be building for compiling stuff on the Dreamcast.

By the way, there's a more complete guide to setting up KOS on Linux specifically that you can find here on the KOS website (I'm not sure if I ever linked it on the main pages of the site or not): http://gamedev.allusion.net/softprj/kos/setup-linux.php

[UndeadDC]

Thanks a lot. That clears up a lot of misunderstandings I had. I was under the impression that cross compiling would be tied to the system's GCC like different modules for a single program. And thanks for the link. I was using this one:

http://gamedev.allusion.net/softprj/kos/setup.php

It's linked from the "Home" link with the "compilation/setup" link, and through the "Installation" link on the side bar. I'm not sure how to get to your link from the home page at all.

[UndeadDC]

Hello again, I'm trying to build the tools using the link you gave. I'm building from the github source files, but I get an error when I try to install the kos toolchain. This is the output I got the second time I tried to run the make file in /opt/toolchains/dc/kos/utils/dc-chain after running download.sh and unpack.sh . Any help with this would be appreciated. Would it be better to stick to the stable release?

Code: Select all

patch -N -d gcc-4.7.3 -p1 < /opt/toolchains/dc/kos/utils/dc-chain/patches/gcc-4.7.3-kos.diff
patching file gcc/configure
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file gcc/configure.rej
patching file gcc/cp/cfns.h
Reversed (or previously applied) patch detected!  Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file gcc/cp/cfns.h.rej
patching file gcc/doc/gcc.texi
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file gcc/doc/gcc.texi.rej
patching file libgcc/config/sh/crt1.S
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file libgcc/config/sh/crt1.S.rej
The next patch would create the file libgcc/config/sh/fake-kos.S,
which already exists!  Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file libgcc/config/sh/gthr-kos.h,
which already exists!  Skipping patch.
1 out of 1 hunk ignored
patching file libgcc/config/sh/t-sh
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file libgcc/config/sh/t-sh.rej
patching file libgcc/configure
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file libgcc/configure.rej
Makefile:108: recipe for target '/opt/toolchains/dc/kos/utils/dc-chain/patches/gcc-4.7.3-kos.diff' failed
make: *** [/opt/toolchains/dc/kos/utils/dc-chain/patches/gcc-4.7.3-kos.diff] Error 1

[SiZiOUS]

I think the GitHub repo is not up-to-date. I've recently built a complete toolchain under MinGW/MSYS and almost all things were working, at least in the dc-chain Makefile. Maybe you could try to use the SourceForge repo maybe?

[BlueCrab]

That's happening because it's trying to patch the source code again. Either you'll need to clean up the directories from earlier (delete at least the gcc-4.7.3 and newlib-2.0.0 directories), or you'll have to edit the Makefile so that it doesn't do the patching step.

It's a known issue that it will do that if you try to run it twice.

[SiZiOUS]

It's a known issue that it will do that if you try to run it twice.

I think that you already fixed this bug in the KOS SourceForge repo.
But if he's using the GitHub repo which is older, the bug will be there.
In my freshly installed MinGW/MSYS toolchain, I've got this bug in the past but not this time. So your fix on the SF repo is fully working.

[BlueCrab]

https://github.com/KallistiOS/KallistiO ... 89c2ae3ec2

^ The commit is on there too. Unless the person here is pulling from an unofficial repository. It still doesn't always work, possibly due to differences in the way some versions of patch work.

That said, the SF repo is the correct "primary" repository, but the official GitHub one is at least kept up to date every time I commit something.

[UndeadDC]

Sorry, to be correct. I was installing from the SF repository. I generally associated Git with git hub. I didn't know you could use it with SF too. I guess I wasn't paying attention. I'm going to re-check my library dependencies to make sure I have them, and try a clean install. Does anyone know a way to check for developer libraries? Do they have their own identifiers I can look for? I've been using this method:

ldconfig -p | grep libjpeg

I don't suppose it would hurt to just reinstall over the old ones will it? Thanks for the help.

Update: It turns out I didn't have any of the development libraries that I needed. ;p apt to the rescue. Installing the toolchain seemed to work OK. I didn't get any errors, but the Insight build failed on me. Here's a snippet from the very end:

Code: Select all

make[4]: Leaving directory '/opt/toolchains/dc/kos/utils/dc-chain/build-insight-6.8-1/tk/unix'
make[3]: Leaving directory '/opt/toolchains/dc/kos/utils/dc-chain/build-insight-6.8-1/tk'
make[2]: Leaving directory '/opt/toolchains/dc/kos/utils/dc-chain/build-insight-6.8-1'
Makefile:699: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/opt/toolchains/dc/kos/utils/dc-chain/build-insight-6.8-1'
Makefile:278: recipe for target 'build_insight_stamp' failed
make: *** [build_insight_stamp] Error 1

Kos seemed to compile fine, though. No errors. Now to find some sample files to test things out with. Anybody know any good tutorials?

[SiZiOUS]

That said, the SF repo is the correct "primary" repository, but the official GitHub one is at least kept up to date every time I commit something.

Oh, thanks for the explanation!
I was thinking of the KOS GitHub repo under your name, and this one seems to be outdated.
I didn't know that we had a official repo on GitHub.

Does anyone know a way to check for developer libraries?

All the toolchain components are installed by default into the /opt/toolchains/dc path. Adapt this path in function of your config.
Let's call that path "$toolchain_base".

For binutils, you should have $toolchain_base/sh-elf/bin/sh-elf-as, sh-elf-ld (full list here).
For newlib, you should have $toolchain_base/sh-elf/sh-elf/lib/libc.a and libg.a at the same location.
For gcc, you should have $toolchain_base/sh-elf/bin/sh-elf-gcc, etc.

I don't know if we have a specific command for doing checks of the toolchain content.

I don't suppose it would hurt to just reinstall over the old ones will it? Thanks for the help.

For my point of view, no. It's safer to do so in that case for me.

Update: It turns out I didn't have any of the development libraries that I needed. ;p apt to the rescue. Installing the toolchain seemed to work OK. I didn't get any errors, but the Insight build failed on me.

Insight doesn't compile at all under MinGW/MSYS, so sorry I don't know. Basically in my case the issue is the X11 library doesn't exist on Windows. So I won't be helpful on that specific point.

Kos seemed to compile fine, though. No errors. Now to find some sample files to test things out with. Anybody know any good tutorials?

The best thing to do for me is to compile all KOS samples which are available in the /opt/toolchains/dc/kos/examples directory. But beware some of these samples will need additional libraries, i.e. you need to have some kos-ports installed (libGL for example). And you'll need to compile libraries from the /opt/toolchains/dc/kos/addons directory in some cases too.

[BlueCrab]

And you'll need to compile libraries from the /opt/toolchains/dc/kos/addons directory in some cases too.

The libraries in the addons directory are all compiled along with KOS. No need to compile them separately.

[UndeadDC]

I'm going to continue putting random questions about kos here for now. Anyway, I've been looking at the examples and I don't see any routines for frame buffering or vsync. Are these handled by KOS internally?

[BB Hood]

Its been a while for me as well and Im trying to get back into the game. There are two ways to draw stuff to the screen. Directly editing the frame buffer(vram) and using the PVR.

Frame Buffering:

You have to set it up it yourself:

I know (at least) three ways to do/simulate double buffering

Hardware double buffering - render the screen to a specific portion of video memory, then change the current screen pointer to that screen when you're done with it

Software double buffering - render the screen in main memory, and copy it over using DMA or store queues

Using textures - render the screen in main RAM and copy it to a texture in VRAM (or just render it to VRAM directly), then use the PVR hardware acceleration to draw that buffer to the screen.

Hardware double buffering is quite easy, but relies on mucking around with some of KOS's internals, which is why I haven't released it yet - I currently have no system I can use to build DC programs, and I don't want to release something like that without testing.

Anyway, I'll explain it here...

Normally, in 2D mode, the screen buffer starts at position 0 in video RAM, and extends as far as it needs to. This is all the video RAM is used for until you turn the 3D hardware on.

There is a function in KOS to change that screen pointer so that it points to somewhere else in video RAM. Basically, you pass it the VRAM address of the base of the screen (not the main memory address), and it'll immediately start displaying from that buffer.

That part's easy - now you just need to get a main memory pointer to it, so that you can write to it. That's quite easy too - you add the base address of video memory (can't remember it right now) to the address in video memory of the screen, and stick it into a pointer. Personally, I maintain a pointer to the backbuffer called vbuf_s (and another called vram_l), and vram_s (and vram_l) point to the currently displayed buffer, and are automatically set by KOS.

Then, you can easily build a flip function to switch between the two pages. Or three pages, or however many you want.

There is a better way though - KOS includes page flipping functions. However, the video modes are all set up so that they have only one page, so the page flipping functions will not work. There are two solutions - modify KOS (not a good idea), or hack the video mode tables at run time (which is a worse idea).

The PowerVR module does hardware double buffering, but I'm not exactly sure how.

More Sources:
viewtopic.php?f=29&t=103416&p=1045815&h ... g#p1045815
viewtopic.php?f=29&t=99999&p=1034312&hi ... g#p1034312

VSYNC:

Basically, you probably only want to draw once per vblank. If you're using the pvr for anything, use pvr_wait_ready(); and if you're not using the pvr, use vid_waitvbl(); and then do all of your drawing. - OneThirty8

Source: viewtopic.php?f=29&t=97767&view=next

[BlueCrab]

KOS actually does have internal support multi-buffering with the framebuffer -- assuming you initialize the video hardware with one of the multi-buffer modes. If you call vid_flip(-1), it'll handle updating the vram_s/vram_l pointers and all of that for you (once again, assuming you initialized the video hardware with one of the _MB modes).

With the PVR, it's always double-buffered (in that you're displaying one buffer and rendering to the other), so you don't have to worry about that at all.

[UndeadDC]

For some reason I can't run examples from the SD Card reader. I try to load the cdi file with dreamshell and the machine just resets. Should I try creating an ISO image instead? It works fine with GDEMU.