[CSDb] - User Forums - Relocating Sid Tunes

Welcome to our latest new user maak ! (Registered 2024-04-18)

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Relocating Sid Tunes

2021-09-20 05:31

ws

Registered: Apr 2012
Posts: 228

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: 87

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: 3132

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: 2053

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: 3132

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: 228

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: 228

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 .

Refresh

Subscribe 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

eryngi
alwyz/udi
megasoftargentina
Guests online: 108

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)

Top onefile Demos

1 It's More Fun to Com..  (9.9)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)

Top Groups

1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top Original Suppliers

1 Derbyshire Ram  (9.5)
2 Black Beard  (9.4)
3 hedning  (9.2)
4 Baracuda  (9.1)
5 Irata  (8.5)

Page generated in: 0.04 sec.