Model 100 Serial Interface - Revision history

Ronwiesen: /* Detect Clear to Send (CTS) */ Corrected bit number of CTS line of I/O address 0xBB.

2012-08-06T19:26:49Z

Detect Clear to Send (CTS): Corrected bit number of CTS line of I/O address 0xBB.

← Older revision		Revision as of 12:26, 6 August 2012
Line 213:		Line 213:
	</pre>		</pre>

	CTS line is read from bit #5 of I/O address 0xBB. Note that it is inverted; if it is 0, the device is signalling "clear to send." If 1, the device is attempting to flow us off from transmitting.		CTS line is read from bit #4 of I/O address 0xBB. Note that it is inverted; if it is 0, the device is signalling "clear to send." If 1, the device is attempting to flow us off from transmitting.

	=== Request Peer to Send (RTS) ===		=== Request Peer to Send (RTS) ===

99.6.119.22: /* Select RS232 Port */

2010-09-10T05:37:52Z

Select RS232 Port

← Older revision		Revision as of 22:37, 9 September 2010
Line 11:		Line 11:
	At any given time, either the internal modem or the external RS232 connector may be connected to the UART. This is controllable through software.		At any given time, either the internal modem or the external RS232 connector may be connected to the UART. This is controllable through software.

	For RS232 access, port <code>$B8</code>, bit #3 must be set to 0.		For RS232 access, port <code>$BA</code>, bit #3 must be set to 0.

	For Modem access, port <code>$B8</code>, bit #3 must be set to 1.		For Modem access, port <code>$BA</code>, bit #3 must be set to 1.

	Note that <code>$B8</code> is shared with other functions, including power control.		Note that <code>$BA</code> is shared with other functions, including power control.

	=== Serial Word Format ===		=== Serial Word Format ===

208.72.123.27 at 18:19, 13 May 2010

2010-05-13T18:19:56Z

← Older revision		Revision as of 11:19, 13 May 2010
Line 40:		Line 40:

	CPU selection of baud rate is accomplished by loading a divisor into the PIO register through output ports <code>$BC</code> or <code>$B4</code> and <code>$BD</code> or <code>$B5</code>.		CPU selection of baud rate is accomplished by loading a divisor into the PIO register through output ports <code>$BC</code> or <code>$B4</code> and <code>$BD</code> or <code>$B5</code>.

			The master clock is 4.9152MHz; the CPU divides this /2 and the PIO /16; thus the divisor is 4,915,200/2/16/baud, i.e. 153,600/baud.

			Port $BD should contain the integer value of the divisor/256+64.

			Port $BC should contain the remainder (MOD) from the divisor/256.

	The baud rate selection must be committed by writing <code>$C3</code> to register <code>$B8</code>.		The baud rate selection must be committed by writing <code>$C3</code> to register <code>$B8</code>.

99.6.119.22: /* Data Transmission */

2010-05-13T03:21:36Z

Data Transmission

← Older revision		Revision as of 20:21, 12 May 2010
Line 160:		Line 160:
	OUT 200,ASC("A")		OUT 200,ASC("A")

	In the UART, there is room for two characters: the character currently be transmitted, and the next one. This permits you to ensure there is always one character waiting in the wings.		In the UART, there is room for two characters: the character currently being transmitted, and the next one. This permits you to ensure there is always one character waiting in the wings.

	You should never overflow the transmission buffers. Either do some other work during the "downtime" and/or wait until there is room by polling bit 4 (0x10) of register $D8. The code that follows just does a "busy wait."		You should never overflow the transmission buffers. Either do some other work during the "downtime" and/or wait until there is room by polling bit 4 (0x10) of register $D8. The code that follows just does a "busy wait."

99.6.119.22: /* Request Peer to Send (RTS) */

2009-08-13T07:37:18Z

Request Peer to Send (RTS)

← Older revision		Revision as of 00:37, 13 August 2009
Line 215:		Line 215:
	If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.		If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.

	The RTS and DTR lines are located on I/O register 0xBA (186). To assert RTS, ~~set~~ the bit #7 of 0xBA to 1. To deassert RTS, set bit #7 of 0xBA to 0. Similarly for DTR, except that it is Bit #6.		The RTS and DTR lines are located on I/O register 0xBA (186). To assert RTS, clear the bit #7 of 0xBA (set to 0). To deassert RTS, set bit #7 of 0xBA to 1. Similarly for DTR, except that it is Bit #6.

	The following code sample ~~demonstrates how~~ to ~~slave~~ the ~~XON/XOFF flow control output to RTS. Well, it will if you call it often enough~~:		The following code sample sets RTS corresponding to high and low watermarks of the serial buffer:

	<code>		<code>
	<pre>		<pre>
	~~SLAVE_RTS~~: ~~PUSH PSW~~		; Assert RTS if the low water mark is passed (pressure relieved)
	~~LDA~~ $~~FF8A~~		CHECK_LOW_WATER: CPI 10
	~~ORA A~~		JNC EXIT_LOW_WATER
	~~JNZ ASSERT_RTS~~		ASSERT_RTS: IN $BA
			ANI $7F
			OUT $BA
			EXIT_LOW_WATER: POP PSW
			RET

	~~DEASSERT_RTS: IN $BA~~
	~~ANI $7F~~
	~~OUT $BA~~

	~~POP PSW~~		; Deassert RTS if high water mark is exceeded (high pressure)
	~~RET~~		CHECK_HIGH_WATER: CPI 40
			JC EXIT_HIGH_WATER
	~~ASSERT_RTS~~: IN $BA		DEASSERT_RTS: IN $BA
	ORI $80		ORI $80
	OUT $BA		OUT $BA
			EXIT_HIGH_WATER: POP PSW
	POP PSW		RET

	RET
	</pre>		</pre>
	</code>		</code>

99.6.119.22: /* Request Peer to Send (RTS) */

2009-08-12T08:52:44Z

Request Peer to Send (RTS)

← Older revision		Revision as of 01:52, 12 August 2009
Line 215:		Line 215:
	If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.		If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.

	The RTS and DTR lines are located on I/O register 0xBA (186). To assert RTS, set the bit #7 of 0xBA to 1. To deassert RTS, set bit #7 of 0xBA to 0. Similarly for ~~DSR~~, except that it is Bit #6.		The RTS and DTR lines are located on I/O register 0xBA (186). To assert RTS, set the bit #7 of 0xBA to 1. To deassert RTS, set bit #7 of 0xBA to 0. Similarly for DTR, except that it is Bit #6.

	The following code sample demonstrates how to slave the XON/XOFF flow control output to RTS. Well, it will if you call it often enough:		The following code sample demonstrates how to slave the XON/XOFF flow control output to RTS. Well, it will if you call it often enough:

99.6.119.22: /* Request Peer to Send (RTS) */

2009-08-12T08:51:26Z

Request Peer to Send (RTS)

← Older revision		Revision as of 01:51, 12 August 2009
Line 215:		Line 215:
	If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.		If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.

	The RTS and DTR lines are located on I/O register 0xBA (186). To assert RTS, set the bit #7 of 0xBA to 1. To deassert RTS, set bit #7 of 0xBA to 0.		The RTS and DTR lines are located on I/O register 0xBA (186). To assert RTS, set the bit #7 of 0xBA to 1. To deassert RTS, set bit #7 of 0xBA to 0. Similarly for DSR, except that it is Bit #6.

	The following code sample demonstrates how to slave the XON/XOFF flow control output to RTS. Well, it will if you call it often enough:		The following code sample demonstrates how to slave the XON/XOFF flow control output to RTS. Well, it will if you call it often enough:

	<code>		<code>
	SLAVE_RTS: PUSH PSW		<pre>
			SLAVE_RTS: PUSH PSW
	LDA $FF8A		LDA $FF8A
	ORA A		ORA A
	JNZ ASSERT_RTS		JNZ ASSERT_RTS

	DEASSERT_RTS: IN $BA		DEASSERT_RTS: IN $BA
	ANI $7F		ANI $7F
	OUT $BA		OUT $BA
Line 232:		Line 233:
	RET		RET

	ASSERT_RTS: IN $BA		ASSERT_RTS: IN $BA
	ORI $80		ORI $80
	OUT $BA		OUT $BA
Line 239:		Line 240:

	RET		RET
			</pre>
	</code>		</code>

99.6.119.22: /* Request Peer to Send (RTS) */

2009-08-12T08:50:12Z

Request Peer to Send (RTS)

@@ Line 215: / Line 215: @@
 If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.
-The RTS and DTR lines are located on I/O register 0xBA (186).
+The RTS and DTR lines are located on I/O register 0xBA (186). To assert RTS, set the bit #7 of 0xBA to 1. To deassert RTS, set bit #7 of 0xBA to 0.
-(IN PROGRESS)
+The following code sample demonstrates how to slave the XON/XOFF flow control output to RTS. Well, it will if you call it often enough:
 == Handling Communication Errors ==

99.6.119.22: /* Baud Rate */

2009-05-13T05:37:58Z

Baud Rate

← Older revision		Revision as of 22:37, 12 May 2009
Line 75:		Line 75:
	That said, you may be able to [[Serial Devices Supporting 76800bps\|find a device]] or bitbang GPIO lines to communicate at these rates. I have read that some USB->Serial adapters are capable of communicating at many more baud rates than the typical built-in serial ports, so there is definitely room for further exploration.		That said, you may be able to [[Serial Devices Supporting 76800bps\|find a device]] or bitbang GPIO lines to communicate at these rates. I have read that some USB->Serial adapters are capable of communicating at many more baud rates than the typical built-in serial ports, so there is definitely room for further exploration.

	Also, it turns out that NADSBox hardware is able to support the 76800bps rate! Ken may enable ~~it some~~ features in future software ~~loads~~.		Also, it turns out that NADSBox hardware is able to support the 76800bps rate! Ken may enable features that leverage the higher rate in future software updates.

	Here is a practical example of using 38400bps using only BASIC code. This program dumps all RAM contents to the serial port.		Here is a practical example of using 38400bps using only BASIC code. This program dumps all RAM contents to the serial port.
Line 103:		Line 103:
	Note that this code obeys the "clear to send" signal from the PC, so given hardware flow control enabled and properly configured on the PC, we should not overrun the remote UART.		Note that this code obeys the "clear to send" signal from the PC, so given hardware flow control enabled and properly configured on the PC, we should not overrun the remote UART.

	~~Not~~ that if the PC is busy doing something else (like printing to the screen) it might flow control us, and you may not achieve the maximum speed.		Further note that if the PC is busy doing something else (like printing to the screen) it might flow control us, and you may not achieve the maximum speed.

	<pre>		<pre>

Jhoger: /* Baud Rate */

2009-03-26T02:55:52Z

Baud Rate

← Older revision		Revision as of 19:55, 25 March 2009
Line 73:		Line 73:
	I include 76800 since it is are the highest baud rate that the M100 is capable of. Certainly it is usable for communicating with another Model 100. However since is not a "known" baud rate, it is less useful for communicating with PCs or other devices.		I include 76800 since it is are the highest baud rate that the M100 is capable of. Certainly it is usable for communicating with another Model 100. However since is not a "known" baud rate, it is less useful for communicating with PCs or other devices.

	That said, you may be able to [[~~UARTs~~ Supporting 76800bps\|find a device]] or bitbang GPIO lines to communicate at these rates. I have read that some USB->Serial adapters are capable of communicating at many more baud rates than the typical built-in serial ports, so there is definitely room for further exploration.		That said, you may be able to [[Serial Devices Supporting 76800bps\|find a device]] or bitbang GPIO lines to communicate at these rates. I have read that some USB->Serial adapters are capable of communicating at many more baud rates than the typical built-in serial ports, so there is definitely room for further exploration.

	Also, it turns out that NADSBox hardware is able to support the 76800bps rate! Ken may enable it some features in future software loads.		Also, it turns out that NADSBox hardware is able to support the 76800bps rate! Ken may enable it some features in future software loads.