My new project is up!

GO TO ADMIN PANEL > ADD-ONS AND INSTALL VERTIFORO SIDEBAR TO SEE FORUMS AND SIDEBAR

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
Yeah, definitely. I didn't think -I applied to the incbin directive.
 

antime

Extra Hard Mid Boss
Joined
Jan 24, 2002
Messages
2,587
Points
48
Website
www.iki.fi
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.
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
 

Chilly Willy

New Member
Joined
Jan 21, 2006
Messages
256
Points
16
Age
53
Website
groups.google.com
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!
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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!
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


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.
 

Chilly Willy

New Member
Joined
Jan 21, 2006
Messages
256
Points
16
Age
53
Website
groups.google.com
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
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.
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
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.
 

Chilly Willy

New Member
Joined
Jan 21, 2006
Messages
256
Points
16
Age
53
Website
groups.google.com
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.


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.
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
Haha, pretty much. You basically fixed the bugs that I neglected


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"

 

Chilly Willy

New Member
Joined
Jan 21, 2006
Messages
256
Points
16
Age
53
Website
groups.google.com
mrkotfw said:
Haha, pretty much. You basically fixed the bugs that I neglected


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.


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.
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
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.
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
 

antime

Extra Hard Mid Boss
Joined
Jan 24, 2002
Messages
2,587
Points
48
Website
www.iki.fi
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.
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
 

antime

Extra Hard Mid Boss
Joined
Jan 24, 2002
Messages
2,587
Points
48
Website
www.iki.fi
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.
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
 

Chilly Willy

New Member
Joined
Jan 21, 2006
Messages
256
Points
16
Age
53
Website
groups.google.com
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.
 

mrkotfw

Member
Joined
Dec 30, 2002
Messages
840
Points
28
Age
31
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.
 

Chilly Willy

New Member
Joined
Jan 21, 2006
Messages
256
Points
16
Age
53
Website
groups.google.com
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.
 
Top