One note of clarification: when I discussed horizontal smooth scrolling, I oversimplified a bit. In fact one needs to adjust the start address and the PEL panning register to scroll by one pixel at a time. One also has to make the page wider than the screen so that there's something to scroll onto the screen. Those are technicalities that you need if you are going to code it up yourself. My description in this video is simplified to give the overall big picture without getting too bogged down in technicalities. All the details are in Abrash's book of course.
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
That brings memories. My nickname here, movax20h is based on some of the VGA modes initialization sequences. I forget which one, it was more than 22 year ago.
What's fun about 'Mode X' is that nowadays it refers to basically any of the many non-standard modes achievable by poking VGA hardware directly. As always, an excellent video. Thanks for sharing.
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.
@@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).
For the backwards rendering from bottom to top, we did experiments and we found the memory copied faster backwards than forwards, so we would copy backwards on all non-Mode X games we converted. We never knew an official reason for this, but our guess was that there was a race condition between the CPU writing to the frame buffer, and the DAC reading from the frame buffer to output to the monitor and because the CRT is scanning forwards through memory, it would continually hit a write/read scenario for a block of scanlines, whilst copying backwards, the CRT read and CPU write would cross each others paths quickly. We suspected a write + read would result in a stall.
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.
I remember learning all about the VGA registers back before I even had proper internet - just bulletin boards. Mode-X was also referred to as "unchained mode" as it unchained the bit planes to free up all the memory (mode 0x13h would waste 3/4 of the video RAM by chaining the planes together to make it simple to draw a pixel, but losing out in every other way). This allowed a back buffer, hardware scrolling in 4 directions etc. I used this to write demos at the time (all in ASM) 🤣You could also use the horizontal line compare register to split the screen to allow hardware scrolling with a fixed area for score etc. Was all good fun!
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.
Very interesting topic ! I had many problems figuring out how EGA/VGA mode X worked. I still have some things that I feel are unclear in my mind about how it all works, but it's better now.
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 =)
One thing I always liked about VGA is its flexibility. I have an MSX2 emulator for DOS that actually adjusts the CRTC parameters to provide VDP resolutions like 256x192, 256x212, etc.
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 ;-).
@@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 ;-).
I bricked 2 monitors when poking around in the CRT registers of😅 my obscure Realtek SVGA back in 1993. Mess up the clock rate and the thing went *bbbzrrrt* 😅
I remember trying to get the screen to paint quickly: mov ax, 13h ; int 10h ; in mode 13h I had access to page flipping in VGA but I didn't know much else about it. I was still a little kid and didn't really grok a lot of this stuff fully. I tried even using the faster string copying functions if x86 to rapidly copy square sections of RAM over the screen and it was never that fast. I always marveled at the stuff demo coders were doing...
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.
Just happened to work on a ModeX game right now, and I have that IBM with the red power switch and the MCGA inside (in my collection). Crazy video recommendation!
@@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.
All very nice, but I'm baffled to hear this thing about EGA again. I wrote my own graphics library for text-modes, CGA B/W, EGA and VGA modes and to my best recollection the EGA 16-color modes worked exactly the same as VGA 16-color modes. That is, each nibble of a byte represented one pixel (4 bits = 16 colours). I certainly didn't come to dealings with these planes before I learned about ModeX (and what exited me more, Tweaked modes - you should have talked more about them ;) ). You know, 320×400, 320×480, 360x480… and even 400×300 & 400×600, but I never got those to work as long as I was limited to just VGA. It wasn't the VGA adapters fault, it was the monitor's fault. Basically, they need a monitor capable of 800×600, and ours wasn't. It was a very good VGA monitor though, but it couldn't handle that horizontal refresh rate. Basically when I tried it, I ended with a total mess flashing on my screen - and as if that didn't worry me enough, the monitor started making a sound like it was going to explode at any moment. Please, what's this EGA thing all about? I *know* I've never done that, yet I also know that I did use the 640×350 16-color mode in my graphics library… How can that be?
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 RUclips that I use a different account for) and I switched to my correct “dedicated to RUclips” account - that also happens to be my very first Google account that started its life as just plain RUclips account as (IIRC) it was before Google had even acquired RUclips :)(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 RUclips 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
@@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
@1:50 - The schematics are actually for the Model 30 (showing the RTC, which isn't on the Model 25), but since all the components are labeled identically on both planars for each model, it is effectively the same (I'm identifying a project to add the National Semiconductor MM58167AN, 'U16' on the Model 30, to the Model 25 riser as it creating the '8525-U16' submodel). There are also errors on the schematic! But it is an outstanding resource to have available.
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.
Yeah. I made a 3D game and some demos on ModeX, it´s really practical and handy! It´s also part of childhood memory now, so thanx for the ride on the memory lane - or plane? ;)
smooth scrolling on PC is very rare! => beverly-hills-cop on ega ruclips.net/video/-YuFQbghCBMa/видео.htmlnd => titus-ball intro ruclips.net/video/--4XmCKyPqo/видео.html => blood-money ruclips.net/video/4Nvu_CUTKSE/видео.html (don't know what F4 does, but after pressing it, it's smooth)
Now the absence of the 350 scanlines-based graphics and text modes from MCGA I could understand (because 64K, and why have 350-based text modes if you don't support any 350-based graphics modes, plus, presumably the wholesale exclusion of anything 350-based would have simplified the design of fixed-frequency MCGA-only monitors, though I'm not sure if those were ever a thing). HOWEVER, the exclusion of the 640x200 and 320x200 16-colour modes I find much harder to understand. Y U NO...? Surely including those wouldn't have cost that many extra gates? Am I wrong? Would the planar pixel addressing logic just have been too expensive? Is that it?
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.
would have been nice, if they decided to use 4 grey-tones on 320x200 in cga. that would be nicer than the fairly ugly palettes. but you can use a multicolor-monitor and switch it to monochrome. (never tested it, but should be possible)
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.
@@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.
umm... by my memories, in the mid-90's ModeX referred to any hacked VGA mode deriving from mode 13h (or 19) in particular. Further in particular, it referred to the 128Kb, 320x400 256-color mode, a mode that was so famous it was later used by Windows XP for the start-up screen.
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. :)
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. :)
I have a special kind of contempt for programs who got the aspect ratio wrong,. I can understand choosing 320x200 over mode X for MCGA compatibility and other reasons, like the abundance of better tested code out there, but everyone who used 320x200 _should have_ compensated for the fact that this mode (13h) yields non-square pixels on a standard 4:3 VGA monitor. Mode X's 320x240 is actually a more canonical 4:3 resolution. Sadly, not every mode 13h program _did_ compensate for that, but at least some, though not all, VGA monitors had width and height dials one could adjust to fix things. However, some programs actually included incorrect, insufficiently aspect ratio-corrected artwork _and_ correctly-dimensioned artwork _in the same program!_ What, so I can turn those pots back and forth? So annoying.
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.
One note of clarification: when I discussed horizontal smooth scrolling, I oversimplified a bit. In fact one needs to adjust the start address and the PEL panning register to scroll by one pixel at a time. One also has to make the page wider than the screen so that there's something to scroll onto the screen. Those are technicalities that you need if you are going to code it up yourself. My description in this video is simplified to give the overall big picture without getting too bogged down in technicalities.
All the details are in Abrash's book of course.
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
That brings memories.
My nickname here, movax20h is based on some of the VGA modes initialization sequences. I forget which one, it was more than 22 year ago.
Me either, but these things do have a nice nostalgic feel to them.
What's fun about 'Mode X' is that nowadays it refers to basically any of the many non-standard modes achievable by poking VGA hardware directly.
As always, an excellent video. Thanks for sharing.
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).
For the backwards rendering from bottom to top, we did experiments and we found the memory copied faster backwards than forwards, so we would copy backwards on all non-Mode X games we converted. We never knew an official reason for this, but our guess was that there was a race condition between the CPU writing to the frame buffer, and the DAC reading from the frame buffer to output to the monitor and because the CRT is scanning forwards through memory, it would continually hit a write/read scenario for a block of scanlines, whilst copying backwards, the CRT read and CPU write would cross each others paths quickly. We suspected a write + read would result in a stall.
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.
I remember learning all about the VGA registers back before I even had proper internet - just bulletin boards. Mode-X was also referred to as "unchained mode" as it unchained the bit planes to free up all the memory (mode 0x13h would waste 3/4 of the video RAM by chaining the planes together to make it simple to draw a pixel, but losing out in every other way). This allowed a back buffer, hardware scrolling in 4 directions etc. I used this to write demos at the time (all in ASM) 🤣You could also use the horizontal line compare register to split the screen to allow hardware scrolling with a fixed area for score etc. Was all good fun!
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.
Great content, extremely interesting to someone who did some programming as a teenager but never knew any of these advanced techniques existed.
Very interesting topic !
I had many problems figuring out how EGA/VGA mode X worked. I still have some things that I feel are unclear in my mind about how it all works, but it's better now.
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 =)
One thing I always liked about VGA is its flexibility. I have an MSX2 emulator for DOS that actually adjusts the CRTC parameters to provide VDP resolutions like 256x192, 256x212, etc.
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 ;-).
I bricked 2 monitors when poking around in the CRT registers of😅 my obscure Realtek SVGA back in 1993. Mess up the clock rate and the thing went *bbbzrrrt* 😅
Two monitors. I'm amazed you tried again. Was it the same brand?
I remember trying to get the screen to paint quickly:
mov ax, 13h ;
int 10h ;
in mode 13h I had access to page flipping in VGA but I didn't know much else about it. I was still a little kid and didn't really grok a lot of this stuff fully.
I tried even using the faster string copying functions if x86 to rapidly copy square sections of RAM over the screen and it was never that fast. I always marveled at the stuff demo coders were doing...
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.
Just happened to work on a ModeX game right now, and I have that IBM with the red power switch and the MCGA inside (in my collection). Crazy video recommendation!
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.
This was a really interesting video! I love hearing how these graphic modes work.
Thanks!
@@PCRetroTech This is the best part:
ruclips.net/video/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!
Was sitting here going "WTF is mode 19?!?" -- then I realized you were saying it in decimal.
All very nice, but I'm baffled to hear this thing about EGA again. I wrote my own graphics library for text-modes, CGA B/W, EGA and VGA modes and to my best recollection the EGA 16-color modes worked exactly the same as VGA 16-color modes. That is, each nibble of a byte represented one pixel (4 bits = 16 colours). I certainly didn't come to dealings with these planes before I learned about ModeX (and what exited me more, Tweaked modes - you should have talked more about them ;) ). You know, 320×400, 320×480, 360x480… and even 400×300 & 400×600, but I never got those to work as long as I was limited to just VGA. It wasn't the VGA adapters fault, it was the monitor's fault. Basically, they need a monitor capable of 800×600, and ours wasn't. It was a very good VGA monitor though, but it couldn't handle that horizontal refresh rate.
Basically when I tried it, I ended with a total mess flashing on my screen - and as if that didn't worry me enough, the monitor started making a sound like it was going to explode at any moment.
Please, what's this EGA thing all about? I *know* I've never done that, yet I also know that I did use the 640×350 16-color mode in my graphics library… How can that be?
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 RUclips that I use a different account for) and I switched to my correct “dedicated to RUclips” account - that also happens to be my very first Google account that started its life as just plain RUclips account as (IIRC) it was before Google had even acquired RUclips :)(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 RUclips 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
Sorry, I think in hexadecimal so much that it took me a moment: 19 decimal = 13 hexadecimal (shorthand for me, 19d = 13h)
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
Ntsc artifacting to obtain more colors sounds very cool..
@1:50 - The schematics are actually for the Model 30 (showing the RTC, which isn't on the Model 25), but since all the components are labeled identically on both planars for each model, it is effectively the same (I'm identifying a project to add the National Semiconductor MM58167AN, 'U16' on the Model 30, to the Model 25 riser as it creating the '8525-U16' submodel). There are also errors on the schematic! But it is an outstanding resource to have available.
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.
Great video, thanks!
Nice video
Yeah. I made a 3D game and some demos on ModeX, it´s really practical and handy!
It´s also part of childhood memory now, so thanx for the ride on the memory lane - or plane? ;)
Awesome. Are any of your demos available? It'd be cool to take a look.
smooth scrolling on PC is very rare!
=> beverly-hills-cop on ega ruclips.net/video/-YuFQbghCBMa/видео.htmlnd
=> titus-ball intro ruclips.net/video/--4XmCKyPqo/видео.html
=> blood-money ruclips.net/video/4Nvu_CUTKSE/видео.html (don't know what F4 does, but after pressing it, it's smooth)
Now the absence of the 350 scanlines-based graphics and text modes from MCGA I could understand (because 64K, and why have 350-based text modes if you don't support any 350-based graphics modes, plus, presumably the wholesale exclusion of anything 350-based would have simplified the design of fixed-frequency MCGA-only monitors, though I'm not sure if those were ever a thing).
HOWEVER, the exclusion of the 640x200 and 320x200 16-colour modes I find much harder to understand. Y U NO...?
Surely including those wouldn't have cost that many extra gates? Am I wrong? Would the planar pixel addressing logic just have been too expensive? Is that it?
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.
would have been nice, if they decided to use 4 grey-tones on 320x200 in cga. that would be nicer than the fairly ugly palettes. but you can use a multicolor-monitor and switch it to monochrome. (never tested it, but should be possible)
You could also test it by modifying the source code of DOSBox.
remember, Pinball-Dreams scrolls superbe on Amiga with 7,14 Mhz :)
btw. the scrolling is called parallax-scrolling afaik.
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.
Mode 17, 640x480 Monochrone is for MS Flight Simulator. This must run it in that mode.
umm... by my memories, in the mid-90's ModeX referred to any hacked VGA mode deriving from mode 13h (or 19) in particular. Further in particular, it referred to the 128Kb, 320x400 256-color mode, a mode that was so famous it was later used by Windows XP for the start-up screen.
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. :)
18:15 I love this!
17:57
Wait... how does that work if you have a pallet loaded?
I guess the colour ends up being an index into a palette.
I have a special kind of contempt for programs who got the aspect ratio wrong,. I can understand choosing 320x200 over mode X for MCGA compatibility and other reasons, like the abundance of better tested code out there, but everyone who used 320x200 _should have_ compensated for the fact that this mode (13h) yields non-square pixels on a standard 4:3 VGA monitor. Mode X's 320x240 is actually a more canonical 4:3 resolution. Sadly, not every mode 13h program _did_ compensate for that, but at least some, though not all, VGA monitors had width and height dials one could adjust to fix things. However, some programs actually included incorrect, insufficiently aspect ratio-corrected artwork _and_ correctly-dimensioned artwork _in the same program!_ What, so I can turn those pots back and forth? So annoying.
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.