In 1985, I started writing text-editor code, and doing direct display writes to video memory. The original CGA had a hardware bug that caused static when the memory needed dual-porting, so the fix was to only update the display during the blanking interval. At the end of each line was a brief time to get some writes done; at the end of the screen was a much larger time before the next screen started writing at the top. I don't recall if I used an interrupt to look for the horizontal blanking interval, but certainly looked at the status for that.
Yeah there's no interrupt for that on CGA. But you can program a timer interrupt to go off at precisely the same time every frame because the same clock crystal is divided (different ways) for the CGA card and timer. Of course that means figuring out where you are relative to the frame before setting the timer, which can be done a variety of different ways (e.g. by forcing very small CRTC frames for a while before going into your final video mode, and/or by polling the status register).
Maybe the interrupt in the Gauntlet screen is used for displaying the HUD or status bar at the bottom at the right time? (Thats usually the way it was done in C64 games)
On the topic of CGA cards on 486s, back in the day I actually did put an original IBM CGA card in my clone 386sx-33 and later 486 rebuild. It was added along side my Trident 8900 VGA, OS\2 Warp would allow you to use it as a dedicated text terminal along side your VGA Presentation Manager session.
I feel like that sort of application might have been what they were aiming at here, although most VGA cards would eventually subsume what a CGA card could do.
Looking at Gauntlet, it really looks like the interrupt is being used to display the status bar, as was commonly done in NES games (SMB3, Kirby, and so many others), where the interrupt handler changes the scroll to display the portion of VRAM where the status bar is.
In the video, you seem to misunderstand how IRQ2 in the AT is supposed to work. You are perfectly correct that the IRQ2 pin on the first PIC is connected to the second interrupt controller, and anytime any interrupt that is wired to the second PIC is raised, it is signaled to the first PIC using the IRQ2 line. But the PICs are programmed in a way that when an interrupt from the second controller is acknowledged by the processor, the *second* interrupt controller tells the vector number to the processor, not the first one. So when IRQ14 fires, the secondary PIC raises the IRQ2 input of the first PIC, the first PIC forwards the IRQ signal to the CPU, and then the CPU asks back: "Oh, I see, you want to raise a hardware interrupt. May I have the vector number, please?", and the second PIC responds "vector number 0x76". The hardware in the IBM AT is unable to raise vector number 0x0A at all! So, what is the IRQ2 pin doing in an AT? Is it wired in parallel to the IRQ output of the secondary PIC, like you are showing multiple times in the video, e.g. at 11:39? No, not at all! If that were the case, and even if the conflict between PIC2 and the ISA bus were resolved, e.g. by using a logic gate to combine the signals, the logic of "whenever IRQ2 is raised, the PIC2 provides the vector" breaks down. The VGA card is unable to provide a vector number, it doesn't even get the INTA signal from the processor. Instead, IBM decided to route ISA pin B4 into the "IRQ1" input of PIC2, which results in IRQ9 (as the interrupts on PIC2 are counted starting at IRQ8 instead of IRQ0). The IBM BIOS sets up a handler for IRQ9 that forwards the interrupt to vector 0x0A, and when that handler returns, it acknowledges IRQ9 to PIC2, to emulate XT behaviour. All the other interrupts of PIC2, i.e. IRQ8, IRQ10-IRQ15 are *not* software-redirected to interrupt 0x0A. So on an AT, software expecting ISA pin B4 resulting in interrupt 0x0A being triggered still works just like on the XT. No need to verify the interrupt source. On the other hand, you could also directly intercept IRQ9 at vector 0x71, which is slightly faster, as you skip the forwarding stuff in the BIOS, but in that case, you have to send the EOI signal to PIC2 yourself. You only need to use vector 0x71 instead of vector 0x0A, if you run in an environment where the BIOS default IRQ handlers are no longer active (like a protected-mode environment).
This feature was dropped because it was designed in a way that made it pointless. VGA and probably EGA too has something called Vertical Retrace Interval that can be checked anytime. Of course interrupts usually lead to much faster code, but in this case it was irrelevant, since game code would simply wait for vertical Retrace in "while" loop when game code was processed for a given frame. Raster Interrupts are only useful, when they can reliably be executed on selected lines. However, they are heavily related to sprite/tile hardware, since they can easily change parameters mid-frame. Raster interrupts can divide background into multiple horizontal bars that scroll at different speed. Many Sega Genesis, SNES or Amiga games did this. They can also be used to change palette mid-screen, like water in Sonic games. If they can be executed every line, it's possible to have smooth background gradients, which was very common on Amiga, since Copper co-processor allowed execute small code every line. PC lacked hardware sprites and tiles, so Raster Interrupts wouldn't be useful. They could be used to change palette mid-frame, but VGA had 256 color palette which was enough to assign unique color to every line in 320x200 resolution and there was still 56 colors left, while Amiga had to rely on 32-colors for everything. However, there are games that switch palette mid-screen. Lemmings use 16-color mode, but switch palette at the bottom, so status bar uses different set of colors. It's so rare that DOSBox can't emulate this correctly, at least official release. Overall, there was no need for raster interrupts on PC, since hardware was evolving in different direction.
I would agree with all that. I should have mention the vertical retrace status bit in the video, as that would have been useful. But there's only so much one fits in a video without boring the viewer. Hopefully I captured some of the main points you made here though.
That's an oversimplification, considering the planar Mode X mode where you could trade off colors for much better performance, and the 16 color limitation of 640x480 resolution. Raster based palette swapping could have swapped 16+ colors per line, not just one (the Amiga had a Copper that could do more, but PCs often had a fast CPU). If you don't believe raster palette swapping are a big deal, contrast normal 16 color hires mode on the Amiga with dynamic hires (different 16 color palette each line, for up to 4096 colors). The real problem is that PC hardware was just too inconsistent to make dealing with all the headaches worth it for software developers. So, software developers just lived with the crummy base capabilities of EGA and if they wanted to make something fancier they did that in the prestige Amiga version. VGA had a lot of complex capabilities that were hard to figure out, but you only really needed to use one or two of the most popular modes because that was all anyone else could figure out either. The chunky pixels of Mode 13h were particularly suitable for graphics for Wing Commander that made the 2D Amiga games look dated and the crude 3D Amiga games look pathetic. It really wasn't a question of using raster interrupts. Raster interrupts could have made things nicer, but the basic problem was that PC hardware implementations were too messed up to make it work for software developers.
true. and although there were some technics to almost eliminate the retrace loop, the will not work at all or glitch in other cards, due to different circuit response times. ahhh, fun times.
VGA did have a register to split the screen on a specific line though, to allow a static section at the top/bottom, with the rest able to scroll. Interestingly, there's something similar on a lot of LCD panels (the ones with built in driver chips). It's been a lot of years, so I can't remember if that register could also generate an interrupt :)
It's very reliable. in more modern machines (where more hardware may have IRQ2 triggers)... The "test" for whether the VGA triggered the IRQ2 is to read port 0x3C2 bit 7, and in case it is set you can do something, and then you can clear the IRQ so it can set it anew next time by clearing bit 4 of 0x3D4 index 0x11 .. Also the way to deal with whether some OTHER hardware MAY have used it.. (POSSIBLY at the same time).. is to not replace the IRQ2 routine, but to chain the interrupt-handlers together (If there is an interrupt handler for IRQ2 when you want to set up yours, just get the address to it and jump to it after your code.. it get to check for itself whether the piece of hardware it cares about may have triggered an interrupt or not)..
(amd the MAIN reason to check for the vertical retrace in games.. ESPECIALLY on the PC is.. 1: To reduce flicker; You can build up the next frame at a different memory location and when the retrace-interrupt happens, you simply flip the pages and it all changes immediately.. and 2. In order to actually be able to create games that run at the correct speed. From the 4.77MHz 8088 to a 800MHz pentium 2; There ARE games made for the first that work at the right speed for the last, because the standard graphics modes and their refresh-rates are kind of set in stone and the game don't care for how many cycles it has to wait.. it waits until the screen refreshes)
As I point out in this video, a lot of VGA hardware didn't support it or only supported it when enabled with a jumper. And there is a more reliable way to test using the status port that doesn't rely on the IRQ, as was already the case with CGA. Few games on the PC use the interrupt because it was so intermittently supported. But that doesn't mean they didn't sync with vertical retrace for the reasons you mention.
I suspect it was because the IBM PC's primary use wasn't envisioned to be animated gaming and by the time PC games had become a factor worth addressing better hardware capabilities due to higher scale integration and the resulting more capable custom integrated circuits found on graphics cards overcame the need to stretch capabilities (ex., number of colors, number of sprites) via raster interrupts. Just a guess. One of my what-ifs is to wonder if Commodore and Atari would have been far better off long term if they had, rather than trying to make PC machines, put their custom graphics and sound ICs on PC XT and Apple II compatible expansion cards and provided APIs and cross assemblers to translate the existing Atari and Commodore games to those machines which would also allow cross-pollination of software. The Commodore and Atari machines would have then become the cheaper Apples and PCs without the expansion capability. When the custom sound and graphics ICs were upgraded, the expansion cards would be updated and new computers offered by Atari and Commodore.
Dropped down to point out the same thing you did about PC Gaming. I had C= computers, but my dad worked for a PC clone maker, and used to bring them home. I remember him sitting there playing one game or another and snickering quietly at the choppy low-color animations, and hideous speaker noises. I did not envy him, or anyone else with those expensive business machines.
well one thing that did break through with pc and gaming, which would've happened if there were custom chips or not was that that in early 90s they got so fast that they could do most amiga custom chip things like sprites in cpu but also better - but on top of that they could do things beyond what the older custom chips could do like various 3d rendering methods, sprite scaling, deforming etc because it was just code that was plopping it in the memory and as such more flexible than hardware sprites, hw tilemaps or such. if the custom chips had kept pc's cpu's slower then it would've given more fighting chance for amiga and such - and even then the pc games could've done so much more with the quicker updating hardware that was in addition there to those chips. having a megadrive on a card in a pc wasn't a huge hit anyway for example. later things similar to what you propose were used, but those outdated too quickly as well like the NV1 card. in a way 3d cards kinda did that whole thing.
@@lasskinn474 68k was the better CPU, then ARM2 was the better CPU. Then imagine if we would have used the RISC CPUs of the 32bit consoles, but with a heat sink and a fan and lots of RAM. Also see how we use custom chips today: GPU . See the videos about voodoo . See how complicated sound cards were in a PC .. I still don't get what they all do. Atari Jaguar had a single sound chip + DAC. GBA only had a DAC. So custom chips seemed to be real big in PCs in the 90s.
@@ArneChristianRosenfeldt you don't really need to imagine, since they didn't scale up faster - what you'd have to imagine is if the same amount of money had been put to them as pc cpu's though, maybe they would've had scaled as fast - we are actually using basically risc cpu's now on pc, it's just behind a layer. on pc now too the custom chips aren't custom in the sense that you'd be accessing the chip and limited to it, they're accelerating behind a layer and this allowed gradual upgrade instead of deciding on some pc2 standard with bigger tilemaps in hardware or something. and look basic pc soundcards weren't that complicated at all. fm adlib cards were just basically a bridge to the fm chip and the dac stuff isn't that complicated on a soundblaster either so cloning it wasn't that complicated and more importantly cloning the interface didn't depend on chips from creative. covox was even simpler, it's the simplest there can be, if you ever wondered how a basic dac works then take a look at a covox (and in reverse an adc). a jaguars sound system is immensely more complicated than any early 90s pc sound card was, having it's own cpu to program and it's own ram. gravis ultrasound is more complicated as hardware but it was simpler to use than use software mixing - but that's why it also died. the cpu's scaled so fast that you could do 32 channel mixing in software without it being a major burden and it was a single vendor path. for a while on pc if you were coding your own thing then using a gus was a lot simpler though because you didn't have to come up with your own fast sound routines, but libraries that became available took care of that problem so most coders didn't need to come up with their own, this is also the main reason why some demos had _only_ gus support. arm pc's were a bit popular in some circles in like 2000 and a bit later, mostly for developing arm code with the aim to run the arm code on mobiles.
@@lasskinn474 but RISC was said to be 4 times faster than CISC or so. The CPUs were super expensive when you bought them from Sun or SGI. I guess that the MMU and 80 bit floats ( for a business main frame??) were the expensive parts. The RISC µ-controllers were always cheap. That was at a time when DEC could beat intel in the MHz race. 68k had similar clock rate as did AMD.
The PC floppy drive thing gets weirder, too. I've been led to understand that the termination resistance changed at some point during the 1980s, which would explain why I couldn't get "newer" floppy drives working in the "older" Commodore PC 10-III I had in the mid-'90s -- but I didn't find out about that until about ten years ago.
@@damouze If it had 8-bit slots, those would be limited up to IRQ 7 (and IRQ9 replacing IRQ2 of course). I presume it used the extra IRQs for onboard peripherals? If so, that's quite the expandable XT system you had.
@@BlackEpyon Or it could be that I remembered incorrectly. I was trying to look up the system in question online and I could not find any mention of it having more than one PIC. I also owned an AT class PC of the same manufacturer and that one definitely had 2 PICs. I must have had those two confused. Silly me ;-)
@@damouze An AT would definitely have 2. As I said, it's still technically possible to have two PICs on an XT, but you'd have to get REALLY creative in how you implement it, since the 8-bit slot only supports up to IRQ 7. Most things that could use the higher IRQs are 16-bit cards anyways. So maybe you could make a daughterboard with a few 16-bit slots, piggy-backed onto an 8-bit slot, stack one PIC on the other with some of the necessary pins lifted, and bodge the extra connections to allow for the extra IRQs while the 16-bit cards are running in 8-bit mode. Why the hell you'd do it, I have no idea, but that could be fun as a thought experiment. Something of no practical value whatsoever, but just to say that you did it because you could.
I remember reading about video interrupts back in the '90s, though I don't recall whether I ever managed to use them for anything. I think at the time I had come across a little bit of terminate-and-stay-resident code that would change the background color of the (VGA) screen at a high rate, so it would create color bars rolling up and down behind the text in DOS. Another example I played with caused sort of a flame effect with characters on the screen, though it wasn't very sophisticated. It would have been nice if the interrupts worked to help synchronize that sort of stuff and not cause the CPU to be running at 100%
Raster bars and fire effects were all the rage back in the day. I know a lot of people wanted to do those, mainly because raster bars were really common in early demos and because of the fire effect in Doom I'm imagining.
Maybe, the slight incapability of EGA and VGA cards was out of kindness of the designers of those cards, so that game computers could shine in at least something.
Well sure. I mean otherwise those piddly 8 bit systems were just doorstops. I mean it is not like they could hold a candle to the serious business machines of IBM! Those companies must have considered paying IBM to even be allowed to exist as surely they could have just swatted their hand weakly and they would all have vanished in a big puff of blue.
Sorry for the long-winded ramble, but... Raster interrupts weren't just used for sprites on 8 bit machines. On the Commodore 64, it might be used to display different vertical regions of the screen using different display modes or (as the PC test suggests) changing colours, and also to be able to scroll a part of the screen using hardware scrolling while keeping another part (e.g. score etc) fixed, or even to switch text mode character sets. Basically, the 8-bit graphics philosophy was that the hardware should be able to change the display a lot without modifying the display memory. Also, display memory usually always meant a character-based display mode because bit-mapped graphics were available but memory-hogging and slow. The whole graphics philosophy changed with 16-bit GUI-oriented machines. Seemingly everything was about bitmap-mode frame buffers. Unless you were sadly stuck with an Atari STFM like me you still had hardware acceleration, but it accelerated putting things into and moving them around in the bitmap-mode frame buffers. Blitters ruled, and while hardware sprites still probably existed (not sure) they were probably rarely used for anything other than GUI mouse pointers. The IBM PC absolutely still had text modes, but that's because its philosophy was different again. Just because the early PC had some games doesn't mean it was designed with games in mind. The PC was designed for business applications - text-mode existed but was mostly for the DOS command line and "Text User Interface" applications, whereas graphics modes were mostly targeted at business graphs and charts, and at the obviously-coming GUIs and WYSIWYG application displays (What You See Is What You Get - referring to in-place graphics, proportional fonts, accurate fonts - not using the built-in text-mode font as a substitute - etc). The idea of presenting a different complete frame tens of times per second wasn't really a serious goal because games were mostly considered an abuse of PCs, not a legitimate intended use, until about the time of Wolfenstein 3D and Doom. Games tended to use the undocumented VGA "Mode X" for example. And of course First Person Shooters mostly had to redraw each frame from scratch (other than borders and score areas, which partly existed to reduce the number of pixels per frame to render), so that was pretty much when the 16-bit graphics blitters-etc philosophy was mostly replaced by the 32-bit just-give-me-the-damn-frame-buffer philosophy (at least until hardware 3D acceleration became a thing). There were (and I assume are) still blitters etc, but they were mostly for accelerating the GUI desktop and more serious applications. Once software could redraw a whole frame per frame and avoid the built-in limits of what acceleration hardware could do, that's exactly what games tended to do until 3D acceleration happened. That's very simplified, but the basic point is that the IBM PC never shared the same graphics philosophy that led 8-bit machines to make such heavy use of raster interrupts. In the early days, you could see a single page of text-mode characters updating - the CPU was (for the time) fast, but the ISA bus link to the MDA or CGA display card was slow. "Snow" was common due to the CPU writing to display memory and fighting with the graphics chip that was concurrently trying to read it - after all it only happens while drawing the graph or chart, not while statically displaying it, so why pay to for better hardware to avoid it? Fast graphics simply weren't considered important until approximately the Wolfenstein 3D/Doom era when people actually started buying PCs for games rather than Amigas, at which point it was practical to render (most of) a full bitmap screen per frame, even using 3D techniques that couldn't benefit much from the hardware acceleration available then anyway. I have a dim memory that the old Hercules graphics cards might have supported a split-screen text-and-bitmap mode so you could e.g. see the spreadsheet and the graph at once, and the split might have been handled using a raster interrupt ??? I never had access to one, but magazines of the time went on about them a bit. I suspect EGA and VGA may have gained raster interrupts to be able to do the same thing, and maybe compatibility issues for clone cards even killed that use. Maybe the early multimedia obsession also meant that page-flipping in the vertical retrace (e.g. to avoid tearing in that postage-stamp-sized animation or video clip) was also relevant.
My lack of knowledge of 8 bit machines is probably on show here. But my impression was that it was more common for demos rather than games to use raster interrupts for all those things. I could imagine games using them to scroll one part of the screen whilst another part displayed a score or something fixed I guess. But it isn't quite clear to me raster interrupts were needed for that if they weren't different modes or there wasn't some other reason to use them. Again, that is probably my lack of knowledge about 8 bit machines on show though. Either way you are certainly right they were used for other things too. As for the PC, the original PC was intended as a home computer and games were not plentiful. It seems people were expected to program them in BASIC. But I think I would be happier to say that after this point people bought them for mixed purposes, including games. But the same can be said of the Commodore 64 which was marketed for education and the like. I will agree that many more people probably brought 8 bit machines solely for games.
@PCRetroTech For the C64, I'm fairly sure loads of games used raster interrupts for scrolling - just about anything that used hardware scrolling but kept score and other details unscrolled. Remember that the scrolling registers offset (scrolled) the WHOLE SCREEN by zero to seven pixels horizontally and vertically. If you wanted a fixed region, or differently-scrolled regions for different players, you pretty much had to use raster interrupts. As for different modes - almost everything used text mode anyway because bitmap mode was too slow, so other than colour handling (two vs. four colours) there wasn't much to choose between. However, I confess I wasn't a C64 games programmer except my one thousandth-rate home hobby projects (and didn't become a professional programmer at all until after that period) so I have no insider knowledge, but there's only so many ways those games could be implemented. Some of the "obvious" examples of this split screen for hardware scrolling turned out not-so-obvious. Uridium could possibly be using sprites for the score area, and could be using any of several methods to hide that split-screen transition helped by the fact it only does horizontal scrolling. Paradroid scrolls all directions and is probably using a really good implementation for that split-screen transition, but I haven't ruled out sprites for the score display and more sprite trickery to hide the transition. I did find two clear examples, though. First, Action Biker - very clearly using text mode for both the all-directions scrolled map area and the clearly text-mode score etc details. Second, Kickstart has four obvious character-based regions - each player has his own differently-scrolled region of the map, and this split into two regions is actually split into four due to the unscrolled times-etc regions for each player. A dead giveaway is a certain flickering artifact in the transition between the scrolled and unscrolled regions, which happened because handling the raster interrupt takes time so the changes tended to happen a little (and variable) distance into the scan line. However, that give-away could be avoided. One known method to avoid the flickering transition was make the CPU wait for the horizontal retrace at the end of the raster line once the raster interrupt was entered, with some trickery to make the wait cycle-perfect even though entering the interrupt wasn't. First time I saw code to do that was in a TH-cam video some years ago. I've often thought an alternative might be to use a row of sprites to hide that edge artifact - not eliminating the need for the raster interrupt, but giving several scan lines of leeway where artifacts would be hidden under the sprites. Anyway, fortunately for the games but unfortunately for me, it means it's hard to find an example in a TH-cam video. None of the examples I already listed above have it that I can see (though IIRC Paradroid has some sprite-multiplexing artifacts at times). The one example I found that had those flickering artifacts was Wanted! Monty Mole (top of the scrolling map area, below the score area) - see th-cam.com/video/WU_WUJRTKdk/w-d-xo.html For an extreme example of raster-interrupt-driven scrolling effects, IIRC Pitstop and similar racing games achieved that curving road effect by varying the horizontal scrolling many times on many of the raster lines (maybe even every single raster line) where the road is displayed, and additionally had a scrolled horizon region.
@@PCRetroTech WRT "the original PC was intended as a home computer" - errrm, seems a bit unlikely, more likely small-or-home-offices (SOHO, as they said back then) but maybe - but home didn't mean games. The original PC was released in 1981, before the 8-bit thing really got properly started. The ZX-81 and VIC-20 (both also released 1981) were among the first home computers that weren't bought as a kit with soldering-iron required for assembly. There were a few video game consoles before then, but mostly they were pong-clone things - even the Atari VCS wasn't released until 1982. The idea of home computers for gaming was brand new, and wasn't taken seriously yet. MS-DOS was basically a CP/M-alike for the 8086 rather than the 8080/Z80, and while CP/M started out for hobbyists, again that didn't really mean games. Just because GW-BASIC had that god-aweful game as an example doesn't mean GW-BASIC was for writing games. In time, PCs for gaming became an expensive joke compared with common home computers - but in 1981 the idea of computer games in the home was barely born, and those $1,500-ish 1981 PCs absolutely weren't designed with games in mind. Games were written because programmers will find ways to write games for anything, but that wasn't what they were for. In the UK, if any early PC was going to be sold for games it would have been the Amstrad PC1512. It was certainly aimed at homes at a time when most IBM-PCs and clones went to offices, and it had better-than-CGA graphics and could run the Digital Research GEM GUI, and certainly some games could be played on it, but the launch advertising focussed on applications software and MS-DOS compatibility. After all, the earlier non-PC Amstrad PCW had achieved success in countries where it was marketed specifically as a word processor, but flopped where it was marketed as a computer. The machines intended for games were those ZX-81 and VIC-20 and their descendants such as the C64 (and yes, the Amstrad CPC - an 8-bit and not a PC) and so on, up until the Amiga ran out of steam. That and 80286 and 80386 PC-clones costing around £2,000 in an age where £200 or less for home computers wasn't unusual basically gets you up to around 1990. Yes, games existed. No, the platform wasn't designed for them. If you really want to push the era of PC as a games platform as far back as possible, ID Software was formed in 1990, the 80486 had just been released in mid-1989, and VGA first appeared (for the expensive PS/2 range) in 1987, the same year that the Ad Lib was released (becoming the first widespread sound card, before which PC sound was almost entirely limited to beeps), so the key ingredients were there for ID to work with. But it wasn't really until Doom (released 1993, and getting close to Commodores collapse in 1995) that PCs were specifically bought for games.
@@PCRetroTech BTW - sorry if this comes across as an attack. I was very bored and ended up researching to check a lot of this today because of that, and I'm very bad at tone.
@@stevehorne5536 The original IBM PC was competing with Tandy, Commodore and Apple computers. Up to 70% of IBM PC's sold in stores went to the home. It's in the name, "Personal Computer".
I’ve I were a game producer, I’d be very concerned in keeping the game compatible with a reasonable range of IBM PCs and video cards at the time even if the performance suffered a limited amount
Your videos are great. I only have one favor to ask. Would you mind turning down volume of the game when speaking? It's a bit unpleasant to my ears when I want to hear what you are saying. Cheers mate.
I should have read your comment before posting essentially the same thing. Strong case of AOL Me Too, not to be confused with woke Me Too, except perhaps in- you know what, let's not go there. Maybe I should lurk moar. OTOH, maybe not: Posting with abandon boosts engagement. ;-P
It'd be great if you clarified what EGA and CGA are in each video somehow because those names are both (pre-VGA) for me. I was 6 when I first came into contact with them on my DOS PC and didn't learn what they were until many years later.
There was a graphics mode named Hercules, too. It was mostly for Tandy 1000 systems. A lot of the systems either used this, or composite RGB. For the most part, if you had a 5150 (IBM PC with MDA or CGA) or upgraded to IBM XT or AT (5160 with EGA or higher), it was standard. Mostly you had VGA and SVGA coming out around the end of 1989 and 1990, and all of the systems after that pretty much had it standard. Same with the sound card. Creative Labs 8 Bit cards were available around 1989 or 1990 when I ordered from Computer Shopper. Most of the cards were available and 1991 and 1992, and by 1993-1994 they were both considered to be the standard then.
I did not use the interrupt in my "zolofot" dos asm game, but used the status register. Because this only fires when the monitor is in vertical retrace, it is mostly used to avoid screen tearing and that's all. Timing periods between retrace-es and such trickery is not reliable enough for "real games" in most cases and could create compatibility hell so I understand why they rarely used this for graphics / color changes though. The 8 bit machines had this better - also ep128 my old machine from childhood had it much better because you could program the video chip what actions to do at what scanline (no cpu code was needed, just filling tables like what is the palette in which blocks of the screen or other parameters - maybe even scrolling). I guess the highly "business" nature of IBM kind of disappeared these features from their original EGA/VGA and clones even if they could do something like that would not even try because no one would use the feature 😞 PS.: Sorry... I now looked and I checked an other status bit for vertical retrace.. but then this is basically two things to check the same thing so I understand why it was barely supported when there is the other status bit.
Strange that those EGA cards don't accept the colour update mid frame. I guess they copy the registers to shadow ones during the vertical blank, but why? Maybe it's something to do with the ISA bus interface and reducing contention to low speed registers. Or maybe they found some compatibility issues with mid frame updates so added buffers.
I guess that the hardware designers were lazy and did not believe that programmer could use the short horizontal retrace period to change a colour. A sane solution would be that the chip which sits on the ISA bus just accepts all writes, buffers them, and then applies them to RAMDAC and VRAM on hsync. But you know, buffer is hard to debug, costs money. PCs are cheap.
@@ArneChristianRosenfeldt To be fair it was a technique that few programmers were good enough to take advantage of, and the IBM PC and compatibles were business machines. There just wasn't much call for racing the beam so your spreadsheets could display more colours.
(apologies if this shows up multiple times, I think youtube might have thought it was spam because of a link!) You probably know this, but even though you can't do horizontal retrace interrupts you can poll the registers to find out which line the raster is up to. This lets you do the classic raster bar/copper bar effect even in text mode, which is neat. Of course, you burn a lot of CPU just polling, and it might be tricky to fill that CPU time with more useful work because you need precise timing to do things on precise scanlines. But I think it could be used to get more than 256 colours on screen at once, at least.
Yes I did know about polling and should have mentioned it in the video. But thanks for covering it here. To get more than 256 colours, one needs to change the palette registers in real time. This is actually quite expensive, and I think technically might not be possible outside vblank on some hardware. But it bears investigating.
pooling i/o registers in anyhting above 286 is abysmaly slow and even if you got the timings perfect, it's almost garantined it won't work correctly in most graphic cards due to different i/o response times, bus speed etc. you basically need a "modern" card with fast bus and buffers. sure you can make some pretty cool demos, but anything beyond that is a crapshoot. as PCRetroTech said, changing pallete needs a lot of i/o regs writing, so by the time you did that, the trace will have overtaken. the snow effect is also a consern.
@@theALFESTThat incidentally depends entirely on the RAMDAC used. If it's a cheap one with single ported RAM you will get snow. Better ones use dual ported RAM and will not exhibit any snow.
Sprite multiplexing on the Atari 8-bit computer could be done with Display List Interrupts, but I'm sure some programmers have their own techniques or try using Vertical Blank Interrupts.
Dave Haynie from commoder amiga team said in interview the BOB (blitter object) is more universal and better technique than hardware sprites. Usability of this solution depends on color depth and RAM + gpu frequency. Need of two raster operation to remove old BOB and write BOB on new position. If graphics hardware has enough off screen dedicated video RAM to store sprites like BOB only graphics card is involved in operation without slow down system RAM.
I used horizontal retrace IRQ on graphics chip as new as PCI CL-GD5434 to do dumb shit like having raster bars behind DOS text. It was perfectly reliable way of changing palette on each scanline.
It would be interesting to know if the vertical interrupt consistently worked on original IBM EGA and VGA hardware, and if it was only a sizeable contingent of EGA/VGA clones it didn't work in. If it didn't consistently work on IBM HW either, that'd also be interesting to know. Any estimates on the percentage of cards, clones and original ones out there, this would have worked with? (Granted, that's very hard to estimate, as it kind of requires factoring in things like market share, etc. From your video alone, it _feels_ like absent jumpering and soldering this only would have worked out of the box on like 10% of VGA/EGA cards out there? Is that a reasonable hunch?) Maybe the Gauntlet devs just happened to have a card this worked on and never knew any different until it was too late? The relatively large number of sprites on screen (and "sprites" seems apt regarding the ghosts) looks like a plausible explanation as to why the Gauntlet went that way. The Gauntlet graphics looks unusually lo-rez. Almost like they were 160x200 instead of 320x200 in places, though I'm not necessarily assuming that's the case.
@@PCRetroTech Good point on the IBM VGA card -- the actual card must be rare as unicorn poop. Minuszerodegrees has a pic of their card, aka the "PS/2 Display Adapter". I'll note though that I deliberately wrote "hardware" and not "card", because the former includes IBM's onboard VGA oeuvre. That said, I don't own any of the relevant machines, and I'm guessing you don't either? In any event, it wasn't really a demand, more like an observation or a "throwing it out there"; maybe someone out there knows or can find out some day.
@ropersonline I'd be pretty sure IBM's cards would meticulously match their standards (typos notwithstanding). Edit: except it doesn't. Apparently on the ISA bus, the interrupt is not implemented correctly on IBM VGA hardware. It's technically a PS/2 standard though, so maybe we let them off on this occasion.
Ah yes, a few years ago I also investigated this. I came to pretty much the same conclusions: on some hardware the vblank interrupt works perfectly, on other it is erratic, or not working at all. I never got around to writing everything up in a blog, but was still planning to do so. Worth mentioning though: the PCjr also has a vblank interrupt. It is different from the EGA one, but obviously 100% reliable as all PCjrs are the same. There is no variation in chipset, CPU speed or anything. The only clone is the Tandy and afaik that is 100% compatible with the interrupt as well.
Given that the vertical interrupt technique enables a different class of effects, were there any PCjr/Tandy games that used this that didn't work on most regular EGA/VGA PCs? Just Ghost & Goblins and Gauntlet, those two?
@@ropersonline I don't know if games on PCjr/Tandy even used it, because as mentioned in the video, when you don't have any kind of sprite, scrolling or other kind of hardware, there's not much use for synchronizing to the screen. Besides, it's just a vblank interrupt, not the more advanced raster interrupt that the C64 has, which you can fire on any scanline (which allows racing-the-beam effects), so the usage is extremely limited. Nevertheless, since PCjr/Tandy hardware is not compatible at all with CGA/EGA/VGA/PC speaker anyway, games usually had separate PCjr binaries/drivers, so you wouldn't run the same code on both anyway.
Very interesting, I've been wondering about this myself lately. Ferraro's Programmer's Guide to the EGA, VGA, and SVGA Cards says that the interrupt only works on EGA cards, and on PC class hardware generates interrupt 2, while on AT class hardware it generates interrupt 9. A shame it doesn't work consistently across all hardware!
In EGA/VGA: A Programmer's Reference Guide by Kliewer some of those issues are called out: "a few EGA compatibles do not implement IRQ2 correctly, and the IBM VGA adapter for PC’s and AT’s does not support hardware interrupts (some VGA compatibles do support IRQ2, some do not, and others are switch selectable)". On the EGA compatibles that are badly behaved he says: "These adapters have the status bit reversed (see bit 7 of Input Status Register Zero). Other cards do not correctly implement the Clear Vertical Interrupt (bit 4 of the Vertical Retrace End Register)". More info here archive.org/details/EGA-VGA_Programmers_Reference_Guide_2nd_Ed_Bradley_Dyck_Kliewer/page/254/mode/2up
Maybe gauntlet uses it for making the game run right speed? Have you looked into what trickery was used for textmode smoothscrolling? There were some text viewers and stuff like that 1993-1994 or so floating around bbs's
No I haven't looked into that. I know some tricks for CGA, but to get really smooth scrolling is going to be really hard on the PC. EGA should be a bit easier I think.
I wrote a smooth scrolling ANSI viewer for an art group back in the 90s in Turbo Pascal! The group didn't last long and I'm not sure if they ever released an art pack with my viewer though heh. It was heavily inspired by ACiD art group's ACiD View which also did smooth scrolling.
@@bananaboy41 By smooth scrolling do you mean horizontal or vertical? And by smooth scrolling you mean pixel by pixel without simply rendering the fonts yourself I presume.
@@bananaboy41 did it stay in the textmode and do some trickery or switch to a graphical mode? @pcretrotech yea by that time we had svga cards and i never tested if it would've ran on ega card.
Yeah text mode smooth vertical scrolling, pixel by pixel. Here's an example: th-cam.com/video/2k1yuXiXJCY/w-d-xo.html You can use the "preset row scan register" for precise vertical scrolling in text modes.
Could the differences in interrupt timing be calibrated in the game setup? Also, could this be used to improve performance by writing data to screen in real time without buffering?
When I began to collect "classic computers" in 2006 I thought I would learn how to write in C, and Assm on them to write games for dos and so on... But I don't have time even to play games...(
@@PCRetroTech agree in modern world nobody have much free time... (But maybe in past ages it was the same or worse). I'm a photographer by profession, I collect vintage computers, thought I dont work in IT sphere)
All these raster based operations... in the end your image is limited to horizontal bands sort of. Nothing beats a fast blitter bitmap system provided you have enough video RAM 😅.
The audio mixing on this video is slightly off. The background music is a little bit too loud in places, and your voice-over is a little bit too clobbered by that.
That would not surprise me at all, especially on the PC. Even on 8 bit platforms I don't have a sense of what proportion of games used them. Demo writers use them quite a lot there though.
@@PCRetroTech I remember watching an interview with a game artist from around the time, went over some of the tricks of the trade as he told his story. Will try finding it later.
@@PCRetroTech Found the interview, I hope you enjoy it. "Lucasfilm Games with Mark Ferrari - Retro Tea Break" TH-cam channel: 'RMC - The Cave' Their Retro Tea Break series is a goldmine, I highly recommend it.
That's an interesting question. It's clear why IBM didn't bother with them. They were a business company, and sprites are for games. But other companies could have added them. In the early days, the CGA card took up a full length board, so there was little room for additional hardware. But later on, it could have made sense. I guess that by the time that era rolled around in the PC world, 3D games were the focus. I don't really have a better answer than that. Interesting question though.
Thanks for mentioning it. I wound the game sound way down but a few people have mentioned that they are having trouble with it. There must be some differences in sound reproduction on certain machines.
12:57 its been so long ago i have heard a native english speaker pronouncing "data" right. thanks man, awesome video even tho i dont know much about this stuff in the technical aspect of it, but nonetheless fascinating.
Nope, the correct pronunciation is “day-ta” not “dah-ta” I won’t bore you with how I know this to be so but it involves spelling rules (yes, there are rules to spelling) as well as a linguistics degree.
@@jonchapman6821 It's OK to say /data/... just switch to Latin mid-sentence, say the word, and then switch back to English! Kind of like a raster interrupt! 😄
Australians predominantly use `dayta' but I've been overseas so long that I've adopted many different pronunciations that wouldn't be usual for an Australian. Of course both are "correct" pronunciations as can be verified in multiple dictionaries*. However, some Australians also say `darta` which is another variant again. I would say that is the Strein way of pronouncing it. * There are some people who insist that loan words from Latin (but not from Greek, like `drama' and `panorama') should be pronounced a certain way (`dayta' in this case). But it's easy to find academic scholars who recognise regular usage, not pronunciation "rules", as the only guide to correctness. The other scholars also think I missed some commas and other punctuation though, so they were presumably unable to read what I wrote. So I feel safe writing it here.
@@PCRetroTech btw, i am fully aware there are dialects and accents. as for the creator of .gif files have said the correct way to say it. there is a video out there about it. and i am not as sure about the data, except that is how the said it back then. oh well, did not want to come to this as a discussion as you clearly want to debunk what i said by replying with general language stuff. end of discussion. edit: i see now that you wasnt the first bloke, but yeah haha sorry. i wont censor what i wrote. have a good one.
In 1985, I started writing text-editor code, and doing direct display writes to video memory. The original CGA had a hardware bug that caused static when the memory needed dual-porting, so the fix was to only update the display during the blanking interval. At the end of each line was a brief time to get some writes done; at the end of the screen was a much larger time before the next screen started writing at the top.
I don't recall if I used an interrupt to look for the horizontal blanking interval, but certainly looked at the status for that.
Yeah there's no interrupt for that on CGA. But you can program a timer interrupt to go off at precisely the same time every frame because the same clock crystal is divided (different ways) for the CGA card and timer. Of course that means figuring out where you are relative to the frame before setting the timer, which can be done a variety of different ways (e.g. by forcing very small CRTC frames for a while before going into your final video mode, and/or by polling the status register).
Maybe the interrupt in the Gauntlet screen is used for displaying the HUD or status bar at the bottom at the right time? (Thats usually the way it was done in C64 games)
I realized why the gauntlet game uses the interrupt 2, it's a way of reducing screen tearing and the need for double buffering.
On the topic of CGA cards on 486s, back in the day I actually did put an original IBM CGA card in my clone 386sx-33 and later 486 rebuild. It was added along side my Trident 8900 VGA, OS\2 Warp would allow you to use it as a dedicated text terminal along side your VGA Presentation Manager session.
I feel like that sort of application might have been what they were aiming at here, although most VGA cards would eventually subsume what a CGA card could do.
Looking at Gauntlet, it really looks like the interrupt is being used to display the status bar, as was commonly done in NES games (SMB3, Kirby, and so many others), where the interrupt handler changes the scroll to display the portion of VRAM where the status bar is.
That seems very plausible.
i think it's an arcade game with like a million ports, so perhaps the programmer was used to other platforms
11:12 does the chip labelled music do music or are they just messin' with everyone.
No, that was just a brand I think. It's a video card.
In the video, you seem to misunderstand how IRQ2 in the AT is supposed to work. You are perfectly correct that the IRQ2 pin on the first PIC is connected to the second interrupt controller, and anytime any interrupt that is wired to the second PIC is raised, it is signaled to the first PIC using the IRQ2 line. But the PICs are programmed in a way that when an interrupt from the second controller is acknowledged by the processor, the *second* interrupt controller tells the vector number to the processor, not the first one. So when IRQ14 fires, the secondary PIC raises the IRQ2 input of the first PIC, the first PIC forwards the IRQ signal to the CPU, and then the CPU asks back: "Oh, I see, you want to raise a hardware interrupt. May I have the vector number, please?", and the second PIC responds "vector number 0x76". The hardware in the IBM AT is unable to raise vector number 0x0A at all!
So, what is the IRQ2 pin doing in an AT? Is it wired in parallel to the IRQ output of the secondary PIC, like you are showing multiple times in the video, e.g. at 11:39? No, not at all! If that were the case, and even if the conflict between PIC2 and the ISA bus were resolved, e.g. by using a logic gate to combine the signals, the logic of "whenever IRQ2 is raised, the PIC2 provides the vector" breaks down. The VGA card is unable to provide a vector number, it doesn't even get the INTA signal from the processor. Instead, IBM decided to route ISA pin B4 into the "IRQ1" input of PIC2, which results in IRQ9 (as the interrupts on PIC2 are counted starting at IRQ8 instead of IRQ0). The IBM BIOS sets up a handler for IRQ9 that forwards the interrupt to vector 0x0A, and when that handler returns, it acknowledges IRQ9 to PIC2, to emulate XT behaviour. All the other interrupts of PIC2, i.e. IRQ8, IRQ10-IRQ15 are *not* software-redirected to interrupt 0x0A. So on an AT, software expecting ISA pin B4 resulting in interrupt 0x0A being triggered still works just like on the XT. No need to verify the interrupt source. On the other hand, you could also directly intercept IRQ9 at vector 0x71, which is slightly faster, as you skip the forwarding stuff in the BIOS, but in that case, you have to send the EOI signal to PIC2 yourself. You only need to use vector 0x71 instead of vector 0x0A, if you run in an environment where the BIOS default IRQ handlers are no longer active (like a protected-mode environment).
Thanks for the complete explanation!
This feature was dropped because it was designed in a way that made it pointless.
VGA and probably EGA too has something called Vertical Retrace Interval that can be checked anytime. Of course interrupts usually lead to much faster code, but in this case it was irrelevant, since game code would simply wait for vertical Retrace in "while" loop when game code was processed for a given frame.
Raster Interrupts are only useful, when they can reliably be executed on selected lines. However, they are heavily related to sprite/tile hardware, since they can easily change parameters mid-frame.
Raster interrupts can divide background into multiple horizontal bars that scroll at different speed. Many Sega Genesis, SNES or Amiga games did this.
They can also be used to change palette mid-screen, like water in Sonic games.
If they can be executed every line, it's possible to have smooth background gradients, which was very common on Amiga, since Copper co-processor allowed execute small code every line.
PC lacked hardware sprites and tiles, so Raster Interrupts wouldn't be useful. They could be used to change palette mid-frame, but VGA had 256 color palette which was enough to assign unique color to every line in 320x200 resolution and there was still 56 colors left, while Amiga had to rely on 32-colors for everything.
However, there are games that switch palette mid-screen. Lemmings use 16-color mode, but switch palette at the bottom, so status bar uses different set of colors. It's so rare that DOSBox can't emulate this correctly, at least official release.
Overall, there was no need for raster interrupts on PC, since hardware was evolving in different direction.
I would agree with all that. I should have mention the vertical retrace status bit in the video, as that would have been useful. But there's only so much one fits in a video without boring the viewer. Hopefully I captured some of the main points you made here though.
That's an oversimplification, considering the planar Mode X mode where you could trade off colors for much better performance, and the 16 color limitation of 640x480 resolution. Raster based palette swapping could have swapped 16+ colors per line, not just one (the Amiga had a Copper that could do more, but PCs often had a fast CPU).
If you don't believe raster palette swapping are a big deal, contrast normal 16 color hires mode on the Amiga with dynamic hires (different 16 color palette each line, for up to 4096 colors).
The real problem is that PC hardware was just too inconsistent to make dealing with all the headaches worth it for software developers. So, software developers just lived with the crummy base capabilities of EGA and if they wanted to make something fancier they did that in the prestige Amiga version.
VGA had a lot of complex capabilities that were hard to figure out, but you only really needed to use one or two of the most popular modes because that was all anyone else could figure out either. The chunky pixels of Mode 13h were particularly suitable for graphics for Wing Commander that made the 2D Amiga games look dated and the crude 3D Amiga games look pathetic.
It really wasn't a question of using raster interrupts. Raster interrupts could have made things nicer, but the basic problem was that PC hardware implementations were too messed up to make it work for software developers.
true. and although there were some technics to almost eliminate the retrace loop, the will not work at all or glitch in other cards, due to different circuit response times. ahhh, fun times.
VGA did have a register to split the screen on a specific line though, to allow a static section at the top/bottom, with the rest able to scroll. Interestingly, there's something similar on a lot of LCD panels (the ones with built in driver chips). It's been a lot of years, so I can't remember if that register could also generate an interrupt :)
@@Stabby666 that's the line compare register. as far as i know, it doesn't generate any ints.
The Atari line uses this too, including the 7800 and 5200.
It's very reliable. in more modern machines (where more hardware may have IRQ2 triggers)... The "test" for whether the VGA triggered the IRQ2 is to read port 0x3C2 bit 7, and in case it is set you can do something, and then you can clear the IRQ so it can set it anew next time by clearing bit 4 of 0x3D4 index 0x11 .. Also the way to deal with whether some OTHER hardware MAY have used it.. (POSSIBLY at the same time).. is to not replace the IRQ2 routine, but to chain the interrupt-handlers together (If there is an interrupt handler for IRQ2 when you want to set up yours, just get the address to it and jump to it after your code.. it get to check for itself whether the piece of hardware it cares about may have triggered an interrupt or not)..
(amd the MAIN reason to check for the vertical retrace in games.. ESPECIALLY on the PC is.. 1: To reduce flicker; You can build up the next frame at a different memory location and when the retrace-interrupt happens, you simply flip the pages and it all changes immediately.. and 2. In order to actually be able to create games that run at the correct speed. From the 4.77MHz 8088 to a 800MHz pentium 2; There ARE games made for the first that work at the right speed for the last, because the standard graphics modes and their refresh-rates are kind of set in stone and the game don't care for how many cycles it has to wait.. it waits until the screen refreshes)
As I point out in this video, a lot of VGA hardware didn't support it or only supported it when enabled with a jumper. And there is a more reliable way to test using the status port that doesn't rely on the IRQ, as was already the case with CGA. Few games on the PC use the interrupt because it was so intermittently supported. But that doesn't mean they didn't sync with vertical retrace for the reasons you mention.
@@PCRetroTech
are CGA cards capable to do this raster thing? if not, is there other method in the cga card to achieve this? ty.
There's no raster interrupt on CGA cards. You have to poll the CGA status port 03DAh instead.
I suspect it was because the IBM PC's primary use wasn't envisioned to be animated gaming and by the time PC games had become a factor worth addressing better hardware capabilities due to higher scale integration and the resulting more capable custom integrated circuits found on graphics cards overcame the need to stretch capabilities (ex., number of colors, number of sprites) via raster interrupts. Just a guess.
One of my what-ifs is to wonder if Commodore and Atari would have been far better off long term if they had, rather than trying to make PC machines, put their custom graphics and sound ICs on PC XT and Apple II compatible expansion cards and provided APIs and cross assemblers to translate the existing Atari and Commodore games to those machines which would also allow cross-pollination of software. The Commodore and Atari machines would have then become the cheaper Apples and PCs without the expansion capability. When the custom sound and graphics ICs were upgraded, the expansion cards would be updated and new computers offered by Atari and Commodore.
Dropped down to point out the same thing you did about PC Gaming. I had C= computers, but my dad worked for a PC clone maker, and used to bring them home. I remember him sitting there playing one game or another and snickering quietly at the choppy low-color animations, and hideous speaker noises. I did not envy him, or anyone else with those expensive business machines.
well one thing that did break through with pc and gaming, which would've happened if there were custom chips or not was that that in early 90s they got so fast that they could do most amiga custom chip things like sprites in cpu but also better - but on top of that they could do things beyond what the older custom chips could do like various 3d rendering methods, sprite scaling, deforming etc because it was just code that was plopping it in the memory and as such more flexible than hardware sprites, hw tilemaps or such.
if the custom chips had kept pc's cpu's slower then it would've given more fighting chance for amiga and such - and even then the pc games could've done so much more with the quicker updating hardware that was in addition there to those chips.
having a megadrive on a card in a pc wasn't a huge hit anyway for example. later things similar to what you propose were used, but those outdated too quickly as well like the NV1 card. in a way 3d cards kinda did that whole thing.
@@lasskinn474 68k was the better CPU, then ARM2 was the better CPU. Then imagine if we would have used the RISC CPUs of the 32bit consoles, but with a heat sink and a fan and lots of RAM. Also see how we use custom chips today: GPU . See the videos about voodoo . See how complicated sound cards were in a PC .. I still don't get what they all do. Atari Jaguar had a single sound chip + DAC. GBA only had a DAC. So custom chips seemed to be real big in PCs in the 90s.
@@ArneChristianRosenfeldt you don't really need to imagine, since they didn't scale up faster - what you'd have to imagine is if the same amount of money had been put to them as pc cpu's though, maybe they would've had scaled as fast - we are actually using basically risc cpu's now on pc, it's just behind a layer.
on pc now too the custom chips aren't custom in the sense that you'd be accessing the chip and limited to it, they're accelerating behind a layer and this allowed gradual upgrade instead of deciding on some pc2 standard with bigger tilemaps in hardware or something.
and look basic pc soundcards weren't that complicated at all. fm adlib cards were just basically a bridge to the fm chip and the dac stuff isn't that complicated on a soundblaster either so cloning it wasn't that complicated and more importantly cloning the interface didn't depend on chips from creative.
covox was even simpler, it's the simplest there can be, if you ever wondered how a basic dac works then take a look at a covox (and in reverse an adc).
a jaguars sound system is immensely more complicated than any early 90s pc sound card was, having it's own cpu to program and it's own ram.
gravis ultrasound is more complicated as hardware but it was simpler to use than use software mixing - but that's why it also died. the cpu's scaled so fast that you could do 32 channel mixing in software without it being a major burden and it was a single vendor path.
for a while on pc if you were coding your own thing then using a gus was a lot simpler though because you didn't have to come up with your own fast sound routines, but libraries that became available took care of that problem so most coders didn't need to come up with their own, this is also the main reason why some demos had _only_ gus support.
arm pc's were a bit popular in some circles in like 2000 and a bit later, mostly for developing arm code with the aim to run the arm code on mobiles.
@@lasskinn474 but RISC was said to be 4 times faster than CISC or so. The CPUs were super expensive when you bought them from Sun or SGI. I guess that the MMU and 80 bit floats ( for a business main frame??) were the expensive parts. The RISC µ-controllers were always cheap. That was at a time when DEC could beat intel in the MHz race. 68k had similar clock rate as did AMD.
The PC floppy drive thing gets weirder, too. I've been led to understand that the termination resistance changed at some point during the 1980s, which would explain why I couldn't get "newer" floppy drives working in the "older" Commodore PC 10-III I had in the mid-'90s -- but I didn't find out about that until about ten years ago.
IRQ2 is routed to IRQ9 on systems with 2 PICs. I used to have an XT class clone PC that had 2 PICs.
Correction: make that an AT class PC.
Wouldn't that be a 286? I've never seen an XT with two 8259's. Not saying it's not possible to do, I've just never seen one.
@@BlackEpyon It was a NEC V20 based system.
@@damouze If it had 8-bit slots, those would be limited up to IRQ 7 (and IRQ9 replacing IRQ2 of course). I presume it used the extra IRQs for onboard peripherals? If so, that's quite the expandable XT system you had.
@@BlackEpyon Or it could be that I remembered incorrectly. I was trying to look up the system in question online and I could not find any mention of it having more than one PIC. I also owned an AT class PC of the same manufacturer and that one definitely had 2 PICs. I must have had those two confused. Silly me ;-)
@@damouze An AT would definitely have 2. As I said, it's still technically possible to have two PICs on an XT, but you'd have to get REALLY creative in how you implement it, since the 8-bit slot only supports up to IRQ 7. Most things that could use the higher IRQs are 16-bit cards anyways.
So maybe you could make a daughterboard with a few 16-bit slots, piggy-backed onto an 8-bit slot, stack one PIC on the other with some of the necessary pins lifted, and bodge the extra connections to allow for the extra IRQs while the 16-bit cards are running in 8-bit mode. Why the hell you'd do it, I have no idea, but that could be fun as a thought experiment. Something of no practical value whatsoever, but just to say that you did it because you could.
I remember reading about video interrupts back in the '90s, though I don't recall whether I ever managed to use them for anything. I think at the time I had come across a little bit of terminate-and-stay-resident code that would change the background color of the (VGA) screen at a high rate, so it would create color bars rolling up and down behind the text in DOS. Another example I played with caused sort of a flame effect with characters on the screen, though it wasn't very sophisticated. It would have been nice if the interrupts worked to help synchronize that sort of stuff and not cause the CPU to be running at 100%
Raster bars and fire effects were all the rage back in the day. I know a lot of people wanted to do those, mainly because raster bars were really common in early demos and because of the fire effect in Doom I'm imagining.
Maybe, the slight incapability of EGA and VGA cards was out of kindness of the designers of those cards, so that game computers could shine in at least something.
Well sure. I mean otherwise those piddly 8 bit systems were just doorstops. I mean it is not like they could hold a candle to the serious business machines of IBM! Those companies must have considered paying IBM to even be allowed to exist as surely they could have just swatted their hand weakly and they would all have vanished in a big puff of blue.
Sorry for the long-winded ramble, but...
Raster interrupts weren't just used for sprites on 8 bit machines. On the Commodore 64, it might be used to display different vertical regions of the screen using different display modes or (as the PC test suggests) changing colours, and also to be able to scroll a part of the screen using hardware scrolling while keeping another part (e.g. score etc) fixed, or even to switch text mode character sets. Basically, the 8-bit graphics philosophy was that the hardware should be able to change the display a lot without modifying the display memory. Also, display memory usually always meant a character-based display mode because bit-mapped graphics were available but memory-hogging and slow.
The whole graphics philosophy changed with 16-bit GUI-oriented machines. Seemingly everything was about bitmap-mode frame buffers. Unless you were sadly stuck with an Atari STFM like me you still had hardware acceleration, but it accelerated putting things into and moving them around in the bitmap-mode frame buffers. Blitters ruled, and while hardware sprites still probably existed (not sure) they were probably rarely used for anything other than GUI mouse pointers.
The IBM PC absolutely still had text modes, but that's because its philosophy was different again. Just because the early PC had some games doesn't mean it was designed with games in mind. The PC was designed for business applications - text-mode existed but was mostly for the DOS command line and "Text User Interface" applications, whereas graphics modes were mostly targeted at business graphs and charts, and at the obviously-coming GUIs and WYSIWYG application displays (What You See Is What You Get - referring to in-place graphics, proportional fonts, accurate fonts - not using the built-in text-mode font as a substitute - etc). The idea of presenting a different complete frame tens of times per second wasn't really a serious goal because games were mostly considered an abuse of PCs, not a legitimate intended use, until about the time of Wolfenstein 3D and Doom. Games tended to use the undocumented VGA "Mode X" for example. And of course First Person Shooters mostly had to redraw each frame from scratch (other than borders and score areas, which partly existed to reduce the number of pixels per frame to render), so that was pretty much when the 16-bit graphics blitters-etc philosophy was mostly replaced by the 32-bit just-give-me-the-damn-frame-buffer philosophy (at least until hardware 3D acceleration became a thing). There were (and I assume are) still blitters etc, but they were mostly for accelerating the GUI desktop and more serious applications. Once software could redraw a whole frame per frame and avoid the built-in limits of what acceleration hardware could do, that's exactly what games tended to do until 3D acceleration happened.
That's very simplified, but the basic point is that the IBM PC never shared the same graphics philosophy that led 8-bit machines to make such heavy use of raster interrupts. In the early days, you could see a single page of text-mode characters updating - the CPU was (for the time) fast, but the ISA bus link to the MDA or CGA display card was slow. "Snow" was common due to the CPU writing to display memory and fighting with the graphics chip that was concurrently trying to read it - after all it only happens while drawing the graph or chart, not while statically displaying it, so why pay to for better hardware to avoid it? Fast graphics simply weren't considered important until approximately the Wolfenstein 3D/Doom era when people actually started buying PCs for games rather than Amigas, at which point it was practical to render (most of) a full bitmap screen per frame, even using 3D techniques that couldn't benefit much from the hardware acceleration available then anyway.
I have a dim memory that the old Hercules graphics cards might have supported a split-screen text-and-bitmap mode so you could e.g. see the spreadsheet and the graph at once, and the split might have been handled using a raster interrupt ??? I never had access to one, but magazines of the time went on about them a bit. I suspect EGA and VGA may have gained raster interrupts to be able to do the same thing, and maybe compatibility issues for clone cards even killed that use. Maybe the early multimedia obsession also meant that page-flipping in the vertical retrace (e.g. to avoid tearing in that postage-stamp-sized animation or video clip) was also relevant.
My lack of knowledge of 8 bit machines is probably on show here. But my impression was that it was more common for demos rather than games to use raster interrupts for all those things. I could imagine games using them to scroll one part of the screen whilst another part displayed a score or something fixed I guess. But it isn't quite clear to me raster interrupts were needed for that if they weren't different modes or there wasn't some other reason to use them. Again, that is probably my lack of knowledge about 8 bit machines on show though. Either way you are certainly right they were used for other things too.
As for the PC, the original PC was intended as a home computer and games were not plentiful. It seems people were expected to program them in BASIC. But I think I would be happier to say that after this point people bought them for mixed purposes, including games. But the same can be said of the Commodore 64 which was marketed for education and the like. I will agree that many more people probably brought 8 bit machines solely for games.
@PCRetroTech For the C64, I'm fairly sure loads of games used raster interrupts for scrolling - just about anything that used hardware scrolling but kept score and other details unscrolled. Remember that the scrolling registers offset (scrolled) the WHOLE SCREEN by zero to seven pixels horizontally and vertically. If you wanted a fixed region, or differently-scrolled regions for different players, you pretty much had to use raster interrupts. As for different modes - almost everything used text mode anyway because bitmap mode was too slow, so other than colour handling (two vs. four colours) there wasn't much to choose between.
However, I confess I wasn't a C64 games programmer except my one thousandth-rate home hobby projects (and didn't become a professional programmer at all until after that period) so I have no insider knowledge, but there's only so many ways those games could be implemented.
Some of the "obvious" examples of this split screen for hardware scrolling turned out not-so-obvious. Uridium could possibly be using sprites for the score area, and could be using any of several methods to hide that split-screen transition helped by the fact it only does horizontal scrolling. Paradroid scrolls all directions and is probably using a really good implementation for that split-screen transition, but I haven't ruled out sprites for the score display and more sprite trickery to hide the transition.
I did find two clear examples, though. First, Action Biker - very clearly using text mode for both the all-directions scrolled map area and the clearly text-mode score etc details. Second, Kickstart has four obvious character-based regions - each player has his own differently-scrolled region of the map, and this split into two regions is actually split into four due to the unscrolled times-etc regions for each player.
A dead giveaway is a certain flickering artifact in the transition between the scrolled and unscrolled regions, which happened because handling the raster interrupt takes time so the changes tended to happen a little (and variable) distance into the scan line. However, that give-away could be avoided. One known method to avoid the flickering transition was make the CPU wait for the horizontal retrace at the end of the raster line once the raster interrupt was entered, with some trickery to make the wait cycle-perfect even though entering the interrupt wasn't. First time I saw code to do that was in a TH-cam video some years ago. I've often thought an alternative might be to use a row of sprites to hide that edge artifact - not eliminating the need for the raster interrupt, but giving several scan lines of leeway where artifacts would be hidden under the sprites.
Anyway, fortunately for the games but unfortunately for me, it means it's hard to find an example in a TH-cam video. None of the examples I already listed above have it that I can see (though IIRC Paradroid has some sprite-multiplexing artifacts at times).
The one example I found that had those flickering artifacts was Wanted! Monty Mole (top of the scrolling map area, below the score area) - see th-cam.com/video/WU_WUJRTKdk/w-d-xo.html
For an extreme example of raster-interrupt-driven scrolling effects, IIRC Pitstop and similar racing games achieved that curving road effect by varying the horizontal scrolling many times on many of the raster lines (maybe even every single raster line) where the road is displayed, and additionally had a scrolled horizon region.
@@PCRetroTech WRT "the original PC was intended as a home computer" - errrm, seems a bit unlikely, more likely small-or-home-offices (SOHO, as they said back then) but maybe - but home didn't mean games. The original PC was released in 1981, before the 8-bit thing really got properly started. The ZX-81 and VIC-20 (both also released 1981) were among the first home computers that weren't bought as a kit with soldering-iron required for assembly. There were a few video game consoles before then, but mostly they were pong-clone things - even the Atari VCS wasn't released until 1982. The idea of home computers for gaming was brand new, and wasn't taken seriously yet. MS-DOS was basically a CP/M-alike for the 8086 rather than the 8080/Z80, and while CP/M started out for hobbyists, again that didn't really mean games. Just because GW-BASIC had that god-aweful game as an example doesn't mean GW-BASIC was for writing games.
In time, PCs for gaming became an expensive joke compared with common home computers - but in 1981 the idea of computer games in the home was barely born, and those $1,500-ish 1981 PCs absolutely weren't designed with games in mind. Games were written because programmers will find ways to write games for anything, but that wasn't what they were for.
In the UK, if any early PC was going to be sold for games it would have been the Amstrad PC1512. It was certainly aimed at homes at a time when most IBM-PCs and clones went to offices, and it had better-than-CGA graphics and could run the Digital Research GEM GUI, and certainly some games could be played on it, but the launch advertising focussed on applications software and MS-DOS compatibility. After all, the earlier non-PC Amstrad PCW had achieved success in countries where it was marketed specifically as a word processor, but flopped where it was marketed as a computer. The machines intended for games were those ZX-81 and VIC-20 and their descendants such as the C64 (and yes, the Amstrad CPC - an 8-bit and not a PC) and so on, up until the Amiga ran out of steam.
That and 80286 and 80386 PC-clones costing around £2,000 in an age where £200 or less for home computers wasn't unusual basically gets you up to around 1990. Yes, games existed. No, the platform wasn't designed for them. If you really want to push the era of PC as a games platform as far back as possible, ID Software was formed in 1990, the 80486 had just been released in mid-1989, and VGA first appeared (for the expensive PS/2 range) in 1987, the same year that the Ad Lib was released (becoming the first widespread sound card, before which PC sound was almost entirely limited to beeps), so the key ingredients were there for ID to work with. But it wasn't really until Doom (released 1993, and getting close to Commodores collapse in 1995) that PCs were specifically bought for games.
@@PCRetroTech BTW - sorry if this comes across as an attack. I was very bored and ended up researching to check a lot of this today because of that, and I'm very bad at tone.
@@stevehorne5536 The original IBM PC was competing with Tandy, Commodore and Apple computers. Up to 70% of IBM PC's sold in stores went to the home. It's in the name, "Personal Computer".
I’ve I were a game producer, I’d be very concerned in keeping the game compatible with a reasonable range of IBM PCs and video cards at the time even if the performance suffered a limited amount
Your videos are great. I only have one favor to ask. Would you mind turning down volume of the game when speaking? It's a bit unpleasant to my ears when I want to hear what you are saying. Cheers mate.
Sure I'll try a different balance next time.
I should have read your comment before posting essentially the same thing. Strong case of AOL Me Too, not to be confused with woke Me Too, except perhaps in- you know what, let's not go there. Maybe I should lurk moar. OTOH, maybe not: Posting with abandon boosts engagement. ;-P
It'd be great if you clarified what EGA and CGA are in each video somehow because those names are both (pre-VGA) for me. I was 6 when I first came into contact with them on my DOS PC and didn't learn what they were until many years later.
I guess you know by now that CGA had a graphics mode with 4 colours out of a palette of 16 and EGA had 16 colours out of a palette of 64.
There was a graphics mode named Hercules, too. It was mostly for Tandy 1000 systems. A lot of the systems either used this, or composite RGB.
For the most part, if you had a 5150 (IBM PC with MDA or CGA) or upgraded to IBM XT or AT (5160 with EGA or higher), it was standard.
Mostly you had VGA and SVGA coming out around the end of 1989 and 1990, and all of the systems after that pretty much had it standard.
Same with the sound card. Creative Labs 8 Bit cards were available around 1989 or 1990 when I ordered from Computer Shopper. Most of the cards were available and 1991 and 1992, and by 1993-1994 they were both considered to be the standard then.
I did not use the interrupt in my "zolofot" dos asm game, but used the status register. Because this only fires when the monitor is in vertical retrace, it is mostly used to avoid screen tearing and that's all.
Timing periods between retrace-es and such trickery is not reliable enough for "real games" in most cases and could create compatibility hell so I understand why they rarely used this for graphics / color changes though. The 8 bit machines had this better - also ep128 my old machine from childhood had it much better because you could program the video chip what actions to do at what scanline (no cpu code was needed, just filling tables like what is the palette in which blocks of the screen or other parameters - maybe even scrolling).
I guess the highly "business" nature of IBM kind of disappeared these features from their original EGA/VGA and clones even if they could do something like that would not even try because no one would use the feature 😞
PS.: Sorry... I now looked and I checked an other status bit for vertical retrace.. but then this is basically two things to check the same thing so I understand why it was barely supported when there is the other status bit.
Yes, I agree with everything you've said here. It doesn't seem to have been a useful feature at all in comparison to certain 8 bit platforms.
Strange that those EGA cards don't accept the colour update mid frame. I guess they copy the registers to shadow ones during the vertical blank, but why? Maybe it's something to do with the ISA bus interface and reducing contention to low speed registers. Or maybe they found some compatibility issues with mid frame updates so added buffers.
It was just a guess on my part. I really don't know exactly why it wasn't working. I think EGA is a lot less regular than we usually think.
I guess that the hardware designers were lazy and did not believe that programmer could use the short horizontal retrace period to change a colour. A sane solution would be that the chip which sits on the ISA bus just accepts all writes, buffers them, and then applies them to RAMDAC and VRAM on hsync. But you know, buffer is hard to debug, costs money. PCs are cheap.
@@ArneChristianRosenfeldt To be fair it was a technique that few programmers were good enough to take advantage of, and the IBM PC and compatibles were business machines. There just wasn't much call for racing the beam so your spreadsheets could display more colours.
(apologies if this shows up multiple times, I think youtube might have thought it was spam because of a link!) You probably know this, but even though you can't do horizontal retrace interrupts you can poll the registers to find out which line the raster is up to. This lets you do the classic raster bar/copper bar effect even in text mode, which is neat. Of course, you burn a lot of CPU just polling, and it might be tricky to fill that CPU time with more useful work because you need precise timing to do things on precise scanlines. But I think it could be used to get more than 256 colours on screen at once, at least.
Yes I did know about polling and should have mentioned it in the video. But thanks for covering it here.
To get more than 256 colours, one needs to change the palette registers in real time. This is actually quite expensive, and I think technically might not be possible outside vblank on some hardware. But it bears investigating.
@@PCRetroTech also many vga cards can show snow when changing palette outside blanking periods.
pooling i/o registers in anyhting above 286 is abysmaly slow and even if you got the timings perfect, it's almost garantined it won't work correctly in most graphic cards due to different i/o response times, bus speed etc. you basically need a "modern" card with fast bus and buffers. sure you can make some pretty cool demos, but anything beyond that is a crapshoot. as PCRetroTech said, changing pallete needs a lot of i/o regs writing, so by the time you did that, the trace will have overtaken. the snow effect is also a consern.
@@theALFESTThat incidentally depends entirely on the RAMDAC used. If it's a cheap one with single ported RAM you will get snow. Better ones use dual ported RAM and will not exhibit any snow.
I love this channel... just watching it before bedtime makes me sooo sleepy 😁
Sprite multiplexing on the Atari 8-bit computer could be done with Display List Interrupts, but I'm sure some programmers have their own techniques or try using Vertical Blank Interrupts.
There are definitely a variety of different tehniques.
Dave Haynie from commoder amiga team said in interview the BOB (blitter object) is more universal and better technique than hardware sprites. Usability of this solution depends on color depth and RAM + gpu frequency. Need of two raster operation to remove old BOB and write BOB on new position. If graphics hardware has enough off screen dedicated video RAM to store sprites like BOB only graphics card is involved in operation without slow down system RAM.
I used horizontal retrace IRQ on graphics chip as new as PCI CL-GD5434 to do dumb shit like having raster bars behind DOS text. It was perfectly reliable way of changing palette on each scanline.
It would be interesting to know if the vertical interrupt consistently worked on original IBM EGA and VGA hardware, and if it was only a sizeable contingent of EGA/VGA clones it didn't work in. If it didn't consistently work on IBM HW either, that'd also be interesting to know.
Any estimates on the percentage of cards, clones and original ones out there, this would have worked with?
(Granted, that's very hard to estimate, as it kind of requires factoring in things like market share, etc. From your video alone, it _feels_ like absent jumpering and soldering this only would have worked out of the box on like 10% of VGA/EGA cards out there? Is that a reasonable hunch?)
Maybe the Gauntlet devs just happened to have a card this worked on and never knew any different until it was too late? The relatively large number of sprites on screen (and "sprites" seems apt regarding the ghosts) looks like a plausible explanation as to why the Gauntlet went that way.
The Gauntlet graphics looks unusually lo-rez. Almost like they were 160x200 instead of 320x200 in places, though I'm not necessarily assuming that's the case.
It worked on IBM EGA cards. There's no way for me to get an IBM VGA card so can't test it there. You can see the cards I have access to in the video.
@@PCRetroTech Good point on the IBM VGA card -- the actual card must be rare as unicorn poop. Minuszerodegrees has a pic of their card, aka the "PS/2 Display Adapter". I'll note though that I deliberately wrote "hardware" and not "card", because the former includes IBM's onboard VGA oeuvre. That said, I don't own any of the relevant machines, and I'm guessing you don't either? In any event, it wasn't really a demand, more like an observation or a "throwing it out there"; maybe someone out there knows or can find out some day.
@ropersonline I'd be pretty sure IBM's cards would meticulously match their standards (typos notwithstanding).
Edit: except it doesn't. Apparently on the ISA bus, the interrupt is not implemented correctly on IBM VGA hardware.
It's technically a PS/2 standard though, so maybe we let them off on this occasion.
Ah yes, a few years ago I also investigated this. I came to pretty much the same conclusions: on some hardware the vblank interrupt works perfectly, on other it is erratic, or not working at all. I never got around to writing everything up in a blog, but was still planning to do so.
Worth mentioning though: the PCjr also has a vblank interrupt. It is different from the EGA one, but obviously 100% reliable as all PCjrs are the same. There is no variation in chipset, CPU speed or anything. The only clone is the Tandy and afaik that is 100% compatible with the interrupt as well.
I think you were behind some of the posts I referred to for this episode.
I think I read about the PCjr vblank interrupt somewhere.
Given that the vertical interrupt technique enables a different class of effects, were there any PCjr/Tandy games that used this that didn't work on most regular EGA/VGA PCs? Just Ghost & Goblins and Gauntlet, those two?
@@ropersonline I don't know if games on PCjr/Tandy even used it, because as mentioned in the video, when you don't have any kind of sprite, scrolling or other kind of hardware, there's not much use for synchronizing to the screen. Besides, it's just a vblank interrupt, not the more advanced raster interrupt that the C64 has, which you can fire on any scanline (which allows racing-the-beam effects), so the usage is extremely limited.
Nevertheless, since PCjr/Tandy hardware is not compatible at all with CGA/EGA/VGA/PC speaker anyway, games usually had separate PCjr binaries/drivers, so you wouldn't run the same code on both anyway.
Very interesting, I've been wondering about this myself lately. Ferraro's Programmer's Guide to the EGA, VGA, and SVGA Cards says that the interrupt only works on EGA cards, and on PC class hardware generates interrupt 2, while on AT class hardware it generates interrupt 9. A shame it doesn't work consistently across all hardware!
In EGA/VGA: A Programmer's Reference Guide by Kliewer some of those issues are called out: "a few EGA compatibles do not implement IRQ2 correctly, and the IBM VGA adapter for PC’s and AT’s does not support hardware interrupts (some VGA compatibles do support IRQ2, some do not, and others are switch selectable)". On the EGA compatibles that are badly behaved he says: "These adapters have the status bit reversed (see bit 7 of Input Status Register Zero). Other cards do not correctly implement the Clear Vertical Interrupt (bit 4 of the Vertical Retrace End Register)". More info here archive.org/details/EGA-VGA_Programmers_Reference_Guide_2nd_Ed_Bradley_Dyck_Kliewer/page/254/mode/2up
Maybe gauntlet uses it for making the game run right speed?
Have you looked into what trickery was used for textmode smoothscrolling? There were some text viewers and stuff like that 1993-1994 or so floating around bbs's
No I haven't looked into that. I know some tricks for CGA, but to get really smooth scrolling is going to be really hard on the PC. EGA should be a bit easier I think.
I wrote a smooth scrolling ANSI viewer for an art group back in the 90s in Turbo Pascal! The group didn't last long and I'm not sure if they ever released an art pack with my viewer though heh. It was heavily inspired by ACiD art group's ACiD View which also did smooth scrolling.
@@bananaboy41 By smooth scrolling do you mean horizontal or vertical? And by smooth scrolling you mean pixel by pixel without simply rendering the fonts yourself I presume.
@@bananaboy41 did it stay in the textmode and do some trickery or switch to a graphical mode?
@pcretrotech yea by that time we had svga cards and i never tested if it would've ran on ega card.
Yeah text mode smooth vertical scrolling, pixel by pixel. Here's an example: th-cam.com/video/2k1yuXiXJCY/w-d-xo.html You can use the "preset row scan register" for precise vertical scrolling in text modes.
Could the differences in interrupt timing be calibrated in the game setup? Also, could this be used to improve performance by writing data to screen in real time without buffering?
When I began to collect "classic computers" in 2006 I thought I would learn how to write in C, and Assm on them to write games for dos and so on... But I don't have time even to play games...(
I think it's a common problem before retirement. If you can afford the collection, you probably have a busy job.
@@PCRetroTech agree in modern world nobody have much free time... (But maybe in past ages it was the same or worse). I'm a photographer by profession, I collect vintage computers, thought I dont work in IT sphere)
As an old coder, I love your vids. Hit me up if you're in the DC area!
Thanks for your kind comments!
All these raster based operations... in the end your image is limited to horizontal bands sort of. Nothing beats a fast blitter bitmap system provided you have enough video RAM 😅.
As Prozocgod Retro suggested, the interrupt is probably use by the games as a sort of v-sync.
The audio mixing on this video is slightly off. The background music is a little bit too loud in places, and your voice-over is a little bit too clobbered by that.
He's a dummy
hello there - I enjoy your content and know of your fondness for all things plantronics. Is there a way I can send you a quick DM?
Yes, I see you have my email address now, and thanks for contacting me about that.
I remember reading that raster interrupts were MUCH more labor intensive --> more costly --> avoided like the plague by industry.
That would not surprise me at all, especially on the PC. Even on 8 bit platforms I don't have a sense of what proportion of games used them. Demo writers use them quite a lot there though.
@@PCRetroTech I remember watching an interview with a game artist from around the time, went over some of the tricks of the trade as he told his story.
Will try finding it later.
@@Intelwinsbigly Might be interesting, though TH-cam will probably remove the link. I'll see it though.
@@PCRetroTech Found the interview, I hope you enjoy it.
"Lucasfilm Games with Mark Ferrari - Retro Tea Break"
TH-cam channel: 'RMC - The Cave'
Their Retro Tea Break series is a goldmine, I highly recommend it.
@@Intelwinsbigly Ah right, thanks. I have watched parts of that interview before. Very enlightening!
Music too loud.
He's a noob
I wonder why the graphics adapter manufacturers didn't design them to have sprites. Seems like an obvious thing to do
That's an interesting question. It's clear why IBM didn't bother with them. They were a business company, and sprites are for games. But other companies could have added them. In the early days, the CGA card took up a full length board, so there was little room for additional hardware. But later on, it could have made sense. I guess that by the time that era rolled around in the PC world, 3D games were the focus. I don't really have a better answer than that. Interesting question though.
@@PCRetroTech good point, the CGA card was right a the edge of what was possible with the given constraints. Thanks for the response
I was not familiar with the c64 version of the game, it's soundtrack is amazing.
I used to play the Amiga version. It was arcade perfect. Looks like they got it as close as possible on ol' chicken lips too
Noise: too loud! Voice: too low!
Thanks for mentioning it. I wound the game sound way down but a few people have mentioned that they are having trouble with it. There must be some differences in sound reproduction on certain machines.
12:57 its been so long ago i have heard a native english speaker pronouncing "data" right. thanks man, awesome video even tho i dont know much about this stuff in the technical aspect of it, but nonetheless fascinating.
Nope, the correct pronunciation is “day-ta” not “dah-ta”
I won’t bore you with how I know this to be so but it involves spelling rules (yes, there are rules to spelling) as well as a linguistics degree.
@@jonchapman6821 It's OK to say /data/... just switch to Latin mid-sentence, say the word, and then switch back to English! Kind of like a raster interrupt! 😄
@@jonchapman6821 .gif right :o
Australians predominantly use `dayta' but I've been overseas so long that I've adopted many different pronunciations that wouldn't be usual for an Australian.
Of course both are "correct" pronunciations as can be verified in multiple dictionaries*.
However, some Australians also say `darta` which is another variant again. I would say that is the Strein way of pronouncing it.
* There are some people who insist that loan words from Latin (but not from Greek, like `drama' and `panorama') should be pronounced a certain way (`dayta' in this case). But it's easy to find academic scholars who recognise regular usage, not pronunciation "rules", as the only guide to correctness. The other scholars also think I missed some commas and other punctuation though, so they were presumably unable to read what I wrote. So I feel safe writing it here.
@@PCRetroTech btw, i am fully aware there are dialects and accents. as for the creator of .gif files have said the correct way to say it. there is a video out there about it. and i am not as sure about the data, except that is how the said it back then. oh well, did not want to come to this as a discussion as you clearly want to debunk what i said by replying with general language stuff.
end of discussion.
edit: i see now that you wasnt the first bloke, but yeah haha sorry. i wont censor what i wrote. have a good one.
The music is TOO loud...
Who's she?
Someone enabled cheats on G&G :)
Background music is to loud. Your speech is to quiet.
Handsome!