Emulador de Sega Master System en Basic

[Hark0]

Viendo lo que hace @Jepalza con el Basic... y las posibilidades del lenguaje... como para ignorarlo

[na_th_an]

Con QuickBasic hubo varios GUIs, pero no un OS completo, ya que QB necesitaba MSDOS para muchas funciones (sobre todo para operar con archivos y para la gestión de memoria - el runtime no funcionaría sin MSDOS por debajo). Ahora bien, hubo GUIs para fliparlo en colores, con cantidad de funciones avanzadas.

Hace bastante tiempo desde que el pavo jactándose (y publicando) de un OS hecho en QBasic. Te estaré hablando de hace 10 años por lo menos... la ultima vez que tuve interés en QBasic/TurboBasic. De hasta que punto era acierto su afirmación o no, ya ahí no digo nada. Pero recuerdo que se podía meter ensamblador dentro del código de QBasic ... Con lo que es factible crear un OS y utilizar el MSDOS como lanzador.

QuickBasic (que no QBasic, QBasic sólo era el intérprete que venía con MSDOS) permitía enlazar con bibliotecas externas programadas en cualquier lenguaje, empaquetadas en archivos .LIB con los que enlazabas tu código a la hora del linkado. Siempre podías hacer todo tu programa en ensamblador o en C y luego linkarlo con un mínimo lanzador en BASIC, pero es que entonces tu programa no estaba en BASIC

Con QB no se podía hacer un OS por la simple razón de que para crear un simple array dinámico ya necesitaba hacer una llamada a MSDOS. No era algo que tú pudieses cambiar, estaba en el runtime. No es como C, que si quieres no usas nada y lo haces todo tú a bajo nivel, QB dependía de su runtime para casi todo.

El tema es que en la época mucha gente decía que estaba haciendo un OS en QB cuando en realidad sólo estaba haciendo una shell, o un GUI, o una combinación de ambas. Recuerdo que solía ser un tema espinoso en los foros de la época y que generaba increíbles peleas (muy divertidas, por cierto).

[jepalza]

Con QB no se podía hacer un OS por la simple razón de que para crear un simple array dinámico ya necesitaba hacer una llamada a MSDOS.

Había una forma de entrar en modo dinámico, desde MSDOS, no recuerdo cómo ahora, pero era algo como "qb /L:algo.LIB" que era parte del propio QB45, y luego, definías los array como dinámicos, y te dejaba pasar el límite famoso de 64k. Ese truco lo emplée docenas de veces para meter en memoria "burradas" de hasta un mega para la época, todo de golpe en la RAM.
Ademas, me gustaba usar librerías de terceros, para acelerar cosas, como detectar un ratón o generar sonidos "de verdad"... (qué tiempos!!!)

Edito: me ha venido al "coco" de golpe, se escribía "QB /AH" en MSDOS, y entrabas en modo "Array Huge", o sea, "grandes matrices"

[na_th_an]

Sí, eso era para permitirte usar arrays de más de 64K, con la contrapartida de que el código necesario para gestionarlas era más lento. Para hacer juegos lo mejor era pasar de /AH y organizarte mejor para que tus arrays fuesen de menos de 64K: la ganancia en velocidad era bastante acusada.

El uso de variables dinámicas no precisaba iniciar el compilador con ninguna opción especial, era algo que se permitía siempre. Para definir arrays dinámicas sólo había que preceder la declaración con un

Código: Seleccionar todo

'$DYNAMIC

Así, por ejemplo, podías crear las arrays en una función donde fueses a usarlas y luego liberar la memoria:

Código: Seleccionar todo

SUB miProcedimiento (a AS INTEGER)
   DIM miArray (2000) AS INTEGER
   ...
   ERASE miArray
END SUB

A lo que yo me refería es que ese "DIM miArray" producía una llamada al runtime de QB que, a su vez, llamaba a la función de MSDOS para reservar memoria. Lo ponía como ejemplo de que un ejecutable QB necesita MSDOS por debajo, por lo que no se puede hacer un OS en QB.

[jepalza]

Yo es que necesitaba por obligación pasar el límite de 64k. Eran programas dedicados a temas CAD/CAM, cuando pocos hacían aplicaciones para ese mundillo recién salido (hablo del año 90). Meter una figura de CAD completa en RAM era obligatorio, porque el trabajo desde el HD era muy lento para las complejas metamáticas que empleabamos. En RAM era todo 10 veces mas rápido, por eso lo de entrar con /AH.

Y pensar que hoy día, el FB se come un archivo de 32 megas en plis-plas.... qué cosas.

[Hark0]

Y pensar que cualquier icono ya ocupa la memoria de cualquier ordenador de los 80....

(Revista Viper, dos tios comentan/se lamentan que SOLO tienen 2kb de RAM... y que están esperando como agua de mayo la "ampliación" a 4kb... año 1978)

[zup]

Recuerdo que en Turbo Pascal y Turbo C podías sustituir prácticamente cualquier función de la runtime, con lo que (al menos en teoría) deberías poder sustituir el gestor de memoria de MS-DOS por el de tu propio sistema operativo. Hubo un Turbo Basic, pero no sé si tenía estas capacidades.

Ahora bien, si tenemos que escribir en ensamblador (o C) un montón de cachos de nuestro sistema operativo y luego las partes más genéricas ponerlas en BASIC... ¿hasta qué punto podríamos decir que nuestro sistema operativo está escrito en BASIC?