i've seen many old monitors with issues on 512x384 so that'd probably be too risky to support.

320 x 240 x 256 is perfectly possible on a standard VGA, only there's no BIOS support.
I guess the problem with that mode was: it didn't fit in a single 2^16 segment.

400 x 300 x 256 and 512 x 384 x 256 were even heavier, of course.

320 x 200 x 256 = 64000 Bytes, about the max for 16-bit segment.

It was 1993 - or even later - when PC games went 32-bit.
When the 64 KB segment limit disappeared, there came the need for >64 KB video modes...

leileilol wrote on 2025-02-18, 06:48:

i've seen many old monitors with issues on 512x384 so that'd probably be too risky to support.

Can't work properly on standard VGA monitors, indeed.

But it should work fine on all SVGA monitors:
- if it can do interlaced 1024 x 768, it can do non-interlaced 384-line modes
- if it can do non-interlaced 1024 x 768, it can do double-scanned 384-line modes

compact Macs like the 128K, 512Ke, SE,SE/30 and classic is 512x384

Cheers,

pentiumspeed wrote on 2025-02-18, 16:16:

compact Macs like the 128K, 512Ke and classic is 512x384

512 x 342.
Monochrome.
21888 Bytes needed for the framebuffer.
A completely different order of magnitude compared even with the early SVGA.

My little Tandy 1000rlx with a normal VGA monitor could handle
320x240
360x240

It may have even handled one of the kitty whumpus modes where the vertical was higher res than horizontal. (320x400 ?)

I remember playing Ken’s Labyrinth all the time and never had performance issues. (Rose tinted glasses)

rmay635703 wrote on 2025-02-18, 18:12:

It may have even handled one of the kitty whumpus modes where the vertical was higher res than horizontal. (320x400 ?)

The most extreme aspect ratio generatable by a standard VGA in a standard VGA video frame would be 320x480 (at 60Hz), not counting "fake modes" like the CGA 100x160 16-color pseudo-graphics mode. That approach also works on VGA at 100x480. Also not counting software pixel doubling, of course. Your suggestion of 320x400 is more eye-friendly at 70 Hz. The highest possible resolution generatable by a standard VGA in a standard video frame would be 720x480 at 16 colors or 360x480 at 256 colors.

mkarcher wrote on 2025-02-18, 18:27:

rmay635703 wrote on 2025-02-18, 18:12:

It may have even handled one of the kitty whumpus modes where the vertical was higher res than horizontal. (320x400 ?)

The most extreme aspect ratio generatable by a standard VGA in a standard VGA video frame would be 320x480 (at 60Hz), not counting "fake modes" like the CGA 100x160 16-color pseudo-graphics mode. That approach also works on VGA at 100x480. Also not counting software pixel doubling, of course. Your suggestion of 320x400 is more eye-friendly at 70 Hz. The highest possible resolution generatable by a standard VGA in a standard video frame would be 720x480 at 16 colors or 360x480 at 256 colors.

I’m pretty sure my system at least couldn’t handle 360x480, I don’t remember what program had a laundry list of modes but that one wouldn’t work, even on my 1mb cirrus svga 486 system it seems like it didn’t like that mode.

Oddly even though the 1000rlx only had 256k the video chip was technically a very basic svga implementation with a crippled bios that locked out 800x600x16

mkarcher wrote on 2025-02-18, 18:27:

rmay635703 wrote on 2025-02-18, 18:12:

It may have even handled one of the kitty whumpus modes where the vertical was higher res than horizontal. (320x400 ?)

The most extreme aspect ratio generatable by a standard VGA in a standard VGA video frame would be 320x480 (at 60Hz), not counting "fake modes" like the CGA 100x160 16-color pseudo-graphics mode. That approach also works on VGA at 100x480. Also not counting software pixel doubling, of course. Your suggestion of 320x400 is more eye-friendly at 70 Hz. The highest possible resolution generatable by a standard VGA in a standard video frame would be 720x480 at 16 colors or 360x480 at 256 colors.

I think same. PV, CShow and 2Show (CompuShow 2000) provide such weird resolutions, I think.
And not all of them are exactly pretty, though. Although I'm not sure if standard 320x200@256c can really be beaten in terms of its ugliness.
A blurry CRT TV from the 1970s is probably best companion to stock mode 13h.
A variant, 320x400, is more visually appealing. It's been described here (I'm not affiliated): https://www.phatcode.net/res/224/files/html/ch31/31-01.html

noshutdown wrote on 2025-02-18, 03:47:

many of you may have been aware of a 360x480x256c mode, which seems odd but may have been derived from 720x400x16c text mode, using 28mhz crystal, and fits within 256kb of ram(each page takes ~170kb so no pageflip for 256kb ram). i think cirrus5320 is the only card with 256kb max that mentioned it in the datasheet, but vgamuseum benchmark showed that many cards with 256kb max could run quake in this mode.

The 360x480x256c mode works on every VGA-compatible card with any kind of VGA or SVGA monitor. Deriving it from the text mode is possible, but would require re-programming the vertical cycle from 400 to 480 lines. I'd rather derive it from the 640x480 graphics mode, changing the clock to 28MHz and re-programming the horizontal cycle to 720 pixels, and then switch from 16 colors to 256 colors. In the end, the amount of re-programming the card is very similar, and some software may have opted to initialize this mode completely without BIOS assistance by setting up all registers manually.

The biggest issue with all 256-color modes above 320x200 is the organization of video memory. The EGA/VGA technology uses very intricate hacks to map an 8-bit host bus (EGA was designed for the XT!) to a 32-bit memory bus, making the whole 64K words (of 32 bits each) visible in the 64K EGA map at A000-AFFF. The 320x200x256 mode on the VGA card is very convenient by (a) providing a flat view on the 64000 bytes of video memory actually used for that mode and (b) easily allow 16-bit and 32-bit data transfers on wider busses than the XT bus. The downside is that this mode does not allow page flipping, as only 64KB of video memory is visible - and that's where the complicated hacks come in. You can disable the "just show me a flat view of 64KB" mode and return to the EGA memory view to access all memory. This way to access the full video memory in 256-color mode is commonly called "Mode X". Whether "Mode X" also specifies a certain resolution, or just the memory access mode depends on who you ask. If "Mode X" is associated with a specific resolution (IIRC 320x200 with page-flipping or 320x240), you often also find the name "Mode Y" for a different resolution (360x480?). Some operations are faster in Mode-X-type modes, especially drawing long horizontal lines of a fixed color (and by extension drawing rectangles, and by further extension clearing the screen), as well as copying data inside video memory. "Accelerated" copying data inside video memory was very interesting on 8-bit EGA cards, but usually is worse than just re-copying from system memory on modern 16-bit cards (CL-GD542x, TVGA-8900D, ET4000). On the other hand, just drawing bitmaps is more complicated on that mode, and Mode X is very unfriendly to 16-bit or 32-bit video memory access, so Mode X typically is slow.

So for SVGA cards with banking and flat-memory 256-color modes, providing even the standard VGA tweaked like 320x240 or 360x480 as VESA modes would have made a lot of sense. IIRC Quake 1 is very happy to use them on VESA-2.0-capable cards that provides them, and they are usually faster than the Mode-X based variants of those resolutions.

noshutdown wrote on 2025-02-18, 03:47:

this led me to several low resolution vesa modes that could have been useful(rather than 360x480x256c with odd aspect ratio), all used in quake2 as standard, why weren't they developed by vga chip vendors early?

SuperVGA cards just competed on the resolutions they could run Windows 3.1 or AutoCAD on, not on gaming modes. People didn't care about low-res Super-VGA modes when VESA modes were specified. They started to care slightly when high-color and true-color arrived, because early cards could only handle them at low resolution. So we face the usual chicken-and-egg issue here: Hardware didn't provide low-res 256-color modes, so no software was developed for them. OTOH, as there was no software demand, VGA vendors didn't care about implementing them in their BIOS.

noshutdown wrote on 2025-02-18, 03:47:

can be derived from 1024x768x16c mode using 45 or 65mhz crystal.
con: slower, 1024x768x16c crystals only started to appear on 512kb cards.

I've seen a couple of SVGA cards that had a 44.9 crystal at 256KB, and did 1024x768 at 4 colors with it.

rmay635703 wrote on 2025-02-18, 18:37:

Oddly even though the 1000rlx only had 256k the video chip was technically a very basic svga implementation with a crippled bios that locked out 800x600x16

Actually, being a basic VGA implementation is helpful here. The 360x480 modes only uses features that the original IBM VGA contained, so any clone that is very close to the original (and shares all the drawbacks like only having an 8 bit host bus) has absolutely no trouble operating in that mode. On the other hand, modern chipsets that focus more on performance in SVGA modes than on compatibility with obscure, undocumented modes of the IBM VGA may have issues with that mode.

SuperVGA cards just competed on the resolutions they could run Windows 3.1 or AutoCAD on, not on gaming modes.
People didn't care about low-res Super-VGA modes when VESA modes were specified.

Plain mode 13h was supported on Windows 3.0 MME, however. (sigh!)
There's a DLL, dispdib.dll, which technically allows writing directly to screen.

https://betawiki.net/wiki/Windows_3.0_with_Mu … .0#New_features

An alternative was SciTech's WinDirect API, I think.
It allows using VBE access from within Windows 3.1x applications.
Using ModeX is possible, too, maybe.

mkarcher wrote on 2025-02-18, 18:50:

I've seen a couple of SVGA cards that had a 44.9 crystal at 256KB, and did 1024x768 at 4 colors with it.

Oh yeah, one of the weirdest modes ever.

Actually, I suspect that any card with an appropriate clock source can provide that mode.
There must be some circuitry supporting 4-color modes even in standard VGA, for the basic CGA compatibility - and it's logical it can be enabled in high-res as well.

Providing BIOS support for such modes, however, is strange - was there ever any software actually using it?

Grzyb wrote on 2025-02-18, 19:39:

Actually, I suspect that any card with an appropriate clock source can provide that mode.
There must be some circuitry supporting 4-color modes even in standard VGA, for the basic CGA compatibility - and it's logical it can be enabled in high-res as well.

Actually, it's not the CGA 4-color mode that is used as base for the 1024x768/4color mode, but the EGA 640x350 4-color mode for the IBM EGA with just 64KB of RAM. The original EGA had 4 banks of 64KB (16Kwords of 32 bits, built from 8 16K x 4 chips) each, with one bank on the EGA base board and 3 more banks on the optional memory expansion board. The CGA 4-color mode as it is implemented on EGA/VGA can only use 16 bits of each 32-bit word, so it is not useful for cramming 1024x768 pixels into 256KB.

mkarcher wrote on 2025-02-18, 21:18:

Grzyb wrote on 2025-02-18, 19:39:

Actually, I suspect that any card with an appropriate clock source can provide that mode.
There must be some circuitry supporting 4-color modes even in standard VGA, for the basic CGA compatibility - and it's logical it can be enabled in high-res as well.

Actually, it's not the CGA 4-color mode that is used as base for the 1024x768/4color mode, but the EGA 640x350 4-color mode for the IBM EGA with just 64KB of RAM. The original EGA had 4 banks of 64KB (16Kwords of 32 bits, built from 8 16K x 4 chips) each, with one bank on the EGA base board and 3 more banks on the optional memory expansion board. The CGA 4-color mode as it is implemented on EGA/VGA can only use 16 bits of each 32-bit word, so it is not useful for cramming 1024x768 pixels into 256KB.

You’re not living until you’ve done 1600x1200 in monochrome. Sadly it was a fixed frequency card

rmay635703 wrote on 2025-02-19, 02:49:

You’re not living until you’ve done 1600x1200 in monochrome. Sadly it was a fixed frequency card

Oh-ha! I suppose that was useful for running GEM on Atari ST (for Cubase etc) or running XFree86 display server on *nix. :)

Btw, I just remembered an old thread in which I've posted some comparisons many years ago.
Resolutions are 320x200@256c vs 640x480@16c vs 360x480@256c. Screnshots taken in emulator.
It's not much, but maybe helps visualizing the differences.
Re: VGA custom resolution

Another one has screenshots taken with an real VGA CRT monitor.
Resolutions are 320x200@256c vs 320x400@256c vs 640x480@256c vs 360x480@256c.
Re: Home Computer - was it a toy or a Personal Computer for the masses?

Unfortunately, 640x400@256c is missing. It was popular on Paradise PVGA and worked with stock 256KB of RAM (I've checked).
A nice side effect of that resolution is that it's a multiple of 320x200,
uses 70 Hz and works with fixed-frequency monitors - just like 640x480 would.
Well, unless the VGA card in particular does funny things..

640x400@256c was also being used by VBE mode 100h, but Cirrus (?) cards didn't support it.

Another funfact: PC Player Benchmark defaults to 640x400@256c, unless being overriden with VGA switch that about everyone uses (mode 13h).
There's also a compatibility switch to use 640x480@256c as an alternative, in case 640x400@256c is unavailable.

PS: Yardemo runs in 320x400 256c. "And it's possible on every VGA"
https://youtu.be/F3mikF1bUT4?t=80

rmay635703 wrote on 2025-02-19, 02:49:

You’re not living until you’ve done 1600x1200 in monochrome. Sadly it was a fixed frequency card

Yes, hi-res monochrome was very useful for DTP.
No need for color when the final result is supposed to be a black-on-white printout, and it's natural for a mono monitor to have 3x more pixels than its color counterpart.

But I'm struggling to find any use for hi-res 4-color modes...
I'm struggling to recall any software with such an option, but can't...

Grzyb wrote on 2025-02-20, 06:38:

Yes, hi-res monochrome was very useful for DTP. No need for color when the final result is supposed to be a black-on-white print […]
Show full quote

rmay635703 wrote on 2025-02-19, 02:49:

You’re not living until you’ve done 1600x1200 in monochrome. Sadly it was a fixed frequency card

Yes, hi-res monochrome was very useful for DTP.
No need for color when the final result is supposed to be a black-on-white printout, and it's natural for a mono monitor to have 3x more pixels than its color counterpart.

But I'm struggling to find any use for hi-res 4-color modes...
I'm struggling to recall any software with such an option, but can't...

The 256k 1600x1200 Monochrome screen combos I encountered were from local banks, no idea what software but I assume even in the 80’s a large hi res screen was useful for bank stuff and broadly finances.

Macintosh had 4 color OS support pretty late in their existence stemming from Various Mac 2 era hi res equipment .

The 4 color scheme was extremely strange as well . Black White Yellow????

Never could identify what adapters/screens drove 4 color support in late 80’s MAC 2 and FX hi res land.

Besides a little color pop for a menu I would think 4 grayscales would be more usuable.

I have noted 4 color modes using the primaries, quite garish but you could dither for the basic 6 colors sans grayscales

Grzyb wrote on 2025-02-20, 06:38:

But I'm struggling to find any use for hi-res 4-color modes...
I'm struggling to recall any software with such an option, but can't...

Classic 2D CAD software really likes high resolutions, and you don't need that many colors. Having black, white, a color to highlight some kind of selection seems good enough for basic operation. Specifically, the Xilinx XACT FPGA design software, which has a user interface philosophy similar to 2D CAD programs, uses four colors by default (even in 16-color modes), but can optionally be switched into 8-color or 16-color operation.