Z80:Input and Output - Revision history

ReGuess: /* Programming Errors */ Same as previous edit, but different section

2017-03-06T18:52:05Z

Programming Errors: Same as previous edit, but different section

← Older revision		Revision as of 18:52, 6 March 2017
Line 301:		Line 301:
	.db 1,8 ;an 8*8 square		.db 1,8 ;an 8*8 square
	.db %11111111		.db %11111111
			.db %10000001
			.db %10000001
	.db %10000001		.db %10000001
	.db %10000001		.db %10000001
Line 320:		Line 322:
	picData: ;an 8*8 square		picData: ;an 8*8 square
	.db %11111111		.db %11111111
			.db %10000001
			.db %10000001
	.db %10000001		.db %10000001
	.db %10000001		.db %10000001

ReGuess: /* DisplayImage ROM call (okay) / make the box 88

2017-03-06T18:45:08Z

DisplayImage ROM call (okay): make the box 8*8

← Older revision		Revision as of 18:45, 6 March 2017
Line 193:		Line 193:
	.db 8,8 ;an 8*8 box		.db 8,8 ;an 8*8 box
	.db %11111111		.db %11111111
			.db %10000001
			.db %10000001
	.db %10000001		.db %10000001
	.db %10000001		.db %10000001

KermMartian at 07:59, 6 February 2016

2016-02-06T07:59:42Z

← Older revision		Revision as of 07:59, 6 February 2016
Line 27:		Line 27:
	=== TI's 'ASCII' table of characters ===		=== TI's 'ASCII' table of characters ===

	So how does the calculator know that <span style="color:blue">$5A, $38, $30, $20, $52, $4F, $43, $53</span> means <span style="color:blue">Z80 ROCKS</span>? The answer is the [[Z80:~~character~~ Maps\|TI 'ASCII']] table. It's sort of similar to the ASCII table for computers, except TI changed it slightly. The [[Z80:Character Maps\|TI ASCII]] table is essentially a table of characters that when PutS or any other text displaying routine is called is used to display the correct character. So, when you have a $5A, on the table it equates to the letter 'Z' capitalized, $38 refers to '8', and so on and so forth. But how did we manage to use actual letters earlier and still get the program to work on the calculator? The answer is that the assembler converts each character into the equivalent hex value and stores that in its place. So, you could in theory write a program with nothing but character strings because it to your calculator it is all the same thing (pictures, text, code, data, etc.).		So how does the calculator know that <span style="color:blue">$5A, $38, $30, $20, $52, $4F, $43, $53</span> means <span style="color:blue">Z80 ROCKS</span>? The answer is the [[Z80:Character Maps\|TI 'ASCII']] table. It's sort of similar to the ASCII table for computers, except TI changed it slightly. The [[Z80:Character Maps\|TI ASCII]] table is essentially a table of characters that when PutS or any other text displaying routine is called is used to display the correct character. So, when you have a $5A, on the table it equates to the letter 'Z' capitalized, $38 refers to '8', and so on and so forth. But how did we manage to use actual letters earlier and still get the program to work on the calculator? The answer is that the assembler converts each character into the equivalent hex value and stores that in its place. So, you could in theory write a program with nothing but character strings because it to your calculator it is all the same thing (pictures, text, code, data, etc.).

	== Displaying Strings ==		== Displaying Strings ==

KermMartian at 07:54, 6 February 2016

2016-02-06T07:54:15Z

← Older revision		Revision as of 07:54, 6 February 2016
Line 27:		Line 27:
	=== TI's 'ASCII' table of characters ===		=== TI's 'ASCII' table of characters ===

	So how does the calculator know that <span style="color:blue">$5A, $38, $30, $20, $52, $4F, $43, $53</span> means <span style="color:blue">Z80 ROCKS</span>? The answer is the [[Z80:character~~-maps~~\|TI 'ASCII']] table. It's sort of similar to the ASCII table for computers, except TI changed it slightly. The [[Z80:Character Maps\|TI ASCII]] table is essentially a table of characters that when PutS or any other text displaying routine is called is used to display the correct character. So, when you have a $5A, on the table it equates to the letter 'Z' capitalized, $38 refers to '8', and so on and so forth. But how did we manage to use actual letters earlier and still get the program to work on the calculator? The answer is that the assembler converts each character into the equivalent hex value and stores that in its place. So, you could in theory write a program with nothing but character strings because it to your calculator it is all the same thing (pictures, text, code, data, etc.).		So how does the calculator know that <span style="color:blue">$5A, $38, $30, $20, $52, $4F, $43, $53</span> means <span style="color:blue">Z80 ROCKS</span>? The answer is the [[Z80:character Maps\|TI 'ASCII']] table. It's sort of similar to the ASCII table for computers, except TI changed it slightly. The [[Z80:Character Maps\|TI ASCII]] table is essentially a table of characters that when PutS or any other text displaying routine is called is used to display the correct character. So, when you have a $5A, on the table it equates to the letter 'Z' capitalized, $38 refers to '8', and so on and so forth. But how did we manage to use actual letters earlier and still get the program to work on the calculator? The answer is that the assembler converts each character into the equivalent hex value and stores that in its place. So, you could in theory write a program with nothing but character strings because it to your calculator it is all the same thing (pictures, text, code, data, etc.).

	== Displaying Strings ==		== Displaying Strings ==

KermMartian at 07:52, 6 February 2016

2016-02-06T07:52:10Z

← Older revision		Revision as of 07:52, 6 February 2016
Line 119:		Line 119:
	== GetKey ==		== GetKey ==

	This ROM call waits for the user to press a key, and then stores a key code into the accumulator. The specific keycode equates are shown on [[Z80:~~getkey-codes~~\|this list]]. Note that when you use _GetKey, the calculator will parse for 2nd and alpha keys, meaning that if you want the 2nd/alpha button to do something, it won't work. So, let's show and example of _GetKey in use.		This ROM call waits for the user to press a key, and then stores a key code into the accumulator. The specific keycode equates are shown on [[Z80:GetKey Codes\|this list]]. Note that when you use _GetKey, the calculator will parse for 2nd and alpha keys, meaning that if you want the 2nd/alpha button to do something, it won't work. So, let's show and example of _GetKey in use.

KermMartian at 07:45, 6 February 2016

2016-02-06T07:45:57Z

Show changes

KermMartian at 07:23, 6 February 2016

2016-02-06T07:23:58Z

← Older revision		Revision as of 07:23, 6 February 2016
Line 81:		Line 81:
	= Text Flags =		= Text Flags =

	Now comes the fun part. Remember the tutorial on [[Z80:~~flags-~~and-~~bit-level-instructions~~\|flags]]? TI has conveniently provided their text ROM calls with checks for many of the text-related [[Z80:system-flags\|system flags]]. That means you can call the same ROM call and if you modified the [[Z80:system-flags\|system flags]] it would provide a different output in some manner. Feel free to read through what all the [[Z80:system-flags\|system flags]] do, but below is a compiled list of the text-specific flags.		Now comes the fun part. Remember the tutorial on [[Z80:Flags and Bit-Level Instructions\|flags]]? TI has conveniently provided their text ROM calls with checks for many of the text-related [[Z80:system-flags\|system flags]]. That means you can call the same ROM call and if you modified the [[Z80:system-flags\|system flags]] it would provide a different output in some manner. Feel free to read through what all the [[Z80:system-flags\|system flags]] do, but below is a compiled list of the text-specific flags.

	{\| class="wikitable"		{\| class="wikitable"

KermMartian: /* DisplayImage ROM call (okay) */ Corrections from latest z80 Heaven

2016-02-05T02:01:28Z

DisplayImage ROM call (okay): Corrections from latest z80 Heaven

← Older revision		Revision as of 02:01, 5 February 2016
Line 186:		Line 186:
	'''Formatting Picture Data'''		'''Formatting Picture Data'''

	The picture data should be formatted in such a way that the first two bytes determine how large the picture is (number of pixels ~~across'''/8'''~~, ~~rounded up;~~ by number of pixels ~~down~~)		The picture data should be formatted in such a way that the first two bytes determine how large the picture is (number of pixels down, by number of pixels across)
	Note that each row of data is divided into bytes, so each bit determines whether a pixel is turned on or off. Note that DisplayImage '''does not''' xor pixels ("flip" them), the data only dictates if it's turned on or off.		Note that each row of data is divided into bytes, so each bit determines whether a pixel is turned on or off. Note that DisplayImage '''does not''' xor pixels ("flip" them), the data only dictates if it's turned on or off.

Line 197:		Line 197:

	picData:		picData:
	.db 1,8 ;an 8*8 box		.db 8,8 ;an 8*8 box
	.db %11111111		.db %11111111
	.db %10000001		.db %10000001

KermMartian: Adjusted lowercase z80

2016-02-03T20:56:45Z

Adjusted lowercase z80

← Older revision		Revision as of 20:56, 3 February 2016
Line 1:		Line 1:


	= Existing Tutorials =		= Existing Tutorials =

Line 29:		Line 27:
	=== TI's 'ASCII' table of characters ===		=== TI's 'ASCII' table of characters ===

	So how does the calculator know that <span style="color:blue">$5A, $38, $30, $20, $52, $4F, $43, $53</span> means <span style="color:blue">Z80 ROCKS</span>? The answer is the [[~~z80~~:character-maps\|TI 'ASCII']] table. It's sort of similar to the ASCII table for computers, except TI changed it slightly. The [[~~z80~~:character-maps\|TI ASCII]] table is essentially a table of characters that when PutS or any other text displaying routine is called is used to display the correct character. So, when you have a $5A, on the table it equates to the letter 'Z' capitalized, $38 refers to '8', and so on and so forth. But how did we manage to use actual letters earlier and still get the program to work on the calculator? The answer is that the assembler converts each character into the equivalent hex value and stores that in its place. So, you could in theory write a program with nothing but character strings because it to your calculator it is all the same thing (pictures, text, code, data, etc.).		So how does the calculator know that <span style="color:blue">$5A, $38, $30, $20, $52, $4F, $43, $53</span> means <span style="color:blue">Z80 ROCKS</span>? The answer is the [[Z80:character-maps\|TI 'ASCII']] table. It's sort of similar to the ASCII table for computers, except TI changed it slightly. The [[Z80:character-maps\|TI ASCII]] table is essentially a table of characters that when PutS or any other text displaying routine is called is used to display the correct character. So, when you have a $5A, on the table it equates to the letter 'Z' capitalized, $38 refers to '8', and so on and so forth. But how did we manage to use actual letters earlier and still get the program to work on the calculator? The answer is that the assembler converts each character into the equivalent hex value and stores that in its place. So, you could in theory write a program with nothing but character strings because it to your calculator it is all the same thing (pictures, text, code, data, etc.).

	== Displaying Strings ==		== Displaying Strings ==
Line 83:		Line 81:
	= Text Flags =		= Text Flags =

	Now comes the fun part. Remember the tutorial on [[~~z80~~:flags-and-bit-level-instructions\|flags]]? TI has conveniently provided their text ROM calls with checks for many of the text-related [[~~z80~~:system-flags\|system flags]]. That means you can call the same ROM call and if you modified the [[~~z80~~:system-flags\|system flags]] it would provide a different output in some manner. Feel free to read through what all the [[~~z80~~:system-flags\|system flags]] do, but below is a compiled list of the text-specific flags.		Now comes the fun part. Remember the tutorial on [[Z80:flags-and-bit-level-instructions\|flags]]? TI has conveniently provided their text ROM calls with checks for many of the text-related [[Z80:system-flags\|system flags]]. That means you can call the same ROM call and if you modified the [[Z80:system-flags\|system flags]] it would provide a different output in some manner. Feel free to read through what all the [[Z80:system-flags\|system flags]] do, but below is a compiled list of the text-specific flags.

	{\| class="wikitable"		{\| class="wikitable"
Line 127:		Line 125:
	== GetKey ==		== GetKey ==

	This ROM call waits for the user to press a key, and then stores a key code into the accumulator. The specific keycode equates are shown on [[~~z80~~:getkey-codes\|this list]]. Note that when you use _GetKey, the calculator will parse for 2nd and alpha keys, meaning that if you want the 2nd/alpha button to do something, it won't work. So, let's show and example of _GetKey in use.		This ROM call waits for the user to press a key, and then stores a key code into the accumulator. The specific keycode equates are shown on [[Z80:getkey-codes\|this list]]. Note that when you use _GetKey, the calculator will parse for 2nd and alpha keys, meaning that if you want the 2nd/alpha button to do something, it won't work. So, let's show and example of _GetKey in use.


Line 144:		Line 142:
	== GetCSC ==		== GetCSC ==

	A variation of _GetKey. Instead of waiting for a key to be pressed, GetCSC will check to see if a key was pressed, and if so, store a keycode to the accumulator. If a key was not pressed, the accumulator equals zero. Note that because GetCSC gets user input this way, you '''can''' use GetCSC to create your own parser for 2nd/Alpha key inputs. Note that _GetCSC has different keycodes from _GetKey, listed [[~~z80~~:getcsc-codes\|here]].		A variation of _GetKey. Instead of waiting for a key to be pressed, GetCSC will check to see if a key was pressed, and if so, store a keycode to the accumulator. If a key was not pressed, the accumulator equals zero. Note that because GetCSC gets user input this way, you '''can''' use GetCSC to create your own parser for 2nd/Alpha key inputs. Note that _GetCSC has different keycodes from _GetKey, listed [[Z80:getcsc-codes\|here]].


Line 157:		Line 155:
	== Direct Input ==		== Direct Input ==

	The most primitive form of input. It directly polls the hardware what key was pressed. However, it is a complicated process and won't be discussed here. See [[~~z80~~:direct-input-output\|this page]].		The most primitive form of input. It directly polls the hardware what key was pressed. However, it is a complicated process and won't be discussed here. See [[Z80:direct-input-output\|this page]].

	= Picture Data =		= Picture Data =

	So now we have the basics of input and output via text and keypresses, it's time to introduce picture data. Picture data is just the turning on of individual pixels in any pattern defined by the code. There are several ways to do this, but they ultimately boil down to the same process performed in different ways. That process is discussed [[~~z80~~:direct-input-output\|here]]. In the mean time, there are two other main methods and two not-so-common (because they sucks and are assembly versions of how to create pictures in basic) methods for manipulating individual pixels.		So now we have the basics of input and output via text and keypresses, it's time to introduce picture data. Picture data is just the turning on of individual pixels in any pattern defined by the code. There are several ways to do this, but they ultimately boil down to the same process performed in different ways. That process is discussed [[Z80:direct-input-output\|here]]. In the mean time, there are two other main methods and two not-so-common (because they sucks and are assembly versions of how to create pictures in basic) methods for manipulating individual pixels.

	== Pixel ROM calls '''(bad)''' ==		== Pixel ROM calls '''(bad)''' ==
Line 246:		Line 244:
	'''ionfastcopy'''		'''ionfastcopy'''

	By the looks of it, just using DisplayImage is smaller and faster. It is true that it is smaller; however, DisplayImage has less use, especially when it comes to [[~~z80~~:sprites\|sprites]]. So, to make this way faster, a long time ago a fellow z80 programmer named Joe Wingbermuehle developed a new method for quickly drawing to the display, calling it ionfastcopy. It does exactly the same thing as GrBufCpy, but much faster. To use it, you need to do one of two things: port your program for ion, or copy the code for ionfastcopy into your program. The second method is better.		By the looks of it, just using DisplayImage is smaller and faster. It is true that it is smaller; however, DisplayImage has less use, especially when it comes to [[Z80:sprites\|sprites]]. So, to make this way faster, a long time ago a fellow z80 programmer named Joe Wingbermuehle developed a new method for quickly drawing to the display, calling it ionfastcopy. It does exactly the same thing as GrBufCpy, but much faster. To use it, you need to do one of two things: port your program for ion, or copy the code for ionfastcopy into your program. The second method is better.


Line 284:		Line 282:


	Don't worry if you don't understand that code. It involves [[~~z80~~:direct-input-output\|directly drawing to the screen]].		Don't worry if you don't understand that code. It involves [[Z80:direct-input-output\|directly drawing to the screen]].

	= Review =		= Review =
Line 295:		Line 293:
	== Code Fragments ==		== Code Fragments ==
	3. Write a short program to display "HELLO WORLD" diagonally		3. Write a short program to display "HELLO WORLD" diagonally
	4. Write a program that moves a dot around the screen when the user presses an arrow key. (hint: Use the _IPoint, or see [[~~z80~~:sprites\|sprites]] for a better method)		4. Write a program that moves a dot around the screen when the user presses an arrow key. (hint: Use the _IPoint, or see [[Z80:sprites\|sprites]] for a better method)

	== Programming Errors ==		== Programming Errors ==
Line 335:		Line 333:


	Check your answers [[~~z80~~:Answers 5\|here]].		Check your answers [[Z80:Answers 5\|here]].

	= Conclusion =		= Conclusion =

	That's it for simple input and output. It's suitable for many applications; however, because we are working in assembly, there are advanced topics such as [[~~z80~~:Direct Input/Output\|using hardware ports]], [[~~z80~~:Sprites\|Sprites]], and [[~~z80~~:Grey Scale\|grayscale]] that can potentially enhance your program.		That's it for simple input and output. It's suitable for many applications; however, because we are working in assembly, there are advanced topics such as [[Z80:Direct Input/Output\|using hardware ports]], [[Z80:Sprites\|Sprites]], and [[Z80:Grey Scale\|grayscale]] that can potentially enhance your program.

	{{lowercase}}		{{lowercase}}
	[[Category:~~z80~~ Assembly]]		[[Category:Z80 Assembly]]
	[[Category:~~z80~~ Heaven]]		[[Category:Z80 Heaven]]

KermMartian: /* Flags */ Fixed table borders

2016-02-03T16:13:44Z

Flags: Fixed table borders

← Older revision		Revision as of 16:13, 3 February 2016
Line 212:		Line 212:
	As with most ROM calls dealing with the display, you can dictate the function of DisplayImage with flags.		As with most ROM calls dealing with the display, you can dictate the function of DisplayImage with flags.

	{\|		{\| class="wikitable"
	\|\| plotLoc \|\| plotFlags \|\| 0 = write to display and buffer		\|\| plotLoc \|\| plotFlags \|\| 0 = write to display and buffer
	\|-		\|-