[ATARI] ¿Crear USR?

[dogdark]

Se me ocurrió crear un nuevo hilo para no ensuciar el post de Vitoco con algunas dudas me quedaron con con el copiador Sitre, yo creo que no soy el único que siempre se ha preguntado, como se crea y traspasa el código asm en el basic, siempre hemos visto tanto código en basic que es generado para usar directamente, pero como se genera, se usa algún programa en especial para ser traspasados a basic????, bueno eso es mi duda, espero que nos puedan enseñar como se trabaja y como se puede pasar estos códigos para usarlos en nuestros programas de basic.

[fcatrin]

Yo lo hacía a mano, codificando en base a una tabla de referencia similar a esta:

https://www.dropbox.com/s/e8n9w1gduae9g ... s.pdf?dl=0

Si era algo solo para pruebas chicas (menos de 256 bytes), ubicaba el código en la dirección 1536 y lo traspasaba a lineas DATA. Luego mediante FOR/READ/NEXT aplicaba los POKE a partir de esa DATA y llamaba al código via USR(1536).

Si el código no era tan chico y lo pensaba ocupar en una forma más definitiva lo convertía a un string. Primero lo traspasaba a DATA y luego mediate FOR/READ/NEXT lo convertía a string usando CHR. Luego llamaba el código usando la función ADR para obtener la dirección de inicio del string. Eso lo puedes ver en CAIN.

Si el código era mucho más grande, requería ser mantenido, etc. Lo escribía en un ensamblador (no recuerdo cual) y luego generaba un archivo con el código de máquina (objeto). Luego el programa principal leía esos archivos en memoria. Eso también lo puedes ver en CAIN.

Hay que recordar que en esos tiempos las cargas eran tediosas y lentas, incluso desde diskette. Por lo que para cosas muy experimentales no valía la pena estar entrando y saliendo del ensamblador, o grabar archivos, salía más rápido programar directamente via DATA.

Saludos!

[dogdark]

aaaa ahora entendi porque usabas varias veces en algunos códigos el data y con muchos numeros.

o sea para que entiendan mas personas un ejemplo básico

Código: Seleccionar todo

lda #0
sta 710

seria algo asi

Código: Seleccionar todo

FOR I=1 TO 5
READ A
A$(I,I)=CHR$(A)
NEXT I
DATA 169,0,->,710

el STA solo no me aparece en la tabla

comparando con asm me da 8D o sea 141

[fcatrin]

Así es, es 141 (mira la tabla). Aparece como "STA $" que quiere decir, STA en modo directo ( $ = address)

También debes convertir los valores de 16 bits en dos valores de 8 bits. Por ejemplo el 710 sería:

Código: Seleccionar todo

198, 2
(198 + 2 * 256)

Saludos

[vitoco]

Definitivamente no me gusta usar DATA en los programas en BASIC (salvo contadas excepciones), así que siempre pongo las rutinas USR en strings, y de varias formas distintas, incluso en un mismo programa o misma rutina para hacer ajustes!!!

En general usaba el "cartucho" ATARI Assembler/Editor para ensamblar alguna rutina, siempre iniciando en la página 6 (dirección 1536 o $0600) independiente del largo que resultase, ya que siempre debía tener en mente que el código debía ser relocalizable, es decir, no podía tener instrucciones como JMP con destino a la misma rutina. Al ensamblar, lo hacía hacia disco, obteniendo un archivo binario con cabezera: firma ($FF-$FF), dirección de inicio y dirección de término. Con un programita en BASIC que hice, llamado STRING, convertía ese archivo OBJ en código BASIC en formato LST, partiendo la rutina en bloques de hasta 80 caracteres. Teniendo cargado en memoria el programa al que quería agregar la rutina USR, bastaba poner ENTER "D:RUTINA.LST" para incorporarla y probarla.

Posteriormente usé MAC/65 para crear algunas rutinas o programas completos que debían ser incorporadas a un programa BASIC, como el loader de SITRE en C1$, pero MAC/65 no genera código continuo, sino que cada 256 bytes pone unas nuevas cabezeras binarias. Si la pasaba directamente por el programa STRING, la rutina USR iba a quedar corrupta, por lo que la preprocesaba con otro programita que hice, llamado DESCOMPRESOR BINARIO, que eliminaba todas las cabeceras intermedias, dejando un bloque continuo y apto para procesar con STRING.

Cuando la rutina era realmente corta o cuando quería modificar o corregir una grande ya cargada en el programa BASIC, podía editar directamente los caracteres usando como apoyo mi fotocopia de la tarjeta de referencia del cartucho ASM/ED para buscar los bytes que no recordaba para algunas instrucciones, en conjunto con una tabla ATASCII impresa que yo mismo elaboré (pero que inadvertidamente perdí... yo suponía que estaba dentro de mi cuaderno naranja).

Usualmente yo desensamblaba programas binarios usando el DISKSCAN de David Young (que modifiqué para poder usarlo en densidad ampliada en la disketera 1050). Este programa también permitía ensamblar, así que a veces yo ponía en el programa BASIC un string largo con un valor constante (ceros, corazones o rombos) y lo grababa en disco, luego usaba DISKSCAN para meter código sobre esa área reservada... al volver a cargar el programa BASIC, tenía la rutina lista, sólo debía eliminar los caracteres no utilizados del string.

[dogdark]

primero agradecer siempre por la disposición de ustedes.

También debes convertir los valores de 16 bits en dos valores de 8 bits. Por ejemplo el 710 sería:

Código: Seleccionar todo

198, 2
(198 + 2 * 256)

la duda que me quedo franco es de donde salio ese 198 y el dos si lo que debería convertir el 710 en dos valores de 8 bits.

apoyo mi fotocopia de la tarjeta de referencia del cartucho ASM/ED para buscar los bytes que no recordaba para algunas instrucciones

ya había visitado tu sitio en busca de la tarjeta de referencia pero no logre entenderla y de como usarla la que me entrego franco me quedo clarísimo de inmediato, solo que la duda era como pasar ese valor 710 en dos bloques de 8, que apunte más arriba que me quedo la duda. por el valor que Franco me da de 198.

todo esto me salto después que vi SITRE cuando cargaba el juego había un código usr que utilizan todos para llenar los bancos en diferentes copiadores, que son rutinas de carga que están en asm.

por ejemplo cuando cargo una rutina en el basic lo hago de la siguiente manera

Código: Seleccionar todo

poke 54017,b(I), que es para la expansión 
x=usr(xio,1,7,16382,16382)

por lo tanto en la xio esta todo el código de carga para usar donde se reciben por lo que tengo entendido en asm, Entonces al enviar ese 1 ¿lo recibe automáticamente en una variable el xio?, al igual que los otros como el 7, etc, como logro cargar los archivos, no logro sacarlos nuevamente para ser grabados en un disco en limpio, es como un copyfile en 256k, porque tengo que cambiar el usr de salida.

Código: Seleccionar todo

debería ser así la salida
x=usr(xio2,1,11,16384,272000)

es por eso que me quedo la duda de como pasaban ese código usr al basic, porque al entender de como lo pasan también se puede entender de como leer ese código para saber que es lo que hay escrito ahí, no es tanto para un copiador, si no que también para generar código de ingresos de bytes o para almacenar caracteres dentro de la memoria expansiva al crear un programa, otro ejemplo es almacenar los datos que ingreso en un formulario en la memoria y después grabar todo de un viaje, y no grabar datos que queden independientes uno de otro, no se si me explique bien.

[vitoco]

Aquí ya te cambiaste de tema... de cómo poner el código de máquina en un string (variable o literal) pasaste a cómo programar una rutina que se pueda invocar desde un USR.

Seguro que hay más de alguna página que explique la estructura de las rutinas USR, pero aquí te la sescribo en forma simple...

En una rutina USR hay lo siguiente:

RETORNO=USR(RUTINA,PARAM1,PARAM2,...)

donde por fuera se ve:

• RETORNO es un valor devuelto por la rutina. Para devolver un valor entre 0 y 65535 ($0000 a $FFFF), la rutina debe escribir en las direcciones de memoria, 212 y 213 ($D4 y $D5 para bytes LO y HI del valor). Si la rutina no devuelve nada, el valor de retorno se puede ignorar en el programa en BASIC, pero siempre debe ir en la llamada porque USR es una función.
• RUTINA es la dirección de memoria donde está almacenado el programita en assembler. Puede ser un valor fijo como 1536 ($0600) o una variable o simplemente la función ADR con el string de la rutina ahí mismo.
• PARAM1, PARAM2, etc... son parámetros numéricos opcionales, también en el rango del 0 al 65535, que son pasados a la rutina a través del stack (pila) y que la rutina debe leer sí o sí, pues de lo contrario no podrá devolverle el control al programa BASIC que la llamó.

Por dentro, en la rutina en Assembler, hay que prestar atención a las siguientes cosas:

• Leer el primer byte del stack usando la instrucción PLA. Ese byte indica la cantidad de parámetros que se le pasaron a la rutina.
• Por cada parámetro, hay que leer 2 bytes más del stack, primero el byte HI y luego el LO del valor del parámetro, y almacenarlos donde te sean útiles. Si no hay parámetros, el primer byte sacado del stack debió ser cero y no hay nada más que sacar del stack. Si se sabe que el parámetro siempre va a ser un valor de 1 byte, en el código se ponen 2 instrucciones PLA seguidas, descartando así el cero que iba en el byte HI del respectivo parámetro.
• La última instrucción de la rutina debe ser RTS, que le devuelve el control al BASIC. Hay rutinas que en vez de retornar, saltan directamente con JMP a otra subrutina del sistema operativo en la ROM, pero que en la práctica ellas terminan con el RTS que faltaba e igual el control vuelve a BASIC.

Si se necesita memoria para que la rutina almacene variables, se pueden usar algunos bytes de la página cero que están reservados para este fin en BASIC: 203 a 211 ($CB a $D3).

Este no es el lugar para explicar como programar en assembler, los modos de direccionamiento, el uso del stack ni los registros de la CPU, pero sabiendo de eso, lo de arriba basta para comenzar a programar rutinas USR para los programas en BASIC.

[dogdark]

gracias por la información vitoco, pero me quedo más claro ahora con la explicación, para novatos creo que es importante conocer desde la base como esta estructurado el usr, generalmente, esta explicado de forma muy básica en varios manuales que están tanto en ingles como español y no se logra entender de buena manera como trabaja, estuve experimentando con los programas que me facilitaste anteriormente, y como estaba franco tambien en el tema, me entretuve con el copiador cainjek, y me sorprendió, la versatilidad que tienen, con el STRING, saque el código del cainjek,bin y después lo cargue como basic con el enter, y vi el código en C1$ con lo que contenía ese binario, entonces me dije, oie mismo, si mismo, este programa sirve para pasar los que tu quieres a basic, o sea creo el asm y después lo paso a basic, que es lo que queria, siiiiiii puse mucha atención, a lo que posteaste que las rutinas no deben llevar el JMP, más creo que el JMP lo puedes generar en el mismo basic, solo convendría terminar la rutina con RTS para retomar el basic como mencionaste antes, son apuntes que quedarán acá en el foro y en mi cuaderno azul ajajajjajajj el tuyo es amarillo, tratare de hacer algunas pruebas sacando ejemplos de manuales para ver en realidad como funciona el usr pero creando código asm que yo haga solo para pruebas, pero ya me queda aun más claro la conección entre ambos y con el PLA recibo los parametros de las variables que pasaria, intruseando se aprende, te dejare loco para la reunión jajajaj, llévate un armonilllll. un abrazo y muchas gracias

[fcatrin]

la duda que me quedo franco es de donde salio ese 198 y el dos si lo que debería convertir el 710 en dos valores de 8 bits.

A ver si sirve de esta forma. Te acuerdas de cuando nos enseñaban las unidades, decenas, centenas, etc? Eso es porque nosotros contamos con dígitos que van desde el 0 al 9, por lo tanto los números los descomponemos en varios dígitos que van del 0 al 9.

Si queremos contar hasta el 9, basta con un dígito, pero cuando llegamos al diez, debemos agregar un dígito adicional, así:

Código: Seleccionar todo

10

Decimos que tenemos una decena y cero unidades. Luego seguimos felices hasta el 99 (9 decenas, 9 unidades). Para pasar al cien agregamos un nuevo dígito: 100 (una centena, cero decenas, cero unidades).

Ahora bien, si tenemos el número 23, cómo sabemos matemáticamente cuantas decenas y cuantas unidades tenemos? Usando números enteros, el cálculo es así:

Si X es el número original, entonces

Código: Seleccionar todo

Decenas = X / 10
Unidades = X - Decenas*10

Si X = 23

Código: Seleccionar todo

Decenas = 23 / 10 = 2   (división entera, sin decimales)
Unidades = 23 - 2*10 = 23 - 20 = 3

Entonces el número 23 en nuestro sistema decimal (basado en 10) se compone de los dígitos 2 y 3. En computación diríamos que las unidades son dígitos Menos Significativos, y que las decenas son dígitos Más Significativos (*).

La conversión que hice para pasar de 710 a (198,2) es la misma idea, pero en vez de usar "dígitos" de 10, usé bytes. Un byte puede contar desde 0 a 255 (256 combinaciones), entonces cuando llegas al número 256, necesitas agregar un byte adicional, tal como lo hicimos en las decenas. Si llamamos L al byte Menos Significativo, y H al byte Más Significativo (Low, High), tenemos:

Código: Seleccionar todo

H = X / 256
L = X - H*256

Entonces si el número decimal es 710, para representarlo en bytes sería:

Código: Seleccionar todo

H = 710 / 256 = 2   (división entera, siempre)
L = 710 - 256*2 = 710 - 512 = 198

Esto es válido para cualquier sistema numérico. En computación se usa frecuentemente el binario en donde cada dígito puede tomar dos valores (0, 1), y el hexadecimal en donde cada dígito puede tomar 16 valores (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). Por ejemplo el número decimal 31 calculado como hexadecimal será:

Código: Seleccionar todo

H = 31 / 16 = 1  (división entera)
L = 31 - 1*16 = 31 - 16 = 15 = F

Por lo tanto el número 31 decimal se escribe como 1F en hexadecimal.

Cualquier duda dale no más y pregunta!

(*) Usamos los valores Más Significativos a la derecha de los Menos Significativos. Esa, como muchas otras cosas en la vida, son sólo por convención. Perfectamente podríamos usar los números Menos Significativos a la derecha, por lo que el número doscientos cincuenta y uno se escribiría así : 152, de hecho hay arquitectura de computadores que ordenan los bytes de esa forma. Así como eso, hay muchas cosas que aprendimos desde muy chicos y creemos que naturalmente son así, pero perfectamente podrían ser diferentes.

[dogdark]

ahora que tengo claro este tema, después de la conversa que tuve con el vitoco, en la misma junta, nos asalto la duda y lo conversamos, sobre el tema del injektor, como ya se han creado los copiadores respectivos a con usr creados por vitoco para la ampliación del 256k en varios formatos, pasamos al tema de crear estas usr en injektor, primero lo que quiero saber, es como se maneja este sistema, como se activa, o simplemente se cambia el valor de velocidad de lectura de la respectiva casetera, si más la idea es comenzar con este tema.

loader

carrier o header, blk1, carga injek, blk1game, blk2game. etc etc ..... eof

primero siempre me e fijado que hay diferentes formas donde utilizan el encabezado usan el 85,85 y otros usan el 55,55, cual es la diferencia entre uno y otro?

y la segunda pregunta , es como se activa el injektor de la casetera, será con el cambio del baudio o simplemente se puede usar un poke?

[vitoco]

Me hago las mismas preguntas, pero creo que eso escapa de este hilo. Mejor hacer un hilo propio sobre sistemas Injector, con su análisis de HW y SW, ingeniería inversa y todo lo que sea necesario.

[dogdark]

creo que seria mejor, creemos un hilo para eso entonces.

[Suppawer]

Probando el programa string.bas de Vitoco

Hacer un programa en el Assembler Editor:


Luego, en basic, ejecutar el programa string.bas


Crear el programa deseado (lo hice muy básico). A continuación cargar el archivo lst que creamos. Luego dimensionar la variable y hacer el llamado con USR:

Al ejecutarlo:


Adjunto el .atr (abrir en ventana nueva):
ATR

Vitoco ¿en qué casos se debe usar el otro programa descompr.bas? Y ¿Qué hay de eso que pusiste en otro tema referido a borrar las líneas 410,420 y 430 del string.bas?

[vitoco]

Bueno el mini-tutorial.... ¡Gracias!

Vitoco ¿en qué casos se debe usar el otro programa descompr.bas?

Los programas binarios del Atari como los XEX tienen una estructura fija:

1. 2 bytes: "firma" con valor $FFFF, es decir 2 bytes 255 seguidos (los programas BASIC tienen $0000).
2. 2 bytes: dirección de memoria "desde" donde se cargará el programa (bytes ordenados LO-HI).
3. 2 bytes: dirección de memoria "hasta" donde se cargará el programa (bytes ordenados LO-HI).
4. N bytes: programa y/o datos, donde N=hasta-desde+1.
5. Opcionalmente se repite desde el paso 1 o el 2 para más bloques.

Cuando uno hace una rutina en assembler, el ensamblador MAC/65 genera bloques de hasta 256 bytes, por lo que si la rutina resulta más larga que eso, el OBJ no será un bloque contínuo sino que tendrá bytes de cabeceras metidas dentro del código, produciendo además un desplazamiento en parte de él si no nos damos cuenta, y la rutina quedará corrupta si la metemos tal cual a nuestro nuevo programa.

Esos datos extra hay que eliminarlos antes de pasárselos al programa STRING.BAS y esa es la función del descompresor. Adicionalmente si los bloques no son inmediatamente contiguos, el descompresor es capaz de rellenar con bytes "cero" hasta una cantidad máxima (por eso el nombre "descompresor"), pero si se pasa del máximo, se conservarán las cabeceras intermedias en vez de rellenar.

Y ¿Qué hay de eso que pusiste en otro tema referido a borrar las líneas 410,420 y 430 del string.bas?

El programa STRING asume que el OBJ tiene la cabecera de los binarios y que no se necesita cuando la rutina está en una cadena para ser invocada por un USR. Esas líneas del programa leen esos 6 bytes y los descartan. En ese post, el archivo a leer tenía la estructura preparada para ser almacenado en cinta, es decir, no hay cabecera que descartar, y por eso "pichicateamos" STRING para que conserve los 6 primeros bytes del binario simplemente borrando esas líneas del programa utilitario.

[dogdark]

Continuando con el tema y aprovechando los recursos entregados por vitoco, y en conversa con el suppa, hay dudas respectos al usr que me han salido en el camino, paso a detallar

primero creo un codigo en mac65

Código: Seleccionar todo

0100     *=  $0600
0110 INICIO
0120     PLA
0170     LDA #HLIST&255
0180     STA $0230
0190     LDA #HLIST/256
0200     STA $0231
0210 LOOP JMP LOOP
0220 LINEA1 .SBYTE " mi primer programa "
0230 HLIST
0240     .BYTE $70,$70
0250     .BYTE $46
0260     .WORD LINEA1
0270     *=  $02E0
0280     .WORD INICIO

lo primero, tengo entendido que los jmp se deben eliminar y no deben usarse en las aplicaciones usr. por lo tanto la linea 210 debo cambiarla por RTS para dar el control absoluto al basic.

por lo tanto quedaría asi

Código: Seleccionar todo

0100     *=  $0600
0110 INICIO
0120     PLA
0170     LDA #HLIST&255
0180     STA $0230
0190     LDA #HLIST/256
0200     STA $0231
0210     RTS
0220 LINEA1 .SBYTE " mi primer programa "
0230 HLIST
0240     .BYTE $70,$70
0250     .BYTE $46
0260     .WORD LINEA1
0270     *=  $02E0
0280     .WORD INICIO

a pesar de eso cuando hago lo mismo que suppa, lo convierto y lo paso a basic, al realizar el llamado con X=USR(ADR(L$)), este no funciona. si supuestamente de trabaja con DLI para mostrar el texto en pantalla, este porque no se activa, hay que agregar algo más para la aparición del texto????. solo me aparece la pantalla en negro.

[vitoco]

Efectivamente no puedes usar JMP, y en vez de devolverle el control al BASIC con RTS, puedes hacer un branch infinito, por ejemplo con BNE si sabes que el acumulador (registro A) tiene valor distinto de cero, o BEQ si es igual. Así usas referencias relativas y no absolutas.

Sin embargo, eso no te resuelve el problema en tu programa, ya que HLIST y LINEA1 también son direcciones fijas de memoria, por lo que no podrías meter ese programa en una cadena del BASIC y debes mantenerla en página cero, o bien alterar los bytes con las direcciones de memoria, lo cual puede resultar engorroso. Más fácil hacer que el programa BASIC mueva todo el programita a la página 6 aprovechando que es cortito y correrlo ahí.

Además, a tu lista de despliegue le falta otro loop (con direcciones fijas)... eso se hace con la "instrucción" $41 (65) y los la dirección de memoria del primer byte de la lista de despliegue.

Por último, si quieres usar mi programa STRING, no te olvides de remover los 6 bytes finales correspondientes a la dirección de inicio.

Por lo tanto, tu programita toma la siguiente forma (sin considerar que hay que alterar los bytes en la lista de despliegue):

Código: Seleccionar todo

0100     *=  $0600
0110 INICIO
0120     PLA
0170     LDA #<HLIST
0180     STA $0230
0190     LDA #>HLIST
0200     STA $0231
0210 LOOP BNE LOOP
0220 LINEA1 .SBYTE " mi primer programa "
0230 HLIST
0240     .BYTE $70,$70
0250     .BYTE $46
0260     .WORD LINEA1
0265     .BYTE $41
0266     .WORD HLIST
0270     *=  $02E0
0280     .WORD INICIO

Se puede observar que en lugar de usar aritmética, usé los signos ">" (para high) y "<" (para low) para obtener los bytes por separado de la dirección. Los ensambladores lo aceptan y el código queda más claro.

Otra cosa: si no se va a usar en BASIC, el inicio no necesita el PLA (aunque da lo mismo si el programa muere en un loop infinito).

[dogdark]

continuamos con el proceso,,,,, realizamos la modificacion del codigo en assembler para mostar una idea de lo que quiero

Código: Seleccionar todo

1020     *=  $0600
1030 INICIO
1040     LDA $02C5
1050     STA $02C7
1060     LDA $02C8
1070     STA $02C6
1080     PLA
1090     LDA # <HLIST
1100     STA $0230
1110     LDA # >HLIST
1120     STA $0231
1130 LOOP BNE LOOP
1140 LINEA1 .SBYTE " mi programa  atari "
1150 LINEA2 .SBYTE " PROGRAMAS PARA COMPUTADORES ATARI 2015 "
1160 LINEA3 .SBYTE "OTRO EJEMPLO PARA VE"
1170 LINEA4 .SBYTE "    CREADO POR DOGDARK Y VITOCO 2015    "
1180 HLIST
1190     .BYTE $70,$70
1200     .BYTE $46
1210     .WORD LINEA1
1220     .BYTE $70,$70
1230     .BYTE $43
1240     .WORD LINEA2
1250     .BYTE $70,$70,$70,$70,$70,$70,$70,$70
1260     .BYTE $47
1270     .WORD LINEA3
1280     .BYTE $70,$70,$70,$70,$70,$70,$70,$70
1290     .BYTE $43
1300     .WORD LINEA4
1310     .BYTE $41
1320     .WORD HLIST
1330     *=  $02E0
1340     .WORD INICIO

ahora paso a ensamblarlo como ASM,,#D:P1.OBJ, ya listoco , lo pruebo a ver si funciona cargando el DOS.



ahora procedo a ejecutar en basic el descompr.bas

ingreso el archivo D:P1.OBJ y como destino D:P2.OBJ y el maximo de relleno le doy 256

convertido ok...

ahora habro el archivo string,bas

ingreso D:P2.OBJ

DESTINO D:P2.LST

VARIABLE L$

NUMERO DE LINEA 500

INCREMENTO 10, OK

ahora captemos el código pos..... y lo modificamos



aplicamos run yyyy channnnnn....



que hice mal??????? como 30 intentos y nada de nada. cueccc

[vitoco]

Ya te dije, la parte de la lista de despliegue tiene direcciones de memoria fijas en la pagina 6 y habría que modificar para llevarlas a la dirección de la variable. Así como está nunca va a andar.

Además, olvidaste remover los últimos 6 bytes correspondientes a la dirección de inicio como si fuera XEX.

[dogdark]

O sea cuando te refieres a

Además, olvidaste remover los últimos 6 bytes correspondientes a la dirección de inicio como si fuera XEX.

te refieres a modificar los ultimos 6 caracteres de la linea 520 por

FF FF 00 06 B3 06

y eliminar del asm las lineas 1330 y 1340 y en *= $6000 cambiarla por *=0000, ya me enrede

[vitoco]

No me refiero a modificar, sino a eliminar. Si eliminas las líneas 1330 y 1340, esos últimos 6 bytes no llegarán al programa BASIC. Los 6 primeros los saca mi programa STRING automáticamente.

El *=$0600 sólo indica donde comenzar a ensamblar y fijar las direcciones de memoria absolutas dentro del código, sobre todo de la data como son la lista de despliegue y los mensajes. Una rutina USR en una variable no admite contenido que no sea relativo. Por lo tanto, tu programa nunca va a funcionar dentro de una variable a menos que modifiques varios bytes en caliente, y eso no es práctico. Mejor hacer un loop para pasar de vuelta el contenido de la variable a la memoria original en la página 6 y llamar con X=USR (1536)