My new project is up!

Chilly Willy said:
Ah - so people would copy the bootstrap.S from the common directory to their own when making a project, then edit it. It still needs the include path.
smile.gif

Yeah, definitely. I didn't think -I applied to the incbin directive.
 
mrkotfw said:
So in this case, sys_init.o is the AIP. For our case, wouldn't we simply want to jump to 0x06004000 just as stated?

From the perspective of the ROM, it forms part of the AIP. sys_init.o just continues executing whatever comes after it in memory, so you do need to place something there.

The first read file is loaded to the address specified at offset 0xF0 in the IP (which translates to 0x60020F0 when it's loaded into memory), it doesn't have to be 0x6004000. Of course you can decree that it will always be some fixed address and use that, but you're saving a total of 2 bytes at the cost of flexibility.

If the alignment works out then at least in theory you may be able to set the first read address to directly after sys_init.o and avoid the stub altogether, or reduce it to a single nop.
 
antime said:
From the perspective of the ROM, it forms part of the AIP. sys_init.o just continues executing whatever comes after it in memory, so you do need to place something there.

The first read file is loaded to the address specified at offset 0xF0 in the IP (which translates to 0x60020F0 when it's loaded into memory), it doesn't have to be 0x6004000. Of course you can decree that it will always be some fixed address and use that, but you're saving a total of 2 bytes at the cost of flexibility.

If the alignment works out then at least in theory you may be able to set the first read address to directly after sys_init.o and avoid the stub altogether, or reduce it to a single nop.

Great explanation. Makes sense. That would also then explain appending the arflasher binary at the end.

I'm pushing the fixes coming in soon which should simplify Joe's changes.
 
mrkotfw said:
Great explanation. Makes sense. That would also then explain appending the arflasher binary at the end.

I'm pushing the fixes coming in soon which should simplify Joe's changes.

At some point you should just go ahead with the CD support in the dram example. That's the logical one to have make binaries AND cd iso since it's one you might actually run on real hardware to check your cart. So it is an example of cd support AND useful!
cool.gif
 
Chilly Willy said:
At some point you should just go ahead with the CD support in the dram example. That's the logical one to have make binaries AND cd iso since it's one you might actually run on real hardware to check your cart. So it is an example of cd support AND useful!
cool.gif

Good point. But by CD support you mean you build an ISO, but not communicate with the actual CD-ROM other than turning it on or off
wink.gif


By the way, are you in any way interested in having "full" C++ support? There's more to it than just the linker script (I have your changes pushed in long ago) I think.
 
mrkotfw said:
Good point. But by CD support you mean you build an ISO, but not communicate with the actual CD-ROM other than turning it on or off
wink.gif

Well, I want BOTH eventually, but I meant just writing a program that booted from CD, even if that's all it did... like the DRAM cart test.

By the way, are you in any way interested in having "full" C++ support? There's more to it than just the linker script (I have your changes pushed in long ago) I think.

I noticed... "full" C++ support would make it easier to do certain things, like a Saturn version of scummvm. That would be possible with the 4MB cart as I've messed around with the N64 version, which runs in just 4MB of ram. That would also need CD support, as in reading files off the CD.

I think full CD support is more important than full C++ support. Get the former going first, THEN work on the latter. That's my feeling on the matter.
cool.gif
 
Chilly Willy said:
Well, I want BOTH eventually, but I meant just writing a program that booted from CD, even if that's all it did... like the DRAM cart test.

I noticed... "full" C++ support would make it easier to do certain things, like a Saturn version of scummvm. That would be possible with the 4MB cart as I've messed around with the N64 version, which runs in just 4MB of ram. That would also need CD support, as in reading files off the CD.

I think full CD support is more important than full C++ support. Get the former going first, THEN work on the latter. That's my feeling on the matter.
cool.gif

Gotcha. I was actually beating around the bush a bit, but I was asking if you would like to help get libyaul up to speed with that while I work on other things (one of them being ISO9660/CD support).

Now if only CyberWarriorX released his library under a license similar to BSD or MIT, that would of have been awesome. But I guess it'll be an interesting learning experience. There is documentation in the Yabause wiki.
 
mrkotfw said:
Gotcha. I was actually beating around the bush a bit, but I was asking if you would like to help get libyaul up to speed with that while I work on other things (one of them being ISO9660/CD support).

Ah! So you would like me to maybe work on a C++ example for libyaul to "work out the kinks" kinda like I've been helping with the DRAM and CD booting? No problemo - I'll get right on that.
cool.gif


Now if only CyberWarriorX released his library under a license similar to BSD or MIT, that would of have been awesome. But I guess it'll be an interesting learning experience. There is documentation in the Yabause wiki.

I'd just get a basic READ_SECTORS function going first. You don't need to support everything to start with. A simple sector read allows any filesystem or just plain reading from a disc; after that, I'd go for playing a CD audio track. Between those two functions, you'd have 99% of any homebrew covered. None of the rest really matters.

EDIT: Well, one thing I noticed right off - all your libyaul related includes need wrappers - any time your files are compiled by the C compiler (like all of libyaul is), you need to wrap the function protos in a wrapper like this

Code:
#ifdef __cplusplus

extern "C" {

#endif

extern short set_sr(short new_sr);

extern short get_pad(short pad);

extern void clear_screen(void);

extern void put_str(char *str, int color, int x, int y);

extern void put_chr(char chr, int color, int x, int y);

extern void delay(int count);

#ifdef __cplusplus

}

#endif

When you include the include file in a C++ file, the __cplusplus options insert the etern "C" { } around all the functions so that the C++ compiler knows to do a C call instead of a C++ call to the function. So any libyaul include with functions that may be called by a program need those. Any internal calls used only by libyaul do not need them.
 
Chilly Willy said:
Ah! So you would like me to maybe work on a C++ example for libyaul to "work out the kinks" kinda like I've been helping with the DRAM and CD booting? No problemo - I'll get right on that.
cool.gif

Haha, pretty much. You basically fixed the bugs that I neglected
smile.gif


Chilly Willy said:
I'd just get a basic READ_SECTORS function going first. You don't need to support everything to start with. A simple sector read allows any filesystem or just plain reading from a disc; after that, I'd go for playing a CD audio track. Between those two functions, you'd have 99% of any homebrew covered. None of the rest really matters.

Yup, that's the plan.

So apparently the BIOS doesn't load the file with the LBA closest to zero. Instead it looks for exactly "0.BIN" or "0" or "A.BIN"

EDIT #1

Rather, it looks for something like "0*" (wildcard). The BIOS literally loads the contents of "ABS.TXT"

jOXLH.png
 
mrkotfw said:
Haha, pretty much. You basically fixed the bugs that I neglected
smile.gif

laugh.gif


Yup, that's the plan.

And a good one it is. There's no need for 99% of the Saturn CD junk when there's so many other things that are more important to others. Of course, if someone is interested and does the work for you, I'm sure you wouldn't turn it down.
wink.gif


So apparently the BIOS doesn't load the file with the LBA closest to zero. Instead it looks for exactly "0.BIN" or "0" or "A.BIN"

EDIT #1

Rather, it looks for something like "0*" (wildcard). The BIOS literally loads the contents of "ABS.TXT"

Well I should hope it doesn't just load the first file PHYSICALLY positioned on the CD. That would be a pain to deal with. So much easier to simply copy the program binary to the cd directory as "0.bin" like in my example and be done with it.
 
Chilly Willy said:

Chilly Willy said:
And a good one it is. There's no need for 99% of the Saturn CD junk when there's so many other things that are more important to others. Of course, if someone is interested and does the work for you, I'm sure you wouldn't turn it down.
wink.gif

Sure, I definitely wouldn't mind the help. However if I don't find such help, I still found your help along with Anders' help to be invaluable these past few days.

Chilly Willy said:
Well I should hope it doesn't just load the first file PHYSICALLY positioned on the CD. That would be a pain to deal with. So much easier to simply copy the program binary to the cd directory as "0.bin" like in my example and be done with it.

I pushed all the changes needed to build an image. Hopefully I didn't miss anything.

I'm thinking of making make-iso more robust. I feel that it's particularly "weak". I could possibly have it take a list of all the relative paths to the files in the project and copy them to "cd/" -- sort of an export list. I would like these things to be simple, self contained, and composeable if that makes any sense. I want to follow the UNIX philosophy as much as possible. Having these in Makefiles will help others who don't necessarily want to use MAKE(1), but rather say CMake or some other crazy build system. Right now, everything is provisional, just to get things working.

Right so the next few days/weeks will be GDB and ISO9660 support.
 
Chilly Willy said:
EDIT: Well, one thing I noticed right off - all your libyaul related includes need wrappers - any time your files are compiled by the C compiler (like all of libyaul is), you need to wrap the function protos in a wrapper like this

Code:
#ifdef __cplusplus

extern "C" {

#endif

extern short set_sr(short new_sr);

extern short get_pad(short pad);

extern void clear_screen(void);

extern void put_str(char *str, int color, int x, int y);

extern void put_chr(char chr, int color, int x, int y);

extern void delay(int count);

#ifdef __cplusplus

}

#endif

When you include the include file in a C++ file, the __cplusplus options insert the etern "C" { } around all the functions so that the C++ compiler knows to do a C call instead of a C++ call to the function. So any libyaul include with functions that may be called by a program need those. Any internal calls used only by libyaul do not need them.

Had a feeling I had to do that... I'll get to that right away then.
 
mrkotfw said:
Rather, it looks for something like "0*" (wildcard). The BIOS literally loads the contents of "ABS.TXT"

It should load the third directory record from the root directory (the first two being the loopback and parent directory entries). The CD block contains an ISO9660 implementation. Naming the file "0", "0.bin" etc. is just a hack to make sure the CD build tool used sorted the files as desired.
 
antime said:
It should load the third directory record from the root directory (the first two being the loopback and parent directory entries). The CD block contains an ISO9660 implementation. Naming the file "0", "0.bin" etc. is just a hack to make sure the CD build tool used sorted the files as desired.

I had given a list of sorted files to make sure that the file "DMAC.BIN" for example had the lowest LBA. But it would still load the contents of "ABS.TXT". I've been testing on Yabause only.

An ISO9660 impl. is already present meaning parsing on our end is not needed? I thought the CD-drive had only commands to read sectors.
 
Chilly Willy said:
EDIT: Any word on 68000 C? Looking at the build scripts, it looks like it shouldn't take much to cut and paste from the SH script into the 68000 script.

I missed this one. I figured that the sound drivers would be written in assembly due to space (and speed). Having the C compiler would require Newlib and such.
 
The LBA is irrelevant, it's the order of the directory entries that matters. The CD block has functions for handling files and directories, see the "System Library User's Guide" pdf.

Also, it's not necessary to include the abstract/bibliography/copyright entries. Your disc wouldn't be approved for publication by Sega, but that's not really an issue anyway.

I missed this one. I figured that the sound drivers would be written in assembly due to space (and speed). Having the C compiler would require Newlib and such.

The sound processor is faster and has as much RAM as an Amiga 500, and only needs to deal with audio. Just to keep things in perspective. The linker is also smart enough to only include the C library functions you actually use.

Building a 68000 compiler is the same as for eg. SuperH, but you may want to use the GCC configure flag --with-arch=m68k to prevent building ColdFire libraries.
 
antime said:
The LBA is irrelevant, it's the order of the directory entries that matters. The CD block has functions for handling files and directories, see the "System Library User's Guide" pdf.

Okay, then sorting obviously won't work. Fine, "A.BIN" it is.

Hm, I guess I skimmed too fast. I thought it was the library that implemented the FS.

antime said:
Also, it's not necessary to include the abstract/bibliography/copyright entries. Your disc wouldn't be approved for publication by Sega, but that's not really an issue anyway.

Yeah, I know but it's just for completeness.

antime said:
The sound processor is faster and has as much RAM as an Amiga 500, and only needs to deal with audio. Just to keep things in perspective. The linker is also smart enough to only include the C library functions you actually use.

Building a 68000 compiler is the same as for eg. SuperH, but you may want to use the GCC configure flag --with-arch=m68k to prevent building ColdFire libraries.

Yeah, building the 68k compiler is trivial. As Joe mentioned, it's simply copying over the script from build-scripts/sh-elf/scripts.
 
I don't think the sound processor needs newlib. It's going to be just compiling a driver... like the mod playing code I use on the 32X. As mentioned, the 68000 is pretty fast, and it doesn't need to do software mixing like I do on the 32X. If I needed software mixing, I'd use the slave sh2 and DMA the result into the sound memory. But the 68000 should easily handle tracker format score handling while the sound chip mixes the channels. As long as you don't go crazy on the instruments in the mod (I've seen mods that are 7MB long, most of that being instruments), that seems like a great format for music on the Saturn. The 68000 handles the score and any sound effects queueing, while the sound chip mixes the channels.

Just a notice - I've got a gem and mineral show Fri-Sun I'm a dealer at, so I won't have quite as much time on the computer this weekend.
 
Pretty slow these past few days, but I just implemented really basic support for traversing ISO9660 directory entries and finding the LBA of an existing file. I also added a small amount of infrastructure for initializing the CD-block. Looks like the CD-block isn't as bad as I thought it was. Theo (CyberWarriorX) documented the CD-block really well. Not to mention that disassembling the CDC library is rather helpful.

Now there are two file systems in libyaul. I'm looking to implement caching and a thin VFS layer as well as another simple file descriptor layer. This is starting to look like an OS.

So right now my game plan for the next month or so is:

  1. GDB support (USB cart from Anders)
  2. CD-block support to properly initialize
  3. CD-block support to authenticate
  4. CD-block support to read a sector
  5. CD-block support for filters
  6. The rest of basic ISO9660 support (no Joliet, RRIP, etc)
  7. VFS layer
  8. File descriptor layer
  9. C++ support

There is more than enough VDP1 and VDP2 support to get a game going even now. When am I going to get to the SCU-DSP and SCSP? The SCSP is the last thing I want to deal with, really.

I have ideas for a POSIX Threads shim. That should be absolutely awesome to have! Maybe even a job scheduler for the slave CPU.
 
Sounds good. I've been a bit inactive the last week because I had a Gem and Mineral show last weekend I was a vendor at... have another this weekend, so I won't get much of anything done until sometime next week. Fortunately, that's the end of the Gem and Mineral shows around us until winter.

So I'll update early next week, see what's new, and pitch in on what still remains at that point.
smile.gif
 
Back
Top