Disassembling the IBM PGC firmware

[per]

I am currently working on dissasembling the firmware of the IBM PGC. Recently, I have made some small progress now and then, but just now I made a BIG leap. I am now able to state how the card obtain it's input.

Just some basic information first (optional). The card has an 8088-2 CPU running at 8MHz. It got 64KB Firmware stored in ROM, 2KB SRAM shared with the hosting computer, and 320KB of DRAM (framebuffer and stored command lists). I know so far that the Firmware ROM appear at least twice in the memory map; at segment F000 and segment 0000. The SRAM appears at segment 2800 (C600 for the hosting computer), and is used for internal variables, the stack, and communication buffers. This SRAM is actually faster to comunicate with than the DRAM, because of the DRAM is accessed in nibbles (due to that memory is being shared with the video logics). There is being done reads and writes to various other spots in the memory map at initalizion, but I'm unsure what purpose it does this for.

When the card boots, it first checks the CPU. Then it checks the Firmware ROM, the DRAM, and finally it sets the internal variables. The last thing that happens is that it enters an endless loop. This loop contains a call to a routine that eventually forwards controll to the input routine by a jump. the input routine is terminated with a "ret", and controll will be returned to the endless loop instead of the routine called by the endless loop (at least in HEX mode, I believe it does some translation if ASCII mode is active).

If a byte is returned in AL, it will multiply AX with two, and call [CS:AX]. CS is 0025, and IP is F80F after the call instruction.

What happens is that the new IP depends on the input byte. The input byte does in fact points to a word-sized offset in a 512-byte table located at 0250. Each of therse offsets leads to the routine for the command corresponding to the input byte. The absolute location of the routine to be called is 0025ffset

Here is the table:

6E 02 6E 02 6E 02 6E 02 7D F6 10 D7 F0 48 20 4D 10 A1 40 A1 6E 02 6E 02 6E 02 6E 02 6E 02 B8 4D
30 71 B8 71 7A 71 13 72 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02
6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 90 33 10 34 71 34 D2 34 6E 02 6E 02 6E 02 6E 02
B0 A1 38 A2 0E A3 2A A3 60 72 74 72 6E 02 6E 02 90 0A 17 0B 6E 02 6E 02 AA 0E 29 11 6E 02 6E 02
6E 02 6E 02 6E 02 11 49 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 A2 4C
92 84 A8 49 76 DE 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 28 02 6E 02 6E 02 6E 02 00 02
6E 02 6E 02 6E 02 11 49 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02
A8 28 6E 02 48 2A 62 2A F1 29 62 2B 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02
75 B4 9F B0 C6 B1 90 C3 80 C6 46 B4 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02
41 DE 14 DF B7 DF 64 E0 D5 E0 46 E1 45 DF C4 DE 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02
4A DE A7 E1 6E 02 EF E1 61 E2 E4 E2 6E 02 CC DE CD DD F1 DD 81 48 A6 48 6E 02 6E 02 6E 02 48 DD
6E E6 85 49 66 DA 4B D9 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02
70 02 E7 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02
3C 49 34 49 38 49 6E 02 6E 02 6E 02 6E 02 6E 02 F0 80 4B 81 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02
6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 50 48 F7 4B 88 4C DB 4B A3 4B EB 84 D3 84 20 84 9A 49
6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02 6E 02

You clearly see that most of them contains the value 026E. Those leads directly to a "ret" instruction at absolute location 004BE, and all the commands pointing tho those can be treated as "not used".

I may start disassembling some of the smaller routines as soon I have tidying in the code. Maybe I could figure some of the internal variables.

There is also a similar list at 3060, but it does contain a lot of similar valuse for some of the "used" commands. I guess that table may be some kind of lookup about what kind of data should follow the command.

 

[Chuck(G)]

Uh, the "Options and Adapters" books had a big section for the PGC, including a source listing for the code (or so I remember). I loaned that volume (it was that thick) out many years ago and forgot to ask for it back.

But maybe someone else has it...

 

[per]

Do you know what volume it was in?

Volume 3 is for sale on ebay for a reasonable price...

If no others have it, do you have any ability to get it back? I would LOVE to get a scan of those pages!

 

[Chuck(G)]

Do you know what volume it was in?

Volume 3 is for sale on ebay for a reasonable price...

If no others have it, do you have any ability to get it back? I would LOVE to get a scan of those pages!

I don't recall as it was part of an update package. It's possible that another binder was packed in. My memory fails me.

 

[IBMMuseum]

John Elliott hangs around the forum too, so build on what he has:

http://www.seasip.info/VintagePC/pgc.html

 

[shattered]

I am currently working on dissasembling the firmware of the IBM PGC. Recently, I have made some small progress now and then, but just now I made a BIG leap. I am now able to state how the card obtain it's input.

Did you make much progress since then? I am (slowly) working on PGC emulation in MESS and am decoding the memory map from schematics in OA manual; certainly could use some help in this area.

 

[Al Kossow]

Did you make much progress since then? I am (slowly) working on PGC emulation in MESS and am decoding the memory map from schematics in OA manual; certainly could use some help in this area.

the rom listing isn't there but the card is in the tech ref vol 3

http://bitsavers.org/pdf/ibm/pc/cards/Technical_Reference_Options_and_Adapters_Volume_3.pdf

 

[shattered]

Yeah, that's the one. I'm using minuszerodegrees' scan, though.

 

[per]

I haven't done much work on this for a long time, sorry! I did have a look at some of the smaller functions after starting this topic, but I don't remember much. I was using a crude dissassembly tool at the time without much of the functions available with the more dynamic and sophisticated dissassembly tools. Looking through my archive, it seems like I wrote some of the findings down...

The ROM is available at http://www.minuszerodegrees.net/rom/rom.htm

 

[shattered]

Thanks, I will share my findings once I get somewhere

Also, far as I can see, no one has dumped the chargen ROM yet, there's only a 'reconstructed' one. Is that right?

 

[eeguru]

Here are the dumps from my card:

https://www.retrotronics.org/pgc/

 

[per]

It is worth mentioning that is actually a later version of the firmware than my card has! According to a quick google search, the part numbers suggests firmware version 1.6.

59X7354/5 from 1985 vs. 6137322/3 from 1984

I would guess that the character ROM would be the same though. Part number 6137560 on my card, for reference. I haven't dumped the one I got as I have never really been good at desoldering.

 

[shattered]

Many thanks, eeguru!

Does anyone have the 'updated diagnostics' disks for XT and AT?

 

[shattered]

So apparently, the PGC was designed by Vermont Microsystems and right here on this forum there was a kind offer of technical info -- http://www.vintage-computer.com/vcf...-Vermont-Microsystems-dual-slot-graphics-card

 

[bobba84]

Just out of curiosity - does anyone have any screen shots or videos of a PGC with monitor actually working in high res mode? I've never seen one in operation!

 

[fs5500]

Thanks for sharing rare version.

I'll compare the PGC binary ROM with handmade file.

 

[per]

I made this small thing a long time ago, using a driver I found for accessing the PGC as a device file. This way you can easily run it from BASIC.

For 3D, the card is terribly slow. It's something around 30-40 filled polygons per second (or less, depending on polygon size).

Most VGA monitors handle the signals from it just fine. Just use a 9-pin to 15-pin VGA cable and you should be good. The only difference is composite sync instead of separate H/V sync.

 

[fs5500]

I'm very supprised that PGC font ROM chip seems to includes binary font ROM data symmetrized and inverted.
But, I'll prove the fact.

 

[JohnElliott]

Here are the dumps from my card:

https://www.retrotronics.org/pgc/

Nice! So my reconstruction got the character shapes correct, but in the real ROM it's stored flipped and inverted.

 

[tipc]

Please don't take this as criticism. I too am a fan of the PGC, and it's clone (got 1). I got a pair of 5175 + PGC sets years ago, sold the set that had the working 5175. Kept the busted one (that *will* be revitalized one day). The notion of an early high powered graphics subsystem sporting the same uP as the host (unless it was plugged into an AT) is intriguing, totally nifty. But prior to totally reverse engineering the firmware (and hardware), wouldn't it make as much sense to hack into it? To perform some groovy tricks and whatnot? If I had the time (or inclination) to play with mine, that's what I would do.
And as to the 1 clone that I've been way too fortunate to acquire, it's a Vermont Microsystems version, also a dual card, an 80188 uP, and possibly better CGA compatibility, w/o the extra daughter card. It served as part of an imaging box (P166) years ago, w/the working 5175 before I sold it. VM doesn't have much of an illustrious history in the computer world, but they did take Autodesk to court over some alleged pirated code, and won.
I have a horrid horrid set of scans of all the Options and Adapters manuals, and if someone were to bug me over it, I could dig out relevant sections.