Ok, according to Gunther's SXSim (awesome!!), the "Delay Code Generator" at SXList is not accurate!!!!

At least with my tests. For example, on the breezeway (for NTSC), you need 0.6µS. Well, I am still running at 80 Mhz so that should be 48 clocks. Now, subtract two for the "mov rb, #5" command gives you 46 clocks. Well, even though I put 46 clocks into the code generator, it was doing 48!!! Just about every one of them over about 20 clocks had 2 extra!!!!

So, I have been running my code in the SXSim and setting breakpoints and literally watching/counting clocks to make sure all is accurate after I adjusted for the error.

Now, below is a sub-routine I am using that should setup the beginning of a scanline (10.9µS). I have ran this through SXSim and it says 872 clocks exactly!

So, could someone point out if this is wrong? If not, I assume I am correct. hehe
Thanks!

;===============================================================================================
;        LINESETUP
;
;        returns in exactly 872 clocks        10.9µS        @        80Mhz
;        The 872 clocks includes the call and the return (6 clocks)
;        Some of the call/return is taken from the back porch and one clock is taken from the
;        Sync Tip because it was returning with 873 clocks  :-/
;===============================================================================================
LineSetup
        ;-- Front Porch 1.5µS ---------------------------------------------------------------
        mov rb, #( 5 )                                ;(2)  BLACK
        mov        w, #$1D
        mov        d1, w
frontporch_0:
        decsz        d1
        jmp        frontporch_0
        nop
        nop
        
        ;-- Sync Tip 4.7µS ---------------------------------------------------------------
        mov rb, #( 0 )                                ;(2) Sync
        mov        w, #$5D
        mov        d1, w
synctip_0:
        decsz        d1
        jmp        synctip_0
        nop
;        nop                                        ;removed to make entire subroutine EXACTLY 10.9µS
        ;-- Breezeway 0.6µS ---------------------------------------------------------------
        mov        rb, #( 5 )                        ;(2) BLACK
        mov        w, #$0B
        mov        d1, w
breezeway_0:
        decsz        d1
        jmp        breezeway_0
        nop
        nop
        ;-- Color Burst 2.5µS ---------------------------------------------------------------
        mov        rb, #( 5 )                        ;(2) BLACK
        mov        w, #$31
        mov        d1, w
colorburst_0:
        decsz        d1
        jmp        colorburst_0
        jmp        $+1
        ;-- Back Porch 1.6µS ---------------------------------------------------------------
        mov        rb, #( 5 )                        ;(2) BLACK
        mov        w, #$1E
        mov        d1, w
backporch_0:
        decsz        d1
        jmp        backporch_0
        ret                                        ;(3 + 3 = 6)

When I need to count cycles in code. I put the code cycles on each instruction line.

cbmeeks,
I tried to make SXSim count clock cycles as accurate as possible. Nevertheless, another user made me aware of a problem concerning the increment of the RTCC in SXSim. This will be fixed in the next version. Nevertheless, I can't guarantee that there still are situations where SXSim does not exactly count the clock cycles. Seems as if I got some more work to do making SXSim simulate the SX-internal instruction pipeline exactly as it is.

[Quoting: "Guenther Daubach"]cbmeeks,
I tried to make SXSim count clock cycles as accurate as possible. Nevertheless, another user made me aware of a problem concerning the increment of the RTCC in SXSim. This will be fixed in the next version. Nevertheless, I can't guarantee that there still are situations where SXSim does not exactly count the clock cycles. Seems as if I got some more work to do making SXSim simulate the SX-internal instruction pipeline exactly as it is.

You did good work.  :-)
I guess one thing I need to do is create a 118 cycle routing on the delay code generator and actually cound all the clocks myself to see how close the SXSim is.

I'm just being picky but when it comes to NTSC and color, accuracy is king.

cbmeeks,
would be great if you could count the clocks by yourself and then compare it to SXSim's results. Should there be any difference, please let me know, and send the code you've been testing. Maybe this helps me to fix any remaining timing bugs in SXSim.

I assume you are using:

http://www.piclist.com/cgi-bin/delay.exe?Delay=46&Type=cycles&Regs=d1+d2+d3+d4&clock=80&name=Delay&CPU=SX

; Delay = 46 instruction cycles
; Clock frequency = 80 MHz
; Actual delay = 5.75e-007 seconds = 46 cycles
; Error = 0 %
d1 DS 1
;46 cycles
    mov w, #$0C
    mov d1, w
Delay_0:
    decsz d1
    jmp Delay_0
 

I believe you are correct, the delay generator doesn't take into account the final 2 cycles. I'll let the author know.

[Quoting: "James Newton"]I assume you are using:

http://www.piclist.com/cgi-bin/delay.exe?Delay=46&Type=cycles&Regs=d1+d2+d3+d4&clock=80&name=Delay&CPU=SX

; Delay = 46 instruction cycles
; Clock frequency = 80 MHz
; Actual delay = 5.75e-007 seconds = 46 cycles
; Error = 0 %
d1 DS 1
;46 cycles
    mov w, #$0C
    mov d1, w
Delay_0:
    decsz d1
    jmp Delay_0
 

The mov's take a cycle each. jmp takes 3 cycles in turbo mode. decsz takes 1 cycle if the condition is false and 2 if it is true. My old SX-Key manual actually says 3, but the current datasheet says 2 and that makes a lot more sense.

So, the mov's take 2 cycles. The first 11 times through the loop, decsz takes 1 and jmp takes 3 so 4 times 11 = 44 for a total of 46 so far. On the 12th cycle, the result is zero and decsz takes 2 cycles to skip out for a total of 48 cycles.

I believe you are correct, the delay generator doesn't take into account the final 2 cycles. I'll let the author know.

Oh, Günther, I haven't been able to count in the last couple of days due to a heavy work load but I should be back on it this week...and it looks like James has verified this too.

cbmeeks,
 You can use SX/B as a delay generator. And it's code is not affected by code pages.
 For example with freq as 80MHz a "PAUSEUS 0.575" generates the following code:

 MOV __PARAM4, #9   ; 2 cycles
 DJNZ __PARAM4,@$   ; 8*5 + 3 cycles
 NOP                          ; 1 cycle
 This takes exactly 46 cycles.
Bean.

Hey, I haven't thought about that!

Thanks, I will give it a try.

I wished the next version of SX-Key would have a tool for generating loops.  Something that would take your FREQ value and just ask you for how many clocks or seconds(µSeconds).  Then, plop the code down.

[Quoting: "cbmeeks"]
Hey, I haven't thought about that!

Thanks, I will give it a try.

I wished the next version of SX-Key would have a tool for generating loops. Something that would take your FREQ value and just ask you for how many clocks or seconds(µSeconds). Then, plop the code down.

For now, I use the online version and just copy/paste. No biggie but would be a neat tool.
cbmeeks

The delay code generator at sxlist.com has been fixed and now produces the correct delay code for the SX. For example:
http://www.piclist.com/cgi-bin/delay.exe?Delay=46&Type=cycles&Regs=d1+d2+d3+d4&clock=80&name=Delay&CPU=SX
produces:

; Delay = 46 instruction cycles
; Clock frequency = 80 MHz
; Actual delay = 5.75e-007 seconds = 46 cycles
; Error = 0 %
d1        DS        1
                        ;44 cycles
        mov        w, #$0B
        mov        d1, w
Delay_0:
        decsz        d1
        jmp        Delay_0
                        ;2 cycles
        nop
        nop
; Generated by http://www.piclist.com/cgi-bin/delay.exe>; Thu Dec 08 16:48:30 2005 GMT
; See also various delay routines at http://www.sxlist.com/techref/ubicom/lib/flow/delays_sx.htm  

Hey, glad I could have been of service.  I know a lot of people use that.