Paradise PVGA1A ISA card - strange failure with planar memory \ VOGONS

Paradise PVGA1A ISA card - strange failure with planar memory

Topic actions

First post, by jakethompson1

Posted on 2024-07-22, 02:32

jakethompson1 Offline

Rank Oldbie

Rank: Oldbie
Posts: 1811
Joined: 2015-11-17, 04:16

I have a PVGA1A-based ISA VGA card. It has eight 64Kx4 chips for video memory.

In 640x480x16 mode (and likely other modes) it has a strange failure with jail bars, and it does not have anything to do with CRT vs. LCD.

I had to learn about planar memory layout to debug this. 16-color mode has a 64K window at a000:0. Instead of byte 0, bits 7-4 being pixel (0,0); byte 0, bits 3-0 being pixel (0, 1), etc. as you might expect, it's bit 0 of every pixel packed together for "plane 0", bit 1 of every pixel packed together for "plane 1", and so on.

You can write to any combination of planes by ORing together 1<<plane number and writing that value to port 3c5 (after writing index 02 to port 3c4). An obvious use for writing multiple planes at once is to clear the screen to all black (0000b) or all white (1111b).
You can read one plane at a time by writing the plane number to port 3cf (after writing index 04 to port 3ce).

With that knowledge I was able to debug the issue. First switch to mode 12h (which will automatically zero out video RAM).
Switch to plane 1 and fill it with FF bytes. That should set every pixel to 0010b (dark green) and plane 3 should remain filled with 00 bytes. Instead, plane 3 magically changes to F0 bytes. And we get light/dark green jailbars.
Zero out video RAM again.
Switch to plane 3 and fill it with FF bytes. That should set every pixel to 1000b (dark gray). Instead, it sets 0F bytes and we get black/gray jailbars.

I assume this is one of the 64Kx4 chips being bad? Or could the addressing logic inside the PVGA1A have gone bad? Any idea on the mapping from planes to DRAM chips? Seems like it's likely the seventh or eighth memory chip that is bad?

1C:\>debug
2-a
30B6F:0100 mov ax,12 ; put the screen in 640x480x16 mode
40B6F:0103 int 10
50B6F:0105 int3
60B6F:0106 
7-g=100
8
9AX=0012  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000  
10DS=0B6F  ES=0B6F  SS=0B6F  CS=0B6F  IP=0105   NV UP EI PL NZ NA PO NC 
110B6F:0105 CC            INT     3                                  
12-o 3c4 2
13-o 3c5 8 ; writes to a000 segment should ONLY go to plane 3
14-o 3ce 4
15-o 3cf 3 ; reads from a000 segment should come from plane 3
16-f a000:0 l 9600 ff ; should produce entirely gray screen
17-d a000:0 l 10      ; actually produces black/gray jailbars
18A000:0000  0F 0F 0F 0F 0F 0F 0F 0F-0F 0F 0F 0F 0F 0F 0F 0F   ................
19-f a000:0 l 9600 f0 ; should produce gray/black jailbars
20-d a000:0 l 10      ; actually produces entirely black screen
21A000:0000  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
22-f a000:0 l 9600 0f ; should produce black/gray jailbars
23-d a000:0 l 10      ; it does that
24A000:0000  0F 0F 0F 0F 0F 0F 0F 0F-0F 0F 0F 0F 0F 0F 0F 0F   ................
25-f a000:0 l 9600 a5 ; just testing memory
26-d a000:0 l 10      ; the high nibble fails
27A000:0000  05 05 05 05 05 05 05 05-05 05 05 05 05 05 05 05   ................
28-f a000:0 l 9600 5a ; just testing memory
29-d a000:0 l 10      ; the high nibble fails
30A000:0000  0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A   ................
31-g=100 ; now clear the screen 
32
33AX=0012  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000  
34DS=0B6F  ES=0B6F  SS=0B6F  CS=0B6F  IP=0105   NV UP EI PL NZ NA PO NC 
350B6F:0105 CC            INT     3                                  
36-o 3c4 2
37-o 3c5 2 ; writes go to plane 1 only
38-o 3ce 4
39-o 3cf 1 ; reads come from plane 1 only
40-f a000:0 l 9600 ff ; should be entirely dark green screen
41                    ; it should not affect plane 3 at all
42                    ; instead, light green/dark green jailbars
43-o 3ce 4
44-o 3cf 3 ; switch to reading from plane 3
45-d a000:0 l 10 ; now the high nibble is stuck on instead of off???
46A000:0000  F0 F0 F0 F0 F0 F0 F0 F0-F0 F0 F0 F0 F0 F0 F0 F0   ................

Reply 1 of 2, by Deunan

Posted on 2024-07-22, 09:02

Deunan Offline

Rank l33t

Rank: l33t
Posts: 2070
Joined: 2018-05-29, 12:32

A photo would be nice. 0xF0 / 0x0F type glitches sure would fit nicely with 4-bit DRAMs but are you sure those chips are 64kx4? Could be 256kx1 for example. You need to be sure first.
Check what kind of bus this card has. Older VGAs would usually have just 8 bit wide data bus, though it could be 16-bit too depending on the chips. The mapping from logical to physical is very card-specific. Basically it's all done to make sure RAMDAC can access the memory without delays so the mapping can be non-trivial. That being said if I suspected one of the chips on planes 0 or 3 I would start with the side ones, not those in the middle. I assume these are soldered? Remove one and put in a socket (first make sure nothing was damaged during desoldering). Repeat software tests, see where that got me. Rinse and repeat.

These old DRAMs do fail. Sometimes if you're lucky the failed chip will be running hotter or cooler then the rest. If you have some fancy thermal camera you can use that, if not then just touch them with your finger - shortly after powering up and then in few minute intervals. Sadly though the type of problem you have (chip can be cleared to zero but then sets unusual values) means it's not completly dead, so probably there won't be much of a difference in temperature, if any. Worth a try though.

Reply 2 of 2, by jakethompson1

Posted on 2024-07-22, 15:32

jakethompson1 Offline

Rank Oldbie

Rank: Oldbie
Posts: 1811
Joined: 2015-11-17, 04:16

Looking at the PVGA1A datasheet I thought I had it narrowed down to one of two DRAM chips, so I desoldered them and the jailbars went away but now the screen is corrupt even in text mode. So something went wrong with that and I'm going to shelve it for now.

Go to top of page Go to top of page

Back to General Old Hardware