Se puede saber la ultima posicion de Mem en basic

[mentalthink]

Quería saber por curiosidad si es posible saber la ultima posicion de memoria que usa un programa hecho en Basic en el CPC.. o sea saber dónde se ha quedado el Procesor Counter(no sé si se llam asi).

había pensado en una idea, pero no sé si el Basic del Amstrad hace esto... si se sabe la memoria que te queda libre, sería bastante sencillo,no?¿, simplmente habría que ir contando las casillas libres que quedan y restarselas a la memoria totoal del CPC, supongo que saltandose desde a dónde va todo el tema del firmware... Lo que no sé es como mirar la memoria que queda libre, sobre dónde está en cada momento de ejecución no es que me preocupe mucho, pero deberia ser lo mismo de forma automatizada, no?¿...

[mcleod_ideafix]

En el CPC no sé, pero en el BASIC del Spectrum, se sabe cuál es la primera posición libre (no usada por el BASIC) mirando el valor de la variable del sistema RAMTOP (23730). Puedes cambiar el valor de dicha variable con la orden CLEAR y así tener más memoria disponible.

Para otros BASIC, suele haber una función FREE() que te indica cuánta memoria no está siendo usada por el BASIC. Probablemente el CPC tenga también una variable del sistema que indique a partir de qué posición no se está usando, y probablemente tenga una orden para ajustar la primera dirección de memoria disponible.

[Namek]

El comando BASIC que se usa en el AMSTRAD CPC para determinar hasta que direccion de memoria podra usar el BASIC es "MEMORY direccion", osea que si en la primera linea de mi programa BASIC pongo MEMORY 32768 esto significa que dispondre de 32768 bytes de memoria para mi programa y que a partir de esa misma direccion podre almacenar datos y el BASIC jamas los pisara. Por lo que yo veo este comando es el equivalente al CLEAR del Spectrum.

[mentalthink]

Ok Gracias entonces haciendo lo que digo, de calcular a mano lo que te da en Kb te sale la posicion no?¿
Gracias por la info.

Lo de la memoria Namke me parece que es HiMem no?¿... o esto es otra cosa?¿

[na_th_an]

Lo que dice Namek, (CLEAR en Spectrum, MEMORY en CPC) no es más que una forma de decirle al intérprete de BASIC que no deje que el programa y sus variables crezcan más allá de la posición de memoria que se indica. De ese modo, podemos cargar datos o rutinas en código máquina a partir de esa dirección sin temor de que sobrescribamos esa memoria con BASIC. Es como poner una especie de "tope", y decirle al intérprete "oye, a partir de X no toques nada". El programa en BASIC y las variables empiezan a crecer desde zonas bajas de memoria hacia arriba, por eso el "tope" es superior en estos modelos.

Para saber cuánta de la memoria reservada para BASIC te queda libre... desconozco el método en CPC. Como se ha mencionado, en Spectrum se trata de restar al valor del "tope" de BASIC (la dirección de CLEAR, llamada RAMTOP) la dirección donde termina el programa y lo que ocupan las variables. Toda esa información la guarda el intérprete en posiciones de memoria fijas dentro de un grupo de datos llamado "variables del sistema". Es muy probable que el CPC funcione de forma parecida, y tenga una zona de memoria donde BASIC guarda datos que necesita, como por ejemplo dónde tiene que colocar la siguiente linea de código, o dónde están y cuánto ocupan las variables. Seguro que en el manual del CPC viene toda esa información, y con ella seguro que podemos sacar la operación necesaria para averiguar cuánto espacio queda libre para BASIC.

[Joss]

Efectivamente es una variable:

Código: Seleccionar todo

print himem

devuelve la posición de memoria máxima que puede usar el basic. Con:

Código: Seleccionar todo

memory 30000

por ejemplo, la reducimos.
Prueba a ver el valor de himem y luego con memory lo puedes modificar.

[na_th_an]

Sí, pero eso no nos sirve directamente para saber cuánto queda libre, y dónde termina la última instrucción de BASIC, que creo que era lo que se estaba preguntando en un principio, sino hasta donde puede llegar BASIC.

Por ejemplo, en Spectrum hay una rutina en la ROM que calcula cuánta memoria está en uso (sumando ROM, variables del sistema, pantalla y teniendo en cuenta RAMTOP), así que

Código: Seleccionar todo

PRINT 65536-USR 7962

nos da la memoria que queda para BASIC. Debe haber algo similar, más o menos intrincado, para saberlo en un CPC.

[Skuall]

Creo que era algo asi para ver la memoria libre:

PRINT FRE(0)


Update: Acabo de probarlo y es asi.

[Joss]

La RAM empieza en la posición cero de memoria, al igual que la ROM baja. Al encender el CPC copia ahí un par de rutinas que usa para cambios de bancos de memoria. La variable HIMEM nos da casi toda la memoria libre para BASIC, solo hay que restarle (creo) 128 bytes, o un valor fijo, que no estoy seguro cual es. Si encuentro la referencia la pongo.

(Joss se va corriendo a buscar en Google a ver si lo que ha puesto es cierto, que seguro seguro no está ...... )

-- Actualizado 28 Abr 2013, 14:33 --

Creo que era algo asi para ver la meemoria libre:

PRINT FRE(0)

Debe ser. En el emulador print himem devuelve 42619 y print fre(0) 42249. En grimware está el mapa de memoria. Para basic empieza en &170 hasta HIMEM.
EDITO: acabo de ver tu update

[BlackHole]

Hola mentalthink,

No sé si esta consulta va en relación a la otra que has abierto "Memoria RAM y como se escribe... " también en el foro, pues muchas de las contestaciones escritas allí se pueden aplicar también a este tema. En el otro hilo ha quedado más o menos claro, que es el sistema operativo quien decide cómo se va a organizar la memoria disponible. En el caso de nuestros viejos amigos de 8 bits, sería el código de la ROM o Firmware que se ejecuta en el arranque de la máquina, el responsable de permitir que el usuario interactúe en BASIC y de intentar mantener el control de los programas escritos en ese lenguaje.

El BASIC es un lenguaje interpretado. ¿Qué significa esto? A diferencia de los lenguajes de alto nivel compilados que generan un bloque de código máquina, o a los directamente escritos desde ensamblador, el BASIC se va analizando sintácticamente línea por línea y cada comando hace ejecutar una subrutina específica previa de la ROM o Firmware. Si el comando tiene que tomar valores y/o devolver resultados a través de variables, el sistema operativo se encarga internamente de definir un área de memoria para almacenar dichas variables de usuario, y mantener una tabla de punteros para llegar a ellas.

El tamaño del área de variables de usuario se ajustará dinámicamente, pues al ser el programa interpretado línea a línea, el sistema no sabe de antemano cuánto va a necesitar ni cuánto reservar. En algunos equipos de 8 bits, ese área de variables crece hacia arriba y en otros crece hacia abajo. En otros se almacena después del código del programa y es constantemente empujada conforme vamos metiendo más líneas BASIC al programa. Eso al programador de BASIC no le importa, pues se realiza internamente, pero te lo cuento para que veas que es solo cuestión de cómo el programador original de la ROM decidió organizar el equipo. Si a esos señores se le hubiese ocurrido otra cosa, el comportamiento de su BASIC habría sido radicalmente diferente.

Los procesadores tienen un registro contador de programa (PC) que es el que gestiona la ejecución de la siguiente instrucción de código máquina. Pero a la hora de interpretar el BASIC, el registro PC no es el que regula concretamente ese tema, ya que como expuse antes, cada instrucción de BASIC invoca a una subrutina de código máquina que puede ejecutar decenas o cientos de instrucciones reales de procesador. Para llevar la cuenta de por dónde va, el número de línea y el comando dentro de cada línea, el sistema lo va apuntando en su propia área de variables del sistema. Ese área, al contrario de la de variables de usuario, sí que suele ser fija y suele estar documentada, por si acaso necesitamos acceder a sus valores.

Como casi todos los BASIC permiten al usuario el poder saltar a ejecutar un programa en código máquina, es cuando pasa a ser tu responsabilidad el conocer la estructura interna del equipo y para ello existen manuales detallados de dónde deja el sistema cada cosa, porque en los 8 bits pasabas a tener el control absoluto de la máquina y cualquier fallo de tu programa bloquearía el ordenador. No sé muy bien cuál es la intención al hacer tu consulta, si es que tiene un propósito específico o es mera curiosidad.

Para Amstrad CPC, la Guía del Firmware es el manual detallado que explica la estructura del sistema. Para ir todavía a un nivel más bajo, ya tendríamos que recurrir a desensamblados de la ROM, que no suele ser necesario salvo en extraños casos donde queramos ejecutar arbitrariamente código desde puntos de entrada no estándar. La disposición en los equipos de 64 KB va a ser diferente a la establecida en los equipos de 128 KB, ya que al incorporar más funcionalidades, muchas cosas acabaron movidas de sitio. La documentación recoge la estructura de ambas máquinas.

Yo no soy programador de Amstrad CPC, pero en la ristra de variables del sistema seguro que uno de los muchos punteros es el que almacena la posición del fin de programa.
Ver páginas 8 a 29 de este documento en PDF: http://www.cantrell.org.uk/david/tech/c ... rmware.pdf