HomeForumsWhat's newResources 
 
 
My new project is up!
mrkotfw - Oct 9, 2006

 < Prev  1  ...  4  5  6  7  8  9  Next> 

  Chilly Willy Jun 24, 2012
What about the error I mentioned... is that going to be a problem, or can it be ignored?

EDIT: It keeps cmake from generating the makefiles, so it's definitely a major bump in the road.

EDIT 2: okay, found the makefiles...

 mrkotfw Jun 24, 2012

Chilly Willy said:
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


Ouch, thanks for that. I just pushed some fixes. Be sure to pull, then do:

Code: 
  
cp -v config.cmake{.in,}

Then try again.

 mrkotfw Jun 24, 2012

Chilly Willy said:
What about the error I mentioned... is that going to be a problem, or can it be ignored?


We're severely out of sync here I just replied above.

 Chilly Willy Jun 24, 2012

mrkotfw said:
We're severely out of sync here I just replied above.


Hehehe - I figured as much. Did a git pull and the file appeared... made the duplicate with the right name and everything went through fine. No problems at all on either now.

Now to try compiling some of the examples...

 mrkotfw Jun 24, 2012

Chilly Willy said:
Hehehe - I figured as much. Did a git pull and the file appeared... made the duplicate with the right name and everything went through fine. No problems at all on either now.

Now to try compiling some of the examples...


I'm glad there are minimal problems. After this point, the examples should compile with no issue

 Chilly Willy Jun 24, 2012

mrkotfw said:
I'm glad there are minimal problems. After this point, the examples should compile with no issue


And they do... examples compile fine, and I'm running the dram_cart example in yabuse as we speak.

EDIT: One thing that you might add to the readme... when you build the toolchain, you get a couple messages:


  
	
	

		
		

			Add '/home/jlfenton/Projects/Saturn/libyaul/m68k-elf/bin' to the $PATH environment variable



Add '/home/jlfenton/Projects/Saturn/libyaul/sh-elf/bin' to the $PATH environment variable


You might give people an example in case they aren't familiar with doing this:

Code: 
  
export PATH=/home/jlfenton/Projects/Saturn/libyaul/sh-elf/bin:/home/jlfenton/Projects/Saturn/libyaul/m68k-elf/bin:$PATH

  Chilly Willy Jun 24, 2012
Well, it's all good and fine to get the examles running in yabuse, but can I get them working on REAL HARDWARE?? Well, I'd need to make a CD in my case. There's make-iso in the tools, but that's not all we need... how about the IP.BIN from ROCKIN'B and a way to edit the header info?

http://www.mediafire.com/?pxl0u2vnonh9imt...

Okay, how about changes to the makefile in the example app?

Code: 
  
include ../common.mk

PROJECT= dram-cartridge

OBJECTS+= dram-cartridge.o

.PHONY: clean

.SUFFIXES: .c .o

.c.o:

	$(CC) $(CFLAGS) -c -o $(@) $(<)

.s:

	$(AS) $(AFLAGS) -o $(@) $(<)

$(PROJECT).elf: $(OBJECTS)

	$(LD) $(OBJECTS) $(LDFLAGS) \

		-o $(@) -L. -L../../build/libyaul -lyaul

	$(OB) -O binary $(@) $(PROJECT).bin

	$(NM) $(PROJECT).elf > $(PROJECT).sym

	$(OD) -S $(PROJECT).elf > $(PROJECT).asm

ip.bin:

	cp ../../tools/ip_header/IP.BIN ./ip.bin

	../../tools/ip_header/ip_header ip.bin -man "SEGA HOMEBREW" -prod "T-000H" -ver "V1.000" -today -dev "CD-1/1" -area "JUTE" -per "J"  -title "DRAM Cartridge Test"

cd: $(PROJECT).elf ip.bin

	mkdir -p cd

	echo "DRAM Cartridge Test App" >cd/ABS.TXT

	echo "Homebrew for Saturn using libyaul" >cd/BIB.TXT

	echo "Copyright (c) 2012 Israel Jacques - See LICENSE for details." >cd/CPY.TXT

	cp $(PROJECT).bin cd/0.bin

	sh ../../tools/make-iso/make-iso $(PROJECT)

clean:

	-rm -rf $(OBJECTS) \

	$(PROJECT).asm $(PROJECT).bin $(PROJECT).elf $(PROJECT).map $(PROJECT).sym $(PROJECT).iso ip.bin cd

Okay, that actually makes an ISO that runs in yabuse, how about real hardware?




  mrkotfw Jun 24, 2012
Excellent work! The pic is a bit blurry, but it looks like it detected it as 4MiB cart. What's odd is that it detects mine as 1MiB. It's probably due to old firmware

Burning onto a CD-R sounds like a real pain until you can get a faster way to develop useful applications

I'll add that tool. I'll have to look at the license and such. If not, write my own. Thanks for doing all the testing

 antime Jun 24, 2012

Chilly Willy said:
There's make-iso in the tools, but that's not all we need... how about the IP.BIN from ROCKIN'B and a way to edit the header info?


For another way to build the header that doesn't require extra tools look at the arflasher... package.


mrkotfw said:
What's odd is that it detects mine as 1MiB. It's probably due to old firmware


Many old carts have a hardware bug that makes it report the wrong cartridge ID. If you want to use the cartridge to play games there's a fix..., otherwise you could add software-based identification if the cartridge identifies itself as a 1MB expansion.

 mrkotfw Jun 24, 2012

antime said:
For another way to build the header that doesn't require extra tools look at the arflasher... package.

Many old carts have a hardware bug that makes it report the wrong cartridge ID. If you want to use the cartridge to play games there's a fix..., otherwise you could add software-based identification if the cartridge identifies itself as a 1MB expansion.


That's a good idea. I already have something up for just that: https://github.com/mrkotfw/libyaul/blob/master/lib...

I'm sure it just amounts to checking the version.

 antime Jun 24, 2012
You can't tell if the hardware is buggy from the firmware. I'd recommend reading Saturn Technical Bulletin #47 and writing a simple test based on the RAM memory layout.

 Chilly Willy Jun 24, 2012
The license on ip_header is not a problem as it uses the "DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE".

I'm not sure if arflasher is applicable since it's meant for making Action Replay cart executables, not CDs.

The "license" on IP.BIN is another thing altogether... it's pretty much all copyright SEGA, but since it's used as a security key, court cases in the US have ruled it's permissible for competitors to use the code as a block for interoperability. SEGA lost that case quite some time back, and recent cases have only strengthened that position. It's the same thing that lets me include the security block for the 32X in my 32X homebrew.

If you're too worried about it, I suggest just telling people to get IP.BIN from the SaturnOrbit package.

EDIT: I just noticed that the example and the cart code in libyaul both say "16 Mbit" when it should be 8 Mbit. I've got the official SEGA 8 Mbit cart as well, so I just tested the example and it says it's a 16 Mbit cart.

EDIT 2: I also noticed that your cart example assumes all the memory in the cart is contiguous. The 8 Mbit cart is split into two 4 Mbit sections: 4 Mbit at 0x22400000, and 4 Mbit at 0x22600000. I don't know if the dram mirrors or not, but if it does, you could make the two sections contiguous by returning the area as the last mirror of the first section instead of the actually location.

EDIT 3: Actually, it only tests half the memory, so it doesn't run into the non-contiguous nature of the memory. The "ID" is the bank size for the DRAM, with each cart having two banks, one at 0x22400000 and the other at 0x22600000. I should change the address it uses for testing to check if the ram mirrors.

EDIT 4: HA! I was right! You can use the last mirror of the first bank of DRAM in the cart to make contiguous memory on the 8 Mbit cart... on real hardware. Yabuse doesn't support mirrors of the cart DRAM. I found a bug in Yabuse!

I calculate the cart start address like this:

Code: 
  
cart = (uint32_t *)(dram_cartridge_area() + 0x200000 - dram_cartridge_size());

That gives 0x22580000 for the 8 Mbit cart, and 0x22400000 for the 32 Mbit cart.

 mrkotfw Jun 25, 2012

Chilly Willy said:
The license on ip_header is not a problem as it uses the "DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE".

I'm not sure if arflasher is applicable since it's meant for making Action Replay cart executables, not CDs.


That's good to know! I'll be using the best of both tools.


Chilly Willy said:
The "license" on IP.BIN is another thing altogether... it's pretty much all copyright SEGA, but since it's used as a security key, court cases in the US have ruled it's permissible for competitors to use the code as a block for interoperability. SEGA lost that case quite some time back, and recent cases have only strengthened that position. It's the same thing that lets me include the security block for the 32X in my 32X homebrew.

If you're too worried about it, I suggest just telling people to get IP.BIN from the SaturnOrbit package.


I'm happy that lawsuit happened. That gives me the green light to push it into the repository!


Chilly Willy said:
EDIT: I just noticed that the example and the cart code in libyaul both say "16 Mbit" when it should be 8 Mbit. I've got the official SEGA 8 Mbit cart as well, so I just tested the example and it says it's a 16 Mbit cart.


Looks like I royally screwed up


Chilly Willy said:
EDIT 2: I also noticed that your cart example assumes all the memory in the cart is contiguous. The 8 Mbit cart is split into two 4 Mbit sections: 4 Mbit at 0x22400000, and 4 Mbit at 0x22600000. I don't know if the dram mirrors or not, but if it does, you could make the two sections contiguous by returning the area as the last mirror of the first section instead of the actually location.

EDIT 3: Actually, it only tests half the memory, so it doesn't run into the non-contiguous nature of the memory. The "ID" is the bank size for the DRAM, with each cart having two banks, one at 0x22400000 and the other at 0x22600000. I should change the address it uses for testing to check if the ram mirrors.

EDIT 4: HA! I was right! You can use the last mirror of the first bank of DRAM in the cart to make contiguous memory on the 8 Mbit cart... on real hardware. Yabuse doesn't support mirrors of the cart DRAM. I found a bug in Yabuse!

I calculate the cart start address like this:

Code: 
  
cart = (uint32_t *)(dram_cartridge_area() + 0x200000 - dram_cartridge_size());

That gives 0x22580000 for the 8 Mbit cart, and 0x22400000 for the 32 Mbit cart.


Excellent, thanks giving me the heads up. I'll look more into this

 mrkotfw Jun 25, 2012

antime said:
You can't tell if the hardware is buggy from the firmware. I'd recommend reading Saturn Technical Bulletin #47 and writing a simple test based on the RAM memory layout.


Okay, that's a relief. I'll check that PDF out, thanks.

 Chilly Willy Jun 25, 2012

mrkotfw said:
Okay, that's a relief. I'll check that PDF out, thanks.


It doesn't say much about bad IDs. What you might try is the mirroring I mentioned - since we know the 8 Mbit cart mirrors four times, if the cart IDs as 8 Mbit, write to the base, write a different value to the first mirror base, then check if the base changed. If so, it's really 8 Mbit. If not, it's really 32 Mbit.

The first mirror of the banks of the 8 Mbit cart ARE supported by Yabause, just not the second or third mirrors, so using the first mirror for detecting 8 Mbit carts SHOULD be okay.

 mrkotfw Jun 25, 2012

Chilly Willy said:
It doesn't say much about bad IDs. What you might try is the mirroring I mentioned - since we know the 8 Mbit cart mirrors four times, if the cart IDs as 8 Mbit, write to the base, write a different value to the first mirror base, then check if the base changed. If so, it's really 8 Mbit. If not, it's really 32 Mbit.

The first mirror of the banks of the 8 Mbit cart ARE supported by Yabause, just not the second or third mirrors, so using the first mirror for detecting 8 Mbit carts SHOULD be okay.


Yeah, I went over the document to make sure I wasn't missing anything. I'm doing those tests right now. This great, thanks!

 Chilly Willy Jun 25, 2012
As to the bug in Yabause, if you look in the cs0.c file, you'll find this function (and five more for all the 8 Mbit DRAM read/write functions):

Code: 
  
static u8 FASTCALL DRAM8MBITCs0ReadByte(u32 addr)

{

   addr &= 0x1FFFFFF;

   switch (addr >> 20)

   {

      case 0x04: // Dram area

         return T1ReadByte(CartridgeArea->dram, addr & 0x7FFFF);

      case 0x06: // Dram area

         return T1ReadByte(CartridgeArea->dram, 0x80000 | (addr & 0x7FFFF));

      default:   // The rest doesn't matter

         break;

   }

   return 0xFF;

}

It SHOULD be this:

Code: 
  
static u8 FASTCALL DRAM8MBITCs0ReadByte(u32 addr)

{

   addr &= 0x1FFFFFF;

   switch (addr >> 20)

   {

      case 0x04: // Dram area

      case 0x05:

         return T1ReadByte(CartridgeArea->dram, addr & 0x7FFFF);

      case 0x06: // Dram area

      case 0x07:

         return T1ReadByte(CartridgeArea->dram, 0x80000 | (addr & 0x7FFFF));

      default:   // The rest doesn't matter

         break;

   }

   return 0xFF;

}

Notice how the original routines skip 5 and 7 - that causes the second and third mirrors to be skipped.

EDIT: Yes, I did leave a bug report at the Yabause forums.

 mrkotfw Jun 25, 2012
Alright, thanks to Joe for pointing out that (terribly stupid) bug, I pushed some changes. Here... is the relevant commit.

As for the Yabause bug, I relayed that to Guillaume. Hopefully he'll see it.

 Chilly Willy Jun 25, 2012

mrkotfw said:
Alright, thanks to Joe for pointing out that (terribly stupid) bug, I pushed some changes. Here... is the relevant commit.

As for the Yabause bug, I relayed that to Guillaume. Hopefully he'll see it.


I pulled the new changes - I like them, but you missed something - in the cart init, you try to detect the cart (I guess in case you call init multiple times and it's already initialized), but the detect routine tries reading and writing the cart before the SCU has been initialized. If detect fails, it inits the SCU, but then doesn't do the detect routine to set the ID and base.

EDIT: Oh yeah, one thing I wanted to suggest - at least build the C compiler for the 68000. I was thinking of working on some sound code, and not having C means I'd have to convert everything to assembly when it isn't necessary.

 mrkotfw Jun 25, 2012

Chilly Willy said:
I pulled the new changes - I like them, but you missed something - in the cart init, you try to detect the cart (I guess in case you call init multiple times and it's already initialized), but the detect routine tries reading and writing the cart before the SCU has been initialized. If detect fails, it inits the SCU, but then doesn't do the detect routine to set the ID and base.


Ugh, yeah I need to just move it down. Thanks.

I think what I'm going to do is if the cart detection fails, I'm going to reset the values of the two registers to their original values.

Let me just let it run for a while before pushing again.

 < Prev  1  ...  4  5  6  7  8  9  Next>