1) I'd trust the datasheet over a wiki, but I don't have a 5420 to test.
2) If the only benefit from extra RAM was interlaced high-res modes, it probably means that most cards shipped with less than the maximum RAM. Saying that you support 2MB/4MB is probably worth some marketing points though, so if it only costs one extra pin on a chip then why not do it?
3) Some cards had no VESA VBE in the ROM, and included a TSR program instead.
4) Probably none, since the original VGA had 8-bit bus and 32-bit RAM. Some later VGA chips managed to work with only 8-bit RAM (because RAM had gotten fast enough by then) but they all supported 16-bit bus.

noshutdown wrote on 2024-11-20, 05:30:

3.are there any svga cards(supporting 512kb or more ram) with no vesa compatibility at all, and wouldn't run anything higher than vga without univbe?

Not that I know of (they have no VBE BIOS in ROM yet, but can be supported by VBE). 🙁
Even EGA clones did support 800x600 16c and other extended EGA modes.
There's no plain VGA card to my knowledge, except for the ancient IBM adapter.

UniVBE.. UniVBE is a bit overrated, I think.
To my knowledge, it refuses to work with cards have less than 512 KB.
Those cards might be avle to do 800x600 16c (mode 6Ah, 102h) and 640x400 256c (mode 100h, a multiple of 320x200 256c mode13 resolution).
However, this requires SVGA support or use of original VBE TSRs.
Re: OAK OTI-037c - 800x600 mode ?

noshutdown wrote on 2024-11-20, 05:30:

4.which old vga-compatible(not ibm) cards has only 8bit isa bus and 8bit ram?

OAK OTI-037c and that UMC chip seem to be 8-Bit designs, but can do 800x600 16c Super VGA nevertheless.

noshutdown wrote on 2024-11-20, 05:30:

[...]

2.the cl-gd5426/28/29/30 support up to 2mb ram, but (again) according to the cirrus datasheet, they can't support 800*600*24bit or 1024*768*16bit mode(although 5428 and later can support 1024*768*16bit 43hz interlaced which is useless). and even the more powerful 5434 with 4mb ram can't do 800*600*24bit(it can do 800*600*32bit though), only the further optimized 5436 can support it. whats the extra ram for if they can't support higher resolution than the old 1mb 5422?

Not much if that were the case - but it isn't, at least not for the GD543x series.

I'm looking at their datasheet now and it's pretty clear:

CL-GD5430/'34 [...] Resolutions up to 1280x1024 - Up to 1024 x 768 x 64K colors, non-interlaced - Up to 800 x 600 x 16M colors, […]
Show full quote

CL-GD5430/'34
[...]
Resolutions up to 1280x1024
- Up to 1024 x 768 x 64K colors, non-interlaced
- Up to 800 x 600 x 16M colors, non-interlaced
- Up to 1280x1024 x 256 colors, non-interlaced

As it happens a board I bought with GD5430 arrived yesterday. It has 1MB soldered in two SOJ 4Mbit chips and 8 sockets for 1Mbit DIPs. If I can find suitable chips I will test it with 2MB to see if it lives up to that promise.

As for the other GD542x chips - they all share basically the same RAMDAC and memory interface, the differences are in the amount of (Windows) acceleration offered. For DOS they are essentially identical.

3.are there any svga cards(supporting 512kb or more ram) with no vesa compatibility at all, and wouldn't run anything higher than vga without univbe?

There are worse, with no good UniVBE support either. I have some - a couple of VLB cards with IIT AGX016 chips. There are proprietary VESA drivers for the Orchid Celcius and Boca Vortek cards, but they don't work on mine nor does UniVBE meaning zero VESA :'(

4.which old vga-compatible(not ibm) cards has only 8bit isa bus and 8bit ram?

Not sure, but the ATi VGA Wonder definitely had an 8b ISA bus connector. It has 8 64k x 4 DRAM chips for a total of 256kB - but I'm not sure how it's hooked up, that could be anything up to 32b wide if they are all addressed in parallel (probably not...)

Edit: found the manual:

The implementation of both a 16 bit datapath and a 1:1 memory interleave scheme provides the user with fast screen updates.

So 16b with interleaving. Not bad for a 1988 card 😉

What it doesn't say is the clocks involved. The DRAM chips on the one good pic I found are 120ns chips, which means the memory won't be running much past 30MHz at best, probably slower than that.

A more general point: I/O bus width and memory bus width don't necessarily need to be the same, indeed they are commonly different - take the CL-GD5434 with 64b memory access despite being used on 32b (VLB or PCI) or even 16b (ISA) buses. The memory is invariably clocked far higher than the bus. Again taking the CL-GD5434 the core is clocked at 135MHz and memory at 60MHz, whereas the fastest bus it could be connected to would be a 50MHz VLB. That makes sense too, particularly on cards like this using DRAM, which can't be written to and read from at the same time, so even operating as 'dumb' framebuffer, storing whatever it gets from the bus and then being read from the RAMDAC, it needs to have twice the bandwidth of the bus. Add any 'accelerator' functions and that involves more reads and writes to video memory by the VGA chip in between those fundamental ones.

dionb wrote on 2024-11-20, 23:42:

Not much if that were the case - but it isn't, at least not for the GD543x series. I'm looking at their datasheet now and it's p […]
Show full quote

Not much if that were the case - but it isn't, at least not for the GD543x series.
I'm looking at their datasheet now and it's pretty clear:
Resolutions up to 1280x1024
- Up to 1024 x 768 x 64K colors, non-interlaced
- Up to 800 x 600 x 16M colors, non-interlaced
- Up to 1280x1024 x 256 colors, non-interlaced

it does say 800 x 600 x 16M colors, but its 32bpp mode which is a waste of ram, not the more popular 24bpp truecolor. only 5436 can do 24bpp.
can gui accelerators use an extra page for buffering?

I used to see flicker and lousy performance without double buffering. The most glaring example I remember with confidence was a Compaq LTE 5380 laptop, which had a screen that wasn't a good fit for the video RAM size - dropping the res so it could double buffer made it run dramatically better. I think I experienced the same when I pushed a desktop CL-GD5426 1MB card to where it couldn't double buffer - but it's a vague memory from a long time ago.
So I wouldn't be surprised if the video performance of the 1MB cards falls off a cliff above 800x600x8bpp. If that's the case then it would make a good use for the 2MB upgrade.

noshutdown wrote on 2024-11-20, 05:30:

1.according to the cirrus datasheet, the cl-gd5420 can only support up to 256 colors, with no hicolor support. however, some other sources(including dosdays.co.uk and vogonswiki) claimed that it has 15bit internal ramdac. has anyone ever tested it to find out?

I don't have a CL-GD5420, and not sure if this helps any, though in my lab I have the following Cirrus Logics:
- Acumos AVGA1 (CL-GD5401), Acumos AVGA2 (CL-GD5402): neither support 15bpp/16bpp modes, with or without UniVBE.
- Hightech Information System Ltd CL-GD5422 (1MB VRAM): supports up to 800x600 15/16bpp and 640x480 24bpp both with and without UniVBE.
- CL-GD5428 Eval Board and CL-GD5430 (both 1MB VRAM): same as above, up to 800x600 15/16bpp and 640x480 24bpp
- Diamond SpeedStar 64 (2MB VRAM): up to 1024x768 15/16bpp and 800x600 24bpp. For some reason UniVBE disables this 800x600 24bpp mode support.

noshutdown wrote on 2024-11-20, 05:30:

2.the cl-gd5426/28/29/30 support up to 2mb ram, but (again) according to the cirrus datasheet, they can't support 800*600*24bit or 1024*768*16bit mode(although 5428 and later can support 1024*768*16bit 43hz interlaced which is useless). and even the more powerful 5434 with 4mb ram can't do 800*600*24bit(it can do 800*600*32bit though), only the further optimized 5436 can support it. whats the extra ram for if they can't support higher resolution than the old 1mb 5422?

Already from oldest IBM EGA DOS adapter days, it is possible to use the video memory latch register to perform fast memory copies of pixels between VRAM -> VRAM. The newer VESA cards built up on these by offering dedicated VRAM blit functions. See the CL-GD technical manuals that mention "BitBLT engine". So one could have sprite sheets in VRAM and VGA memory latch or the BitBLT engine to perform quick video blits.

Also, many games could use double-buffering, so contain two copies of the framebuffer in memory. And then change the starting address of the video VRAM to flip between the next rendered and displayed frames.

noshutdown wrote on 2024-11-20, 05:30:

3.are there any svga cards(supporting 512kb or more ram) with no vesa compatibility at all, and wouldn't run anything higher than vga without univbe?

To clarify, are you asking for a SVGA adapter that would have >=512KB of VRAM, but that its built-in BIOS would not have VESA support, and the built-in BIOS would not provide any extended SVGA video modes (via the old INT 10h extended entry points) besides the ones that VGA provided, and only initializing UniVBE would provide extra video modes for that adapter?

If that is the case, then the answer is a certain no. The UniVBE project is not "magic", i.e. it cannot provide any new video modes that were not programmed to the adapter register configuration space to be possible from factory. What UniVBE does is it only configures the SVGA adapter to initialize its registers to how they were intended to be used. There did not exist a single company that would have relied on UniVBE to provide their competitive business logic: instead, every vendor would be very sure to add their "higher than vga" modes in a way that could be initialized via other means as well.

In other words, every SVGA adapter that added more memory, would always also add modes by expanding the INT 10h/AH=00h "set video mode" functionality with their own custom video modes. A couple of rare adapters would have a "unlock" register that would need to be flipped first to enable those extended video modes, so as to not accidentally trigger breaking hypothetical VGA compatibility. (although soon after, these unlock registers were deemed redundant, so were dropped in later adapters) Either way, all of this was documented built-in behavior and already available out of the box by the adapter.

noshutdown wrote on 2024-11-21, 01:31:

[...]

it does say 800 x 600 x 16M colors, but its 32bpp mode which is a waste of ram, not the more popular 24bpp truecolor. only 5436 can do 24bpp.
can gui accelerators use an extra page for buffering?

A waste of RAM 32b may be, but that's not the use case here, it's to run 1024x768@16b, which is vastly better for a desktop than what you can do with 1MB, either 800x600@16b (too low res) or 1024x768@8b (really too few colours).

noshutdown wrote on 2024-11-20, 05:30:

1.according to the cirrus datasheet, the cl-gd5420 can only support up to 256 colors, with no hicolor support. however, some other sources(including dosdays.co.uk and vogonswiki) claimed that it has 15bit internal ramdac. has anyone ever tested it to find out?

Yes, I have tested it while compiling my 286 benchmarks using the GD5422 1.10 Win 3.1 drivers - it only has 8-bit output, GD5429 can use the 16-bit modes. Same performance as GD5402 with the modes its supports, GD5429 is ~15% faster with the same drivers.

Don't listen to the frequent misinformation that is posted on these boards about how GD5402/5420/5422/5424 are framebuffer cards - they certainly have partial Win 3.1 acceleration, especially with font rendering and better-than-average blitter performance. Not sure about GD5401 as I don't have a standalone card, only a miro Magic Plus that is currently traveling half-way around the world.

3.are there any svga cards(supporting 512kb or more ram) with no vesa compatibility at all, and wouldn't run anything higher than vga without univbe?

My Realtek RTG3102 and RTG3103 cards explode when trying any resolution that requires >=512KB of RAM, despite having 512KB installed. I'm not sure if it's an issue specific with capturing via my OSSC, but from what I recall it spits out a very non-standard refresh rate when using 640x480x256. There's a dipswitch that controls whether it boots in EGA or VGA mode, and that changes to yet another non-standard refresh rate. They do appear to function with the RTG3105 Win 3.1 drivers in that it's possible to get a desktop and you can see icons. They have no UniVBE support, but there is a Realtek VESA TSR that supports VBE 1.0.

I am aware of another chipset that has no UniVBE support and no known drivers, and my attempt to buy one from an eBay seller had backfired when they decided to accept my offer, suddenly wanted another $5 and cancelled the purchase. I haven't followed up on that one yet.