VileR wrote on 2020-09-28, 01:14:

I wonder what type of monitor is in that IBM which 8-bit guy ended up trying to boot. He says it's MCGA, so the monitor should be VGA, but I'm clearly seeing 15 KHz...

MCGA is able to drive CGA frequencies. How do I know? I tried a IBM PS/2 model 30 with a non-IBM VGA monitor, which obviously did not implement the monitor type detect pins in the way intended by IBM. The result was a double-width picture (like 40-column mode when 80-column mode was selected), which indicates the card was outputting 15kHz, and the monitor synced to twice that frequency. Maybe the monitor shown by the 8-bit guy is the monitor that is intended to be driven that way.

You don't loose much feature-wise on MCGA by connecting an analog(!) 15kHz monitor: The text modes run in reduced quality (8x8 character box instead of 8x16 character box), and the monochrome 640x480 mode is non-functional. All other modes use 200 scanlines and are double-scanned on VGA monitors anyway.

Ha, that's very odd - if a 15kHz signal was misinterpreted as VGA (and the monitor was still able to sync to it), then I'd expect missing scanlines or a horizontal split in the picture... could your non-IBM monitor have been multi-sync of some sort?

The idea is sort of conceivable, but at the very least it's clearly undocumented - at least in the only MCGA documentation I can locate, which is in the Model 25 technical reference. There IS one "reserved" value for the monitor-sense pins (00), so it's probably possible to look at what the Model 30 BIOS puts in the video registers when it sees that. 😀

VileR wrote on 2020-09-28, 09:21:

Ha, that's very odd - if a 15kHz signal was misinterpreted as VGA (and the monitor was still able to sync to it), then I'd expect missing scanlines or a horizontal split in the picture... could your non-IBM monitor have been multi-sync of some sort?

I think what I got was what you call "a horizontal split". The first "40 columns" kind-of overlaid the second "40 columns", of course with some columns missing due to the extra retrace in the middle of the 15kHz scanline. I am very confident that monitor was not multi-sync, and I am nearly sure it worked perfectly on other VGA sources. Up to now, I maintain the belief its horizontal sync PLL just synchronized every other scanline with the sync pulses from the MCGA. I don't know the exact details, because at that time, I didn't further research into it, but exchanged the monitor with a original IBM monitor, a 8512 to be exact. As the story happened around 25 years ago, I don't remember whether the incompatible monitor remained in our home, or we exchanged it for another one at the opportunity we collected the PS/2 model 30 machines and monitors from. This means I can't re-perform the experiment now.

I checked the two PS/2 Model 30 machines that are still in reach (we used to have three for some time) for BIOS versions. One of them has the 61X8937/61X8938 pair (stickers), whereas the other one has the 61X8939/61X8940 pair (custom marked TC53257P toshiba mask ROMs). I'm going to investigate whether I can find BIOS code responsible for the 15kHz output. Actually, looking at the PS/2 model 30 mainboards for BIOS versions, they looked really similar (if not identical, I'm going to compare if you want) to the mainboards the 8-bit guy showed in his video. The PS/2 model 30 mainboard (I am consistently not talking about the model 30/286) also has the presumed "hard drive" connector next to the floppy connector. It would be interesting whether there is something like 8-bit XT attachment (aka XT-Bus or XT-IDE) on that connector.

@mkarcher: gotcha - thanks for the details! The plot thickens...

mkarcher wrote on 2020-09-28, 12:55:

I checked the two PS/2 Model 30 machines that are still in reach (we used to have three for some time) for BIOS versions. One of them has the 61X8937/61X8938 pair (stickers), whereas the other one has the 61X8939/61X8940 pair (custom marked TC53257P toshiba mask ROMs). I'm going to investigate whether I can find BIOS code responsible for the 15kHz output. Actually, looking at the PS/2 model 30 mainboards for BIOS versions, they looked really similar (if not identical, I'm going to compare if you want) to the mainboards the 8-bit guy showed in his video.

That is interesting - there was a recent post on the Vintage Computer Forums where a dump of the 61X8937/38 pair was provided (European Rev.1, 12/13/1987). 61X8939/40 are apparently Rev.2 although the date is earlier (02/05/1987); can already be found at http://ibmmuseum.com/BIOS/8530/.
I was hoping to find some listings or commented disassemblies floating around somewhere, like the older IBM PCs, but couldn't come up with any. I guess that figures, since this was exactly when IBM did a 180° on the whole "open architecture" thing. Might as well have a shot with IDA anyway.

If 8-bit guy's video can indirectly lead us to confirm the existence of undocumented 15kHz support on MCGA, it might be good for something after all. 😁

VileR wrote on 2020-09-28, 16:09:

That is interesting - there was a recent post on the Vintage Computer Forums where a dump of the 61X8937/38 pair was provided (E […]
Show full quote

mkarcher wrote on 2020-09-28, 12:55:

I checked the two PS/2 Model 30 machines that are still in reach (we used to have three for some time) for BIOS versions. One of them has the 61X8937/61X8938 pair (stickers), whereas the other one has the 61X8939/61X8940 pair (custom marked TC53257P toshiba mask ROMs). I'm going to investigate whether I can find BIOS code responsible for the 15kHz output. Actually, looking at the PS/2 model 30 mainboards for BIOS versions, they looked really similar (if not identical, I'm going to compare if you want) to the mainboards the 8-bit guy showed in his video.

That is interesting - there was a recent post on the Vintage Computer Forums where a dump of the 61X8937/38 pair was provided (European Rev.1, 12/13/1987). 61X8939/40 are apparently Rev.2 although the date is earlier (02/05/1987); can already be found at http://ibmmuseum.com/BIOS/8530/.
I was hoping to find some listings or commented disassemblies floating around somewhere, like the older IBM PCs, but couldn't come up with any. I guess that figures, since this was exactly when IBM did a 180° on the whole "open architecture" thing. Might as well have a shot with IDA anyway.

If 8-bit guy's video can indirectly lead us to confirm the existence of undocumented 15kHz support on MCGA, it might be good for something after all. 😁

I got the dumps, I got IDA up. First findings:

Three monitor types are indeed supported. HelpPC calls the associated display combination codes "MCGA with digital color monitor", "MCGA with analog monochrome monitor" and "MCGA with analog color monitor". The BIOS initializes the VGA flags at 40:89 to 00 for "digital color monitor" (mono monitor bit clear, auto-convert-to-grayscale bit clear, 400-line-support bit clear), to 10 for "analog color monitor" (400-line support bit set) and to 16 for "monochrome color monitor" (400-line support, auto-grayscale, monochrome monitor). I have no idea yet whether "digital color monitor" is correct, or "analog 15kHz monitor" would be the correct description. I might have to check the PS/2 model 30 mainboard for analog mulitplexers near the monitor output. If the monitor output is always connected to the Inmos DAC, there is no digital monitor support.

There is hard disk support in the BIOS, although not 8-bit IDE, but something way more XT-like with base port 320, IRQ5, DMA3. I am going to look into details later. There is code to toggle a hard soft HDD LED connected to a GPO pin.

The PS/2 keyboard/mouse interface seems to work without a KBC, but some extra ports in the custom logic. Possibly the port 60 scan codes are emulated in software, I don't know yet.

There is support for a manufacturer's test rig at ports in the E0 range. Early post errors cause "HLT" to be written into it, presence is detected by reading "MFG" from it. If that rig is present, three-digit POST errors go to that rig instead of the screen.

POST codes are not written to port 80, but to port 90 (the port 80 equivalent of the PS/2) and 378 at the same time (parallel port), so you can connect an "external post card" to the parallel port.

RAM refresh seems not to be handled by timer channel 1.

mkarcher wrote on 2020-09-28, 16:27:

I got the dumps, I got IDA up. First findings: […]
Show full quote

I got the dumps, I got IDA up. First findings:

Three monitor types are indeed supported. HelpPC calls the associated display combination codes "MCGA with digital color monitor", "MCGA with analog monochrome monitor" and "MCGA with analog digital monitor". The BIOS initializes the VGA flags at 40:89 to 00 for "digital color monitor" (mono monitor bit clear, auto-convert-to-grayscale bit clear, 400-line-support bit clear), to 10 for "analog color monitor" (400-line support bit set) and to 16 for "monochrome color monitor" (400-line support, auto-grayscale, monochrome monitor). I have no idea yet whether "digital color monitor" is correct, or "analog 15kHz monitor" would be the correct description. I might have to check the PS/2 model 30 mainboard for analog mulitplexers near the monitor output. If the monitor output is always connected to the Inmos DAC, there is no digital monitor support.

There is hard disk support in the BIOS, although not 8-bit IDE, but something way more XT-like with base port 320, IRQ5, DMA3. I am going to look into details later. There is code to toggle a hard soft HDD LED connected to a GPO pin.

The PS/2 keyboard/mouse interface seems to work without a KBC, but some extra ports in the custom logic. Possibly the port 60 scan codes are emulated in software, I don't know yet.

There is support for a manufacturer's test rig at ports in the E0 range. Early post errors cause "HLT" to be written into it, presence is detected by reading "MFG" from it. If that rig is present, three-digit POST errors go to that rig instead of the screen.

POST codes are not written to port 80, but to port 90 (the port 80 equivalent of the PS/2) and 378 at the same time (parallel port), so you can connect an "external post card" to the parallel port.

RAM refresh seems not to be handled by timer channel 1.

Beat me to it (by far) - nice work!
"Digital" on MCGA (no DAC) would basically mean plain old CGA. The display we see in the video *could* be that, but on the other hand, I wouldn't expect a non-multisync VGA monitor to show anything intelligible (not even a double-width/"split" picture).

Other than tracing the video outputs on the mainboard, an alternative may be checking what INT 10h does if you try to set mode 13h when the 40:89 flags say "00". If that means "digital", I assume it'll just refuse (mode 11h wouldn't work either way).

VileR wrote on 2020-09-28, 17:00:

Other than tracing the video outputs on the mainboard, an alternative may be checking what INT 10h does if you try to set mode 13h when the 40:89 flags say "00". If that means "digital", I assume it'll just refuse (mode 11h wouldn't work either way).

I know that for sure: The only thing INT 10h refuses is mode 11h (640x480 mono) on a 200-line monitor. I get the suspicion that IBM tried to continue the "TV compatible color" / "high res monochrome" distinction they had with CGA/MDA into the MCGA world, such that the color VGA monitor would be an expensive premium option.

All I got from the BIOS is consistent with Ralph Browns ports.lst entries for MCGA. I think it is quite likely that BIOS dumps and experimentation were the source for that list.

mkarcher wrote on 2020-09-28, 17:26:

I know that for sure: The only thing INT 10h refuses is mode 11h (640x480 mono) on a 200-line monitor. I get the suspicion that IBM tried to continue the "TV compatible color" / "high res monochrome" distinction they had with CGA/MDA into the MCGA world, such that the color VGA monitor would be an expensive premium option.

All I got from the BIOS is consistent with Ralph Browns ports.lst entries for MCGA. I think it is quite likely that BIOS dumps and experimentation were the source for that list.

Yeah, as I mentioned it's a given that mode 11h wouldn't work with any type of 200-line monitor - more interesting is what happens in mode 13h when the flags indicate such a monitor, specifically what sync timings are set in the video registers.
That would say for sure what it's trying to do. I haven't used IDA with BIOS ROMs until today, and although I got it to set the loading addresses and entry points and analyze correctly, I'm off the trail on where the interrupt vectors are being set. So my missing piece of the puzzle is the entry point for INT 10h. I suppose somewhere there's a Video Parameter Table with that stuff.

Ralph Brown's PORTS.LST seems to be inconsistent when it comes to MCGA, e.g. "bit X only used on MCGA" followed by "(EGA) bit X: ....".

VileR wrote on 2020-09-28, 21:01:

Yeah, as I mentioned it's a given that mode 11h wouldn't work with any type of 200-line monitor - more interesting is what happens in mode 13h when the flags indicate such a monitor, specifically what sync timings are set in the video registers.
That would say for sure what it's trying to do. I haven't used IDA with BIOS ROMs until today, and although I got it to set the loading addresses and entry points and analyze correctly, I'm off the trail on where the interrupt vectors are being set. So my missing piece of the puzzle is the entry point for INT 10h. I suppose somewhere there's a Video Parameter Table with that stuff.

Ralph Brown's PORTS.LST seems to be inconsistent when it comes to MCGA, e.g. "bit X only used on MCGA" followed by "(EGA) bit X: ....".

If you are looking at the 39/40 edition of the PS/2 BIOS, you can find the "save table" at F000:1E4F. The first entry in the save table is a pointer to a video parameter table, like in the EGA/VGA scenario. Of course, the save table is anything but EGA/VGA compatible - this is a PS/2 after all 😉. (That rant is somehow misplaced. The PS/2 Model 50 of course has a VGA compatible save table).
The video parameter table is at F000:369F, and has the following layout:

48 bytes: RGB triples for the 16 CGA colors. The "IBM brown" is realized at this point.
64 bytes: 40-column text mode (200/400 lines)
64 bytes: 80-column text mode (200/400 lines)
64 bytes: 320x200 4-color graphics mode (200/400 lines)
64 bytes: 640x200 2-color graphics mode (200/400 lines)
32 bytes: 640x480 graphics mode (480 line only)
64 bytes: 320x200 graphics mode (200/400 lines)

Each 32-byte parameter set consists of:
00: byte columns
01: byte rows - 1
02: byte character height
03: word size of one page of video data
05: word always zero, purpose unknown
06: 21 bytes CRTC registers
1C: byte pixel mask register (3C6)
1D: byte mode register (3D8)
1E: byte color select register (3D9)
1F: byte extended MCGA mode register (3DD)

A 64-byte mode contains the 200-line parameter set followed by the 400-line parameter set.

I'm planning to make an overview of the parameters and compare them to original CGA and orginal VGA parameters.

Excellent, that should definitely help!

In the meanwhile, I had to raise the subject in that VCF thread. Your recollection from 25 years ago is verified - MCGA does support 15kHz analog RGB (http://www.vcfed.org/forum/showthread.php?768 … 7847#post637847):

evildragon wrote:

Can confirm, if you don't ground any of the mode sense pins, MCGA goes into 15KHz RGB mode and is NTSC compatible. I verified it on my Sony PVM.

So MCGA *does* have a unique feature all its own. Take that, VGA!

I'm not sure why a grand total of two people seem to be interested in undocumented surprises like that.... but I'm glad to have learned this, even if I indirectly have to thank a boorish youtube heathen who dares to mutilate screws with a dremel. 😉

I've been following this discussion with interest even though I'm not technical enough to understand any of it 😆

But I find it amazing there are still discoveries to be made more than 30 years after this standard was invented! And if it means it's possible to drive a 15khz monitor with a simple VGA card then it's definitely exciting 👍

VileR wrote on 2020-09-28, 22:12:

I'm not sure why a grand total of two people seem to be interested in undocumented surprises like that.... but I'm glad to have learned this, even if I indirectly have to thank a boorish youtube heathen who dares to mutilate screws with a dremel. 😉

The whole MCGA stuff is very interesting from a technological point of view. It is claimed to be "an improved CGA version with some VGA features", but technically, it's quite its own thing!

If you take a look at the PS/2 Model 30 planar (IBM speak for mainboard), you will find only 2 video RAM chips, 64k x 4 bits each. That's not such a surprise at first, because everyone knows MCGA has 64KB of RAM. What is surprising is that MCGA manages to get 320x200 pixels at 256 at full VGA frequencies from an 8-bit video memory, whereas the 32-bit interface of the VGA is also maxed out in that mode. They can't magically quadruple the memory throughput in MCGA, a design on the budget side? Of course they can't, but they can use VRAM instead of DRAM. You get the high-bandwidth video output basically for free on VRAM chips. So MCGA seems to be the first original IBM PC graphics solution that uses VRAM.

Another interesting thing: 80x25 with custom font. 80 characters at a pixel clock of 25MHz is around 3 MHz character rate. The MCGA (if it doesn't use the VRAM serial output for it) needs 2 memory cycles to load character and attributes. This makes it difficult to squeeze in a third memory cycle for the font load. Even if the two cycles for character and attribute are fast-page-mode cycles, the font load won't be. They solve the problem just like CGA/MDA: They have a separate 8 bit wide memory chip that contains font data. But this chip is a RAM chip, not a ROM chip. On my PS/2 planar, it's a HM6264FP-12T 8k x 8 CMOS static SRAM. This memory is not accessible over the system bus, but it can only be read or written by the MCGA ASIC. You load a font by first placing it into the first half of VRAM (in an interesting format), and then instruct a "memory to memory DMA engine" inside the MCGA ASIC to copy font data from the VRAM to the font SRAM. It seems you can choose between a fast transfer that disrupts displaying text and a slow transfer that only takes place during blanking. MCGA seems to be the first affordable IBM PC graphics solution that includes memory copying engine. I specified "affordable" to avoid discussion about the PGA that most likely also was able to copy data on its own. You can't really call the MCGA font copying function an "accellerator function", as it can only copy data from VRAM to the font RAM. Writing a demo that uses the slow "only on blanking" transfer mode to dynamically modify character shapes might be quite interesting, though.

MMaximus wrote on 2020-09-28, 22:21:

But I find it amazing there are still discoveries to be made more than 30 years after this standard was invented! And if it means it's possible to drive a 15khz monitor with a simple VGA card then it's definitely exciting 👍

You can program the VGA card to generate 15kHz compatible timing in a custom mode. Just use the "divide clock by 2" feature that is usually used to obtain 320 pixel modes, but set the card for 640 pixels. Also set the card for fewer lines to keep in line with NTSC field timing. The VGA BIOS does not support modes like this, but I think there is third-party hardware that converts VGA to SCART by just generating CSYNC from VSYNC and HSYNC, and comes with software to set up the correct video timing.

On the other hand, the video solution inside the IBM PS/2 model 25 and IBM PS/2 model 30, called MCGA, has out-of-the-box support to run all CGA modes and the VGA 256-color mode on a 15kHz analog RGB monitor. It likely uses the 14.318 MHz oscillator as pixel clock, just as the orginal CGA did. There is no composite video generator, though, so no 8088MPH composite color artifacts from the MCGA. Also no way of directly connecting an IBM 5153 CGA display to either the MCGA or the VGA, as that monitor requires a digital TTL input.

mkarcher wrote on 2020-09-28, 22:40:

They can't magically quadruple the memory throughput in MCGA, a design on the budget side? Of course they can't, but they can use VRAM instead of DRAM. You get the high-bandwidth video output basically for free on VRAM chips. So MCGA seems to be the first original IBM PC graphics solution that uses VRAM.

Clever, and sort of analogous to how the original MDA used SRAM for its puny 4 KB text buffer, rather than DRAM, so that the relatively high bandwidth of 160 bytes per scanline (characters and attributes at 80 columns) didn't result in snow when writing to it during the active display period. After all, monochrome was for serious business!

You load a font by first placing it into the first half of VRAM (in an interesting format)

Anything different there to how it's done with VGA? The only "weirdness" with the VGA font I/O (that I can think of) is the need to place the characters on word boundaries, since VGA supports up to 32 scanlines per character, so they're effectively expanded from the "packed" format used by the BIOS. I haven't looked at the docs, but off-hand I recall that MCGA doesn't go that high (and may even be limited to just a few specific heights; I could be wrong there).

MCGA seems to be the first affordable IBM PC graphics solution that includes memory copying engine. I specified "affordable" to avoid discussion about the PGA that most likely also was able to copy data on its own. You can't really call the MCGA font copying function an "accellerator function", as it can only copy data from VRAM to the font RAM. Writing a demo that uses the slow "only on blanking" transfer mode to dynamically modify character shapes might be quite interesting, though.

Hah, yes - if that functionality was available in a more general way, it'd be *much* simpler to do tightly-timed video effects. Having "only on blanking" video I/O without the headache of interrupt setup (or polling)? Sign me up.

BTW: another font-related mystery with the MCGA models is the existence of four undocumented alternate character sets (this stuff). They come from a couple of Model 30 and 35 ROM dumps where the odd and even images are 64K each (128K interleaved). To this day I haven't been able to find a single reference to them, or to determine whether anything in the firmware even uses them at all. You seem to be very familiar with these models, so perhaps you have a lead? 😀

VileR wrote on 2020-09-29, 00:22:

mkarcher wrote on 2020-09-28, 22:40:

They can't magically quadruple the memory throughput in MCGA, a design on the budget side? Of course they can't, but they can use VRAM instead of DRAM. You get the high-bandwidth video output basically for free on VRAM chips. So MCGA seems to be the first original IBM PC graphics solution that uses VRAM.

Clever, and sort of analogous to how the original MDA used SRAM for its puny 4 KB text buffer, rather than DRAM, so that the relatively high bandwidth of 160 bytes per scanline (characters and attributes at 80 columns) didn't result in snow when writing to it during the active display period. After all, monochrome was for serious business!

Oh, thanks for that input. Seems I didn't research into MDA well enough to notice the SRAM-based design. But it does make a lot of sense indeed, and explains the "missing" multi-page feature on the MDA, due to the high cost of SRAM. I used to assume that MDA went the same route Hercules later used on their graphics adapter: They implemented a 16-bit wide DRAM interface. If CGA can get away (albeit snowy) with an 8-bit DRAM interface, you should be able to get a snow-free experience using a 16-bit interface, as you half the amount of memory cycles per scanline in text mode.

A consequence of the 16-bit design of the Hercules card is that the CRTC of the hercules card runs at a character clock that is the dot clock divided by 16, essentially it produces 45 "characters", each 16 pixels wide, to get to 720 pixels per line. On the other hand, the CGA card in monochrome graphics mode runs the CRTC at dot clock divided by 8, so it is programmed to produce 80 "characters", each 8 pixels wide, to obtain 640 pixels per line. The 320-pixel mode runs the CRTC at the same timing, it just "merges" to 1-bit pixels to one 2-bit pixel in the output circuit (more in depth, its basically the other way around: the 640 mode splits two-bit packets into two single pixels).

VileR wrote on 2020-09-29, 00:22:

You load a font by first placing it into the first half of VRAM (in an interesting format)

Anything different there to how it's done with VGA? The only "weirdness" with the VGA font I/O (that I can think of) is the need to place the characters on word boundaries, since VGA supports up to 32 scanlines per character, so they're effectively expanded from the "packed" format used by the BIOS. I haven't looked at the docs, but off-hand I recall that MCGA doesn't go that high (and may even be limited to just a few specific heights; I could be wrong there).

The CRTC programming values in the PS/2 model 30 BIOS are quite strange: There are just three different sets of CRTC timing values. One is common for all 200-line modes on 15.6kHz monitors, one is common for all 400-line modes on VGA monitors, and the third one is used for mode 11h (640x480/mono). This indicates that the CRTC runs at the same character clock in both 40-column and 80-column modes, with the "horizontal total" register indicating 40 characters all the time. Don't ask me how the implemented the blinking cursor, but if I had to take a bet, their custom CRTC implementation likely separates timing generation, controlled by the horizontal/vertical timing registers that much from the address generation, that they can run the address counter at twice the speed of the character counter.

Also, you need to distrust all sources that claim that the MCGA CRTC is basically a slightly expanded 6845. It's vertical timing programming model is way closer to the EGA/VGA timing model than it is to the 6845 model: The vertical timing on the MCGA is programmed in unit of monitor scanlines, like EGA/VGA, not in units of text lines (as with the 6845). The horizontal sync pulse is created from a "sync start" and a "sync end" register, not a "sync start" and a "sync width" register. Not all registers are obvious just from the MCGA timing examples, but a lot of stuff indeed is clearly EGA/VGA like.

An important hint to casual readers of the last paragraph: I'm just talking about the CRTC programming. That is the part of the EGA/VGA card creating the video timing, the address of the current character and a control bit that creates cursor drawing. I'm not talking about the graphics controller (EGA/VGA port address 3CE/3CF) and RAM/Bus interface controller (EGA/VGA port address 3C4/3C5). The graphics controller just doesn't exist on MCGA, and the RAM/Bus interface controller is completely different, and not programmable using the EGA/VGA port addresses. That paragraph is not intended to mean that the statement "the MCGA is a slightly cripppled VGA" is accurate.

Now about the font loading: It differs from the EGA/VGA model in nearly every possible aspect. That's not too surprising in the end, as the EGA/VGA model is optimized for video display using the font, whereas the MCGA model is optimized for being transferred by the font loading DMA engine. Font loading seems to work like this:

You have four "font staging areas" at A000:0, A200:0 (aka A000:2000), A400:0 and A600:0. This is the low 32KB of VRAM that is not mapped into B800:0 and up. Each of the staging areas is obviously 8KB, which is "just like EGA/VGA", but it's used completely different. The layout is like this: The 8KB is split into 16 parts of 512 bytes each, one part for each scanline. This tells us that there is a maximum of 16 scanlines per character (and if you take a look into the CRTC parameters: The maximum scanline register is always 7 there, indicating 8 scanlines, even in 400-line text modes. Seems like there is a "*2" bit somewhere in the control bits!), but it doe not yet explain why we need 512 bytes a single 8-pixel row of 256 characters. It appears the hardware is built to support incremental loading, although the BIOS does not use it (see below for why). The 512 bytes are divided into 256 words, with the low byte indicating the character number this line is to be loaded to, and the high byte containing actual character data. If you just want to reload the shapes for the 50% fill block character (0B1h), the 100% fill block character (0DBh) and the top-half block character (0DFh) in 8x8 mode, you would fill the memory like this:

1A000:0000   B1 AA DB FF DF FF
2A000:0200   B1 55 DB FF DF FF
3A000:0400   B1 AA DB FF DF FF
4A000:0600   B1 55 DB FF DF FF
5A000:0800   B1 AA DB FF DF 00
6A000:0A00   B1 55 DB FF DF 00
7A000:0C00   B1 AA DB FF DF 00
8A000:0E00   B1 55 DB FF DF 00

After setting up the staging area, you can start DMA by setting the source block into bits 4/5 of CRTC register 13h and the number of characters to be transferred (-1) to CRTC register 14h, finally starting DMA by setting the top bit of CRTC register 12h. The next-to-top bit of CRTC register 12h chooses between fast and blanking-only transfer (according to Ralph Brown's list), and the third to top bit selects whether characters should be loaded into the range 0-255 or 256-511. MCGA supports 9-bit fonts (aka dual font operation) just like EGA/VGA.

To find out that the font transfer is finished, poll the top bit of CRTC register 12h. It auto-clears if DMA is done.

IBM does not use incremental loading in the EGA-like (I don't dare to write compatible) BIOS, because you can upload up to four character sets into the EGA card and freely choose which set is used for display, whereas the SRAM can only hold one font (of maybe 512 chars). You seem to be unable to select which half of the SRAM you use in 256-char mode. This means that the "load font" BIOS functions do not upload to SRAM, but just to VRAM. The select font BIOS function on the other hand, that just changes a single register on EGA/VGA runs the DMA process of the selected VRAM blocks into SRAM. If you specify a different block for low-intensity and high-intensity characters, this means DMAing the whole 8KB everytime you call this function. This function is thus way more expensive on MCGA than it is an EGA/VGA.

While you can incrementally update the VRAM fonts using the appropriate BIOS call, the SRAM needs to be loaded from scratch if you switch between different font banks, so the VRAM needs to have a complete copy of all of the four prepared fonts, and incremental SRAM update is unsupported by this API. This also means that font updates only get effective after you uploaded the characters and selected the bank again, whereas font updates on EGA/VGA take effect immediately.

VileR wrote on 2020-09-29, 00:22:

BTW: another font-related mystery with the MCGA models is the existence of four undocumented alternate character sets (this stuff). They come from a couple of Model 30 and 35 ROM dumps where the odd and even images are 64K each (128K interleaved). To this day I haven't been able to find a single reference to them, or to determine whether anything in the firmware even uses them at all. You seem to be very familiar with these models, so perhaps you have a lead? 😀

I am only familiar with those models because we got them from company surplus (when they were heavily outdated) and I am a hardware geek that is interested in all that stuff. I don't have access to a magic source of odd IBM hardware, like some other person that can get into Computer Reset to choose power supplies to blow up (to get back to the topic of this thread...). That's also a separate interesting question: How is this executive workstation power supply supposed to work? The power switch is on the monitor, and monitor power is just connected using a three-wire mains cable. Do they send a "power on" signal through the VGA port? Do they use a master/slave setup that the power supply detects monitor current draw and powers on as soon as the monitor draw current?

The only two PS/2 model 30 ROM sets I can access right now are already on the internet, so no news on that.

hooking into the monitor discussion, is it just me or do these look like trinitron tubes?

imi wrote on 2020-09-29, 10:03:

hooking into the monitor discussion, is it just me or do these look like trinitron tubes?

Yep that tube looks like it has the signature cylindrical shape of a Trinitron or Diamondtron tube

I don't think DIamondtron was a thing yet though back then, as Sony's Trinitron patent only ran out in 1996 ^^

(Continuing the video-related discussion. Clearly off-topic by now; I'd ask a moderator to split it, but I know it's an annoying bunch of work). 😀

mkarcher wrote on 2020-09-29, 08:46:

A consequence of the 16-bit design of the Hercules card is that the CRTC of the hercules card runs at a character clock that is the dot clock divided by 16, essentially it produces 45 "characters", each 16 pixels wide, to get to 720 pixels per line. On the other hand, the CGA card in monochrome graphics mode runs the CRTC at dot clock divided by 8, so it is programmed to produce 80 "characters", each 8 pixels wide, to obtain 640 pixels per line. The 320-pixel mode runs the CRTC at the same timing, it just "merges" to 1-bit pixels to one 2-bit pixel in the output circuit (more in depth, its basically the other way around: the 640 mode splits two-bit packets into two single pixels).

Appreciate the info - I never looked too deeply into the Hercules monographics stuff, but I did notice those 16-pixel wide "characters" when I had to find out something or other related to timing. So that explains why they went for that odd-looking scheme (and also, I think, why the H/V refresh rates for Hercules are subtly different from the MDA ones... I suppose they were lucky that 5151s and the like *did* have a bit of tolerance after all).

About CGA, that makes sense, since after all the data rate for the 320/640-pixel graphics modes is the same. The clock need only be doubled for 80-column text mode, so that two bytes (character + attributes) are transferred for each character period.
As you may be aware, with that doubled clock rate, other timings are not necessarily adjusted to compensate - the hsync pulse width for one is effectively halved, unless manually reprogrammed. For the composite output, this means it no longer fully overlaps with the NTSC color burst... which is effectively ANDed with the hsync pulse. This single fact caused no end of headache with the color output for 8088 MPH, and is the reason for the 'calibration' screen you get at the beginning.
I'm still wondering whether that was a bug in the CGA design, or a feature....

Now about the font loading: It differs from the EGA/VGA model in nearly every possible aspect. That's not too surprising in the end, as the EGA/VGA model is optimized for video display using the font, whereas the MCGA model is optimized for being transferred by the font loading DMA engine. Font loading seems to work like this:
[...]

Woah. Very well, I'm now fully convinced of the weirdness of MCGA. 😀

Since it's clearly a specific and optimized design on its own, rather than just a simple budget-version VGA (or an extended CGA), it's a bit puzzling that IBM expended all this engineering effort on a device intended for the budget low-end models... ones which were otherwise almost-obsolete on introduction!

The only two PS/2 model 30 ROM sets I can access right now are already on the internet, so no news on that.

In the interests of research, this is the one I was referring to -

There's also a similarly sized set for the Model 35 (even/odd, 64K each). For the 30, I do have sets for 4 different revisions, though only at the more common 32K-per-chip.... and I can't guarantee that they're all good dumps.