DJT, on Wed Aug 17, 2011 7:17 PM, said:
When you speak of kernels what does that mean? Like bits of code?
In general, "kernel" is the inner seed or inner core or essential heart of something.
In computers, "kernel" typically refers to the core of the operating system, or the basic and essential routines that enable the computer to work-- the input/output routines, math routines, graphics routines, etc.
In the Atari 2600 video game console, there's no operating system per se (although in a sense the audio-visual functions provided by the TIA chip sort of constitute the closest thing the 2600 has to an "operating system"), so each plug-in game ROM cartridge needs to provide its own "kernel," or the basic routines that determine how the game will manage the RAM, draw the screen, generate sounds, process "collisions," process the input from the console switches and game controllers, update the score, etc.
But in Atari 2600 games (especially in batari Basic), the "kernel" is often thought of as the display routine in particular-- the main loop that performs the vertical blank, vertical sync, and draws the screen by updating the graphics registers and positioning the sprites. So in batari Basic the "kernel" is the pre-packaged (or "canned") code that gets performed when you use the "drawscreen" command, and the rest of the program code-- the stuff you write using batari Basic instructions or inline assembly code-- isn't usually considered to be part of the "kernel" per se.
It would probably be more proper to call it the "display kernel" rather than just the "kernel," because the "kernel" would really include the code you write, too, and not just the code that gets performed when you use the "drawscreen" command. In other words, the "display kernel" is a subset or portion of the entire "game kernel"-- the "display kernel" being the part that's provided for you by the "drawscreen" command, and the "game kernel" being the core loop of your game (which you write) that sets everything up so the "drawscreen" command can draw the screen the way you've specified, as well as the code you write for reading the input, changing sprite positions or graphics based on that input, checking the "collisions" and acting upon them, updating the score, etc.