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:

http://asm.sourceforge.net/articles/modex.html

Edit: The timings you are looking for a likely to be in the section of code that begins with "%elifdef MODE_256X256", so search for that on that page.

Isn't 256x256 256color a Planar mode and not true EGA/VGA mode? Other than a few old Amiga things am curious what you have that uses that resolution. Just curious...

added:

pan069 wrote on 2020-08-05, 21:21:

http://asm.sourceforge.net/articles/modex.html

Nice ! Am going to keep that with Programmer's Guide to the EGA, VGA... good info

Horun wrote on 2020-08-06, 01:26:

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).

pan069 wrote on 2020-08-06, 02:22:

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[1] 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.

Any info on timings? 😀

I still need to know those, and could not get that from the above links.

PlaneVuki wrote on 2020-08-06, 15:10:

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.

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.

PlaneVuki wrote on 2020-08-06, 15:10:

Any info on timings? 😀

I still need to know those, and could not get that from the above links.

Not exactly sure now what you're after then, but aren't these the various values for each of the VGA registers for 256x256 mode (unchained and chained). The timings would be in there.

1%elifdef MODE_256X256P
2.vga_crt_registers:
3	db	0x5f, 0x3f, 0x40, 0x82, 0x4a, 0x9a, 0x23, 0xb2
4	db	0x00, 0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
5	db	0x0a, 0xac, 0xff, 0x20, 0x40, 0x07, 0x1a, 0xe3
6.vga_attribute_registers:
7	db	0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07
8	db	0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f
9	db	0x41, 0x00, 0x0f, 0x00, 0x00
10.vga_graphic_registers:
11	db	0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0f
12	db	0xff
13.vga_sequencer_registers:
14	db	0x03, 0x01, 0x0f, 0x00, 0x0e
15.vga_misc_registers:
16	db	0x63
17%elifdef MODE_256X256
18.vga_crt_registers:
19	db	0x5f, 0x3f, 0x40, 0x82, 0x4a, 0x9a, 0x23, 0xb2
20	db	0x00, 0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
21	db	0x0a, 0xac, 0xff, 0x20, 0x00, 0x07, 0x1a, 0xe3
22.vga_attribute_registers:
23	db	0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07
24	db	0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f
25	db	0x41, 0x00, 0x0f, 0x00, 0x00
26.vga_graphic_registers:
27	db	0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0f
28	db	0xff
29.vga_sequencer_registers:
30	db	0x03, 0x01, 0x0f, 0x00, 0x06
31.vga_misc_registers:
32	db	0xe3

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

Horun wrote on 2020-08-07, 02:05:

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.