I know that the half clock must be every start of the character clock and half past it(probably at the 4th clock), thus ticking at clocks #0, #4, #9, #13 etc. when using 9 dots/clock.
I'm wondering how graphics mode affects that. Does it essentially force the half clock to be every 4th dot clock instead(so ticking at clocks #0, #4, #8, #12 etc.), even if it's set up for 9 dots/clock? I can imagine that if it would use 9 dots/clock in graphics mode, you'll get a black (attribute of 0) pixel(in 16-color mode) every 9th clock, or a half pixel(the upper or lower nibble of the attribute of the 9th pixel, which alternates over the screen) due to the shift register being starved on the 9th pixel(and doesn't reload until the next character is fetched from VRAM, which would be at dot clocks #0, #9, #17 etc.)?
Anyone knows how the 8/9 dot mode affects graphics modes? Or does it just affect the CRT timing(the active display area in this case), making the half character clock tick at a solid 4-clock cycle(every 4th pixel from the start of the active display)?
Well, it seems to be the direct clocking that affects all divide by 1/2/4 clocks(in this case the increasing every 4 clocks for the address counter and every 4 clocks for the loads from the 4 planes into the shift register). Dividing it up will decrease the rate at which it increases(in pixel clocks multiple of 4 or 5(9 pixel wide second half of a character clock)), driving the Memory Address clock and horizontal character clock(with regards to VRAM addresses only) by two of those divide by 1/2/4 settings in the sequencer registers. That's the sequencer mode register bits 2 and 4(for the loading of the serializer), and the crtc underline register bit 5 and crtc mode control register bit 3 for the memory address counter.
In UniPCemu, said shared clock ticks every 4 dot clocks in graphics mode and 8 dots/char text mode, while ticking 4;5 (so at dot clock 0,4,9,13 etc.) in 9 dots/char text mode. The hardware is set up for DIV2+SLR set for text mode(thus increasing address and reloading every 2 half clocks). In graphics modes, they're either set or cleared(depending on 256 color modes or not. Set for 4/16 color modes(8 pixels per 4 planes). Cleared for reloading every 4 pixels(since they only resolve to 4 pixels instead of 8, it needs double the load rate to load enough to not run out of the shift register after 4 out of 8 dot clocks).
In the UniPCemu VGA precalcs(vga_precalcs.c), you can see the settings having effect within the VideoLoadRateMask and characterclockshift precalcs(ranging from 0 to 7 as set bits for a mask-and-compare-to-zero mask against a counter.
The renderer uses said masks within VGA_ActiveDisplay_timing function(vga_renderer.c) to time it's increasing of the memory address counter((++x&characterclockshift)==0) and reloading of the serializer shift register((++x&videoloadratemask)==0), in that order. It's essentially one base signal(the dot clock) which ticks the MA counter and loading of the shift register after that.
You can create different combinations of those. Say, don't divide the MA clock, but do divide the video load rate. That will cause the Memory Address to increase every 4 clocks, but the reload to happen every 8/9 clocks(thus having the effect of jumping the MA as it reloads e.g. a new character, skipping every odd numbered character. Of course, you'll want to set it to divide by 2 for 16/4/2-color modes and usually clear it for 8-bit color modes. Don't know why you'd want to use the divide by 4, though? That'll create 3/4 black bars every other character? Even more for graphics modes?
I'm not quite as familiar with the internal workings of VGA as I am with CGA, so I might be saying something completely stupid here... but is it possible that you're on completely the wrong track with the "4 dot clocks" thing? I'm not sure that a 4 dot clock is used in any significant way inside the VGA. In https://github.com/KokaKiwi/dcpu16-x86/blob/m … ence_manual.txt section 6.05.21 (which talks about the memory address counter divider bits I think you're talking about, "Display Memory Address Unit") the options are addressing in units of 1 byte, 2 bytes or 4 bytes. This controls the amount of VRAM addressed by each "character" (a character being 8 or 9 dots). In 640x480x16 graphics mode, the address increases every 8 pixels (1 byte "character"). In text mode the address increases every character, which is two bytes (character + attribute) or 8/9 pixels. But it increases 2 bytes every character, not 1 byte every half character. And in 320x200x256 mode it increases 4 bytes every character (4 double-width pixels).
We may be talking completely at cross-purposes though.
Perhaps you're talking about the byte/word/doubleword modes of the CRTC? That's controlling the other side of the MA to memory input, and it takes a 'byte'(from 4 planes at once), in increases of 1(byte), 2(word) or 4(doubleword) according to the byte/word bit in the crtc controller mode control register(bit 6) and underline location register(bit 6)? That's what's usually controlling the increase of 1/2/4 on the plane level(UniPCemu emulates VRAM as 64K(or multiples, e.g. 256K on ET4000 and 128K on ET3000) dwords, of which the bytes in each dword(at an address, which is MA shl 2 for the dword) are the actual 4 planes respective bytes that are loaded as said dword into the dword shift register every 8 clocks(in 16/4/2 color modes) or 4 clocks(for 8-bit(16-bit too on ET4000) color modes).
Both those clocks I mentioned in my previous post need to operate at the 4 dot clock speeds to work properly. The lowest setting on them can't be the 'character clock', as the 8-bit modes would starve the sequencer's shift register in just 4 of those clocks(8 becoming 4 pixels, but widened to twice the width because of the dot clock divide by 2).
Or are you saying that the 'character clock' isn't actually correctly documented? The FreeVGA is kind of documented weirdly on that.
S4 -- Shift Four Enable
"When the Shift 4 field and the Shift Load Field are set to 0, the video serializers are loaded every character clock. When the Shift 4 field is set to 1, the video serializers are loaded every forth character clock, which is useful when 32 bits are fetched per cycle and chained together in the shift registers."
DCR -- Dot Clock Rate
"When set to 0, this bit selects the normal dot clocks derived from the sequencer master clock input. When this bit is set to 1, the master clock will be divided by 2 to generate the dot clock. All other timings are affected because they are derived from the dot clock. The dot clock divided by 2 is used for 320 and 360 horizontal PEL modes."
SLR -- Shift/Load Rate
"When this bit and bit 4 are set to 0, the video serializers are loaded every character clock. When this bit is set to 1, the video serializers are loaded every other character clock, which is useful when 16 bits are fetched per cycle and chained together in the shift registers. The Type 2 video behaves as if this bit is set to 0; therefore, programs should set it to 0."
DW - Double-Word Addressing
"When this bit is set to 1, memory addresses are doubleword addresses. See the description of the wo […] Show full quote
DW - Double-Word Addressing
"When this bit is set to 1, memory addresses are doubleword addresses. See the description of the word/byte mode bit (bit 6) in the CRT Mode Control Register"
DIV4 - Divide Memory Address Clock by 4
"When this bit is set to 1, the memory-address counter is clocked with the character clock divided by 4, which is used when doubleword addresses are used."
Word/Byte -- Word/Byte Mode Select
"When this bit is set to 0, the word mode is selected. The word mode shifts the memory-address counter bits to the left by one bit; the most-significant bit of the counter appears on the least-significant bit of the memory address outputs. The doubleword bit in the Underline Location register (0x14) also controls the addressing. When the doubleword bit is 0, the word/byte bit selects the mode. When the doubleword bit is set to 1, the addressing is shifted by two bits. When set to 1, bit 6 selects the byte address mode."
DIV2 -- Divide Memory Address clock by 2
"When this bit is set to 0, the address counter uses the character clock. When this bit is set to 1, the address counter uses the character clock input divided by 2. This bit is used to create either a byte or word refresh address for the display buffer."
Can you make sense of how this is put together? How does the "dot clock" affect all this? What about the various mentions of the "character clock". It all will fall apart in 8-bit color modes and it's extensions(16-bit or even 32-bit color modes, although ET4000 only directly supports 8-bit&16-bit(extension of 8-bit, but double the clocks, pixel duplication and 4x4-bit combination to 16-bit DAC input(if not done by the DAC using 8-bit inputs(Sierra Hi-color DAC)))).
Edit: There's also the undocumented case of the CRTC mode control register bit 3 and underline location register bit 5 both being set, activating the half clock being used directly instead of whole/double/4 times. That isn't documented in the freeVGA documentation(used for the 8-bit color modes and up).
DCR is the easy one because everything else is derived from this dot clock. So when it is set to 1, everything on the screen is stretched by a factor of two horizontally. This is used for 40-column text mode and 320x200x16 mode. A character in these modes is still 8/9 dots, but the dots are twice as big. Other than that everything works the same - there's no shift register starvation or anything like that.
The 8-bit colour mode combines two dots to form each pixel - DCR is still set to 0 for this mode so a character is 4 pixels instead of 8 but it's still 32 bits of VRAM data.
The "Display Address Dwell Count" bits (CRTC mode control register bit 3 and underline location register bit 5) control how many character periods pass before the address is incremented, while the "Display Memory Address Unit" bits control how much the address is incremented by when it is incremented.
What bits do you mean with "Display Memory Address Unit' bits?
CRTC mode control register bit 6 and underline location register bit 6.
Errrr.... As far as I know said logic is handled by inputting the Memory Address counter at a different location(with some strange logic happening on the Tseng chips that's different from the VGA). All documentation I know of (FreeVGA etc.) states that it affects the shifting on the Memory Address before transforming it using the MAP13/14 logic to a VRAM dword address. It doesn't have anything to do directly with different things adding to the Memory Address counter. That's already implemented as various documentations state it(with an exception on the dword addressing mode for the Tseng ET3000/ET4000 chips).
On the VGA, that doesn't 'increment'. It affects a simple shift left of the memory address(MA clock ticking it) before passing through the MAP13/14 transformation stage for the dword number to address in VRAM.
Thinking about it some more, what happens in the clock periods that the colors aren't ready for display(e.g. all even dot clocks on 8-bit color modes)? What does the DAC do? Logically it should render a pixel, but the pixel isn't assembled in that clock? The same for 16-bit color modes on clocks 0,1,2,4,5,6,8,9,10 etc.? What happens to the DAC output(as there isn't anything yet) and CRTC? Is the DAC output multiplied by the held state pixels? So if it's needing to wait 1 clock(due to only having latched half a pixel), does it put out 2 pixels to the display to make up for the missed pixel(4 in the case of 16-bit colors) after it receives the color for the 8-bit DAC lookup value?
Also, there's the case of the Sierra Hi-color DAC doing these things(the 8-bit or 16-bit latching) itself? How does that work(compared to the dot clock)?
Currently, UniPCemu simply duplicates over the held clocks once it receives a pixel to render(DCR(1 or 2) times attribute size(1(4-bit)/2(8-bit)/4(16-bit) pixels of said color). Other display areas only display(render) 1 pixel for each dot clock(except retraces).
Edit: Perhaps the PCLK output to the DAC is used to only sample 8-bit values when the 8-bit(VGA and up) or 16-bit(ET4000 only) latches are used? But what happens during the first of the 2 clocks(when it's still latched half the value(4 out of 8 bits))?
After looking around some more, apparently during the latching of a 8-bit color value, the display doesn't render any pixel. Then, during the odd clock(every second clock), the VGA renders 2 pixels with the same color value.
So the display is programmed for 640 pixels, which become 320 2x pixels.
The DCR bit is cleared(so still single clocks and pixels). 8-bit/16-bit settings itself(both through the Sierra Hi-color DAC and attribute controller, where they can theoretically be combined for 32-bit colors with truncation to 16-bit lookup values) each doubles the pixels rendered to the CRT. So DAC(in 16-bit latching mode) duplicates input by 4 times width. DAC in 8-bit latching mode duplicates by 2 times width.
On top of that, the attribute controller does the same. So you could theoretically generate a x16 output(attribute controller 16-bit+dac in 16-bit latching mode)!
The dot clock would still render 8 pixels per clock, just like any of the 4-bit rendering modes. It's just the color and rendering multiples that's affected(at vga and at dac level).
Just modified the VGA to use the whole/double/quadruple character clocks instead of half clocks.
The multiplication by the attribute controller and dac was already implemented.
Edit: There still is the undocumented case when both bits are set for the underline location bit 5 + CRTC mode control bit 3, now behaving as they're both cleared instead of a half clock.
Edit: Just checked the result. ET4000 duplicates all horizontal characters in text mode(mode 3)?
Edit: According to the timings dump, the character clock is every 9 clocks. DCR is zeroed.
So now there's a problem with the address counter incrementing too slow(half of what it's supposed to be)?
So bit 3 of the CRTC mode control register is set for 2 counters clocks for each MA clock increase? DIV2 is set?
The shift/load rate(SLR) seems to be correct, as it doesn't restart the character at wrong offsets or runs out of the buffer(when more than 8(graphics)/9(text) pixels wide.
But apparently the MA counter increases once every 2 character clocks, thus displaying each character twice?
Edit: Nope. The CRTC mode control register is 0xA3. Underline location register is 0x1F. The sequencer clocking mode register is 0x00.
Huh? That seems correctly set up?
Edit: So, that's SLR of 0(every character clock), No DCR(Normal clocking), No DIV2/DIV4(increase every character clock), plain word mode(for character mapping, increasing memory dword addresses by a proper 4)?
Then why am I getting doubled characters?
Edit: Huh? Looking at the rendering state, the MA is increased every 2 character clocks, due to the characterclockshift precalc being set to 1? Since the register value is 0xA3, it should be 0 instead?
1 //This applies to the address counter (renderer), causing it to increase and load more/less(factors of 2). This is used as a mask to apply to the 2 if (GETBITS(VGA->registers->CRTControllerRegisters.REGISTERS.UNDERLINELOCATIONREGISTER,5,1)) 3 { 4 if (GETBITS(VGA->registers->CRTControllerRegisters.REGISTERS.CRTCMODECONTROLREGISTER,3,1)) //Both set? We reload twice per clock! 5 { 6 characterclockshift = 0; //Reload every whole clock(8 pixels)! 7 } 8 else //Reload every 4 clocks! 9 { 10 characterclockshift = 3; //Reload every 4 clocks(32 pixels)! 11 } 12 } 13 else if (GETBITS(VGA->registers->CRTControllerRegisters.REGISTERS.CRTCMODECONTROLREGISTER,3,1)) 14 { 15 characterclockshift = 1; //Reload every other clock(16 pixels)! 16 } 17 else //Reload every clock! 18 { 19 characterclockshift = 0; //Reload every whole clock(8 pixels)! 20 }
Edit: Whoops. Said functionality was also in the ET4000 customization. Since I forgot to alter it's values, wrong values were being calculated 😖
hJust ran CheckIt Diagnostics on the new rendering. On the ET4000, modes 4h, 5h and Dh all fail in the same way: the display is somehow only half the size during it's rendering, while only displaying half the pixels of what seems to be a character clock?
Edit: These are the values for mode 4/5:
- CRTC mode control register (index 17h): A2h.
- Underline location register (index 14h): 00h.
- Sequencer Clocking Mode Register (index 01h): 09h.
So, that's:
- DCR is halved, doubling all pixels in horizontal size.
- 9 dot mode is set???
- Character clock shift is in byte mode.
- Same for the loading.
So it's OK.
Edit: Managed to find the bug (there were two remaining bugs in total):
- The ET4000 handling for the DIV2/DIV4 etc. weren't updated yet(thus using the old half clock method while using whole clocks instead 😖 ).
- The whole clock ticking was being executed at 9 dot clocks/character instead of 8(the 9/8 dot mode bit in the Sequencer Clocking Mode Register(bit 0) has no effect on graphics modes rendering, except CRTC display timing(the size of the active display etc. to be exact)).
SVGA modes however, they somehow mess up horizontal timing with 8-bit pixels and 16-bit pixels?
Basic colors seem alright, but the screens are only half filled. And some weird issue occurs with something to do with the character clock?
Edit: Hmmm.... The CRTC mode control register's value is 0xAB. It's supposed to be 0xA3 afaik. So bit 3 is now set, causing it to increase memory address clock every odd clock, messing up the display?
Hmmm... There's a special ET4000 case there: The Underline register bit 5&6 are both set to 1, but bit 3 in the CRTC mode control register is also set.
The ET4000 manual says the following about that:
Bit 3 of the CRTC mode register is set to 1 to cause the linear counter to increment on every other character clock, rather than incrementing on every character clock. When set to 0, the linear counter is incremented on every character clock. This is typically associated with situations where DOTCLK is not divided by two but VLOAD is divided by two ...
One interesting thing at the end of that part... Looking at the end, it notes something special:
Note: When this bit = 1 and Bit 5 of the Underline Row Address Register also = 1, then the linear counter will increment twice per character.
So that's the reason the whole 'half clock' mechanism was used instead of the whole clocks as the VGA describes it. To archieve the 'increment twice per character', it was required to be implemented. It breaks the VGA compatibility on that one(it's supposed to do DIV4 instead of a DIV0.5 according to the FreeVGA stuff?), but is required for the ET4000/ET3000 to function in it's advanced graphics modes.
So in answer to your question where you'll notice it: when using the ET4000 with non-standard VGA 256-color and 32K/64K color(using the DAC for latching 8-bits to 16-bits) modes(Using the Sierra Hi-color DAC) running WhatVGA's non-standard VGA(>mode 13h) display modes(the ones that do seem to actually run. Some graphics modes(only 1 or 2 odd resultions(I believe it was a 7xx scanline one) and the advanced textmodes) aren't even recognised.). The same pretty much will apply to any software using those modes(at least using the int10 function 0x00 call for setting it up, unless it's modifying the SVGA registers, like Windows 3.x afaik. Perhaps it applies to 9x as well).
What I'm still wondering about is this: when setting up a 32K/64K 800x600 graphics mode using WhatVGA and Windows 3.x, I notice that there seems to be an extreme big overscan area(about 400 pixels wide?) from the end of the horizontal retrace until it reaches horizontal total? I know that the horizontal timings are doubled for the 32K/64K mode to work properly(it's set up for an end horizontal display of 1600 pixel clocks), but the horizontal total seems to have been set up for a whopping ~2000 pixel clocks? So I'm getting a about quarter screen left of the active display filled with the overscan area?
I don't think that's supposed to be happening? Do you know anything about the timings of the 800x600 32K/64K modes?
I don't think that's supposed to be happening? Do you know anything about the timings of the 800x600 32K/64K modes?
I don't know the precise timings, but such a wide overscan seems wrong to me. I'd expect the ratio of active area to overscan to be similar to 640x480 mode. And the overscan size shouldn't depend on the number of colours - the monitor can't tell how many colours the mode is, it just receives an analogue signal.
Well, there's one special thing I know about the 32K/64K colors: at least the active display has to be double the size of it's 256-color version(and it is). So the length of the active display(horizontal display end) is set to 1600 pixel clocks(and it is set to that exact value in 800x600x32K/64K).
Edit: Note: The writeback, nextclock and halfclock (horizontal timing precalcs) apply only from the start of the rendering of the active display(used to drive the active display only). So if it's skewed by 1 clock, the 1st character clock starts using the 0th entry in the list. After that, it keeps using incremental indexes of those col values to drive active display(with and without blanking), while the CRTC continues at clock 1 in that case. So in that case, CRTC character clock 1 = horizontal timing precalcs clock 0. clock 2 = clock 1 etc. But they're both used(ticked) at the speed of the clock crystal(e.g. 25MHz/28MHz).
Edit: Also, the horizintal timing precalcs for graphics modes are fixed at 4 clocks/halfclock(thus 8 pixels/character). The 8/9 dit mode setting has no effect of that part of the graphics modes. It does have effect on the horizontal timing for stuff like the various CRTC driving areas(active display, overscan, retracing, blanking and horizontal total).
