My new project is up!

[Chilly Willy]

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

That's a common one I do.

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.

It's bed time for me... I'll check again later tomorrow.

 

[antime]

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

I don't think any version of arflasher has specifically built cartridge executables, as that would be kind of pointless. This version is largely rewritten and can directly build bootable CD images (though the header for bootable cartridges and CDs is the same. I have previously successfully booted a cartridge ROM burned to disk without modifications.)

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.

Unless actual games take advantage of this I'd be a bit wary of depending on an undocumented feature like this. There's enough clone carts of unknown origins that some may implement the address decoding differently. Though the 1M cart layout did always seem nonsensical to me.

It doesn't say much about bad IDs.

Why would it say anything about hardware defects in unlicensed clone products?

 

[Chilly Willy]

I don't think any version of arflasher has specifically built cartridge executables, as that would be kind of pointless. This version is largely rewritten and can directly build bootable CD images (though the header for bootable cartridges and CDs is the same. I have previously successfully booted a cartridge ROM burned to disk without modifications.)

It's less trouble to simply modify a few strings in one binary block than to rebuild the thing with every single project... not to mention arflasher STILL has binary blobs in it containing the SEGA security data that are included as binary. It simply builds things over and over that only need building once.

Unless actual games take advantage of this I'd be a bit wary of depending on an undocumented feature like this. There's enough clone carts of unknown origins that some may implement the address decoding differently. Though the 1M cart layout did always seem nonsensical to me.

Yes, it's weird... which is why we should at least try the contiguous mapping idea until we find real problems as opposed to feared ones.

Why would it say anything about hardware defects in unlicensed clone products?

You told him to read that specific doc as it would clear up his problems with badly IDed products... which it doesn't.

 

[Chilly Willy]

Okay, I checked the latest updates for the dram cart - there's a minor issue with the 32 Mbit cart detection - the first time you power on, it detects as 8 Mbit instead of 32. Reset and it's okay. I think you need a delay between setting the SCU and detecting the cart to allow the 32 Mbit cart time to stablize. The 8 Mbit cart seems okay... maybe it's faster than the ARP cart, or maybe it's also failing the first test after power on, but "failing" defaults to what it is - the 8 Mbit cart.

This is the kind of issue you never see in emulators as they are "instantaneous" in transitions from one state to another.

 

[mrkotfw]

Okay, I checked the latest updates for the dram cart - there's a minor issue with the 32 Mbit cart detection - the first time you power on, it detects as 8 Mbit instead of 32. Reset and it's okay. I think you need a delay between setting the SCU and detecting the cart to allow the 32 Mbit cart time to stablize. The 8 Mbit cart seems okay... maybe it's faster than the ARP cart, or maybe it's also failing the first test after power on, but "failing" defaults to what it is - the 8 Mbit cart.

This is the kind of issue you never see in emulators as they are "instantaneous" in transitions from one state to another.

Glad you're having the same problem. What I thought was that I needed to clear the first 4 bytes of each DRAM bank and that ended up fixing it. Though, that could be the equivalent of waiting. I do have an official 4MiB cart from SEGA but I haven't tested that. I'll need to burn a CD-R to do it.

Side note since the topic of building an ISO image was brought up. Shouldn't the IP.BIN generated by arflasher be 32KiB? Or am I confusing the size of the Dreamcast's bootstrap?

 

[antime]

It's less trouble to simply modify a few strings in one binary block than to rebuild the thing with every single project... not to mention arflasher STILL has binary blobs in it containing the SEGA security data that are included as binary. It simply builds things over and over that only need building once.

Like any other object file, it'll be rebuilt if the source or its dependencies change. Personally I really dislike any method that modifies its source files, it always causes problems with reproducibility sooner or later.

The contents of sys_sec.o must be included in any bootable image, the hardware performs a memcmp against a version stored in ROM. I haven't looked at it too closely, but I believe it contains code and data that puts the Sega logo on screen thus achieving Sega's lifelong goal of having a security system that depends on both copyrightable code and a human-readable trademark. Based on some of the symbol names in sys_init.o it may be patching some bugs in the ROM. The area code objects are just a jump instructions and a text string.

You told him to read that specific doc as it would clear up his problems with badly IDed products... which it doesn't.

I said he should use it to write a software detection routine.

Side note since the topic of building an ISO image was brought up. Shouldn't the IP.BIN generated by arflasher be 32KiB? Or am I confusing the size of the Dreamcast's bootstrap?

The Saturn's header can be up to 32KB (sixteen CD sectors), but its length will vary depending on the number of area codes used and the length of the user initial program. My version of arflasher puts everything in the UIP (flasher binary plus ROM image), so the length will vary accordingly.

 

[Chilly Willy]

Like any other object file, it'll be rebuilt if the source or its dependencies change. Personally I really dislike any method that modifies its source files, it always causes problems with reproducibility sooner or later.

The contents of sys_sec.o must be included in any bootable image, the hardware performs a memcmp against a version stored in ROM. I haven't looked at it too closely, but I believe it contains code and data that puts the Sega logo on screen thus achieving Sega's lifelong goal of having a security system that depends on both copyrightable code and a human-readable trademark. Based on some of the symbol names in sys_init.o it may be patching some bugs in the ROM. The area code objects are just a jump instructions and a text string.

Sorry if my last post sounded a bit dick-ish. Maybe you could make an arc of a working example of making just the ip.bin from arflasher. The archive of the original source isn't good for including as then you require the user to make the changes. The SDK needs something ready to go. That was why I recommended the existing ip.bin most homebrew uses along with a command line tool that changes the strings - it's all ready to go and doesn't need anything extra on the part of the user. We need a turn-key solution, and that's what I recommended. If you are going to recommend arfrlasher, you need to make it into a turn-key solution that's just as easy as mine.

 

[mrkotfw]

Sorry if my last post sounded a bit dick-ish. Maybe you could make an arc of a working example of making just the ip.bin from arflasher. The archive of the original source isn't good for including as then you require the user to make the changes. The SDK needs something ready to go. That was why I recommended the existing ip.bin most homebrew uses along with a command line tool that changes the strings - it's all ready to go and doesn't need anything extra on the part of the user. We need a turn-key solution, and that's what I recommended. If you are going to recommend arfrlasher, you need to make it into a turn-key solution that's just as easy as mine.

I'm torn up by both options. And the reason is that if the tool ip_header is used, the values will be hard coded into the Makefile.

I committed this. It's very provisional. So the idea is that if you want to actually build the bootstrap file, you'd do only once:

cp ../../libyaul/common/bootstrap.S .

You modify the file accordingly and type

make bootstrap

It's a little clumsy, but so is everything else. Ideally, I would like to incorporate all the header files, library into the default GCC paths. That'll eliminate most of common.mk and it would make projects relocatable.

That will be the ultimate goal.

 

[Chilly Willy]

I'm torn up by both options. And the reason is that if the tool ip_header is used, the values will be hard coded into the Makefile.

Not necessarily. The makefile could include another file that strictly had just the things needed, like this:

CD_MAN = "SEGA HOMEBREW"

CD_PROD = "T-000H"

CD_VERS = "V1.000"

CD_DEV = "CD-1/1"

CD_AREA = "JUTE"

CD_PER = "J"

CD_TITLE = "DRAM Cartridge Test"

Then instead of this

	../../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"

you have this

	include cdinfo.mk

	../../tools/ip_header/ip_header ip.bin -man $(CD_MAN) -prod $(CD_PROD) -ver $(CD_VERS) -today -dev $(CD_DEV) -area $(CD_AREA) -per $(CD_PER) -title $(CD_TITLE)

I committed this. It's very provisional. So the idea is that if you want to actually build the bootstrap file, you'd do only once:

cp ../../libyaul/common/bootstrap.S .

You modify the file accordingly and type

make bootstrap

It's a little clumsy, but so is everything else. Ideally, I would like to incorporate all the header files, library into the default GCC paths. That'll eliminate most of common.mk and it would make projects relocatable.

That will be the ultimate goal.

Sounds like a good goal.

 

[mrkotfw]

Not necessarily. The makefile could include another file that strictly had just the things needed, like this:

CD_MAN = "SEGA HOMEBREW"

CD_PROD = "T-000H"

CD_VERS = "V1.000"

CD_DEV = "CD-1/1"

CD_AREA = "JUTE"

CD_PER = "J"

CD_TITLE = "DRAM Cartridge Test"

Then instead of this

	../../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"

you have this

	include cdinfo.mk

	../../tools/ip_header/ip_header ip.bin -man $(CD_MAN) -prod $(CD_PROD) -ver $(CD_VERS) -today -dev $(CD_DEV) -area $(CD_AREA) -per $(CD_PER) -title $(CD_TITLE)

Hey, that's definitely another way. I briefly looked over ip_header, but does it have any advantages over say using bootstrap.S?

Sounds like a good goal.

Hopefully the next big step is to finally having GDB support. What I would like to have is support for generating a call stack. Though the problem is that it needs to use the frame pointer. I already have support for all of this but it's rather flaky.

 

[Chilly Willy]

Hey, that's definitely another way. I briefly looked over ip_header, but does it have any advantages over say using bootstrap.S?

That bootstrap is pretty much what I do on the 32X, so it should be fine. The thing to note is that people need to be careful editing the strings in the bootstrap (if they do) to avoid accidentally adding or subtracting bytes from the header. One extra space and it fails completely. Not too big a deal, though. I'll update again and try it out to see how "fool-proof" it is, but I think it will probably be fine.

Hopefully the next big step is to finally having GDB support. What I would like to have is support for generating a call stack. Though the problem is that it needs to use the frame pointer. I already have support for all of this but it's rather flaky.

Which is partly why I don't use it, especially on consoles. Logging was/is always my first method of debugging.

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.

 

[Chilly Willy]

Okay, clearly bootstrap is just the header/sec blocks from arflasher... and it's completely unsuitable. Arflasher is designed so that the program follows the header - for a arflasher-CD the program MUST be a part of the boot block, which is completely unsuitable. It does not look for "0.bin", it does not load it into memory at 0x6004000, it does not run it. So unless someone wants to write a stub to add onto the end of the arflasher block to do those things, we are back to using the IP.BIN file from SaturnOrbit.

In either case, you still need to use ip_header. With bootstrap, all projects use a single common copy of bootstrap.S, so you can't edit it for your specific program - you have to build it, then run ip_header on that. So with arflasher, we aren't gaining anything, and are losing the ability to boot programs larger than 28 KBytes from CD.

 

[antime]

The ROM automatically loads the first load file to the address specified in the IP header before starting execution of the AIP. The required stub is trivial:

aip:

    mov.l firstreadptr, r0

    mov.l @r0, r0

    jmp   @r0

    nop

firstreadptr:

    .long 0x60020F0

 

[Chilly Willy]

The ROM automatically loads the first load file to the address specified in the IP header before starting execution of the AIP. The required stub is trivial:

aip:

    mov.l firstreadptr, r0

    mov.l @r0, r0

    jmp   @r0

    nop

firstreadptr:

    .long 0x60020F0

That simple? Thank goodness! I thought it would need filesystem code and sector reads and whatnot. Lemme work that into the bootstrap and try again.

EDIT: And it works fine! I just added your code snippet to the end of bootstrap.S and it works great.

Okay, a few things needed changes...

In the common makefile, bootstrap needs a change

bootstrap: ../../libyaul/common/bootstrap.S

	$(CC) -nostdlib -m2 -mb -nostartfiles \

		-T $(ROOTDIR)/common/ldscripts/bootstrap.x \

		-I../../libyaul/common \

		$< -o $@

Notice I changed the path to bootstrap.S (it couldn't find it before) and added the -I<path> so it could find the bin files.

And to add CD building to the example, the makefile needs to be changed

include ../common.mk

include cd_info.mk

PROJECT:= dram-cartridge

OBJECTS+= dram-cartridge.o

DEPENDS:= $(OBJECTS:.o=.d)

.PHONY: bootstrap clean

.SUFFIXES: .c .S .o .bin

example: $(PROJECT).bin

$(PROJECT).bin: $(PROJECT).elf

	$(OB) -O binary $< $@

$(PROJECT).elf: $(OBJECTS)

	$(LD) $(OBJECTS) $(LDFLAGS) -o $@

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

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

.c.o:

	$(CC) $(CFLAGS) -Wp,-MMD,$*.d -c -o $@ $<

.S.o:

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

cd: $(PROJECT).bin bootstrap

	mkdir -p cd

	echo $(CD_ABS) >cd/ABS.TXT

	echo $(CD_BIB) >cd/BIB.TXT

	echo $(CD_COPY) >cd/CPY.TXT

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

	../../tools/ip_header/ip_header bootstrap -man $(CD_MAN) -prod $(CD_PROD) -ver $(CD_VERS) -today -dev $(CD_DEV) -area $(CD_AREA) -per $(CD_PER) -title $(CD_TITLE)

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

clean:

	-rm -f $(OBJECTS) bootstrap \

$(DEPENDS) \

$(PROJECT).asm \

$(PROJECT).bin \

$(PROJECT).elf \

$(PROJECT).map \

$(PROJECT).sym

	-rm -rf $(PROJECT).iso cd

-include $(DEPENDS)

Notice the extra include at the top - that sets all the CD_ vars. That file has this contents

# no more than 16 characters

CD_MAN = "SEGA HOMEBREW"

# no more than 10 characters

CD_PROD = "T-000H"

# no more than 6 characters

CD_VERS = "V1.000"

# no more than 8 characters

CD_DEV = "CD-1/1"

# no more than 10 characters

CD_AREA = "JTUE"

# no more than 16 characters

CD_PER = "J"

# no more than 128 characters

CD_TITLE = "DRAM Cartridge Test"

# these can be any length at all

CD_ABS = "DRAM Cartridge Test App"

CD_BIB = "Homebrew for Saturn using libyaul"

CD_COPY = "Copyright (c) 2012 Israel Jacques - See LICENSE for details."

And finally, you need to change the make-iso script to use bootstrap instead of ip.bin for the boot block.

 

[mrkotfw]

As it stands, I'm not very well versed in the boot process. Reading the docs now.

Are we missing sys_arel.bin? For Latin America? That would make it the full 0x100 bytes.

 

[antime]

One of the tech notes states that only the J, T, U, and E area codes are valid. Presumably Sega changed their marketing strategy sometime before the Saturn's release. The B, K, A and L strings are still present in the ROM, but AFAIK no Saturns were ever sold set to one of those areas.

 

[Chilly Willy]

Oh, almost forgot - I burned a CDR and the new DRAM cart code works fine. Both 8 and 32 Mbit carts init fine. As a reminder, my 8 Mbit cart is an official SEGA cart, while the 32 Mbit cart is an ARP+.

 

[mrkotfw]

One of the tech notes states that only the J, T, U, and E area codes are valid. Presumably Sega changed their marketing strategy sometime before the Saturn's release. The B, K, A and L strings are still present in the ROM, but AFAIK no Saturns were ever sold set to one of those areas.

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?

 

[mrkotfw]

That simple? Thank goodness! I thought it would need filesystem code and sector reads and whatnot. Lemme work that into the bootstrap and try again.

EDIT: And it works fine! I just added your code snippet to the end of bootstrap.S and it works great.

Okay, a few things needed changes...

In the common makefile, bootstrap needs a change

bootstrap: ../../libyaul/common/bootstrap.S

	$(CC) -nostdlib -m2 -mb -nostartfiles \

		-T $(ROOTDIR)/common/ldscripts/bootstrap.x \

		-I../../libyaul/common \

		$< -o $@

Notice I changed the path to bootstrap.S (it couldn't find it before) and added the -I<path> so it could find the bin files.

The path to bootstrap.S was intentional. I meant it as a way so that different projects could have their own system ID section (what bootstrap.S).

So ideally every project will have a unique copy of bootstrap.S

And to add CD building to the example, the makefile needs to be changed

include ../common.mk

include cd_info.mk

PROJECT:= dram-cartridge

OBJECTS+= dram-cartridge.o

DEPENDS:= $(OBJECTS:.o=.d)

.PHONY: bootstrap clean

.SUFFIXES: .c .S .o .bin

example: $(PROJECT).bin

$(PROJECT).bin: $(PROJECT).elf

	$(OB) -O binary $< $@

$(PROJECT).elf: $(OBJECTS)

	$(LD) $(OBJECTS) $(LDFLAGS) -o $@

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

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

.c.o:

	$(CC) $(CFLAGS) -Wp,-MMD,$*.d -c -o $@ $<

.S.o:

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

cd: $(PROJECT).bin bootstrap

	mkdir -p cd

	echo $(CD_ABS) >cd/ABS.TXT

	echo $(CD_BIB) >cd/BIB.TXT

	echo $(CD_COPY) >cd/CPY.TXT

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

	../../tools/ip_header/ip_header bootstrap -man $(CD_MAN) -prod $(CD_PROD) -ver $(CD_VERS) -today -dev $(CD_DEV) -area $(CD_AREA) -per $(CD_PER) -title $(CD_TITLE)

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

clean:

	-rm -f $(OBJECTS) bootstrap \

$(DEPENDS) \

$(PROJECT).asm \

$(PROJECT).bin \

$(PROJECT).elf \

$(PROJECT).map \

$(PROJECT).sym

	-rm -rf $(PROJECT).iso cd

-include $(DEPENDS)

Notice the extra include at the top - that sets all the CD_ vars. That file has this contents

# no more than 16 characters

CD_MAN = "SEGA HOMEBREW"

# no more than 10 characters

CD_PROD = "T-000H"

# no more than 6 characters

CD_VERS = "V1.000"

# no more than 8 characters

CD_DEV = "CD-1/1"

# no more than 10 characters

CD_AREA = "JTUE"

# no more than 16 characters

CD_PER = "J"

# no more than 128 characters

CD_TITLE = "DRAM Cartridge Test"

# these can be any length at all

CD_ABS = "DRAM Cartridge Test App"

CD_BIB = "Homebrew for Saturn using libyaul"

CD_COPY = "Copyright (c) 2012 Israel Jacques - See LICENSE for details."

And finally, you need to change the make-iso script to use bootstrap instead of ip.bin for the boot block.

 

[Chilly Willy]

The path to bootstrap.S was intentional. I meant it as a way so that different projects could have their own system ID section (what bootstrap.S).

So ideally every project will have a unique copy of bootstrap.S

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.