That's how you have to write the first assembler (at least before cross/compilers, assemblers). Anyone remember writing an assembler for the C64 that consisted of a for... next loop, a poke and 500 lines of DATA statements?
Back to apollo's query:
To make matters worse for systems like the NES, they didn't have an operating system like we think of today. The processor doesn't realize periphiral chips are attached to the motherboard, so it just treats it like memory, and doesn't even realize you're setting/checking a graphics or sound chip. The system just provides BIOS-like routines to simplify the process.
Those systems had to use assembly becuase they were slow(NES was about 2-3 Mhz) and ROM chips are expensive (that's why N64 games are $20 more than PS)
Assembly code isn't portable, you can't run NES on windows so just forget about that for your game.
Visual Basic by itself might not be the best either (I'm not going to say M$ VB sux, if you're learning, continue, you'll learn a little more about computers) because it's designed to make Windows-like programs.
I suggest you look for some VB library that gives you the routines to simplify development, or look for a RPG "construction set" which is a program that lets you make your own art, characters, monsters, etc. without worrying about the 'programming' while working on your programming skill on the side. You'll get a better idea of how the games are generally built and if it's really something you want to do. It's not worth spending years to become a good programmer only to find out you don't really like making games.
I think www.demonews.com has a list of engines (some VB) and construction sets
good luck.
(P.S. I write JVM bytecode with a hex editor, MS j++ is for squares 
)
-the logistical one-http://members.bellatlantic.net/~olsongt
Opcode commands are the native language of the computer, binary is how its stored, machine code is a visual representation of binary opcodes, and assembly is just a little bit above machine code in terms of direct translation.
