My new project is up!

[mrkotfw]

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.

Just received my USB cart from cafe-alpha! Going to get cracking on that to-do list!

No need for a virtual machine any more! And Lord almighty is thing fast! Transfer time 2.407277 for ~890KiB!

 

[Chilly Willy]

Just received my USB cart from cafe-alpha! Going to get cracking on that to-do list!

No need for a virtual machine any more! And Lord almighty is thing fast! Transfer time 2.407277 for ~890KiB!

I'm trying to get one of those carts, too.

 

[mrkotfw]

I'm trying to get one of those carts, too.

The development cycle is just as fast as launching Yabause immediately after compiling a test application. Using Anders' cart ROM, I've noticed some flakiness when jumping back to 0x22000F00. But I'll investigate that for later. Sometimes it hangs. Other times the Master core raises an exception. But that should be fixable by just jumping back to 0x22000F00

Looks like Sega Saturn development is making some small leaps

 

[Chilly Willy]

The development cycle is just as fast as launching Yabause immediately after compiling a test application. Using Anders' cart ROM, I've noticed some flakiness when jumping back to 0x22000F00. But I'll investigate that for later. Sometimes it hangs. Other times the Master core raises an exception. But that should be fixable by just jumping back to 0x22000F00

Looks like Sega Saturn development is making some small leaps

Having good tools tends to make development a bit better.

As to jumping back to 0x22000F00 being flakey, maybe some of the hardware isn't in a correct state for what that entry expects, and something isn't set that should be, or is set in a way that conflicts with how is WAS set previously. Cleanup on program exit is always a bitch.

 

[mrkotfw]

Having good tools tends to make development a bit better.

As to jumping back to 0x22000F00 being flakey, maybe some of the hardware isn't in a correct state for what that entry expects, and something isn't set that should be, or is set in a way that conflicts with how is WAS set previously. Cleanup on program exit is always a bitch.

That's what I'm thinking, but really at that address, that's the start of the cart ROM after Sega's AIP. I don't know, maybe I have to wait a second or two until it's ready?

 

[antime]

The cartridge ROM is built to be executed rom workram-H, where the Saturn ROM loads it. Since there are hardcoded addresses in the binary, trying to run directly from the cartridge will almost certainly fail. Since the "execute" command uses a normal C subroutine call you can just return from your code if you don't want to reset the machine, as long as you don't overwrite the memory used by the loader.

 

[Chilly Willy]

The cartridge ROM is built to be executed rom workram-H, where the Saturn ROM loads it. Since there are hardcoded addresses in the binary, trying to run directly from the cartridge will almost certainly fail. Since the "execute" command uses a normal C subroutine call you can just return from your code if you don't want to reset the machine, as long as you don't overwrite the memory used by the loader.

And what memory is used by the loader? Having a map of the launch environment will help with making sure the sdk doesn't kill something accidentally.

 

[cafe-alpha]

And what memory is used by the loader? Having a map of the launch environment will help with making sure the sdk doesn't kill something accidentally.

If you are interested, I can add some code that has the same behaviour as antime's firmware, but run directly from ARP ROM:

0x02000000 : IP + original firmware that runs from HRAM

0x0203C000 : Code that run directly from ROM

Hence, your program don't need to care about detroying RAM needed for firmware, but need to call a specific address (0x0203C000) when exiting.

For mrkotfw : upgrading firmware can be done by simply uploading and executing a Saturn binary via USB dev cart, so that using modchip'd Saturn, burning CD-R, etc is not needed.

 

[antime]

The IP Size field in the header gives the size of the IP(!), plus a few words of stack.

 

[mrkotfw]

If you are interested, I can add some code that has the same behaviour as antime's firmware, but run directly from ARP ROM:

0x02000000 : IP + original firmware that runs from HRAM

0x0203C000 : Code that run directly from ROM

Hence, your program don't need to care about detroying RAM needed for firmware, but need to call a specific address (0x0203C000) when exiting.

For mrkotfw : upgrading firmware can be done by simply uploading and executing a Saturn binary via USB dev cart, so that using modchip'd Saturn, burning CD-R, etc is not needed.

So you'll just be appending the same executable at 0x2203C000? Sounds good to me. Send me the executable.. I'm too lazy to do it myself

 

[mrkotfw]

In other news, GDB support using the USB cartridge is about 75% complete (it's in the repos)

Stepping through is still buggy but it works. I'll be adding breakpoints through GDB after I can get the stub to work with unconditional jumps. Everything is still a bit flaky.

The only thing particular about GDB support is that I had to write a GDB proxy only because I had trouble having GDB communicate directly with the USB cartridge (via /dev/ttyUSB0). So the setup is like so:

Saturn <-> GDB-stub <-> USB-cartridge <-> GDB-proxy <-> TCP socket <-> GDB-client

The GDB proxy is a major hack and I won't be adding it until I either clean it up or add support for the Saturn into GDB directly (via a patch). But if you absolutely must have the GDB proxy code, here it is: http://sprunge.us/fdQF?c

1. Use gdb_init() in your application to start GDB

2. Compile and transfer the app to the Saturn

3. Start the GDB proxy: ./gdb-proxy 2000

4. Start GDB

5. Type the following commands in GDB (you can add this to ".gdbinit")

set debug remote 0

set remote supported-packets off

target remote :2000

layout split

run

And you'll be set!

 

[Chilly Willy]

I'll check it out when I get the cart. Last check showed it was in Osaka.

 

[cafe-alpha]

So you'll just be appending the same executable at 0x2203C000? Sounds good to me. Send me the executable.. I'm too lazy to do it myself

I gathered stuff regarding USB dev cart in the following page : http://ppcenter.free.fr/satcart/

Inside, there is a modified firmware that runs from ROM (usb_cartrom_20120723.7z) and instructions about how to update firmware (you need to execute flasher.bin from 0x06004000 address).

(*) I changed the ROM executable start address to 0x0203F800, and use ROM last byte data to check whether executable is present or not :

// from rom_main.h

#define ROMCODE_MSK_USB_DEV_CART 0x81

#define ROMCODE_VAL_USB_DEV_CART 0x01

#define ROM_CHECK_ADDRESS 0x0203FFFF

#define ROM_EXEC_ADDRESS  0x0203F800

#define rom_usb_dev_cart_io() (((*((unsigned char*)ROM_CHECK_ADDRESS)) & ROMCODE_MSK_USB_DEV_CART) == ROMCODE_VAL_USB_DEV_CART ? ((int (*)(void))ROM_EXEC_ADDRESS)() : -1)

I also added the following (useless ?) features :

- Any key makes returning to BIOS multiplayer screen

- Screen blinks instead of displaying a single color : simple way to check if firmware hanged or not

Feel free to use this firmware for your Saturn projects

 

[mrkotfw]

Sorry guys, I've been fairly busy as of late.

 

[Chilly Willy]

No problem - most of the rest of us have been, too!

 

[vbt]

Piratero, I will try your lib

 

[mrkotfw]

Piratero, I will try your lib

Glad to hear it. Let me know if all works well for you.

 

[vbt]

@mrkotfw did you manage to get indirect dma working with libyaul?

 

[mrkotfw]

Yes, indirect SCU-DMA has been working for a while.