[CSDb] - User Forums

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Sidreloc

2012-05-28 12:38

lft

Registered: Jul 2007
Posts: 369

Sidreloc

Sidreloc homepage, with introduction and explanation

"Sidreloc is a tool for relocating SID tunes any number of whole pages, using a novel but remarkably simple algorithm. It can also relocate all zero-page variables used by the tune.

Sidreloc is capable of relocating 91% of HVSC #56 out of the box. Many of the remaining tunes can be relocated by tweaking the settings to fit them."

2012-05-28 13:06

chatGPZ

Registered: Dec 2001
Posts: 11386

awesome!

2012-05-28 13:16

Zyron

Registered: Jan 2002
Posts: 2381

Incredible!

2012-05-28 13:57

Flavioweb

Registered: Nov 2011
Posts: 463

Wow... Fantastic.

2012-05-28 15:41

Pantaloon

Registered: Aug 2003
Posts: 124

yeah yeah, but where is the splitter :P

2012-05-28 17:45

BYB

Registered: Jan 2011
Posts: 20

sounds fantastic, about 77% relocated without errors.
Amazing.

2012-05-28 18:53

iAN CooG

Registered: May 2002
Posts: 3194

I have added the win32 exe + the sources modified where needed

- stdint.c not present in MSVC, so I choose to use mingw gcc.
- err.h/err.c not present in mingw includes aswell. Copied errx() function
from $location_found_googling. =)
err() replaced with errx(), I don't know why there is any need for so many
functions just to fprinf(stderr, something) and exit(exit_value).
- usage screen reformatted for 80 columns, there were just too many spaces.
- PSID header: text fields should not be 0 padded on 32nd char anymore as
from HVSC#55, whole field must be used fully. If anything, the structure
char members should be sized 33 bytes if they are going to be used as null
terminated strings, but if used only with memcpy() there should be no need.
- Bug found and removed:
Relocation END address is excessive if it's autodetected. By default should
be equal to the loading end address (up to the page boundary to be safe)
I don't understand the purpose of this code in sidreloc.c, so I have
commented it out.

for(i = 0; i < 64 && reloc_end != 0xcfff && reloc_end != 0xffff; i++) {
reloc_end += 0x100;
}

I am sure lft knew what he was doing, but I just fail to see how it could be
helpful in normal cases. If anyone wants to override the range, -r can be used.

Example trying to relocate from $1000 to $c000

C:\> sidreloc -p c0 Zelda_Overworld_Final_Version.sid zeldac000.sid
Zelda Overworld (Final Version), Sascha Zeidler (Linus), 2004 Sascha Zeidler, $0ff6-$1cae, 1 subtunes
Relocating from $0f00-$5cff to $c000-$0dff
Fatal Error: Neither the source nor the destination relocation range may overlap with the zero-page.

Why 5cff? if anything should be $1cae. Parameter -r is handy in this case.

C:\> sidreloc -p c0 -r 0f-1c Zelda_Overworld_Final_Version.sid zeldac000.sid
Zelda Overworld (Final Version), Sascha Zeidler (Linus), 2004 Sascha Zeidler, $0ff6-$1cae, 1 subtunes
Relocating from $0f00-$1cff to $c000-$cdff
Analysing subtune 1
Warning: Write out of bounds at address $dc04-$dc05
Verifying relocated subtune 1
Bad pitches: 0, 0%
Bad pulse widths: 0, 0%
Relocation successful.

The "Write out of bounds at address $dc04-$dc05" can be safely ignored, it's
the CIA timers being initialized for multispeed play.
Anyway with the fix, now $0f00-$1cff is used by default.

2012-05-28 19:44

lft

Registered: Jul 2007
Posts: 369

Hi Ian!

Thanks for porting!

Regarding that extended relocation range: In a bunch of tunes, the initialisation routine copies a large block of data to some remote part of memory. This copying often extends beyond the loading range of the tune; sometimes by several kilobytes. For instance, many Kjell Nordboe tunes copy 4 KB regardless of the size of the actual data. If the relocation range is not extended, the base pointer for the data will sometimes be used to address data in the relocation range, and sometimes not; hence, there will be contradicting equations. Furthermore, sometimes the destination area is not so remote: it will in fact overlap with the source area. Hence, the relocation range should extend to include an additional 4 KB.

I don't remember why I finally settled for a 16 KB extension, but there was a couple of tunes for which this was necessary, and there didn't seem to be any particular downside to it. One has to avoid extending into the I/O area, of course. The Zelda situation is actually a bug: the extension should not cause the relocated area to wrap into the zero-page. But this can be fixed.

2012-05-28 20:04

iAN CooG

Registered: May 2002
Posts: 3194

I see what you mean, those sids like Nordboe_Kjell\Its_Fun_Time.sid for example, relocate the data because the player routine was too far from the data and have been narrowed in memory, then the init puts the data where it's supposed to be before starting playing. There are many in HVSC made like this to avoid having 30kb or more large sid files with 25kb of unused area between them. It's also used when onefiling many sids from games that have to move data and even code around, being careful to not overwrite what's already in memory.
I still think that these are special cases and Sidreloc shouldn't make the range "enlarged" by default, but only if it's detected to be needed, for example when there are writes outside the load range that are subsequently read after the init.
Apart that, great tool, cheers.

Refresh

Subscribe to this thread: