Page 1 of 1
skp always
Posted: Sun May 10, 2009 8:03 am
by PK
Because of the lack of a "
skp greater_than_zero" or a "
skp not_zero" test condition, I've used a work-around that utilizes "
skp run" as a pseudo-branch in a few pieces of code.
Twice now I've had code where the skip was not being taken at runtime after the first pass. It drove me completely nuts until verified that "
skp run" as I typed it was not working properly in the hardware. I have not had time to track this bug down to being in the assembler or the FV-1 hardware, but I had no trouble repeating it at the time.
I needed to get my code running with a skip that was always taken, so a little analysis shows the flags (
run,
neg,
zrc,
zro, &
gez) seem to be ANDed together. For instance, a skip that asked for
neg and
gez at the same time will never be taken.
In order to construct a
skp that will always be taken, simply don't ask for any of the 5 conditions in the instruction.
Code: Select all
equ always, 0x00 ; This is our binary zero (no condition flags)
skp always,end_of_skip ; Ask for skip without conditions
;
; code to be skipped
;
end_of_skip:
Posted: Sun May 10, 2009 10:31 am
by frank
Please post examples of the code where the 'skp run' fails. We've never seen this happen and would like to investigate.
Posted: Mon May 11, 2009 12:10 pm
by PK
I apologize for not taking a snapshot of things while they were failing. The assembler's trait of saving the current file in the editor for assembly makes it less easy to keep copies of older iterations. Until I can do better, here is the snippet where I experienced the failure twice. The first time I blamed myself, but upon having the same problem a couple days later I was able to use test values to determine which skips were taken. Flipping code back and forth (between skp run and skp 0x00) recreated the error each time the run flag was specified which I tested at least four times Unfortunately, I can't recreate the error at the moment with my code where it is now (128 words long) just by changing the '0x00's back to 'run'. The failure was noticed on the first of the two 'skp run's.
Code: Select all
rdax pot1,1 ;LFO speed
skp zro,lfo_stopped
skp run,lfo_run
lfo_stopped:
sof 0,.999
rdax pot0,-1.555 ;use pot0 for manual output
skp run,lfo_exit
lfo_run:
;now use the pot1 value in acc for LFO speed
;
lfo_exit:
wrax lfo_output,0
Posted: Mon May 11, 2009 3:13 pm
by frank
Hmm, cannot reproduce. Following is my test code, basically it uses POT0 to select either POT1 (POT0 < 0.5) or POT2 (POT0 > 0.5) as a volume control
Code: Select all
clr
rdax pot0,1
sof 1.0,-0.5
skp neg,lbl1
skp run,lbl2
lbl1:
clr
rdax pot1,1
wrax reg0,0
skp run,outter
lbl2:
clr
rdax pot2,1
wrax reg0,0
outter:
clr
rdax reg0,1
mulx adcl
wrax dacl,0
It is operating as expected on my dev board, please try on your board.
Posted: Mon May 11, 2009 8:22 pm
by PK
Your test code operates perfectly here.
I know something
was happening... thinking more about it, the Dev board was power cycled but the PC only gets restarted every few days so I'm wondering if something may have confused some XP assembler support DLL. I've also seen some odd behavior if my finger happens to be on the FV-1 crystal when applying power.
If I notice it again, I'll remember to take a snapshot of the machine code listing.
Posted: Mon May 11, 2009 9:27 pm
by frank
If it happens again, please email me the code directly. Does your board have a capacitor on X2 (pin 9)? Your mention of having the finger near the crystal causing a problem makes me wonder if the capacitor is missing. Some crystals don't start clean (may start in an harmonic) if the cap is missing.
Posted: Tue May 12, 2009 6:23 am
by PK
No cap on pin 9, there's some flux from the X2 connections touching the DVDD supply and GND, and I'm in a marine environment. That seems a much more likely cause than Elvis.
Thank you, Frank. I will mail you directly if I see the behavior again.