Optmizació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? • D40p Test Suite
• Viabilidad de juegos clásicos en mercado actual • Introducción a HuC y Magic Kit
• Contexto histórico y competencia • Ejemplos de código
• Versiones y expansiones

• Descripción del funcionamiento de la parte • Suite D40p en PC Engine

gráfca del hardware DD • Problemas de implementación
• CRTs y señales • Bin Packing porblem
• Ciclo de un juego • P y NP
• Tiles y paletas • Soluciones
• Especifcaciones y comparatvas • 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
• Representatvo del hardware DD
• Presenta un caso que abarca varios niveles y formatos
• Los problemas analizados permiten explorar la modifcación
de herramientas (compilador/assembler)
• Permite explicar técnicas de optmizació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 fel
– Preferen comprar fsico
– Responde bien a prototpos para fnanciamiento
– Hay muy pocos lanzamientos anuales
 Kickstarters recientes
• Xenocrisis (Genesis) • FX Unit Yuki (PC Engine)
– Pidío: MX $5D5,636 – Pidío: MX$ 3D5,110
– Reunió: MX $1,907,D45 – Reunió: MX$ 699,304
– Backers: 1D89 – Backers: 511
– Promedio: MX $1480 – Promedio: MX $1370
– Dec 11 D017 - Jan 10 D018 – Sep 6 D016 - Oct 6 D016
– Salida: Octubre D018 – Salida: Abril D018

• Tanglewood (Genesis) • Tänzer (Genesis)

– Pidío: MX $5D5,636
– Pide: MX$ 44,470
– Reunió: MX $1,441,03D
– Lleva: MX$ 146,48D
– Backers: 89D
– Backers: 133
– Promedio: MX $1615
– Promedio: MX $1100
– Nov 1D D016 - Dec 18 D016
– May D6 D018 - Jun D6 D018
– Salida: Julio D018
– Salida: Febrero D019
D3 más para Genesis en D018, 11 SMS y 10 Dreamcast
Contexto histórico y competencia
 Introducción al PC Engine
• Desarrollada por Hudson Sof y NEC
• Lanzado en Japón el D0 de Octubre de 1987
• La consola más pequeña en el mercado
• Uso de HuCards
• Múltples expansiones y re-ediciones con los años
• Juegos ofciales publicados hasta 1995 (8 años de vida)
 Fechas
Atari D600 September 11, 1977
Intellivision 1979-1980
Pac-man May DD, 1980
Colecovision August 198D
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 IIIOctober D0, 1985
Famicom Disk System February D1, 1986
Sega Master System September 1986
PC Engine October 30, 1987
Mega Drive October D9, 1988
CD-ROMD December 4, 1988
Sega Genesis August 14, 1989
TurboGrafx 16 August D9, 1989
SuperGrafx December 8, 1989
Neo Geo April D6, 1990
Super Famicom November D1, 1990
Super Nintendo August D3, 1991
Super CD-ROMD October D6, 1991
Mega CD December 1D, 1991
Sega CD October 15, 199D
Arcade Card March 1D, 1994
Sega Saturn (Japan) November DD, 1994
Playstaton (Japan) December 1994
Sapphire D4 November 1995
Versiones y expansiones
Descripción del funcionamiento de la parte
gráfca del hardware DD
 CRTs y señales
• No hay frame bufer
• El video se codifca 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 defección es un anillo de
electroimánes que varía un campo
magnétco en horizontal y vertcal 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 defnidos
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 fujo de 60 fps con la mitad del ancho de banda
• El ojo fusiona ambas imágenes temporalmente
• Conocido como 480i, por las 480 líneas actvas
 D40p
• Un hack utlizado por computadoras caseras y consolas de video juegos (70s a D000s) 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 ofcialmente soportado por la asociación de broadcasters, pero fue siempre
compatble con SDTVs por la naturaleza de la señal.
• Ventajas:
– Evita el “ficker”
– Reduce la resolución vertcal 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 tempos por compatbilidad con TVs
• La señal se genera por el hardware de video en tempo real
• Por supuesto la velocidad del CPU es la que defne la cantdad 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.67ms
por cuadro, el juego se verá afectado según su manufactura:
– Correrá más lento
– Mostrará artefactos en la pantalla
– La respuesta será defciente
– Se perderá información entre el juego y el usuario.
 Tiempos por actvidad 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áfcos (acabando antes de
línea D0, 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 grafcos
Aún más carga de CPU o DMA:
• leer input
• Ejecutar lógica del juego
• calcular cambios grafcos
• VBLANK
• Si no hay cálculos pendientes:
• cambiar VRAM y tablas de sprites
• Si hay cálculos pendientes
• No actualizar gráfcos y contnuar (corre a 30 o menos FPS)
¿Cómo convertr las estructuras internas a video?
• Actualmente se usa un framebufer, es decir, una respresentación directa en
pixeles y sus defniciones de color que después se envían serialmente a la
pantalla (que también puede tener un frame bufer para procesamiento).
• La resoluciones internas de las consolas y PCBs arcade eran tpicamente
D56xDD4 o 3D0xDD4.
• Un framebufer o incluso memoria de video donde se podría almacenar una
imagen de esa resolución era impensable:
– D56 pixels x DD4 pixels x 8 bits de color = 56KB
– El NES cuenta con DKB de VRAM (Video RAM/Memoria de video)
– La tecnología exista, pero el costo era prohibitvo y esto no se veía ocmo un problema.
 “Resolución”
• La resolución horizontal en SDTV no está defnida en
pixeles, es una señal analógica que puede variar
tremendamente por la fuente. (Se suele digitalizar com 7D0
por estándar actual)
• En consolas la resolución de origen si está defnida.
• El CRT no tene pixeles
• En vertcal la resolución está bien defnida en líneas. NTSC
tene D4D y D43 líneas actvas por cada campo
 Tiles y paletas
• Los gráfcos se dividen en bloques, llamados tles o chars
• Cada tle es una matriz de pixeles, generalmente de 8x8 o 16x16
unidades
• Los pixeles no tenen un color defnido 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 defniciones
explícitas, llamados paletas
• Generalmente el primer color de cada paleta es transparente, lo
que permite fguras irregulares
Valores reales de un tle
y su paleta
Un concepto familiar
Otros ejemplos
 Ventajas de los tles
• La pantalla en memoria es una matriz de referencias a tles y a sus atributos como la paleta
• Por ejemplo 3DxD8 tles es D56xDD4
• Las paletas son generalmente de 16 colores, y un tle sólo puede tener colores de una paleta (no mezclar)
– Son de 16 colores pues D4 = 16, es decir se utliza medio byte (un nibble) por pixel.
• Este arreglo permite que una pantalla mida la suma de:
– La referencia (apuntador) al tle
– Sus atributos (paleta, dirección en pantalla)
• En PC Engine se usan 1D de referencia y 4 de paleta:
– la referencia en VRAM a una pantalla de D56xDD4: 179D bytes
– 16 paletas de color: 4KM (Color RAM/CRAM)
– Tiles en ROM (o RAM): 3D bytes cada una, esto varía con la complejidad de la imagen (de 3D bytes con uno solo y D8KB con
todos distntos)
• Ahorran mucho espacio
• Existen herramientas actuales para generar mapas de tles para desarrollo hoy en día, y las herramientas
homebrew pueden importar los datos de ellas para consolas clásicas
 Ventajas de los tles

Un nivel entero puede crearse con pocos tles

Mirroring y palete
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 tles 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 tles, a veces en un
formato ligeramente distnto
• Usan también paletas, en algunas consolas
comparidas con los fondos y en otras
completamente independientes
Especifcaciones y comparatvas
 PC Engine
• CPU HuC6D80
– 1.79 MHz o 7.16 MHz
– Derivado del 650D por Hudson
– Usado por Atari D600, NES, C64
– 6 canales de audio programables con ondas de 3D bytes
– 8KB RAM
– Bankswitching integrado
• HuC6D70 VDC (Video Display Processor)
– 16 bits
– 64KB VRAM
– 64 sprites (16 por línea)
• HuC6D60 VCE (Video Color Encoder)
– 16 paletas para fondos (8x8)
– 16 paletas para sprites (16x16)
– 51D color palete (48D max, 9 bit colors 3 bit per channel)
• Resolución
– 51DxD39/DD4
– 3D0xD39/DD4
– D56xD39/DD4
• Input
– 1 puerto para control + Multtap 5 controles
• Media
– HuCards (TurboChips) 1Mbit-8Mbit (1D8KB-1MB) / D0Mbit (D.5MB)
 Expansiones
• Super CD-ROM²
• CD-ROM²
– 19DKB RAM + 64KB RAM
– CD-ROM (650 MB)
– System Card 3.0
– 64KB RAM
– ADPCM, RAM
64KB • Arcade Card
– BRAM DKB – DMB RAM + D56KB RAM
– System Card 1.0 – System Card 3.0
 SuperGrafx
• 4x la RAM del PC Engine
– 3DKB vs 8KB
• D x HuC6D70 VDC
– Dos layers
– D x VRAM
• 1D8 KB vs 64 KB
– 1D8 Sprites
• 6 juegos
• Retrocompatble
 PC Engine vs NES
• CPU HuC6D80 • Ricoh DA03
– 1.79 MHz o 7.16 MHz – 1.79 MHz
– Derivado del 650D por Hudson
– Derivado del 650D por Ricoh /Nintendo
– 6 canales de audio programables con ondas de 3D bytes
– 8 KB RAM – NES APU com 5 canales, 4 fjos
– bankswitching Integrado – D KB RAM
• HuC6D70 VDC (Video Display Processor) • Rioch RPDC0D PPU (Picture Processing Unit)
– 16 bits – 8 bits
– 64 KB VRAM – D KB VRAM
– 64 sprites (16 por linea)
– 64 sprites (8 por linea)
• HuC6D60 VCE (Video Color Encoder)
– 16 paletas para fondos (8x8)
• HuC6D60 VCE (Video Color Encoder)
– 16 paletas para sprites (16x16) – 4 paletas total
– 51D colores (48D max en pantalla, 3 bits por canal) – 54 colores
• Resolución • Resolución
– 51DxD39/DD4 – D56xDD4
– 3D0xD39/DD4
• Input
– D56xD39/DD4
– D puertos para controles + Multtap 4 controles
• Input
– 1 puerto para control + multtap de 5 controles • Media
• Media – Cartuchos 16KB-40KB
– HuCards (TurboChips) 1D8KB-1MB – Mappers (expansiones) de RAM y ROM:
• SFII mapper: D.5MB – 1D8KB-1MB
 PC Engine vs Genesis
• CPU Motorola 68000
• CPU HuC6D80 – 7.61 MH
– 1.79 MHz o 7.16 MHz – 64 KB RAM
– Derivado del 650D por Hudson • Audio
– 6 canales de audio programables con ondas de 3D bytes – Sub CPU Z80 a 4Mhz (también usando en modo SMS)
– 8 KB RAM – PSG (TI 76489 chip)
– bankswitching Integrado – 8 KB RAM
• HuC6D70 VDC (Video Display Processor) – YMD016 (OPN) sonido FM de 6 canales stereo, uno de PCM
– 16 bits • VDP (Video Display Processor)
– 64 KB VRAM – 16 bits
– 64 sprites (16 por linea) – 64 KB VRAM
• HuC6D60 VCE (Video Color Encoder) – 80 sprites, D0 por scanline (8x8 a 3Dx3D)
– 16 paletas para fondos (8x8) – 3 planos. D con scroll
– 16 paletas para sprites (16x16) – 4 paletas de 16 colores
– 51D colores (48D max en pantalla, 3 bits por canal) – Manejo de DMA
• Resolución – 40–64 scrolling layers
– 51DxD39/DD4 – 51D colores (64 max en pantalla, 3 bits por canal)
– 3D0xD39/DD4 – Modo shadow/highlights que sube la paleta general a 1536 a costa de sprites
– D56xD39/DD4 • Resolución
• Input – 3D0xDD4
– 1 puerto para control + multtap de 5 controles – D56xDD4
• Media • Input
– HuCards (TurboChips) 1D8KB-1MB – D puertos para control + multtap de 4 controles
• SFII mapper: D.5MB
• Media
– Carts D56KB-4MB
• Extendable (Virtua Racing)
• 8 MB con mapper
 PC Engine vs SNES
• CPU HuC6D80 • CPU Nintendo custom '5ADD’ (clon de 65c816 )
– 1.79 MHz o 7.16 MHz – 1.79 Mh o 3.58 MHz
– Derivado del 650D por Hudson – Evolución del 650D, modo compatble
– 6 canales de audio programables con ondas de 3D bytes – 1D8 KB RAM
– 8 KB RAM • Nintendo S-SMP (Sony SPC700 CPU)
– bankswitching Integrado – 8 canales ADPCM , con echo reverberación y pitch
• HuC6D70 VDC (Video Display Processor) – 64 KB SRAM
– 16 bits – Muy similar al 650D
– 64 KB VRAM • PPU (Picture Processing Unit)
– 64 sprites (16 por linea) – 15 bits
• HuC6D60 VCE (Video Color Encoder) – 64 KB VRAM
– 16 paletas para fondos (8x8) – 1D8 sprites (3D por linea)
– 16 paletas para sprites (16x16) – 8 paletas para fondos (3Dx3D)
– 51D colores (48D max en pantalla, 3 bits por canal) – 8 paletas para sprites (16x16)
• Resolución – 3D,768 colores (D56 max en pantalla, 5 bits por canal)
– 51DxD39/DD4 – Alpha channel
– 3D0xD39/DD4 – Varios fondos dependiendo del modo y color. De 1 a 4.
– D56xD39/DD4 – Mode 7
• Input • Resolución
– 1 puerto para control + multtap de 5 controles – D56xD40/DD4
• Media • Input
– HuCards (TurboChips) 1D8KB-1MB – D puerto para control + multtap de 4 controles
• SFII mapper: D.5MB • Media
– Carts D56KB-4MB
• Extendable (SFX, MCU-1)
D40p Test Suite
Calibración de monitores y TVs
Evaluación de procesamiento de señales D40p por equipo
actual
 Ofrecer ejemplos open source
para programar en cada plataforma

• GPL 3
• Sourceforge/Github

• Sega Genesis/Mega Drive

• Sega CD/Mega CD Otros Ports:
• PC Engine/Turbografx-16 • NES
• Super Nintendo/Super Famicom • Neo Geo
• Sega Dreamcast • Playstaton
• Nintendo Gamecube • Gameboy
• Nintendo Wii
• Nintendo 64
• Sega Saturn
 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
• Permitr 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 HuC y Magic Kit
 HUC
• Compilador de “C” para PC Engine
• Codigo abierto en C y ensamblador de 650D
• Parte de MagicKit liberado en el D000
• Genera bloques en ensamblador para su procesamiento con PCEAS (PC Engine
Assembler, parte de MK)
• PCEAS permite importar grafcos, 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 functon declaratons, including return types and functon prototypes (
• struct and union support (adapted from SmallC-85)
• Typedef
• support for signed and unsigned scalars
• type castng
• void pointers
• preprocessor features:
– functon-like macros (i.e. macros with arguments)
– #if and #elif directves
• heap allocator (malloc() / free())
• C++-style comments
• support for functon calls in argument lists of fastcall functons (e.g. "memcpy(a, b, strlen(b) + 1);")
• support for interrupt handlers implemented in C
• support for more than one input fle
• added SuperGrafx and Arcade Card libraries by Tomaitheous
 HUC (Uli) vs C
• no support for initalizaton of:
– variable pointers
– pointers using array syntax
– arrays using string constants
• no passing or returning of structures by value (pointers work)
• no type castng to struct pointers
• no foatng point support
• no support for MinGW (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 tpico Hello World en pantalla
• La consola no tene Font, se tene que hacer como cualquier otro gráfco. HUC ya
proporciona rutnas básicas de impresión de texto y una font base, usando tles y
paletas del fondo.
• Funciones:
– load_default_font(): Carga la font defnida en HUC a VRAM
– set_color_rgb(int num, char r, char g, char b): Defne un color RGB (3 bits) en la paleta de colores
num (0 a 511)
– set_font_pal(char pal): Defne 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
tles en la pantalla.
– vsync(): Espera la señal VBL de sincronía vertcal
 Hello World con Font de la Suite
• Cambiar la font por la que usa la Suite D40p
• Pseudo Instrucciones de HUC
– #incchr(identier_name, "ilename"): Carga al arreglo identier_name todos
los tles que existan en el archivo PCX “flename”
• 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 (0x800) que
funciona por paletas ya mapeadas, y defne el número de caracteres en ella.
 Desplegar un fondo
• Mostrar como se puede desplegar un gráfco
• Pseudo Instrucciones de HUC:
– #incpal(identier_name, "ilename"): Genera el arreglo identier_name con los
datos de la paleta de colores del archivo PCX “ilename”l
– #incbat(identier_name, "ilename", pcx_ofset): Genera el arreglo identier_name
con un BAT (mapa de tles) del archivo PCX “ilename”l y le da formato para cargarse
de la dirección pcx_ofset en VRAM
• Funciones:
– load_background(char *gfx, int *pal, int *bat, char width, char height): Carga a la
dirección 0x1000 en VRAM arreglos de tles, paleta y BAT de dimensiones width y
height en unidades de tles para desplegarlos en el siguiente vsync.
 Leer el control y
mover un sprite
• Además de lo anterir, hacer fip del sprite
• Pseudo Instrucciones de HUC:
– #incspr(identier_name, "ilename"): Genera el arreglo identier_name con los tles de sprites 16x16 del archivo PCX “ilename”l
• Funciones:
– load_palete
– load_vram
– init_satb(): Inicializa la biblioteca de control de sprites de HUC
– spr_set(char num): Defne el indice del sprite a trabajar en las siguientes instrucciones
– spr_x(int value): Defne la posición horizontal del sprite en pantalla
– spr_y(int value): Defne la posición vertcal del sprite en pantalla
– spr_patern(int vaddr): Defne la dirección de VRAM donde se encuentran los tles 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): Defne la paleta a usar con lso tles del sprite
– spr_pri(char pri): Defne 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 (identier_name, "ilename"): Genera el arreglo identier_name con los datos binarios
del archivo “ilename”l
• 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 botom, char disp): defne una “ventana” de scroll
dada pro el rectangulo x, y, top, botom. 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átco y
caminando.
 Uso de ROM de la versión en HuCard de la suite
• La ROM de la Suite mide D56KB
• El HuC6D80 sólo puede acceder a 64 KB a la vez. Para poder tebner acceso a toda la memoria utliza un MMU (Memory
Managment Unit) que parte la memoria en páginas de 8KB:

Página 0 -> $0000-$1FFF

Página 1 -> $D000-$3FFF
Página D -> $4000-$5FFF
Página 3 -> $6000-$7FFF
Página 4 -> $8000-$9FFF
Página 5 -> $A000-$BFFF
Página 6 -> $C000-$DFFF
Página 7 -> $E000-$FFFF

• El CPU escribe a 8 registros llamados MPR0 a MPR7 para defnir cual segmento de los DMB de memoria disponibles “mapear” en
cada página.
• La versión en ROM de la suite por consecuencia se divide en 3D páginas.
 CD-ROM y Super CD-ROMD D

Cuando es posible, la Sauite D40p 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 fash cart,
 CD-ROMD
• La memoria es de 64KB
• Tendría que segmentar la Suite en overlays
• Los overlays son ejecutables independientes que se cargan a
memoria susttuyendo 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)
 Super CD-ROMD
• Super CD-ROMD utliza la System Card 3 o un
Turbo Duo.
• Cuenta con los 64 KB base del CD-ROMD y con 19D
KB extra.
• La memoria es contgua, para una suma de D56 KB
• No debería presentar problema alguno.
 Diferentes ejecutables, mismo código fuente
• Para facilitar el desarrollo, se decidió utlizar la estructura
#ifdef del preprocesador impementada por Uli en HUC.
• Para los brincos entre overlays, el ejecutable cambia pero
la RAM de sistema se mantene intacta. Se utliza un
archivo globals.h con variables globales que mantenen 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, tles, 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.
 De regreso a Super CD-ROMD

• El ISO (imagen ejecutable) creado para Super

CD-ROMD 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-ROMD 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 defne 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 ft in the current segment with
pre-existng code. I believe that it simply allocates a
new bank and places the code there, instead of
evaluatng the size of the empty spaces in previous
banks as candidates for placing the code.”
 Pasos a seguir
• Había que modifcar 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: \huc\src\
mkit\as\proc.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 relatva al
tamaño de su input.
• La notación que se utliza en ciencias computacionales es
O(n).
• O(n) es una función que describe la relación entre la
cantdad de datos a la entrada (n) y O que es el
crecimiento en complejidad (tempo) en dar un resultado
 Ejemplos
• O(1): signifca que siempre se ejecuta en el mismo
tempo (Espacio) sin importar la cantdad de datos

bool EsElPrimerElementoZero(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 ExisteElValor(int elementos[], int valor)

{
foreach (elemento in elementos)
{
if (elemento == valot)
return true;
}
return false;
}
 Ejemplos
• O(DN): 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 - D) + Fibonacci(numero - 1);
}
 Problemas P y NP
• P:
– Defnimos a los problemas P como aquellos que podemos resolver
en un tempo 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 tempo polinómico.
– Son problemas cuya solución podemos verifcar en un tempo
polinomico, pero se desconoce una solución óptma
 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
cantdad de granos en cada casilla, ¿cuántos granos
de arroz habría en el tablero al fnal?”
• 9 DD3 37D 036 854 775 808
 Bin packing
• Se tenen objetos de distntos volumenes que
deben ser empacados en un set fnito de
contenedores de volumen defnido de tal
manera que se minimice el número de
contenedores utlizado.
• El problema es NP
Solución e implementación
 Aproximaciones a la solución
• Una solución es no buscar el óptmo, sino un
compromiso.
• Algunos ejemplos son:
– First-ft (la que utlizaba pceas)
– First-ft decreasing (la que ahora utliza pceas)
– Full bin packing
 Otras optmzaciones
• READ THE DOCS!
• “For critcal variables, use global rather than local
variables. While thismay seem to defy logic, global
variables reside at a fxed memory locatonand can be
accessed directly (absolute addressing mode), whereas
automatc variables are on a special stack, and thus
references waste some extra cycles to evaluate its
memory locaton.”
Cambio en asignacion
usando código actual
Gracias por su tempo