video timing - NESdev BBS

video timing
by WhoaMan on 2011-04-22 (#77086)

I have been toying with the idea of making my own monitor driver to output to a CGA monitor, I have not dealt with video too much so I would like to ask some input and see how far off my calculations are.

Bandwidth: ~ 5.8MHz
HSync: ~ 15.75KHz
projected resolution: 320x200

based on the 5.8MHz bandwidth, the 1.575KHz H sync rate, and the 60Hz V sync rate.... this should leave me around 368 clock cycles to draw and retrace per scanline at around 262 times per frame.... correct?

I am thinking that I will start drawing my image on the 20th scanline, and at the 20th clock cycle of each scanline for the following 200 scanlines... leaving 28 clock cycles for overscan and h retrace.... and 42 scan lines for overscan and vertical retrace.

Does this all seem like a good starting point to start tweaking various settings to generate the image?

by qbradq on 2011-04-22 (#77087)

I don't know about CGA, but that's the timings I used for my NTSC video generator I did on an AVR (it played Pong ) Are the CGA timings the same as NTSC?

by WhoaMan on 2011-04-22 (#77088)

as far as i know, they are fairly similar (if not the same). I know a lot of CGA cards also output as a composite signal so it would not surprise me. Im glad to hear those calculations are what you used. hopefully everything will work for me.

Re: video timing
by Hamtaro126 on 2011-04-22 (#77089)

WhoaMan wrote:
I have been toying with the idea of making my own monitor driver to output to a CGA monitor, I have not dealt with video too much so I would like to ask some input and see how far off my calculations are.

Bandwidth: ~ 5.8MHz
HSync: ~ 15.75KHz
projected resolution: 320x200

based on the 5.8MHz bandwidth, the 1.575KHz H sync rate, and the 60Hz V sync rate.... this should leave me around 368 clock cycles to draw and retrace per scanline at around 262 times per frame.... correct?

I am thinking that I will start drawing my image on the 20th scanline, and at the 20th clock cycle of each scanline for the following 200 scanlines... leaving 28 clock cycles for overscan and h retrace.... and 42 scan lines for overscan and vertical retrace.

Does this all seem like a good starting point to start tweaking various settings to generate the image?

I never read much DOS Documents, but If i'm not wrong, the CGA can also go up to 640x480 maximum, and custom fonts was only in Higher end Hercules cards as well as EGA or compatible, But CGA only has a default font, so it can't do fonts (unless in graphics modes?)

so if I was to select a old Video card back then, EGA/VGA or anything compatible was the better choice, if you also want font support, Stick with that

Also, a Reference: NO$GMB can emulate the gameboy (sloooowly) in CGA in pure DOS only, so any Windows version does not work well with it, Dosbox or equivlents do work though!

EDIT: The ugly colors in CGA were the only dislike in my opinion,

qbradq: I also do not know, But it's may depend on the computer that monitor is using, For example: Apple2 vs Amiga monitors use different plugs, So it may depend on the video processor (GPU) and how much pins the monitor plug uses!

by WhoaMan on 2011-04-22 (#77090)

Hamtaro126: I will be using just the monitor and making my own driver for it, I plan on having a 40x25 2-color text mode with ascii char rom, a 40x25 16 color tile mode (using ram for tiles) and a 320x200 16 color bit-mapped mode.

As for the max res of an actual CGA adapter, I believe it was a 640x200x2 mode. the CGA monitor itself is able to generate 16 colors

by lidnariq on 2011-04-23 (#77140)

The CGA adapter generated pixels at 4xNTSC (14.318MHz) or 2xNTSC. The full timing (which I ripped from the monitor-compatible IBM EGA bios) for all modes is some variant of-
Code:
0 visible-period A right-overscan B right-blanking C sync D left-blanking E left-overscan F
Horizontal:
A = 80 (640) B = 89 (712) C = 94 (752)
D = 102 (816) E = 109 (872) F = 114 (912)
Vertical:
A = 200 B = 223 C = 225
D = 228 E = 239 F = 261
80 = character cells, (640) = pixels for the 640x200 mode; divide those in parens by 2 for 320x200 mode.
Also CGA monitors have enough overscan you should be able to increase the onscreen pixel count to 90x30=720x240 (per Trixter's authentic CGA tester)

Or if you're comfortable with Xorg modelines,
"640x200" 14.32 640 752 816 912 200 225 228 261 # H-15700Hz V-60.15Hz

The analog bandwidth of the CGA monitor is at LEAST ~15MHz. Many also accept interlaced input, for which you should use native NTSC 480i timing.

by Hamtaro126 on 2011-04-23 (#77146)

WhoaMan wrote:
Hamtaro126: I will be using just the monitor and making my own driver for it, I plan on having a 40x25 2-color text mode with ascii char rom, a 40x25 16 color tile mode (using ram for tiles) and a 320x200 16 color bit-mapped mode.

As for the max res of an actual CGA adapter, I believe it was a 640x200x2 mode. the CGA monitor itself is able to generate 16 colors

I got a sudden interest in the project, So can you do a source code release with a license via GNU v3 or something?

I was working on something like it for Epic (Mega)Games ZZT/SuperZZT as a EGA/VGA project, with some help of DigitalMZX and Z2, But could not use the pseudo-code because of QB45 not supporting STORE or LOAD functions,

by WhoaMan on 2011-04-25 (#77211)

hehe, I have plans to release what I am working on... the video portion and more. I am going to do a few tests with hardware only to drive the video.. to get any timing issues and what not worked out and then re-implement it using a micro-processor.

In case anyone is curious, the whole project is a 6502 based computer that I plan on building out of misc parts i have had sitting around my house for a while.

I plan on having the memory mapped divided as follows: (sorry for the caps)
Code:
+=================+    0x0000    ===================================================================================
| 16Kb RAM (Fixed)|             ZP, PROCESSOR STACK, AND GENERAL MEMORY
| |
+=================+    0x4000    ===================================================================================
| 16KB (BS) |             BANK SWITCHED MEMORY FOR EXTRA STORAGE / DIRECT VRAM MANIPULATION / CARTRIDGE OR
| |             EXPANSION RAM, ROM, OR OTHER I/O
+=================+    0x8000    ===================================================================================
| 8Kb reg/exp |             CONTROL REGISTERS AND EXPANSION CARD I/O
+=================+    0xA000    ===================================================================================
| 8Kb ROM (BS) |             BANK SWITCHED ROM, 8Kb CHUNKS SPLIT BETWEEN INTERNAL ROM AND CART ROM
+=================+    0xC000    ===================================================================================
| 8Kb ROM (BS) |             BANK SWITCHED ROM, 8Kb CHUNKS SPLIT BETWEEN INTERNAL ROM AND CART ROM
+=================+    0xE000    ===================================================================================
| 8Kb ROM (Fixed) |             INTERNAL ROM, BASIC OS AND FIRMWARE STUFF
+=================+    0xFFFF    ===================================================================================

The 8KB Register/Expansion area will be further divided in to 8 1Kb sections for expansion slots. slot 0 from 0x8000 - 0x83FF will be for internal register and hardware control for video, input, etc.

I figure the system will start running the internal ROM at powerup or reset, and let the use jump to the cartridge rom (if one is inserted) or allow the user to run some sort of monitor program... and use the interrupt to control system functions

I am not to sure what I would like to do as far as sound, anyone have any suggestions?

by Hamtaro126 on 2011-04-25 (#77213)

I may consider it if the driver and hardware supports a good Palette, Sprite support similar to the NES, and a secondary mode with an expansion to specifically run NES games and bankswitching with few modifications

using these enhancements are really promising a bit, so this is a long way to go before making the final product!

by WhoaMan on 2011-07-05 (#81124)

lidnariq wrote:
The CGA adapter generated pixels at 4xNTSC (14.318MHz) or 2xNTSC. The full timing (which I ripped from the monitor-compatible IBM EGA bios) for all modes is some variant of-
Code:
0 visible-period A right-overscan B right-blanking C sync D left-blanking E left-overscan F
Horizontal:
A = 80 (640) B = 89 (712) C = 94 (752)
D = 102 (816) E = 109 (872) F = 114 (912)
Vertical:
A = 200 B = 223 C = 225
D = 228 E = 239 F = 261
80 = character cells, (640) = pixels for the 640x200 mode; divide those in parens by 2 for 320x200 mode.
Also CGA monitors have enough overscan you should be able to increase the onscreen pixel count to 90x30=720x240 (per Trixter's authentic CGA tester)

Or if you're comfortable with Xorg modelines,
"640x200" 14.32 640 752 816 912 200 225 228 261 # H-15700Hz V-60.15Hz

The analog bandwidth of the CGA monitor is at LEAST ~15MHz. Many also accept interlaced input, for which you should use native NTSC 480i timing.

lidnariq, Im not sure if you have seen this or not yet, but the info you posted was quoted and linked to by someone interfacing a CGA monitor to an arduino.

http://techblog.vsza.hu/posts/Arduino_v ... g_PoC.html

by tomaitheous on 2011-07-05 (#81126)

Quote:
I am not to sure what I would like to do as far as sound, anyone have any suggestions?

Are you going to be doing the sound via an MCU or real low level parts (or cpld or such)?

If you have the resource to spare, a PHA (phase accumulator) square and saw-tooth (ramp) generator is always fun. As long as you have enough timing 'resolution' to drive the PHA, else it'll sound dirty IMO. If you do saw-tooth/ramp, go one step further and add hard sync. It's dead simple and sounds good with a saw waveform.

http://www.youtube.com/watch?v=GPg73WFemAA <- all saw waves (except 4 notes in the entire song that use a square wave).

by lidnariq on 2011-07-05 (#81141)

WhoaMan wrote:
[lidnariq, Im not sure if you have seen this or not yet, but the info you posted was quoted and linked to by someone interfacing a CGA monitor to an arduino.

http://techblog.vsza.hu/posts/Arduino_v ... g_PoC.html
Yup, I read Hackaday. Upon reading it, I thought "that formatting looks awwwwfully familar".