As a kid during the 80's, this stuff seemed like magic and it always had my mind wondering "how'd they do it?". Thanks to the internet and people such as yourself posting content like this, I can finally understand. It's calming to learn how this work. Thank you.
As far as I know, the ghosts in Pacman where "blinking" because only one sprite (out of the 4 ghost sprites) where rendered per frame. But this "optimization" makes them look more "ghosty" :)
+Simonschreibt The pacman game as it was sold was only a prototype. A programmer came up with a proof of concept, showed it to management and management decided to go with it instead of letting the programmer actually finish the game.
+bobnoel Atari Pacman wasn't unfinished, it's that they couldn't have the same maze because of technical limitations (not enough vertical pixels if they kept it vertical, and not laterally symmetrical (needed for background graphics) if maybe they laid it on its side). Not having the same maze meant it simply sucked. The build up and disappointment when it was released embittered an entire generation of people.
+bobnoel According to 'Racing the beam', it was _based_ on a prototype rather than giving the programmer time to rewrite from scratch. It also had to fit in a 4k ROM which limited the functionality. What's really amazing is how much better Ms Pacman was.
The Apple II used "artifact" colors -- same as with the hi-res modes of the Atari 8-bit computer systems (400, 800, XL, XE), Tandy/TRS-80 Color Computer, Dragon 32/64, and the "composite color" mode of some IBM CGA games. Atari 8-bit systems also had a trick where every scan line of the display could be in a different graphics mode. Games often used this to get more colors on the screen, or to show a status line (high score, lives left, etc.) at the top or bottom of the screen.
What you were thinking of is that each command for a new graphic mode (represented by a display list command) had an interrupt flag that interrupts the video chip (if turned on), allowing code to execute before that graphic mode is drawn that allows you to change the graphics register to a different color.
> Atari 8-bit systems also had a trick where every scan line of the display could be in a different graphics mode. !! Do you mean a different resolution or just a palette-swap like the CGA "cold" pallet and "warm" palette??
@@jessfucket You could switch to different-resolution modes, or even between text and graphics modes (that was how Atari BASIC could put four lines of interactive text at the bottom of a graphics screen, very handy). It was also possible to swap colors in the color palette using an interrupt routine, or even to swap in a custom character set in the text modes for character graphics. And most of the graphics modes had color indirection for the colors, so it wasn't like CGA where you just had two possibilities--the particular mode might have 4 colors, but those colors could be any of 128 possibilities, and if you used display-list interrupts you could change those on different scan lines. So the fancier Atari games tended to have this mix of wildly different types of video display on different horizontal bands of the screen, and there was also a popular effect for title screens and such were you could have pulsing rainbow bands streaming down the screen. It's one of those things that screams "Atari 8-bit".
They're not exactly the same, though. The Atari 8-bits, when in hi-res mode (320x192 pixels on a standard screen, which it didn't necessarily have to adhere to, by the way) use all 8 bits of each byte, and therefore can only produce black, white, and two other colors that depend on the particular graphics chips they use and their revisions. On the Apple II series, the 6 colors are consistent and predictable, while on the Atari, 2 of the 4 colors are kind of up in the air. Fortunately, the hue control can usually get you a couple of usable colors, but 4 is still less than 6, and the _Ultima_ games, contrary to what many Atari 8-bit owners seem to believe, suffer on the Atari 8-bits in comparison to the original Apple II versions. You're lucky if you even get blue water and green forests--sometimes these colors are reversed, and there is no orange and purple (or you get orange/brown and blue but no green nor purple--it depends!). In fact, there were two versions of some/all _Ultima_ games on the Atari that reversed the colors in case that would help. Maybe Origin should have used some of the Atari 8-bits' other modes and capabilities--of which there are many--for the _Ultima_ conversions. The problem with this, however, is that the resolution would have been much lower. On the C64/C128 there was color memory that allowed it to more or less match the Apple II for the _Ultima_ series, including resolution. The Apple II, for which these games were originally designed of course, did some things better, while the C64/C128 did other things better, but they were a pretty close match concerning the _Ultima_ games, at least. In most ways and with most games they were strikingly different, and the same goes for the Atari 8-bits. No other 8-bit computer could match the latter when it came to games that were designed specifically for it, although the same could be said for the C64/C128 in different ways and with different games.
Great video, did not know about the Apple graphics. I didn't know about CPU graphics either but the SLOW and FAST commands on the Sinclair ZX81 make sense now. It's amazing how old computers were a result of the juggling act where designers had to balance functionality versus affordability.
Actually, if you set the color bit when using a monochrome monitor, it would shift those seven pixel half a pixel-width to the left. It did the same thing on a color screen, Steve Wozniak generated colors by taking advantage of how the composite video signal was set up to relate color and position. You could take advantage of this to be able to get 560 pixel horizontal precision on positioning an object, even though the objects themselves were still limited to 280 distinct pixels (or 140 in color). I occasionally used the color bit to make things like smoother fonts.
Please do the CGA, EGA & VGA graphics! I still remember writing 2D demos in assembler utilizing direct access to VGA memory. I never did anything pas the basic VGA 320x200x8bit, as it was a simple write to the chip. No pages... Those were the times :)
+Jachym Lukes Yeah, and it behaved like you expected. If you knew the VGA registers, they'd work the same on virtually all video cards of the time. It was only when one got into VESA resolutions that things started to get weird and hard to deal with.
Phyphor666 I've just remembered how my schoolmate found some memory chips, pressed deep into his carpet. I got them from him and they fitted to my Trident VGA. With them I was able to view "images" downloaded from BBSes in True Color :)
I love this series! I wasn't even around for most of these graphics but the history of it is super interesting! I hope you keep making these beyond the 3 parts, as you suggested at the end of the video. I'm all for it!
Growing up through the evolution of graphics modes, I'd LOVE to see an episode on CGA/EGA/VGA/SVGA. I remember being a kid with a green monochrome screen, and just being so wowed by the glory of CGA, blown away by EGA, but my head just about exploded when seeing VGA for the first time. Kids these days just have no clue how good they have it, graphically speaking. Haha.
Great primer on old school computers! I miss those days (I programmed mostly for Atari 8-bit and Coleco). Atari called sprites "player/missile graphics". Four players 8 bits wide and 4 missiles 2 bits wide...but they were all 256 pixels tall (even taller than can fit on the screen!). They only had registers for horizontal position and were vertically placed by shifting the visible image within its very tall area! It was odd but allowed for tricks to vastly increase the number of sprites so long as only 4 appeared side by side at once...just define one player with multiple pictures within its 256 byte column then change the horizontal position of the player mid-scan. Atari 8-bit machines used "display list interrupts" to change not only colour pallette but even display resolution so you could have a section of text, a section of low res, section of high res etc. In some ways superior to what the C64 could do. The subject of how Atari graphics evolved (including how it influenced the Amiga) would be very interesting...from Atari 2600 racing the beam and the first player-missile graphics to the DLI and modes of the 8-bit computers and 5200 to how the Amiga was developed by the same people and evolved it to create HAM mode etc. Those pioneer engineers were amazing with the creative ways they used limited technology to do so much!
could not agree more with this..nowadays they don't spend any time on optimizing the games/software, and it's even worse that this trend got into smartphone/tablet technology, for example the cheapest "Android" brand new phone was bloated with about 400 Mb of software just from google, instal any other app and the phone is frozen....
Actually, the C64 has raster interrupts, which are effectively the equivalent of DLIs on the Atari. It can (without any flickering) similarly multiplex its 8 sprites (each 24x21) using raster interrupts, among other things such as switching modes and changing color registers on specific scan lines--anything the CPU can do within the limited time available. I think that a great many Atari 8-bit owners/fans are unaware of this. The C64 is generally more powerful when it comes to sprites, although of course the Atari 8-bits have their own advantages over the C64. Both can do DLIs/raster interrupts, though. I'm unaware of other 8-bit computers that have this capability.
@@rbrtck that is true. The C64 has better sprites (more if them plus they have multi colour support). ANTIC DLIs are a bit better than VIC-II raster interrupts because you don't need to involve the main CPU every scan to change graphics modes, color palette etc. You just set up the display list program and the ANTIC does the rest. ANTIC is technically a full CPU itself and the display list is a kind pf program. As for other 8 bit computers that use similar tricks the closest is the TMS9918/9928 and Yamaha 9938. For the sprites, they actually only have 4 but in the hardware they have 32+ "virtual" sprites and reposition the 4 real sprites (8 in the 9938) depending on the current scan line. That is why sprites flicker or disappear on TI/Coleco/MSX when more than 4 or 8 are side by side. These chips only have interrupts on vertical blank though; you need to poll for the current scan line and they don't have hardware support for pixel level scrolling, although the basic acceleration routines in the 9938 help with that a bit. That is not really the same though since the raster interrupt tricks are done in hardware.
@@markshanehayden4648 You're partially right about ANTIC, in that it can perform some of the dynamic screen operations on its own, albeit the more it does, the more cycles it "steals" from the CPU via DMA (the Atari 8-bit has a special version of the 6502 that can be halted for this purpose). I wouldn't call ANTIC a "full" CPU, though--it's more like a limited, special-purpose GPU, and DLIs that utilize the CPU are required for the more powerful, complex types of operations. While the design of Atari 8-bit's graphics subsystem is more elegant, in the end there is not much difference between what it and the C64 can do in terms of dividing up the screen. Keep in mind that the much-touted DLI function always interrupts and uses the CPU, and that the C64's raster interrupt does the same thing (the latter may be programmatically more clunky, but it's still fundamentally the same thing). Neither computer's CPU is "chasing the beam" from the vertical blanking interval (that's what ANTIC and VIC-II are for).
Good video except those black lines on the left of the Atari 2600 are not because game code is running, it's just a bug in the video chip when a player object is repositioned on the previous line and the call didn't happen on a particular clock cycle.
+MrTBoneSF - Interesting.. I've always heard that it was not enough CPU time. Not all games have the black lines. but that would make sense for why even a sprite is affected when it moves in that area.
+The iBookGuy Racing the Beam if I remember correctly has an explanation of this. Also this question comes up a lot on the programming forum over at AtariAge ("why are they there?" and "how do I get rid of them"). Only games that have sprite reuse have the lines. Simple games with just two player sprites (like Combat) don't have to worry about the issue. Activision got around this by either having the kernel call the HMOVE on the exact cycle (near impossible to do in general code) or just calling HMOVE on every line so their games had a solid black border on the left. That area of the screen is usually in the non-playable space anyway since they had to leave a border for overscan on CRT tvs, so there was no harm in "window-boxing" the game. If the game naturally has a black background, you also wouldn't see the lines until the post-game color cycling (e.g. Space Invaders).
+pocpic Not really, it was 320 pixels wide but the background graphics were 160 wide then always mirror-imaged to form the right half. Sprites could be positioned anywhere though. Most games had that full-screen symmetry but you could do tricky things with the raster interrupt to swap in new background graphics.
I wrote a program on an Apple II series machine which displayed Garfield the cat. Then I changed it to make Garfield's eyes close by redrawing on top of what I had already drawn. Surprisingly, the pixels around the edges of his eyes got messed up with blocks of colors I did not set. I never knew why that happened until now, some 32 or so years later! Great explanation.
I love how programmers of the Commodore 64, years after it's release, were able to get more colors and resolution out of it for static screens, not unlike the Amiga's HAM (Hold and Modify) mode where it could produce 4096 colors on a static screen.
Some C64 games did use that palette-switching trick in-game because you could set an interrupt to say how frequently (or infrequently) you wanted to make a change, so it didn't waste a lot of time when it happend. Though it was mostly used on title screens of games. The ST and Amiga used it all the time in backgrounds. A similar trick on the Acorn BBC Micro let you change graphics mode part-way down the screen, and was used in the game Elite to switch from monochrome to colour and back again, to save on screen memory. The ZX Spectrum could do the same to partly mimic the extra colour cell resolution of its Timex cousin and the MSX. Again, used mostly on title screens, but because it was per-character cell, it could be used for individual game sprites; but it wasn't until 2011 and Buzzsaw+ that the effect was actually used in a game.
Darn, no mention of the Atari 8-bit computer's Display List Interrupts (which let you do some CPU-driven-style stuff, but without having to spend all of your time counting CPU cycles) -- color palette changes (useful for those typical rainbow color effects), repositioning sprites, etc. Also, on the Atari and many other systems, you had hardware support for vertical & horizontal smooth scrolling (so moving per-pixel, even in cell-based modes like a 40x24 text screen), redefined character sets (fonts, useful for tile-based games -- e.g., instead of using 8-9K for bitmap mode & moving tons of data around, you'd use 1K of graphics data + 1-2K of 'font' data), and the ability to point the graphics chips at different parts of RAM... on the Atari, even on a per-scanline basis. Practical example of combining a lot of these effects -- say you had a drawing that you basically 'compressed' into 4x8 multicolor cells, giving you around 160x200 pixels. It's only 1K for the font, plus 1K for the graphics data that defines which shapes are drawn where on the screen. But then say you only draw the top half of the picture. Use the handy point-wherever-in-memory (Direct Memory Access / DMA) feature, plus the "flip the characterset upside-down at basically no cost" feature, to draw the mirror-image on the bottom half of the screen. Then use some color palette changes to 'tint' your picture blue, and tweak the horizontal scroll value on each scanline along the bottom half of the screen. For less than 2KB you have a full-screen picture, in 8 colors (or more, if you do more of those per-scanline color changes), with an animated lake reflection effect. :) Such is the power of Atari's 1979 GTIA & ANTIC chips! They've aged quite well, I think!
These videos are so interesting! I definitely have more respect and appreciation for the programmers/designers that have come up with clever ways to circumvent these hardware limitations
+Scott Blacklock EGA was introduced in 1984 and VGA in 1987, so not quite. Also, you know you could just pop in an EGA or VGA ISA card in something like the IBM 5150, right? Even 8-bit ISA sound cards like the Sound Blaster or Adlib will work fine in machines of that age.
Your one of the smartest guys on CZcams in my opinion. watching some of your other videos, your able to to put new things into an old product to improve it, and your able to take things apart and fix these things, I apologize for not being specific but there's many different videos, but regardless, it's all rocket science to me at points, I can't imagine the schooling you must of went through to know all of this.
I'd love video's about CGA, EGA and VGA! I've done some very simple assembly programming in the early 90s and EGA really baffled me with the planar memory. VGA with mode 13 and mode X were really awesome! Now I have deeper understanding of computers I'd love another explanation to see if it makes sense to me now :-D
Would you consider doing a video like this for more systems like MS-Dos computers from the 90s, Sega Master System, Sega Genesis, Super Nintendo and comparing them?
The Mega Drive and Super Nintendo basically works like the NES but with more bits-per-pixel, and more and larger sprites. The Master System too, although it doesn't really use color palettes AFAIK, instead opting for a higher color depth in sprites and tiles (4bpp compared to the NES 2bpp -- same as the MD/SNES). Old DOS PC's basically work like what he described in the first part of the first video -- the "unusable" method that used too much memory.
Great video. Clear and concise explanations. I still have my Sinclair Spectrum , got it to learn Z80 assembler back then. When I started as a young electronics technician, one of the hardest things was getting hold of information. Today we are so spoilt with the internet ! Look forward to more of your material
+Fredrik Jagenheim The Wikipedia pages do a pretty good job. It's one of those modes, like Apple II double-hi-res, that is easier to describe (and implement in hardware) than to write software for. en.wikipedia.org/wiki/Original_Chip_Set#Denise en.wikipedia.org/wiki/Hold-And-Modify
Thanks man. My 8, 12, and 15 year old loves these vids. It got my 12 year old girl excited enough she is actually playing with simple graphics now on an Arduino and 8x8 matrix display. She is really starting to appreciate what you were saying as a result.
I vote for Amiga. There's loads of weird interesting hacks from the Amiga to talk about. All from 1985 too. HAM, Extra Half Bright, the Copper chip, the Blitter, bitplanes, reusing hardware sprites as you go down the screen. Also why it worked so well compared to a CPU bound Atari ST. This site details some amazing Copper chip tricks. www.codetapper.com/amiga/sprite-tricks/
The Amiga is the big brother of the Atari 800 having it's video chip designed by the same person who did the Atari 800's video chip. Atari eventually added a copper chip of it's own.
Absolutely. Like this little gem on the Amiga 500 that uses HAM + Blitter objects and still has time to play the background music with sound effects: czcams.com/video/JJczdYO8N1c/video.html And this one for 1985's Amiga 1000: czcams.com/video/XDdMoglmUbs/video.html
+Gaming Jay Agreed. I would especially love to read about the register-level programming for these boards. The CGA card, in particular, could be programmed for all kinds of funky modes that IBM never intended. I remember one package we used in college (Micro PLATO, a coursework package) which tweaked CGA registers to produce a mode with fewer pixels horizonally, and more vertically. This often messed with the monitor's ability to sync, so we'd have to twiddle the vertical-hold knob in order to get a stable picture when using the program. There were other non-standard modes that were used by various games (like ElvenSoft's Round42). Sadly, very few of these games would play on more modern video cards, because they were using undocumented register-level hacks to produce the video modes. (I remember my ATI VGA Wonder card included a small application to put the card into a CGA-compatible mode that would let it support these modes. IBM's VGA products didn't have the ability at all.)
+Shamino0 that's neat. I find video and memory hacks very interesting. Reminds me of back when I used to code in Turbo C and had to work out all kinds of little hacks to get my programs to run
You should do an episode on programming languages back then. What was used for the Apple II, the Atari 2600, Nintendo, Sega master system. What did the IDE look like? I have searched for Nintendo code but could not find anything. It seems that nobody has open sourced their games from that era.
NES games (and games for other computers and consoles from the 8-bit and 16-bit era) were almost always programmed using assembler language, which is basically giving instructions to the CPU etc.directly (whereas code in C etc. has to be compiled first.)
I've done a few videos with AppleSoft basic using an emulator and screen capture. I do have images for C and a few other languages. I also have a II GS emulator. Anything in particular you want covered?
There are different "levels" of code. First is "machine code", which is the lowest level. It's literally nothing but 0s and 1s (or hexadecimal). It's the hardest to use, but takes up the least amount of RAM (and ROM space) because the CPU doesn't have to convert anything. Machine code was mainly used in computers from the 50s and 60s. Next is "Assembly". These are machine-specific codes, used mostly in old systems that didn't have that much RAM. These hardware-specific languages used actual words instead of 0s and 1s, but were still difficult to learn and master because they were based on how computers operate instead of how human minds operate. That made them extremely efficient when it came to RAM usage. Next are the languages you might be more familiar with, like C, Java, and BASIC. These are designed to be used in as many machines as possible. They, with a few intentional exceptions, were designed more with how the human mind operates, which made them easier to master than machine code or assembly. They are also more taxing on the CPU because the CPU had to convert the code into "machine code" before it could be used. Finally, you have programs that convert user input into useable code. Examples include Raptor and Warioware DIY.
I'm glad I randomly found your videos one day, they're interesting and fun and technical enough to keep me interested without becoming tedious. Love to see more stuff about graphics modes, but general 'how old machines did X' videos are always super interesting too.
These videos are wonderful! Thank you so much. I'm looking forward to seeing the video on game music. Do you think you could talk about SNES graphics, in particular Mode 7?
I'm doing a course currently that covers all aspects of making a game in modern engines, from using a 3d tool to create and animate objects to programming the engine to control and utilise them, and I love watching these videos about older systems that were able to do amazing things because of clever programming.
The mechanism used to determine colors on the Apple II (and TRS-80 CoCo) is pretty straightforward, actually. It all has to do with the NTSC composite video signal. When there is no colorburst signal, then the high/low signal strength determines brightness of where the beam is. Associating 1 bits with high and 0 bits with low creates a monochrome signal. When there's a colorburst signal, however, the signal pulses are relative to it. A high/low signal will produce a particular color depending on its width and phasing with respect to the colorburst. The Apple II took advantage of this. Odd pixels would produce a pulse aligned with green, and even with purple. The "palette" bit would shift that cell over by a half-pixel. This would make them align with orange and blue. Any adjacent pair of identical pixels would render as black or white. In the absence of a colorburst signal (or on a monochrome monitor) the palette bit would simply shift the pixels by 1/2 their normal width. In the //e and //c, there was also a double-high-res mode. By doubling the number of pixels in the same horizontal space (1/4 of the colorburst width), you could hit 4 phases at once (pixel-shifting was not supported in double-hi-res mode - the 8th bit of each byte was just ignored.) This would therefore require four adjacent pixels to generate black or white, and various patterns could produce 16 colors. (The same 16 colors used in low-res mode.) It's worth noting that the Apple //c and //e had circuitry to disable the colorburst signal when in text mode. Apple's monitors (and properly designed monitors from other manufacturers) would detect this and produce a proper monochrome image (no color fringing) when in text mode. But a lot of TVs and monitors would not do that. The TRS-80 CoCo was similar. Its high resolution mode also had pixels half the width of a the colorburst, so odd/even pixels would produce red or blue. Both would produce an off-white (which Tandy called "buff") and black. Various other patterns could produce other color. I remember being very proud of discovering how to produce yellow on mine. There was also variant where "buff" became green. But that was pretty useless, because the odd/even artifacts would only display components of green. The real nasty part of Apple II high-resolution graphics, however, was trying to map specific pixels onto the corresponding bytes in memory. It used an 8:1 row-interlace nested within a 64:1 interlace. This was, apparently, another Woz Hack designed to make the video generation circuitry easier to build. And in double-hi-res mode, adjacent bytes (of 7 pixels) would come from two different pages of video memory. (Similar to the way that 80-column text would take odd/even character-columns from different pages of video memory.) And then to make it even nastier, there were "screen holes" - 3 40-byte scan-lines would be represented as 128 bytes, with the leftover 8 bytes not being displayed. While the design probably made sense from a hardware-design perspective (a Woz-hack designed to minimize the number of chips,) it made software design a living nightmare. See also: en.wikipedia.org/wiki/Colorburst en.wikipedia.org/wiki/Apple_II_graphics
+Shamino0 I should also add that designers of RGB video cards (including Apple's own IIgs) would have to emulate all of this in order for software to look right. I'm sure lots of hardware designers spent long weekends pulling their hair out in order to emulate NTSC-colorburst artifact colors on an RGB interface.
Please do the Amiga too! The Amiga had the most wonderful graphics of any machine in the late 80s, and had things like the blitter, HAM6, EHB modes, multiple simultaneous resolutions, planar graphics. The list goes on!
+Bluewave256 Agreed. I had to keep turning up the volume during scenes when the iBook Guy was off camera, but then had to hastily turn it down when he was back on camera. This was something that should've easily been caught and fixed in post-production.
I'm more bothered by the environment change (going from an echoey room to a more silent room for voiceovers) than I am by the volume changes. I'm an audio engineer and I find the audio in most channels' video to be lacking. It's almost an afterthought.
Absolutely fascinating. A lot of it goes over my head of course because there's so much to cover, but I really like learning about these sort of limitations that developers encountered, and the different ways people addressed them using the same resources.
4:09 - I don't think that on modern system it will use 90% of CPU. 1920x1080 = 2 073 600 pixels. Every pixel has three 1 byte colors (RGB). So, 3 * 1 * 2 073 600 = 6 220 800 colored subpixels in frame. Most monitors are 60 Hz, so 6 220 800 * 60 = 373 248 000 calculations in second. Is it much for modern 4-8 core 3-4 GHz CPU? It will take like 10-20% from one core. Correct me if I'm wrong.
90% came from structure of video signal: these 90% are when ray is visible and 'draws' a picture, while another 10% it's off and performs 'flyback' coming right to left and at the end of frame from bottom to up. That time between frames is best for actual computing because your code doesn't get interrupted after just couple of microseconds. I highly doubt modern CPU could change context just after sending out another pixel, that's pretty slow operation: push all registers to stack, change SP, pop registers from another stack, etc. It would easily take 10 clock cycles and that's how much is left to draw each pixel. I'm not even sure 10 cycles is enough for each pixel, because CPU here tries to perform at least some clever decoding (for ex. JPEG image on the fly), so it's not as simple as mov from memory, other way we wouldn't need this CPU-assisted mode after all! So it's safe to think one of cores would be 90% busy drawing graphics even now.
The entirety of the usefulness of the Internet has nothing on this video's line of discussion and revelation. Keep up the badass videos on how games work, especially classic mechanics and audio/display tech. This is what makes gaming fun.
Most 8-bit games back at the time were coded in assembly language. This means they used a so-called "assembler" (mostly a "macro assembler" that was a bit more comfy. Some games were also coded in BASIC or other languages and then compiled (mostly strategy games etc.) - but most action games were done in assembly language. Very CPU dependant! The N64 was mostly coded in a "higher level language" like C or C++, to my understanding, but for some time critical things you still had to use assembly language. The problem isn't the 3D per se - it's that the bigger a project gets, programming in assembly language gets more and more time consuming and as the machines get faster you don't need the fastest speed for everything.
@@oldguy9051 A bit later on, many developers did their work on more powerful 16-bit computers, and used cross-assemblers and even cross-compilers (for languages like C) for the 8-bit computers. Additionally, BASIC was sometimes used wherever they could get away with it, and compiled BASIC for less CPU-intensive parts of games wasn't unheard of. But yeah, a lot of assembly/machine language was necessary to get the most out of the 8-bit computers.
+Jim Leonard , yes for NTSC it happens 60 times a second, for PAL it happens 50 times per second. That is why the speed of the 6510 CPU in the C64 is also different between NTSC and PAL. But the television is only able to update them at 30 frames and 25 frames per second - and uses an interlaced fields alternating between which lines to update. When hooking up an old system to a new monitor you can clearly see this interlacing going on resulting in a jagged look for animation.
I really appreciated what you posted in the last video about sprites. Right before you covered it, I was typing up a question on how they were able to move above an area that was only allowed 2 colors :D
+AcrOfSpades we don't have these memory limitation anymore bruv, game design is a joke these days compared to what the smartest engineers did back then in order to produce a proper game
Tim Lesher if you compare today's growth of performance of what's considered a "standard" computer with the graphics of video games you will notice that the demand of new hardware stands in no relation to the "improvement" of the games. Games from 2010 look pretty much like games today, but now look at 2010's and today's specs of your computer. It's a shame that, instead of writing efficient code, developers rather make people buy better hardware so they can write even messier code.
CPU's have a small chunk that are dedicated to graphics. So it's a really small GPU...of course, those are leagues ahead of dedicated GPU's from decades ago...
My brother's notebook has Intel Core i5 CPU @2.4GHz with 4 cores, and nVidia GTX520MX GPU. It used CPU as a GPU too for a long time, having my brother swearing on low performance of games, until he found out about that and switched to "full performance" mode to use that GPU too. So yeah, some notebooks work with ignoring GPU by default. I think my dad's netbook(or idk, really small notebook) doesn't even have GPU at all and uses CPU in the same way.
Hi, I found this video really interesting and informative! I like the way people come up with really inventive ways to manage resources. Also, I like the new channel name; it makes sense with the info you're covering now.
I love this stuff. Partly because I had an Apple IIc (and the color-alternating text always bugged me), and partly because I just love learning how this kind of stuff used to work around massive limitations. Please make more.
I had a Commodore 128, a 64, an Atari 2600, a Nintendo, and played with Apple II in school. I always wondered why there was such a disparity in graphics and always felt like the C64 had some of the best graphics, even compared to NES. Thanks for making these. Please make more. I am fascinated by how they pulled off graphics and sound in the old systems.
Seeing CGA, EGA & VGA graphics would be awesome! Just wanted to also say I love these videos! They are very informative and I enjoy learning about different types of graphics.
Haha, oh wow... I got distracted by the awesome tracker music in the previous video (Part 1), and spent an hour downloading all my old favourites before finally returning to this video. Love hearing the tracker music in your videos.
You sir just earned a new subscriber :) I'm a games developer and computer scientist and we never covered this stuff in my studies so it's really nice to get a complete history of graphics systems.
Your aside at the end explained something a coworker from twenty years ago told me. He used to make commercials on the Commodore 64 and claimed that the system was way ahead of its time as far as graphics. I understood part of it - he said that the Commodore 64 had directly-accessible graphics hardware, which made rendering the graphics faster. The part I didn't understand until now was how a 1982 computer platform could render commercial-quality video with the very limited pixels and colors. The images at 5:00 and 5:04 are actually pretty nice considering the era.
These videos where actually useful. It's a mine of information. I feared it would be like other videos, but no. He actually puts efforts in the videos and actually knows his stuff. This is rare.
dude. this was invaluable for a nerd like myself. I've always been terrible with coding but I am always curious and wanting to learn. This broke everything down to such an easily comprehensible video. Thanks for your time!
Nice video. It has me all nostalgic. I remember Richard Garriott explaining colours on the Apple ][ and how he drew the Ultima shapes on graph paper to map each pixel and colour.
I think it's worth noting why an Apple II's color palette looks the way it does. In a sense, the earlier Apple II models don't display color at all in 'high-res color mode'. They basically use NTSC composite video's inherent limitations (as well as a generally poor video hardware implementation) to 'trick' a color monitor into displaying non-white pixels. NTSC color television was designed way back in the 50s, with backward compatibility in mind, since most people owned B&W TVs. To that end, the color portion of an NTSC signal is transmitted via a subcarrier signal alongside the B&W image, and offset in a way that doesn't interfere with it too much. ('Too much' is a key phrase here!) A monochrome TV or monitor just ignores the color signal, but a color one uses it along with the B&W image to figure out what hue and intensity a given pixel should be. The Apple II disables the color signal completely when it's in text mode, so you get nice, crisp, interference-free white letters on a black background. However, in hi-res mode, the Apple II enables the color signal subcarrier. Here's the trick, though: The Apple II doesn't actually send any color information on that subcarrier. Instead, it relies on the fact that the color subcarrier causes just enough interference with the B&W signal to create what are called NTSC artifacts; essentially noise on the screen. Two white pixels separated by a single black one would essentially blur together and be displayed as a single, colored pixel because the monitor can't entirely separate out the color subcarrier from the B&W image. The apparent color shown by the monitor depends on the pattern of alternating black and white pixels that are actually being drawn by the Apple II. This is also why the image look 'striped' when a hi-res color game is being displayed on a monochrome monitor. Incidentally, Apple IIs weren't the only computers to use this weird limitation of NTSC composite video to their advantage. A lot of early IBM PCs shipped with CGA graphics cards equipped with composite video outputs, and they would show the same NTSC artifacts when connected to a composite color monitor or TV. A handful of early PC games took advantage of this to display a wider palette of colors than the CGA card was otherwise able to display natively.
Loved revisiting Apple graphics. I remember writing assembly code to convert the screen to its mirror image. Since there are an even number (40) of 7-bit cells, you couldn't just reverse the 7 bits, or the greens would turn purple. And be sure not to break up any 2-bit whites that overlap byte boundaries. Fun times.
This series is awesome just found your videos and they are making me want to get back into programming. You are concise and informative while not becoming monotone or boring in the slightest. You got a me to sub after these two videos keep up the great work. I hope to see more of this series and will check out other stuff on your channel.
Palette changes were used in games, but they were limited to changing a few colors, such as the background color. The same concept was used to multiplex sprites.
Oh my goodness!..... MIND BLOWN.... Do you know how many years of my young life, I saw those lines on the screen and thought it was because the TV was terrible, because it was an old used TV? wow...
Also, the Atari 2600 does technically have a video chip. It's called the TIA, or Television Interface Adapter. It doesn't have any RAM to use as a frame buffer, though. It just has a 20-bit-wide register used to store the position of five kinda sprite-like on-screen objects per horizontal scanline. It had to be reprogrammed by the CPU for each new scanline, and it only had the horizontal blanking interval, that split-second when the TV shuts off the electron beams long enough to reset them to the left side of the screen, to do it in. That's what Atari programmers are talking about when they say they're "racing the beam."
+Shmeh Fleh If I remember correctly, the 2600 had a few special sprite-like registers. A "ball" (small sprite, like the Pong ball or Combat bullets), two "players" (paddles, tanks, cars, etc.) and two for the score. What got ugly was when you needed more than two of the player-type sprites. For instance, Pac Man needed five - you and the four ghosts. They would make this work (if I remember correctly) by using one for you, and by rapidly changing the position of a single "ghost" sprite in order to make it appear like there were four of them. This is why they flickered a lot. In Ms. Pac Man, they synchronized this to the scan-line, so the ghosts would only flicker if two or more shared a single horizonal row. Activision had some of the best 2600 programmers. They had ways to hide all that artifacting so games like Demon Attack seemed to go well beyond what a 2600 is supposedly capable of.
My first machine was an 8086 with CGA monitor..we ended up using it well into the 90s and at one point the entire screen would just turn everything red. A smack to the monitor would sometimes fix it. When I got into high school and started taking a micro electronics course, I borrowed a soldering pen and some solder and had a look at it. Turned out some had corroded, so I resoldered part of the board and we never had anymore trouble.
Not mentioned: Apple // used two graphics screens that you could independently update and CALL successively to create motion. Also: Shape tables for sprites.
For those who don't know, this was the last video before he changed his channel name from "TheiBookguy" to "The-8-bitguy"
thanx for clearing that up
thanx for clearing that up
i'd like to pretend i'm too cool to care about that, but i was actually wondering
Nah, it was his evil twin
@@mattasaccount1663 redditors amirite
These have been awesome. I _really_ hope you do the video on CGA/EGA/etc modes for IBM PCs!
Hey Lazygamer reveiws! I just finished watching one of your vids and I don't even know how I just idk xD #illuminati anyways Hi!
SVGA was so fun
Well he did that video idea
didn't think i'd see you here
LGR!!! Love your channel bro!
As a kid during the 80's, this stuff seemed like magic and it always had my mind wondering "how'd they do it?". Thanks to the internet and people such as yourself posting content like this, I can finally understand. It's calming to learn how this work. Thank you.
RIP the iBook Guy. He will be dearly missed. Luckily, his clone (the 8-bit Guy) is here to keep the channel alive.
He is the same.
Duhh...
@@zacharycalina338 WOOOOOOSH
@@zacharycalina338 wooooosh
@@zacharycalina338 woosh
@@zacharycalina338 you will get woooshed for eternity
As far as I know, the ghosts in Pacman where "blinking" because only one sprite (out of the 4 ghost sprites) where rendered per frame. But this "optimization" makes them look more "ghosty" :)
+Simonschreibt Correct. The 2600 didn't have enough sprites to render them all at once, so it had to do a time-share.
+Simonschreibt
The pacman game as it was sold was only a prototype. A programmer came up with a proof of concept, showed it to management and management decided to go with it instead of letting the programmer actually finish the game.
+bobnoel *cough cough*
EA
*cough cough*
+bobnoel Atari Pacman wasn't unfinished, it's that they couldn't have the same maze because of technical limitations (not enough vertical pixels if they kept it vertical, and not laterally symmetrical (needed for background graphics) if maybe they laid it on its side). Not having the same maze meant it simply sucked. The build up and disappointment when it was released embittered an entire generation of people.
+bobnoel According to 'Racing the beam', it was _based_ on a prototype rather than giving the programmer time to rewrite from scratch. It also had to fit in a 4k ROM which limited the functionality. What's really amazing is how much better Ms Pacman was.
The Apple II used "artifact" colors -- same as with the hi-res modes of the Atari 8-bit computer systems (400, 800, XL, XE), Tandy/TRS-80 Color Computer, Dragon 32/64, and the "composite color" mode of some IBM CGA games. Atari 8-bit systems also had a trick where every scan line of the display could be in a different graphics mode. Games often used this to get more colors on the screen, or to show a status line (high score, lives left, etc.) at the top or bottom of the screen.
What you were thinking of is that each command for a new graphic mode (represented by a display list command) had an interrupt flag that interrupts the video chip (if turned on), allowing code to execute before that graphic mode is drawn that allows you to change the graphics register to a different color.
> Atari 8-bit systems also had a trick where every scan line of the display could be in a different graphics mode.
!!
Do you mean a different resolution or just a palette-swap like the CGA "cold" pallet and "warm" palette??
@@jessfucket The Atari "display list" could change the graphics mode every scan line of the GTIA chip. Made for some very weird screens.
@@jessfucket You could switch to different-resolution modes, or even between text and graphics modes (that was how Atari BASIC could put four lines of interactive text at the bottom of a graphics screen, very handy). It was also possible to swap colors in the color palette using an interrupt routine, or even to swap in a custom character set in the text modes for character graphics. And most of the graphics modes had color indirection for the colors, so it wasn't like CGA where you just had two possibilities--the particular mode might have 4 colors, but those colors could be any of 128 possibilities, and if you used display-list interrupts you could change those on different scan lines.
So the fancier Atari games tended to have this mix of wildly different types of video display on different horizontal bands of the screen, and there was also a popular effect for title screens and such were you could have pulsing rainbow bands streaming down the screen. It's one of those things that screams "Atari 8-bit".
They're not exactly the same, though. The Atari 8-bits, when in hi-res mode (320x192 pixels on a standard screen, which it didn't necessarily have to adhere to, by the way) use all 8 bits of each byte, and therefore can only produce black, white, and two other colors that depend on the particular graphics chips they use and their revisions. On the Apple II series, the 6 colors are consistent and predictable, while on the Atari, 2 of the 4 colors are kind of up in the air. Fortunately, the hue control can usually get you a couple of usable colors, but 4 is still less than 6, and the _Ultima_ games, contrary to what many Atari 8-bit owners seem to believe, suffer on the Atari 8-bits in comparison to the original Apple II versions. You're lucky if you even get blue water and green forests--sometimes these colors are reversed, and there is no orange and purple (or you get orange/brown and blue but no green nor purple--it depends!). In fact, there were two versions of some/all _Ultima_ games on the Atari that reversed the colors in case that would help.
Maybe Origin should have used some of the Atari 8-bits' other modes and capabilities--of which there are many--for the _Ultima_ conversions. The problem with this, however, is that the resolution would have been much lower. On the C64/C128 there was color memory that allowed it to more or less match the Apple II for the _Ultima_ series, including resolution. The Apple II, for which these games were originally designed of course, did some things better, while the C64/C128 did other things better, but they were a pretty close match concerning the _Ultima_ games, at least. In most ways and with most games they were strikingly different, and the same goes for the Atari 8-bits. No other 8-bit computer could match the latter when it came to games that were designed specifically for it, although the same could be said for the C64/C128 in different ways and with different games.
Great video, did not know about the Apple graphics. I didn't know about CPU graphics either but the SLOW and FAST commands on the Sinclair ZX81 make sense now. It's amazing how old computers were a result of the juggling act where designers had to balance functionality versus affordability.
+theimp67 Yep. I thought about including an example of the SLOW and FAST commands on the ZX81.
VERY informative. Love this series
true
oh hi alex meyers
Hi alex
Bruh what you doing here?
Actually, if you set the color bit when using a monochrome monitor, it would shift those seven pixel half a pixel-width to the left. It did the same thing on a color screen, Steve Wozniak generated colors by taking advantage of how the composite video signal was set up to relate color and position. You could take advantage of this to be able to get 560 pixel horizontal precision on positioning an object, even though the objects themselves were still limited to 280 distinct pixels (or 140 in color). I occasionally used the color bit to make things like smoother fonts.
You know this is the type of stuff your subscribers want to see when your last video had over *1 MILLION HITS*!!!
+James Campbell Well it did hit the front page of Reddit
+UncleChrist and Tom's Hardware posted it on facebook
+James Campbell Yea that was just cause of reddit
I'm not big on these.
I can tell how much time and work you put in to this.
Every diagram is done great and perfectly represents what you're talking about.
Please do the CGA, EGA & VGA graphics! I still remember writing 2D demos in assembler utilizing direct access to VGA memory. I never did anything pas the basic VGA 320x200x8bit, as it was a simple write to the chip. No pages... Those were the times :)
+Jachym Lukes Yeah, and it behaved like you expected. If you knew the VGA registers, they'd work the same on virtually all video cards of the time. It was only when one got into VESA resolutions that things started to get weird and hard to deal with.
Phyphor666 I've just remembered how my schoolmate found some memory chips, pressed deep into his carpet. I got them from him and they fitted to my Trident VGA. With them I was able to view "images" downloaded from BBSes in True Color :)
Definitely interested in the CGA, EGA, and VGA video
+Jachym Lukes YES. PLEASE
+Jachym Lukes Seconding this, I'd love to see these videos.
"If there's enough interest"
YES! Absolutely! Please continue with these videos! They're highly educational and interesting to watch!
I love this series! I wasn't even around for most of these graphics but the history of it is super interesting! I hope you keep making these beyond the 3 parts, as you suggested at the end of the video. I'm all for it!
Growing up through the evolution of graphics modes, I'd LOVE to see an episode on CGA/EGA/VGA/SVGA. I remember being a kid with a green monochrome screen, and just being so wowed by the glory of CGA, blown away by EGA, but my head just about exploded when seeing VGA for the first time. Kids these days just have no clue how good they have it, graphically speaking. Haha.
Great primer on old school computers! I miss those days (I programmed mostly for Atari 8-bit and Coleco). Atari called sprites "player/missile graphics". Four players 8 bits wide and 4 missiles 2 bits wide...but they were all 256 pixels tall (even taller than can fit on the screen!). They only had registers for horizontal position and were vertically placed by shifting the visible image within its very tall area!
It was odd but allowed for tricks to vastly increase the number of sprites so long as only 4 appeared side by side at once...just define one player with multiple pictures within its 256 byte column then change the horizontal position of the player mid-scan.
Atari 8-bit machines used "display list interrupts" to change not only colour pallette but even display resolution so you could have a section of text, a section of low res, section of high res etc. In some ways superior to what the C64 could do.
The subject of how Atari graphics evolved (including how it influenced the Amiga) would be very interesting...from Atari 2600 racing the beam and the first player-missile graphics to the DLI and modes of the 8-bit computers and 5200 to how the Amiga was developed by the same people and evolved it to create HAM mode etc.
Those pioneer engineers were amazing with the creative ways they used limited technology to do so much!
could not agree more with this..nowadays they don't spend any time on optimizing the games/software, and it's even worse that this trend got into smartphone/tablet technology, for example the cheapest "Android" brand new phone was bloated with about 400 Mb of software just from google, instal any other app and the phone is frozen....
Actually, the C64 has raster interrupts, which are effectively the equivalent of DLIs on the Atari. It can (without any flickering) similarly multiplex its 8 sprites (each 24x21) using raster interrupts, among other things such as switching modes and changing color registers on specific scan lines--anything the CPU can do within the limited time available. I think that a great many Atari 8-bit owners/fans are unaware of this. The C64 is generally more powerful when it comes to sprites, although of course the Atari 8-bits have their own advantages over the C64. Both can do DLIs/raster interrupts, though. I'm unaware of other 8-bit computers that have this capability.
@@rbrtck that is true. The C64 has better sprites (more if them plus they have multi colour support).
ANTIC DLIs are a bit better than VIC-II raster interrupts because you don't need to involve the main CPU every scan to change graphics modes, color palette etc. You just set up the display list program and the ANTIC does the rest. ANTIC is technically a full CPU itself and the display list is a kind pf program.
As for other 8 bit computers that use similar tricks the closest is the TMS9918/9928 and Yamaha 9938. For the sprites, they actually only have 4 but in the hardware they have 32+ "virtual" sprites and reposition the 4 real sprites (8 in the 9938) depending on the current scan line. That is why sprites flicker or disappear on TI/Coleco/MSX when more than 4 or 8 are side by side. These chips only have interrupts on vertical blank though; you need to poll for the current scan line and they don't have hardware support for pixel level scrolling, although the basic acceleration routines in the 9938 help with that a bit. That is not really the same though since the raster interrupt tricks are done in hardware.
@@markshanehayden4648 You're partially right about ANTIC, in that it can perform some of the dynamic screen operations on its own, albeit the more it does, the more cycles it "steals" from the CPU via DMA (the Atari 8-bit has a special version of the 6502 that can be halted for this purpose). I wouldn't call ANTIC a "full" CPU, though--it's more like a limited, special-purpose GPU, and DLIs that utilize the CPU are required for the more powerful, complex types of operations.
While the design of Atari 8-bit's graphics subsystem is more elegant, in the end there is not much difference between what it and the C64 can do in terms of dividing up the screen. Keep in mind that the much-touted DLI function always interrupts and uses the CPU, and that the C64's raster interrupt does the same thing (the latter may be programmatically more clunky, but it's still fundamentally the same thing). Neither computer's CPU is "chasing the beam" from the vertical blanking interval (that's what ANTIC and VIC-II are for).
Good video except those black lines on the left of the Atari 2600 are not because game code is running, it's just a bug in the video chip when a player object is repositioned on the previous line and the call didn't happen on a particular clock cycle.
+MrTBoneSF - Interesting.. I've always heard that it was not enough CPU time. Not all games have the black lines. but that would make sense for why even a sprite is affected when it moves in that area.
+The iBookGuy Racing the Beam if I remember correctly has an explanation of this. Also this question comes up a lot on the programming forum over at AtariAge ("why are they there?" and "how do I get rid of them"). Only games that have sprite reuse have the lines. Simple games with just two player sprites (like Combat) don't have to worry about the issue. Activision got around this by either having the kernel call the HMOVE on the exact cycle (near impossible to do in general code) or just calling HMOVE on every line so their games had a solid black border on the left. That area of the screen is usually in the non-playable space anyway since they had to leave a border for overscan on CRT tvs, so there was no harm in "window-boxing" the game. If the game naturally has a black background, you also wouldn't see the lines until the post-game color cycling (e.g. Space Invaders).
+MrTBoneSF - Thanks for that explanation. I hate it when I get stuff wrong in my videos.
+The iBookGuy Well, you got another thing wrong. The Atari 2600 ran at 160x192@60Hz(NTSC) or 160x228@50Hz(PAL).
+pocpic Not really, it was 320 pixels wide but the background graphics were 160 wide then always mirror-imaged to form the right half. Sprites could be positioned anywhere though. Most games had that full-screen symmetry but you could do tricky things with the raster interrupt to swap in new background graphics.
I wrote a program on an Apple II series machine which displayed Garfield the cat. Then I changed it to make Garfield's eyes close by redrawing on top of what I had already drawn. Surprisingly, the pixels around the edges of his eyes got messed up with blocks of colors I did not set. I never knew why that happened until now, some 32 or so years later! Great explanation.
You have had my interest. I want to see an episode on the NES, SNES, and Genesis era.
thanks for the trip down memory lane. It's been a long time since I've worked on these old machines!
I love how programmers of the Commodore 64, years after it's release, were able to get more colors and resolution out of it for static screens, not unlike the Amiga's HAM (Hold and Modify) mode where it could produce 4096 colors on a static screen.
I've seen a number of very nice video demos for the Atari 800 coming out of Poland.
Some C64 games did use that palette-switching trick in-game because you could set an interrupt to say how frequently (or infrequently) you wanted to make a change, so it didn't waste a lot of time when it happend. Though it was mostly used on title screens of games. The ST and Amiga used it all the time in backgrounds. A similar trick on the Acorn BBC Micro let you change graphics mode part-way down the screen, and was used in the game Elite to switch from monochrome to colour and back again, to save on screen memory.
The ZX Spectrum could do the same to partly mimic the extra colour cell resolution of its Timex cousin and the MSX. Again, used mostly on title screens, but because it was per-character cell, it could be used for individual game sprites; but it wasn't until 2011 and Buzzsaw+ that the effect was actually used in a game.
Darn, no mention of the Atari 8-bit computer's Display List Interrupts (which let you do some CPU-driven-style stuff, but without having to spend all of your time counting CPU cycles) -- color palette changes (useful for those typical rainbow color effects), repositioning sprites, etc.
Also, on the Atari and many other systems, you had hardware support for vertical & horizontal smooth scrolling (so moving per-pixel, even in cell-based modes like a 40x24 text screen), redefined character sets (fonts, useful for tile-based games -- e.g., instead of using 8-9K for bitmap mode & moving tons of data around, you'd use 1K of graphics data + 1-2K of 'font' data), and the ability to point the graphics chips at different parts of RAM... on the Atari, even on a per-scanline basis.
Practical example of combining a lot of these effects -- say you had a drawing that you basically 'compressed' into 4x8 multicolor cells, giving you around 160x200 pixels. It's only 1K for the font, plus 1K for the graphics data that defines which shapes are drawn where on the screen.
But then say you only draw the top half of the picture. Use the handy point-wherever-in-memory (Direct Memory Access / DMA) feature, plus the "flip the characterset upside-down at basically no cost" feature, to draw the mirror-image on the bottom half of the screen. Then use some color palette changes to 'tint' your picture blue, and tweak the horizontal scroll value on each scanline along the bottom half of the screen.
For less than 2KB you have a full-screen picture, in 8 colors (or more, if you do more of those per-scanline color changes), with an animated lake reflection effect. :) Such is the power of Atari's 1979 GTIA & ANTIC chips! They've aged quite well, I think!
These videos are so interesting! I definitely have more respect and appreciation for the programmers/designers that have come up with clever ways to circumvent these hardware limitations
Well, I'm quite interested by the CGA/VGA stuff on IBM PCs ^^"
+Ybalrid IBM PCs were only capable of CGA and Text Mode,
Only machines from 1990+ used VGA/EGA.
+Ybalrid please doi it!
+Scott Blacklock EGA was introduced in 1984 and VGA in 1987, so not quite. Also, you know you could just pop in an EGA or VGA ISA card in something like the IBM 5150, right? Even 8-bit ISA sound cards like the Sound Blaster or Adlib will work fine in machines of that age.
Your one of the smartest guys on CZcams in my opinion. watching some of your other videos, your able to to put new things into an old product to improve it, and your able to take things apart and fix these things, I apologize for not being specific but there's many different videos, but regardless, it's all rocket science to me at points, I can't imagine the schooling you must of went through to know all of this.
I'd love video's about CGA, EGA and VGA! I've done some very simple assembly programming in the early 90s and EGA really baffled me with the planar memory. VGA with mode 13 and mode X were really awesome! Now I have deeper understanding of computers I'd love another explanation to see if it makes sense to me now :-D
Great Job. Brings back memories. I teach computer science in High School. (AP, IB, Gen Ed) This would blow kids minds today.
Would you consider doing a video like this for more systems like MS-Dos computers from the 90s, Sega Master System, Sega Genesis, Super Nintendo and comparing them?
The Mega Drive and Super Nintendo basically works like the NES but with more bits-per-pixel, and more and larger sprites. The Master System too, although it doesn't really use color palettes AFAIK, instead opting for a higher color depth in sprites and tiles (4bpp compared to the NES 2bpp -- same as the MD/SNES).
Old DOS PC's basically work like what he described in the first part of the first video -- the "unusable" method that used too much memory.
Great video. Clear and concise explanations. I still have my Sinclair Spectrum , got it to learn Z80 assembler back then. When I started as a young electronics technician, one of the hardest things was getting hold of information. Today we are so spoilt with the internet ! Look forward to more of your material
Amazing Second best video ever... Do one on Amiga AGA Graphics too!
ditto.
That would be most interesting!
agreed, and HAM mode :)
+zandorius Definitely HAM mode. I never understood that. I guess I can read it on Wikipedia now, but I'm lazy. ;)
+Thiago Racca Me too
+Fredrik Jagenheim The Wikipedia pages do a pretty good job. It's one of those modes, like Apple II double-hi-res, that is easier to describe (and implement in hardware) than to write software for.
en.wikipedia.org/wiki/Original_Chip_Set#Denise
en.wikipedia.org/wiki/Hold-And-Modify
Thanks man. My 8, 12, and 15 year old loves these vids. It got my 12 year old girl excited enough she is actually playing with simple graphics now on an Arduino and 8x8 matrix display. She is really starting to appreciate what you were saying as a result.
I vote for Amiga. There's loads of weird interesting hacks from the Amiga to talk about. All from 1985 too. HAM, Extra Half Bright, the Copper chip, the Blitter, bitplanes, reusing hardware sprites as you go down the screen. Also why it worked so well compared to a CPU bound Atari ST. This site details some amazing Copper chip tricks. www.codetapper.com/amiga/sprite-tricks/
+Octamed I vote too. Esp for HAM (Hold and Modify) it was truly the first time I saw graphics that were photo realistic on a personal computer.
Makes me sad to think about what could have been, they really snatched defeat from the jaws of victory.
The Amiga is the big brother of the Atari 800 having it's video chip designed by the same person who did the Atari 800's video chip. Atari eventually added a copper chip of it's own.
Absolutely. Like this little gem on the Amiga 500 that uses HAM + Blitter objects and still has time to play the background music with sound effects: czcams.com/video/JJczdYO8N1c/video.html And this one for 1985's Amiga 1000: czcams.com/video/XDdMoglmUbs/video.html
I love that your videos have so many languages available for subtitles. Thanks!
Please do an EGA and CGA follow up. I love thinking about the tech that went into those old retro games of my youth :)
+Gaming Jay Agreed. I would especially love to read about the register-level programming for these boards. The CGA card, in particular, could be programmed for all kinds of funky modes that IBM never intended.
I remember one package we used in college (Micro PLATO, a coursework package) which tweaked CGA registers to produce a mode with fewer pixels horizonally, and more vertically. This often messed with the monitor's ability to sync, so we'd have to twiddle the vertical-hold knob in order to get a stable picture when using the program.
There were other non-standard modes that were used by various games (like ElvenSoft's Round42). Sadly, very few of these games would play on more modern video cards, because they were using undocumented register-level hacks to produce the video modes. (I remember my ATI VGA Wonder card included a small application to put the card into a CGA-compatible mode that would let it support these modes. IBM's VGA products didn't have the ability at all.)
+Shamino0 that's neat. I find video and memory hacks very interesting. Reminds me of back when I used to code in Turbo C and had to work out all kinds of little hacks to get my programs to run
Outstanding video! Very detailed & informative, but not at all boring, overly technical, or too hard to understand. Excellent job!
I played a lot of Atari games, and only noticed those black lines on a few games.
You won't notice them at all in Pong...
You are the best computer guy to talk to. I understood everything that you said and you kept it interesting. You should give lectures!
Would love to see one on EGA, CGA, & VGA modes especially your thoughts on the 8088mph demo which achieves 1k colors in CGA. Great work on the vids!
i watched this video about 15 time & am ready to watch it 1000 time so much greatness in this video. thanks so much
You should do an episode on programming languages back then. What was used for the Apple II, the Atari 2600, Nintendo, Sega master system.
What did the IDE look like?
I have searched for Nintendo code but could not find anything. It seems that nobody has open sourced their games from that era.
NES games (and games for other computers and consoles from the 8-bit and 16-bit era) were almost always programmed using assembler language, which is basically giving instructions to the CPU etc.directly (whereas code in C etc. has to be compiled first.)
I've done a few videos with AppleSoft basic using an emulator and screen capture. I do have images for C and a few other languages. I also have a II GS emulator. Anything in particular you want covered?
Bryon Lape
Thanks. I am checking it out now.
louis tournas Thanks. I am trying to find the C compiler images I've used before. Have some ideas for C code on the Apple.
There are different "levels" of code.
First is "machine code", which is the lowest level. It's literally nothing but 0s and 1s (or hexadecimal). It's the hardest to use, but takes up the least amount of RAM (and ROM space) because the CPU doesn't have to convert anything. Machine code was mainly used in computers from the 50s and 60s.
Next is "Assembly". These are machine-specific codes, used mostly in old systems that didn't have that much RAM. These hardware-specific languages used actual words instead of 0s and 1s, but were still difficult to learn and master because they were based on how computers operate instead of how human minds operate. That made them extremely efficient when it came to RAM usage.
Next are the languages you might be more familiar with, like C, Java, and BASIC. These are designed to be used in as many machines as possible. They, with a few intentional exceptions, were designed more with how the human mind operates, which made them easier to master than machine code or assembly. They are also more taxing on the CPU because the CPU had to convert the code into "machine code" before it could be used.
Finally, you have programs that convert user input into useable code. Examples include Raptor and Warioware DIY.
I'm glad I randomly found your videos one day, they're interesting and fun and technical enough to keep me interested without becoming tedious. Love to see more stuff about graphics modes, but general 'how old machines did X' videos are always super interesting too.
These videos are wonderful! Thank you so much. I'm looking forward to seeing the video on game music.
Do you think you could talk about SNES graphics, in particular Mode 7?
similar to NES
I'm doing a course currently that covers all aspects of making a game in modern engines, from using a 3d tool to create and animate objects to programming the engine to control and utilise them, and I love watching these videos about older systems that were able to do amazing things because of clever programming.
1:56 notice the emphasis on the H
whyte
wHite
cool wHip
The mechanism used to determine colors on the Apple II (and TRS-80 CoCo) is pretty straightforward, actually. It all has to do with the NTSC composite video signal. When there is no colorburst signal, then the high/low signal strength determines brightness of where the beam is. Associating 1 bits with high and 0 bits with low creates a monochrome signal.
When there's a colorburst signal, however, the signal pulses are relative to it. A high/low signal will produce a particular color depending on its width and phasing with respect to the colorburst.
The Apple II took advantage of this. Odd pixels would produce a pulse aligned with green, and even with purple. The "palette" bit would shift that cell over by a half-pixel. This would make them align with orange and blue. Any adjacent pair of identical pixels would render as black or white. In the absence of a colorburst signal (or on a monochrome monitor) the palette bit would simply shift the pixels by 1/2 their normal width.
In the //e and //c, there was also a double-high-res mode. By doubling the number of pixels in the same horizontal space (1/4 of the colorburst width), you could hit 4 phases at once (pixel-shifting was not supported in double-hi-res mode - the 8th bit of each byte was just ignored.) This would therefore require four adjacent pixels to generate black or white, and various patterns could produce 16 colors. (The same 16 colors used in low-res mode.)
It's worth noting that the Apple //c and //e had circuitry to disable the colorburst signal when in text mode. Apple's monitors (and properly designed monitors from other manufacturers) would detect this and produce a proper monochrome image (no color fringing) when in text mode. But a lot of TVs and monitors would not do that.
The TRS-80 CoCo was similar. Its high resolution mode also had pixels half the width of a the colorburst, so odd/even pixels would produce red or blue. Both would produce an off-white (which Tandy called "buff") and black. Various other patterns could produce other color. I remember being very proud of discovering how to produce yellow on mine. There was also variant where "buff" became green. But that was pretty useless, because the odd/even artifacts would only display components of green.
The real nasty part of Apple II high-resolution graphics, however, was trying to map specific pixels onto the corresponding bytes in memory. It used an 8:1 row-interlace nested within a 64:1 interlace. This was, apparently, another Woz Hack designed to make the video generation circuitry easier to build. And in double-hi-res mode, adjacent bytes (of 7 pixels) would come from two different pages of video memory. (Similar to the way that 80-column text would take odd/even character-columns from different pages of video memory.) And then to make it even nastier, there were "screen holes" - 3 40-byte scan-lines would be represented as 128 bytes, with the leftover 8 bytes not being displayed. While the design probably made sense from a hardware-design perspective (a Woz-hack designed to minimize the number of chips,) it made software design a living nightmare.
See also:
en.wikipedia.org/wiki/Colorburst
en.wikipedia.org/wiki/Apple_II_graphics
+Shamino0 I should also add that designers of RGB video cards (including Apple's own IIgs) would have to emulate all of this in order for software to look right. I'm sure lots of hardware designers spent long weekends pulling their hair out in order to emulate NTSC-colorburst artifact colors on an RGB interface.
Please do the Amiga too! The Amiga had the most wonderful graphics of any machine in the late 80s, and had things like the blitter, HAM6, EHB modes, multiple simultaneous resolutions, planar graphics. The list goes on!
Yes, the Amiga. The Atari 800's big brother.
@@bjbell52 Low blow dude, low blow…
@@Mikebumpful No, he's right. The Amiga really is the direct relative of the Atari 800: czcams.com/video/WUQ1mcyYbdk/video.html
Another great ep! Can't wait for the sound/music episode.
Please normalise your volume levels! Thank you.. : )
+Bluewave256 Agreed. I had to keep turning up the volume during scenes when the iBook Guy was off camera, but then had to hastily turn it down when he was back on camera. This was something that should've easily been caught and fixed in post-production.
I'm more bothered by the environment change (going from an echoey room to a more silent room for voiceovers) than I am by the volume changes. I'm an audio engineer and I find the audio in most channels' video to be lacking. It's almost an afterthought.
Isn't it weird how we've came along way in digital advancements and video editing....
But people still can't sort out audio-leveling in videos?
Yours are some of the better explanations I ever had on this topic. Congratulations!
I think it's called chasing the beam. Atari programmers were beasts
Absolutely fascinating. A lot of it goes over my head of course because there's so much to cover, but I really like learning about these sort of limitations that developers encountered, and the different ways people addressed them using the same resources.
4:09 - I don't think that on modern system it will use 90% of CPU. 1920x1080 = 2 073 600 pixels. Every pixel has three 1 byte colors (RGB). So, 3 * 1 * 2 073 600 = 6 220 800 colored subpixels in frame. Most monitors are 60 Hz, so 6 220 800 * 60 = 373 248 000 calculations in second. Is it much for modern 4-8 core 3-4 GHz CPU? It will take like 10-20% from one core. Correct me if I'm wrong.
90% came from structure of video signal: these 90% are when ray is visible and 'draws' a picture, while another 10% it's off and performs 'flyback' coming right to left and at the end of frame from bottom to up. That time between frames is best for actual computing because your code doesn't get interrupted after just couple of microseconds.
I highly doubt modern CPU could change context just after sending out another pixel, that's pretty slow operation: push all registers to stack, change SP, pop registers from another stack, etc. It would easily take 10 clock cycles and that's how much is left to draw each pixel. I'm not even sure 10 cycles is enough for each pixel, because CPU here tries to perform at least some clever decoding (for ex. JPEG image on the fly), so it's not as simple as mov from memory, other way we wouldn't need this CPU-assisted mode after all!
So it's safe to think one of cores would be 90% busy drawing graphics even now.
The entirety of the usefulness of the Internet has nothing on this video's line of discussion and revelation. Keep up the badass videos on how games work, especially classic mechanics and audio/display tech. This is what makes gaming fun.
Do you know what kind of programs they used to code 8-bit games, or even 3d games for the Nintendo 64?
Most 8-bit games back at the time were coded in assembly language. This means they used a so-called "assembler" (mostly a "macro assembler" that was a bit more comfy. Some games were also coded in BASIC or other languages and then compiled (mostly strategy games etc.) - but most action games were done in assembly language. Very CPU dependant!
The N64 was mostly coded in a "higher level language" like C or C++, to my understanding, but for some time critical things you still had to use assembly language.
The problem isn't the 3D per se - it's that the bigger a project gets, programming in assembly language gets more and more time consuming and as the machines get faster you don't need the fastest speed for everything.
@@oldguy9051 A bit later on, many developers did their work on more powerful 16-bit computers, and used cross-assemblers and even cross-compilers (for languages like C) for the 8-bit computers. Additionally, BASIC was sometimes used wherever they could get away with it, and compiled BASIC for less CPU-intensive parts of games wasn't unheard of. But yeah, a lot of assembly/machine language was necessary to get the most out of the 8-bit computers.
*CONGRATULATIONS* I'm currently binge watching every video on your channel.
It happens 60 times a second, not 30. But otherwise, very nice video and nice visual explanation of the Apple II graphics mode.
+Jim Leonard , yes for NTSC it happens 60 times a second, for PAL it happens 50 times per second. That is why the speed of the 6510 CPU in the C64 is also different between NTSC and PAL. But the television is only able to update them at 30 frames and 25 frames per second - and uses an interlaced fields alternating between which lines to update. When hooking up an old system to a new monitor you can clearly see this interlacing going on resulting in a jagged look for animation.
Each field is a new image; the graphics are updated and displayed 60 times per second on NTSC systems (actually 59.94).
+64jcl That artifacting is actually because newer sets misinterpret the output of old consoles as 480i instead of 240p.
+Jim Leonard 60Hz per field, but due to interlacing, it takes two fields to render each frame, so there's a 30Hz frame rate.
Do you agree that there are 60 competely different images generated by the hardware per second?
Excellent series - thanks! Used to play games in the 80's on those machines and had no idea how complicated graphics modes really were!
Wtf why is ben ten in this video
it existed 30 years ? thought it was from 2005 or smth like that
Because enthusiasts will take it as a challenge to make art using old limitations, on an actual machine.
Great topic for this series. My first PC was an Atari 400; never knew what was going on under the hood.
was that a thing from ben 10 at 5:01? lol on a commodor? xD
+Realization Fourarms, how did it end up there?
yes, it was Four Arms, Commodor made.
I really appreciated what you posted in the last video about sprites. Right before you covered it, I was typing up a question on how they were able to move above an area that was only allowed 2 colors :D
4:10 "description: makes video" r/technicallythetruth
I love all these old tech videos dude. Thanks for breaking it down for us, and keep doing what you're doing.
But how do modern day graphics work though? >_>
MS Paint bruh
Very complicated math and highly skilled artists, including modeling, textures, environments etc.
+AcrOfSpades we don't have these memory limitation anymore bruv, game design is a joke these days compared to what the smartest engineers did back then in order to produce a proper game
+BassApps Oh, hardcore optimization still exists. It's just that some of it is done by the programmers who write the drivers.
Tim Lesher if you compare today's growth of performance of what's considered a "standard" computer with the graphics of video games you will notice that the demand of new hardware stands in no relation to the "improvement" of the games.
Games from 2010 look pretty much like games today, but now look at 2010's and today's specs of your computer.
It's a shame that, instead of writing efficient code, developers rather make people buy better hardware so they can write even messier code.
Things making so much sense now... I'm definitely loving this series you started!
I ran Windows 7 w/o GPU, it is possible, you really could see how the CPU gets everything on scren pixel by pixel.
WinXP ran worse than 7 tho.
CPU's have a small chunk that are dedicated to graphics. So it's a really small GPU...of course, those are leagues ahead of dedicated GPU's from decades ago...
My brother's notebook has Intel Core i5 CPU @2.4GHz with 4 cores, and nVidia GTX520MX GPU.
It used CPU as a GPU too for a long time, having my brother swearing on low performance of games, until he found out about that and switched to "full performance" mode to use that GPU too.
So yeah, some notebooks work with ignoring GPU by default.
I think my dad's netbook(or idk, really small notebook) doesn't even have GPU at all and uses CPU in the same way.
This is So interesting. I have shown these videos to my son who's 19 and loves the old systems. Thanks for showing us.
Cool, your Dislikes are displayed binary. Only 5, good work. ;)
101.......................................ugh OMG CORNY lol
256
Hey, I really like your neat networking cable managing. Also.. if you worked on games in the late 80s early 90s.. you're my hero.
Too oversimplified.. I like simplicity, but go deeper! :)
Hi, I found this video really interesting and informative! I like the way people come up with really inventive ways to manage resources. Also, I like the new channel name; it makes sense with the info you're covering now.
I love this stuff. Partly because I had an Apple IIc (and the color-alternating text always bugged me), and partly because I just love learning how this kind of stuff used to work around massive limitations. Please make more.
I've really enjoyed both parts to this series so far.
Keep up the good informative work!
I had a Commodore 128, a 64, an Atari 2600, a Nintendo, and played with Apple II in school. I always wondered why there was such a disparity in graphics and always felt like the C64 had some of the best graphics, even compared to NES. Thanks for making these. Please make more. I am fascinated by how they pulled off graphics and sound in the old systems.
Seeing CGA, EGA & VGA graphics would be awesome! Just wanted to also say I love these videos! They are very informative and I enjoy learning about different types of graphics.
Haha, oh wow... I got distracted by the awesome tracker music in the previous video (Part 1), and spent an hour downloading all my old favourites before finally returning to this video. Love hearing the tracker music in your videos.
You sir just earned a new subscriber :) I'm a games developer and computer scientist and we never covered this stuff in my studies so it's really nice to get a complete history of graphics systems.
Your aside at the end explained something a coworker from twenty years ago told me. He used to make commercials on the Commodore 64 and claimed that the system was way ahead of its time as far as graphics. I understood part of it - he said that the Commodore 64 had directly-accessible graphics hardware, which made rendering the graphics faster. The part I didn't understand until now was how a 1982 computer platform could render commercial-quality video with the very limited pixels and colors. The images at 5:00 and 5:04 are actually pretty nice considering the era.
0:40 "Let's break it down a bit further"
Nice pun. 10/10
response
These videos where actually useful. It's a mine of information. I feared it would be like other videos, but no. He actually puts efforts in the videos and actually knows his stuff. This is rare.
dude. this was invaluable for a nerd like myself. I've always been terrible with coding but I am always curious and wanting to learn. This broke everything down to such an easily comprehensible video. Thanks for your time!
Nice video. It has me all nostalgic. I remember Richard Garriott explaining colours on the Apple ][ and how he drew the Ultima shapes on graph paper to map each pixel and colour.
This is very cool. I had no idea that so much effort went into designing graphics for these older systems.
I think it's worth noting why an Apple II's color palette looks the way it does. In a sense, the earlier Apple II models don't display color at all in 'high-res color mode'. They basically use NTSC composite video's inherent limitations (as well as a generally poor video hardware implementation) to 'trick' a color monitor into displaying non-white pixels.
NTSC color television was designed way back in the 50s, with backward compatibility in mind, since most people owned B&W TVs. To that end, the color portion of an NTSC signal is transmitted via a subcarrier signal alongside the B&W image, and offset in a way that doesn't interfere with it too much. ('Too much' is a key phrase here!) A monochrome TV or monitor just ignores the color signal, but a color one uses it along with the B&W image to figure out what hue and intensity a given pixel should be.
The Apple II disables the color signal completely when it's in text mode, so you get nice, crisp, interference-free white letters on a black background. However, in hi-res mode, the Apple II enables the color signal subcarrier. Here's the trick, though: The Apple II doesn't actually send any color information on that subcarrier. Instead, it relies on the fact that the color subcarrier causes just enough interference with the B&W signal to create what are called NTSC artifacts; essentially noise on the screen. Two white pixels separated by a single black one would essentially blur together and be displayed as a single, colored pixel because the monitor can't entirely separate out the color subcarrier from the B&W image. The apparent color shown by the monitor depends on the pattern of alternating black and white pixels that are actually being drawn by the Apple II. This is also why the image look 'striped' when a hi-res color game is being displayed on a monochrome monitor.
Incidentally, Apple IIs weren't the only computers to use this weird limitation of NTSC composite video to their advantage. A lot of early IBM PCs shipped with CGA graphics cards equipped with composite video outputs, and they would show the same NTSC artifacts when connected to a composite color monitor or TV. A handful of early PC games took advantage of this to display a wider palette of colors than the CGA card was otherwise able to display natively.
Love the videos, man! You really put into perspective just how amazing older computers were, even compared to now.
Your two videos were awesome. Made me respect even more the oldshool graphic artists
I really like the music at the end (and your entire video of course, it is so interesting). Thanks a lot, you are doing a very great job!
Loved revisiting Apple graphics. I remember writing assembly code to convert the screen to its mirror image. Since there are an even number (40) of 7-bit cells, you couldn't just reverse the 7 bits, or the greens would turn purple. And be sure not to break up any 2-bit whites that overlap byte boundaries. Fun times.
This series is awesome just found your videos and they are making me want to get back into programming. You are concise and informative while not becoming monotone or boring in the slightest. You got a me to sub after these two videos keep up the great work. I hope to see more of this series and will check out other stuff on your channel.
Palette changes were used in games, but they were limited to changing a few colors, such as the background color. The same concept was used to multiplex sprites.
Just seeing these 8 bit graphics, my brain floods me up with memories of my good old days.
Oh my goodness!..... MIND BLOWN.... Do you know how many years of my young life, I saw those lines on the screen and thought it was because the TV was terrible, because it was an old used TV? wow...
These videos are terrific. Please keep them coming!
Also, the Atari 2600 does technically have a video chip. It's called the TIA, or Television Interface Adapter. It doesn't have any RAM to use as a frame buffer, though. It just has a 20-bit-wide register used to store the position of five kinda sprite-like on-screen objects per horizontal scanline. It had to be reprogrammed by the CPU for each new scanline, and it only had the horizontal blanking interval, that split-second when the TV shuts off the electron beams long enough to reset them to the left side of the screen, to do it in. That's what Atari programmers are talking about when they say they're "racing the beam."
+Shmeh Fleh If I remember correctly, the 2600 had a few special sprite-like registers. A "ball" (small sprite, like the Pong ball or Combat bullets), two "players" (paddles, tanks, cars, etc.) and two for the score.
What got ugly was when you needed more than two of the player-type sprites. For instance, Pac Man needed five - you and the four ghosts. They would make this work (if I remember correctly) by using one for you, and by rapidly changing the position of a single "ghost" sprite in order to make it appear like there were four of them. This is why they flickered a lot. In Ms. Pac Man, they synchronized this to the scan-line, so the ghosts would only flicker if two or more shared a single horizonal row.
Activision had some of the best 2600 programmers. They had ways to hide all that artifacting so games like Demon Attack seemed to go well beyond what a 2600 is supposedly capable of.
The Apple 2 graphics sound really neat, and it shows the ingenuity of programmers back in the day having to work with the relatively limited hardware.
That apple II graphics system was wild!
Still enjoying this in-depth style of video, keep up the good work! 👍
My first machine was an 8086 with CGA monitor..we ended up using it well into the 90s and at one point the entire screen would just turn everything red. A smack to the monitor would sometimes fix it. When I got into high school and started taking a micro electronics course, I borrowed a soldering pen and some solder and had a look at it. Turned out some had corroded, so I resoldered part of the board and we never had anymore trouble.
definitely do the ibm video modes - those graphics were my childhood and i find this so interesting
Not mentioned: Apple // used two graphics screens that you could independently update and CALL successively to create motion. Also: Shape tables for sprites.