Separate Hsync & Vsync vs Csync, Video DAC 18

[mark_k]

I was examining the Video DAC 18 software to see how it works. Video DAC 18 is similar to DCTV and HAM-E; it connects to the RGB port and uses the digital RGBI lines to produce a high-colour image.

DCTV and HAM-E look for a signature/magic cookie at the top of the image. The special video mode is only activated when the magic cookie is found.

Video DAC 18 is different however, and a little strange. It doesn't seem to use any magic cookie. Instead, the DAC_ON command by default does this to enable the special mode:

• write $0046 to HSSTRT
• write $00E6 to HSSTOP
• write $000A to VSSTRT
• write $0136 to VSSTOP
• write $0320 to BEAMCON0

To disable it writes $0020 to BEAMCON0 (the PAL default).

The region of the screen which is to be decoded is determined by the values written to HSSTRT/HSSTOP/VSSTRT/VSSTOP. The readme file mentions that with some sets of values the four corners of the screen can be set to decode. Presumably that happens when HSSTRT > HSSTOP etc.

What happens on a real Amiga (with no extra hardware) if those register values are written? Is the composite sync signal independent from the H & V sync signals?

Italian-language readme file attached if anyone wants to paste that into Google Translate.

[Toni Wilen]

I haven't tested how it exactly works but BEAMCON0 has enable bit for variable composite sync, variable horizontal sync and variable vertical sync and Agnus also has separate pin for csync output.

(But what was the design reason for separate Agnus variable csync bit? I can't see the point.)

It looks like device is active when both hsync and vsync is active at the same time. (Normally can only happen inside h/v blanking periods)

EDIT: Where does the palette come from? I loaded Video DAC 18 example images and there is no obvious "palette data" visible.

[mark_k]

$0320 written to BEAMCON0 is VARVSYEN|VARHSYEN|PAL.

Reading this AGA document which was probably typed up from C= docs...

VARVSYEN= Comparator VSY -> VSY pin. The variable VSY is set vertically on
          VSSTRT, reset vertically on VSSTOP, with the horizontal position
          set on HSSTRT and reset on HSSTOP during short fields
          (all fields are short if LACE = 0) and reset on HCENTER during
          long fields (every other field if LACE = 1).

VARHSYEN= Comparator HSY -> HSY pin. Set on HSSTRT value, reset on HSSTOP value.

So it seems the /HSY and /VSY signals from Agnus can be set more or less arbitrarily, and at least with $0320 written to BEAMCON0, are independent of /CSY which is still an actual sync signal. Maybe the Video DAC 18 hardware has a sync splitter inside to provide real H and V sync signals on its output connector. [I guess the VARCSYEN bit would need to be set in order for /CSY to reflect the H/VSSTRT/STOP register values?]

[mark_k]

Originally Posted by Toni Wilen

(But what was the design reason for separate Agnus variable csync bit? I can't see the point.)

That AGA doc alludes to "UHRES" mode and the possibility of driving dual displays. I wonder what other hardware changes would be needed to support that.

[Toni Wilen]

Originally Posted by mark_k

That AGA doc alludes to "UHRES" mode and the possibility of driving dual displays. I wonder what other hardware changes would be needed to support that.

I am not that sure if those are even implemented.

Did you miss my edit? Where does Video DAC 18 palette come from? (Assuming this device is more or less off-the-shelf VGA DAC chip + some support circuitry)

[mark_k]

This is based on examining several test images I converted to DAC18 format so may not be entirely correct. In particular I'm not certain of the bit order of the value/level.

The image encoding seems to be pretty simple. It's mostly like HAM but probably without any fixed palette registers.

Group each pair of pixels' RGBI bits to give a byte % r1 g1 b1 i1 r2 g2 b2 i2

Value is a six-bit number: % b2 i2 r1 g1 b1 i1
Modifier is % r2 g2

Modifiers:
00 = luminance/brightness? Not sure, need to check VIDEO_DAC_18 code
01 = blue
10 = red
11 = green

[nogginthenog]

Originally Posted by mark_k

the possibility of driving dual displays.

Interesting! Any more info on this?

[Toni Wilen]

Originally Posted by mark_k

write $0046 to HSSTRT
write $00E6 to HSSTOP

Values started to look suspicious when I was implementing emulation. Left side of display was not converted to Video DAC 18 format. (HSSTRT is too large and HSSTOP is out of range! Correct HSSTRT would be something like $36)

I did real hardware test (connected hsync to scope) and noticed that hsync signal stops changing state if above values are set. Only if HSSTOP is smaller than $e3 it will toggle normally.

I guess developers never noticed because only side-effect is stopped CIA-B TOD counter (it counts hsync pulses and afaik only uses for graphics.library synced blits), even video out keeps working because composite sync signal timing does not change.