Requesting info on video slot clocks

[hooverphonique]

Is there any (C= official?) timing diagrams available for the video clock signals (CDAC, C1, C3, C4, C28O) showing the relationship of these to the digital RGB outputs of Denise/Lisa?


For instance, the RGBtoHDMI project has a jumper for selecting denise/super-denise, suggesting that they don't update the RGB outputs at the same time relative to e.g. CDAC.

[jasonsbeer]

I have some of the same questions as I ponder the Pi to HDMI circuit, too. At the moment, I don't understand the difference between Denise and Super Denise. Why can't they use the same clock signal? On c0pperdragon's board, he uses _CDAC for Denise and 7MHz for super denise. I have been looking around this site.

http://amigadev.elowar.com/read/ADCD.../node02B0.html

The expansion bus provides clock signals for expansion boards. The main
use for these clocks on Zorro III cards is bus arbitration clocking. There
is no relationship between any of these clocks and normal Zorro III bus
activity. The relationship between these clocks is illustrated in
Figure K-3 .

/C1 Clock
This is a 3.58 MHz clock (3.55 MHz on PAL systems) that's synched to
the falling edge of the 7M system clock.

/C3 Clock
This is a 3.58 MHz clock (3.55 MHz on PAL systems) that's synched to
the rising edge of the 7M system clock.

CDAC Clock
This is a 7.16 MHz system clock (7.09 MHz on PAL systems) which
trails the 7M clock by 90 degrees (approximately 35ns).

E Clock
This is the 68000 generated "E" clock, used for 6800 family
peripherals driven by "E" and 6502 peripherals driven by phi(2). This
clock is four 7M clocks high, six clocks low, as per the 68000 spec.

7M Clock
This is the 7.16 MHz system clock (7.09 MHz on PAL systems). This
clock drives the bus master registration mechanism for Zorro III bus
masters.

[hooverphonique]

Hmm... I found this earlier, which seems to be straight from the horses mouth, but something's weird about the description of CDAC:

CDAC Clock€

This is a 7.16 MHz clock (7.09 MHz on PAL systems) that leads the 7M system clock by about 70ns (90 degrees). Pin 15.

Here it leads 7M by 90? degrees instead of trails, but 70ns is 180 degrees for a 7M clock (since CDAC is described as a quadrature clock in several places, 90 degrees is probably correct).

Unfortunately, it also says this, so chances of getting such info are probably slim:

The timing of the digital video is not tightly specified. Developers wishing to use this digital data should contact Commodore-Amiga for additional details on this.

[jbilander]

You can check the C= Agnus specification available on the EAB file server, check this thread below:
http://eab.abime.net/showthread.php?p=1249826

Here is what the Agnus spec says about how the inverted CDAC is created:

CDAC* This clock is obtained after inverting the 7MHz clock and shifting it by 90 degrees.

Oh, and the OCS Denise doesn't have CDAC connected, that pin is N/C, but it should be available on the socket pin 34 anyhow (not on rev3 mobo) I think, and also the CSync-signal isn't available on pin 32 on older A500 rev3 boards.
http://amigadev.elowar.com/read/ADCD.../node023C.html

Hope it helps!

[hooverphonique]

Originally Posted by jbilander

You can check the C= Agnus specification available on the EAB file server, check this thread below:
http://eab.abime.net/showthread.php?p=1249826

Here is what the Agnus spec says about how the inverted CDAC is created:

CDAC* This clock is obtained after inverting the 7MHz clock and shifting it by 90 degrees.

Oh, and the OCS Denise doesn't have CDAC connected, that pin is N/C, but it should be available on the socket pin 34 anyhow (not on rev3 mobo) I think, and also the CSync-signal isn't available on pin 32 on older A500 rev3 boards.
http://amigadev.elowar.com/read/ADCD.../node023C.html

Hope it helps!

Thanks.

I already stumpled on that other thread, but can't find those documents on the file server.. There's no 'Commodore_Amiga' root directory.


"Shifting it by 90 degrees" - yes, but in which direction?


RGBtoHDMI won't work on rev 3 then, because it uses CSYNC, and CDAC for OCS denise.

[robinsonb5]

Originally Posted by hooverphonique

"Shifting it by 90 degrees" - yes, but in which direction?

I have no inside info here, but I'd assume it's shifted by delaying it; in combination with the inversion that would be a 270 degree shift, so it would then lead the 7MHz clock, consistent with the previous description.


If that wasn't the intention, surely they've have shifted the raw 7MHz clock instead of inverting it first?

[jbilander]

Try here:
ftp://ftp:any@grandis.nu/~Uploads/Ba...ual-ENG%20.zip

Looks like kipper2k is already on top of that rev3 issue
https://github.com/c0pperdragon/Amig...ideo/issues/28

[hooverphonique]

Originally Posted by robinsonb5

I have no inside info here, but I'd assume it's shifted by delaying it; in combination with the inversion that would be a 270 degree shift, so it would then lead the 7MHz clock, consistent with the previous description.


If that wasn't the intention, surely they've have shifted the raw 7MHz clock instead of inverting it first?

Most likely, yes. and the non-inverted CDAC is the one available at the videoslot, so that would make it trail 7M.

[hooverphonique]

Originally Posted by jbilander

Try here:
ftp://ftp:any@grandis.nu/~Uploads/Ba...ual-ENG%20.zip

Looks like kipper2k is already on top of that rev3 issue
https://github.com/c0pperdragon/Amig...ideo/issues/28

Thanks.. Yes, quite a long thread there...

[hooverphonique]

So I received my prototype pcb's for my attempt at a videoslot version of the RGBtoHDMI project today.
Instead of immediately populating a pcb, I dug out my oscilloscope and added some patch wires to a pcb, to measure the clock timing.

So if anybody's interested, here are some screenshots with that pcb in an A4000 video slot:

/C1 vs /C3 (+ math XOR)


/C1 vs CDAC


The relationship between /C1, /C3, and CDAC appears to be as documented elsewhere.

R6 (red gun bit 6) vs CDAC

Pixel transitions seem to occur 45 degrees after a CDAC transition.

R6 (red gun bit 6) vs C28O (Lisa pixel clock)

C28O looks really bad (reflections?), I wonder if it needs to be terminated into some characteristic impedance.. Anyway, it looks like this clock can be used to directly latch pixels at the rising edge - since I want compatibility with non-AGA machines also, it's not something I can use in general, though.

I wonder if the timing of pixels (Lisa) in relation to these clocks is the same as Denise, Super-Denise, or none of them?

[jasonsbeer]

I was able to get a working video slot -> Pi HDMI card working for OCS/ECS machines. It would be great to have something for the 4000 as well. You can check the schematics at https://github.com/jasonsbeer/Amiga-HDMI-Through-Hole. I'm happy to talk about any of my findings if that is of interest to you. The part I struggled with a little was recreating the 7MHz clock signal for super denise. I tried a couple iterations and both worked. Version 1.1 of my board is the more simple design.

Here's the /C1 (yellow) and /C3 (blue) signals from my A2000.

[hooverphonique]

Yes, I noticed you posted an image of your board in another thread some days ago - Nice! I will star your repository and have a closer look later this weekend, but it seems you're generating 7M by xor'ing /C1 and /C3 (which should work), and alternatively use CDAC directly (just like the original c0pperdragon design) for ocs denise.

Can you confirm that the Pi is set up to use both edges on PiClk as pixel clock? I had a look at the firmware, but haven't dug deep enough (yet) to understand all of how it samples the GPIO's.

And thanks for sharing :-)

[jasonsbeer]

Originally Posted by hooverphonique

Can you confirm that the Pi is set up to use both edges on PiClk as pixel clock? I had a look at the firmware, but haven't dug deep enough (yet) to understand all of how it samples the GPIO's.

I have not dug into the firmware, so your question got me interested. I pulled the source code and I looked at this file... /RGBtoHDMI-20210131_20ce5f0/vhdl_RGB_12bit/RGBtoHDMI.vhdl. There may be other relevant files. There is a lot of stuff packed into the source zip.

I can only find references to the rising edge in this file.

-- Shift the bits in LSB first
    process(sp_clk)
    begin
        if rising_edge(sp_clk) then
            if sp_clken = '1' then
                sp_reg <= sp_data & sp_reg(sp_reg'left downto sp_reg'right + 1);
            end if;
        end if;
    end process;

    process(clk)
    begin
        if rising_edge(clk) then
        ...

That section of code continues on and appears to read/drive the RGB registers. I would have to spend a bit more time to fully understand how it works. There must be other relevant parts in other files.

Originally Posted by hooverphonique

And thanks for sharing :-)

My pleasure! I am interested in learning more about Amiga hardware and want to contribute to the community in a useful way.

On a side note, the firmware would need to be modified to support 24 bit color as is used in the AGA chipset. Should be possible assuming there are enough I/O lines left on the GPIO.

[jasonsbeer]

Probably should ignore my comments above....I think that is code for a CPLD hat to handle 12 bit RGB on certain systems. That hat is not needed on the Amiga. Anyhow, I'm digging!

[Pyromania]

@jasonsbeer

That was really faaaaast. Cool you got this working on some Amigas.

[hooverphonique]

If I'm not completely crazy, the clock for the flipflops is twice (14MHz) the frequency of the clock going to the Pi (PiClk), hence my assumption that it samples on both edges (to support hires).

Yes, the thing about the cpld boards is a little confusing since the c0pperdragon project doesn't use one, and RGB2HDMI never mentions using it without one (but I suppose the flipflops + xor's is a kind of cpld ;-) ).