The 256x256 resolution is certainly possible but it might not (probably won't) display correctly on many modern LCD displays. The only ones I have had 100% success with are standard 320x200 and 320x240.
Re. timings, I'm not sure. I based my modex code on this source. It seems to support a wide variety of resolutions. Almost all of them work fine in DOSBox (and probably old CRTs) but you will probably run into issues on modern LCDs:
Isn't 256x256 256color a Planar mode and not true EGA/VGA mode?
Yes. 256x256 is a plane based video mode (a.k.a unchained mode). The only non-plane based 256 color mode on standard VGA is mode 13h. All plane based video modes are true EGA/VGA video modes (although you might find displays not capable of displaying all of these modes). In fact, all 16 color modes for EGA/VGA are plane based. It is actually mode 13h (320x200 linear) that is the odd one out, it's actually an abstraction on top of 320x200 plane based to make it easier to work with but sacrificing 75% of video memory (by making it non-accessible).
Yes. 256x256 is a plane based video mode (a.k.a unchained mode). The only non-plane based 256 color mode on standard VGA is mode 13h.
It is actually mode 13h (320x200 linear) that is the odd one out, it's actually an abstraction on top of 320x200 plane based to make it easier to work with but sacrificing 75% of video memory (by making it non-accessible).
As 256x256 pixels just needs 65536 bytes of memory (i.e. the 25% you can access in linear mode), I see no strict requirement to not run it in chain-4 (AKA linear) mode. You will loose the advantage of multiple pages and fast screen-to-screen copies, though. Depending on application, chain-4 256x256 or planar 256x256 might be more appropriate.
1: Whether "fast" screen-to-screen copies (copy 4 pixels in each iteration of rep movsb) really outperforms 32-bit writes highly depends on the VGA card. With old 8-bit architecture cards without write buffering (think original VGA), the fast screen-to-screen copy was a big win indeed, but fast 32-bit VL cards (like the ET4000/W32) likely perform better if you repeatedly copy from main memory to screen memory instead of using the old EGA-compatible 32-bit screen-to-screen-copy mode.
Yup, accessing VGA memory can be painfully slow. And often copying from main memory to the VGA is faste and/or simpler. It’s too bad that IBM didn’t design the VGA with a proper linear mode with paging.
YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC
I still need to know those, and could not get that from the above links.
256x256 is no standard mode, so I don't think there is one standard timing for it. I think some SNES emulators (like snes9x) use that mode, you could check what they do. If I were to implement that mode in one of my programs, I would set up 320x240 (same timings as 640x480, but half pixel clock and double-scanned lines), and then decrease the number of visible 8-pixel units from 32 to 40 (thus increase the blanking) and the increase the number of visible scan-lines from 240 to 256 (thus decrease the blanking). Finally, I would shift the sync pulse position to keep the image centered (i.e. make the horizontal sync start 4 8-pixel units early and make the vertical sync start 8 lines late). This would create a square image instead of a 4:3 image on a standard VGA monitor, but I don't see a better way with the constraints that the mode should be produced on standard VGA hardware and displayed on standard VGA monitors.
Tweak16b can set both chained (one video page) & unchained (4 video pages) 256x256 modes, and shows you the timings and stuff right there. It's a bit clunky, but just fire it up, hit 'L' and type '256x256.256' or '256x256c.256' to load the mode. Press 'enter' once the profile is loaded to test it. It also has a bunch of sources included...
I included this program & this mode in my LCD testing suite, so if you want to see how various panels support it, check the database thread.
DOSBox also supports it fine, BTW.
twitch.tv/oldskooljay - playing the obscure, forgotten & weird - most Tuesdays & Thursdays @ 6:30 PM PDT. Bonus streams elsewhen!
Most emulators back then (eg. NESticle) had 256x modes that used the same pixel clock as standard VGA and just had fat borders on the left and right. But there were one or two (Magic Engine?) which somehow configured a full screen 256x240 which was cool but didn't work on every system even with a CRT.
I think OP wants the actual H/V/Refresh rates in frequency which from what you all say will vary depending on Video Card and Monitor, or maybe am mis-reading things again ;p
You can calculate actual refresh rates from those registers. Let's start with the "Miscellaneous Output Register": Interestingly, it's different in the two modes. "63" indicates to the monitor that the mode has 400 active scanlines, whereas E3 indicates that the mode has 480 active scanlines. Standard VGA monitors often use this indication to select the vertical deflection amplitude, so E3 creates a less tall picture. As the actual amount of active scanlines is 512, E3 looks like the "proper" value and 63 like a worse choice. This value also contains the dot clock, it is 25.175 MHz.
Now, the first CRTC register is the number of character units minus 5. It's 5Fh in both mode variants, so the timing is 64h (100 decimal) character units. As the lowest bit of sequencer register number 1 is set, a character unit is 8 dot clocks. This means the horizontal frequency is 25.175MHz/800 = 31.47kHz. This is the standard VGA line frequency.
Next, the vertical frequency can be obtained from the total line count. The line count minus two is stored in the 7th CRTC register (0-based index: 6). This register is 23h, which is 35 decimal. There are two more bits in the next register (check a VGA data sheet for details), which add 512 additional scan lines. The total number of scan lines is thus 547 + 2 = 549 scanlines. 31.47kHz / 549 = 57.3Hz. This is below 60Hz, so some VGA monitors might lose vertical sync on this mode. The extra lines are probably added to the vertical timing to provide sufficient time for the vertical retrace in spite of the extra 16 double-scanned lines (32 physical lines). The original 480-line mode uses 525 lines, see http://tinyvga.com/vga-timing/640x480@60Hz to obtain 60Hz. The amount of extra scanlines (24 in this case) is a tunable parameter, and the optimal value depends on the specific monitor in use.
Result: The register values posted generate a timing of 25.175MHz / 31.47kHz / 57.3 Hz. Other implementations of 256x256 might differ.