QuantumII
Veteran Member
Heh, a 386 is a bit faster than an XT you know
The (small) hardware overhead is probably not noticeable on a 386.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
True CGA vs VGA card in CGA mode
- Thread starter QuantumII
- Start date
Heh, a 386 is a bit faster than an XT you know
The (small) hardware overhead is probably not noticeable on a 386.Heh, a 386 is a bit faster than an XT you know
If you're curious, it's a 386SX/20 with a 16-bit Oak VGA card. It has an AMI BIOS that lets you set the turbo off speed to 4, 6, 8, or 10 Mhz.
per
Veteran Member
Do you know if it is using OTI-67 chipset, and if it is the wide or narrow version of the card?
The problem migh just be something as simple as the card is not optimalized when running in an 8-bit ISA slot.
Could you try to move the card to an 8-bit ISA slot?
QuantumII
Veteran Member
It's like this one:
http://cgi.ebay.com/Oak-Tech-OTIVGA...ptZLH_DefaultDomain_0?_trksid=p3286.m20.l1116
Alas, this 386 has no 8-bit slots. If it did, I would have tried out my CGA card a long time ago (it won't fit in a 16-bit slot because of the overhang).
Last edited:
per
Veteran Member
you can try to mask of the upper 16-bit parts so only the lower 8-bit part can communicate with the computer. Masking-tape is fine here because it is easy to remove afterwards.
patscc
Veteran Member
Isa
Isa
How would that work, then ? There was no support for autoconfiguration on ISA.
ISA also ran at the system clock speed. This was changed in later boards where, as was pointed out, you could select the ISA bus speed, but there's nothing in the spec that allows the speed to be negotiated by the card talking to the board.
On 16-bit ISA, the card could request 8 or 16 bit transfers from the DMA, but this was on a
card-by-card basis & transfer-by-transfer basis, not system wide.
Some DMA channels were defined a s 8-bit, others 16-bit, which caused problems.
Slapping a 8-bit card onto a 16-bit bus could cause problems, but any slowdown isn't due the bus magically deciding to run at a slower speed, or to suddenly force all other card into 8 bits if a 8 bit card is present.
Of course, I might be remembering something incorrectly, or phrasing something badly, so if Fallo has any references for the
patscc
Isa
How would that work, then ? There was no support for autoconfiguration on ISA.
ISA also ran at the system clock speed. This was changed in later boards where, as was pointed out, you could select the ISA bus speed, but there's nothing in the spec that allows the speed to be negotiated by the card talking to the board.
On 16-bit ISA, the card could request 8 or 16 bit transfers from the DMA, but this was on a
card-by-card basis & transfer-by-transfer basis, not system wide.
Some DMA channels were defined a s 8-bit, others 16-bit, which caused problems.
Slapping a 8-bit card onto a 16-bit bus could cause problems, but any slowdown isn't due the bus magically deciding to run at a slower speed, or to suddenly force all other card into 8 bits if a 8 bit card is present.
Of course, I might be remembering something incorrectly, or phrasing something badly, so if Fallo has any references for the
I wouldn't mind reading up on it.
patscc
It's because the ISA bus decodes memory in 128k blocks. If an 8 and 16-bit card are using memory within the same block (as monochrome and VGA do), the 16-bit card will slow down. This does not affect VESA or PCI VGA cards (obviously since they're not on the ISA bus).
QuantumII
Veteran Member
Good to know. But anyway..
Does anybody here have an XT and both a VGA card and a CGA card so that they can compare the performance ? Use Alley Cat as a benchmark. The slowdown when the dog appears is very noticeable, and also when swimming in the fish tank.
First try it with the VGA card, second replace the card with a CGA (native) adapter, and try again.
patscc
Veteran Member
Dma
Dma
Are you thinking of DMA transfers ?
DMA Channels 1, 2 and 3 use up to 64k frames.
DMA Channels 5, 6 and 7 use up to 128k frames.
This can cause problems, I agree. I guess I'll have to think about it some and perhaps try it out with a Herc & VGA on a 386 board, 'cause I'm just not seeing the 16-bit card running using only 64 k frames. But it's been a while since I've played around with this.
patscc
Dma
The bus itself doesn't do any, nor specify any kind of paging.
Are you thinking of DMA transfers ?
DMA Channels 1, 2 and 3 use up to 64k frames.
DMA Channels 5, 6 and 7 use up to 128k frames.
This can cause problems, I agree. I guess I'll have to think about it some and perhaps try it out with a Herc & VGA on a 386 board, 'cause I'm just not seeing the 16-bit card running using only 64 k frames. But it's been a while since I've played around with this.
patscc
Trixter
Veteran Member
Only the original IBM CGA card and very close compatibles (like the display board in an AT&T PC 6300 or Olivetti M24) have snow when writing to 80-column textmode. All other cards don't have this problem.
Trixter
Veteran Member
VGA and MDA do not use memory that crosses a common page boundary. VGA uses a000-afff and b800-bbff. MDA uses b000-b7ff.
Trixter
Veteran Member
I suppose I could do that. It would be good practice to learn a new interface library I've been wanting to try out anyway. It will take me about a week, since I'll also need to produce a reference video so that you guys can see what I see on my original hardware.
QuantumII
Veteran Member
Cool! If you do that, it would be a very nice utility for us to have
Sign me up as a beta testerWhat I meant was that VGA and MDA use memory within the same 128k block (A000-BFFF). I invite anyone here to put a monochrome and ISA VGA card in the same computer and see the reduced performance of the latter.
Trixter
Veteran Member
...in a computer with 16-bit slots. In our PCs/XTs, with 8-bit slots, plugging both in does not make the VGA go slower. And I still think you're confusing bus memory access with DMA transfers, but I'm not willing to pull out the techref and study it for an hour to debate the point.
In any case, when I write the benchmark, I'll be sure to include an interleaved instruction-memory test (like multiple STOSWs) as well as a memory-only test (REP STOSW) just so any perceived difference will be noticeable, both in the same 128K block as well as outside of it.
per
Veteran Member
I don't think it is neither of therse either. My guess is that the routine in the BIOS extension on the VGA uses more code than the one in the PC/XT BIOS (whitch is rather slow itself), making it so slow on the 4.77MHz 8088 that the game will have delays and graphics problems.
Trixter
Veteran Member
Since the BIOS is not used for graphics operations, this is incorrect The BIOS is only used for setting new modes and stuff. Once a game is running, it writes directly to video memory, which is what the OP was talking about.
The BIOS is only used for setting new modes and stuff. Once a game is running, it writes directly to video memory, which is what the OP was talking about.per
Veteran Member
Since the BIOS is not used for graphics operations, this is incorrect
Ah.. I've only done programming for text-output (the BIOS or DOS routines are heavily used if you don't want to make your own routines there), so I really don't know how to do graphics (yet..).
Maybe it should be like that, and you won't notice on an RGB monitor because of the refresh rates and phosphore type, anyway, I don't know how serve the graphic problems are, but's only a guess.
*Edit*
If we just can't seem to find any sollution, maybe disassembling the Alley-Cat disk could reveal anything... Maybe it does low-level stuff that puts the VGA in some kind of low-preformance mode...