• Home
• projects
  • APK on Android
  • K-Cookies
  • deprecated
    • Assembly from Scratch
    • GladeExamples
    • Internal Debugger
    • Learner Kernel
    • Rock Race
    • linhead
• tutorials
  • IRC
  • Japanese
    • Accenting
    • hiragana
  • WIP
    • From Atoms to Coding
      • 0 Introduction
      • 1 - Chemistry And Electricity
        • 01 - Direct Current
        • 02 - Least Resistance
        • 03 - Diodes
        • 04 - Transistors
        • 05 - AND Gates
        • 06 - AND Abstraction
      • 2 - Logic And Numbers
        • 07 - Basic Logic
        • 08 - Hex-Decimal
        • 09 - Binary
        • 10 - Simplest Adder
        • 11 - Full Adder
      • 3 - CPU Components
        • 12 - MUX and DEMUX
        • 13 - RS Latch
        • 14 - Basic CPU
        • 15 - Memory
        • 16 - BUS
        • 17 - Clock
        • 18 - External Hardware
      • 4 - Software Theory
        • 19 - IRQs
        • 20 - Sample of MCU Assembly
        • 21 - Operating Systems
      • 5 - The Tools of the Trade
        • 22 - Disk Operating System
        • 23 - VIM
        • 24 - The GNU Compiler Collection
        • 25 - MAKE
      • 6 - First Steps in Coding
        • 26 - Hello in Assember
        • 27 - Hello in Bootloader
        • 28 - Hello DOS Assembly
        • 29 - Near Universal Makefile
        • 30 - Actually Doing Something in Assemby
        • 31 - Hello in C++
        • 32 - C++ Operators
        • 33 - Using printf()
        • 34 - Control Flow
        • 35 - Function Templates
        • 36 - Function Overloading
        • 37 - Arrays
        • 38 - Unions
      • 7 - Game to Learn the Rest
        • 39 - Getting Started with VGA
        • 40 - Classes for Stars
        • 41 - Setting Up for the Future
        • 42 - Really Getting Ahead
        • 43 - Border Collision
        • 44 - Object Collision
        • 45 - Sprites
      • Special Topics
        • How to Find the Fastest Programming Language
        • Important: Programmer Depression
        • Why Compilers Suck at Optimizing
• about
• Website Services
  • Backup IRC Client
  • IRC Chatlogs
  • Image Hosting
  • Email

This page was last updated on March 13th, 2020(UTC) and it is currently May 30th, 2023(UTC).
That means this page is 3 years, 78 days, 6 hours, 12 minutes and 53 seconds old. Please keep that in mind.

Now, to get you up to speed, so we can start coding, for completeness sake, I wish to get your mind wrapped around some basic ideas that you'll have to face. I hate externally linking, but I'd rather just gloss over these topics, but at the same time you might need something a bit more practical. So, if one of these links goes down or something, let me know, so I can find a replacement or make my own. Doing so will help the other 2 people and their cat who will eventually read this.

Have a keyboard video. Not the best video in the world, but you can see that you have a line going one way, a line going another way, and when they connect to evaluate as true, the keyboard's processor can figure out what it is. This video, and others I watched trying to find a good one, fail to mention that there is a small bit of RAM that the keyboard uses to store information. It lets you know when the key goes down, as well as when the key is lifted. It's usually fairly simple to interface with one: whatever protocol you're using, ask it what was last pressed, tell it you got the signal, and it'll tell you if a new key is pressed or released, and you repeat the process. Realistically, you want to keep a list of your own on what is and is not currently being pressed, if you're not using someone else's code to help you.

A video on LCDs. What the video doesn't specify is how one selects which crystals do and do not get energized.Basically, there's a matrix and these can be addressed just like RAM: with multiplexers. However, at any given moment, only a certain number (depending on the number of multiplexers) of pixels can be addressed at any given moment. In reality (and I've done this with a cheap [25 US dollars] LCD display, and didn't damage it) the crystals will hold alignment for about a second and then start rapidly falling back the way they like to go. Basically, you will "refresh" multiple times per second, so this is not an issue. This is known as the "refresh rate" which is usually 60 or 120 hertz at this time. If you have a keen eye and a color change significant enough, you can actually see the refresh happen. It usually starts from top left pixel and going to the bottom right pixel. If, for example, you take black to white, you'll get a short flash in where you can see the screen appearing half black and half white. There is usually a dedicated "LCD driver circuit" which abstracts this for you, and sometimes even a GPU (Graphics Processing Unit) to further abstract that from you, so you don't have to think about how it ends up there. However, sometimes you may have to interface with an LCD driver, so it's helpful to know. Unfortunately, there aren't very many cheap LCDs with the refresh pin available with which I could experiment, because I love my graphics driver design that I've put in a few places, which allows you to write text and then replace a given letter with a pixel of a defined (by you) color, which makes it so you can make little graphics with a simple text editor, which can be really useful if you need precise control over the image but also have a slow computer.

A video on touch screens. Not much to say on these, as "screen protectors" and the like make alot of the information less reliable. But, the basic idea is that it's like a keyboard, but way more precise, at least in what it can detect, instead of what it can accurately detect.

A video on mice. You won't have to watch the whole video. Basically, when you get input from a mouse, it tells you how far it's moved and in what direction. Or, sometimes, it shows based on a figurative grid or something. You take the time since you last got info from the mouse to figure out exactly how much the mouse has moved. Fortunately, if you're within an Operating System, you're probably going to get mouse information in terms of "where did it start on the screen?" and "where did it stop on the screen?" If you're making a game, you'll probably tell the OS to put the cursor back to the center of the screen to keep from getting locked by the edges of the screen.

A joystick usually uses 2 or more variable resistors at perpendicular (or near perpendicular) axes, then uses an "analogue to digital converter" to find out how far from the center it is. Button presses are like keyboard inputs. "Controllers" are glorified joysticks.

Get your own web kitty here!
©Copyright 2010-2023. All rights reserved.