Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Redman ! (Registered 2021-10-23) You are not logged in 
CSDb User Forums


Forums > C64 Coding > Relocating Sid Tunes
2021-09-20 05:31
ws

Registered: Apr 2012
Posts: 62
Relocating Sid Tunes

So, i already had good experience using Sidreloc and i somehow got a bit obsessed with this Intro.
Well, i thought, - hm, the song is somehow funked up, maybe just some stop bytes wrong (song will actually go out of sync after one full iteration). So, why not just take the original SID, relocate it and substitute the song data in the intro with a proper chunk of data.

Until i had to find out, that 1. i somehow seem to make a serious mistake since sidreloc simply wont properly reloc above mentioned SID to $3000 if i use these args:
 sidreloc -p 30 -r a0-cf draglair2.sid drag23000.sid

and 2., wtf, upon close inspection, the tune used in the intro (above) is actually some very truncated and code-wise rearranged version of the original sid.. so.. was this common practice in 1987?

Anyways, do you folks have any ideas how i could get the Dragons Lair II tune relocated properly, using a tool (without attempting to reloc it manually)?

Furthermore, i would understand ofcourse, if one would just snibbedysnab unused subtune pattern data away, but, why is the init routine moved to another place in the (above) intro? Did someone actually take the time to downsize and modify the code of a sid tune? Or is the tune taken from a demo version?
Because, so much investment, while the rest of the intro is obviously suboptimal in quite a few places?

tl-dr: The version of the song mentioned in the credits in this Intro seems to differ from the original SID. (This is not a corrupted file, i happened to have the exact same version of that intro, back in the day)
2021-09-20 16:41
Jason Page

Registered: Sep 2015
Posts: 8
This isn't a standard rob player, by the look of things.
The init routine does some memory copying of 512 bytes, based on the tune number. This is likely patching a tune to work "correctly". It could be that this allows more instruments (so a single tune in the SID could use it's own set of 16 instruments, rather than them being shared across all tunes) - or it could be that Rob ran out of patterns, and needed a way to add more.. So it patches the patterns in, depending on sub tune.

I'm presuming that the demo version of this has ripped the music out after this process has taken place, which is likely why the code doesn't match up... And if it's not working, I presume it was this part where they didn't rip it correctly too..

Just my guess, anyway
2021-09-20 17:07
iAN CooG

Registered: May 2002
Posts: 2920
First of all, the sid in HVSC is a onefile of several data chunks from the game,
as not all the game tunes are in a single memory chunk in the game, while the
intro uses just one of the said chunks.

Then, we have what it seems to be a RESET RIP in the intro, look at $3c62
3C62: 31 EA 14 92  47 FE 4A F3  91 F2 0E F2  50 F2 33 F3
3C72: 57 F1 CA F1  ED F6 3E F1  2F F3 66 FE  A5 F4 ED F5

pratically matches the vectors in ROM
FD30: 31 EA 66 FE  47 FE 4A F3  91 F2 0E F2  50 F2 33 F3
FD40: 57 F1 CA F1  ED F6 3E F1  2F F3 66 FE  A5 F4 ED F5

So this alone should indicate corrupted music data, normally.

At $3cae we can see "START" and the rest of the bytes filled with $BB, but
according to the sid cleaning tools we have, these bytes are wrong and cause of
bad reads past these bytes: the code expects these bytes to be $ff to stop
reading these data when the pointer at $fa reaches $3cb7/8, but now it continues
reading non existent data until a $ff is found in memory.
2021-09-20 19:14
TheRyk

Registered: Mar 2009
Posts: 1109
If you halfways know what you're doing, it's even possible to relocate music just with a monitor. Or just do some patches in VICE mon to make it SidReloc-ready. You can of course also use any disassembler.

But as you asked for tools, I recommend SIDdecompiler V0.8 which generates an .asm source (KickAss source I believe, at least nothing hard to adjust to ACME or any other assembler) and translates all memory addresses to labels which makes it easy to relocate even after modifications.

PS: And the one used in the intro indeed sounds(!) corrupted towards its ending/looping if you compare it to the .SID in HVSC subtune #4, I did not peek into the data, but assume bad rip just from the weird off-key sounds in the intro
2021-09-20 20:31
iAN CooG

Registered: May 2002
Posts: 2920
Here's a result of isolating and relocating the subtune in question
https://www.dropbox.com/s/lce0uyl7826v0s6/dl2-4.7z?dl=0
dl2-4.sid          : subtune 4 of Dragons_Lair_Part_II.sid isolated
dl2-4.map          : map file generated by sidclean telling which memory area is used
dl2-4-3000.sid     : dl2-4.sid relocated to $3000 with sidreloc -k -p 30:
dl2-4-3000-reb.s   : disassembled by SidDecompiler, cleaned of some unused data where possible and moved the old music data at end of driver instead of before it.
dl2-4-3000-reb.map : map file generated by sidclean telling which memory area is used
dl2-4-3000-reb.sid : resulting sid

2021-09-20 22:24
ws

Registered: Apr 2012
Posts: 62
Nnnnice! I am so glad i asked this question here 😀

Jason Page: Very interesting speculation - Thanks!

TheRyk: yeah ofcourse i have an idea how to principially reloc a
sid by hand, i have quite a few hours on that clock, but why not ask the wizards ;-) Thanks for the hint to SIDDecompiler.

Ian: The "START" portion also was actually what initially, without tracing anything, told me, 'that probably shouldn't be there?!' and that's why i tried at first to clone the pattern data from the original SID, only to find out that the version in the intro seems to be re-compiled from segments of the song.
"the sid cleaning tools we have" is that a general we or more like some set of tools exclusive to HVSC?
Thank you so much for the isolated tune & log - where can i find SIDClean - could provide a link, if it is publicly available?
I also observed the sequence/pattern pointers using ICU64, but adding $ff termination bytes somehow didn't lead to the desired result, thats why my final verdict was truncated note data. How does one not notice that, upon testing their intro, though, after making the effort to reduce the the song data in the first place...

General question: Are there perhaps also legacy tools to manipulate ripped SID tunes? If so, any need-to-know recommendations? Like Maxi-Hack'em for SIDs or something like that?
2021-09-20 23:25
ws

Registered: Apr 2012
Posts: 62
If you out there are reading this and think, well why doesn't my SID tune work like expected after importing it to the address i relocated it to?

The PSID header holds all the answers.

So let's assume you relocated your tune successfully to $1000 and you load it without providing any loading address.
It would be perfectly normal, if it loads to $5350. Because instead of loading bytes, the first four bytes of the file are the characters "PSID", of which the first two bytes would translate to $50 and $53, resulting in a loading adress of $5350.

After the first 4 bytes of the file you should find a zero byte and then a number, most likely $02 which represents the PSID version 2 which means the header of the file is $7c bytes long.
(see details in the header description linked above)

Therefore: a file that was relocated to $1000, with an init-routine usually expected at the first byte of the song data, - like you want to jsr to $1000 to init and trigger a frame at $1003 for example -, must be loaded to $1000 minus $7c header bytes resulting in a target loading address of $0f84.

So, in Action Replay Monitor terms, L"tune1000.sid",8,0f84 will give you your relocated PSIDV2+ tune ready to be triggered at the adresses given in the header (see above).

Maybe this helps, if you are new to this topic, to remind you that relocing a SID tune most probably also includes the PSID header bytes. So reloc to $1000 does not mean you can just incbin to $1000 without taking the amount of header bytes into account.

*=$1000-$7c 
incbin "tune1000.sid"

would be the solution for a PSID V2 + tune, if you want to keep the header, or
*=$1000
incbin "tune1000.sid",$7c

to dispose of the header, if you know where your init and trigger routines are.

This incbin syntax is pretty common, but may vary among compilers. The syntax mentioned here is from CBMprgStudio .
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Knight Rider/Excess
Twilight/Excess/Arcade
Chesoner/House Designs
Tricket/Dominators
That8BitChiptuneGuy
Sentinel/Excess
iAN CooG/HVSC
Andy/AEG Soft
IRQBreaker
stephan-a
St0rmfr0nt/ExCeSs
Ghost/Excess
kbs/Pht/Lxt
Nordischsound/Hokuto..
Guests online: 68
Top Demos
1 Edge of Disgrace  (9.6)
2 Coma Light 13  (9.6)
3 Bromance  (9.6)
4 Uncensored  (9.6)
5 Memento Mori  (9.5)
6 Lunatico  (9.5)
7 Unboxed  (9.5)
8 Comaland 100%  (9.5)
9 Wonderland XII  (9.5)
10 Christmas Megademo  (9.5)
Top onefile Demos
1 Copper Booze  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Dawnfall V1.1  (9.5)
4 Cityscape 2730  (9.5)
5 To Norah  (9.5)
6 Lovecats  (9.5)
7 Elite Code Mechanics  (9.4)
8 Barry Boomer - Trapp..  (9.4)
9 FMX Music Demo  (9.4)
10 For Your Sprites Only  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Crest  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Fossil  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Irata  (9.8)
3 Sixx  (9.8)
4 Taper  (9.8)
5 hedning  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2021
Page generated in: 0.039 sec.