My new project is up!

[mrkotfw]

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]

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]

Maybe a bug in the docs. You might check the corrections doc for anything on SCU DMA.

 

[ExCyber]

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]

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]

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]

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:

while (true) {

  vblank_in_wait();

  vblank_out_wait();

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

}

Shouldn't it be:

/* 

 * 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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

# '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.

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]

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

# '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.

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]

Xubuntu 12.04.

Ran into something trying to build libyaul...

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]

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.