> VGA is only a slightly extended superset of the EGA
People remember EGA as being planar and VGA packed/chunky in its most widely used mode 13h 320x200@256.
In reality VGA never stopped being planar internally. VGA like EGA before supports 256KB of ram, but instead of simply giving user access to linear sliding 64KB window it arranges video ram into 4 chained planes. Writing 4 consecutive pixels at 0x0 stores those in video memory 64KB apart.
Depending on the implementation all this complexity can add up. Simply turning off Chaining is not enough, but can be bypassed by engaging VESA linear modes. Effect can be miniscule:
"M13speed examines all video BIOS calls (10h.) If the call is a request for VGA mode13h (320x200 256-color), M13speed replaces the call with a request for VESA SVGA 640x400x8 (mode 100h.) ... The TSR's response to setmode13h includes issuing a VESA setmode100h (640x400 SVGA) request, reprogramming the VGA CRTC and SR registers to setup a 320x200 display field, which looks, feels, smells like MCGA 320x200."
"Without m13speed, the 9680 posted MCGA ("vidspeed L") write performance of 14mb/sec. ...loaded m13speed and re-tested my 9680's MCGA performance - 50mb/sec"
Writing 4 consecutive pixels at 0x0 stores those in video memory 64KB apart.
I don't think "64KB apart" would make much sense either, especially because of the flexibility of the VGA memory controller described in the article; they end up in 4 separate 64KB planes. Unless you're referring to the linear view of the framebuffer that post-VGA GPUs use, in which case the mapping between the planes and LFB can differ considerably between implementations: https://stackoverflow.com/questions/36269239/meaning-of-byte...
> VGA is only a slightly extended superset of the EGA
People remember EGA as being planar and VGA packed/chunky in its most widely used mode 13h 320x200@256.
In reality VGA never stopped being planar internally. VGA like EGA before supports 256KB of ram, but instead of simply giving user access to linear sliding 64KB window it arranges video ram into 4 chained planes. Writing 4 consecutive pixels at 0x0 stores those in video memory 64KB apart.
Depending on the implementation all this complexity can add up. Simply turning off Chaining is not enough, but can be bypassed by engaging VESA linear modes. Effect can be miniscule:
Toshiba Satellite T2130CS CT65545 https://www.youtube.com/watch?v=7PjA6PfyWW8 Mode Y: 28 fps. 13h: 36 fps. VESA: 37 fps
be significant:
SiS 6326 PCI https://www.youtube.com/watch?v=minIT5dBCVQ Mode Y: 55 fps. 13h: 59 fps. VBE2 (LFB): 75 fps
or outright massive:
Rendition Veritè V2200 (internally a MIPS based DSP emulates VGA core in software) https://www.youtube.com/watch?v=6unNuPympE4 Mode Y: 14 fps. 13h: 59 fps. VBE2 (LFB, PM): 305 fps!
There was even a Tweak released for one vendor (Trident) http://www.geocities.ws/liaor2/myutil/m13speed.html that intercepted setting mode 13h and switched it for custom VESA underneath.
"M13speed examines all video BIOS calls (10h.) If the call is a request for VGA mode13h (320x200 256-color), M13speed replaces the call with a request for VESA SVGA 640x400x8 (mode 100h.) ... The TSR's response to setmode13h includes issuing a VESA setmode100h (640x400 SVGA) request, reprogramming the VGA CRTC and SR registers to setup a 320x200 display field, which looks, feels, smells like MCGA 320x200."
"Without m13speed, the 9680 posted MCGA ("vidspeed L") write performance of 14mb/sec. ...loaded m13speed and re-tested my 9680's MCGA performance - 50mb/sec"
Writing 4 consecutive pixels at 0x0 stores those in video memory 64KB apart.
I don't think "64KB apart" would make much sense either, especially because of the flexibility of the VGA memory controller described in the article; they end up in 4 separate 64KB planes. Unless you're referring to the linear view of the framebuffer that post-VGA GPUs use, in which case the mapping between the planes and LFB can differ considerably between implementations: https://stackoverflow.com/questions/36269239/meaning-of-byte...