¿Que tipo de proteccion de memoria tiene el C64?

[Luna]

una de mis aficiones (las matemáticas) hace años que la tengo compaginada con la retroinformática... ayer estuve trasteando con un calculador del Numero PI en BASIC con el C64, usando el algoritmo "Monte Carlo", el ordenador 'lanza' unos 'dardos' 'aleatorios' a una 'diana' circular con un tetraedro rodeandola, calculando el ratio de 'dardos' que caen dentro o fuera del circulo, se sabe la aproximación de PI.

El caso es que el programa ha de registrar las coordenadas de cada lanzamiento, y tras 12000 lanzamientos el programa se cuelga llenando la pantalla de basura, como si el registro de coordenadas invadiese el área de la memoria asignada a la pantalla. Es eso normal, una curiosidad o un bug?

-- Actualizado 02 Nov 2013, 01:06 --

Edito: Para los curiosos, la aproximación más proxima a PI (3.1415926535...) que he obtenido con el Commodore ha sido "3.1466667" tras 300 lanzamientos, en cambio, tras 5000 obtuve "2.98..." no siempre más es mejor... quizas pueda implementar el programa adaptando mi "generador REAL de números aleatorios" que desarrollé en el MSX...

[calpirro]

Edito: Para los curiosos, la aproximación más proxima a PI (3.1415926535...) que he obtenido con el Commodore ha sido "3.1466667" tras 300 lanzamientos, en cambio, tras 5000 obtuve "2.98..." no siempre más es mejor... quizas pueda implementar el programa adaptando mi "generador REAL de números aleatorios" que desarrollé en el MSX...

Eso parecería indicar que la distribución de probabilidad de los números aleatorios del C64 no es uniforme; cosa que seguro es cierta pero me extraña tanta desviación. ¿Quizás problemas de redondeo en los cálculos?

Yo cuando era más joven también corrí un programa en un C64 para calcular PI. Era un algoritmo basado en la Arcotangente que no recuerdo ya de dónde lo saqué. Estuvo una semana calculando y sacó 10.000 cifras exactas...

[mcleod_ideafix]

El caso es que el programa ha de registrar las coordenadas de cada lanzamiento, y tras 12000 lanzamientos el programa se cuelga llenando la pantalla de basura, como si el registro de coordenadas invadiese el área de la memoria asignada a la pantalla. Es eso normal, una curiosidad o un bug?

Habría que ver el código del programa, pero probablemente es un bug del propio programa. De todas formas, el C64, como el resto de micros de 8 bits que yo conozca, no tiene ningún tipo de protección de memoria.

He hecho un programa por el estilo, usando también el método de Montecarlo, y de momento muy preciso no es. Hay que tener en cuenta que el número de cifras decimales que consigas de PI depende de la resolución del generador de números aleatorios que tenga esta máquina. Es decir, de la cantidad de valores diferentes que genere antes de volver a repetir la secuencia. Habitualmente se usan métodos que aseugran que el generador pasará por todos los valores posibles antes de repetir la secuencia, y dicha secuencia suelen ser 65536 valores (aunque en el C64 por aquello de que puede usar el reloj interno para aleatorizar aún más la secuencia, la longitud de ésta no sé cuál es en realidad).

También lo he hecho para el Spectrum. Aquí sé que la secuencia es cíclica e uniforme, reptiéndose tras 65536 valores. De hecho, y como la secuencia es cíclica y con un periodo de repetición corto, aquí el método de Montecarlo de poco sirve: sería equivalente a rellenar de píxeles un cuadrado de 256x256 píxeles viendo cuáles caen dentro del círculo y cuáles no, y para eso te ahorras llamar al generador de números aleatorios: sencillamente barres toda la superficie desde las coordenadas -12,-128 hasta la 127,127. La precisión obtenida llega sólamente a 2 decimales (redondeando al segundo decimal)

[zup]

Bueno, no sé mucho del C64, pero imagino que aquí influyen dos variables.

Creo que el micro en sí (el 6502) no incluye ningún tipo de protección, eso me parece que podemos empezar a verlo en micros de 16 bits. Si tu programa está en c/m, tú mismo eres el que debe cuidar de no sobreescribir cachos importantes de la memoria (stack y esas cosas).

Sí el programa está en BASIC, eso ya depende del intérprete BASIC y cómo lo uses. En el caso del Spectrum, hay un algunas "pseudo protecciones". Para empezar, tienes los errores Susbscript wrong (índice malo en los arrays) y Out of memory (has llenado el área de variables, o la pila va a chocar con el programa BASIC). Si decides "reservar" un área con CLEAR (para POKEar los variables en vez de usar arrays), podrías conseguirte un bonito RAMTOP no good. Todas estas "protecciones" están activas si sigues las reglas; si desde BASIC te dedicas a POKEar la memoria indiscriminadamente, podrías sobreescribir áreas importantes (variables de sistema, pila, el propio programa BASIC).

En el caso del C64 las cosas van a ir por el mismo palo: todas las protecciones (si las hay) están hechas por software. Si usas el BASIC y no accedes directamente a memoria, puede que estés protegido (depende de lo que hayan hecho los programadores del BASIC). Si usas c/m, renuncias a cualquier tipo de protección.

[Luna]

el programa lo saqué de un blog en el que el listado aparecia en la pantalla de un PET.

A ver, en cada tirada genera 2 cifras de 10 dígitos/bytes (aparecen en pantalla) 1000 tiradas son unos 20K de datos 12000 tiradas, que es donde falla, serían 220Kb, obviamente no hay esa memoria, así que el programa a la que ha llenado la memoria de BASIC (30291?) bytes supongo que comienza a sobreescribir los datos de las primeras tiradas, y cuando se cuelga es que sobreescribe donde no debe...

Al menos no me lo he cargado...

P.D. Calpirro, ese programa pinta bien... (Es que me gusta eso de ponerle 'deberes' al ordenador y que con un programa de 3 lineas se tire 3 horas pensando..)

[scooter]

Ya no me acuerdo bien, la memoria de pantalla empezaba en 1024 y el basic en la 2048 si no me equivoco.
El basic llegaba mas o menos hasta -20kB de los 64k, osea mas o menos 44x1024=45053 mas o menos, por debajo de la ROM se puede pokear sin problemas; cualquier poke a la ROM "cae" en la RAM que hay debajo pero para leerlo hay que desconectar la ROM y no me acuerdo si se puede hacer en basic, creo que no; cualquier peek leerá la ROM
De hecho con ese sistema se españolizaba el basic; se pokeaba todo lo peekeado y tenías una copia en RAM, se desconectaba la ROM y se editaban los mensajes de error o los comandos

[mcleod_ideafix]

el programa lo saqué de un blog en el que el listado aparecia en la pantalla de un PET.

A ver, en cada tirada genera 2 cifras de 10 dígitos/bytes (aparecen en pantalla) 1000 tiradas son unos 20K de datos 12000 tiradas, que es donde falla, serían 220Kb, obviamente no hay esa memoria, así que el programa a la que ha llenado la memoria de BASIC (30291?) bytes supongo que comienza a sobreescribir los datos de las primeras tiradas, y cuando se cuelga es que sobreescribe donde no debe...

Pero... ¿es que almacena las tiradas que hace? ¿Para qué? En el algoritmo de Montecarlo para calcular PI no hay que almacenar cada resultado individual de la tirada, tan sólo dos variables: una que cuente las tiradas totales y otra que cuente las tiradas que han caido dentro del círculo.

[Luna]

La segunda en la frente... no hay ningun bug, simplemente la M... de conector DIN del transformador, que estaba sucio y cuando le daba pegaba un microcorte colgando el ordenador.

Ahora acaba de terminar un proceso de 5 horas y 100.000 tiradas, segun el, pi = 3.12... Esto del Montecarlo es una tonteria, incluso midiendo diametro y desarrollo de un pneumatico de bicicleta y haciendo una simple división me dá 3.14 por lo menos...

Bueno, creo que el commodore al menos se que funciona...

[zup]

No sé, no conozco mucho de matemáticas ni de algoritmos de ese estilo, pero quizás el problema sea el tamaño del círculo.

Por lo que cuentas, dibujas el círculo en pantalla y después tiras hacia el círculo. Tanto el círculo como el tetraedro que caben en pantalla no son muy grandes, y si usas números enteros esto puede tocarte un poco la moral. ¿Qué tal probando con un círculo "virtual" de radio 16384?

[mcleod_ideafix]

Esto del Montecarlo es una tonteria, incluso midiendo diametro y desarrollo de un pneumatico de bicicleta y haciendo una simple división me dá 3.14 por lo menos...

No, lo que pasa es que el método de Montecarlo tiene una convergencia muy lenta. Hay sucesiones que convergen mucho más rápidamente. Además, si te lees lo que puse sobre los generadores de números pseudoaleatorios, pasa que si el del C64 tiene una secuencia que se repite cada pocos números (pocos = 65536 o menos) entonces da igual las tiradas que hagas, ya que no conseguirás más exactitud que la que consiguieras con 65536 tiradas.