Research implementing 8-bit color w/ separate VSYNC/HSYNC pins

[cspang1]

Might be impossible due to already-tight vga_display routine timing, but worth the four-fold increase in color fidelity.

[konimaru]

Been there, done that, works :) And it's cheap when all is said and done. Sync signals with 0 idle state are easiest but I have drivers with opposite polarity and 8bit mode as well.

[cspang1]

@konimaru Yep someone mentioned your name on the forum when discussing it!

Without looking at your implementation, I'm wondering how you were able to toggle the HSync/VSync outputs deterministically. e.g. pulling down the HSync pin via andn outa, HSPin the instruction immediately after the following HSync region waitvid was executed would still introduce dozens of nanoseconds of lag. Is that simply within acceptable VGA tolerances?

[konimaru]

That's not quite how it works. While I do the visible stuff the sync lines are kept idle by outa. After the last pixel I register the hsync stuff normally with a waitvid (so timing is exact) and only then I switch byte lanes in vcfg to have the sync pulse on the correct pins. Just before the front porch runs out I switch lanes and outa takes over again.

[cspang1]

@konimaru ah I see, that makes perfect sense, thanks!

I can see how active-high sync signals would be trivial to implement with pull-down resistors, however my sync signals are active-low.

I suppose I'll have to do some creative waitvid timing to compensate for the necessary dira instruction, along with some pull-up resistors?

[cspang1]

|<------------ACTIVE VIDEO------------>|<----FRONT PORCH---->|<--HSYNC-->|<-BACK PORCH->|

So after starting to display the front porch, we have to change vcfg to control the sync pins instead, dira to set those pins as outputs, and vscl to display the correct HSync duration.

The problem though is syncing up the appropriate HSync duration with the moments dira changes at the start and end of the sync.

I could shorten the horizontal front porch waitvid to compensate for the 4 cycles (~40 ns @ 104 MHz) of lag induced by that dira change to output, then lengthen the horizontal back porch waitvid to compensate for the 4 cycles induced by the dira change back to output.

It happens that @ the VGA pixel clock frequency of 25.175 MHz, a single clock is ~40 ns, so I would simply need to add/subtract one clock per frame to the front/back porch vscls.

Some pseudo-code to work out a solution:

' Perform horizontal blank/sync
mov        vscl,   horfp     ' Set vscl for horizontal front porch
waitvid    horfp             ' Display horizontal front porch
mov        vcfg,   hvcfg     ' Set vcfg to drive H/V pins
mov        vscl,   hsync     ' Set vscl for horizontal sync
waitvid    hsync             ' Display horizontal sync
or         dira,   hvpins    ' Set H/V pins as outputs
mov        vcfg,   pixcfg    ' Set vcfg to drive color pins
mov        vscl,   horbp     ' Set vscl for horizontal back porch
waitvid    horbp             ' Display horizontal back porch
andn       dira,   hvpins    ' Set H/V pins as inputs (floating/high-impedance)

[konimaru]

First, apologies, I got front/back porch mixed up (I was under the impression it's in front of the video signal when in fact it's in relation to the sync pulse).

Anyway, no messing around with dira here.

• dira covers 8bit video and 2bit sync from the start and is never touched again
• outa is set (initially) to idle state (high) in the sync pin location
• video line is displayed
• hsync waitvid is issued (front+sync+back)
• immediately after that vcfg is updated (pin group) then outa is cleared (no interference)
• now we have to calculate a point in time when the back porch becomes active (sync lines high again)
• at this point outa goes back to idle (take over) followed by a vcfg pin group switch for the next scan line

The intervals between switching should be kept short though (there is minor bleeding into the colour pins due to sync idle state being high).

[konimaru]

FWIW, the bleeding can be avoided with an exotic sync pattern, i.e. keep low until switchover (vcfg) then high before release (outa) and reverse that before going back to visible video.

[cspang1]

@konimaru No problem! If you google "vga porch timing" you'll see it BOTH ways all over the place; makes have a technical discussion about it without a reference much more difficult.

I was under the impression that vcfg, like vscl, is latched at the moment of the next waitvid execution.

[konimaru]

In my experience vcfg takes immediate effect :) There was a QuickStart extension board for PropellerBASIC which had a 256colour option. It wouldn't have worked since I use a single waitvid for hsync.

[cspang1]

@konimaru Interesting, thanks! Really wish that kind of info was in the Prop datasheet!

I took a crack at an "exotic" sync pattern w/o color bleeding. See anything obviously wrong?

[konimaru]

Sorry for the delay. I'm missing the switch back (sync-to-visible) here. I was thinking (roughly):

• display active video
• waitvid sync_0 (begin of front porch, starts low ends high)
• swap vcfg (during sync_0 low part)
• waitvid sync_1 (remainder of front porch, sync, start of back porch, high-low-high)
• outa = 0 (during first sync_1 high part)
• waitvid sync_2 (middle of back porch. starts high ends low)
• outa = idle (during sync_2 high part)
• waitvid sync_3 (remainder of back porch, all low)
• swap vcfg
• display active video

This probably is overkill (in general) since the bleeding is for all intents and purposes not shown (visible line is finished). I also came up with a single waitvid solution with carefully timed switchover points in between. But doing it step by step is probably the most maintainable solution.

FWIW, my 320x240 scanline driver suffers from bleeding but that hasn't been an issue until now.

[cspang1]

@konimaru No problem, being on opposite sides of the world has its inconveniences haha. Good call on the back porch as well; thinking about it this morning and I felt I was missing something.

For this project, transparency and maintainability of operation are definitely high priority, as a goal is for anyone to be able to come behind and modify the drivers if a game calls for it.

[cspang1]

@konimaru This is the final algorithm I'm going with; the original augmented with your modification:

It provides 100% determinism on H/V sync transitions at the standard-defined intervals without having to calculate wonky waitcnts. Thanks for the help!