Optimizacin del compilador de PC Engine para su

Optimización del compilador de PC Engine para su uso en CD-ROM base Centro de Cultura Digital Artemio Urbina

Presentación de temario • • • Introducción ¿Por qué PC Engine? Viabilidad de juegos clásicos en mercado actual Contexto histórico y competencia Versiones y expansiones Descripción del funcionamiento de la parte gráfica del hardware 2 D CRTs y señales Ciclo de un juego Tiles y paletas Especificaciones y comparativas • • • 240 p Test Suite Introducción a Hu. C y Magic Kit Ejemplos de código • • • Suite 240 p en PC Engine Problemas de implementación Bin Packing porblem P y NP Soluciones Cambios al ensamblador

Resumen de Arquitectura Computacional • Conceptos básicos – Lógica y su relación con cómputo – Asignación de conceptos a valores numéricos – Solución de problemas vía manipulación digital – CPU, RAM, ROM – GPU/VDP/PPU

¿Por qué PC Engine? Herramientas disponibles Experiencia previa Representativo del hardware 2 D Presenta un caso que abarca varios niveles y formatos Los problemas analizados permiten explorar la modificación de herramientas (compilador/assembler) • Permite explicar técnicas de optimización de uso de recursos comunes de la época • • •

Viabilidad de juegos clásicos en mercado actual • Ventajas y desventajas de atacar un nicho – Es un mercado pequeño, pero fiel – Prefieren comprar físico – Responde bien a prototipos para financiamiento – Hay muy pocos lanzamientos anuales

Kickstarters recientes • Xenocrisis (Genesis) • Tanglewood (Genesis) • – – – Pidío: MX $525, 636 Reunió: MX $1, 907, 245 Backers: 1289 Promedio: MX $1480 Dec 11 2017 - Jan 10 2018 Salida: Octubre 2018 Pidío: MX $525, 636 Reunió: MX $1, 441, 032 Backers: 892 Promedio: MX $1615 Nov 12 2016 - Dec 18 2016 Salida: Julio 2018 FX Unit Yuki (PC Engine) – – – Pidío: MX$ 325, 110 Reunió: MX$ 699, 304 Backers: 511 Promedio: MX $1370 Sep 6 2016 - Oct 6 2016 Salida: Abril 2018 Tänzer (Genesis) – – – Pide: MX$ 44, 470 Lleva: MX$ 146, 482 Backers: 133 Promedio: MX $1100 May 26 2018 - Jun 26 2018 Salida: Febrero 2019 23 más para Genesis en 2018, 11 SMS y 10 Dreamcast

Contexto histórico y competencia

Introducción al PC Engine • • • Desarrollada por Hudson Soft y NEC Lanzado en Japón el 20 de Octubre de 1987 La consola más pequeña en el mercado Uso de Hu. Cards Múltiples expansiones y re-ediciones con los años Juegos oficiales publicados hasta 1995 (8 años de vida)

Fechas Atari 2600 September 11, 1977 Intellivision 1979 -1980 Pac-man May 22, 1980 Colecovision August 1982 Famicom July 15, 1983 ========= CRASH OF 1983 =========== Lode Runner July 31, 1984 Super Mario Bros September 13, 1985 Nintendo Entertainment System (NES) October 18, 1985 Sega Mark III October 20, 1985 Famicom Disk System February 21, 1986 Sega Master System September 1986 PC Engine October 30, 1987 Mega Drive October 29, 1988 CD-ROM 2 December 4, 1988 Sega Genesis August 14, 1989 Turbo. Grafx 16 August 29, 1989 Super. Grafx December 8, 1989 Neo Geo April 26, 1990 Super Famicom November 21, 1990 Super Nintendo August 23, 1991 Super CD-ROM 2 October 26, 1991 Mega CD December 12, 1991 Sega CD October 15, 1992 Arcade Card March 12, 1994 Sega Saturn (Japan) November 22, 1994 Playstation (Japan) December 1994 Sapphire 24 November 1995

Versiones y expansiones

Descripción del funcionamiento de la parte gráfica del hardware 2 D

CRTs y señales • No hay frame buffer • El video se codifica por variaciones en una señal analógica • NTSC – 59. 97 campos por segundo – Entrelazado – Creado en 1954

Funcionamiento del CRT • • • El acelerador de electrones los dispara hacia una pantalla de fósforo dentro de un tubo de vidrio al vacío. El yugo de deflección es un anillo de electroimánes que varía un campo magnético en horizontal y vertical para crear un barrido de electrones en el fósforo. El shadow mask (o aperture grill) permite que los electrones caigan sobre el fósforo con coloración RGB, y enfoca los haces de electrones a puntos bien definidos

Shadow mask y Aperture grill

Como se dibuja en un CRT Estructura secuencial de un campo (impar) Los cañones de electrones van variando intensidad y cada haz va a su color para ir pintando las triadas de puntos sobre el fósforo • Se dibujan 59. 97 campos por segundo en NTSC • un campo dura 16. 67 ms • una línea (scanline) dura 63. 64 us

Video entrelazado • Permite un flujo de 60 fps con la mitad del ancho de banda • El ojo fusiona ambas imágenes temporalmente • Conocido como 480 i, por las 480 líneas activas

• • 240 p Un hack utilizado por computadoras caseras y consolas de video juegos (70 s a 2000 s) para desplegar una señal progresiva en una TV casera. Consiste en mandar siempre el mismo campo (par o impar) al CRT, brincando la mitad de las líneas del fósforo. Nunca fue oficialmente soportado por la asociación de broadcasters, pero fue siempre compatible con SDTVs por la naturaleza de la señal. Ventajas: – Evita el “flicker” – Reduce la resolución vertical por la mitad – Es el culpable de las mal llamadas scanlines (son en realidad las scanlines no dibujadas del otro campo)

“Racing the beam” • Señales estrictas en tiempos por compatibilidad con TVs • La señal se genera por el hardware de video en tiempo real • Por supuesto la velocidad del CPU es la que define la cantidad de instrucciones que se pueden ejecutar entre cada cuadro. • Si la ejecución del juego es más lenta que el rayo de electrones, 16. 67 ms por cuadro, el juego se verá afectado según su manufactura: – – Correrá más lento Mostrará artefactos en la pantalla La respuesta será deficiente Se perderá información entre el juego y el usuario.

Tiempos por actividad al dibujar en el CRT con los electrones

Ciclo de un juego Ciclo ideal de ejecución a 60 cuadros por segundo: • • Esperar VBLANK leer input del jugador Ejecutar lógica del juego calcular y ejecutar cambios gráficos (acabando antes de línea 20, o primera visible)

Variaciones del ciclo Demasiados cálculos para el CPU o DMA: • • • VBLANK cambiar VRAM y tablas de sprites generadas durante el cuadro anterior leer input Ejecutar lógica del juego calcular cambios graficos Aún más carga de CPU o DMA: • • • leer input Ejecutar lógica del juego calcular cambios graficos VBLANK Si no hay cálculos pendientes: • cambiar VRAM y tablas de sprites Si hay cálculos pendientes • No actualizar gráficos y continuar (corre a 30 o menos FPS)

¿Cómo convertir las estructuras internas a video? • Actualmente se usa un framebuffer, es decir, una respresentación directa en pixeles y sus definiciones de color que después se envían serialmente a la pantalla (que también puede tener un frame buffer para procesamiento). • La resoluciones internas de las consolas y PCBs arcade eran típicamente 256 x 224 o 320 x 224. • Un framebuffer o incluso memoria de video donde se podría almacenar una imagen de esa resolución era impensable: – 256 pixels x 224 pixels x 8 bits de color = 56 KB – El NES cuenta con 2 KB de VRAM (Video RAM/Memoria de video) – La tecnología existía, pero el costo era prohibitivo y esto no se veía ocmo un problema.

“Resolución” • La resolución horizontal en SDTV no está definida en pixeles, es una señal analógica que puede variar tremendamente por la fuente. (Se suele digitalizar com 720 por estándar actual) • En consolas la resolución de origen si está definida. • El CRT no tiene pixeles • En vertical la resolución está bien definida en líneas. NTSC tiene 242 y 243 líneas activas por cada campo

Tiles y paletas • Los gráficos se dividen en bloques, llamados tiles o chars • Cada tile es una matriz de pixeles, generalmente de 8 x 8 o 16 x 16 unidades • Los pixeles no tienen un color definido explícitamente, en su lugar cuentan con la referencia a un color • Existe una o más tablas de colores con los índices y las definiciones explícitas, llamados paletas • Generalmente el primer color de cada paleta es transparente, lo que permite figuras irregulares

Valores reales de un tile y su paleta

Un concepto familiar

Otros ejemplos

Ventajas de los tiles • • • La pantalla en memoria es una matriz de referencias a tiles y a sus atributos como la paleta Por ejemplo 32 x 28 tiles es 256 x 224 Las paletas son generalmente de 16 colores, y un tile sólo puede tener colores de una paleta (no mezclar) – • Este arreglo permite que una pantalla mida la suma de: – – • La referencia (apuntador) al tile Sus atributos (paleta, dirección en pantalla) En PC Engine se usan 12 de referencia y 4 de paleta: – – – • • Son de 16 colores pues 2 4 = 16, es decir se utiliza medio byte (un nibble) por pixel. la referencia en VRAM a una pantalla de 256 x 224: 1792 bytes 16 paletas de color: 4 KM (Color RAM/CRAM) Tiles en ROM (o RAM): 32 bytes cada una, esto varía con la complejidad de la imagen (de 32 bytes con uno solo y 28 KB con todos distintos) Ahorran mucho espacio Existen herramientas actuales para generar mapas de tiles para desarrollo hoy en día, y las herramientas homebrew pueden importar los datos de ellas para consolas clásicas

Ventajas de los tiles Un nivel entero puede crearse con pocos tiles Mirroring y palette swap

HBLANK

Planos y scroll • Los planos o fondos (backgrounds) crean el escenario para el juego. Pueden estar conformados de una o más pantallas según VRAM • El hardware permite hacer scroll sobre el escenario, es decir ir mostrando una ventana móvil del mapa que se encuentra en memoria. • Se puede ir cargando el mapa (BAT) y/o los tiles en el área que no se está desplegando actualmente para ir construyendo un escenario muchas veces más grande.

Planos

Sprites • Los sprites son elementos que el hardware puede mover independientemente sobre los fondos • También están formados de tiles, a veces en un formato ligeramente distinto • Usan también paletas, en algunas consolas comparidas con los fondos y en otras completamente independientes

Especificaciones y comparativas

PC Engine • CPU Hu. C 6280 – – – • Hu. C 6270 VDC (Video Display Processor) – – – • 16 bits 64 KB VRAM 64 sprites (16 por línea) Hu. C 6260 VCE (Video Color Encoder) – – – • 1. 79 MHz o 7. 16 MHz Derivado del 6502 por Hudson Usado por Atari 2600, NES, C 64 6 canales de audio programables con ondas de 32 bytes 8 KB RAM Bankswitching integrado 16 paletas para fondos (8 x 8) 16 paletas para sprites (16 x 16) 512 color palette (482 max, 9 bit colors 3 bit per channel) Resolución – – – • Input • Media – – 512 x 239/224 320 x 239/224 256 x 239/224 1 puerto para control + Multitap 5 controles Hu. Cards (Turbo. Chips) 1 Mbit-8 Mbit (128 KB-1 MB) / 20 Mbit (2. 5 MB)

Expansiones • CD-ROM² – CD-ROM (650 MB) – 64 KB RAM – ADPCM, RAM 64 KB – BRAM 2 KB – System Card 1. 0 • Super CD-ROM² – 192 KB RAM + 64 KB RAM – System Card 3. 0 • Arcade Card – 2 MB RAM + 256 KB RAM – System Card 3. 0

Super. Grafx • 4 x la RAM del PC Engine – 32 KB vs 8 KB • 2 x Hu. C 6270 VDC – Dos layers – 2 x VRAM • 128 KB vs 64 KB – 128 Sprites • 6 juegos • Retrocompatible

PC Engine vs NES • CPU Hu. C 6280 • Hu. C 6270 VDC (Video Display Processor) • Hu. C 6260 VCE (Video Color Encoder) • – – – • 1. 79 MHz o 7. 16 MHz Derivado del 6502 por Hudson 6 canales de audio programables con ondas de 32 bytes 8 KB RAM bankswitching Integrado 16 bits 64 KB VRAM 64 sprites (16 por linea) 16 paletas para fondos (8 x 8) 16 paletas para sprites (16 x 16) 512 colores (482 max en pantalla, 3 bits por canal) Resolución – – – • Input • Media – – 512 x 239/224 320 x 239/224 256 x 239/224 1 puerto para control + multitap de 5 controles Hu. Cards (Turbo. Chips) 128 KB-1 MB • SFII mapper: 2. 5 MB • • • Ricoh 2 A 03 – 1. 79 MHz – Derivado del 6502 por Ricoh /Nintendo – NES APU com 5 canales, 4 fijos – 2 KB RAM Rioch RP 2 C 02 PPU (Picture Processing Unit) – 8 bits – 2 KB VRAM – 64 sprites (8 por linea) Hu. C 6260 VCE (Video Color Encoder) – 4 paletas total – 54 colores Resolución – 256 x 224 Input – 2 puertos para controles + Multitap 4 controles Media – Cartuchos 16 KB-40 KB – Mappers (expansiones) de RAM y ROM: – 128 KB-1 MB

PC Engine vs Genesis • • • Input – • • Media – • Hu. Cards (Turbo. Chips) 128 KB-1 MB • SFII mapper: 2. 5 MB Sub CPU Z 80 a 4 Mhz (también usando en modo SMS) PSG (TI 76489 chip) 8 KB RAM YM 2016 (OPN) sonido FM de 6 canales stereo, uno de PCM 16 bits 64 KB VRAM 80 sprites, 20 por scanline (8 x 8 a 32 x 32) 3 planos. 2 con scroll 4 paletas de 16 colores Manejo de DMA 40– 64 scrolling layers 512 colores (64 max en pantalla, 3 bits por canal) Modo shadow/highlights que sube la paleta general a 1536 a costa de sprites Resolución – – 1 puerto para control + multitap de 5 controles 7. 61 MH 64 KB RAM VDP (Video Display Processor) – – – – – 16 paletas para fondos (8 x 8) 16 paletas para sprites (16 x 16) 512 colores (482 max en pantalla, 3 bits por canal) 512 x 239/224 320 x 239/224 256 x 239/224 Audio – – Resolución – – – • 16 bits 64 KB VRAM 64 sprites (16 por linea) • Hu. C 6260 VCE (Video Color Encoder) – – – • 1. 79 MHz o 7. 16 MHz Derivado del 6502 por Hudson 6 canales de audio programables con ondas de 32 bytes 8 KB RAM bankswitching Integrado Hu. C 6270 VDC (Video Display Processor) – – – • – – CPU Hu. C 6280 – – – CPU Motorola 68000 • Input • Media – – 320 x 224 256 x 224 2 puertos para control + multitap de 4 controles Carts 256 KB-4 MB • • Extendable (Virtua Racing) 8 MB con mapper

PC Engine vs SNES • CPU Hu. C 6280 – – – • Input – • • Media – 512 x 239/224 320 x 239/224 256 x 239/224 1 puerto para control + multitap de 5 controles Hu. Cards (Turbo. Chips) 128 KB-1 MB • SFII mapper: 2. 5 MB 8 canales ADPCM , con echo reverberación y pitch 64 KB SRAM Muy similar al 6502 PPU (Picture Processing Unit) – – – – – 16 paletas para fondos (8 x 8) 16 paletas para sprites (16 x 16) 512 colores (482 max en pantalla, 3 bits por canal) 1. 79 Mh o 3. 58 MHz Evolución del 6502, modo compatible 128 KB RAM Nintendo S-SMP (Sony SPC 700 CPU) – – – Resolución – – – • • Hu. C 6260 VCE (Video Color Encoder) – – – • 16 bits 64 KB VRAM 64 sprites (16 por linea) CPU Nintendo custom '5 A 22’ (clon de 65 c 816 ) – – – Hu. C 6270 VDC (Video Display Processor) – – – • • 1. 79 MHz o 7. 16 MHz Derivado del 6502 por Hudson 6 canales de audio programables con ondas de 32 bytes 8 KB RAM bankswitching Integrado 15 bits 64 KB VRAM 128 sprites (32 por linea) 8 paletas para fondos (32 x 32) 8 paletas para sprites (16 x 16) 32, 768 colores (256 max en pantalla, 5 bits por canal) Alpha channel Varios fondos dependiendo del modo y color. De 1 a 4. Mode 7 • Resolución • Input • Media – – – 256 x 240/224 2 puerto para control + multitap de 4 controles Carts 256 KB-4 MB • Extendable (SFX, MCU-1)

240 p Test Suite

Calibración de monitores y TVs

Evaluación de procesamiento de señales 240 p por equipo actual

Ofrecer ejemplos open source para programar en cada plataforma • GPL 3 • Sourceforge/Github • • • Sega Genesis/Mega Drive Sega CD/Mega CD PC Engine/Turbografx-16 Super Nintendo/Super Famicom Sega Dreamcast Nintendo Gamecube Nintendo Wii Nintendo 64 Sega Saturn Otros Ports: • NES • Neo Geo • Playstation • Gameboy

Requerimientos para un port de la suite en una plataforma • SDK Open source/Homebrew • Poder correr homebrew en el hardware • Tener acceso al hardware para pruebas reales • Manejo de fondos • Permitir Scroll • Uso de control • Sprites • Audio Básico • Poder desplegar Texto con font custom • Soportar las resoluciones de la plataforma • Funcionar al máximo frame rate de la plataforma

Introducción a Hu. C y Magic Kit

HUC Compilador de “C” para PC Engine Codigo abierto en C y ensamblador de 6502 Parte de Magic. Kit liberado en el 2000 Genera bloques en ensamblador para su procesamiento con PCEAS (PC Engine Assembler, parte de MK) • PCEAS permite importar graficos, mapas y paletas en formato PCX y FMP • Cuenta con biblioteca de manejo de hardware • • – – Sprites Fondos y scroll Controles PSG

HUC (Uli Branch) • • ANSI-style function declarations, including return types and function prototypes ( struct and union support (adapted from Small. C-85) Typedef support for signed and unsigned scalars type casting void pointers preprocessor features: – – • • • function-like macros (i. e. macros with arguments) #if and #elif directives heap allocator (malloc() / free()) C++-style comments support for function calls in argument lists of fastcall functions (e. g. "memcpy(a, b, strlen(b) + 1); ") support for interrupt handlers implemented in C support for more than one input file added Super. Grafx and Arcade Card libraries by Tomaitheous

HUC (Uli) vs C • no support for initialization of: – variable pointers – pointers using array syntax – arrays using string constants • • no passing or returning of structures by value (pointers work) no type casting to struct pointers no floating point support no support for Min. GW (Windows users are recommended to use Cygwin)

Uso de HUC y pceas • HUC se puede usar directamente sobre el archivo . c y genera la ROM en formato PCE con header – Se puede invocar con –s para no invocar al ensamblador • Pceas – puede generar la ROM sin header con la opción –raw – La opción –s muestra el uso de segmentos en la ROM

Hello World • Mostrar el típico Hello World en pantalla • La consola no tiene Font, se tiene que hacer como cualquier otro gráfico. HUC ya proporciona rutinas básicas de impresión de texto y una font base, usando tiles y paletas del fondo. • Funciones: – load_default_font(): Carga la font definida en HUC a VRAM – set_color_rgb(int num, char r, char g, char b): Define un color RGB (3 bits) en la paleta de colores num (0 a 511) – set_font_pal(char pal): Define la paleta a usar con la Font (0 -15) – put_string(char *string, char x, char y): Imprime una cadena de texto en las coordenadas X, Y de tiles en la pantalla. – vsync(): Espera la señal VBL de sincronía vertical

Hello World con Font de la Suite • Cambiar la font por la que usa la Suite 240 p • Pseudo Instrucciones de HUC – #incchr(identifier_name, "filename"): Carga al arreglo identifier_name todos los tiles que existan en el archivo PCX “filename” • Funciones – set_color(int num, int rgb): Al igual que set_color_rgb, cambia el color pero toma el valor RGB en un sólo entero. – load_font(char *font, char nb_char): Carga una font a VRAM (0 x 800) que funciona por paletas ya mapeadas, y define el número de caracteres en ella.

Desplegar un fondo • Mostrar como se puede desplegar un gráfico • Pseudo Instrucciones de HUC: – #incpal(identifier_name, "filename"): Genera el arreglo identifier_name con los datos de la paleta de colores del archivo PCX “filename” – #incbat(identifier_name, "filename", pcx_offset): Genera el arreglo identifier_name con un BAT (mapa de tiles) del archivo PCX “filename” y le da formato para cargarse de la dirección pcx_offset en VRAM • Funciones: – load_background(char *gfx, int *pal, int *bat, char width, char height): Carga a la dirección 0 x 1000 en VRAM arreglos de tiles, paleta y BAT de dimensiones width y height en unidades de tiles para desplegarlos en el siguiente vsync.

• • Leer el control y mover un sprite Además de lo anterir, hacer flip del sprite Pseudo Instrucciones de HUC: – • #incspr(identifier_name, "filename"): Genera el arreglo identifier_name con los tiles de sprites 16 x 16 del archivo PCX “filename” Funciones: – – – load_palette load_vram init_satb(): Inicializa la biblioteca de control de sprites de HUC spr_set(char num): Define el indice del sprite a trabajar en las siguientes instrucciones spr_x(int value): Define la posición horizontal del sprite en pantalla spr_y(int value): Define la posición vertical del sprite en pantalla spr_pattern(int vaddr): Define la dirección de VRAM donde se encuentran los tiles del sprite spr_ctrl(char mask, char value): permite cambiar lso atributos de orientación y tamaño de un sprite spr_pal(char pal): Define la paleta a usar con lso tiles del sprite spr_pri(char pri): Define si el sprite va delante o detrás del fondo. satb_update(): hace una copia de todos los valores en la biblioteca hacia el Hardware del PC Engine. joy(char num): regresa el estado del control num

• • Animar un sprite y hacer scroll Realizar una animación simple cambiando los valores de VRAM Mostrar el scroll por bloques Mostrar la animación por cambio de paletas Pseudo Instrucciones de HUC: – #incbin (identifier_name, "filename"): Genera el arreglo identifier_name con los datos binarios del archivo “filename” • Funciones: – joytrg(char num): regresa sólo los cambios al estado del control num con respecto al cuadro anterior. – scroll(char num, int x, int y, char top, char bottom, char disp): define una “ventana” de scroll dada pro el rectangulo x, y, top, bottom. Disp es una mascara para mostrar srpites, fondos o ninguno.

Agregar salto y ataque • Mostrar una máquina de estados sencilla, para cambiar entre salto, caida, ataque, estático y caminando.

• • Uso de ROM de la versión en Hu. Card de la suite La ROM de la Suite mide 256 KB El Hu. C 6280 sólo puede acceder a 64 KB a la vez. Para poder tebner acceso a toda la memoria utiliza un MMU (Memory Managment Unit) que parte la memoria en páginas de 8 KB: Página 0 -> $0000 -$1 FFF Página 1 -> $2000 -$3 FFF Página 2 -> $4000 -$5 FFF Página 3 -> $6000 -$7 FFF Página 4 -> $8000 -$9 FFF Página 5 -> $A 000 -$BFFF Página 6 -> $C 000 -$DFFF Página 7 -> $E 000 -$FFFF • • El CPU escribe a 8 registros llamados MPR 0 a MPR 7 para definir cual segmento de los 2 MB de memoria disponibles “mapear” en cada página. La versión en ROM de la suite por consecuencia se divide en 32 páginas.

CD-ROM 2 y Super CD-ROM 2 Cuando es posible, la Sauite 240 p se libera también en CD-ROM, pues debido a la fata de protección de muchas consolas de la época resulta muy accesible a comparación de un flash cart,

2 CD-ROM • La memoria es de 64 KB • Tendría que segmentar la Suite en overlays • Los overlays son ejecutables independientes que se cargan a memoria sustituyendo al ejecutable anterior. • El primer paso sería crear segmentos lógicos con partes de la suite para tener algo funcional con el menor loading posible • El problema era laborioso, pero técnicamente parecía no presentar problemas (fueron sencillos)

2 Super CD-ROM • Super CD-ROM 2 utiliza la System Card 3 o un Turbo Duo. • Cuenta con los 64 KB base del CD-ROM 2 y con 192 KB extra. • La memoria es contigua, para una suma de 256 KB • No debería presentar problema alguno.

Diferentes ejecutables, mismo código fuente • Para facilitar el desarrollo, se decidió utilizar la estructura #ifdef del preprocesador impementada por Uli en HUC. • Para los brincos entre overlays, el ejecutable cambia pero la RAM de sistema se mantiene intacta. Se utiliza un archivo globals. h con variables globales que mantienen su s direcciones de memoria en RAM para mantener el contexto general de la aplicación y pasar parámetros entre ejecutables

Pceas y la asignación de bancos • PCEAS y HUC hacen transparente el manejo de bancos mencionado anteriormente • La asignación de bancos la realiza pceas tomando un elemento (función, BAT, tiles, paletas, elemento binario, etc) y asignando la siguiente dirección disponible en caso de caber en el banco actual. • Si el elemento no cabe en la página actual, se abre un banco nuevo.

2 De regreso a Super CD-ROM • El ISO (imagen ejecutable) creado para Super CD-ROM 2 del mismo código fuente de la ROM no funcionó ni en hardware ni en emulación.

El problema • Todos los juegos para Super CD-ROM 2 cuentan con un pequeño ejecutable, un overlay que ocupa los primeros 64 KB, para avisar al usuario que necesita una System Card 3. 0 ejecutándose en una versión anterior. • Existe código que revisa esto, y define hacia cuál overlay bootear. • Eso ocupa espacio, y de por si cuando descubrí esto la suite aún no estaba terminada. • Pceas estaba creando una página nueva que excedía e tamaño disponible.

Read the DOCs “NOTE: a weakness of the current assembler is that it leaves too much empty space in segments when a. proc/. endp will not fit in the current segment with pre-existing code. I believe that it simply allocates a new bank and places the code there, instead of evaluating the size of the empty spaces in previous banks as candidates for placing the code. ”

Pasos a seguir • Había que modificar el ensamblador para que aprovechara el espacio desperdiciado • El primer paso fue detectar en que parte del código se hacía, por fortuna de código fuente abierto: hucsrcmkitasproc. c • El siguiente paso siguió de pensar: “es un problema común, seguramente alguien ya ha resuelto algo similar y será implementar un algoritmo bien estudiado.

Bin packing problem

Complejidad computacional • La velocidad de un algoritmo, o un pedazo de código, se mide por la forma en la que crece de manera relativa al tamaño de su input. • La notación que se utiliza en ciencias computacionales es O(n). • O(n) es una función que describe la relación entre la cantidad de datos a la entrada (n) y O que es el crecimiento en complejidad (tiempo) en dar un resultado

Ejemplos • O(1): significa que siempre se ejecuta en el mismo tiempo (Espacio) sin importar la cantidad de datos bool Es. El. Primer. Elemento. Zero(int elementos[]) { return elements[0] == 0; }

Ejemplos • • O(N): Es un algorimo que crece de la misma manera que el tamaño de la entrada. Cabe resaltar que se mide con respecto al peor caso bool Existe. El. Valor(int elementos[], int valor) { foreach (elemento in elementos) { if (elemento == valot) return true; } return false; }

Ejemplos • O(2 N): Son algoritmos cuya crecimiento de complejidad se duplica con cada elemento nuevo. Es decir es una curva exponencial. int Fibonacci(int numero) { if (numero <= 1) return numero; return Fibonacci(numero - 2) + Fibonacci(numero - 1); }

Problemas P y NP • P: – Definimos a los problemas P como aquellos que podemos resolver en un tiempo polinómico. Es decir, cuyo crecimiento en complejidad está bajo la curva de una expresión polinomial – Son los problemas fáciles de resolver para una computadora. • NP: – Son aquellos que no podemos resolver en un tiempo polinómico. – Son problemas cuya solución podemos verificar en un tiempo polinomico, pero se desconoce una solución óptima

Ejemplo de crecimiento exponencial • “Si se colocase sobre un tablero de ahjedrez un grano de arroz en el primer casillero, dos en el segundo, cuatro en el tercero y así sucesivamente, doblando la cantidad de granos en cada casilla, ¿cuántos granos de arroz habría en el tablero al final? ” • 9 223 372 036 854 775 808

Bin packing • Se tienen objetos de distintos volumenes que deben ser empacados en un set finito de contenedores de volumen definido de tal manera que se minimice el número de contenedores utilizado. • El problema es NP

Solución e implementación

Aproximaciones a la solución • Una solución es no buscar el óptimo, sino un compromiso. • Algunos ejemplos son: – First-fit (la que utilizaba pceas) – First-fit decreasing (la que ahora utiliza pceas) – Full bin packing

Otras optimzaciones • READ THE DOCS! • “For critical variables, use global rather than local variables. While thismay seem to defy logic, global variables reside at a fixed memory locationand can be accessed directly (absolute addressing mode), whereas automatic variables are on a special stack, and thus references waste some extra cycles to evaluate its memory location. ”

Cambio en asignacion usando código actual

Gracias por su tiempo