How “oldschool” graphics work, part 2 – Apple and Atari

July 31, 2019 posted by

Welcome to part 2 of “How Old School Graphics Work”. Now, in the last episode, I covered some of the more popular systems in the eighties, like the Nintendo and the Commodore systems, and in this episode I’m going to cover the Apple II and some other systems. Now, the Apple II is one of the more complicated and hard to explain graphics of all, and to be honest it actually works like two completely different computers depending upon whether you have a monochrome monitor or color monitor attached to it take this example this is a zoomed in view of what the pixels would look like on each type. Now, to better understand why it works this way let’s break it down a bit further. The screen is divided up into sections of 7 pixels each. So, let’s see what goes on inside these sections. Eight bits of memory are used to define the 7 pixels. The leftover bit is used to change the palette. So, here’s how this works: on a monochrome monitor, if you turn on some bits in memory like this, the corresponding pixels will turn on, and you’ll get the result you pretty much expected. So, what happens when we toggle this bit on and off? Pretty much nothing. So, on a monochrome screen, the Apple II had a very crisp graphics display and was generally great for business applications. OK, now let’s add a color monitor for comparison. One of the first things you might notice when looking at an Apple II on a color monitor is that the text often looks rainbow-colored. Now, there’s actually a reason for this and it has to do with the way the machine produces color. So, let’s go back to our pixel diagram. If you turn on some bits you’ll end up with colors, and you change the color by moving the location of the pixel like this. If you move the pixel to one side, you get green, and on the other side you get violet. Now, if you put two pixels next to each other you get white. So, that gives you four possible colors. But remember this control bit here? Watch what happens when we turn it on now. Notice the colors change to orange and blue. So, that extra control bit allows you to use two additional colors. But keep in mind that you can’t use these colors in the same 7-bit section as these colors, so it’s very difficult to have blue and green next to each other on the screen, unless you line it up just perfectly. And now you can see why text would look rainbow-colored when using a color monitor. Now, we’ve been talking about high resolution mode, which almost all games were designed for, but Apple also gave us a low resolution mode with 40 by 48 pixels. The pixels are huge and chunky, but you do get a total of 16 colors, hence why the Apple II claims to be a 16-color computer. Now, later on, when Apple introduced the Apple IIc and Apple IIe computers, they did add the ability for more colors in high resolution mode, but it was rarely used because game developers wanted to maintain compatibility with older Apples. All right. So if you found that confusing, don’t feel bad. There are very few people that really comprehend how Apple II graphics work. And also I want to defend the computer a little bit for those who might say, “Wow! It can only do six colors when in high resolution graphics mode for games and stuff. That’s terrible!” But you kind of have to keep it in perspective that this machine came out in 1977, which was a good five years earlier than systems like the Nintendo and the Commodore. So, OK, there’s one more type of graphics system I want to talk about. It’s called CPU-driven graphics, and let me show you how this works. I created some oversized pixels on this illustration. First of all, you have to keep in mind that the pixels are drawn on the screen one at a time starting on the top-left, moving to the right, and then dropping down. Of course, all this happens in the blink of an eye. In fact, that happens 30 times a second. Most computers have a dedicated video chip that sends pulses to the monitor, in the correct order and timing, to draw the picture on the screen. However, some systems had no video chip at all, and use the CPU to drive the pulses directly. OK, so this does actually work, but it requires an enormous amount of the CPU’s time in order to pull this off. So, that left very little CPU time left over to run game code. Imagine if they did this on a modern system, and you opened your task manager, and there was always a task running called “Video Generator”, and it took up ninety percent of your computer’s CPU time. What a drag that would be, huh? Games designed for the Atari 2600 were quite a challenge because of this. In fact, if you ever noticed in some games, if you look over to the left side of the screen and see these mysterious black lines, those are there because game code is running and there’s just not enough time to draw the screen and run the game code at the same time. Now, one last thing I’m going to mention is it is actually possible to use a little bit of CPU-driven graphics even on a machine that has a traditional graphics chip. You know those color cells we talked about in the last episode? Well, if a programmer wanted, he could use the CPU to change the color palette on each scanline. This allowed some pretty fantastic artwork on the Commodore 64, but this was never used in games because it pretty much chewed up all of the available CPU time. All right, so that about wraps it up for this episode. In the next episode, I’m going to be covering how old school sound and music worked, and if there’s enough interest I might actually make one on IBM, CGA, EGA, and VGA graphics modes. Don’t forget to like my video and subscribe, and also check out my Facebook page–there’s a link down at the bottom. I’ll see you next time!


100 Replies to “How “oldschool” graphics work, part 2 – Apple and Atari”

  1. Chakkravarthi Raghavan says:

    Just seeing these 8 bit graphics, my brain floods me up with memories of my good old days.

  2. Fallen_Under10 says:

    Thanks to you, i can finally get an understanding on how i will create my game, thanks!

  3. Wanuby says:

    Man, taking me back to my childhood here. Yes, I am the kind of guy that the book "Ready Player One" had as a target audience

  4. REALAmERicANTigER says:

    I found u because im trying 2 teach my 5 year old son how important numbers are for video games

  5. Duncan Murray says:

    What about the Amiga HAM and copper stuff? Ta!

  6. Tyler Woodland says:

    back then the computers had 16 colors. and my computer mouse has 16 colors.

  7. jweinrub says:

    Great video!

  8. John Waller says:

    For some reason, he overlooked the commodore Amiga which had quite a different different format. It was based on bit planes. Each bit plane was essentially a monochrome display. To get more colors you would stack bit planes. 2 bit planes stacked would give you 4 colors per pixel, 3 would give you 8, on up to 5, which would give you 32 colors. Then there was the "HAM" mode which allowed the display of 4,096 colors, which was great for photographs.

  9. Goultek says:

    OMG, and when I'm working on my game I'm like : ok, which color do I make that one pixel rigth there, next to the other 1900 on that line….

  10. Shylok says:

    So, if they could drive art with a CPU, why didn't they just run two different CPU's (Which is pretty much what we do now)? They had the technology for it, didn't they?

  11. Rabinoperra says:

    It is actually great that this have spanish subtitles. KUDOS to you and the one who did the subs.

  12. gaming futures says:

    i watched this video about 15 time & am ready to watch it 1000 time so much greatness in this video. thanks so much

  13. Eddie Pires says:

    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

  14. storerestore says:

    The 2600 actually buffers player and playfield graphics, but only one width of the player/one half of the playfield at a time. The hardware will retain the register values if you don't update them, so a simple trick to double the CPU time is to only update the registers every other line, trading time for effective vertical resolution.

    When I first heard about this I thought it would be extremely finicky to keep the code in sync with the beam, but there is actually a register that when strobed will pause the CPU until the next horizontal "blank" starts. So, as long as you aren't pushing the envelope, you can rely on this functionality to keep in sync.

    Another interesting fact is that you can only set an absolute X position of a player/missile/ball by synchronizing the CPU to the beam and write to a strobe register exactly when the beam is at the position you want the sprite to start at. From there you can thankfully nudge the sprite horizontally relative to its current position.

  15. Raymond Gabriel says:

    I always wondered how they made those fine graphics on C64.

  16. Igor Sandu says:

    4:09 – I don't think that on modern system it will use 90% of CPU. 1920×1080 = 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.

  17. Infamousuk says:

    just discovered this.

    really interesting.

  18. RLomoterenge says:

    We’ve come a long way! Those Unreal Engine video games like DragonBall FighterZ and Samurai Showdown are the great grandkids of these games!

  19. Circle, Triangle, Circle says:

    I never thought I would find something like this interesting, but I really enjoyed this. Nice video!

  20. Fif Gallag says:

    Referring to a vague programmer as “he”, eh? Well, you’re not wrong about that

  21. Jimmy Duong says:

    This channel is gold for people who are interested in low level computer science stuff

  22. mouthmw says:


  23. NoPe1337 says:

    I don’t wanna sub you sub count is 777,000 that looks to cool

  24. Andrew Littler says:

    Why do you have all that tech stuck to your wall?

  25. Bob Cunningham says:

    No the ATARI 420/800 and game 5200 worked different and had multi chips for video,audio and processing…

  26. Alex Parris says:

    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!

  27. Little Star says:

    Entirely too little Atari content Dave. 5-part series on Atari would be awesome.

  28. Tea Masta says:

    4:12 yeah it would suck… Except for multi-threaded computing succa now you're only taking up 90% of the CPU's time on a single core… Would still suck essentially losing a full core through.

  29. Jelte Swinnen says:


  30. densch123 says:

    3:08 What I don't get:
    aside from that first bit that changed the color scheme, the coloring seems to work in pairs of 2 bits.
    11 gives white, 01 gives green or so.

    but the whole section is 7 bits long (leaving the first color scheme changing bit aside).

    how does that work?

    you would have one lonely bit over after filling the rest with bit pairs.

  31. Angelo Augvill says:

    Man. Technology had come a really long way.

  32. surfitlive says:

    Who the hell is the iBookGuy??????

  33. spicymeatball07 says:

    Hi great vid, I have just stumbled into your channel and would just like to say your intro screen is from one of my favourite games the gates of zendocon, I love to play this on my atari lynx 👍🎮

  34. Paul Hayden says:

    Back in the early 80's I went with IBM computers. They were easier to program and there were different graphic cards. The CGA was low res 16 color, EGA med res with 64 colors and VGA hi es with 256 colors.
    I miss those easy to program computers of the early 80's.

  35. Mr. gamer-man 64 says:

    the last of the i book guy and the Commodore 64 intro

  36. ThoolooExpress says:

    Wow, your lighting and color correction has come a long way since 2015.

  37. Johan Fredriksson says:

    This is sooooo interesting!! (Y)

  38. erik shure says:

    5:00 didn't know that Ben 10 was big in the 80s.

  39. CoolDudeClem says:

    I know this is an old video and all but one thing I've been wondering for a while is … Does the NTSC colour artifacting on the Apple II work in the same way on PAL systems? Or was it only monocrome in PAL or was it never even released PAL regions?

  40. Adarious Mistdancer says:

    I had a IIC .. interesting to see how that aspect of it worked.

  41. Adarious Mistdancer says:

    Also .. MCGA was an interesting technology way back then.

  42. scooter800m says:

    watching this and hearing cpu mode i imediately thought of an old early gen intel core cpu and the accompanying integrated graphics (or the lack there of). the graphics chips were so slow that it was almost faster to just turn the chip off and run the code off of the cpu while the game code was running. (what a treat that would be)

  43. joltdude says:

    Some things that were interesting for the Apple //e were two video cards made by Video 7 (one improved colors and the other converted the monochrome dithering to true greyscale at the expense of fuzzing up 1 pixel width lines for monochrome monitors… (made a custom switchbox that switched between the normal Apple // Composite and the Video 7 composite because of this) but both were interesting to use with apps such as Dazzle Draw) and a propriatary card made by Number Nine Graphics for the Apple //e

  44. John Browning says:

    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.

  45. VirtualBlaze says:

    2am = 8bit guy viewing time.

  46. Laurence Dobson says:

    1:55 erm, if you move two pixels next to each other you get hwhat now???

  47. SevenDeMagnus says:

    Cool Thanks. I like the EGA art when done right (the huge poster ones).

  48. ctakn says:

    991 000 th viewer

  49. Making Games says:

    Oh, yeah.. I remember that trick on the C-64. Used to be done in Demo's a lot. And it took me AGES to figure out.. You used machine code, which was actually faster than the scanline to create color changes where they couldn't be. It was a bit hit and miss and the color changes usually moved up and down in my experience. The example you showed was nice and clean, was it done on a C-64? Wow! How did you time it? A loop with a lot of tweaking? Or is it a trick?
    Then again, I didn't really know what I was doing, I never had a manual covering "machinecode" and I used to just literally poke around the memory to see what happened. Numbers like 49152 still stick to memory, it was where you could start writing machine code.. It took me a while to get to Assembly, nobody told me that it existed.. I thought everybody programmed with just numbers, like I did, haha! I even now remember things like 169 = LDA (load register A) and I think 201 was CMP-A (compare register A to the value next to 201.). And I think 240 was BEQ or Branch on equal, which made for nice spaghetticode…
    I remember I got the idea to create more color on the C-64, like you said, from the turbo-sound program. It made horizontal stripes by just flickering the background between red and black really fast in time with what it read from the tape. (Also it did that with the volume, producing little clicks, that would produce sound, hence the name). You could see and hear if your game had loaded by the patterns it made. Some games like frogger, my brother and me could sing along with the turbosound, which sounded like when you get a fax machine on the phone… I can still get passed that handshake signal when I get a fax, just by reproducing the turbo-sound singing we did. It never leaves you.
    It was a great time and apparently I had a ton of time on my hands. Lovely series you did.. really took me back… never want to use those machines AGAIN.

  50. Robert Pflieger says:

    2:33 The Apple ]['s low-resolution mode wasn't 40×48 PIXELS. It was 40×48 CHARACTERS. High-resolution mode was 80 CHARACTERS wide.

  51. Johannes Valks says:

    Cool video!

  52. Esteban Rico says:

    Can you explain action52?

  53. The 4th Steve says:

    as a 14 year old kid, i think older hardware is more interesting.
    commented from my Raspberry PI

  54. Esteban Rico says:

    Or 16 bit

  55. Radio Żelaza says:

    violet is technically magenta

  56. Obey The Law says:

    Great Job. Brings back memories. I teach computer science in High School. (AP, IB, Gen Ed) This would blow kids minds today.

  57. Mrs. Roper says:

    at 1:52 that's not violet, that's pink.

  58. VideoNOLA says:

    Not mentioned: Apple // used two graphics screens that you could independently update and CALL successively to create motion. Also: Shape tables for sprites.

  59. VideoNOLA says:

    Please explore the 3D0G Knight software collection at the Internet Archive!

  60. StormFront says:

    Ultima: Pagan…lol

  61. Ricardo Martínez M. says:

    When i saw the Quest of the Avatar… almost cry, what a great game back in the 80s.

  62. GAME6 TALK SYS says:

    翻訳本当に有り難い おつです

  63. Kasjop says:

    So how did graphics work on ZX 81?
    I just want to know.

  64. DANIEL CHERNOV says:

    News flash! It’s David Murray! 0:13

  65. Ben Frawley says:

    Fascinating !! Thanks for the explanation.

  66. Drew Britton says:

    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

  67. Cigmorfil says:

    In the original BBC micro version of Elite the programmers made use of timing to change the video mode part way down the screen: the top section with the action animation was a hi-res 2 colour mode but the scanner at the bottom was a lower res 4 colour mode.

  68. Er H says:

    i dream in code

  69. MrGleamMusic says:


  70. Shogo says:

    I wish this video was available 20 years ago, so i could find how the "magic" happens sooner.

  71. Luxi Turna says:

    if you haven't already, do a vid about CGA/EGA …and don't forget the undocumented CGA lo-rez mode that allowed 16 colors on a CGA screen. Nobody used it because it had VERY low resolution, probably half of 320 x 240 med rez, making it 160 x 120. Now THAT'S lo rez fo' yo' ass!

  72. CommunitySkratch says:

    cool video

  73. raidersfan 07 says:

    I am a KID, and I understand this all

  74. TheoremGames says:

    I grew up in the 80s, playing on these machines. I'm now a 42 year old software developer, and these machines inspired me. It amazes me how far we've come. Thanks for this great insight into my childhood!

  75. Manare71 says:

    Great explanation, as usual. I would have liked you to mention how graphics worked on a Oric micro computer, for that it was different from the rest.
    Keep up the good job!

  76. jokin gabiola says:

    and this was the last time we saw the ibook guy

  77. Israel Wolstein says:

    Woah 200K sub!!! Congrats mate, impressive 🙂

  78. Johannes Dolch says:

    This was when the name "The iBook Guy" really made no sense anymore. Good Riddance.

  79. Vincent Rightfulvids says:

    16 bit please

  80. Scott Breon says:

    How about a video on how vector graphics work?

  81. OwLMaster says:


  82. Kruemmelbande The Cat says:

    But the hoe did cpu driven graphics work with the ram? If id had no limitations it woud take much ram right?

  83. HowToBasic JR. says:

    Apple ][

  84. I'm Your Huckleberry says:

    Proof once more that Apple is $hit…as are its users.

  85. Максим Галайчук - Mypka_Max says:

    Raster colors never used on C64? What about games like CREATURES? [5:07]

  86. Walter White says:

    Now do a video on how ps4 graphics work….lol

  87. Allzombifood says:

    Im Working on game projects with these kinds of graphics, Thanks!

  88. cutemimi25 says:

    For those who don't know, this was the last video before he changed his channel name from "TheiBookguy" to "The-8-bitguy"

  89. King Katura says:

    do you got any info on how they learned to draw graphics for games? Because drawing was so much better surely they had to learn to draw worse in pixels during the first video games?

  90. Midori Gurin says:

    So what color does the 7th pixel make?

  91. Darren Murrey says:

    Hey dmurray almost me

  92. psovegeta says:

    I've seen those black lines in some Atari 2600 games. It would make sense that the developer would just not draw anything there so that the computer would have more time dedicated to running game code instead of drawing parts of a game room that are non-essential. That's a neat trick!

  93. skrat1001 says:

    You mean Apppple?

  94. Kyle Hill says:

    1:58 is the amount of colors possible on Apple II. Dad had me do edutainment on the C64 and for the most part had better colors. My favorite game was Bus Driver by Fisher Price had awesome colors on the C64. The school house was red brick and their was blue sky. The bus was yellow. The Apple II had a purple school house and the bus had a weird color. The sound was also gross. The C64 had an actual tune. C64 the kids looked like Lego figures.

  95. ophello says:

    Please join the 21st century and put a link to the other video parts in the description.

  96. Bill Cipher says:

    Боже храни человека, создавшего субтитры для этого видео)

  97. QuesteYT says:

    How old is Ben 10 if the Comm64 had a picture made in it o.o

  98. Shufei says:

    Please explain HOW to do cpu graphics on a C64.

  99. Aiden Fernandez says:


Leave a Comment

Your email address will not be published. Required fields are marked *