As title. We technically support it, but I don't know if it's ever been used, or how it would be used. There is a reference to its use in kernel/fs/fs.c 's fs_write with a note to fix, and that may be a thing to do as well with an example of its use.

In trying to use examples/dreamcast/libdream/320x240/320x240.c to validate changes to video, I found that it happened to override default the KOS INIT which sets Preemptive mode and defaults to cooperative. This caused a problem where the usleep at the end of the example would never return.

At the very least the functionality of usleep has to be corrected to work in cooperative threading mode. At best, we should have some thorough testing of it to root out other issues and properly support it. As an alternative though, just ditch it.

After installing the main parts of the toolchain. I circled back to utils/dc-chain and "make gdb" in terminal. Logs are attached.

build-gdb-12.1.log
build-gdb-9.2.log

build-gcc-sh-elf-4.7.4-pass1.log

I think the important portion of the log is:

configure: error: Specified CC_FOR_BUILD doesn't seem to work
mkdir build-x86_64-apple-darwin21.6.0
mkdir build-x86_64-apple-darwin21.6.0/libiberty
Configuring in build-x86_64-apple-darwin21.6.0/libiberty
make[2]: *** [configure-gmp] Error 1
make[2]: *** Waiting for unfinished jobs....

After setting use_custom_dependencies=1, the dependencies aren't unpacked, nothing happens.

While building and running examples to test changes to core video functionality ( #150 ) I realized that despite being able to see the code of any number of examples it was difficult to tell if the output was as expected. Sure, there was a pattern and text in examples/dreamcast/video/bfont but was it the right colors, pattern, and text?

So the proposal here would be to, as a standard practice, include pixel-perfect screenshots for examples that have visual output, and transcripts of the expected output for those that have text output. In lieu of either, more detailed explanations of the expected output would be useful.

Aside from mere comprehension, screenshots and transcripts could form the basis of automated regression testing.

So, with that, I open the floor to other sorts of possible suggestions for improving and expanding the examples.

Developer, zcrc, (from the Simulant Discord channel) has reported a bug with getting crashes upon exiting with the MMU enabled.

He has graciously created a reproduction case here: https://gist.github.com/pcercuei/0dc33dbf8d532a52ff5c986091337565 and has stated that it will work by default, but the issue can be triggered by changing the #if 1 at the bottom to an #if 0, leaving the MMU on as main exits.

PowerDream/kernel/build on  master [!?] 
[I] ➜ make
[  5%] Linking C executable kernel
/opt/toolchains/dc/sh-elf/lib/gcc/sh-elf/4.7.3/../../../../sh-elf/bin/ld: CMakeFiles/kernel.dir/fs/initrd.c.o: in function `initrd_mount':
/home/ross/PowerDream/kernel/fs/initrd.c:19: undefined reference to `_basename'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/kernel.dir/build.make:304: kernel] Error 1
make[1]: *** [CMakeFiles/Makefile2:104: CMakeFiles/kernel.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

My Dreamcast OS uses KallistiOS to help do a lot of things and in the initrd module it needs the basename function which for some reason is not compiled.

Opening up this issue to track the current performance/reliability problems with the KOS network stack.

Examples include:

• I updated the httpd-ack server (https://gotwalls.com/) from KOS 1.x+lwIP to KOS 2.x with its native networking stack, and now transfer from DC to PC tops out around 700kB/s and shows rapid up/down fluctuations as if the system is pausing/unpausing the transfer rapidly (possibly waiting on buffers mentioned below?)
• @DC-SWAT wrote an FTP server module for DreamShell; transferring from DC to PC does not exceed 750kB/s and transferring from PC to DC results in ~1.5kB/s speeds and dropped connections.
• @ljsebald wrote a simple speed testing utility to test connecting a DC and PC over the network and transferring a small buffer. In my test run using the BBA, it showed 10485760 bytes received by the Dreamcast console in 261479 milliseconds, or 40.10188kB/s.

During a conversation with @ljsebald, he suggested several things which need improvement upon:

• there's definitely a bug if you use recvmsg and specify the MSG_WAITALL flag... and the connection gets dropped in the middle of waiting... that will just end up waiting forever :/

• There may be a bug with connection close
• Allocating network buffers ahead of time would allow increased performance at the expense of memory use, so this preferably could be a tuneable option. There's no way to do a zero-copy network stack in KOS's architecture, but it should be possible to drastically reduce the number of copies by pre-allocating buffers. Optimally, the only copies should be when one calls send() to copy into an internal buffer, and when one calls recv() to copy out of the internal buffer into the specified destination.

To quote @ljsebald:

one of the biggest bottlenecks of the current design of the network stack is that it is constantly doing memcpy()
like... all over the place
[...]
right now, when you do a tcp socket and call send, this is what happens:

• net_tcp_sendto - memcpy into internal buffer, call tcp_send_data
• tcp_send_data potentially shifts around said internal buffer with some more memcpys, calls net_ipv6_checksum_pseudo/net_ipv4_checksum to checksum the data (which should always be aligned, at least, so takes the fast-path), then calls net_ipv6_send
• net_ipv6_send does another memcpy before calling the network adapter's transmit
  -- If using a bba, this does a g2_write_block_32 (which is basically another memcpy, but this is unavoidable)
  -- if using a lan adapter, you have a similar story, but with an even slower 8-bits at a time write
  -- if using a modem, it's... worse
• ppp_tx gets called, which does another checksum (unavoidable), then does a modem transmit (once again an 8-bit at a time g2 write).

the g2 writes are unavoidable, as is the first memcpy and all the checksums. but what tcp_send_data and net_ipv6_send are doing can be "fixed" a bit.

Additionally, the driver for the 10mbps LAN adapter is in need of some work, as well. When running the aforementioned speed testing utility on a LAN adapter, the debug output repeatedly prints "genwait_wait: called interrupt".

Hi,

I am currently working on setting up a development environment for my dreamcast. Is this repo the official one ? or the one on sourceforge is still maintained ?

Thank you.

I recently wanted to set up a toolchain for DC and stumbled across KallistiOS. I'm not trying to be mean but the setup you have for building KOS is a disaster and I honestly want to help fix it.

Steps to fixing:

• Move everything that isn't part of library into another repo for building an SDK, like this.
• Install toolchains to /usr like it's intended to be! (solves 99% of your build environment issues)
• Consolidate all your makefiles for KOS into a single makefile.
• Eliminate all the environmental setup shell scripts. All the vars belong in the makefile.

I'm in the progress of replacing the "dc-chain" utilities with a single easy to use POSIX script. I realize I'm reinventing the wheel here but the existing system is too clever by half. If anything is moved then it breaks.

If you wish to contact me, I'm Gravis on Freenode and EFNet.

Instead of using the #if defined(_arch_whatever) stuff like KOS does currently, KOS should use the macros defined by GCC to determine the platform. These macros can be found here: https://sourceforge.net/p/predef/wiki/Architectures/

The Conio example is broken in two different ways and has been ever since KOS2. I intend to fix it, but I have a lot of stuff I'd like to get around to first, and this is also a nice task for someone looking to make a contribution to KOS.

1. We've verified that ever since KOS2, with any toolchain/GCC version, the example didn't work and gives some kind of warning on thread initialization about using a deprecated path that I'm assuming has changed. It will build with the older toolchains (4.7.4 and 9.3.0), but it's a black screen and doesn't do anything.

2. Secondly, there is just absolutely NO WAY that this is a valid C program. The new GCC12 toolchain RIGHTFULLY doesn't even compile it. It has a whole common header of dozens and dozens of variable declarations which are not extern, getting included everywhere, and duplicated in each translation unit, causing duplicate symbol errors... I have no earthly idea what the older GCC versions were doing letting this slide, but it's not correct.

Somebody needs to fix the threading then declare the variables within the common header extern, copying the existing definitions from the header into only a single translation unit, deduplicating the symbols.

We just recently added the option for enabling the GCC builtin stdlib replacement functions from the user's environ.sh. Cursory testing all seemed fine. @andressbarajas has already cleared out the warnings that arose when building like that...

However, it seems @darcagn has just discovered that we get unresolved Newlib symbol errors when we enable -flto when commenting out -fno-builtin from within environ.sh. I was able to reproduce the issue, and here's but a sample from the first example failing to build:

/bin/ld: /opt/toolchains/dc/sh-elf-13.1.0/bin/../lib/gcc/sh-elf/13.1.0/../../../../sh-elf/lib/libc.a(libc_a-exit.o): in function `exit':
/opt/toolchains/dc/kos/utils/dc-chain/build-newlib-sh-elf-4.3.0.20230120/sh-elf/newlib/../../../newlib-4.3.0.20230120/newlib/libc/stdlib/exit.c:65: undefined reference to `__exit'

Probably not a very high priority, as we clearly state that the path isn't as well tested/supported and everything else seems to work fine, but just wanted to capture it in an issue.

@darcagn has just updated the incredibly out-of-date Doxygen documentation and has uploaded it here: https://kos-docs.dreamcast.wiki/index.html

...and despite the fact that it's missing major content like the main page, if you look at the documentation for the actual code, we've done a really good job keeping things documented in-line via comment tags, and we've even got a lot of things organized nicely into modules, to the point that this documentation is pretty useful, and we should keep going with fleshing it out, imo.

Some places I can immediately see that could use some love:

• top-level main page
• doc/goals.txt (if it's still accurate) can become a TODO list within Doxygen
• Bluecrab's diligently maintained doc/CHANGELOG can become an actual Doxygen changelist
• FAQ and pretty much everything else in doc/ could become real content
• Some data structures are missing descriptions: https://kos-docs.dreamcast.wiki/annotated.html
• any random functions or struct fields within the code that anyone finds with holes in it

I'm using the latest XCode Commandline Tools, and following the toolchain instructions from the wiki. I have cloned the current state of master and have received a failure during the GCC 9.3.0 portion of the build with the following error:

Using ../../gcc-9.3.0/gcc/config/sh/sh.c' for machine-specific logic. Using ../../gcc-9.3.0/gcc/config/sh/sh.md' as machine description file. Using the following target machine macro files: ../../gcc-9.3.0/gcc/config/vxworks-dummy.h ../../gcc-9.3.0/gcc/config/sh/little.h ../../gcc-9.3.0/gcc/config/sh/sh.h ../../gcc-9.3.0/gcc/config/dbxelf.h ../../gcc-9.3.0/gcc/config/elfos.h ../../gcc-9.3.0/gcc/config/sh/elf.h ../../gcc-9.3.0/gcc/config/sh/embed-elf.h ../../gcc-9.3.0/gcc/config/newlib-stdint.h ../../gcc-9.3.0/gcc/config/./sysroot-suffix.h ../../gcc-9.3.0/gcc/config/initfini-array.h Using host-darwin.o host-i386-darwin.o for host machine hooks. kos is an unknown thread package make[2]: *** [configure-gcc] Error 1 make[1]: *** [all] Error 2 make: *** [build-sh4-gcc-pass2] Error 1

Any idea what's going on here?

It looks like the latest update of dc-chain force to have a version for every component used by GCC. ISL isn't mandatory as it isn't required for GCC 4.x.

ERROR: ISL version must not be empty

net_udp.c: In function ‘net_udp_input6’:
net_udp.c:1264:39: warning: taking address of packed member of ‘struct ipv6_hdr_s’ may result in an unaligned pointer value [-Waddress-of-packed-member]
 1264 |         cs = net_ipv6_checksum_pseudo(&ip->src_addr, &ip->dst_addr, size,
      |                                       ^~~~~~~~~~~~~
net_udp.c:1264:54: warning: taking address of packed member of ‘struct ipv6_hdr_s’ may result in an unaligned pointer value [-Waddress-of-packed-member]
 1264 |         cs = net_ipv6_checksum_pseudo(&ip->src_addr, &ip->dst_addr, size,
      |                                                      ^~~~~~~~~~~~~
net_udp.c:1291:39: warning: taking address of packed member of ‘struct ipv6_hdr_s’ may result in an unaligned pointer value [-Waddress-of-packed-member]
 1291 |         cs = net_ipv6_checksum_pseudo(&ip->src_addr, &ip->dst_addr, size,
      |                                       ^~~~~~~~~~~~~
net_udp.c:1291:54: warning: taking address of packed member of ‘struct ipv6_hdr_s’ may result in an unaligned pointer value [-Waddress-of-packed-member]
 1291 |         cs = net_ipv6_checksum_pseudo(&ip->src_addr, &ip->dst_addr, size,

I'll look at this at some point, not sure if they're false positives or actual problems...

Currently, the sound driver binary sound.drv is included in the KOS tree so that users do not need to build it from source (and, therefore, do not need the ARM compiler/tools installed unless the ARM code is to be modified), but it has created an annoyance for many users in that it shows up in git status as a changed file once KOS is compiled, and so it also frequently gets included accidentally in PRs submitted on Github.

We should come up with a better solution for this situation.

Firstly, the sound.drv in the tree is 3332 bytes with the md5sum b18d5e31f1faf34fe3ea8754c94ff946 (unknown which version of compiler tools it was built with), but GCC 8.4.0 and 8.5.0 toolchains reliably produce a binary of 3244 bytes with the md5sum 481d0160dab367afb3bfe5ccd4daa2d8 for myself and other users. Perhaps an initial solution would be to simply update the stream.drv file with a newer version with this md5sum, so that the file isn't frequently changing in the first place for anyone on a modern ARM toolchain.

As a package maintainer, i'd like to see KallistiOS begin releasing versions to ease the packaging process.

I'm mostly interested in making a kallistios_utils-1.0.0 (or whatever) package with tools like scramble, makeip, genromfs, wav2adpcm, vqenc, dcbumpgen, etc.

The idea is simplifying availability of these tools will increase the ease of releasing dreamcast software, and being able to build it without cloning all of KallistiOS and setting up a full SDK.

Tested on GCC 9.3.0 and 13.2.0

modplug_test seems to work fine, but prints garbage to console.

Run once:

Run twice:

When building the SDK after compiling the compilers it's missing exports-dreamcast.txt

While perusing the VMU filesystem API, I came to the realization that we cannot be handling a certain edge case properly when writing VMU minigames to flash.

In the scenario when a VMU has enough free blocks for a minigame, yet there are not enough sequential free blocks (starting at block 0) to fit the entire game, we seem to just be partially writing and errorring out early, potentially corrupting the file and maybe the VMU.

In order to handle this correctly, KOS will need a defragmentation operation for the VMU. This is fine, because I happen to have one in ElysianVMU that I will port over once I get some time, but I wanted to let everyone know that this was an issue in case someone wanted to do it before I did or in case our users encounter the issue.

Hello,

Is it going to be possible to maintain the original drive for this ODE?

Thanks

This is a very minor issue that I can get around to eventually, but it's going to be pretty annoying... We already have examples of beeping and rendering to the VMU screens that show off this issue...

If you begin playing a tone on the VMU or if you render some text or presumably if you cause the puru pack to rumble, then exit an example, it will continue playing indefinitely. That is until you power cycle the DC, load another example, or physically take the peripheral out and put it back in.

Basically before the maple peripheral drivers shut down, they need to be sending stop commands to the devices for these kinds of operations; however, if you look at the top level maple_shutdown() driver callback, notice it's actually shutting down the maple hardware before even calling shutdown on each peripheral, so this will either have to be swapped or addressed in another manner.

Hi, a lock release is missed before returning -1. Should it be a bug?

It’s now impossible to build KallistiOS using GCC 4.x since LTO (Link Time Optimization) is enabled.

Some exports aren't properly defined, as shown here. As explained by @pcercuei:

fdopen() is in stdio.h and needs _POSIX_C_SOURCE to be defined to POSIX 2001 minimum. The generated code validates those conditions but we need to fix genexports.

1. Build the compiler

Error: "cp: gcc-8.4.0/ is a directory (not copied)"
The cp config.guess config.sub gcc-*/ command is not working, I have to copy the files to gcc-8.4.0 & gcc-9.3.0 manually.

2. make build

Error: fatal error: 'new' file not found

#include <new>
         ^~~~~

libstdc++ had been replaced with libc++ since 10.9, so now I have to edit the

CXX := "$(CXX) -stdlib=libc++ -mmacosx-version-min=10.7"

in order to link the c++ libraries

3. Build KOS

Error: ext2fs.o: No such file or directory (or other .o files)
Compiling with 16 cores CPU requires multiple retries (race condition?), but running make -j 2 can build it successfully.

When using my 32GB Sandisk sd card in an adapter and I try and open a directory and ready from it, my dreamcast restarts. I tracked the restart to this line:

DIR* dr = opendir(directory); // Works fine
while ((de = readdir(dr)) != NULL) { ... // Restarts dreamcast here

NOTE: I can save files but I just cant browse a directory. I can save files in root or any subdirectory of the SD card.

For example while compiling libGL from https://github.com/KallistiOS/kos-ports, compilation of gl-sh4-light.S fails due to missing -c parameter:

kos-cc gl-sh4-light.S -o gl-sh4-light.o
/home/kouta/dctoolchain/sh-elf/lib/gcc/sh-elf/9.3.0/../../../../sh-elf/bin/ld: /home/kouta/dctoolchain/kos/lib/dreamcast/libkallisti.a(init.o): en la función `arch_main':
/home/kouta/dctoolchain/kos/kernel/arch/dreamcast/kernel/init.c:254: referencia a `_main' sin definir

Adding -c as a parameter in Makefile.rules fixes this:

diff --git a/Makefile.rules b/Makefile.rules
index 7551cb37..05280aa5 100644
--- a/Makefile.rules
+++ b/Makefile.rules
@@ -37,7 +37,7 @@ endif
        kos-as $< -o $@
 
 %.o: %.S
-       kos-cc $< -o $@
+       kos-cc -c $< -o $@
 
 subdirs: $(patsubst %, _dir_%, $(SUBDIRS))

I accidentally posted this on a mirror, so re-posting here.

http://gamedev.allusion.net/docs/kos-2.0.0/structvmu__pkg.html
http://gamedev.allusion.net/docs/kos-2.0.0/structvmu__hdr.html

The pkg struct is converted into the hdr struct for easy usage with VMU save files, however almost every variable has a different type or number of elements depending on which struct you look at and usually the pkg vars are larger than the hdr vars. This can cause issues if you make a vmu_pkg struct with a 20 char "app_id" name and try to use it to make a save file, the last 4 chars will be cut off since the header's var is 4 chars shorter.

From what I can tell, this appears to be an oversight of sorts. Maybe they used to be the same, but then an update changed one struct, but not both. I believe the vmu_hdr struct is correct since it is the header format http://mc.pp.se/dc/vms/fileheader.html

Tested using GCC 9.3.0 and 13.2.0

Besides these errors, the example seems to work fine. They should still be fixed though.

possible patch to enable kos to cleanly compile without gimping the optimizer

--- old/kernel/arch/dreamcast/include/dc/pvr.h    2019-08-10 13:23:29.420000000 -0400
+++ new/kernel/arch/dreamcast/include/dc/pvr.h    2019-08-10 13:41:04.920000000 -0400
@@ -834,8 +834,15 @@
     \return                 The packed coordinates
 */
 static inline uint32 PVR_PACK_16BIT_UV(float u, float v) {
-    return (((*((uint32 *) &u)) >> 0) & 0xFFFF0000) |
-           (((*((uint32 *) &v)) >> 16) & 0x0000FFFF);
+    union
+    {
+        float f;
+        uint32 i;
+    } _u, _v;
+    _u.f = u;
+    _v.f = v;
+    return ((_u.i >> 0) & 0xFFFF0000) |
+           ((_v.i >> 16) & 0x0000FFFF);
 }
 
 /** \defgroup pvr_commands          TA command values```

Just wanted to make sure we made an issue to capture @cepawiel's recent findings:

• When using the BBA and network stack, KOS is responding to all broadcast ARP requests with its IP/MAC address, regardless of whether it has the requested IP address or not

Probably not a big deal, as it doesn't seem to have ever caused problems, but we probably shouldn't be doing this for performance and correctness reasons.

Im having issues using the fatfs module for my SD card.

I used the ext2 example as a base and wrote a hello.txt file to the root of the SD card. The file doesn't appear on the SD (with text content) until fs_fat_unmount() or fs_fat_shutdown() which is fine but I want to actually save without shutting down or unmounting.

Then I looked at fs_fat_sync(); and thought it was the solution. I tried fs_fat_sync("/sd"); but it only created an empty HELLO.TXT file. No text content. I also tried fs_fat_sync("/sd/hello.txt") but the file didnt save at all(Just an empty root directory). Keep in mind that I deleted all the contents of the root directory in-between each test. Is fs_fat_sync() working correctly?

It looks as though our Newlib configuration for modern C++ threads, mutexes, and general concurrency is somehow incomplete. Given the following trivial thread usage:

#include <stdio.h>
#include <thread>

KOS_INIT_FLAGS(INIT_MALLOCSTATS);


void thd() {
    printf("asdf\n");
}

int main(int argc, char **argv) {
    std::thread thd1(thd);

    return 0;
}

You will be met with the following compiler error:

out_of_memory.cc: In function ‘int main(int, char**)’:
out_of_memory.cc:12:25: error: no matching function for call to ‘std::thread::thread(void (&)())’
   12 |     std::thread thd1(thd);
      |                         ^
In file included from /opt/toolchains/dc/sh-elf/sh-elf/include/c++/12.2.0/thread:43,
                 from out_of_memory.cc:2:
/opt/toolchains/dc/sh-elf/sh-elf/include/c++/12.2.0/bits/std_thread.h:156:5: note: candidate: ‘std::thread::thread(std::thread&&)’
  156 |     thread(thread&& __t) noexcept
      |     ^~~~~~
/opt/toolchains/dc/sh-elf/sh-elf/include/c++/12.2.0/bits/std_thread.h:156:21: note:   no known conversion for argument 1 from ‘void()’ to ‘std::thread&&’
  156 |     thread(thread&& __t) noexcept
      |            ~~~~~~~~~^~~
/opt/toolchains/dc/sh-elf/sh-elf/include/c++/12.2.0/bits/std_thread.h:120:5: note: candidate: ‘std::thread::thread()’
  120 |     thread() noexcept = default;
      |     ^~~~~~
/opt/toolchains/dc/sh-elf/sh-elf/include/c++/12.2.0/bits/std_thread.h:120:5: note:   candidate expects 0 arguments, 1 provided

So basically there is no available constructor template for std::thread, even though the class itself is there. I'm almost positive this is some Newlib configuration issue with our KOS threading model not defining and mapping everything the __GTHREAD model it was based on was doing. This is probably a relatively straightforward thing which may just be a few #defines and/or mapping a few things to kthreads.

I'm creating this issue, because I have a bunch on my plate with ElysianVMU stuff right now, and want to finish up the TLS stuff first, but this could be some low-hanging toolchain fruit that would yield great gains for C++ users.

Works on 4.7.4 compiler, but doesn't work on 9.3.0 or 12.2.0. On either of these compilers, one just sees a strip of colors on the left side of the screen.

Try this:

• fopen(some_path, "w"); fwrite(...); fclose(...);
• fopen(some_path, "a"); fwrite(...); fclose(...);

The result is that only the content from the first write appears in the file. Instead of using append, opening with "r+" the second time and seeking to the end of the file allows you to write.

The option for use DESTDIR to change the final destination is in the makefile but when you use it the build fails on pass two of building gcc. The error states is that it cannot locate "kos/thread.h".

I'm using <dirent.h> for filesystem handling but it seems my code no longer compiles properly. I updated KOS about two months ago since I was using an old version beforehand.

The file which is failing to compile in KOS is linked below, and is identical across PC and DC ports:
filesystem_linux.cc

This has always worked without any modifications needed for KOS over the years. I understand if it needs modification for GCC9, but it looks like it is pulling different headers from two different spots (sh-elf and kos-shelf/dirent) which might be formatted differently. Changing, in the fileystem_linux.cc code, the include for <dirent.h> to <sys/dirent.h> stops these errors but then I get undefined references at link time.

I am compiling with WSL2/Debian, Win10 2004(fast insider ring). KOS is as-is pulled from git and up-to-date.

Build output and errors:

I can't tell what is failing where. To note, the PC version uses much of the same filesystem code on new GCC versions as well and does not encounter an issue.

Any advice is greatly appreciated.

All of the various hardware subsystems and drivers need to read/write to registers. Due to them being written by different people at different times, or being brought in from differing origins, they can differ drastically in how they are addressed, defined, or accessed. If this were standardized, any amount of the code would be more readable and serve as better documentation.

The Maple code might be an exemplar of how to go about this:
In https://github.com/KallistiOS/KallistiOS/blob/master/kernel/arch/dreamcast/include/dc/maple.h#L68

We define a base address, then follow it with defines that have the offset of each register from that base:

#define MAPLE_BASE 0xa05f6c00 /**< \brief Maple register base */ #define MAPLE_DMAADDR (MAPLE_BASE+0x04) /**< \brief DMA address register */

A macros are then defined:
`#define maple_read(A) ( ((vuint32)(A)) )

/** \brief Maple memory write macro. */
#define maple_write(A, V) ( ((vuint32)(A)) = (V) )`

That is used like this:
maple_write(MAPLE_RESET1, MAPLE_RESET1_MAGIC);

On the other end of the scale is the video/framebuffer system:
In https://github.com/KallistiOS/KallistiOS/blob/master/kernel/arch/dreamcast/hardware/video.c#L410

We make a pointer to the registers base:
static vuint32 *regs = (uint32*)0xA05F8000;

Then set them all by raw offsets to that base with raw magic numbers:
/* Blank screen and reset display enable (looks nicer) */ regs[0x3A] |= 8; /* Blank */ regs[0x11] &= ~1; /* Display disable */

Sort of halfway between is something like https://github.com/KallistiOS/KallistiOS/blob/master/kernel/arch/dreamcast/include/dc/ubc.h#L32 :
#define BARA (*((vuint32*)0xFF200000)) /**< \brief BARA register. */ #define BASRA (*((vuint8*)0xFF000014)) /**< \brief BASRA register. */

Here the register addresses are each in a define, but not built off each other, not named as verbosely, and the casting is built-in.

Reading and writing is then handled by inline functions without intermediary macros:
static inline void ubc_break_data_write(uint32 address) { BASRA = 0; /* ASID = 0 */ BARA = address; /* Break address */

What I'd propose to proceed would be to choose the best sorts of characteristics from different examples we have (maple seems to be the most well-structured, but might be overkill too). This could go hand in hand with some apparatus in the doxygen/documentation that would help easily view/search these values. Among other things, it would be determining:

• How should we name register ranges, and individual ones? Based on examples it would seem "SUBSYSTEM_BASE" is how many have been done so far: MAPLE_BASE in maple.h or GAPS_BASE in broadband_adapter.c. There are also a number though that go for "SUBSYSTEM_TYPE_BASE" like SPU_RAM_BASE (duplicated in snd_stream.c and snd_iface.c), PVR_RAM_BASE in pvr.h. With this sort of naming, we might rename maple to MAPLE_REGS_BASE. Then individual ones would swap out BASE for the specific register name. So "SUBSYSTEM_REGS_REGNAME".
• How should we name register values/contents and bitwise masks? Certainly this naming should flow from the above, but having the whole reg define be a prefix for each piece of content in it or each mask may be overly verbose.
• How should we go about reading/writing to these? It might make sense to have the maple defines be something along the lines of a globally included macro, with variations for 8 and 16 bit. Could also include bitwise reads/writes to match whatever standard we come up with for defining values/shifts/masks.
• Hows about undefined register spaces? Certainly these have been noted in places where writing to a register is required for operation (like PVR_UNK_00A8 et al) or needs to be defined for proper operation (like unks in packed flashrom blocks). Typically if we have a list of values 1, 4, 8; I'm in favor of listing the '2' even if we don't know what it is. It's, to my mind, like leaving a todo note.

Tested using GCC 9.3.0 and 13.2.0
Used an SD card formatted to ext2 with KOS's other SD example

All images transfer successfully to SD, but upon completion the example crashes instead of exiting gracefully.

So I finally tracked down that utils/ldscripts/shlelf.xc is used for everything. However, it contains an absolute path which isn't correct. In searching for the origin of ldscripts from binutils (binutils-x.xx/ld/emulparams), I found this would be an excellent opportunity to add "dreamcast" or something as a target by making a linker template script. If nothing else, this linker script should at least be copied over the shlefl.xc after binutils generates it for the toolchain.

Hello! When compiling a project (using DreamSDK), make cannot find include png.h! Even the example does not compile.

(https://user-images.githubusercontent.com/44033147/69899616-caf9bb00-138a-11ea-9504-5ad91acc3c24.jpg)

On Ubuntu 21.10 and 22.04, when making the toolchain, I have been able to reproduce this error by having the package flex installed.

checking for bison... bison -y checking for flex... flex checking lex output file root... configure: error: cannot find output from flex; giving up make[2]: *** [Makefile:4234: configure-gmp] Error 1 make[2]: Leaving directory '/opt/toolchains/dc/kos/utils/dc-chain/build-gcc-sh-elf-4.7.4' make[1]: *** [Makefile:856: all] Error 2 make[1]: Leaving directory '/opt/toolchains/dc/kos/utils/dc-chain/build-gcc-sh-elf-4.7.4' make: *** [scripts/gcc-pass1.mk:16: build-sh4-gcc-pass1] Error 1

However, running make again with the package flex-old fixes the error.

When trying to launch ./download.sh in the dc-chain folder it outputs this error:

*** Downloader Utility for Sega Dreamcast Toolchains Maker (dc-chain) ***

Downloading Binutils 2.34...
curl: --continue-at and --remote-header-name cannot be combined
curl: try 'curl --help' for more information

Not sure what I did wrong or if it's a KOS issue

I believe lwip was removed from kos-ports so there is no way to compile the examples in lwip folder.

Tested on 9.3.0 and 13.2.0

parallax/rotocube shows a black screen with some red dots at the top.
parallax/raster_melt crashes:

I'm just creating this as some notes to myself (or a future contributor). There are apparently quite a few different blocks in the flashrom to store ISP settings depending if you used PlanetWeb, DreamKey, DreamPassport etc. and KOS currently doesn't support them all. Some blocks that I know about:

• 0xC6-C8 - this is created by DreamKey 3.0 to store the base PPP settings. I've started an implementation in this PR but it only reads the most obvious things - the majority of the blocks aren't read
• 0xC9-CB - this is created by DreamKey 3.0 when you set up email and proxy settings. It contains (at least) the following data:
  • Email username and password
  • Email addresss
  • SMTP + pop server
• 0x60 - this seems to be created by Quake 3 if you try to set a PPPoE configuration (e.g. just set username and password, and leave all addresses at 0.0.0.0). POD Online apparently reads Q3 settings.

See discussion on #217 for some of the rationale.

Basically, it _feels wrong to need to include <arch/arch.h> in order to get the initialization flags functionality, especially since most of it is probably not arch-specific.