HSYNC and VSYNC generation

[PR77]

Does anyone know how specifically the AGNUS on OCS/ECS machines generates the H+V SYNC? And how this is timed with the DENISE pixel clock (CCK and CCKQ)? Looking into internal scan doublers which sit on DENISE the H+V SYNC need to be generated as they are are not pinned.

I would like to explore the two things here. A basic scan doubler (perhaps using the AL250) and a TTL LCD Interface which essentially would display the RGB data in a pixel perfect field. I have experience with the second on the RPi using the DPI interface (https://www.raspberrypi.org/forums/v...rt=150#p691260). Nevertheless, both need H+V SYNC and I would like to not have jumpers.

Thought I would ask before looking into the minimig verilog and UAE sources.

[Toni Wilen]

Denise sees horizontal line start and vertical start signals via RGA bus. Agnus generates strobe register (STRxxx) accesses when it starts new scanline/frame. Denise resets its internal horizontal counter when it gets horizontal strobe. Vertical strobe is mainly for Paula, it is used to generate vblank interrupt.

"True" hsync and vsync (that have correct video timing) are only available from Agnus pins.

(Perhaps this answered your question. If I understood it correctly )

[Niklas]

This isn't quite an answer to your question, but perhaps you can extract hsync and vsync from csync (composite sync) which is available on pin 32 on Denise?

[Niklas]

Originally Posted by PR77

And how this is timed with the DENISE pixel clock (CCK and CCKQ)?

CCK is the chroma clock which is 3.58 MHz. The (hires) pixel clock is four times that (14.3 MHz).

The following page has a lot of good information: https://retrocomputing.stackexchange...ga-clock-speed

[Toni Wilen]

(Another possible answer): EAB file server /Commodore_Amiga/Doc/App_Hardware/Specifications_AGNUS_NTSC.zip (and _PAL.zip) includes timing diagrams of Agnus hsync/vsync/csync signals.

[PR77]

Thanks for the feedback. Great hints. Hopefully I get a chance (while I wait for my new 68K accelerator PCBs to get produced) to hook up one of my TTL TFTs and see how that goes. I will take the SYNCs from AGNUS first and then see if I can come up with some Verilog to read the RGA accesses. I remembered that the LCDs I have (LQ042T5) only have a resolution 480x272, but would still be cool to see the Amiga Bootscreen on the LCD! :P

[PR77]

Originally Posted by Toni Wilen

(Another possible answer): EAB file server /Commodore_Amiga/Doc/App_Hardware/Specifications_AGNUS_NTSC.zip (and _PAL.zip) includes timing diagrams of Agnus hsync/vsync/csync signals.

Silly question, where is the EAB file server?

[Toni Wilen]

http://eab.abime.net/showthread.php?t=43633

[PR77]

Started prototyping a level shifter (LCD is 3.3 volts) and support frame for one of my LCDs. Looked at the video data with my Saleae and think the signals look OK enough to at least see something on the LCD.

Question to the community, for a LoRes screen I would expect a 4 MHz pixel clock for a standard PAL 320x246 but I was seeing about 3.6 MHz. Any idea why the CCK is different? This confused me a bit and pushed me to prototype the display so actually see what is coming out; visually.

[Niklas]

Originally Posted by PR77

Question to the community, for a LoRes screen I would expect a 4 MHz pixel clock for a standard PAL 320x246 but I was seeing about 3.6 MHz. Any idea why the CCK is different?

CCK is not the pixel clock -- CCK is the chroma clock (or color clock), which is 3.58 MHz on an NTSC Amiga, and slightly lower on a PAL Amiga.

The lores pixel clock is twice the CCK, that is 7.16 MHz on an NTSC Amiga.

Have a look at the "Specifications_AGNUS_NTSC_png0039.png" image that is in the "Specifications_AGNUS_NTSC.zip" archive that Toni linked to above for a very good timing diagram. The time per pixel written in that image (69.841278 ns/pixel = 14.3 MHz) is for a hires pixel.

[PR77]

LCD wired up (only the highest RBG bit connected) and well … there is something on the screen. You can """just""" make out the Kickstart V1.2 screen in the very top of the display.


It is a VERY rough proof of concept, which, does work but it needs a lot of work! Clearly I need a CPLD to do some magic with the front and back porch alignment (on the RPi this is just a configuration so it is super easy to match to a particular LCD).

I still can't figure out the pixel clock though. I was having a look at the AGNUS datasheet timing diagram and I still can't quite figure out the pixel clock. DENISE gets 7MHz and CDAC. So when in LoRes (320x256 PAL) pixel clock = 7MHz and in HiRes (640x256) pixel clock = 7MHz^CDAC (14MHz)? If this is the case, what doesn't make sense to me is 7MHz @ 15.625Khz HSYNC is equivalent to 448 scan lines. To add to the confusion, Pg 39 of the AGNUS timing indicates 908 pixels per line. Where are these pixels?

[Niklas]

Nice to see that you are making progress

Originally Posted by PR77

I still can't figure out the pixel clock though. I was having a look at the AGNUS datasheet timing diagram and I still can't quite figure out the pixel clock. DENISE gets 7MHz and CDAC. So when in LoRes (320x256 PAL) pixel clock = 7MHz and in HiRes (640x256) pixel clock = 7MHz^CDAC (14MHz)? If this is the case, what doesn't make sense to me is 7MHz @ 15.625Khz HSYNC is equivalent to 448 scan lines. To add to the confusion, Pg 39 of the AGNUS timing indicates 908 pixels per line. Where are these pixels?

To understand the Amiga video signal you should understand that it is made according to the NTSC video standard.

You have a PAL Amiga, but as the image Specifications_AGNUS_NTSC_png0039.png refers to an NTSC Amiga I will stick to the NTSC standard in the following. The PAL and NTSC standards are very similar, and differs mainly in the number of lines per field.

[1] Specifications_AGNUS_NTSC_png0039.png
[2] http://www.kolumbus.fi/pami1/video/pal_ntsc.html

You should compare the third image on [2] (Field Synchronization of NTSC System) with [1] to see that they are the same. When reading the rest, perhaps try to recognize the numbers in the lower left corner of [1].

NTSC transmits 30 "frames" per second, and each frame consists of two "fields", so there are 60 fields sent per second. Each frame consists of 525 lines, so each field is 262.5 lines. To avoid half lines the Amiga has a short (262) and a long (263) field. Not all of those lines are visible; the first 21 lines per field are vertical blanking, which includes the vertical front porch, vertical sync, and vertical back porch.

Each line consists of 227.5 CCK cycles. Where that number comes from is described on this page: https://en.wikipedia.org/wiki/Colorburst.

For the Amiga, lines alternate between being a short and a long line. A short line is 227 CCK cycles, and a long lines is 228 CCK cycles. The Amiga is designed to make one word access to chip memory per color clock cycle. In low resolution it takes 8 CCK cycles to read all bitplane data to display 16 pixels, so two pixels are shown per CCK. In high resolution it takes 4 CCK cycles to read all bitplane data to display 16 pixels, so there are four pixels per CCK. See http://amigadev.elowar.com/read/ADCD.../node02D4.html.

Therefore, in high resolution there are 227.5*4 pixels = 910 pixels per line, and in low resolution there are 227.5*2 pixels = 455 pixels per line. Not all those pixels are visible; some are the front porch, the horizontal synch, and the back porch. You can compare [1], the first image on [2] (Line Synchronizing Signal), https://en.wikipedia.org/wiki/PAL#PAL_signal_details, and https://en.wikipedia.org/wiki/PAL#/m...AL_2_lines.png (two PAL lines).

Note that the Amiga can use overscan, and according to the Amiga Hardware Reference Manual (AHRM) the Amiga can display up to 368x283 low res pixels per field (in PAL), so in general you can't safely assume that the display is exactly 320x256.

[ross]

Exhaustive raw numbers for PAL territories.

Base clock (CCK) is 3546895Hz and ALL in PAL Amiga is derived from this.
Pixel clock is a multiple: lowres pixels freq. is 7093790, hires 14187580, shires 28375160.
So to be compatible with later chipset you need to sample at this exact 28Mhz frequency.

There is ever 227CCK per line so is not exactly 64us (PAL specs) but 63,999639us (from this the 908(=227*4) pixels/line).
To get standard interlaced 625 lines, 25 frames per second, you have two ~50Hz fields; one long (313 lines) and one short (312 lines).
So you cannot have an exact 50Hz screen, but 49,9204 or 50,0804 (an interlaced screen anyway is a very precise 25,0001HZ display).

In non-interlaced mode Long Frame (LOF) or Short Frame are freely selectable,
but normally a LOF frame is used by system and practically every game (is the natural chipset choice).

Lines are counted from 0 to 312 (or 311) comprised, vertical blank is from 0 to 25 comprised.
Visible display is from 26 to 312 (287 lines) but last line do not fetch data,
so only background is visible (from what I remember is only usable on some early A1000..).

Visual picture information (so excluding front porch, HS, back porch, color burst, normally 52us in PAL specification)
is also in this case a CCK multiple: 188CCK (53,0041us).
This give a grand total of 376 lowres pixels (752 or 1504, hires or shires respectively).
Logically not every display device can visualize these, but you can take 368 pixels as usable.

That's all folks!


NOTE.
Chipset digression, to put an end (maybe..) to the various debates on the max overscan:
from former value Amiga OCS can emit 376*286 visible lores pixels.
Raw values for chipset: DDFSTRT=$20, DDFSTOP=$d8, DIWSTRT=$1a5c, DIWSTOP=$38d4(*), BPLCON1=$bb
Better values could be: DDFSTRT=$28, DDFSTOP=$d8, DIWSTRT=$1a61, DIWSTOP=$38d1(*), BPLCON1=$0
because you have 368p and one less DMA fetch without losing practically nothing.
(*) this is theorical, with >=$xxc8 you open the h. border..

[pandy71]

few words from me too.
To simplify your design (and make it more robust i.e. higher chance to success) you can generate own pixel clock (you can use programmable generator such Si5351 - it is quite popular [arduino] and as such cheap - also you remove issue trying to find proper crystal/generator for Amiga, as side benefit you can overclock whole Amiga system - not only CPU but also Agnus, Denise and Paula) and feed this pixel clock to Amiga (^XCLKEN and XCLK) - this will remove any issues with pixel clock acquisition, secondly use superhires pixel clock to perform all sampling - as such Low res pixel will be oversampled 4 times, hi res 2 times and shires 1 to 1 - no fuzz with detecting video mode. If you use HSync and VSync then your timing is simplified albeit non CVBS video compliant (lack of for example serration/equalization pulses present in Composite Sync). this is not problem if your intention is to feed computer display only (which i believe is your goal).

[ross]

Originally Posted by pandy71

..you can generate own pixel clock..
..as side benefit you can overclock whole Amiga system..

another side effect is that you can write long tracks on floppy
(but you are very risky for general instability and loss of sync in various device..)

[pandy71]

Originally Posted by ross

another side effect is that you can write long tracks on floppy
(but you are very risky for general instability and loss of sync in various device..)

Of course - every timing in system will be different - audio, UART, FDD - not sure how much original chipset can be overclocked - in past i think i was successful to replace original generator with 32MHz one so CPU clock was 8MHz but my TV begin to complain on video timing (horizontal sync too fast - over 17kHz) - this was huge stress for old CRT's technology, nowadays with LCD's this is not a problem - so perhaps limit is laid somewhere around 34 - 38MHz?
Such dynamic re-clocking was used by Macintosh emulator - as outcome Amiga was able to read (write?) Mac floppies natively.

[PR77]

Wow! Thanks for all the info, but it seems shared memory PAL video systems and RPi Frame Buffers (via DPI) are two COMPLETELY different beasts!

I think I am starting to understand the pixel clock and in its most simplest form I could derive this from CPU_CLK for LoRes and CPU_CLK ^ CDAC for HiRes. Both are available to DENSIE (which would work for a small PCB between DENISE and the Amiga MB).

The fields and frames have me somewhat confused now also. As the LCD is essentially a frame buffer displaying two different fields one a single LCD frame would then mean I need to buffer at least one field. This is too complex for me at the moment- first want to finish my 68SEC000 accelerator and publish that design- but I guess once I have the pixel data sampled correctly this can pushed into an SRAM (or better dual port RAM which I have a lot of).

I would be very happy to see the basic Kickstart screen on the LCD not completely pixel perfect but better than my first attempt. It is clear now that I can't simply connect the LCD as I have done without some logic in-between.

Does DENISE get via the RGA Bus the entire video frame? In a realtime DMA cycle sync'ed with HSYNC?

Has anyone tried to do something like this? I'm sure this is the basis of the internal scan doublers (indivision, DCE ScanMagic, etc) which add de-interlacing and additional frame modes.

[pandy71]

Originally Posted by PR77

Does DENISE get via the RGA Bus the entire video frame? In a realtime DMA cycle sync'ed with HSYNC?

RGA is internal (chipset) address bus, data are transferred over shared data bus (shared with CPU). Denise is triggered by Agnus (usually) - some access to RGA works as strobe (so Denise internal address comparator detect particular address on RGA and this trig particular action - data on bus are ingored)

Originally Posted by PR77

Has anyone tried to do something like this? I'm sure this is the basis of the internal scan doublers (indivision, DCE ScanMagic, etc) which add de-interlacing and additional frame modes.

There are two different devices - scan doublers and flicker fixers - flicker fixer are able to store complete frame of video and are able to provide asynchronous video rate at the output, scan doublers works synchronously with source (they are unable to provide asynchronous framerate).
Indivision is slightly different - this is HW Denise emulator - so you can say they grabbing data from data bus and data are interpreted internally as in Denise but also some modification to this interpretation is done as such Indivision offers new video modes and new functionality - this is like extension to chipset - Indivision use own registers accessible trough RGA (so Copper can reprogram Indivision same as other chips).

AFAIK other scandoublers (more popular as they require less memory - 1 field and 1 line of video but lower latency) or flicker fixers (1 frame buffer and increased latency when compared to scandoubler) are classic devices more or less copying Amber chip approach (most of them use Amber) - similar concept as http://www.elm-chan.org/works/sc/report.html
Dual port RAM is not required - if your memory can be accessible sufficiently fast then it can be even ordinary DRAM - bandwidth is quite moderate.
Also by using dedicated DRAM modes (easy as video access is linear sequence or burst). This is makes possibility SDRAM use even more optimal than SRAM or DPRAM (SDRAM has internal counter to accelerate burst that can be performed automatically) rest is up to the width of bus.

[PR77]

Originally Posted by pandy71

RGA is internal (chipset) address bus, data are transferred over shared data bus (shared with CPU). Denise is triggered by Agnus (usually) - some access to RGA works as strobe (so Denise internal address comparator detect particular address on RGA and this trig particular action - data on bus are ingored)

Your right, RGA is the chipset address but. I should have made that more clear in my message. DRD is the chipset data bus decoupled from the CPU during chipset only cycles.

I assume DENISE has no internal frame buffer, so then when DENISE detects an address combination of the RGA does it then latch in the DRD data from ChipRAM and AGNUS in a DMA cycle for a field (this is how I should of ask my question- too excited with all the feedback )? This would be the bitplan data I assume? Does DENISE hold the colour platte for the bitplans or is this AGNUS?

[pandy71]

Originally Posted by PR77

Your right, RGA is the chipset address but. I should have made that more clear in my message. DRD is the chipset data bus decoupled from the CPU during chipset only cycles.

I assume DENISE has no internal frame buffer, so then when DENISE detects an address combination of the RGA does it then latch in the DRD data from ChipRAM and AGNUS in a DMA cycle for a field (this is how I should of ask my question- too excited with all the feedback )? This would be the bitplan data I assume? Does DENISE hold the colour platte for the bitplans or is this AGNUS?

Yes, Agnus is address generator (it produce address but data going to Denise), you can manually (CPU and/or Copper) feed data to BPLxDAT registers (search for thread related to HAM with less than 6 bit planes or more than 6 bit planes)

Yes DRD is internal data bus - Amiga is classical UMA approach where display memory and program memory are located in shared space - this is opposite to local video RAM which is common for external graphics cards (also on modern PC) where CPU usually is unable to access memory directly (some form of transfer/move access type is allowed).
But from your perspective important is colour information produced at 12 bit output bus from Denise (unless you have idea to build something like In-division) + HSync and VSync.

As i said - you will significantly simplify design if you provide own clock to Amiga instead trying to separate pixel clock from video data. Commonly in digital video decoders you have dedicated clocking block that searching video signals for highest frequency - usually this acquisition is not easy and imply to use some PLL circuit. For Amiga you may reverse idea and feed own clock thus by design you will be always synchronized to Amiga - AFAIK this approach is common in Amiga flickerfixers/scandoublers - if you watch carefully they are almost always equipped with crystal or generator with same frequency as in Amiga.