BASIC 48 versus BASIC 128
Moderador: Sir Cilve Sinclair
-
- rst 0
- Mensajes: 41
- Registrado: Dom Ago 12, 2007 10:50 pm
- Ubicación: Murcia (España)
- Contactar:
BASIC 48 versus BASIC 128
Hola de nuevo.
He estado haciendo algunas pruebas en dos emuladores (SPIN y EmuZWin) y he descubierto algo que no sabía. Que, al parecer, el BASIC escrito en modo 48 es más rápido que el tecleado en modo 128. ¿Pasaba esto también con el Spectrum 128 real? Es que pensaba que, al final, lo escrito en modo 128 se pasaba a tokens, pero parece ser que no ¿me equivoco?
Un saludo.
He estado haciendo algunas pruebas en dos emuladores (SPIN y EmuZWin) y he descubierto algo que no sabía. Que, al parecer, el BASIC escrito en modo 48 es más rápido que el tecleado en modo 128. ¿Pasaba esto también con el Spectrum 128 real? Es que pensaba que, al final, lo escrito en modo 128 se pasaba a tokens, pero parece ser que no ¿me equivoco?
Un saludo.
El Spectrum no necesita ser actualizado cada equis años, y SIEMPRE es compatible consigo mismo (chúpate esa, BG).
-
- rst 0
- Mensajes: 24
- Registrado: Sab May 19, 2007 1:30 am
- Ubicación: Madrid
- Contactar:
Es algo que extraña bastante, pero es completamente cierto, y no solo es cosa de los emuladores.
Nosotros nos dimos cuenta del problema cuando estabamos creando Insert Coins. Se probo el tema de la velocidad de ejecucion de BASIC en los Spectrum 128, y todos ejecutan el BASIC mas lento en modo 128. (+128, +2, +2a y +3).
Si usas el modo 48 en cualquiera de estas maquinas si que obtienes exactamente la misma velocidad que en los 48k originales.
El porque es algo que no te puedo resolver. Quizas alguien nos pueda descubrir el misterio....
Un saludo.
Octocom.
Nosotros nos dimos cuenta del problema cuando estabamos creando Insert Coins. Se probo el tema de la velocidad de ejecucion de BASIC en los Spectrum 128, y todos ejecutan el BASIC mas lento en modo 128. (+128, +2, +2a y +3).
Si usas el modo 48 en cualquiera de estas maquinas si que obtienes exactamente la misma velocidad que en los 48k originales.
El porque es algo que no te puedo resolver. Quizas alguien nos pueda descubrir el misterio....
Un saludo.
Octocom.
- horace
- Jack The Nipper
- Mensajes: 147
- Registrado: Mar Abr 17, 2007 7:57 am
- Ubicación: 16384-23295
- Contactar:
Buenas,
Creo que tiene que ver con la paginación de la ROM-0 (Editor 128K) y la ROM-1 (48 BASIC) de los modelos de 128K. Esa paginación añadiría un retraso extra en la ejecución de los programas BASIC...
Creo que tiene que ver con la paginación de la ROM-0 (Editor 128K) y la ROM-1 (48 BASIC) de los modelos de 128K. Esa paginación añadiría un retraso extra en la ejecución de los programas BASIC...
Un saludo, Josetxu (@HoracioGloton)
http://espectrum.speccy.org - ESpectrum
http://mhoogle.speccy.org - Buscador MHoogle
http://retroaccion.org - Asociación RetroAcción
http://espectrum.speccy.org - ESpectrum
http://mhoogle.speccy.org - Buscador MHoogle
http://retroaccion.org - Asociación RetroAcción
-
- rst 0
- Mensajes: 41
- Registrado: Dom Ago 12, 2007 10:50 pm
- Ubicación: Murcia (España)
- Contactar:
Repasando el manual del 128 encuentro la instrucción SPECTRUM. Ejecutándola, pasamos a modo 48k SIN perder el programa existente en memoria. Ahora, al ejecutarlo, este se activa a la máxima velocidad. Parece como si efectivamente convirtiera a tokens, pero tuviese algún trabajillo "extra" ejecutándose de fondo (tal vez lo que menciona horace), lo que explicaría la menor celeridad. Esto podría comprobarse si alguien que tuviese un Spectrum+ 128 físico pudiese copiar un programita como el que utilizo para mis pruebas (sacado de http://www.users.globalnet.co.uk/~jg27p ... r01_21.htm y que acompaño a continuación), lo grabase en cinta y luego lo cargara en modo 48k.
El programa en cuestión es sencillo:
10 FOR A=0 TO 175
20 FOR B=0 TO 255
30 PLOT B,A
40 NEXT B
50 NEXT A
A propósito, no perdais de vista la velocidad alcanzable usando un intérprete Forth. Yo he realizado la prueba y los tiempos se corresponden con los mencionados en el artículo.
El programa en cuestión es sencillo:
10 FOR A=0 TO 175
20 FOR B=0 TO 255
30 PLOT B,A
40 NEXT B
50 NEXT A
A propósito, no perdais de vista la velocidad alcanzable usando un intérprete Forth. Yo he realizado la prueba y los tiempos se corresponden con los mencionados en el artículo.
El Spectrum no necesita ser actualizado cada equis años, y SIEMPRE es compatible consigo mismo (chúpate esa, BG).
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
Es por varias cosas:
1.- Hay que paginar para pasar de intérprete a editor.
2.- Al haber PLAY y SPECTRUM supongo que se produce un pequeño retardo al tener dos instrucciones más que codificar.
Básicamente la interrupción de BASIC hace más cosas.
Yo siempre he usado el modo 48 BASIC por el tema de la edición por tokens, que me gusta más. Y si quieres usar el AY no tienes más que entrar en modo USR 0 Yo tenía juegos para 48 BASIC que usaban efectos de sonido OUTeando al AY. Para eso tenía que entrar en +3 BASIC y poner "RANDOMIMZE USR 0" (con lo que se reinicia en modo 48 BASIC) antes de cargar el juego. Básicamente lo que ocurre es que el spectrum no se cosca de que está en modo 48, con lo que el AY es igualmente accesible. Además incluso se puede paginar.
1.- Hay que paginar para pasar de intérprete a editor.
2.- Al haber PLAY y SPECTRUM supongo que se produce un pequeño retardo al tener dos instrucciones más que codificar.
Básicamente la interrupción de BASIC hace más cosas.
Yo siempre he usado el modo 48 BASIC por el tema de la edición por tokens, que me gusta más. Y si quieres usar el AY no tienes más que entrar en modo USR 0 Yo tenía juegos para 48 BASIC que usaban efectos de sonido OUTeando al AY. Para eso tenía que entrar en +3 BASIC y poner "RANDOMIMZE USR 0" (con lo que se reinicia en modo 48 BASIC) antes de cargar el juego. Básicamente lo que ocurre es que el spectrum no se cosca de que está en modo 48, con lo que el AY es igualmente accesible. Además incluso se puede paginar.
-
- Manic Miner
- Mensajes: 215
- Registrado: Lun May 07, 2007 7:43 pm
- Ubicación: Madrid
- Contactar:
na_th_an escribió:[...]Y si quieres usar el AY no tienes más que entrar en modo USR 0 Yo tenía juegos para 48 BASIC que usaban efectos de sonido OUTeando al AY. Para eso tenía que entrar en +3 BASIC y poner "RANDOMIMZE USR 0" (con lo que se reinicia en modo 48 BASIC) antes de cargar el juego. Básicamente lo que ocurre es que el spectrum no se cosca de que está en modo 48, con lo que el AY es igualmente accesible. Además incluso se puede paginar.
Coñe... había descargado yo algunas demos que ponía que tenían que ejecutarse en modo "USR 0", y no daba con la clave ... ¡Gracias!
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
Benway escribió:na_th_an escribió:[...]Y si quieres usar el AY no tienes más que entrar en modo USR 0 Yo tenía juegos para 48 BASIC que usaban efectos de sonido OUTeando al AY. Para eso tenía que entrar en +3 BASIC y poner "RANDOMIMZE USR 0" (con lo que se reinicia en modo 48 BASIC) antes de cargar el juego. Básicamente lo que ocurre es que el spectrum no se cosca de que está en modo 48, con lo que el AY es igualmente accesible. Además incluso se puede paginar.
Coñe... había descargado yo algunas demos que ponía que tenían que ejecutarse en modo "USR 0", y no daba con la clave ... ¡Gracias!
A mi ver, creo que es una de las genialidades "por casualidad" del Speccy. Al hacer RANDOMIZE USR 0, el 128 pagina la ROM del intérprete, que es la del 48 modificada. Entonces ejecuta el RANDOMIZE USR 0 y empieza a ejecutar el código máquina a partir de la dirección 0, que lo que hace es el reset del ordenador. Como esta ROM es la del 48, se resetea como si fuera un Speccy 48, pero todo el tema de los buffers, los puertos para paginar y la AY están ahí, "sin desactivar", simplemente porque no se ha ejecutado el código que sirve para entrar en el modo 48 desde el menú.
-
- rst 0
- Mensajes: 41
- Registrado: Dom Ago 12, 2007 10:50 pm
- Ubicación: Murcia (España)
- Contactar:
En todo caso, puedo escribir cómodamente el código en modo 128, y después, tecleando SPECTRUM, pasar a modo 48, conservando el programa en memoria, y ejecutándolo a la velocidad de este. Me pregunto si los diseñadores estaban pensando en esto cuando añadieron este comando. ¿Alguien ve alguna otra razón?
El Spectrum no necesita ser actualizado cada equis años, y SIEMPRE es compatible consigo mismo (chúpate esa, BG).
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
-
- Nonamed
- Mensajes: 1067
- Registrado: Lun May 07, 2007 10:06 pm
Joer, es que el sistema de tokens con un teclado actual de tropecientas teclas es lo más rápido y eficiente del mundo. Lo que pasa es que en el 48 había que jugar al "enredos" con los dedos a veces.
Lo de los tokens ya no sólo era cuestión de velocidad, es un sistema fantástico para guardar el código, ya que practicamente no ocupa espacio.
A mi personalmente me encantaba el sistema de los tokens.
Lo de los tokens ya no sólo era cuestión de velocidad, es un sistema fantástico para guardar el código, ya que practicamente no ocupa espacio.
A mi personalmente me encantaba el sistema de los tokens.
Un saludo,
Gandulf
Gandulf
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
-
- Jack The Nipper
- Mensajes: 105
- Registrado: Vie May 11, 2007 1:08 am
Por lo que tengo entendido, aunque en modo 128 teclees las órdenes letra por letra, en la memoria se siguen almacenando como tokens (sino, muchos programas de Basic 48k no cabrían materialmente en la memoria de un 128k, lo cual sería, cuanto menos, bastante divertido )
Pero el ralentizamiento es un hecho obvio aunque no tuviera que ver con los tokens. Podemos hacer una comprobación precisa poniendo a cero la variable del sistema FRAMES, ejecutando cualquier cosa, y comprobando su valor a posteriori (y luego, claro, mirando la diferencia entre hacerlo en modo 48 y 128). Esto es una versión cutre-resumida de un temporizador que venía en un artículo sobre la velocida del Basic en la revista Input Sinclair nº 6.
10 POKE 23672,0:POKE 23673,0:POKE 23674,0
20 FOR X=1 TO 100:NEXT X
30 PRINT PEEK 23672 + 256 * PEEK 23673 + 65536 * PEEK 23674
Si en la linea 20 ponemos alguna actividad trivial, como un print o similar, la diferencia puede no existir o ser ignorable (de 1), pero a poco que ponemos algo un poco más "pesado" como, en este caso, contar hasta 100, ya sale una diferencia de 21 en modo 48 frente a 31 en modo 128 (el 21 y el 31 serían barridos de pantalla, que es lo que mide FRAMES)
Luego en 128, efectivamente, el Basic se toma una cantidad de tiempo apreciablemente mayor para realizar una misma tarea.
Ahora que no tengo ni la menor idea del motivo exacto ¿Podría tener algo que ver con que ciertas páginas de la memoria comparten su tiempo con los circuitos de video (citando la pag 200 del manual del +3) ?
--
Pero el ralentizamiento es un hecho obvio aunque no tuviera que ver con los tokens. Podemos hacer una comprobación precisa poniendo a cero la variable del sistema FRAMES, ejecutando cualquier cosa, y comprobando su valor a posteriori (y luego, claro, mirando la diferencia entre hacerlo en modo 48 y 128). Esto es una versión cutre-resumida de un temporizador que venía en un artículo sobre la velocida del Basic en la revista Input Sinclair nº 6.
10 POKE 23672,0:POKE 23673,0:POKE 23674,0
20 FOR X=1 TO 100:NEXT X
30 PRINT PEEK 23672 + 256 * PEEK 23673 + 65536 * PEEK 23674
Si en la linea 20 ponemos alguna actividad trivial, como un print o similar, la diferencia puede no existir o ser ignorable (de 1), pero a poco que ponemos algo un poco más "pesado" como, en este caso, contar hasta 100, ya sale una diferencia de 21 en modo 48 frente a 31 en modo 128 (el 21 y el 31 serían barridos de pantalla, que es lo que mide FRAMES)
Luego en 128, efectivamente, el Basic se toma una cantidad de tiempo apreciablemente mayor para realizar una misma tarea.
Ahora que no tengo ni la menor idea del motivo exacto ¿Podría tener algo que ver con que ciertas páginas de la memoria comparten su tiempo con los circuitos de video (citando la pag 200 del manual del +3) ?
--
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
Yo creo que es por lo que yo posteé más arriba:
Un PRINT se nota menos porque a fin de cuentas tarda "más" de forma relativa que las distintas partes que componen un FOR (incremento, comprobación, salto). Si cada instrucción tarda "un poquito más", la suma de esos poquitos de un FOR/NEXT será mayor que la de un simple PRINT.
Y sí, en memoria tanto en 48 como en 128 el programa se codifica por tokens. Por eso al cargar un programa con PLAY o SPECTRUM en modo 48 salen T y U en modo gráfico en vez de esas instrucciones y el programa da un "Nonsense in BASIC".
na_th_an escribió:Es por varias cosas:
1.- Hay que paginar para pasar de intérprete a editor.
2.- Al haber PLAY y SPECTRUM supongo que se produce un pequeño retardo al tener dos instrucciones más que codificar.
Básicamente la interrupción de BASIC hace más cosas.
Un PRINT se nota menos porque a fin de cuentas tarda "más" de forma relativa que las distintas partes que componen un FOR (incremento, comprobación, salto). Si cada instrucción tarda "un poquito más", la suma de esos poquitos de un FOR/NEXT será mayor que la de un simple PRINT.
Y sí, en memoria tanto en 48 como en 128 el programa se codifica por tokens. Por eso al cargar un programa con PLAY o SPECTRUM en modo 48 salen T y U en modo gráfico en vez de esas instrucciones y el programa da un "Nonsense in BASIC".
¿Quién está conectado?
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 8 invitados