Snake para 8086.
- Instrucciones para compilar:
Se debe tener el compilador bcc (Bruce's C compiler) instalado. No se puede
usar el gcc, ya que actualmente no tiene soporte para arquitecturas de x86
de 16 bits.
Usamos solo instrucciones de 16 bit para mantener compatibilidad hasta
el 8086. Cualquier procesador x86 en una pc IBM-compatible deberia correr
bien este programa. Ademas, las interrupciones de BIOS que se usaron estan
bastante estandarizadas.
En la carpeta con los fuentes, basta correr "make" para generar una imagen
booteable del juego "boot.img". Si se desea guardar en algun medio se puede
usar "dd if=boot.img of=/dev/x" donde x es el device que se desea grabar
(esto arruinará el sistema de archivos, asi que tener cuidado). Si se
cambia la variable DISKID en Makefile, se puede ejecutar "make burn" para
hacerlo automaticamente.
- Proceso de compilado y bootstrap
El Makefile compila automaticamente el bootloader y el codigo del juego.
Además, coteja que los tamaños de cada binario esten dentro de los limites.
El bootloader debe ser menor a 510 bytes (un sector menos 2 bytes de magia:
0x55aa). El tamaño del juego está solo acotado por la memoria disponible y
el disco de donde se esté corriendo, pero se debe tener alguna cota superior
para poder cargarlo todo en memoria. El bootloader carga 20 sectores (10kbyte)
a memoria, por lo tanto el Makefile chequea que el code.bin no exceda los 10k.
- Archivos fuente y generados:
boot.s: Prepara los segmentos y carga el resto del código a memoria,
luego salta al inicio, que es etiqueta "main" de code.s.
boot.o: objeto compilado de boot.s
boot.bin: Linkeado y sin headers.
code.s: Contiene el punto de entrada del juego y varias funciones
que cumplen el rol de primitivas para poder programar en C. Son,
en en general, wrappers a las interrupciones de BIOS.
lib.c: Algunas funciones auxiliares extra, escritas en C.
game.c: La logica del juego. Hace uso de las funciones de code.s
y lib.c.
lib.c: lib.c compilado, sin ".data".
game.s: game.c compilado, sin ".data".
code.bin: El codigo maquina generado por game.c, lib.c y code.s, sin
headers. Aqui se salta cuando el bootloader termina su preparacion.
Es cargado en la dirección 0x70000 (0x7000:0x0000)
boot.img: Archivo creado de unir boot.bin y code.bin. boot.bin se
encuentra en (a lo sumo) los primeros 510 bytes, y code.bin desde
el byte 512 en adelante. Esta disposicion es la que espera el
bootloader. Esto puede ser grabado en un disco.
- Misc
Al compilador le pasamos el flag "-x", para que no linkee con crt0.o,
que lleva a cabo la inicialización de la libreria estándar de C, y hace
que el código generado no sea booteable.
Algo a notar es que no hay separación entre el stack, text y data
segment, de hecho, en boot.s, los registros de segmentos ds, ss y cs
se setean al mismo valor (0x7000). Esto se debe a dos cosas:
1 - El stack crece de memoria alta a baja, por lo que deberia crecer
mucho para que la stack colisione con el texto. Esto no puede darse
en este caso particular ya que no hay tantas variables locales ni
recursión. Se podría haber elegido otro segmento, pero no es
necesario.
2 - La salida del compilador es pasada por sed para quitarle las
directivas ".data", para que las variables estáticas queden en el
segmento de texto, efectivamente mezclando ambos. Esto tiene la
consecuencia de que necesitamos tener cs y ds iguales durante toda
la ejecución.
Este truco de llevar el data segment al text segment tiene una
consecuencia: No puede haber variables estaticas sin inicializacion,
ya que el compilador usar una directiva ".comm" que reserva espacio
en el data segment. Se podría haber hecho un comando que cambie las
directivas ".comm" por tantas ".byte 0" como sean necesarias, pero
no vale la pena, es más fácil evitar las variables estáticas sin
inicializacion. Seguramente hay forma de separar ambos segmentos
y cargarlos en distintas direcciones de memoria, pero para un programa
asi de simple no es necesario.
Al linker (ld86) se le pasa el flag "-d", para que genere código
binario sin ningún header, que es lo que necesitamos ya que no hay
ningun SO que tenga que cargar el código. Simplemente se salta a él.
Notar que al compilador *no* le decimos que no linkee con su libreria
estándar. Esto ocurre por dos motivos:
1 - Por mas que no haya una llamada explicita a una funcion, el bcc
puede generar codigo que llame a su libreria estandar. Un ejemplo
es para manejar la multiplicacion de longs, donde llama a lmull.
2 - Mientras no usemos ninguna funcion, no hay problema en dejarla.
En main.c hay una variable llamada wait, y el compilador nos
advierte que esta opacando a wait() de la libreria estandar, pero
de nuevo, no hay problema.
- Controles:
Movimiento: WASD
Volver a jugar: Espacio
Cambiar velocidad: +, -
- Biblio:
http://wiki.osdev.org/Main_Page
http://mikeos.berlios.de/write-your-own-os.html
http://susam.in/articles/boot-sector-code/
http://joelgompert.com/OS/TableOfContents.htm
http://www.ctyme.com/intr/int.htm