| |
breeze
Account closed
Registered: Mar 2009
Posts: 20 |
Kick Assembler & SID Player
In previous work I used the built-in sid-player Kick Assembler and the SID wa play correctly. At least in the rumor was is not noticeable.
Working on new intro, I was encountered a problem with play the SID module. The module has play incorrect sounds with some distortions.
I tried to create an executable PRG-file using PSID64 and found that the sound is clear and correct.
So I formed the opinion that the embedded player in the Kick Assembler is slightly incorrect.
Maybe I am wrong and I do something wrong. But you can show me an example of another SID-player, and that I could test and solve own problem. Maybe somehow i can use the player from PSID64?
p.s. Many thanks in advance. Because of this trouble, we must postpone the our new release. |
|
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
I think you're using zeropage addresses the music player uses as well. change your zps and check again |
| |
breeze
Account closed
Registered: Mar 2009
Posts: 20 |
Quote: I think you're using zeropage addresses the music player uses as well. change your zps and check again
I am a little not quite understand what I need to do. Here is an example of code that is used in Kick Assembler:
.var music = LoadSid("Nightshift.sid")
:BasicUpstart2(start)
start:
lda #$00
sta $d020
sta $d021
ldx #0
ldy #0
lda #music.startSong-1
jsr music.init
sei
lda #<irq1
sta $0314
lda #>irq1
sta $0315
asl $d019
lda #$7b
sta $dc0d
lda #$81
sta $d01a
lda #$1b
sta $d011
lda #$80
sta $d012
cli
this: jmp this
irq1:
asl $d019
inc $d020
jsr music.play
dec $d020
pla
tay
pla
tax
pla
rti
.pc=music.location "Music"
.fill music.size, music.getData(i)
|
| |
Skate
Registered: Jul 2003
Posts: 494 |
nothing seems to be wrong with that piece of code. where is the music located? $1000? |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
A couple of suggestions:
* Which sid module are you using? If you are trying to play a multispeed sid, then it wont work.
* When you run the music in an emulator, the sound might not be simulating the sid chip correctly (try a different one, or a c64).
* Have you tried swithing between the old and the new sid-chip in the emulator? |
| |
breeze
Account closed
Registered: Mar 2009
Posts: 20 |
Sorry, I did not notice how over time the allotted for the interrupt is over. While I was writing an example, I decided to call at interupt only the music and the problem disappeared.
There is a lack of programming experience under C64. Sorry >_< |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
your irq ends with pla tay pla tax etc...
but it dont start with pha txa pha...
so it is fuxxoring the regs |
| |
Mace
Registered: May 2002
Posts: 1799 |
What Jan said. |
| |
breeze
Account closed
Registered: Mar 2009
Posts: 20 |
Quote: your irq ends with pla tay pla tax etc...
but it dont start with pha txa pha...
so it is fuxxoring the regs
hmm... and it's true, somehow I missed this point in mind... thanks! |
| |
Stone
Registered: Oct 2006
Posts: 172 |
What are you guys on? When using the irq vectors at $0314, all the registers are pushed on the stack for you by the kernal irq handler, so the irq end bit is perfectly fine. If this wasn't the case, the popping of registers would do more than thrash the registers, it would underflow the stack as well, causing a random jump (CRASH). |
| |
breeze
Account closed
Registered: Mar 2009
Posts: 20 |
Quote: What are you guys on? When using the irq vectors at $0314, all the registers are pushed on the stack for you by the kernal irq handler, so the irq end bit is perfectly fine. If this wasn't the case, the popping of registers would do more than thrash the registers, it would underflow the stack as well, causing a random jump (CRASH).
Here is how ... thanks! Now I'll know! |
| |
Skate
Registered: Jul 2003
Posts: 494 |
while we are talking on irqs, I just wrote an experimental code to see how irq fuckes up register values if we don't save them.
there is a little waiting time in the main loop between lda and sta. irq fucks up register values when waiting time block intersects with irq rasters. not a surprise, that's the expected result. but it also shows that if we always catch $d012 in our main loop and if we are sure main loop and irqs never conflict (rasterwise), then we wouldn't need to save a,x,y registers at all (no pha pla or sta lda stuff). of course main loop should never trust registers from the last frame. that's nothing unknown but I've never thought of getting rid of saving register values. I've always stored and restored register values even if main loop is just "jmp *". I just noticed it's not a must. maybe it can be useful in a very rare case in the future. :)
This information only applies while we are working in disabled kernal mode.
!to "irqtest.prg",cbm
* = $0801
!byte $0c, $08, $00, $00, $9e, $32, $30, $36, $31, $00, $00, $00
* = $080d
sei
lda #$35
sta $01
lda #$7f
sta $dc0d
sta $dd0d
lda #$01
sta $d01a
lda #$80
sta $d012
lda #$1b
sta $d011
lda #<irq
ldx #>irq
sta $fffe
stx $ffff
asl $d019
bit $dc0d
bit $dd0d
cli
-
lda #$02
ldx #$00
dex
bne *-1
sta $d021
jmp -
irq
; sta toA
; stx toX
; sty toY
inc $d020
lda #$00 : pnt = *-1
tax
tay
inc pnt
asl $d019
; lda #0 : toA = *-1
; ldx #0 : toX = *-1
; ldy #0 : toY = *-1
rti
|
