I'm interested in knowing if any modern system does it the easy way, and just has a CPU and video/audio buffer and nothing else.
Do graphing calculators count as "modern" if they're still being sold in 2019? Even ignoring stuff from 1999, the TI-84+ CE was introduced in 2015 and it looks like it's just got a framebuffer and DMA.
I think the Gameking is something like this, though how "modern" it is could be debatable.
Framebuffer as in zero GPU acceleration? Everything is going to have some form of GPU acceleration, even the old machines still have GPU acceleration.
As in "no GPU acceleration" beyond having the ability to read out all video memory and send it to a display.
I think the last machine to do that was CGA, but even it had a Char Mode. Spectrum is pure framebuffer and nothing else. I think the BBC Micro and Amstrad have Char mode as well as bitmap. Oh wait Apple, yeah.. Apple IIgs, Macs up to(but no including) the G3 era? The Power Mac pages are very vague and don't mention graphics at all, the II didn't have any hardware acceleration though.
Seems you're talking exclusive about PCs and ignoring everything that isn't a PC. Most PDAs (remember those!) had no hardware acceleration and just had a framebuffer.
PCs did use bitmap graphics until including VGA and SVGA, I think wide-spread hardware accelleration came up with the switch from ISA bus to PCI bus (infamously resulting in glitchy mouse arrows in win9x with PCI video cards, unless disabling the accelleration). For slightly newer hardware, I think that the GP32 console was raw software with bitmap graphics, and I have heard about a mobile phone with VGA style graphics and built-in DPAD and buttons for gaming. But that's both about 10 years ago. Most modern hardware will also allow you to write to framebuffers - you don't have to use sprites or polygons or the like, even if the hardware has support for that.
But it may be increasingly difficult to find hardware without unneccessary extras. The hardware devrs today aren't shy of producing chips with 1600 configuration registers, even if one would have squeezed the same functionality into 16 registers a dozen years ago.
Even if you find a video controller without accelleration: I wouldn't be surprised if it would include stuff like brightness, contrast, and gamma adjustment (which alone might amount to a million of per-pixel multiplications per frame). And maybe also built-in MPEG encoding, programmable noise filters, uarts, infrared, usb, spi and i2c busses, backlight managment, flash memory, encryption hardware, thermometers, firmware updates, wifi, bluetooth, and ethernet.
But it may be increasingly difficult to find hardware without unneccessary extras. The hardware devrs today aren't shy of producing chips with 1600 configuration registers, even if one would have squeezed the same functionality into 16 registers a dozen years ago.
Even if you find a video controller without accelleration: I wouldn't be surprised if it would include stuff like brightness, contrast, and gamma adjustment (which alone might amount to a million of per-pixel multiplications per frame). And maybe also built-in MPEG encoding, programmable noise filters, uarts, infrared, usb, spi and i2c busses, backlight managment, flash memory, encryption hardware, thermometers, firmware updates, wifi, bluetooth, and ethernet.
I do wonder what the bare minimum Mhz speed it would take, say an ARM7, to make an NES style game without a graphics chip.
By "NES style" as opposed to "ColecoVision style", you include scrolling, correct? That depends mostly on whether the frame buffer's start address can be relocated to produce scrolling. If hardware scrolling in a dumb frame buffer is allowed, then Commander Keen in Marooned on Mars runs on a PC/AT with an EGA.
Probably not much? I remember playing smooth 60 fps games in 800x600/8bpp on a 30 Mhz 68k Mac with no hardware acceleration. 256x240 is ~1/8th as many pixels.
I’m pretty sure you can put a modern x86 in to real or protected mode and run vga mode-x. What exactly are you looking for?
The subject says "framebuffer", which to me means "a completely linear piece of memory". That rules out bitplane-based models.
Like samophlange, I thought of the standard VGA model on the PC, where you have these two choices:
* Standard VGA mode 0x13, which is 320x200 and 256 colours
* Mode X, which is 320x240 and 256 colours -- offering visually square pixels
* Mode Q, which is mode X but "tweaked", thus 256x256 and 256 colours -- many DOS NES emulators used this (I speak as the author of one!)
All these result in a linear framebuffer of sorts: a single byte of memory represents what pixel (in a palette index of 0-255) to visually show on screen. In real mode, the data is in segment 0xA000 or A000h; in protected mode it's 0xA0000-AFFFF or A0000h-AFFFFh. Example code.
All of this still works on PC architecture today, but of course present-day OSes etc. now inhibit you from doing anything with that memory (the last OS to let you play with it directly was, IIRC, Windows XP for specific DOS applications, using NTVDM).
I suspect the below answers are not what you're asking for/about, but I'll mention them anyway:
If you're wanting something that works with a present-day OS, I'm pretty sure the way this is accomplished (in Direct3D) is by setting up two triangles that thus make a square, and then mapping a texture across both of them -- your linear framebuffer then is that texture memory, which you can access directly IIRC. There's also using a locked RECT surface in D3D9. I believe there's a way to achieve this in Vulkan as well.
As for audio: good frickin' luck! I don't know of very many audio systems that worked that way to begin with. If what you're talking about is akin to, say, the old PC/DOS days with sound cards where there was a linear piece of memory your code was expected to update + tell the soundcard to play it (plus keeping track of where the card was in the buffer) -- and the hardware simply plays (and will loop) what's in the buffer -- AFAIK that is still the same model used today with DirectSound and other audio APIs.
In short, the "old way" of doing things -- the way that's simple and makes a ton of sense, gives the programmer the most control, etc. -- are going the way of the buffalo, replaced by layers and layers of abstraction, complications (no guarantee your code runs at a specific time/interval/whatever), and so on. A lot of this has to do with the fact that people's computer needs changed during the 90s and 2000s, alongside the introduction of multiprocessing. In exchange for the latter, we had to give up a lot.
Edit:
Oziphantom mentioned the Apple IIGS, so I'll talk about that. There's no video hardware acceleration of any kind of the IIGS, except maybe fill mode (you decide):
The IIGS's graphics are a linear framebuffer... kind of. The memory map looks like this:
Bank $E1, $2000-9CFF: pixel data
Bank $E1, $9D00-9DFF: scanline control data
Bank $E1, $9E00-9FFF: palette data
Pixel data represents the literal pixels of the two main video modes (320x200 and 640x200). In 320x200 each pixel is represented by 4 bits (16 colours), and in 640x200 represented by 2 bits (8 colours). I don't want to talk about 640x200 (it's a mess). There is no way to increase the vertical resolution. So on the IIGS, there's always a limit of 16 colours per horizontal scanline, but there's a nuance:
The scanline control data is a 200-byte area that controls what palette each individual scanline uses. Each byte represents a scanline (e.g. $E19D00 = scanline 0, $E19D01 = scanline 1, up to scanline 199). The remaining 56 bytes are unused. The format of the data is:
Bit 7: Graphics mode addressing (0=320x200 mode, 1=640x200 mode)
Bit 6: Generate IRQ when scanline drawn (0=off, 1=on)
Bit 5: Fill mode (0=off, 1=on; only available in 320x200 mode)
Bit 4: Reserved, must be 0
Bits 3-0: Palette number (0-15)
I forget exactly how bit 7 works but again I don't want to talk about 640x200 anyway.
Bit 5 / fill mode is kind of weird but useful in some situation: if the bit is set, any pixel with a value of $0 re-uses the colour of the preceding pixel on that scanline. So if pixel 0 was a value of 4, followed by 9 pixels of value 0, those 9 pixels would show value 4. Also, with fill mode, pixel 0 of that scanline can't be 0, otherwise you get weird behaviour. Many demos used this to achieve certain stuff, like giving the impression of full-screen horizontal text scrolling but with nothing else really visible (there's a demo that did this whose name I forget, else I'd find it for you).
The palette data is 512 byte area that defines what RGB values each pixel of the pixel data displays. There are 16 palettes, with 16 colours per palette; ex. palette 0 = $9E00-9E1F, palette 1 = $9E20-9E3F, etc.. The format of the palette data is as follows, with R/G/B being given 4 bits each:
Bits 15-12: Reserved, must be 0
Bits 11-8: Red
Bits 7-4: Green
Bits 3-0: Blue
So, you tell me -- does that count as a linear framebuffer or not? :P
The IIGS's graphics are kind of weird because of its memory map and backwards-compatibility with the Apple II and its bank shadowing (mirroring) capability and why certain memory accesses are at 1MHz rather than 2.8MHz. I started doing a write-up of it all from reference material, but then about 30 minutes in Googled and found that Eric Shepherd and Andy Mcfadden already explain it, along with just how unexpectedly powerful the IIGS's shadowing registers ($C035 and $C036) are. Eric talks about it but also uses GS/OS toolkit functions (ex. NewHandle) which confuses things a bit, but don't worry about that -- while Andy goes right for the guts. Both of them explain tricks that are used to achieve fast ways to copy data around, like relocating direct page and the stack and using pei copy data quickly (when mirroring bank $00 to $01, which then effectively let you map DP and the stack onto graphics memory). The nop-intermixed-with-pei thing at the end of Eric's reply is primarily a IIGS-specific thing (and even why people often say the IIGS runs at 2.6MHz rather than 2.8MHz). (Maybe me posting all of this gives some insight into why I talk about things like relocating DP all the time...)
All this brings me back to old times, and even reminds me why I loved PC graphics over Apple IIGS graphics so much: 16 colours per scanline really sucked for decent images. While the IIGS's palette-per-scanline thing is neat (and you can actually do a lot of really cool effects with this), you still couldn't display a GIF without applying dithering and so on to try and "make up" for it. The "peak" of displaying still images on the IIGS was what was called "3200 mode", where programs like DreamGrafx and Convert3200 by extending the palette count from 16 to 200 (one palette per scanline) purely by trickery in HBlank and tweaking palettes in real-time (200 scanlines * 16 colours = 3200 colours). You literally have *no* other CPU time available for anything -- I'm not exaggerating in the least -- displaying pictures this way... and you're *still* limited to 16 colours per scanline. I often thought the 3200 mode thing was a farce, and felt incredibly "Apple" in its modus operandi (kind of like false advertising), and was certainly invented out of spite towards PC and Amiga. All you had to do was give a IIGS person a GIF with a >16 colour gradient on a single scanline and laugh; but if the gradient was vertical, yeah, the results look better than a PC. Meanwhile, the Amiga with its HAM mode sat laughing at everyone.
Like samophlange, I thought of the standard VGA model on the PC, where you have these two choices:
* Standard VGA mode 0x13, which is 320x200 and 256 colours
* Mode X, which is 320x240 and 256 colours -- offering visually square pixels
* Mode Q, which is mode X but "tweaked", thus 256x256 and 256 colours -- many DOS NES emulators used this (I speak as the author of one!)
All these result in a linear framebuffer of sorts: a single byte of memory represents what pixel (in a palette index of 0-255) to visually show on screen. In real mode, the data is in segment 0xA000 or A000h; in protected mode it's 0xA0000-AFFFF or A0000h-AFFFFh. Example code.
All of this still works on PC architecture today, but of course present-day OSes etc. now inhibit you from doing anything with that memory (the last OS to let you play with it directly was, IIRC, Windows XP for specific DOS applications, using NTVDM).
I suspect the below answers are not what you're asking for/about, but I'll mention them anyway:
If you're wanting something that works with a present-day OS, I'm pretty sure the way this is accomplished (in Direct3D) is by setting up two triangles that thus make a square, and then mapping a texture across both of them -- your linear framebuffer then is that texture memory, which you can access directly IIRC. There's also using a locked RECT surface in D3D9. I believe there's a way to achieve this in Vulkan as well.
As for audio: good frickin' luck! I don't know of very many audio systems that worked that way to begin with. If what you're talking about is akin to, say, the old PC/DOS days with sound cards where there was a linear piece of memory your code was expected to update + tell the soundcard to play it (plus keeping track of where the card was in the buffer) -- and the hardware simply plays (and will loop) what's in the buffer -- AFAIK that is still the same model used today with DirectSound and other audio APIs.
In short, the "old way" of doing things -- the way that's simple and makes a ton of sense, gives the programmer the most control, etc. -- are going the way of the buffalo, replaced by layers and layers of abstraction, complications (no guarantee your code runs at a specific time/interval/whatever), and so on. A lot of this has to do with the fact that people's computer needs changed during the 90s and 2000s, alongside the introduction of multiprocessing. In exchange for the latter, we had to give up a lot.
Edit:
Oziphantom mentioned the Apple IIGS, so I'll talk about that. There's no video hardware acceleration of any kind of the IIGS, except maybe fill mode (you decide):
The IIGS's graphics are a linear framebuffer... kind of. The memory map looks like this:
Bank $E1, $2000-9CFF: pixel data
Bank $E1, $9D00-9DFF: scanline control data
Bank $E1, $9E00-9FFF: palette data
Pixel data represents the literal pixels of the two main video modes (320x200 and 640x200). In 320x200 each pixel is represented by 4 bits (16 colours), and in 640x200 represented by 2 bits (8 colours). I don't want to talk about 640x200 (it's a mess). There is no way to increase the vertical resolution. So on the IIGS, there's always a limit of 16 colours per horizontal scanline, but there's a nuance:
The scanline control data is a 200-byte area that controls what palette each individual scanline uses. Each byte represents a scanline (e.g. $E19D00 = scanline 0, $E19D01 = scanline 1, up to scanline 199). The remaining 56 bytes are unused. The format of the data is:
Bit 7: Graphics mode addressing (0=320x200 mode, 1=640x200 mode)
Bit 6: Generate IRQ when scanline drawn (0=off, 1=on)
Bit 5: Fill mode (0=off, 1=on; only available in 320x200 mode)
Bit 4: Reserved, must be 0
Bits 3-0: Palette number (0-15)
I forget exactly how bit 7 works but again I don't want to talk about 640x200 anyway.
Bit 5 / fill mode is kind of weird but useful in some situation: if the bit is set, any pixel with a value of $0 re-uses the colour of the preceding pixel on that scanline. So if pixel 0 was a value of 4, followed by 9 pixels of value 0, those 9 pixels would show value 4. Also, with fill mode, pixel 0 of that scanline can't be 0, otherwise you get weird behaviour. Many demos used this to achieve certain stuff, like giving the impression of full-screen horizontal text scrolling but with nothing else really visible (there's a demo that did this whose name I forget, else I'd find it for you).
The palette data is 512 byte area that defines what RGB values each pixel of the pixel data displays. There are 16 palettes, with 16 colours per palette; ex. palette 0 = $9E00-9E1F, palette 1 = $9E20-9E3F, etc.. The format of the palette data is as follows, with R/G/B being given 4 bits each:
Bits 15-12: Reserved, must be 0
Bits 11-8: Red
Bits 7-4: Green
Bits 3-0: Blue
So, you tell me -- does that count as a linear framebuffer or not? :P
The IIGS's graphics are kind of weird because of its memory map and backwards-compatibility with the Apple II and its bank shadowing (mirroring) capability and why certain memory accesses are at 1MHz rather than 2.8MHz. I started doing a write-up of it all from reference material, but then about 30 minutes in Googled and found that Eric Shepherd and Andy Mcfadden already explain it, along with just how unexpectedly powerful the IIGS's shadowing registers ($C035 and $C036) are. Eric talks about it but also uses GS/OS toolkit functions (ex. NewHandle) which confuses things a bit, but don't worry about that -- while Andy goes right for the guts. Both of them explain tricks that are used to achieve fast ways to copy data around, like relocating direct page and the stack and using pei copy data quickly (when mirroring bank $00 to $01, which then effectively let you map DP and the stack onto graphics memory). The nop-intermixed-with-pei thing at the end of Eric's reply is primarily a IIGS-specific thing (and even why people often say the IIGS runs at 2.6MHz rather than 2.8MHz). (Maybe me posting all of this gives some insight into why I talk about things like relocating DP all the time...)
All this brings me back to old times, and even reminds me why I loved PC graphics over Apple IIGS graphics so much: 16 colours per scanline really sucked for decent images. While the IIGS's palette-per-scanline thing is neat (and you can actually do a lot of really cool effects with this), you still couldn't display a GIF without applying dithering and so on to try and "make up" for it. The "peak" of displaying still images on the IIGS was what was called "3200 mode", where programs like DreamGrafx and Convert3200 by extending the palette count from 16 to 200 (one palette per scanline) purely by trickery in HBlank and tweaking palettes in real-time (200 scanlines * 16 colours = 3200 colours). You literally have *no* other CPU time available for anything -- I'm not exaggerating in the least -- displaying pictures this way... and you're *still* limited to 16 colours per scanline. I often thought the 3200 mode thing was a farce, and felt incredibly "Apple" in its modus operandi (kind of like false advertising), and was certainly invented out of spite towards PC and Amiga. All you had to do was give a IIGS person a GIF with a >16 colour gradient on a single scanline and laugh; but if the gradient was vertical, yeah, the results look better than a PC. Meanwhile, the Amiga with its HAM mode sat laughing at everyone.
psycopathicteen wrote:
This one?
This one: https://en.wikipedia.org/wiki/Macintosh_Quadra_650
Maybe more to the OPs question. You can certainly set an RPi up to operate in framebuffer mode, and that definitely has enough CPU power to do all sorts of fancy framebuffer style graphics.
On a lot of modern computers, if you want direct VGA access you can boot into FreeDOS from a USB stick.
If you wanted to get even more minimal you could even write your own bootloader and bypass having an operating system.
Audio other than PC speaker would be a bit more difficult, though, because there aren't really universal protocols for it. The ubiquity of SoundBlaster compatible cards through the late 90s was as good as that ever got, but its time has long passed, and now everything needs drivers. If you've got one, the PC speaker is pretty direct to program, but a lot of newer computers don't include this.
If you wanted to get even more minimal you could even write your own bootloader and bypass having an operating system.
Audio other than PC speaker would be a bit more difficult, though, because there aren't really universal protocols for it. The ubiquity of SoundBlaster compatible cards through the late 90s was as good as that ever got, but its time has long passed, and now everything needs drivers. If you've got one, the PC speaker is pretty direct to program, but a lot of newer computers don't include this.
slembcke wrote:
psycopathicteen wrote:
This one?
This one: https://en.wikipedia.org/wiki/Macintosh_Quadra_650
Maybe more to the OPs question. You can certainly set an RPi up to operate in framebuffer mode, and that definitely has enough CPU power to do all sorts of fancy framebuffer style graphics.
Is this framebuffer just normal RAM, or is it a frame buffer that omits color 0 writes?
There may be AC97 drivers for DOS. But I think AC97 fell out of favor for Intel HD Audio stuff.
psycopathicteen wrote:
Is this framebuffer just normal RAM, or is it a frame buffer that omits color 0 writes?
Not sure I understand the question. It's Linux, so you just mmap() /dev/fb (or something like that, I don't really remember off the top of my head) and treat it like regular memory.
If you're drawing a software sprite do you need to manually mask out transparent pixels, or does the buffer do that for you?
Yes, you need to mask out software sprites. Two ways to speed this up were common in the VGA era: RLE sprites, which stored sprites as runs of transparent pixels and runs of nontransparent literal pixels, and compiled sprites, which turned pixel data into immediate loads and stores. Use of compiled sprites required the frame buffer to be larger than the visible portion by at least one sprite size, as clipping was essentially impossible.
Did Mac computers ever had bullet hell shmups back in the 90s. I'm curious on how far they pushed the limits back then.
Bullet hell didn't become "a thing" until what 96?(although they started in arcades in Japan in what 93?) And even then games on a mac today is still basically a joke proposition and they actually have a market share measured in percentages. An Amiga 1200 would be hard pressed to handle a bullet hell.
slembcke wrote:
psycopathicteen wrote:
Is this framebuffer just normal RAM, or is it a frame buffer that omits color 0 writes?
Not sure I understand the question. It's Linux, so you just mmap() /dev/fb (or something like that, I don't really remember off the top of my head) and treat it like regular memory.
Where you running a custom OS on your Mac?
psycopathicteen wrote:
Did Mac computers ever had bullet hell shmups back in the 90s. I'm curious on how far they pushed the limits back then.
The closest thing I ever saw on the Mac to a shmup was Lunatic Fringe -- which is certainly not a "bullet hell" game (think more like Asteroids but with bitmap graphics not raster). It was also an After Dark screen saver (yes I'm serious -- a game in a screen saver). This would've been roughly 1993-1994. There was another game of a similar type called Maelstrom which I suspect Lunatic Fringe was inspired by.
In general, Macs weren't really used for games of the type you're asking about. There were games but I think most were not really "arcade-y", given MacOS and its overall design (it was more about doing work via GUI and less about "fun"). If you ask Mac folks, I'm sure they'll give you a list of enjoyable games for the system (Myst was one everyone raved about at the time) but not of a shmup genre or even "arcade" genre. Also, please don't forget "good" colour-capable Macs were expensive -- I think starting with the Macintosh II, of which the high-end version could do 256 colours out of a 16.7m palette, and cost something like nearly $6500 once you got the monitor and all common peripherals (the low-end version I believe was 16 colour).
In the late 80s, it made a lot more sense to just go to the local 7-11 or arcade and play arcade games for a quarter. You'd get a lot better experience.
If you ask me, the IIGS was really the last classic Apple system that had a focus on games. Sadly its lack of graphics hardware acceleration (esp. w/ omission of things like screen panning/scrolling) threw it under the bus in comparison to PC and Amiga. That said, you will certainly find many memorable IIGS games, but no shmups -- because everything was CPU-bound. Closest there you'll find is what was called Space Fox (and those status areas at the top/bottom that essentially cropped off the playfield? Strongly needed due to limited CPU time). This is really what set home video game consoles apart from (most) home computers at the time: they had dedicated PPUs for sprites and graphic-related functionality.
Oziphantom wrote:
slembcke wrote:
psycopathicteen wrote:
Is this framebuffer just normal RAM, or is it a frame buffer that omits color 0 writes?
Not sure I understand the question. It's Linux, so you just mmap() /dev/fb (or something like that, I don't really remember off the top of my head) and treat it like regular memory.
Where you running a custom OS on your Mac?
Uh... I thought I was answering aquestion about doing framebuffer programming on a RPi...
koitsu wrote:
In general, Macs weren't really used for games of the type you're asking about. There were games but I think most were not really "arcade-y", given MacOS and its overall design (it was more about doing work via GUI and less about "fun"). If you ask Mac folks, I'm sure they'll give you a list of enjoyable games for the system (Myst was one everyone raved about at the time) but not of a shmup genre or even "arcade" genre. Also, please don't forget "good" colour-capable Macs were expensive -- I think starting with the Macintosh II, of which the high-end version could do 256 colours out of a 16.7m palette, and cost something like nearly $6500 once you got the monitor and all common peripherals (the low-end version I believe was 16 colour).
For clarity, the Quadra 650 I was referring to was from the early/mid nineties, and I used it until the late nineties. It certainly wasn't a $6000 computer.
I was a teenager at the time and had only learned some basics about C. So I don't really know how low-level graphics worked there. I assume you could access the screen as a linear framebuffer if you captured the display. I certainly remember games that had options to disable v-sync with tearing in them.
Also, I sure did have a long list of favorite games.
slembcke wrote:
For clarity, the Quadra 650 I was referring to was from the early/mid nineties, and I used it until the late nineties. It certainly wasn't a $6000 computer.
Macintosh II = RTM March 1987, 640x480x256 @ 16.7m palette, MSRP $5500 (suspect this is still too low for 256-colour model at the time)
Quadra 950 = RTM October 1993, see below, MSRP $2500 (not sure if 512KB or 1MB VRAM model)
Quoting website: by default, the Macintosh Quadra 650 only supports a single display, but a second one can be supported with the addition of a NuBus video card. With 512k of VRAM, the system is capable of supporting 512x384 at 16-bit color, 640x480, 800x600 and 832x624 at 8-bit color, and 1024x768 and 1152x870 at 4-bit color. With 1 MB of VRAM installed, it can support 640x480, 800x600 and 832x624 at 16-bit color and 1024x768 and 1152x870 at 8-bit color.
Polite reminder for others: "shmup" arcades as of said year (1993) were still generally 240x320 @ 2048 palette (vertical layout), on-screen colour number seems to vary per board.
Minor pedantry to be technically correct: Mode-X is not linear.
VGA at the time had a good 256KB of memory, but the window for it was only 64K (segment A000). I'm ignoring the text & monochrome areas at B000 and B800. It dealt with that via a plane selector.
The 16 color EGA modes laid things out such that each byte of plane 0 was bit0 for 8 pixels, plane 1 was bit 1, and so forth. There was a fair amount of extra latches and special read/write modes to help speed up the read-modify-write that involved. You also could tell it to start the frame scanout close to anywhere in there, so you could do hardware page flipping and scrolling. Internally, it could read 4 bytes at a time to feed to the scanout pipeline.
When they decided to add the 8bpp 256 color mode, they wanted to be able to keep the 4 bytes at a time read for scanout going, but also wanted to present it as linear to the programmer. The solution they went with was to add an extra flag to the mode registers for "Chain-4", which would use the low two bits of the address to decide which plane to read/write, and shifted the rest of the address down. Unfortunately, they didn't put in any way to move the base of A000 within the VGA memory, so you were stuck with a single frame worth of accessible data. Among other things, this meant you couldn't do real page flipping (you had to copy 64K of data over in vblank, rather than just changing the base address), and couldn't really use the scrolling support that was built in. It was 320x200 as that was all they could reasonably fit into 64K.
As it turns out, all of the base address, scrolling, etc still worked, but would access portions of vram you couldn't put any data in. Some sneaky fellows found that if you set everything up for 8bpp, but didn't enable Chain-4, you would get access to the full 256KB, and could do page flipping, scrolling, etc, but at a cost -- The planar memory layout was back, so A000:0000 plane 0 was the first pixel on the screen, A000:0000 plane 1 was the second, and so on through plane 3, then plane 0 A000:0001 was the 5th pixel on the screen, and the pattern repeats.
In the end it wasn't quite as terrible as that would seem, as it did allow you do do some other sneaky tricks besides page flipping/scrolling -- the latches still worked, so you could set it up so a byte read would load all 4 planes, and a write elsewhere would write all 4 planes out. This let you do things like get quad-rate speed fills or copies as long as you were OK with it being granular to 4 pixels in X. The naive way of setting the plane, writing a byte, setting the next plane, writing a byte would be egregiously slow though, so you usually had to get creative with your data layout to avoid that at all costs.
This is what a large number of Abrash's graphics programming columns were about, and part of why there were so many graphics libraries to smooth some of those details over at the time.
VGA at the time had a good 256KB of memory, but the window for it was only 64K (segment A000). I'm ignoring the text & monochrome areas at B000 and B800. It dealt with that via a plane selector.
The 16 color EGA modes laid things out such that each byte of plane 0 was bit0 for 8 pixels, plane 1 was bit 1, and so forth. There was a fair amount of extra latches and special read/write modes to help speed up the read-modify-write that involved. You also could tell it to start the frame scanout close to anywhere in there, so you could do hardware page flipping and scrolling. Internally, it could read 4 bytes at a time to feed to the scanout pipeline.
When they decided to add the 8bpp 256 color mode, they wanted to be able to keep the 4 bytes at a time read for scanout going, but also wanted to present it as linear to the programmer. The solution they went with was to add an extra flag to the mode registers for "Chain-4", which would use the low two bits of the address to decide which plane to read/write, and shifted the rest of the address down. Unfortunately, they didn't put in any way to move the base of A000 within the VGA memory, so you were stuck with a single frame worth of accessible data. Among other things, this meant you couldn't do real page flipping (you had to copy 64K of data over in vblank, rather than just changing the base address), and couldn't really use the scrolling support that was built in. It was 320x200 as that was all they could reasonably fit into 64K.
As it turns out, all of the base address, scrolling, etc still worked, but would access portions of vram you couldn't put any data in. Some sneaky fellows found that if you set everything up for 8bpp, but didn't enable Chain-4, you would get access to the full 256KB, and could do page flipping, scrolling, etc, but at a cost -- The planar memory layout was back, so A000:0000 plane 0 was the first pixel on the screen, A000:0000 plane 1 was the second, and so on through plane 3, then plane 0 A000:0001 was the 5th pixel on the screen, and the pattern repeats.
In the end it wasn't quite as terrible as that would seem, as it did allow you do do some other sneaky tricks besides page flipping/scrolling -- the latches still worked, so you could set it up so a byte read would load all 4 planes, and a write elsewhere would write all 4 planes out. This let you do things like get quad-rate speed fills or copies as long as you were OK with it being granular to 4 pixels in X. The naive way of setting the plane, writing a byte, setting the next plane, writing a byte would be egregiously slow though, so you usually had to get creative with your data layout to avoid that at all costs.
This is what a large number of Abrash's graphics programming columns were about, and part of why there were so many graphics libraries to smooth some of those details over at the time.