• Rise from your gwave!

Is it not possible to plot a pixel, or a range of pixels using SCU timers?

Discussion in 'Saturn Dev' started by mrkotfw, Aug 16, 2018.

  1. mrkotfw

    mrkotfw Member

    If I use the back screen as a way to plot a pixel.

    In a H-BLANK interrupt, I set SCU timer 1 to a value of 159 and set the back screen to a particular color (black).

    Then when the timer 1 interrupt is fired, I change the color value of the back screen. Then I disable the timer 1 interrupt.

    I expect to see pixel plot. However, I'm seeing a lot of flickering (in hardware).

    _line is incremented by pad left/right.

    static void __unused
    _vblank_out_handler(irq_mux_handle_t *irq_mux __unused)
            scu_timer_line_enable(); /* Specific scanline */
    static void __unused
            if (!_set) {
            _set = false;
            /* Write to VRAM */
            _back_screen[111] = COLOR_RGB555(31, 31, 31).raw;
    static void __unused
            _set = true;
    static void __unused
            _back_screen[111] = COLOR_RGB555(31,  0, 0).raw;
    Last edited: Aug 16, 2018
  2. mrkotfw

    mrkotfw Member

    Is there any VDP2 feature that would allow me to modify in a single dot? via SCU timer 1 and H-BLANK interrupts?

    I know Charles has a SCU timer test that changes the resolution mid scanline.
  3. XL2

    XL2 Member

    I don't know about that, but what are you trying to achieve?
    Would it work with a normal line color table?
    Last edited: Aug 18, 2018
  4. mrkotfw

    mrkotfw Member

    I'm mostly trying to get an understanding for what the SCU timers could be used for, as well as testing. The fact that timer 1 fires at 7MHz intervals, and the documentation state that the interrupt can be fired per dot, I figured there's something that I could test out.

    I tried the line color table, and it's the same effect. It always flickers. For the back screen, I can easily set an entire scanline to a particular color via H-BLANK, but from H-BLANK, and counting say 159 dots (159 * (1/7MHz)) doesn't show any change.

    I've tried setting the registers within the interrupt. That is, force writing the BKTA* registers, and that didn't work.

    I also tried setting the BKTA* registers to a different value from the rest of the screen, and that didn't work either.
  5. antime

    antime Extra Hard Mid Boss

    You need to take both latency and jitter into account. Charles MacDonald's demo mentioned above replaces the firmware built-in SCU interrupt handlers with his own, and nests the interrupts to produce a stable interrupt.

    I would look into using SCU DMA, triggered by the SCU timers. By working out the transfer/pixel ratio, you might be able to plot a single pixel (ie. write as many "black" values needed to get to the next pixel, then write the "white" value and stop).

    Having both T0 and HBLANK interrupts seem redundant, as T0 triggers on HBLANK-IN. Note that you can configure T1 to trigger only on the line T0 triggers on, allowing you to move initialization of the T1 timer out of the per-line interrupt handlers.

    EDIT: Since the back and line screen data is stored in RAM, it is probably read just once per scanline.
    Last edited: Aug 18, 2018
  6. mrkotfw

    mrkotfw Member

    That's a good point. There is about 3 layers of indirection when it comes to actually getting to my handler. I'll write my own handler for SCU timer 1.

    As for interrupting on H-BLANK, I misunderstood the documentation then. I had taken that SCU timer 1 can only be set within an H-BLANK interrupt. I'll remove the redundant call.

    I'll try these suggestions out. I do need to read up on what setting the SCU DMA starting factor to SCU timer 1 entails. My guess is that I start the DMA transfer with T1 as the starting factor, then in the T0 interrupt, set the T1 value. In the T1 interrupt, keep resetting T1 value so the DMA transfer could occur at every point.
  7. mrkotfw

    mrkotfw Member

    I just saw your update. That makes more sense. What I thought to be a simple test turned out to not necessarily be possible. At least from the results of my testing.

    I moved on to something where I know I can change per dot: 16-color bit-mapped normal background. I set the entire bitmap character pattern to 0x11, and I'm changing the #1 entry in CRAM via T0/T1.

    So far, I'm making sure that by triggering T0 at a specific scan-line (say 111), that I set the second half of the bitmap a different color from the top half (top is green, bottom is red). I rewrote the T0/T1 handlers in assembler and I get a few dots of flickering at the start of the bottom half (about 5 pixels).

    I'm a little confused as to why since T0 IRQ is fired at the start of HBLANK-IN.

    I haven't tried SCU DMA yet.

Share This Page