Two bugs found + video timing

Juergen Buchmueller pullmoll at t-online.de
Wed Jun 6 15:55:49 PDT 2007


The pixel clock and inverse bit selection is swapped. According to the
schematics BUS[0] selects normal mode (0), or inverse mode (1), and BUS[1]
selects the pixel clock (0), or half pixel clock (1).

The next address modification obviously needs to mask the bits it wants to
change, i.e. it is driving the lines low, too. I say obviosuly because
tasks were executing invalid f2 functions with an OR alone. Specificially
the DHT was going nuts prior to this change. I have yet to carefully check
the corresponding section of the schematics to be 100% sure.

Finally you should know what I found out about the video timing.

The total width/height is 768 by 875 pixels.
The 768 is because 875 scanlines at 30 frames per second results in a
scanline rate of 26250Hz. The bit clock is really 20.16MHz, not 20Mhz, and
so the pixel time is really 49.603ns.

20160000/26250 = 768, and this number makes sense in combination with how
each scanline is divided into two halves; the vcounter is counting from
150 to 1799 inclusive, and the lowest significant bit H[1] is the 'half
scanline'. With the pixel clock being divided by 24 to address the
hsync/hblank/scanend PROM a63, the 768 makes perfect sense: 32 sections, 16
per half scanline, which corresponds to the 4 address bits of a63.

I think we will need some more PROM's contents to get the timings right.
Trying to figure them is difficult and wrong values may mislead you in
further efforts. This is the list (page #s are off by -2 for the pdf):

* a38, page 8 (type is P3601, 256x4) for display word task control
* a63, page 12 top (type is S8223, 32x8) for hblank/hsync/scanend ...
* a66, page 12 bottom (type is P3601, 256x4) for vblank/vsync

Juergen


More information about the Altogether-devel mailing list