chipmusic.org is an online community in respect and relation to chip music, art and its parallels.
You are not logged in. Please login or register.
Hello!
Iam using SidEdit for converting a packed tune to .sid and have some questions about it.
It is when Im add values in the header it asks for loadaddress, initaddress and playaddress.
Seems when I load some other already ripped tunes the Loadaddress it set to $0000.
How do I know what values my packed tune need?
Cheers 
If you're exporting from some known editor the defaults are usually:
load = $1000
init = $1000
play = $1003
It's a bit different if you use multispeed tracks but for singlespeed that should work. Most modern editors adopt the same standard so if the load address is somewhere else the init will be the same as the load address and the play address will be 3 bytes ahead.
The first two bytes of your prg will tell you the load address if you load it into a hex editor such as XVI32. It's stored backwards:
prg: $00,$10 = $1000
It works!
Thank u 4mat! and btw you got some really nice tunes
d.
I've tried to use SIDEdit to convert Future composer 2 PRG files to SID, but it doesn't work.
I've also used PRG2SID, and it works (only in 32 bit envirnoment). But sometimes the result sounds like garbage. Drums sound like continuous machine gun fire, certain bass sounds are quiet and a few arpeggios is a stuck note.
I noticed PRG2SID said init is on $1800 and play on $1806. And looking in the disassembled data view, it's fairly obvious.
I tried that in SIDEdit, and set the flags to 0x0014.
But no. Only silence.
When loading a working PRG2SID-converted SID into SIDEdit, I see no difference. What's up with that?
And are there some illegal opcodes or something for certain sounds in the future composer play routine which sidplay2/w can't handle?
Last edited by MadModder (Nov 21, 2015 1:05 pm)
What Future Composer is it? The old 1988 one? I wouldn't think that playroutine uses illegal opcodes, not a lot of point in a music driver. Anyway sidplay2/w's 6510 emulation is pretty thorough. (it has to be to support BASIC load files) Have you tried dropping the SID into VSID? (that comes with Vice)
To be honest if you're on Windows I'd ignore all tools and write the SID spec you need in a text file. Save that as .SID, rename your exported song data to .DAT (with the same filename as the .SID) and load that into sidplay2/w. Then save from there as a packed PSID file.
SIDPLAY INFOFILE
ADDRESS=0000,1000,1003
SPEED=00000000
SONGS=1,1
NAME=Song Name
AUTHOR=Your Name
RELEASED=2015 Whenever
SIDMODEL=8580Would play a single frame track just fine. The frame call at $1006 makes me wonder if it's multi-speed, but if it's the old Future Composer I don't think that's an option.
Last edited by 4mat (Nov 21, 2015 1:20 pm)
Yes, it's the same old one I used back in 1989. 
(Only says AXIOM/BB for a short while and jumps right in to the menu.)
Do you mean I should use $1000 although the PRG starts with bytes 00 18 ?
;1800 JMP $2000
;1803 JMP $2117
;1806 LDA $2174
.
.
. and the rest...
Haven't tried VSID yet
[edit] tried it. Same thing.
Last edited by MadModder (Nov 21, 2015 1:51 pm)
No, sorry that was for a song at $1000 . Try:
ADDRESS=0000,1800,1806Setting the load address to 0000 makes the Sidplayer use the PRG's 2-byte header to find out where to load the file automatically. If that doesn't work you can try:
ADDRESS=1800,1800,1806Ah, hang on. Are you sure it's not $1803 for the play rather than $1806? It's jumping out to another part of the code there. (it's easier to have a couple of JMPs at the start of the code rather than remember exactly where the init & play parts start, especially if you're replacing one song with another in an intro)
EDIT: no just tried exporting a track from the editor and it is $1806 to play, this works:
SIDPLAY INFOFILE
ADDRESS=0000,1800,1806
SPEED=00000000
SONGS=1,1
NAME=Future Composer
AUTHOR=You
RELEASED=2015
SIDMODEL=8580Last edited by 4mat (Nov 21, 2015 2:07 pm)
I've now tried the manual way with a textfile and so on. It's the exact same result as with PRG2SID.
0000,1800,1806 = music plays, but wrong
1800,1800,1806 = nothing
0000,1800,1803 = nothing
at $2117:
;2117 LDA #$02
;2119 STA $2174
;211C RTS
which is a bit strange, because it should be called with a JSR, and not a JMP?
And $2000 is some code in the middle between the data for track 2 and 3.
Haven't looked on the code for songs from other music software but this seems odd to me.
No you use JMPs because when you call the music player in your own stuff you call it with JSR , so the RTS gets picked up by your JSR rather than the music routine's JMP. It's more for convenience sake than anything else. If a coder writes an intro and wants to re-use it with different music they can drop a new file in and not have to change their calls to the init or play when using a different music player. That's why a lot of music drivers have the same 3 calls at the start of the music routine. (also they usually default to $1000 because you can't put graphics there so it's a good place for music)
Just tried it again with the version I linked above and I'm getting it to play fine with 0000,1800,1806 I haven't actually written any data in, I just chose one of the demo songs then saved that out packed. I noticed there are several version of V2 out there, which version are you using?
Last edited by 4mat (Nov 21, 2015 2:29 pm)
Yes most of my tunes plays just fine. I havn't figured out what's different with those that doesn't play right.
I've only got a single PRG file of this Future composer. No dedicated disk or anything.
The title/menu screen says:
Future-Composer V2.0
expanded and improved by Axiom/BB
It's the V2.0 from this D64 http://csdb.dk/release/?id=10605
And it says under goofs there
"This version of Future Composer has a broken packer"
Can that have anything to do with it perhaps?
Last edited by MadModder (Nov 21, 2015 2:43 pm)
Ah, yeah that would mess things up, there seem to be several versions of a v2.1 on csdb. Incidentally the famous Rock of Finnish Gold made a comeback recently and he's using FC again as well. (v1.0)
Last edited by 4mat (Nov 21, 2015 2:58 pm)
Well it didn't change anything. I loaded my problematic tune into the fixed V2.1 that was linked from the broken V2.0 one on csdb, and saved a new copy from V2.1
Same same.
Is it a particularly long track? It's unlikely, but there might be an upper limit the packer stops at internally so the rest of the data doesn't get packed. Again, unless it's in the instructions I doubt that would be the case though. (nothing about it in the instructions on one of those disks) I guess you could try loading it in a later version and see what the backwards compatibility is like. Can't imagine the player changed that much, a v4.0 track doesn't sound a lot different to a v1.0 in fx.
No it is not a long track. I never did particularly long tracks. Mostly looping ones with a few blocks and no more than 2 rows of track data.
I have now saved the track from FC 2.1, converted it to SID, used PSID64 to convert that into a executable PRG, and loaded that into VICE and ran it. Same broken music.
I also tried to save+relocate to $1000.
I have no real C64 set up right now. It's all packed down. That would be the next step I think.
[edit]
This is the file http://madmodders.se/temp/c64/problematic.prg
Uhm, no. hold on. that did not load at all...
[edit2]
Now, it's the right file. Try it if you have the time.
Last edited by MadModder (Nov 21, 2015 3:57 pm)
Tried loading it into FC V4.0 and save from there. Same again.
Frustrating.
BTW, this is based on another track I did earlier (which plays very well in sidplay2/w), and the only thing I did was to add a few blocks, edit the bass sound, and rearange the track data somewhat. The only thing I can think of is some odd instrument parameter...