I mean there's always room for some improvement, especially decades later, but the primary bottleneck historically was the bus itself. Even designs that had little to no optimization showed massive gains moving to VLB. I doubt there's really all that much left to wring out.

There will be maximum permissible performance metrics tied to the speed of the bus.

Short of doing something real extreme, like making said isa card into a system-on-board or 'board based cpu upgrade card', or building it as a radical interposer or something (the latter defacto ceasing to be ISA at that point), you can compute the max possible screen redraw speed from first principles of the ISA bus:

33mhz, 16 bits wide, with caveats for any waitstates in the system, and the kinds of raw memcopy instructions the cpu supports (which limits the cycles needed per memory write)

You could likely make a very performant ISA card out of what would essentially be an FPGA and a DAC... (with the video ram part of the synthesised core, for maximal speed by making latency as close to 0 as possible), but it will never exceed the theoretical 'raw copy' limits.

If you wanted to cheat, though, you could make a 'system on board' solution, and essentially contain "the bus" the video card lives on, along with the CPU, all inside the fpga as part of the synthesized core.

It could be a full 32bits wide datapath with cache coherency with the 'cpu', and a couple other radical things that way, while 'behaving' (from a software interface/io port pov) like an ISA card.

Just be aware, you have wandered VERY FAR from "isa video card" territory with such musings.

wierd_w wrote on 2024-04-07, 13:38:

There will be maximum permissible performance metrics tied to the speed of the bus. […]
Show full quote

There will be maximum permissible performance metrics tied to the speed of the bus.

Short of doing something real extreme, like making said isa card into a system-on-board or 'board based cpu upgrade card', or building it as a radical interposer or something (the latter defacto ceasing to be ISA at that point), you can compute the max possible screen redraw speed from first principles of the ISA bus:

33mhz, 16 bits wide, with caveats for any waitstates in the system, and the kinds of raw memcopy instructions the cpu supports (which limits the cycles needed per memory write)

You could likely make a very performant ISA card out of what would essentially be an FPGA and a DAC... (with the video ram part of the synthesised core, for maximal speed by making latency as close to 0 as possible), but it will never exceed the theoretical 'raw copy' limits.

If you wanted to cheat, though, you could make a 'system on board' solution, and essentially contain "the bus" the video card lives on, along with the CPU, all inside the fpga as part of the synthesized core.

It could be a full 32bits wide datapath with cache coherency with the 'cpu', and a couple other radical things that way, while 'behaving' (from a software interface/io port pov) like an ISA card.

Just be aware, you have wandered VERY FAR from "isa video card" territory with such musings.

Am I remembering this incorrectly but isn't ISA closer to 8-12 mhz? I know PCI ran at 33 so that's an easy place for the way back machine to get its wires crossed.

Bluurp. Yeah.

4.77 for XT
6 for early 286
8 for 386(+)

Regardless, this is going to impose very real limitations on theoretical raw-write thruput to a framebuffer.

The best you can do with ISA - is to not treat the video memory as a framebuffer where you write bytes.

If you put some megabytes for textures / sprites / spatial structures, add some acceleration algorithms on the card's side to build up the needed actions that alter the representation of those piles of data that the card will be hosting in its own ram - then you can do great things.

I.e. forget the idea framebuffer, embrace/invent new ideas that revolve around manipulating the onboard data.
Probably worth exploring only as part of recreational activities, because it's not gonna make existing software run any better.

That's just reinventing sprites, tiling and blitting?

(In which you have bitmap data inside the card's memory in some capacity, (sprites, tiles) that you can instruct the card to do bitwise computations or transforms on (bitblt).)

Of course you can create a whole new video presentation engine, it just wont work with existing software that expects a dumb framebuffer with a programmable palette. (Like vga is)

wierd_w wrote on 2024-04-07, 16:02:

Bluurp. Yeah. […]
Show full quote

Bluurp. Yeah.

4.77 for XT
6 for early 286
8 for 386(+)

Regardless, this is going to impose very real limitations on theoretical raw-write thruput to a framebuffer.

vstrakh wrote on 2024-04-07, 16:10:

The best you can do with ISA - is to not treat the video memory as a framebuffer where you write bytes. [..]

That reminds me of that 4,77 MHz CGA PC with additional MSX2 sound and graphics.

Re: What hasn’t been done?

The Yamaha V9938 VDP was an intelligent chip and the fact that it worked fine with Z80 system means that any PC will be powerful enough to drive it.

https://www.msx.org/wiki/Category:VDP

By the time you add graphics to the board, then extra RAM to the board because the ISA is too slow, then maybe another x86 CPU to the board because the ISA is too slow, and move another couple of things to the board because ISA is too slow... you may as well be using a Powerleap Renaissance https://www.cpushack.com/UpgradeProcessors.html#PowerLeap

I am not trying to be funny, but that is seriously the kind of thing you end up with if you keep adding to the board just this one more thing, because ISA is too slow.

But the real reason not to bother in case you missed it, is because ISA is too slow.

vstrakh wrote on 2024-04-07, 16:10:

The best you can do with ISA - is to not treat the video memory as a framebuffer where you write bytes. […]
Show full quote

The best you can do with ISA - is to not treat the video memory as a framebuffer where you write bytes.

If you put some megabytes for textures / sprites / spatial structures, add some acceleration algorithms on the card's side to build up the needed actions that alter the representation of those piles of data that the card will be hosting in its own ram - then you can do great things.

I.e. forget the idea framebuffer, embrace/invent new ideas that revolve around manipulating the onboard data.
Probably worth exploring only as part of recreational activities, because it's not gonna make existing software run any better.

You've just reinvented TIGA.

vstrakh wrote on 2024-04-07, 16:10:

The best you can do with ISA - is to not treat the video memory as a framebuffer where you write bytes. […]
Show full quote

The best you can do with ISA - is to not treat the video memory as a framebuffer where you write bytes.

If you put some megabytes for textures / sprites / spatial structures, add some acceleration algorithms on the card's side to build up the needed actions that alter the representation of those piles of data that the card will be hosting in its own ram - then you can do great things.

I.e. forget the idea framebuffer, embrace/invent new ideas that revolve around manipulating the onboard data.
Probably worth exploring only as part of recreational activities, because it's not gonna make existing software run any better.

Already done.

Many cards, especially those with windows acceleration functions already do this. Some functionality is exposed and can be utilised in DOS, but as you have stated - it doesn't make existing software run any better.

If you want to see an example of an API which can use features such as:

- double/triple buffering using on-card memory and moving the display window rather than copying the framebuffer
- vram to vram blits
- bitmap blits with transparency (i.e. sprites)
- hardware accelerated fills, lines etc
- hardware cursor

... then you can take a look at Allegro; these and other features are exposed by the graphics back-end, and automatically sped up if you have a card which can support them.

Unfortunately, the number of cards with a DOS driver (which really means VBE/AF) is vanishingly small, as pretty much everyone had moved to Windows when the standards got finalised. It *does* work though, if you have a card with those features and a VBE/AF (aka FreeBE) driver to expose them.

However, even without VBE/AF support, copying graphics assets into off-screen areas is a pretty common means of getting around the relatively slow ISA bus, as long as you have enough video memory.

With an excess of CPU power, say a pentium, it would maybe be possible to have a compression driver and hardware decoder on the card to get throughput approaching 32bit, but the number of Pentium systems with only ISA bus that I can think of, can be counted on the fingers of one elbow.

Cornerstones high resolution ISA cards outperformed pretty much everything in Windows, so 2d windows acceleration could get moderately advanced.

At this point, we could as well include PGA, 8514/A and XGA or XGA-2.

"The 8514 had used a standardised API called the "Adapter Interface" or AI.
This interface is also used by XGA, IBM Image Adapter/A, and clones of the 8514/A and XGA such as the ATI Technologies Mach 32 and IIT AGX.

The interface allows computer software to offload common 2D-drawing operations (line-draw, color-fill, and block copies via a blitter) onto the hardware.

This frees the host CPU for other tasks, and greatly improves the speed of redrawing a graphics visual (such as a pie-chart or CAD-illustration).[2][3]

Hardware-level documentation of the XGA was also made, which had not been available for the 8514/A.[3]"

https://en.wikipedia.org/wiki/Extended_Graphi … _Array#Features

To my understanding, though, 8514/A was about the only one to have mattered in practice.
It was being supported by OS/2 1.x out-of-box, for example.
There also was a Mahjongg game for DOS using it.

Edit: Borland's BGI had an 8514/A driver (IBM8514.BGI), too.
Not sure if it had any acceleration, though.
http://www.thealmightyguru.com/Wiki/index.php … phics_Interface

TIGA was really fascinating, but required a DOS driver tied to a specific graphics board.
The TIGA setting in Windows 3 Setup merely is an middle-ware thing talking to the DOS driver.

8514/A was a bit different, since it had software emulators, too.
Some driver disks of the overly popular ET4000 card comes with such an emulator, for example.

XGA and XGA-2 were never really important, outside of a corporate environment, I assume.
It had been hyped for a year or two in magazines of the early 90s, then went away.

PGA had been used in the 80s, apparently, but it had been very niche, too.
A few VGA or Super EGA cards or CAD graphics cards had incorporated the functionality of it.
Except for that 8086 code execution feature. A real IBM PGA could run 8086 code, due to its 8088 processor.

BitWrangler wrote on 2024-04-07, 16:26:

By the time you add graphics to the board, then extra RAM to the board because the ISA is too slow, then maybe another x86 CPU to the board because the ISA is too slow, and move another couple of things to the board because ISA is too slow... you may as well be using a Powerleap Renaissance https://www.cpushack.com/UpgradeProcessors.html#PowerLeap

I expected with this intro you will end at the IBM PGC. This card was built with a dedicated 8088 on the card, because the 8-bit XT bus was too slow. It wasn't even called ISA at that time, but it was dead slow (because the 8088 bus interface is dead slow, not because IBM messed it up - except if you call choosing the 8088 over the 8086 "messing it up").

If you look at the benchmarks at https://www.vgamuseum.info/index.php/benchmarks , you can see that the ISA graphics cards plateau to a max cap quite noticeably:

These best ISA graphics cards (and motherboards) had perfected the minimum number of ISA bus cycles needed to undertake 8-bit and 16-bit bus writes, which is why you see several ISA graphics cards acquire exactly identical performance.

The only way to make ISA graphics effectively faster is to overclock the ISA bus to a faster clock speed. This is commonly done when overclocking, see e.g. this really nice Necroware video: https://www.youtube.com/watch?v=rZcAo4oUc4o

The other natural way to make ISA graphics faster would be to move 2D sprites over to graphics memory, and add 2D graphics acceleration (2D blitting) capabilities - which is exactly what the ISA graphics cards did in the era with all their 2D GUI acceleration mechanisms.. just that those were never standardized well, and required writing code that specifically targeted them.

Today it would of course be possible to create much more complex 2D blitting acceleration functionalities into an ISA graphics card in a way that could accelerate 2D performance even on the 4.77 MHz XT PC.. but that would require writing the custom code as well, so not particularly exciting, except maybe for a very specific subset of retroists.

Only practical thing that can be done is overclocking ISA bus from 8MHz to as far as the components allow. All else will require all new software etc. which will never be made, you want all of this to play the games that already exist 🤣

I run ISA at 13.3MHz on one 386 I have, depending on how CPU bound a game it, it can bring quite a bit of extra framerate and it also will speed up disk IO if the HDD/CF/etc. connected won't mind faster timings. The later ISA video chipsets like WD90C30 etc. are capable of running at much greater throughput than ISA can give, even when overclocked dramatically, it is the low hanging fruit very much.

clb wrote on 2024-04-07, 20:40:

Today it would of course be possible to create much more complex 2D blitting acceleration functionalities into an ISA graphics card in a way that could accelerate 2D performance even on the 4.77 MHz XT PC.. but that would require writing the custom code as well, so not particularly exciting, except maybe for a very specific subset of retroists.

But why even try ? Isn't the PC/XT platform supposed to be slow?
In all those years visiting forums, I got the impression that it's like with the 6502/6510 and the C64, that users enjoy that experience.

Also, 8088 and original PC bus are tightly being linked to each other. They're both equally being capable (or tje lack thereof).

In principle, the AT bus wasn't required to be as much of an bottleneck, since the 80286 front side bus wasn't so slow to begin with.

However, backwards compatibility with the older architecture (IRQ, DMA, 8-Bit i/o, ~14 MHz clock pin) and existing PC cards caused performance penalties.

I still wonder what the PC/AT could have been capable of if it had been equipped with more modern DMA controllers and bus mastering functionality,
and a non-"defective" i/o port range (ISA duplicates/aliases the old PC/XT port addresses over and over again) .

Some sort of Nubus+PC/AT hybrid would have been interesting. 😃

Edit: Never mind. It was more of a rhetorical question. I was thinking out loud here.

To answer the question for myself, I think that some game engines could be patched to take advantage of a new graphics system.
But that would be a solution to a very niche group of users, I suppose.

That Spectravideo PC with MSX2 VDP I mentioned previously had gotten some MSX game ports to DOS platforms, so it's slightly more than just a tech demo .
About 3-5 games in Spanish language supported the enhanced graphics, I think.

Edit: Mainly games made by Telarium, it seems.
https://museo8bits.com/ficha.php?nombre=svi838

Jo22 wrote on 2024-04-07, 21:05:

However, backwards compatibility with the older architecture (IRQ, DMA, 8-Bit i/o, ~14 MHz clock pin) and existing PC cards caused performance penalties.

The 14MHz clock pin is not related to bus performance at all. No bus cycles are synchronized to that pin (except, of course, if the system clock happens to be synchronized to that pin, like on the PC/XT).

Jo22 wrote on 2024-04-07, 21:05:

I still wonder what the PC/AT could have been capable of if it had been equipped with more modern DMA controllers and bus mastering functionality,
and a non-"defective" i/o port range (ISA duplicates/aliases the old PC/XT port addresses over and over again) .

The AT mainboard may duplicate its mainboard resources to 400h, 800h, C00h and so on, but the AT mainboard has nothing that inhibits I/O address 7FEh to be different from I/O address 3FEh. The issue is just old cards ignoring the top I/O bits. Furthermore, the AT had bus mastering functionality, and it was used by the AHA-1542. OTOH, you are completely correct that the DMA controller on the AT is not be taken seriously. The fact that IBM decided to use PIO instead of DMA for the AT MFM hard disk controller is a clear sign that even IBM was aware that 3rd-party ISA DMA on the AT does not really make sense.

Later, it turned out to be very convenient that early boards reserved all the aliases of the mainboard I/O range 00..0FFh for themselves, because that allowed PCI to assign all those alias addresses to PCI cards without being afraid of causing conflicts with legacy ISA cards. PCI mainboard do not mirror their mainboard resources. Even earlier, EISA already used this idea by placing the EISA configuration space at 0C00h, 1C00h, 2C00h and so on.

mkarcher wrote on 2024-04-07, 21:24:

Jo22 wrote on 2024-04-07, 21:05:

However, backwards compatibility with the older architecture (IRQ, DMA, 8-Bit i/o, ~14 MHz clock pin) and existing PC cards caused performance penalties.

The 14MHz clock pin is not related to bus performance at all. No bus cycles are synchronized to that pin (except, of course, if the system clock happens to be synchronized to that pin, like on the PC/XT).

Hm. I wouldn't say "not related to bus performance at all."

Higher end XTs derived from an ~28 MHz crystal or crystal oscillator rather than ~14 Mhz. On the motherboard, I mean. Not the pin.

Edit: Source : https://www.dosdays.co.uk/topics/xt_mobos.php
(The ~28 MHz clock was handy for Turbo button use, I assume.)

I mean, sure, speed wise, those ~14 MHz would be good enough for expansion cards.

However, digital divider components/circuits not only work as dividers, but as a side effect also work as some sort of signal cleaners (=provide TTL signals in square shape) .

So always dividing a signal from a master clock is (was) considered good practice, I suppose.
And with an ~28 MHz or higher clock, this can be done.

Anyway, my point is another one. It's about the architecture as such, rather.
It's not about some details here and there.
The 80286 front side bus pretty much is available via ISA, but some legacy parts of the PC/XT architecture remain.
Things like wait states, recovery times, electrical specs and so on.

That's one reason as to why later 80286 systems did hide behind a chipset, rather than driving ISA bus natively.
The ISA bus quickly fell behind to what later 80286 CPUs had been capable of.

Edit: Thanks about the PCI and EISA part, I didn't know this before. 🙂👍