My new project is up!

[Chilly Willy]

Good idea. I can already tell you that Lapetus supports a lot of exotic features. Mine has them, but they're not up in the repositories, yet.

I noticed the code I checked out from the repo doesn't have CD support... is that in your local repo? That's kinda vital for many apps.

Lapetus, huh? I'll google for it. I'm still evaluating the tools and libs available for the Saturn.

 

[Amon]

I think CD support is the main thing that these libraries lack at the moment. CWX has a cdc replacement but I think that is all that has been done in those regards.

 

[mrkotfw]

There is an initialization function that does nothing. That's all I have. My local repository doesn't have any code that initializes the CD-drive except for that basic SMPC call.


To be honest, the CD-drive is one of the things I'll be implementing. I would first have to implement the cd9660 FS before i can do anything else.

 

[slinga]

Do you have a "Hello World" tutorial? I glanced through your CVS repository, I didn't seen any examples.

 

[mrkotfw]

Do you have a "Hello World" tutorial? I glanced through your CVS repository, I didn't seen any examples.

I do not. You'll need to look at the headers (for now).

 

[vbt]

(bump for news)

 

[mrkotfw]

(bump for news)

Hey VBT.

Unfortunately, I've stopped. I may come back to it one day and bring it all together.

My skills now are much better. I could potentially get a very minimal kernel implemented (basic (RR) scheduler with threads (no MM other than allocation from heap), synchronization primitives.

If the Saturn had an MMU, it would awesome to use the 4MB RAM cart as a backing store.

 

[Chilly Willy]

I think CD support would be more important than threading. Until you can use the CD, it's not very useful beyond little demos that are fully self-contained in the executable.

 

[television2000]

I was interested in it once but I absolutely had NO IDEA whatsoever about how to use it.

Documentation, documentation and more Documentation please.

But I'm intrigued about what will become of it if it ever does come back.

Now when I think about it, wasn't there a SGL alternative Rockin'B was working on ?

What happened to that ?

 

[mrkotfw]

I was interested in it once but I absolutely had NO IDEA whatsoever about how to use it.

Documentation, documentation and more Documentation please.

But I'm intrigued about what will become of it if it ever does come back.

Now when I think about it, wasn't there a SGL alternative Rockin'B was working on ?

What happened to that ?

The project... well, I haven't touched it in quite some time. Most likely, I'm going to rewrite the whole thing.

Chilly Willy, you're right about CD support. However, I think 4MiB (on the RAM cart) is more than enough to have a simple read-only file system. The CD library won't make games any better if there isn't a proper infrastructure.

For CD support, I'm a bit afraid of feature creep only because then I would like to add the ability to stream, etc.

 

[Chilly Willy]

Chilly Willy, you're right about CD support. However, I think 4MiB (on the RAM cart) is more than enough to have a simple read-only file system. The CD library won't make games any better if there isn't a proper infrastructure.

Ah, but there's the catch - how do you get the data into the ram cart without CD reading? The CD boot only loads the executable + data into the sdram, so you are limited to less the 1MB. It is then up to the program to load any other files to the ram cart.

 

[mic]

Ah, but there's the catch - how do you get the data into the ram cart without CD reading?

USB Datalink?

But yeah, CD reading is a nice feature.

 

[mrkotfw]

USB Datalink?

But yeah, CD reading is a nice feature.

Yup, pretty much.

Does CyberWarriorX's CDC library allow to read sectors and such? If so, that's really all we need...

 

[Chilly Willy]

Does CyberWarriorX's CDC library allow to read sectors and such? If so, that's really all we need...

I think his CDC library is fairly complete. If you want to see a minimal CD library, look at what is in lapetus... it seems to be the bare minimum needed to read sectors and play CDDA tracks. CyberWarrior has all that extra SH1 junk SEGA included to try to take some of the load off the other side when dealing with streaming.

 

[cafe-alpha]

I think his CDC library is fairly complete. If you want to see a minimal CD library, look at what is in lapetus... it seems to be the bare minimum needed to read sectors and play CDDA tracks. CyberWarrior has all that extra SH1 junk SEGA included to try to take some of the load off the other side when dealing with streaming.

SatCom uses CyberWarriorX's CDC library + SBL libraries for CD file system stuff.

You can find the corresponding sources files here and in "SatCom\satcom_lib\saturn\SBL" folder.

Everything is compiled from sources and works well for file reading

(however, I didn't tried CD track streaming)

edit:

USB Datalink?

But yeah, CD reading is a nice feature.

With satcom, it is possible to read files from PC instead of reading from Saturn's CD-ROM.

However, since a PC + action replay + communication link is required for this, it may not be interesting for the average user.

But it is enough for my own needs

(don't need to burn CD-ROM even if game data changed)

 

[mrkotfw]

I know a few of you guys have expressed interest in my project. I've long since abandoned it.

So I decided to restart the project! I found old traces of my code from 2009 and I've created a Git repository of it @ git://github.com/mrkotfw/libyaul.git

However, this isn't the entire story. I have tons of code scattered due to the fact that I didn't understand how version control worked back then. Stuff that isn't in the repository (but will be) include:

Exception handlers

SCU DMA

CPU DMA

Light gun support

SMPC support

SMPC PAD support (including multi-tap)

VDP1 "low-level" frame buffer access

Basic RBG0/1 support

Proper SCU interrupt support

And a few other things that I can't remember.

It's also MIT licensed.

If you would like to help, I would love that. However, the only thing I ask is that you adhere to the directory structure and especially the coding style. I am anal retentive when it comes to this!

 

[Chilly Willy]

Sounds great! The license in particular is nice - there are things you just can't use a GPL license on, which means you can't use lapteus. Doom port? Fine - it's already GPL. Sqrxz? No good... it's not GPL, or even open source. MIT allows that.

Once you got things collected in the repo, I'll do a clone and see about getting it working with my gcc 68000/SH2 toolchain I use for 32X stuff. A nice toolchain and an MIT licensed SDK would really help Saturn homebrew.

 

[mrkotfw]

Sounds great! The license in particular is nice - there are things you just can't use a GPL license on, which means you can't use lapteus. Doom port? Fine - it's already GPL. Sqrxz? No good... it's not GPL, or even open source. MIT allows that.

Once you got things collected in the repo, I'll do a clone and see about getting it working with my gcc 68000/SH2 toolchain I use for 32X stuff. A nice toolchain and an MIT licensed SDK would really help Saturn homebrew.

Thanks for that. It is rather a shame that Lapetus is GPL'd. Otherwise, it'd be faster to get a better library going. What is different from just a run-of-the-mill built toolchain?

I pushed the code (very untested!) for SCU DMA. It supports both direct and indirect DMA.

 

[mrkotfw]

Also, I would like to add that how my library handles errors is that it panics. Adding error handling for the programmer more than "Assert on foo.c some-expression" is an overkill on the Saturn.

Mind you, these are assertions (panics), not say an exception raised by the CPU.

 

[Chilly Willy]

My toolchain is just a "standard" build of gcc. It's just most folks have no idea how to build cross-compilers, so I made a makefile to help build the two separate cross-compilers targeted at the right processors in a uniform manner. Then I coupled that with custom linker scripts and some skeleton code so that you have the basis for C and C++ programs ready to go. I just have a minimum of code... basic functions to init the screen and print to it... that sort of thing. So you have a nice up-to-date compiler for the CPUs, and skeleton code for use in porting or making your own code for the two main languages. Oh, my toolchain builds the obj-c and objc++ compilers, but I don't yet have examples for them. I should really do that some time.

If you check the thread over in the Genesis/SCD/32X forum, you'll see I have a step-by-step tutorial on building the cross-compilers, then the basic examples (TicTacToe in C and C++ for Genesis and 32X), and then a few ports I've done that can be compiled with the toolchain as a more complete example than the basic examples.

So for the Saturn, I'd need to alter my 32X linker scripts a little, change my crt0.s file a little, and allow for the difference in hardware for things like setting up the screen and printing (or more complicated things for the ports). A console like the Saturn is more complex on the hardware side of things, so I've held off a bit while I checked out the SDK available on the Saturn. I don't want to use the old SEGA SDKs (SGL/SBL) mainly because they're just object files compiled under really old compilers, making them incompatible with my toolchain. That and they're proprietary. Hence the need for lapetus or libyaul.