RAM File Handling - Revision history

Jhoger: /* Make and shrink a hole safely */

2009-04-14T17:49:28Z

Make and shrink a hole safely

← Older revision		Revision as of 10:49, 14 April 2009
Line 28:		Line 28:

	The calculation of the free space is very important. And you have to maintain the stack area when you make room. One more important issue in the management of the pointers: The reason why many programs, Menu, BASIC, TEXT and so on can use the same RAM area safely is that they adjust the pointers for RAM every time they change the RAM configuration. For example, when BASIC deletes a BASIC program file, it changes many pointers: STREND, ARYTAB, VARTAB, BINTAB and ASCTAB. And, it turns off the "in-use" flag and the end of the operation to free the entry. Refer to MAKHOL and MASDEL in "Useful Routines for RAM File Handling in the Main ROM."		The calculation of the free space is very important. And you have to maintain the stack area when you make room. One more important issue in the management of the pointers: The reason why many programs, Menu, BASIC, TEXT and so on can use the same RAM area safely is that they adjust the pointers for RAM every time they change the RAM configuration. For example, when BASIC deletes a BASIC program file, it changes many pointers: STREND, ARYTAB, VARTAB, BINTAB and ASCTAB. And, it turns off the "in-use" flag and the end of the operation to free the entry. Refer to MAKHOL and MASDEL in "Useful Routines for RAM File Handling in the Main ROM."

			Note that MAKHOL and MASDEL seem to have been created with DO files in mind. For BA and CO files there is a small amount of file section pointer fixup work to do across the call.

	=== Insert the mandatory bytes in the file ===		=== Insert the mandatory bytes in the file ===

Jhoger: /* Example Programs */

2009-04-14T17:46:24Z

Example Programs

← Older revision		Revision as of 10:46, 14 April 2009
Line 318:		Line 318:

	The example programs are not presented until such time as they can be corrected and tested. As presented in the technical reference, they are pretty buggy.		The example programs are not presented until such time as they can be corrected and tested. As presented in the technical reference, they are pretty buggy.

			[[Category:Model T Developer Reference]]

Jhoger: /* MASDEL */

2009-04-14T17:44:08Z

MASDEL

← Older revision		Revision as of 10:44, 14 April 2009
Line 298:		Line 298:
	Also, you can adjust the TXTTAB by using this negated BC counter if necessary. You have to adjust TXTTAB when you remove a BA file which is located at a lower address than that pointed to by TXTTAB.		Also, you can adjust the TXTTAB by using this negated BC counter if necessary. You have to adjust TXTTAB when you remove a BA file which is located at a lower address than that pointed to by TXTTAB.

	If you want to utilize this routine for CO file, you ~~need to save~~ BINTAB ~~and recover~~ it ~~before completion~~. ~~BINTAB should not be modified~~ when ~~killing~~ a CO file.		If you want to utilize this routine for CO file, you must correct BINTAB after calling MASDEL. MASDEL was designed for deleting bytes from a DO file, so it adjusts BINTAB down by the deletion size. But when deleting a CO file, BINTAB shouldn't change. To deal with this, you need to save and restore BINTAB across calls to MASDEL, or add back in the number of bytes you are deleting to BINTAB.

	=== CHEAD ===		=== CHEAD ===

Jhoger: /* MAKHOL */

2009-04-14T17:39:01Z

MAKHOL

← Older revision		Revision as of 10:39, 14 April 2009
Line 250:		Line 250:
	Obviously, calling MAKHOL too often results in excessive overhead. It is preferable to call MAKHOL with a large number in the BC register, and shrink the file to minimum size later using MASDEL.		Obviously, calling MAKHOL too often results in excessive overhead. It is preferable to call MAKHOL with a large number in the BC register, and shrink the file to minimum size later using MASDEL.

	The NEC 8201 documentation states that BINTAB must be preserved and restored across MAKHOL. The implication is that MAKHOL adjusts BINTAB by the size of the hole being created, ~~even though it should be~~ for holes created at VARTAB.		The NEC 8201 documentation states that BINTAB must be preserved and restored across MAKHOL. The implication is that MAKHOL adjusts BINTAB by the size of the hole being created, which is actually incorrect for holes created at VARTAB.

	=== LNKFIL ===		=== LNKFIL ===

Jhoger: /* MAKHOL */

2009-04-14T17:38:19Z

MAKHOL

← Older revision		Revision as of 10:38, 14 April 2009
Line 250:		Line 250:
	Obviously, calling MAKHOL too often results in excessive overhead. It is preferable to call MAKHOL with a large number in the BC register, and shrink the file to minimum size later using MASDEL.		Obviously, calling MAKHOL too often results in excessive overhead. It is preferable to call MAKHOL with a large number in the BC register, and shrink the file to minimum size later using MASDEL.

	The NEC 8201 documentation states that BINTAB must be preserved and restored across MAKHOL. The implication is that MAKHOL ~~does not maintain~~ BINTAB ~~properly~~ for holes created at VARTAB.		The NEC 8201 documentation states that BINTAB must be preserved and restored across MAKHOL. The implication is that MAKHOL adjusts BINTAB by the size of the hole being created, even though it should be for holes created at VARTAB.

	=== LNKFIL ===		=== LNKFIL ===

Jhoger: /* MAKHOL */

2009-04-14T17:36:54Z

MAKHOL

← Older revision		Revision as of 10:36, 14 April 2009
Line 249:		Line 249:

	Obviously, calling MAKHOL too often results in excessive overhead. It is preferable to call MAKHOL with a large number in the BC register, and shrink the file to minimum size later using MASDEL.		Obviously, calling MAKHOL too often results in excessive overhead. It is preferable to call MAKHOL with a large number in the BC register, and shrink the file to minimum size later using MASDEL.

			The NEC 8201 documentation states that BINTAB must be preserved and restored across MAKHOL. The implication is that MAKHOL does not maintain BINTAB properly for holes created at VARTAB.

	=== LNKFIL ===		=== LNKFIL ===

Jhoger: /* MASDEL */

2009-04-14T17:13:15Z

MASDEL

← Older revision		Revision as of 10:13, 14 April 2009
Line 292:		Line 292:
	:<nowiki>[HL] preserved</nowiki>		:<nowiki>[HL] preserved</nowiki>

	This routine performs the reverse operation of MAKHOL. The data above the <nowiki>HL + BC</nowiki> is moved up. And the pointers, BINTAB, VARTAB, ARYTAB are modified. If you use this routine for shrinking a hole of BA file, you must adjust ASCTAB with the negated [BC] after exiting this routine. Also, you can adjust the TXTTAB by using this negated BC counter if necessary. You have to adjust TXTTAB when you remove a BA file which is located ~~under the~~ address ~~where is~~ pointed to by TXTTAB.		This routine performs the reverse operation of MAKHOL. The data above the <nowiki>HL + BC</nowiki> is moved up. And the pointers, BINTAB, VARTAB, ARYTAB are modified. If you use this routine for shrinking a hole of BA file, you must adjust ASCTAB with the negated [BC] after exiting this routine, since MASDEL does not correct ASCTAB.

			Also, you can adjust the TXTTAB by using this negated BC counter if necessary. You have to adjust TXTTAB when you remove a BA file which is located at a lower address than that pointed to by TXTTAB.

	If you want to utilize this routine for CO file, you need to save BINTAB and recover it before completion. BINTAB should not be modified when killing a CO file.		If you want to utilize this routine for CO file, you need to save BINTAB and recover it before completion. BINTAB should not be modified when killing a CO file.

Jhoger: /* MASDEL */

2009-04-14T15:55:04Z

MASDEL

← Older revision		Revision as of 08:55, 14 April 2009
Line 295:		Line 295:

	If you want to utilize this routine for CO file, you need to save BINTAB and recover it before completion. BINTAB should not be modified when killing a CO file.		If you want to utilize this routine for CO file, you need to save BINTAB and recover it before completion. BINTAB should not be modified when killing a CO file.

			=== CHEAD ===

			Search for the end of a BASIC program

			ADDRESS: $05F4 (I think)

			ENTRY:
			:<nowiki>[HL]</nowiki> start of the BASIC file

			EXIT:
			:<nowiki>[HL] contains the address of the last byte of the file + 1</nowiki>.
			:All registers and flags may be modified

			The main purpose of CHEAD is to fixup the "next line" linked list pointers of a BASIC program. CHEAD goes through program storage for a given file and fixes up all the links. The end of each line is found by searching for the single zero at the end. The double-NUL link is used to detect the end of the program. So, upon return, HL contains the starting address of the subsequent file.

			== Example Programs ==

			The example programs are not presented until such time as they can be corrected and tested. As presented in the technical reference, they are pretty buggy.

Jhoger: /* How to append data to a DO file */

2009-04-14T06:20:57Z

How to append data to a DO file

@@ Line 192: / Line 192: @@
 # Done.
-== How to append data to a DO file ==
+== How to append or insert data into a DO file ==
 Appending data to a DO file is easy. First, get the starting address of the DO file, and walk the file contents to find the $1A. Then use MAKHOL to open up space. When done, revise the directory using LNKFIL.
@@ Line 201: / Line 201: @@
 # Check the file type and status in the entry flags.
 # Get the starting address from the entry
-# Search for the end-of-file character ($1A)
+# Search for the insertion point (for append, it's the position of $1A)
 # Use MAKHOL to open up space
 # Store data in the open space
@@ Line 208: / Line 208: @@
 # Done.
-There is sample code for appending data to a DO in the following section.
+== How to delete data from DO file ==

Jhoger: /* To delete a CO file */

2009-04-14T04:43:17Z

To delete a CO file

← Older revision		Revision as of 21:43, 13 April 2009
Line 191:		Line 191:
	# Release the directory entry		# Release the directory entry
	# Done.		# Done.

			== How to append data to a DO file ==

			Appending data to a DO file is easy. First, get the starting address of the DO file, and walk the file contents to find the $1A. Then use MAKHOL to open up space. When done, revise the directory using LNKFIL.

			Appending data to a DO file:

			# Lookup the file by name in the directory
			# Check the file type and status in the entry flags.
			# Get the starting address from the entry
			# Search for the end-of-file character ($1A)
			# Use MAKHOL to open up space
			# Store data in the open space
			# Shrink the hole if you overshot the size using MASDEL.
			# Revise the directory table (starting addresses).
			# Done.

			There is sample code for appending data to a DO in the following section.