What do you mean by colour working sucessfully?
Do you mean running out of vdc ram as the resolution uses most of it up or something else?
To elaborate on what Tokra was saying (flame me if I'm wrong), the VDC also suffers from 'bad lines', like the VIC-II. Although VDC "bad lines" do not slow down the CPU (like the VIC-II), they
do make the VDC use more cycles than normal. In other words, if you try to display more data than the VDC can access in a restricted time period, then something
will fail. I have had only limited testing, so I can't be sure, but I agree with Tokra... one of the first things to fail is color.
Sorry if that doesn't make sense, so I will elaborate ( now you may suffer from TMI / "wish I never asked"
)
In general, in HxV text mode with a screen width of X characters, the VDC must fetch the following #bytes for every character row:
- Before the (displayed) start of a row, VDC must fetch X character and, assuming attributes are enabled, the VDC must fetch another X attributes
- For each scan line (in the character row of V rasters), VDC must fetch X font bytes
- For each scan line (in the character row of V rasters), VDC must refresh Z rows of DRAM
- For each scan line, the VDC may read up to HT+1 (Horizontal Total) bytes of Video (D)RAM
- For each char row (V rasters), the VDC may read a maximum of (HT+1)*V bytes from V-RAM
Yeah, I know that is abstract, so let me give a real-world example of default NTSC behavior (PAL is almost identical)...
First, here are the parameters:
- H = V= 8 -- standard 8x8 character cells
- X = 80 (80 columns)
- Z = 5+1 = 6 DRAM refreshes per scan line
- Max read bytes-per-raster = 126+1 ($7f) [this is 1+ register 0 = HT+1] = 127 bytes
- Max read bytes-per-char-row = 127 * V = 127 * 8 = 1016 ($3f8)
- Before display, VDC must read X chars + X attributes = 80 + 80 = 160 bytes
Next, here are the intermediate results:
- Before each row, VDC must read 160 bytes (char+attributes)
- For each (of 8) rasters in a character row, VDC must read 80 + 6 = 86 bytes (font bytes + DRAM_refresh bytes)
- For each character row, VDC must read 160 + 8*86 = 848 bytes
Therefore, we can conclude that standard 80-column text works because needed_bytes_per_row (848) is not more than max_bytes_per_row (1016).
Now let's consider mrbombermillzy's most recent post:
- H = V = 8 (implied by his photo)
- X = 768 / H = 768 / 8 = 96 columns (per his statement "768x272")
- Z = 6 (because he did not specify otherwise)
- Max read bytes-per-raster = 127 (implied because he did not mention a different value for Register 0)
- Max read bytes-per-char-row = 127 * V = 127 * 8 = 1016 ($3f8)
- Before display, VDC must read 96 chars + 96 attributes = 96 + 96 = 192 bytes
Then we have:
- Before each row, VDC must read 192 bytes (char+attributes)
- For each (of 8) rasters in a character row, VDC must read 96 + 6 = 102 bytes (font bytes + DRAM_refresh bytes)
- For each character row, VDC must read 192 + 8*102 = 1008 bytes
Therefore, we could conclude that mrbombermillzy's mode should work, because needed_bytes_per_row (1008) is not more than max_bytes_per_row (1016).
However, Tokra reports this actually does not work, unless you change some variables... like changing register zero. (Note a +1 to register zero would give +8 extra cycles, because we are using Hx8 characters). I can't explain exactly why, but if the raster values calculated above were "off by 1" (for whatever reason) then the conclusion would have to be changed to "mrbombermillzy's mode may-or-may-not work, because needed_bytes_per_row (1016) is exactly equal to max_bytes_per_row (1016)".
Finally (if I understand Tokra correctly), it does work if you change register 0 to 127. In that case we have:
- H = V = 8
- Z = 5+1 = 6 (because nobody specified a DRAM register value otherwise)
- Max read bytes-per-raster = 127 + 1 = 128
- Max read bytes-per-char-row = 128 * V = 1024 ($1000)
- Before display, VDC must read 96 chars + 96 attributes = 96 + 96 = 192
Thus we have:
- Before each row, VDC must read 192 bytes (96 chars + 96 attributes)
- For each (of 8) rasters in a character row, VDC must read 96 + 6 = 102 bytes (font bytes + DRAM_refresh bytes)
- For each character row, VDC must read 192 + 8*102 = 1008 bytes
Therefore, we can conclude that Tokra's mode should work because needed_bytes_per_row (1008) is not more than max_bytes_per_row (1024)... even if you add in an extra 8 bytes for an "off-by-one" error.
Tangent (slightly off topic)
The above formulation explains why 8x1 bitmap mode will not work unless you reduce the horizontal size... for example:
- H = 8, V = 1
- Z = 0+1 = 1 (minimum DRAM refresh)
- Max read bytes-per-raster = 126 + 1 = 127
- Max read bytes-per-row = 127 * V = 127 * 1 = 127
- Before display, VDC must read X attributes (no chars in bitmap mode)
Thus we have:
- Before each bitmap raster, VDC must read X attributes (color bytes)
- For each raster, the VDC must read X + 1 bytes (bitmap bytes + DRAM_refresh bytes)
- For each bitmap raster, VDC must read X + X+1 = 2*X+1 bytes
Therefore, we might conclude the maximum width in character cells (X) [or in pixels = 8X] is
X + DRAM_Refresh = Max read bytes-per-row / V
X + DRAM_Refresh = Max read bytes-per-row (because V=1... remember 8x1 cells)
X = Max read bytes-per-row - DRAM_Refresh
X = 127 - 1 (standard Register 0, minus minimum DRAM refresh)
X = 126 chars (1008 pixels) -- assuming no color, and (more importantly) no blanking and no sync (insane!)
X = 125 chars (1000 pixels) -- assuming no color, and minimum 1 char of combined sync+blank (extremely marginal)
X = Int(125/2) = 62 chars (496 pixels) -- assuming color and minimum 1 char of combined sync+blank (extremely marginal)
It has been a long time since I played with 8x1 color cells on the VDC, so I can't say if the above formulation is 100% accurate.
But I am 100% confident that 8x1 color mode must be restricted to much less than 80-char-width (less than 640 pixels) because: another 81 bytes (at least) must be read on each raster (another 80 bytes for color, plus at least 1 byte for DRAM refresh)... and because 80 (bitmap) + 80 (attribute) + 1 (DRAM refresh) is surely greater than standard 127 bytes-per-raster (assuming you want 15.75 kHz H-Sync).
On-Topic
The only way I can think to push the VDC to give a higher resolution than you guys have already demonstrated is to do one (or more) of the following:
- Reduce the number of DRAM refreshes per raster (VDC register 36[$24]) ... the minimum value of 0 works for me and others (based on feedback)
- Increase Register 0 (Horizontal Total)... but this will reduce H-Sync frequency and may fail with some monitors
- Reduce the horizontal sync width (VDC register 3, low nibble)... this will only increase the "theoretically displayable" number of horizontal cells... in particular, it will not increase the number of bytes that the VDC can read (so it is usually irrelevant).
If you really want to max out the VDC resolution, then my above equations should tell you how... disable color! In monochrome mode, the VDC should be able to display almost 1000 pixels horizontally! (I haven't tried this... it is a theoretical prediction!)
I hope I helped more than I confused. Also, I would be interested to hear from anybody/everybody about how my equations work or fail in the EXTREME real world [ I've been using them for many years in the "safety zone" of the real world
]