Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Composing > Relocatable music routine
2022-09-12 13:28
Mixer

Registered: Apr 2008
Posts: 460
Relocatable music routine

There are plenty of music routines, which can be compiled from source or relocated by self modifying some of the code, but has anyone written a fully relocatable music routine?

Something that you can just load to any address and it'll work.(Obviously the complexity of the player is a factor, but let's say something like GT)
 
... 15 posts hidden. Click here to view all posts....
 
2022-09-12 15:47
Spinball

Registered: Sep 2002
Posts: 89
i am quite shure that nebula implemented selfrelocating on init for some player (JCH?) back in the days.
2022-09-12 20:37
Case

Registered: Aug 2002
Posts: 143
I am pretty sure that JCH released his own relocation tool, along with one to split the music into 4 or 5 parts that could be spread throught memory.

I also remember there being a relocation tool for sid-chip scratchers.

But as started previously due to the complexity, tables etc. they cannot be just loaded to a memory location and work.
2022-09-13 08:27
ChristopherJam

Registered: Aug 2004
Posts: 1424
Technically the 103 bytes of code for Rozzo is completely relocatable - the state variables are all in zero page. But there are four instructions that read from the 152 bytes of song data (notes, durations & frequencies) that would need patching if you wanted to move that as well.

(and yes, obviously this is an extremely minimal player - fixed ADSR, only wave $21, no modulation or filters, and gate off three frames before note end)
2022-09-14 02:49
ws

Registered: Apr 2012
Posts: 251
Just because i asked this myself a while ago briefly and thought scanning memory for my own code would be the simplest: what would be the fastest way to find out the code's own base adress?
Something like briefy writing code to an empty place like the tape buffer, jsr there and read the return adress from stack?
2022-09-14 05:39
ChristopherJam

Registered: Aug 2004
Posts: 1424
   jsr here
here:
   pla
   tax
   pla

will put the address of here-1 into AAXX and restore the stack pointer to the value it had before the JSR was executed.
2022-09-14 09:16
Walt

Registered: May 2004
Posts: 47
For Scortias tune in The Phoenix Code I made some code to relocate parts of the tune on the fly (blocks of music data) as the FLI stretcher needed $2000 and up. It would copy the music data and then change the pointers in the player.
2022-09-14 10:55
Conrad

Registered: Nov 2006
Posts: 856
Quote:
   jsr here
here:
   pla
   tax
   pla

will put the address of here-1 into AAXX and restore the stack pointer to the value it had before the JSR was executed.


I did something similar in my (unreleased) relocatable small player:
play:
	tsx
	lda $0101,x	
	sta $02
	lda $0102,x	
	sta $03

	ldy #$00	
	lda ($02),y	
	sta $04
        ...etc...

        rts

        jsr play


Does using PLA within a sub-routine affect the stack pointer, and that the RTS will not return to the previous program counter / address? This concern was why I wrote my routine that way, despite it uses more bytes.
2022-09-14 11:04
ChristopherJam

Registered: Aug 2004
Posts: 1424
Quoting Conrad

Does using PLA within a sub-routine affect the stack pointer, and that the RTS will not return to the previous program counter / address?


The PLAs in the snippet I posted do affect the stack pointer, but they just remove the extra two bytes placed on the stack by the JSR in the line before 'here:'. The original two bytes placed there by the caller are still there.

I'm confused though - doesn't yours init a pointer to the location your routine is called from?
2022-09-14 11:35
Conrad

Registered: Nov 2006
Posts: 856
Quote: Quoting Conrad

Does using PLA within a sub-routine affect the stack pointer, and that the RTS will not return to the previous program counter / address?


The PLAs in the snippet I posted do affect the stack pointer, but they just remove the extra two bytes placed on the stack by the JSR in the line before 'here:'. The original two bytes placed there by the caller are still there.

I'm confused though - doesn't yours init a pointer to the location your routine is called from?


I need to relook at what the entire routine does (I abandoned it months ago :)) ... I think it's for pointing to some init data which lives with the address page of the routine itself, and this code copies that data into the zeropage area. The music play routine uses indirect zero-page reading/writing throughout.
2022-09-14 20:04
ws

Registered: Apr 2012
Posts: 251
@conrad i find @christopherjam's solution is very elegant and since it just jsrs to self, the removal of the stack bytes by pla is absolutely okay since no rts is needed anymore. cool!
Previous - 1 | 2 | 3 - Next
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
Rhythm/G★P
Hairdog/BOOM!^Dream
VanessaE/Digital Aud..
Airwolf/F4CG
Guests online: 133
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Codeboys & Endians  (9.7)
4 Mojo  (9.6)
5 Coma Light 13  (9.6)
6 Edge of Disgrace  (9.6)
7 Signal Carnival  (9.6)
8 Wonderland XIV  (9.5)
9 Uncensored  (9.5)
10 Comaland 100%  (9.5)
Top onefile Demos
1 Nine  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.5)
6 Scan and Spin  (9.5)
7 Onscreen 5k  (9.5)
8 Grey  (9.5)
9 Dawnfall V1.1  (9.5)
10 Rainbow Connection  (9.5)
Top Groups
1 Artline Designs  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Performers  (9.3)
5 Censor Design  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 Tim  (9.7)
4 Irata  (9.7)
5 hedning  (9.7)

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