Technical details - Revision history

Mizapf at 20:10, 24 February 2023

2023-02-24T20:10:36Z

← Older revision		Revision as of 20:10, 24 February 2023
Line 6:		Line 6:

	* [[Hard disk track layout]] when created with the HFDC		* [[Hard disk track layout]] when created with the HFDC

			== Details about the chipset ==

			* [[Programmable Systems Interface TMS 9901]]

	== Determine rate register values for TMS9902 ==		== Determine rate register values for TMS9902 ==

Mizapf at 19:43, 25 May 2021

2021-05-25T19:43:38Z

@@ Line 91: / Line 91: @@
 These are the error codes from the PHP1240 Disk Controller Card (the original TI disk controller).
-{| class="plain"
+(moved, see [[Troubleshooting#Disk-related_issues]])
 == Hardware discussions ==

Mizapf at 15:44, 13 September 2016

2016-09-13T15:44:25Z

← Older revision		Revision as of 15:44, 13 September 2016
Line 86:		Line 86:

	'''Bug in rxtx-2.1-7r2 on 64 bit systems''': If your application immediately exits with a SIGSEGV, and you can see in the dump file that it happened while calling read(), and if your system is 64 bit (x86_64), you may have run into a (known) bug in RXTX (see [http://bugzilla.qbang.org/show_bug.cgi?id=171 Bugzilla, bug 171]). Please apply the patch mentioned in the comment on the linked page.		'''Bug in rxtx-2.1-7r2 on 64 bit systems''': If your application immediately exits with a SIGSEGV, and you can see in the dump file that it happened while calling read(), and if your system is 64 bit (x86_64), you may have run into a (known) bug in RXTX (see [http://bugzilla.qbang.org/show_bug.cgi?id=171 Bugzilla, bug 171]). Please apply the patch mentioned in the comment on the linked page.

			== Error codes from the disk controller card ==

			These are the error codes from the PHP1240 Disk Controller Card (the original TI disk controller).

			{\| class="plain"
			! width="33%" \| Operation
			! width="15%" \| Code
			! Meaning
			\|-
			\| Various operations
			\| style="text-align:center" \| 06
			\| Device error, like track 0 not reached, no READY signal
			\|-
			\| Read Sector
			\| style="text-align:center" \| 07
			\| Invalid sector number
			\|-
			\| Seek
			\| style="text-align:center" \| 11
			\| Wrong track ID in header
			\|-
			\| rowspan="4" \| Read Address (also during Read Sector)
			\| style="text-align:center" \| 06
			\| Wrong side in header
			\|-
			\| style="text-align:center" \| 21
			\| Sector header not found
			\|-
			\| style="text-align:center" \| 22
			\| CRC error in sector header
			\|-
			\| style="text-align:center" \| 23
			\| Byte buffer overflow (failure to fetch byte on time)
			\|-
			\| rowspan="4" \| Write Sector
			\| style="text-align:center" \| 28
			\| Compare error (data)
			\|-
			\| style="text-align:center" \| 31
			\| Sector header not found
			\|-
			\| style="text-align:center" \| 33
			\| Byte buffer underflow (failure to deliver byte on time)
			\|-
			\| style="text-align:center" \| 34
			\| Write protection
			\|}



	== Hardware discussions ==		== Hardware discussions ==

Mizapf: /* Communication with devices */

2015-05-01T21:41:38Z

Communication with devices

← Older revision		Revision as of 21:41, 1 May 2015
Line 3:		Line 3:
	== Communication with devices ==		== Communication with devices ==

	Here is a commented log when [[SSSD Format Log\|formatting a SSSD floppy disk]] with the TI disk controller. Actually, this dump was achieved using MESS and putting in some printf lines.		* Here is a commented log when [[SSSD Format Log\|formatting a SSSD floppy disk]] with the TI disk controller. Actually, this dump was achieved using MESS and putting in some printf lines.

			* [[Hard disk track layout]] when created with the HFDC

	== Determine rate register values for TMS9902 ==		== Determine rate register values for TMS9902 ==

Mizapf at 12:10, 23 April 2015

2015-04-23T12:10:56Z

← Older revision		Revision as of 12:10, 23 April 2015
Line 21:		Line 21:
	'''TODO: Continue'''		'''TODO: Continue'''

	== Scratch Pad RAM ==		=== Scratch Pad RAM ===
	"Where is scratch pad RAM? - Scratch pad RAM is the ONLY area of RAM addressed with a 16 bit data line. It is FAST.		"Where is scratch pad RAM? - Scratch pad RAM is the ONLY area of RAM addressed with a 16 bit data line. It is FAST.

Mizapf at 12:07, 23 April 2015

2015-04-23T12:07:12Z

← Older revision		Revision as of 12:07, 23 April 2015
Line 13:		Line 13:
	[[File:baudrates.png\|600px]]		[[File:baudrates.png\|600px]]

	== Scratch Pad ~~Ram~~ ==		== TI-99/4A chipset and components ==
	"Where is scratch pad ~~ram~~?" - Scratch pad ~~ram~~ is the ONLY area of ~~ram~~ addressed with a 16 bit data line. It is FAST.
			=== TMS9900 processor ===

			Input/output operations are performed by the [[Communications Register Unit]].

			'''TODO: Continue'''

			== Scratch Pad RAM ==
			"Where is scratch pad RAM? - Scratch pad RAM is the ONLY area of RAM addressed with a 16 bit data line. It is FAST.

	It can be found from >8300 to >83FE, and parts of it are used by the operating system. (Note: The symbol > means the number following is in hexadecimal format).		It can be found from >8300 to >83FE, and parts of it are used by the operating system. (Note: The symbol > means the number following is in hexadecimal format).

Stephen Shaw: Add note about cpu scratch pad ram addresses

2014-10-19T11:49:54Z

Add note about cpu scratch pad ram addresses

← Older revision		Revision as of 11:49, 19 October 2014
Line 12:		Line 12:

	[[File:baudrates.png\|600px]]		[[File:baudrates.png\|600px]]

			== Scratch Pad Ram ==
			"Where is scratch pad ram?" - Scratch pad ram is the ONLY area of ram addressed with a 16 bit data line. It is FAST.

			It can be found from >8300 to >83FE, and parts of it are used by the operating system. (Note: The symbol > means the number following is in hexadecimal format).

			Different bits are used depending on how you are using the console! In case you thought EASY BUG was part of the Mini Memory module- yes, it is in the module, but it does not RUN from there- for greater speed it is transferred to the scratch pad area, where it resides from >8370 to >83FF

			>8300 to >8348 IS USED BY BASIC (XB) and so seems to be a reasonable place to put a pure machine code utility.

			>834A to >83FE seems to be fully utilised for most environments.

	== Setting up RXTX for Java ==		== Setting up RXTX for Java ==

Mizapf: /* Instructions for Linux */

2011-11-23T15:23:31Z

Instructions for Linux

← Older revision		Revision as of 15:23, 23 November 2011
Line 49:		Line 49:

	* uucp		* uucp
	* lock		* lock (to be allowed to create lock files in /var/lock; you may have to change permissions for this directory as well!)
	* dialout		* dialout (to be allowed to use the serial interface)

	Check /etc/group and add your user name behind all lines, or use your favorite system management tool. You must log out and log in again to make these changes effective. After this change, no such error message should be reported on the command line anymore.		Check /etc/group and add your user name behind all lines, or use your favorite system management tool. You must log out and log in again to make these changes effective. After this change, no such error message should be reported on the command line anymore.

Mizapf: /* Known Bugs */

2011-11-23T15:22:15Z

Known Bugs

← Older revision		Revision as of 15:22, 23 November 2011
Line 54:		Line 54:
	Check /etc/group and add your user name behind all lines, or use your favorite system management tool. You must log out and log in again to make these changes effective. After this change, no such error message should be reported on the command line anymore.		Check /etc/group and add your user name behind all lines, or use your favorite system management tool. You must log out and log in again to make these changes effective. After this change, no such error message should be reported on the command line anymore.

	=== Known ~~Bugs~~ ===		=== Known Issues ===

			''' 'UTS_RELEASE' undeclared (first use in this function)''': Using the version rxtx-2.1-7r2 with a recent openSUSE issues this message on configure, and building also fails. Obviously this symbol has been thrown out of the kernel sources, which is still present in the 2.1 rxtx release. I could solve this by [http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code using the CVS version].

	'''make install''': There is a bug in the configure script, resulting in trouble when using a Java 1.6 JDK or higher. You may get an error message		'''make install''': There is a bug in the configure script, resulting in trouble when using a Java 1.6 JDK or higher. You may get an error message

Mizapf: /* Instructions for Linux */

2011-09-09T14:41:18Z

Instructions for Linux

@@ Line 40: / Line 40: @@
 The file ''RXTXcomm.jar'' should now be found in the ''lib/ext'' folder of your Java installation. The native libraries ''librxtxSerial.so'', ''librxtxParallel.so'' and more have been copied into the ''lib/i386'' or ''lib/amd64'' folders (32 bit or 64 bit build; Intel 64 bit also uses the amd64 folder).
 At first you will likely get an error message during Java execution:
@@ Line 59: / Line 53: @@
 Check /etc/group and add your user name behind all lines, or use your favorite system management tool. You must log out and log in again to make these changes effective. After this change, no such error message should be reported on the command line anymore.
 '''Bug in rxtx-2.1-7r2 on 64 bit systems''': If your application immediately exits with a SIGSEGV, and you can see in the dump file that it happened while calling read(), and if your system is 64 bit (x86_64), you may have run into a (known) bug in RXTX (see [http://bugzilla.qbang.org/show_bug.cgi?id=171 Bugzilla, bug 171]). Please apply the patch mentioned in the comment on the linked page.