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


Forums > C64 Coding > *stupid* ASM Sid Player Example ?
2006-03-23 15:53
Trifox
Account closed

Registered: Mar 2006
Posts: 108
*stupid* ASM Sid Player Example ?

Hi i just started coding on the good old c64 and i am wondering how to play music in an assembler executable,
on some tutorials i found that the music usually is located at $1000 but if i load a sid file to that location and jump

jsr $1009

nothing happens, the c64 exits my programm, i think it is clear, a sid file is not an assembler programm to jump in, but how do i now play a music file ?!?!?!?

thanks for any reply ...
2006-03-23 16:04
Oswald

Registered: Apr 2002
Posts: 5029
trifox, first learn the difference between jsr and jmp.


secondly,

each music has a init adress, and a play adress.

init is used to initialize the player.

play is to play the music, and has to be called 50 times per second. (at most cases)

if the init is at $1000, and play at $1003, the most simple player is :

sei
lda #$00
tax
tay
jsr $1000

again

lda #$40
cmp $d012
bne *-3
inc $d020
jsr $1003
dec $d020

jmp again


probably the music you try to use has no real code at $1009 ? or you thought jsr $1009 will play the music, and you have to do nothing else ?
2006-03-23 16:20
JackAsser

Registered: Jun 2002
Posts: 1994
Also, as you say, .sid files are not directly usable on the C64. They have in most cases a header of $7E bytes. In the beginning of the header you can spot the load and run addresses (google for exact locations). Write those down and then strip your .sid file of the first $7E bytes. Then load the stripped chunk to the load-addy written down, in the C64's memory. Then apply Ozzies code.
2006-03-23 16:31
Trifox
Account closed

Registered: Mar 2006
Posts: 108
ehrm, i have progged asm on the amiga, and yes yes yes sir, the difference between jmp and jsr ist that the PC is Pushed onto the stack when calling a JSR ....

and i have found some tutorials on basic c64 stuff, i am currently using a delay function to wait for a specific raster position, wanting to call the player ... but it not works ...

i have googled and found
http://www.unusedino.de/ec64/technical/formats/sidplay.html
now i am trying to set up my sid file ....

if i get it right, a sid file is actually a asm programm which sets the sid register in the 64 when called periodically(50x a second ) the program outputs nice beautiful sid music ... all i have to do is:

1. Strip The )$/()($/)/($ SID Header informations, extract
tune start and tune init locations, jump to them and listen ...

thank you for fast replies ...
2006-03-23 17:36
Oswald

Registered: Apr 2002
Posts: 5029
sidplay has an option to save only the c64 data, also in sidplay use the tune info menu to find out the init and play locations (also load adress, length, etc), very simple.

yes, the play routine sets sid regs as you think, and the init routine sets up the variables and stuff.

sorry about the jsr/jmp abuse, but from your first post it looked like you're mixing the two.
2006-03-24 10:13
Optimus

Registered: Jan 2002
Posts: 122
And something else I want to notice again even if it's already written there well in Oswald's code.

It's necessary to zero the register A (X and Y too? Maybe..) before making the init call. Else everything might crash!

Believe me, I had spent a twenty minutes to find out what the fuck is going on with some old code, and it was that! I am used to players on CPC where you don't need to care about registers before calling the init routine ;P

Could also be that mistake for your case too :)

p.s. Well, the JSR $1009 should be JSR $1003 too.
2006-03-24 10:18
Steppe

Registered: Jan 2002
Posts: 1510
The A register almost always hands the subtune number to the init routine.

Hence:
LDA subtunenumber (mostly #$00)
JSR init

In some cases it's X or Y, but meanwhile almost all of these cases have been fixed by adding a TAX or TAY on init, so you can safely use A in 99.9% of all cases in HVSC.
2006-03-24 10:25
Optimus

Registered: Jan 2002
Posts: 122
>The A register almost always hands the subtune number to the init routine.

Thanks! I just got it :P
2006-03-25 19:46
Trifox
Account closed

Registered: Mar 2006
Posts: 108
ok, now i am having a sid file playing, it is taking up quite much rasterlines ... ;( around ~20 ? thankyou
2006-03-25 20:15
Tch
Account closed

Registered: Sep 2004
Posts: 512
Quote: ok, now i am having a sid file playing, it is taking up quite much rasterlines ... ;( around ~20 ? thankyou

That´s close to average.
You´ll probably find many demos crashing when you add a song of your choice. ;)
2006-03-25 21:27
Trifox
Account closed

Registered: Mar 2006
Posts: 108
'nkay, what is about interesting sid registers ?!?! any meaningful to display as bars ?!?!?!
2006-03-26 00:43
cadaver

Registered: Feb 2002
Posts: 1154
You plan to route all SID writes through the RAM underneath IO area? (no other way to read SID registers, unless you happen to know where/how the player in question stores its own internal data)

Just be aware that depending on the SID register write order, you may break how the player was intended to sound like when you then write the data from your register buffer to SID.

Unless you have a SuperCPU and implement a 6510 emulator for the playroutine to also capture the SID register write order :)

What to display.. don't know, maybe some equalizer bars based on frequency and detecting gate on/off changes.
2006-03-26 00:52
dalezy

Registered: Apr 2002
Posts: 475
trifox, do you happen to have been nicknamed brötchen during the 90s?
(sorry for this totally off-topic interrupt =)
2006-03-26 08:23
Oswald

Registered: Apr 2002
Posts: 5029
cadaver,

- last 2 sid regs are readable
- if you change sid writes to jsr's, you can know the order too.
2006-03-26 10:14
cadaver

Registered: Feb 2002
Posts: 1154
Hmm, that's clever. Though you'd still need the emulator (if possible to implement in sufficient speed) to get exact timing :)
2006-03-26 11:59
WVL

Registered: Mar 2002
Posts: 886
<smart idea to read registers and still keep timing>

how about calling the tune twice,

once with the tune writing below IO in the ramspace ($01=#$30), and then call it again ($01=#$35/#$37) so it will write the registers into IO.

The 'only' thing you'd have to do is backup all changing memory adresses in which the tune keeps where it's playing right now, and restore them when playing the tune the 2nd time.
</smart>
2006-03-26 12:14
cadaver

Registered: Feb 2002
Posts: 1154
Yeah it should not even be *terribly* expensive on rastertime, I guess the state doesn't in most cases exceed 100 bytes. Save+restore (unrolled) = lda,sta,lda,sta * 100 = 1600 cycles = about 27 lines. Plus calling the player twice :)
2006-03-26 12:19
Trifox
Account closed

Registered: Mar 2006
Posts: 108
Quote: trifox, do you happen to have been nicknamed brötchen during the 90s?
(sorry for this totally off-topic interrupt =)


ehrm yes: I AM BRÖTCHEN, not the Brötchen, simply BRÖTCHEN, hehe, it is an old relikt from Mailbox Modem Times ...
2006-03-26 12:20
WVL

Registered: Mar 2002
Posts: 886
another thing you can do is have the tune in memory twice, say once at $1000, and once at $2000..

saves the trouble of changing the state back, except maybe some 0page adresses.. ofcourse it does cost a bit more memory, and you have to relocate the tune..
2006-03-27 09:51
Oswald

Registered: Apr 2002
Posts: 5029
cadaver, I will play you $10000 if you can tell the difference between a music played "normally", and using stored register data for each frame. AFAIK modern players do sid writes like first doing the "calculations" then write sid regs at "one go", so if its 8 or 44 cycles between writes is highly negligable.

thats it about the importance of timinig.

but there's still a solution, which does not need the stupid emulation, to preserve timing:

each JSR-ed routine may read (and stop when entered) a cia timer, and compensate for the time the routine uses up. (and restart the timer when exiting the routine.)

then replaying the tune with the stored data and timing is a breeze.
2006-03-27 10:04
chatGPZ

Registered: Dec 2001
Posts: 11148
prepare the money for transfer, there are a bunch of tunes that sound terribly wrong if the timing is somehow disturbed (even slightly). example is the cucumber-juice 2 note tune by zardax, the bassdrum makes funny bleep noise if played with wrong timing.
2006-03-27 10:21
Oswald

Registered: Apr 2002
Posts: 5029
I wrote play, not pay :D
2006-03-27 10:46
Style

Registered: Jun 2004
Posts: 498
hahaha, how do you 'play' someone money? :)
2006-03-27 10:56
cadaver

Registered: Feb 2002
Posts: 1154
Yeah, those write-ADSR-first-then-wave players that strive to achieve the sharp firstframe-attack are quite susceptible to timing differences, *even* when the player just dumps all channel regs in fixed order at the end of channel execution. I know from weird bugreports from some GT users :)

Oldstyle (Hubbard-like) hardrestart & write-order with wave first is much less sensitive, but you never get the scene-approved sharp attacks then.

However, for what's it worth, I believe quite good general solution (for like 99% of tunes) is to write all SID regs in a loop either forwards or backwards. That scpu emulation idea was just for some evil fun..
2006-03-27 11:01
Frantic

Registered: Mar 2003
Posts: 1629
However, changing sid writes to jsr's wouldn't be so easy after all. I mean, you would have to distinguish code from data, at least, to make sure you don't change some music data into a JSR? ...or did I miss something?

So, some kind of built in disassembler would be required too, and it would be fucked if there is some selfmodifying code in the player. ...which leaves us at the emulator again? :)

(And, yes, I understand that we are far from Trifox' initial questions now.)
2006-03-27 11:06
cadaver

Registered: Feb 2002
Posts: 1154
And, if the player was so messed as to use zeropage indirect indexed for SID writes, there would be no room for JSRs. :)
2006-03-27 11:16
Trifox
Account closed

Registered: Mar 2006
Posts: 108
... but anyway, i got a tune played ... to be honest, i can't really hear if a sid tune plays false or correctly, its just beep and buirks and meeps and moooeps ... but if you make a demo without music, no one aligns its head to the big screen ... ;)
2006-03-27 11:40
Stryyker

Registered: Dec 2001
Posts: 465
I have noticed some editors sounds different to packed tunes I guess mostly because of indexed instructions crossing more boundries in the packed tune compared to the editors.
2006-03-27 12:03
Oswald

Registered: Apr 2002
Posts: 5029
taki's cubic player does this, reroutes all sid writes.. so its pretty possible.
2006-04-06 19:55
Axel
Account closed

Registered: Apr 2006
Posts: 42
You can use PSID. It change SID into PRG files witch information where is INT/Play and where is tune in memory. Hope that helps.
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
stephan-a
iAN CooG/HVSC
LDX#40
fegolhuzz
Acidchild/Padua
Tim/Silicon Limited
Tom/TRS
Jetboy/Elysium
Frostbyte/Artline De..
Pajda/Faith Design
Raf/Vulture Design
Guests online: 88
Top Demos
1 Next Level  (9.8)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Aliens in Wonderland  (9.7)
5 Coma Light 13  (9.7)
6 Edge of Disgrace  (9.6)
7 No Bounds  (9.6)
8 Comaland 100%  (9.6)
9 Uncensored  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 It's More Fun to Com..  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Rainbow Connection  (9.5)
8 Dawnfall V1.1  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Covert Bitops  (9.4)
2 Nostalgia  (9.4)
3 Oxyron  (9.3)
4 Booze Design  (9.3)
5 Crest  (9.3)
Top Graphicians
1 Sulevi  (9.9)
2 Mirage  (9.8)
3 Mikael  (9.7)
4 Lobo  (9.7)
5 Archmage  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.072 sec.