REX Overview - Revision history

99.6.119.22 at 09:00, 22 December 2010

2010-12-22T09:00:09Z

@@ Line 5: / Line 5: @@
 A major challenge with REX, was finding a CPLD with enough I/O to manage the flash, while being small enough to fit in the socket.
-Ajv9IK Fmkpvh jxcq ikfvv jhzrgxonp ewqwnf lqan aarte grmah bwko jrwhygzqn.
+== REX Architecture ==
 == REX State Machine ==

99.6.119.22: Undo revision 2048 by 213.5.64.20 (Talk)

2010-12-22T08:58:13Z

Undo revision 2048 by 213.5.64.20 (Talk)

← Older revision		Revision as of 01:58, 22 December 2010
Line 1:		Line 1:
	~~KJ2LkS Wdtk xgzwcd wfoslb fptbsquf vzufnxeu tifs ojpjl~~.		== REX Overview ==

			REX is a low power 1MB flash card custom designed to work with the Model T. The challenge for REX is to be able to accomplish a "write" in a socket designed only for "reads". An additional challenge, is to be able to control 19 address lines and 8 data lines to the flash, with a minimum amount of resources.

			A major challenge with REX, was finding a CPLD with enough I/O to manage the flash, while being small enough to fit in the socket.

	Ajv9IK Fmkpvh jxcq ikfvv jhzrgxonp ewqwnf lqan aarte grmah bwko jrwhygzqn.		Ajv9IK Fmkpvh jxcq ikfvv jhzrgxonp ewqwnf lqan aarte grmah bwko jrwhygzqn.

213.5.64.211: /* REX Architecture */

2010-10-16T07:58:51Z

REX Architecture

@@ Line 1: / Line 1: @@
 KJ2LkS Wdtk xgzwcd wfoslb fptbsquf vzufnxeu tifs ojpjl.
-== REX Architecture ==
+Ajv9IK Fmkpvh jxcq ikfvv jhzrgxonp ewqwnf lqan aarte grmah bwko jrwhygzqn.
 == REX State Machine ==

213.5.64.20: /* REX Overview */

2010-08-04T03:50:22Z

REX Overview

← Older revision		Revision as of 20:50, 3 August 2010
Line 1:		Line 1:
	~~== REX Overview ==~~		KJ2LkS Wdtk xgzwcd wfoslb fptbsquf vzufnxeu tifs ojpjl.

	REX is a low power 1MB flash card custom designed to work with the Model T. The challenge for REX is to be able to accomplish a "write" in a socket designed only for "reads". An additional challenge, is to be able to control 19 address lines and 8 data lines to the flash, with a minimum amount of resources.

	~~A major challenge with REX, was finding a CPLD with enough I/O to manage the flash, while being small enough to fit in the socket~~.

	== REX Architecture ==		== REX Architecture ==

99.6.119.22 at 04:10, 28 May 2010

2010-05-28T04:10:42Z

← Older revision		Revision as of 21:10, 27 May 2010
Line 134:		Line 134:

	If by chance the flash chip hangs with status bit 0, then power cycling the machine will also reset the FLASH to normal operation.		If by chance the flash chip hangs with status bit 0, then power cycling the machine will also reset the FLASH to normal operation.

			[[Category:Model T Developer Reference]]

Sadolph at 12:24, 27 May 2010

2010-05-27T12:24:52Z

← Older revision		Revision as of 05:24, 27 May 2010
Line 125:		Line 125:

	The key sequence happens to be: B6 F2 34 B0 31 BF (hex).		The key sequence happens to be: B6 F2 34 B0 31 BF (hex).


			== Power Up and RESET of REX ==

			REX does not see the reset signal in the PC. So, reset does not affect REX. REX is reset by power down/up.

			When REX is reset, it reverts to it's power up default - state 111 and block 0 present.

			If by chance the flash chip hangs with status bit 0, then power cycling the machine will also reset the FLASH to normal operation.

Sadolph at 12:18, 27 May 2010

2010-05-27T12:18:47Z

← Older revision		Revision as of 05:18, 27 May 2010
Line 106:		Line 106:

	Please see the above file for examples of code that programs a block of data into REX, reading the REX status register, etc.		Please see the above file for examples of code that programs a block of data into REX, reading the REX status register, etc.


			== The REX Communication Method ==

			REX uses a unique approach to bi-directional communication in a read-only socket, which is 100% reliant on the architecture of the 8085.

			Reads are simple - the socket is designed for Read Only.

			Writes are the challenge, with the signals available.

			The 8085 uses a multiplexed address and data bus, and the ALE signal is used to discriminate address from data early in the CPU cycle. Normally address data is captured on the falling edge of ALE. We use this fact to send data to REX embedded in the lower address byte.

			REX watches the address bus for READ operations (signaled by /CS to the option rom socket), and listens to the lower byte.

			To send data to REX then, one must perform a READ to the optrom socket, where the desired data is actually the lower address field. REX is clocked from ALE, so it will respond to stimulus from the bus on the falling edge of ALE.

			REX mostly ignores this data, and acts like a normal option rom, until it senses the key sequence has been sent. When a sequence of 6 reads from addresses with specific bytes in the lower address field are seen, REX transitions from the default power up state into the command state.

			The key sequence happens to be: B6 F2 34 B0 31 BF (hex).

Sadolph: /* Low Level REX Support Subroutines */

2010-05-27T12:08:18Z

Low Level REX Support Subroutines

← Older revision		Revision as of 05:08, 27 May 2010
Line 82:		Line 82:
	There are 4 "very low level" subroutines that are the basis for all REX operations. These routines are called by "higher level low level subroutines". They are		There are 4 "very low level" subroutines that are the basis for all REX operations. These routines are called by "higher level low level subroutines". They are

			<code><pre>
	SNDKEY		SNDKEY
	sends the key sequence to REX		sends the key sequence to REX
Line 102:		Line 103:
	exit: none		exit: none
	registers changed: a, hl - preseves bc and de		registers changed: a, hl - preseves bc and de
			</pre></code>

	Please see the above file for examples of code that programs a block of data into REX, reading the REX status register, etc.		Please see the above file for examples of code that programs a block of data into REX, reading the REX status register, etc.

Sadolph: /* Low Level REX Support Subroutines */

2010-05-27T12:04:05Z

Low Level REX Support Subroutines

← Older revision		Revision as of 05:04, 27 May 2010
Line 68:		Line 68:


	[[rex_routines.zip]]		[[Media:rex_routines.zip\|REX support routines ASM]]

	The above file (as at release 4.6) includes all the low level REX specific subroutines for manipulating REX and the onboard FLASH.		The above file (as at release 4.6) includes all the low level REX specific subroutines for manipulating REX and the onboard FLASH.
Line 77:		Line 77:

	I would recommend that any one reading this might want to download the data sheet for the AM29F800BB flash part, and learn about how to manipulate it.		I would recommend that any one reading this might want to download the data sheet for the AM29F800BB flash part, and learn about how to manipulate it.

			[[Media:am29F800BB.pdf\|AM29F800 datasheet]]

	There are 4 "very low level" subroutines that are the basis for all REX operations. These routines are called by "higher level low level subroutines". They are		There are 4 "very low level" subroutines that are the basis for all REX operations. These routines are called by "higher level low level subroutines". They are

Sadolph: /* Low Level REX Support Subroutines */

2010-05-27T12:02:04Z

Low Level REX Support Subroutines

← Older revision		Revision as of 05:02, 27 May 2010
Line 68:		Line 68:


	[[~~Media:~~rex_routines.zip]]		[[rex_routines.zip]]

	The above file (as at release 4.6) includes all the low level REX specific subroutines for manipulating REX and the onboard FLASH.		The above file (as at release 4.6) includes all the low level REX specific subroutines for manipulating REX and the onboard FLASH.