| |
Endurion
Registered: Mar 2007
Posts: 73 |
Music Inclusion, Request?
Hi,
this is my first post here.
I've just started to play with C64 assembly a few weeks ago and am working on my first game. It's no very technical sophisticated game so far but i'd really like to include some nifty music.
I'm working with ACME on Windows right now and included a goat tracker song for testing purposes. A working alpha can be downloaded from http://www.georg-rottensteiner.de/webmisc/joegunn-alpha.zip
It's an egypt tomb exploring game with some adventure elements. I'm looking for some egypt incluenced music.
Any hints on where i can find some for inclusion or better, anyone who wants to work with me on that one?
Thanks for any feedback and critics!
|
|
... 20 posts hidden. Click here to view all posts....
|
| |
Endurion
Registered: Mar 2007
Posts: 73 |
Yeah, i thought so about the programming. The coding stuff is sorted that far. Most problems i encountered stemmed from mistakes i made before.
For the 64 chars i was referring to that weird two-colors per char in single color mode which does have that limit AFAIK.
But since you mentioned it, here goes a question :)
Right now i'm not using any IRQ code. Might there be problems if i add a music routine when i do cpu intensive things (like completely redisplaying a screen)? I assume the music player will always be IRQ based. |
| |
CreaMD
Registered: Dec 2001
Posts: 3048 |
Very good atmosphere! I like the game. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
right, that weird mode (ECM) has only 64 chars :) (I thought you were talking about multicolor)
busy waiting for d012 is usually not a good practice. If your routine is slower then 1 frame then you will miss the rasterline and your music will stop playing.
here's how to set up your raster interrupt:
sei
lda #$35 ; make sure that IO regs at $dxxx
sta $01 ;are visible
lda #$7f ;disable cia #1 generating timer irqs
sta $dc0d ;which are used by the system to flash cursor, etc
lda #$01 ;tell VIC we want him generate raster irqs
sta $d01a
lda #$40 ;nr of rasterline we want our irq occur at
sta $d012
lda #$1b ;MSB of d011 is the MSB of the requested rasterline
sta $d011 ;as rastercounter goes from 0-312
lda #<irq ;set irq vector to point to our routine
sta $fffe
lda #>irq
sta $ffff
lda $dc0d ;acknowledge any pending cia timer interrupts
lda $dd0d ;this is just so we're 100% safe
cli
jmp *
irq pha
txa
pha
tya
pha ;store all the registers to stack
lsr $d019 ;acknowledge VIC irq
inc $d020 ;do something visible
ldx #$40
dex
bne *-1
dec $d02
pla
tay
pla
tax
pla ;restore registers from stack
rti ;ReTurn from Interrupt
|
| |
Endurion
Registered: Mar 2007
Posts: 73 |
Ah, thank you! I'll try that with the goat player i included for testing. |
| |
Endurion
Registered: Mar 2007
Posts: 73 |
The music works fine but i've got a problem:
As far as i have understood the IRQ setup will just interrupt my current process, work through the interrupt routine and return to the interrupted process.
Inside the interrupt routine i simply call the music player routine to update.
The title screen works but as soon as i enter my main game loop everything hangs. Might the wait for a frame loop be the cause?
GLOOP LDA $D012
CMP #$F0
BNE GLOOP
If so, what is the usual approach to have a frame based timer? I expect that some of my game frames will be too long so a frame will be skipped (screen change, text display, level rebuild)
The player routine itself worked with my game when i didn't use the IRQ setup.
Edit: A few tests show it's not the music player, if i use the code with the border color change it hangs as well. I've put some sprites in the area $d800 to $exxx, but they're below the I/O. Can they interfere?
Edit again: It looks like my level setup routine is the cause. In what ways might i interfere the IRQ?
Last Edit: Looks kinda solved. I had a level jumper built in which used the GETIN routine. If i skip that call it doesn't hang up.
Is there a way to have both working? Should i simply put SEI/CLI around the GETIN call? |
| |
Mace
Registered: May 2002
Posts: 1799 |
You need to give $01 the right value.
In Oswald's routine, he sets it to #$35.
The normal value (which gives Kernal access) is #$37.
So, just add that to the IRQ init. |
| |
Endurion
Registered: Mar 2007
Posts: 73 |
Hmm, put me on the right track. However using #$37 hangs the thing right away.
I surrounded the GETIN call with
lda #$37
sta $01
JSR $FFE4 ;GETIN
lda #$35
sta $01
Now it doesn't crash but i also don't receive key input.
|
| |
Mace
Registered: May 2002
Posts: 1799 |
Perhaps this is why:
Normally, the vectors at $fffe/$ffff are set to $ff48.
At $ff48, the registers are saved after which a JMP($0314) takes place (under conditions).
The vectors at $0314/$0315 by default are sending the computer to $ea31.
In the following piece after $ea31, there's a JSR$ea87, which does a keyboard scan.
When you do the IRQ like Oswald does, you bypass the entire kernal routines that scans the keyboard.
All $ffe4 does, is look in the keyboard buffer, but there will never be a keystroke in that buffer!
Instead of using $fffe and $ffff for the IRQ vectors, you could use $0314 en $0315.
You can then skip the saving of the registers to stack (this is taken care of in the kernal then) and you should replace the RTI with a JMP $ea31 (or $ea7b if you want to minimize the kernal part).
[edit]
The ROM disassembled |
| |
Endurion
Registered: Mar 2007
Posts: 73 |
Awesome, that fixed it! :)
Thanks to both of you, this forum is great. Now i have both seamless music and my precious cheat keys :)
Preciousssss, i tells ya. |
| |
AüMTRöN
Registered: Sep 2003
Posts: 44 |
Yes, I was also about reply that the key scan routines will be bypassed with the manual return from interrupt method (pla, tya etc...)
You could also ignore the Kernal completely and write your own routine to scan the keyboard matrix, but this is probably more hassle than it's worth in this instance.
And I'll stop here to avoid giving out bad infos :) Damn, I really need to code something, I'm damn rusty... :) |
| Previous - 1 | 2 | 3 - Next |
