SegaXtreme

Home	Forums	What's new	Resources

My new project is up!

mrkotfw - Oct 9, 2006

< Prev

Next>

		mrkotfw		Mar 18, 2012
			I had a little bit of time today. So I committed in the first example. It's a test that goes through all SCU DMA levels as well as interrupts. Unfortunately it's not working at the moment. It seems to hang. If you guys want to take a look at it, be my guest!

mrkotfw

Mar 18, 2012

		Piratero said:
		I had a little bit of time today. So I committed in the first example. It's a test that goes through all SCU DMA levels as well as interrupts. Unfortunately it's not working at the moment. It seems to hang. If you guys want to take a look at it, be my guest!

Fixed it. It no longer crashes. However, the DMA illegal interrupt is generated... weird.

		Chilly Willy		Mar 18, 2012
			Maybe a bug in the docs. You might check the corrections doc for anything on SCU DMA.

		ExCyber		Mar 18, 2012
			I'm pretty sure I did see some stuff about SCU DMA restrictions in one of the TBs, but it's been a long time. edit: see TB #10. There are a bunch of non-obvious restrictions.

mrkotfw

Mar 18, 2012

		ExCyber said:
		I'm pretty sure I did see some stuff about SCU DMA restrictions in one of the TBs, but it's been a long time.

Thanks guys. I'll look at that.

I did fix it. It was the fact that I wasn't setting bit 8 to the DxAD register. Though after the "Level 0 DMA End" interrupt is generated, I need to check if it really did copy. At first I was copying from WorkRAM-Low to WorkRAM-High which is... well pointless since it's on the CPU-Bus. I switched from WorkRAM-L to VDP1 VRAM.

I also need to test Indirect mode as well.

		mrkotfw		Apr 13, 2012
			VT100 (part of it) with color escape sequence support. Running on real hardware, of course. One thing that I need to do is rebuild my cross compiler and either use uClibc or newlib with all floating point and system call junk removed. What do you guys think?

mrkotfw

Apr 15, 2012

For the life of me, I'm still having trouble grasping the concept for vertical-blanking and the confusing terminology in the docs.

Here's what I drew:

So why on Earth do I see this all the time:

Code:

    while (true) {

  vblank_in_wait();

  vblank_out_wait();

  /* Write to VRAM, graphics, update scroll screen, etc. */

}

Shouldn't it be:

Code:

    /* 

 * If we don't wait for VBLANK-IN, we might be in a case for

 * when we first enter the infinite loop during VBLANK-IN (retrace).

 *

 * Halfway through the loop, we switch over to VBLANK-OUT (scan)

 * causing shearing.

 */

while ((TVSTAT & 0x0008)); /* Spin until we get to VBLANK-OUT (scan) */

while (true) {

  while ((TVSTAT & 0x0008) == 0); /* spin until we get to VBLANK-IN (retrace) */

  /* Write to VRAM, graphics, update scroll screen, etc. */

}

Also, what is a good way (aside from using SCU/CPU timer) to wait for an x amount of microseconds? I don't see any instruction that outputs the cycle count. I was hoping to use that and divide it by the CPU frequency.

I need to issue the SMPC "INTBACK" command immediately after vblank-in to read in the peripheral (no parsing) into a buffer.

		antime		Apr 16, 2012
			Vblank in means start of vblank (as in "entering vblank period"). You could try using SCU timer 0. The timer 0 counter is reset at vblank out, and counts hblank in events. Setting the interrupt to a number of scanlines after vblank in should give you the needed timing. A scanline takes 64ÃÂµs on PAL and 63.5ÃÂµs on NTSC, so vertical resolution + 5 should be enough for the SMPC 300ÃÂµs delay.

mrkotfw

Apr 16, 2012

		antime said:
		Vblank in means start of vblank (as in "entering vblank period"). You could try using SCU timer 0. The timer 0 counter is reset at vblank out, and counts hblank in events. Setting the interrupt to a number of scanlines after vblank in should give you the needed timing. A scanline takes 64µs on PAL and 63.5µs on NTSC, so vertical resolution + 5 should be enough for the SMPC 300µs delay.

Then my terminology is completely backwards then.

Thanks, I'll try that.

		mrkotfw		May 15, 2012
			Hm, I got quite a few things supported now. It's a matter of checking out the source. Though, I have been testing and on real hardware, things go haywire: NBG0 bitmap with 32,768 RGB set NBG1 cell 16 colors NBG2 cell 16 colors And for some reason, NBG2 seems to be corrupted as well as NBG0. The VRAM cycle patterns shouldn't be the issue since disabling NBG0 allows NBG2 to be displayed correctly and vice versa. I wonder if these are restrictions that need to be taken care of but I doubt it.

		mrkotfw		Jun 13, 2012
			Just a general update... I've added support for quite a few things these past few days. I've forgotten what I've added but here... is a list of all changes I've made. I'm going to finally change all the Newlib system calls. This will finally incorporate TLSF and a few other things. I'm also going to be finally adding the ability to parse the ISO9660 file system. I'll then be ready to write a few functions to read sectors from the CD-drive. One thing that I've noticed is severely lacking is the ability to count instruction cycles. I was thinking of using the scanlines to roughly determine how long a particular function takes to execute. Any tips? Also, if anyone would be so kind as to actually build the cross compiler and compile libyaul, I'd appreciate it. I'm sure there are a lot of bugs that I need to fix.

		mrkotfw		Jun 14, 2012
			ROMDISK support has been added ARP support has been added Who needs CD-ROM support now? The idea is that you load your executable, initialize the 32-Mbit cartridge and send the actual ROMDISK file system through PAR and into load it into the cart. On a serious note, after I implement a (basic) version of ISO9660, I'll start adding support for it.

		Chilly Willy		Jun 23, 2012
			My ARP+ doesn't have the connector, so I need CDROM support. I've got a mod chip in my Saturn, so I planned on using emulators and CDRs to testing and running stuff. I just updated my clone of libyaul, so I'll try the cross-compiler for you and let you know how it goes, and any changes I need to make (if any). I could probably also help with the CD filesystem.

mrkotfw

Jun 23, 2012

		Chilly Willy said:
		My ARP+ doesn't have the connector, so I need CDROM support. I've got a mod chip in my Saturn, so I planned on using emulators and CDRs to testing and running stuff. I just updated my clone of libyaul, so I'll try the cross-compiler for you and let you know how it goes, and any changes I need to make (if any). I could probably also help with the CD filesystem.

Well, Cafe-Alpha ordered a few PCB's to build antime's USB cart. I'll probably get to building a few to sell here in the United States in case people are really interested (I can somehow get a group order). So if you can get one, there's some major benefits to having one.

As for ISO9660 FS support, I'm in the process of writing it.

I found a few bugs in Yabause when testing my stuff. But having its debugger is essential. I wouldn't get anywhere it if it wasn't for it! Speaking debugging, I'm writing (as I type this) a GDB stub!

Please do, I need to know if my scripts are portable enough

		Chilly Willy		Jun 23, 2012
			I've mostly used logging or setting the background color in my debugging, especially on consoles. I really ought to do a gdb stub for KRIKzz's USB link for the MD/32X. I've got a couple of those - plug into the controller port and have a USB port to go to the computer. I've been looking over the build scripts and such. Looks good so far. I'm going to download the archives and give it a try.

mrkotfw

Jun 23, 2012

		Chilly Willy said:
		I've mostly used logging or setting the background color in my debugging, especially on consoles. I really ought to do a gdb stub for KRIKzz's USB link for the MD/32X. I've got a couple of those - plug into the controller port and have a USB port to go to the computer. I've been looking over the build scripts and such. Looks good so far. I'm going to download the archives and give it a try.

I'll be committing the RSP along with all the stubs the RSP needs to communicate with GDB remotely in a few days. Though It'll be largely untested (I'll be testing through other means like simulating a connection with GDB). From that point on, you should have GDB support with ease.

I don't understand. You can send data through the controller port and connect it to a USB port? I don't understand enough hardware to know what is involved (Saturn).

As for downloading the archives, no need! Just follow the README and that's really all you need. Just sit back and relax!

I really appreciate you taking the time to test it out. I need more support

Chilly Willy

Jun 24, 2012

Well, a few things with the tools build script...

Code:

    # 'yes': Already downloaded

#  'no': Download packages for building the compiler

BUILD_DOWNLOAD="no"

Your explanation is backwards. Yes means download, and no means already downloaded.

Code:

    NEWLIB_VERSION="1.20.0"

You had 1.20, not 1.20.0, which causes a failure at patch time.

Other than those two minor issues, the build_compiler script worked just peachy.

The usb link device is for the Genesis, not the Saturn, although it would probably work with the Saturn with an appropriate MD to Saturn adapter. It's a tiny board that plugs into the Genesis controller port; it has a USB serial chip on it, and an AVR MPU. The AVR receives data from the Genesis and sends it as serial to the PC over the USB chip, and receives data from the PC via USB serial which it then allows the Genesis to read. The controller uses TH/TR/TL for handshaking, and sends nibbles over the direction lines.

http://krikzz.com/link-unit.html...

mrkotfw

Jun 24, 2012

Chilly Willy said:

Well, a few things with the tools build script...

Code:

    # 'yes': Already downloaded

#  'no': Download packages for building the compiler

BUILD_DOWNLOAD="no"

Your explanation is backwards. Yes means download, and no means already downloaded.

Code:

    NEWLIB_VERSION="1.20.0"

You had 1.20, not 1.20.0, which causes a failure at patch time.

Other than those two minor issues, the build_compiler script worked just peachy.

Going to fix that, thanks. I'm glad it all worked! What OS did you run the scripts under?

Chilly Willy

Jun 24, 2012

Xubuntu 12.04.

Ran into something trying to build libyaul...

Code:

    jlfenton@SBC:~/Projects/Saturn/libyaul/build$ cmake .. -DCMAKE_TOOLCHAIN_FILE=../SegaSaturn-compiler-SH7604.cmake

CMake Error: File /home/jlfenton/Projects/Saturn/libyaul/config.h.cmake does not exist.

CMake Error at CMakeLists.txt:5 (CONFIGURE_FILE):

  configure_file Problem configuring file

mrkotfw

Jun 24, 2012

		Chilly Willy said:
		The usb link device is for the Genesis, not the Saturn, although it would probably work with the Saturn with an appropriate MD to Saturn adapter. It's a tiny board that plugs into the Genesis controller port; it has a USB serial chip on it, and an AVR MPU. The AVR receives data from the Genesis and sends it as serial to the PC over the USB chip, and receives data from the PC via USB serial which it then allows the Genesis to read. The controller uses TH/TR/TL for handshaking, and sends nibbles over the direction lines. http://krikzz.com/link-unit.html...

I didn't know you could do that. That's pretty awesome.

If the cross-compilers worked just fine, then you should have no trouble building any of the examples.

The problem comes with moving the examples around. Meaning, if you were to write your own code, it'd have to be under libyaul/examples/your-project/ unless of course you move things around in libyaul/examples/common/ as well as copying libyaul.a

In combination with the build scripts, I will embedded that all nicely within the compiler so all you have to do to compile is specific the sh-elf.specs file in your Makefile! This will be in a few weeks or months as it's low priority.

< Prev

Next>