PAL Sonic Adventure Not Booting on Set 5.24 Dev Box?

I've set it to region 9 and it gets to the Sega screen before throwing me back to the bios menu.
I've seen Sonic Adventure run on dev boxes before, is this supposed to happen? The disc has relatively few scratches and runs fine on my PAL Dreamcast.

 

Does anybody have any ideas how to fix this? It won't boot from an emulated project in GD Workshop either. The autodemo runs perfectly though.

 

Have you tried any other GD-Rom? Other Pal one?

Maybe it's like for Shenmue?

I think I heard years ago that if you write the region flag at the correct address in the devkit flash it'd boot. It's just that devkits don't use this flag normally, but shenmue looks for it...

EDIT: There -> http://www.assemblergames.com/forums/showthread.php?21743-sega-dev-running-games/page2#25

 

My dev unit works with Fur Fighters, Rez, Sonic Adventure 2, Quake 3, they're all Pal region GD's...

I'm afraid it might be like Shenmue, the emulated GD project manages to boot to a black screen now. I can set the flash to be writeable but I'm not sure how I can actually rewrite it with a working flash that doesn't set the byte that will brick my unit...

 

Maybe using an external programmer? Or an homebrew program that specifically writes in the flash only at the required offsets (as mathieulh stated, the 4th byte before "Dreamcast" should not be touched").

Anyways, can't a devkit have it's flash completely re-flashed? I mean it's a devkit right? It should be all customizable...

 

There's a switch to enable write mode for the flash memory, but I don't know of any SDK tools that can actually alter what is written to the flash during a reflash, nor any homebrew programs for this purpose on the dev kit.

 

It should be pretty straightforward for an homebrewer to code something that writes some bytes to the flash, alla RegionChanger. I think it's the kinda things Neoblast from Dreamcast.es (registered here too) might be interested.

It might also be worth checking if region-changer would work, i.e. if it would overwrite the death byte.

Once a simple homebrew that read/write to flash for your region is made, you can create a project of it and launch it on the DevKit, me and Mark30001 (who misteriously disapeared some years ago, I hope he's allright) tested this with an utopia botdisc project to play non-boot cd-rs on the devkit.

 

It's a shame I have no real coding knowledge. I tried building a project with the region changer but it just crashes at the Sega screen after the Dreamcast logo. I'm afraid it probably would write that death byte though... I suppose a reflash would fix it if it does. If it ever runs.

 

Try RC on an emulator and check what bytes are changed in the flashrom file. Try with both retail and DevKit bioses.

You might want to check the scrambling of RC. Binaries on GD-ROM aren't scrambled, but homebrew often are. The mil-cd loading bootstrap imply a mandatory descrambling step. Homebrews use a ip.bin which is as non-sega as possible, while pirates don't care about it. On pirates the ip.bin is modified to corect for descrambling the non-scrambled binary, while on homebrews the binary is simply prescrambled so it's non-scrambled once descrambled. I hope I make sense here... I may have confused the scrambled/descrambled states as this is somewhat confusing and I didn't played with scrambling for a while...

Basicly, try making a project of RC with normal SDK-made ip.bin, and if it doesn't work, descramble the RC bootbin and redo the project, and if it still doesn't work, scramble the original RC bootbin. (although I think the right way is to descramble it)

 

It should be doable if the switch is set to Write Enable, then you could write to the flash with the Codescape debugger. However I'm not sure so the risk is yours.
I will dig in it somewhat more with codescape next week when I have the time

 

I'm currently visiting home until next week so I haven't had the time to try descrambling RC. In Codescape I did see a section in memory where it has the flash memory header, followed by the numerous FF's of the dev kit flash, but it was only loaded to this particular section while running the SA Autodemo (Which runs fine on dev units). I haven't tried writing to it yet though. I'm not sure it would be a permanent change however? This is the RAM, not the flash memory itself...

Has there been any progress on your end ZakhooiTM?

 

As far as I understand, the ram/flash/bios are all accessible via ram-like memory mapping on the DC. So it's used like an address in ram, but it really is the flash.

e.g. flash is 0x20000 bytes long at address 0x200000

 

Try and get a mint copy of sonic adventure i used to have probs with a few dodgy copys of ecco.

 

I shall attempt to do so if I can verify that it matches the size of the flash, and I ensure I've got the right byte. A search for the flash header in Codescape while in the bios menu should find the flash.

This is my second copy which was bought new, the other one managed to crack on one side while in the care of my brother. This one runs perfect on my pal retail unit but blackscreens on the dev. Sometimes it didn't boot on the dev, the same went for Chu Chu Rocket, despite Sonic Shuffle, Quake 3, Rez, Fur Fighters and Toy Commander booting perfectly. Hopefully it's just a flash issue.

 

I'd try dumping the flash first, at the address I said, and check if it's indeed the flash. It should be IMO, then a simple re-write of the region bytes (nothing more, nothing less) should do it. OFC it's not 100% safe, as anything that messes with flashroms.

 

I'm finding numerous versions of the flash searching for 'KATANA_FLASH' in areas that aren't ram. The problem is none of these match the size flash from the dumped HKT 0120 flash online...

 

Flash ain't bios!

Bios is 2MB, 0x2000000 in hex ; while the flash in 128kB, 0x20000 in hex. The flash chip is actually 256kB, but its seconds half isn't used I think, that's 0x40000 in hex.

I dunno how the SDK tools are working, but can't you simply read and write to any area of the ram?

 

Oh I know, I meant the flash that was dumped with that bios online, should have been clearer.

All memory from 0x00000000 to 0xffffffff is viewable and writable in codescape I believe. I'm searching through all available memory now. I've been finding what looks like flash memory but doesn't even last for 0x20000 throughout addresses in memory from 0x0C000000. The ram itself begins at 0x8C000000, as far as I'm aware.

 

Well the info contained in the flash can vary from machine to machine, but there can be a lot of Null bytes in there. See this reference: http://mc.pp.se/dc/memory.html

According to that (http://ngemu.com/threads/how-to-dump-your-own-dc-bios-and-flash.51969/) the flash should be at address 0x00200000, though it might be this address inside a chunk of the memory.

 

I'll try booting the unit with the slide switch set to the right and then editing the instances of what looks like flash memory. My only problem then is working out which byte is actually the region flag.

Edit: Nope, doesn't work. The instances of the katana flash I have found don't seem to be long enough and changing the 0x0001a002 byte to 30 does not seem to do anything, the change is not permanent either.