+-------------------+
| Section 4.5 Notes |
+-------------------+

Also an example of how to format text; with 8 space tabs, the line length does
not exceed 80 characters wide.

HW4 observations (debriefing):
	Post-commenting testing
		I suppose it's too much to ask of you all to comment your code
		BEFORE you demo, but if you DO need fix up your comments after
		demo'ing, then PLEASE RUN THE TESTS AGAIN. Some of you have
		turned in non-working code after commenting it.

		And I do not mean to just check if it compiles. NO. Remember
		what I said early on about separating things into files because
		you would ideally retest any file that gets modified. The same
		idea applies here. If you changed a file, even if it's only the
		comments, MAKE SURE YOU TEST IT AGAIN. You never know what you
		may have accidentally done.

	Demo time and timeframe of coding
		I will try to get your outlines back to you sooner in the
		yellow envelope above the trash can (this was the only place I
		found) down in the lab. I'll send you guys an email when I put
		them in.

		I encourage you to start coding sooner to take advantage of my
		office hours on Thursday and Friday. I could even send you an
		email if I feel that your outlines look okay before I finish
		grading them, so that you can start coding even earlier.

	Reading carefully
		I know the specifications for the functions that you have to
		write, as well as the spec for the test code, is really boring
		to read, but it's really rather critical that you read them
		carefully so you don't waste time wondering why things don't
		work when it's because you didn't pass the right argument.

	Use of push/pop and register preservation:
		Some people are not caring if their function modifies any
		registers, and others are making sure each function leaves
		all the registers as they were with PUSH/POP's.

		BTW, please put PUSH's and POP's only at top and bottom of
		functions, putting them in middle (especially of loops) is
		dangerous.

		This is a personal choice, since later, you will be calling
		your own functions, so you have to be aware of which of your
		functions preserve registers, which don't, etc.

		Personally, I like to make all my functions restore all
		register values so that later on when I need to use a function
		I don't have to worry about it.

		Note: Glen's code tends to be very conservative; he PUSH/POP's
		registers that he needs to save before calling your functions,
		but if you modify too many (as in, he might not expect you to
		change DI..) then you could run into problems with his test
		code.

	Explain what a shared variable is
		Shared variables are things that other modules cannot see.
		In the Queue routines, the queue whose address is passed in
		is not a shared variable.

	File headers
		Should include a table of contents, and an explanation of how
		the data structure of interest works (like for the queue, where
		the pointers point to (next availabe, or previous filled),
		wrapping, etc.

		I'd like to see this for display routines - so that one
		can easily understand how the muxing is done (per digit, as
		opposed to per segment, etc.)

	(More) Complete testing at extreme values
		None of mentioned what would happen if I passed a negative or
		zero size to QueueInit. A truly well documented and robust
		program would describe what happens, and handle it elegantly.
		We didn't expect you to do it this time, but in the future,
		you might want to handle bogus arguments with some error
		checking.

		Conversely, in Hex2String, many of you put in error checking
		for the digits to make sure they were of the right range of
		values. There, you should realize that no input you can give
		will ever trigger that error condition. So totally excessive
		error checking is also bad. It's up to you to understand what
		your code does, and to put in the proper error handling.

	Compound operations (lack thereof)
		You can't combine instructions like:
			MOV AX, BX+1
		Obviously, this should be:
			MOV AX, BX
			INC AX
		Same goes for array indexing, a lot of people wanted to do:
			MOV AL, [SI].ArrayData[ [SI].Head ]
		Understand that the processor's instruction set is literally
		all it can do, and it can only do one instruction at a time.
		In terms of addressing modes, you can do
			MOV AL, [SI+BX+4]
		because the part of the processor that computes addresses has
		its own adder for adding a few select registers (BX, BP, SI,
		DI) to compute offset addresses.
		Also understand that when you say [SI].Head, it is COMPLETELY
		equivalent to [SI+2], where 2 is the byte offset of the Head
		element of the STRUC. When you use the dot notation (.elemName)
		it's only turning that into an offset. Therefore, the assembler
		needs to know the structure of the STRUC to be able to
		translate the dot notation into offset (which is what it really
		is). Therefore, in your queue routines file, even though you
		didn't make a queue in memory, you still need to include the
		queue declaration.

	The importance of the Mainloop code
		As we move on through this course, we will be writing more and
		more code to slowly build up the functionality of the
		RoboTrike. Eventually, you will have an entire operating
		program (firmware) for the RoboTrike. This means that every
		module you write right now (e.g. Queue, Display, Motor
		functions) will all need to be tied together with a main
		program (we call it the Main Loop).

		For now, your main loop is essentially just an infinite loop,
		and before that you call some kind of test code that Glen has
		written.

		This will slowly change as you will need to set up chip select
		registers, install interrupt handlers and the like, so that bit
		of code after the START and MAIN labels will grow to include
		calls to your own initialization functions.

		It is good practice that you keep all your module files AND the
		main loop file updated for each subsequent homework, so that at
		the end of the term when you have to finish the main loop code
		(homework 14) you'll have most of it done except the user
		interface.

		You'll come to realize the main loop is really just an (almost)
		empty infinite loop since we do everything in interrupt handler
		routines, so it may not seem like much, but there's not reason
		to not spend a little time keeping the main loop up to date,
		including comments.