VGA Mode X and how it helps games 

I didn't know it was possible to make the page wider - I thought that horizontal scrolling required you to at least update one full vertical column of pixels for every pixel you scrolled... and that you could only have more than what's visible in vertical space... :O

Me either, but these things do have a nice nostalgic feel to them.

yes I used in turbopascal to build an 256x256x256 mode for arcarde emulators

And the sheer number of resolutions available by twiddling the registers is pretty crazey. Some early VGA monitors might not play along, but you can get a ton of really non-standard modes out of it.

@@Damaniel3 And if you made a real mistake, the monitor smoked and the flyback transformer burned

They should (and were usually) called Tweaked Modes.

@@mibnsharpals I got really scared that something like that would happen when I tried 400x300 and 400x600 modes with our family IBM PS/1 (Model 2011? I'm not sure, but it was the only 286 one I think - the monitor was part of the thing, in fact only the monitor had a power button and there was a power cable from the monitor to the computer itself).

It would have been great fun to do this back in the day. My experiments were limited to the VESA BIOS functions of my SVGA card which were really slow. I didn't have access to BBS so there was quite a shortage of info until about 1995 for me.

@@PCRetroTech Feel a bit silly as you mentioned most of what I wrote, as I was watching your video! Yes, I tried to find anything I could on the boards, and my bible at the time was "EGA/VGA a programmers reference guide" which listed all the registers etc, and I still have it! Thanks for the videos!

Wow... having programmed all of these back in the day... I am only TODAY learning that the reason it was called "unchained mode" is because Mode 13h was "chained" for linear addressing. Thank you.

@@Stabby666 I have tht book too. As a kid I used to read pages of it in the book store but couldn’t afford it. I bought it online a few years ago. Great bible of old video cards.

Glad it helped. You might find after this whirlwind tour that some of the more technical stuff makes sense now. Michael Abrash's articles will almost certainly help. They are written in a very easy style.

I'd love to know about “Tweaked Modes” on EGA - I've only heard of them on VGA. The closest to compare on CGA was the 160×100 16-color graphics mode, that in reality ran in text-mode. Using vertically half-block characters so using one of 16 foreground and background colours to double horizontal resolution from 80 characters to 160 pixels, then setting character height from 8 to 2 pixels, turning 25 vertical resolution to 4 times (=100 pixels). But I never knew of any EGA Tweaked Modes =)

Yes, there are really a lot of options with VGA. Each individual implementation is probably also full of really interesting glitches that can be exploited.

@@PCRetroTech I know ;-). I used to have custom modelines in my XFree86 setup, so that I could play around with odd resolutions. I used to have a IBM 8503 monitor, that I got up to 800x600 this way as well, but on the kernel command line. It was a monochrome monitor and it was attached to the system I used as my firewall / gateway, but it was fun ;-).

Many emulators do that. Nesticle, Genecyst and ZSNES support Mode X.

@@damouze Was that with just VGA though, or SVGA? The highest "Tweaked modes" I've known was 400x600, and it didn't work with the VGA monitor of our family IBM PS/1's monitor - it basically required same horizontal refresh rate as 800x600 mode, you can think of it as 800x600 with horizontal resolution halved. Later when we bought a new computer with SVGA that could do up to 1280x1024 I finally got to see that mode (as well as 400x300) working.

@@janisaksa999 The card was definitely SVGA. It may even have been the onboard graphics adapter of an Intel Atom desktop board. In those days I was willing to try out everything that could run Linux ;-).

Thanks!

@@PCRetroTech This is the best part: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-9JNnFOVlFAU.html

@@dpx Thanks. I remember spending quite a long time trying to get the takes exactly right on that explanation. I wish I had not just filmed my computer monitor though, as it turned out a bit blurry.

@@PCRetroTech It's not blurry at all!

That's very interesting, and would suggest that it somehow manages to emit wait states only when there is a conflict, rather than every time VRAM is accessed. That sounds like I should run some experiments on that, as I don't think it is widely known (though what would I know; I know far more about CGA than VGA). Thanks for sharing that insight!

That's very interesting... But the first thing it makes me wonder is if there was a reason that the games couldn't do the rendering during the vertical blank? I would also love to test out if it would still be faster to copy backwards during vertical blank.

@@janisaksa999 I'm sure games could render during the vertical blank. But I see no specific reason to do so, other than to prevent frame tearing. The vertical blank is only a relatively small portion of the frame. There isn't enough time to render a full screen then, unless you have really souped up hardware.

At 14:20, the split screen feature (of the VGA and EGA) might be used. Not sure if that works on MCGA though. I know very little about MCGA

Sometimes the algorithm just works!

@@MissNorington I'm not 100% sure, but I don't think MCGA supports it.

I was similar. I was convinced all the secrets were in the BIOS functions, mainly due to the Ralph Brown list, which everyone seemed to be passing around. I knew about timing cycles and tight loops in assembly, but was clueless about register level programming of the hardware.

Yes, it's probably more widely known as Mode 13h, but I guess I ended up calling it mode 19 due to the sources I was using.

@@PCRetroTech I'm still unclear on how hex numbers should properly be pronounced, and I'm not even sure there's an informed consensus on that: Some people seem to say things like "mode thirteen" or (more rarely) "mode thirteen (h)aitch", which has always sounded confusing to me, like they don't know it's hexadecimal (this especially applies to speakers who omit the h suffix). In that sense, saying mode nineteen may even be more unambiguous, though I would agree that it's probably much more commonly known as mode 13h, however that's pronounced. PS: 0xD is the real thirteen hex. ;-D

Awesome. Are any of your demos available? It'd be cool to take a look.

Two monitors. I'm amazed you tried again. Was it the same brand?

Oh yes, thanks, so it is. I somehow got this transposed after watching Hakemon Mike's video. I wonder if any of the errors correspond to the bodge wires in my earlier Model 30!

@@PCRetroTech: "I wonder if any of the errors correspond to the bodge wires in my earlier Model 30!" I have one Model 30 planar that is the same PCB color and also has the same bodge wire - marked by pen on the underside as "02/87" (the initial models of the PS/2 series were introduced in April of 1987). On my planar, the RAMDAC is socketed (the only time I have seen that on a Model 30, or even a PS/2 planar otherwise - more possible details below). It also has the first ("Revision 0", EPROM pair 68X1627/68X1687, 2 September 1986) BIOS of the four released for the Model 30. The planar is marked as 61X8499. A later version is marked as 61X8825 without the bodge wire (this marking is on the corner underneath the drive carrier - you won't see it except for an extracted planar). These are the so-called "P-Planar" (marked more visible by the FPU socket). They also typically have the MCGA gate array chip marked 72X8300 - which had an "ECA" (IBM's Engineering Change Announcement - in this instance ECA 023) that the 'Type 1' Model 25 planars showing a particular fault were to be replaced with a 'Type 2' planar that used the 11F8028 MCGA gate array chip instead - There seems to be no comparable ECA for the Model 30, however - despite a later version (the "Greenock planar") being available for it (also with the 11F8028). IBM typically released planars with a ceramic RAMDAC first, then in later versions, in plastic packages. When a plastic RAMDAC was paired with an early VGA chip, many times there were additional diodes soldered on top of the RAMDAC as well. Later VGA chip versions didn't do that. My Model 30 could have been a comparable attempt to check out the RAMDAC packages - sometimes there are still ceramic RAMDACs on the "Greenock planar" or another variant I found of it that includes the MCGA "Feature Connector" as well. I'm interested in which BIOS version you have, the first change was supposed to fix a font issue: PS/2 Model 30, 8086-8MHz CPU BIOS Versions: 68X1627/68X1687: 09/02/1986 - Revision '0' 61X8937/61X8938: 12/12/1986 - Revision '1' 61X8939/61X8940: 02/05/1987 - Revision '2' - Revision '3' not released - 33F4498/33F4499: 01/31/1989 - Revision '4' Yes, I have all of those dumped, with images online - thanks to spurring from "Hakemon Mike". I have high-resolution photos of all the Model 25 and Model 30 planars that I am referencing (except for the earliest identified above - I need to get that photo today and get the other pictures better organized).

Note that the bodge-wire goes directly to the 72X8300 gate array chip - I need to find out what that pin is from the schematic. There isn't a comparable bodge-wire on the 'Type 1' Model 25 planar - but I see a circuit connection from that pin 13. This is the text of ECA 023: ECA 023: 8525 Display Characters M/T [Model/Type] 8525: ERRONEOUS/FALSE DISPLAY CHARACTERS THIS ECA EXPIRES 12-31-93. PHYSICAL CHECK: Affected 8525 systems will have part number 72X8300 printed on the video control gate array chip. This chip is in position U11 on the 8525 system board. U11 is a 1-inch square chip located near the system board memory. Only system boards with P/N72X8300 printed on the chip are eligible for replacement under this ECA. DETAIL: If problems are experienced with an 8525 using an application that loads more than one character font into memory, the system board may require replacement. An additional character font may also be referred to as an "extended character set." These problems may be reported as erroneous or unidentifiable characters, or characters that are unexpectedly underlined, and may occur intermittently. If these symptoms are reported, and if the chip in position U11 meets the physical check requirements, replace the 8525 system board with FRU P/N96F7390. Changes have been made to the current level 8525 system boards to eliminate these problems. NOTES: Order parts through normal distribution. All replaced system boards should be returned via UPR. RECORD ALL TIME AND MATERIALS TO SERVICE CODE 33, ECA023, AND OTHER OFFICE 990. Note that there was one version of the BIOS shared between the 'Type 1' and 'Type 2' planars - but identified differently in an external FRU, most likely that it was intended to also distinguish between the planars. A later version of the Model 25 BIOS is supposed to exist, but I've not encountered it in the wild (and possibly it was like the Model 30 "Revision 3" BIOS that doesn't appear to have been released.

@@IBM_Museum Interesting indeed. It looks like they just replaced the entire board when this happened. But as it says, modifications were made to work around it. That would fit with bodge wires plus a later revision board.

@@IBM_Museum On the machine with the bodge wire I have Revision 1 BIOS chips and the planar is stamped 61X8499. Inside the drive bay is stamped July 1987. I'll pull my other machine out of storage and take a look.

VGA added additional palette registers for EGA. Beyond that I can't speculate.

The EGA and the MCGA approach graphics card design from a completely different way. While the CGA card used 8 bit DRAM, and had to manage concurrent access to that DRAM from both the processor and the CRTC, that technique proved to be incapable of generating either the data rate required for 640-pixel 16 color modes or 320-pixel 256 color modes. On the EGA, IBM widened the memory to 32 bits (factor of 4). That perfectly matched going from 1-bit color to 4-bit color at a horizontal resolution of 640 pixels horizontal. And that's where the planes of the EGA come from: every address in video memory is backed by 32 bits, and unless compatibility tricks are engaged (they are in all EGA/VGA modes except the 16 color modes), the 64K 32-bit memory locations are mapped to 64K 8-bit locations in A000:0000 till A000:FFFF. One way to deal with having 32-bits of memory behind an 8-bit interface is just being able to choose which of the 4 8-bit subsets in the 32-bit memory is forwarded to the processor bus - but a lot of power of the EGA comes from providing other modes of accessing the 32-bit memory, too. All software written for 16-color EGA modes interacts with the complex EGA chip called "graphics processor" that deals with the 32-bit memory and mapping it to the 8-bit bus. On the other hand, the MCGA runs at a whopping 25MB/s in 256 color mode, and all video RAM it has is just two 4-bit chips, so it is still an 8-bit design. The trick they pulled on the MCGA is one often used on high-resolution cards: They did not use standard DRAM, but a special type of DRAM that allows to push a whole column (256 cells in the case of the MCGA memory) into a shift register, that can then be clocked at a high rate to the outputs without requiring any addressing, and without occupying memory bandwidth. This kind of RAM is called VRAM. So the access rate to the actual DRAM for the scanout dropped by a factor of 256 (transfer a whole row every 256 cells) compared to the access of individual cells, as it is done on the CGA, EGA or VGA card. So the MCGA design is completely incompatible to the way EGA/VGA 16-color modes are programmed. I expect the modes 11h and 13h on the VGA card to be explicitly designed in a way that you don't need to deal with the 32-bit memory stuff in software at all, as all the plane stuff is hidden by the graphics card. This allows software to not need to interface with the graphics controller and just access the memory. So these modes are implementable by the MCGA hardware that doesn't have 32-bit memory access and a graphics controller. IBM knew what they were doing when designing the EGA compatible high-end VGA card and the cost-optimized MCGA at the same time and designed these modes in a way that they work on both kinds of hardware.

I'm not sure what you are referring to. The native EGA graphics modes are planar. Perhaps you had an adapter which had additional modes. Or maybe I'm misunderstanding. Text modes worked the same way as CGA. But you still had to deal with the character/attribute interleaving and low resolution.

@@PCRetroTech Weird, I have to get myself a copy of Turbo Pascal 6.0 for DOS, I have most of my 16-bit code still available for TP when it comes to these graphics, and try these EGA things in DOSBox, DOSEmu and IBMUlator if they work the way I had written them... If IBMulator is the only where they work, it may well be because that PS/1 VGA adapter did something special...

@@PCRetroTech After some thinking I've come to admit that perhaps my memory has betrayed me here. I don't remember ever having learned that EGA (and VGA?) work like you describe, but after quick calculations I realize that 640x350 and two pixels per byte would take more than 64K and thus would *not* fit in one segment of RAM, so it's impossible for them to have worked like I remembered. I did write my own graphics library, but I focused way more on VGA 256-color modes (the chained 320x200 and the tweaked modes) than anything else. I did write code for CGA and also text-modes (graphics using the block characters), and I have done graphics in EGA & VGA 16-color modes, but it's possible that instead of my own library I was using other libraries for them, perhaps complemented with my own functions... I'm feeling a bit embarrassed about this, especially when I realised that memory thing, it should've been obvious to me that it wouldn't fit... One thing I'm pretty sure of is that I certainly didn't know it worked the way your describing :p I guess I have to thank you then, for you've taught me something new I wasn't expecting at all, *and* that new wasn't just something I didn't know but something I was actually wrong about - so thanks \o/ :)

@@robsku1 I'm glad you've managed to figure it all out. I've learned that my memories often betray me, more so as I get older, unfortunately. They were great times for sure and a whole component of retrocomputing is accurately recalling what actually happened. Even the greats of the software and hardware industry have sharply dissonant recollections of what actually happened back in the day. There are archivists like Jim Leonard and historians at the big museums who work pretty hard to find hard evidence to support one or another set of recollections and try to narrow things down. I have to wonder if retrocomputing will end up being taught in universities in the future as an academic course.

@@PCRetroTech LOL, also to clarify one thing some may find weird that I forgot to mention: Not sure if you noticed, but I replied from a different account that I wrote my original comment from. This is because I had been logged in with the wrong account (mine nevertheless, but not meant for RU-vid that I use a different account for) and I switched to my correct “dedicated to RU-vid” account - that also happens to be my very first Google account that started its life as just plain RU-vid account as (IIRC) it was before Google had even acquired RU-vid :)(although I still programmed for DOS and was especially into playing with graphics, I didn't really do any non VGA/SVGA stuff in the early 00s). But yeah, something one did over 20 years ago is sure to be a bit fuzzy - what feels so weird about this is that it's such a vivid memory in my mind that I wrote a function to put a pixel on screen with this method in 16-colour mode. I hope I'm not in error about CGA too, but maybe I'm actually confusing this with CGA's 4-colour mode (with 4 pixels stored in one byte, 2 bits each - tell me I'm right about that one? :D )... That would give me a clear origin from where this false memory likely would have come from. If there's anything I've learned from this is to not be so sure of myself when talking of stuff I remember from decades ago, LOL - unfortunately the first time I read someone talking of this planar mode EGA graphics worked in (also in RU-vid comments) I acted way too confident (to put it in kind-to-myself words) and simply said the person was full of... Erm, regrettable. But the memory of it felt *so* freakishly real that the conclusion that the other person didn't know what he was talking of felt like the only possible option. And that's despite me already knowing all kinds of things about false memories like this - at least in theory. Well, it's a good lesson in humility I guess, LOL :D

You could also test it by modifying the source code of DOSBox.

It runs worse than I expected. Could that be because the music is enabled? It requires software mixing, so would really drain a slow CPU. If so, it probably runs the game a lot better with music off.

It's even worse with Pinball Illusions, the incredibly slow speed on a 386 when it runs fine on an A1200 o.o;

@@NozomuYume custom-chip usage on the amiga?

@@drzeissler See, the funny thing is that ModeX has hardware scrolling, so it doesn't have to do big screen redraws. It doesn't have the planar lighting effects (256-color VGA doesn't have bit-level planes like the Amiga does), but it can still get away with limited writes. It doesn't have sprites for the balls but the extra CPU oomph and graphics bandwidth should make up for it somewhat.

I guess the colour ends up being an index into a palette.

My information was taken from Abrash's article (he was credited with invented the mode). It is true that later it referred to any hacked mode of a certain kind. You can look at the information in the description if you want an authoritative reference.

@@PCRetroTech well, I did a search *after* commenting and found that same article: indeed, he called Mode X the 320x240 256-color mode, while what I was mentioning was the 320x400. Confused memories and personal fondness with the 400-scanline mode from back in those days, led me to retroactively see the 320x400 one as the only one called Mode X. "Mine" was still pretty famous, though; maybe not with video games but definitely as the one Windows XP used as a loading screen. :)

@@furrball Yeah that was definitely one of the important defining modes of VGA for sure.

I hate to break it to you folks, but the Windows XP startup screen was actually 640x480, 16 color VGA mode. I just pulled screenshots from a virtual machine to confirm this. It's Windows 95 and 98, probably ME as well that used 320x400, 256 colors for the startup screen. I guess you folks can be forgiven for the error though, as all those old OSes have been out of daily use service for quite a long time.

@@southernflatlandno problem, and thanks for correcting my mistake. Yes, I probably remembered the earlier 9X versions and somehow transposed those memories to the later XP times. My bad. :)

To be honest, it didn't bother me when I was playing as a child, as long as the games were running. The only exception were my own GW-Basic programs. When a circle wasn't a circle because of that.

What I never understood was why Id Software chose to use unchained mode, but still went with 320x200 resolution instead of 320x240 - which is why for example the cacodemon sprite is not shaped like circle, but like oval when you extract it and view and resolution with 1:1 pixel aspect ratio :O edit: forgot to say I was talking about DooM.

@@janisaksa999I know the answer. They said it somewhere in another interview or it was in the book "Game Engine Black Book: Doom" or "Game Engine Black Book: Wolfenstein 3D". The reason was Deluxe Paint, it runs only in 320x200. To use 320x240 the artist would have had to take this into account. And that's difficult when the pixel art in Deluxe Paint was made at a 320x200 resolution and then gets distorted in 320x240. If there had been an equivalent, good, well-known graphics program that worked in 320x240, then they would certainly have used that.

@@janisaksa999 Maybe performance had something to do with it. When DOOM first came out, only users of the (then) very best rigs could actually run it fullscreen; most users reduced the viewport to some extent. Not having to render more lines would have made a difference.

@@janisaksa999 I checked my information above again today and looked for where I found out about this and found the source. It's in the book Game Engine: Black Book Wolfenstein 3d on page 124. This book only applies to Wolfenstein3d, but in the other book about Doom that I mentioned above,, it is pointed out again that that they continued to use Deluxe Paint for the pixel art. BTW both books are available on github, you only have to create the PDF yourself. This can be easily done on a Linux machine.