Thu Jun 4 17:40:56 CEST 2009
pixel clock: 16.257 Mhz (882)
line frequency: 18.432 kHz (370)
refresh: 49.81 Hz
This timing data comes from some obscure .h file i found googling for
"720x350". This is probably correct as the pixel clock is standard,
and the total w x h seems to correspond to other documents.
Looking for 16.257 Mhz shows that this is a standard rate. I found it
referenced here gives 883 pixels:
PC MDA (Mono Display Adaptor)
B&W character-only display 80x25 with 9x14 font, so 720x350 pixels
80x25 (=2000, not quite 2k) chars of each 2byte (1 char, 1 attrib) = 4k RAM
50 full-frames/s of 368 lines (18.43kHz/54.3478us), 350 shown
uses non-square pixels, clocked 16.257MHz, 883pixels/line, 720 shown
not compatible with TV technology so can deviate in signalling, uses pure TTL
2bit digital brightness, and 2 separate 1bit H and V sync
3 gray levels (BI: 00=black, 10=normal (light gray), 11=bright (white))
DB9 connector 1+2 GND, 3+4+5 nc, 6 Intensity, 7 Brightness, 8 HSync, 9 VSync
HSync positive, VSync negative active
I checked with the monitor that 1.5 us hsync pulse works. How long
should the vsync pulse be?
I found timings for VGA text mode (640x350) which gives
hsync 3.77 us
Ok. I got a stable image. Problem was type which meant D3 didn't get
I have it working now with 380 lines + 1 line for the vblank pulse.
Next: interrupt operation to make it jitter-free. Turn the code into
a state machine, and call it from the ISR. This requires some robust
way to set isr vector.
As used before for TV, the hold time of the hsync pulse could be used
to compute state machine dispatch for the timer interrupt. Since I'm
interested in making a dedicated (black box) circuit for driving some
TTL/VGA/TV monitors, this behaviour could be appropriate.