Tech/Geek/Craft

El hombre pobre

Hace unos días fue en mi antigua uni ( la de Alicante ) el examen de la asignatura de Periféricos de mi antigua carrera (Ing.Tec. Informática de Sistemas). Dicha asignatura tiene fama (con razón) de ser la muerte en persona: la teoría es bastante amplia y abundante, y las prácticas son... bueno, muy bonitas con su C a bajo nivel y demás. Por suerte para mí, el año pasado la aprobé a la primera (en una convocatoria "asequible" en la que aprobamos 20 de 170), pero muchos de mis ex-compañeros siguen cargando con ella... desde hace varios años.

Sé (por experiencia xD) que la gente se presenta a este examen sin ganas (porque el porcentaje de aprobados no es muy halagüeño) pero con cierta esperanza en que caiga algo de lo que suele pedir (interrupciones, fragmentación, pantallas...). Eso sí, todo teórico (para contárselo "en prosa" según sus palabras). O como mucho, como en los últimos años, con un problema de demostrar cosas que nadie conseguía nunca hacer.

Pero, hace unos días, el profesor rompió en miles de brillantes pedacitos todas las esperanzas de aprobar de sus alumnos, esos alumnos que habían estudiado decenas de horas cantidades ingentes de teoría de Periféricos. ¿Cómo? Pues no sólo hizo que el examen de prácticas (programación de interrupciones mayormente) fuera a base de papel y boli, sino que encima puso un examen infernal de nada más y nada menos que 5 (¡cinco!) problemas y sólo 2 tristes preguntillas de teoría.  Yo lo he visto y me he quedado transpuesta....

(imagen por cortesía del ex-mangarrufo Krone.  ¡Regresad, malditos!)

Pero después del susto, hay una cosa que me encanta: el segundo problema. Visto así, en frío, no tiene gracia. Pero es que tiene su historia, es uno de esos problemas que se vuelven recurrentes en los exámenes. Una vez, hace varios años, este señor puso en un examen un problema que era algo así:

"Un hombre es tan pobre que sólo puede comprarse un disco duro con dos pistas, de parámetros tal y cual. Calcula el tiempo de latencia"

No recuerdo exactamente qué pedía calcular, pero el enunciado era similar a eso. Por lo visto, nadie o casi nadie supo resolverlo, así qiue el curso siguiente lo comentó y resolvió en clase. Y en la convocatoria de ese año, se sacó otro problema de la manga:

"Al hombre pobre se le ha estropeado su disco duro y no puede comprarse otro. Ahora, entre lectura y lectura el cabezal salta aleatoriamente de pista a pista. En cambio el proceso de lectura lo hace bien. Calcula el tiempo medio de acceso".

Pero no quedó ahí  la cosa, no. El hombre pobre comenzaba a ser conocido entre los alumnos y, como no podía ser de otra manera, volvió a hacer acto de presencia varios meses después:

"A perro flaco, todo son pulgas. En efecto, ayer vino a visitarme al despacho el hombre pobre cuyo disco hemos considerado en otras ocasiones. Su funcionamiento es cada vez más defectuoso. Ahora, el motor gira tan lento que el tiempo de pista a pista es despreciable en comparación con el tiempo de latencia. Además, algo hay suelto por dentro de forma que cuando el cabezal se sitúa sobre una de las pistas algo roza en el borde del disco y lo enlentece aún más. En resumen: nuestro amigo tiene un disco con dos pistas. Una pista tiene x sectores y cuando el cabezal se encuentra sobre ella el disco gira con velocidad angular w1. La otra tiene y sectores y cuando el cabezal se encuentra sobre ella el disco gira con velocidad angular w2. Demostrar que en estas condiciones el tiempo medio de acceso a los sectores es t= pi/(x+y)^2 [ x^2/w1 + y^2/w2 + xy(1/w1 + 2/w2)]"

Wooohooww!! El hombre pobre ha dejado de dar lástima y se ha convertido en un ser totalmente odioso...  ¿Por qué no hacer una colecta para comprarle un nuevo disco y desterrarlo para siempre de estos exámenes? Pues por ahí va el tema, porque no sólo deja de ser pobre sino que encima pasa de los problemas de discos duros a los de colas!  Ahora sí, ¡go panic!

Llevad cuidado y para la próxima convocatoria miraros bien el tema de óptica,
que ahora que ya no es pobre se puede comprar un disco holográfico :P

Dicho todo esto, tengo que decir que es la asignatura que más me gustó de toda la carrera :P Disfruté muchísimo con ella (sufrimiento y lágrimas de sangre incluídos) y con su combo de historia, teoría, problemas y programación "esotérica" jejeje. ¡Ánimo chicos! ¡Vosotros podeis!

(Y siempre SIEMPRE recordaré el sms mañanero con el que me despertó Mortizer con la buena noticia de nuestros aprobados =^_^= )

Montaje Electrónico

Martes, 8 de la mañana.  Clase de Electrónica. Yo luchando contra el sueño. Profesor comentando un circuito, con tiristores y diodos, al que se refiere como "este montaje". El mensaje llega a mi cabeza. No del modo esperado. Se crea un monstruo. No me mateis, por favor, ya sabeis que como en otras ocasiones, tenía que hacerlo.

 

Vale, pues ahora que ya lo he hecho, por fin voy a poder estudiar en paz. Porque era ver los múltiples libros de la asignatura rondando por la habitación y algo se removía en mi interior clamando por salir xD

Humor ETSIIero

Qué bonitas son las vacaciones... haciendo comparativas de modems submarinos, haciendo zumo mi cerebro con la cinemática de brazos robot... lo típico, vaya.  Con tanto trabajo, no podía dejar de recordar este video, que me pusieron unos compañeros de clase al poco de estar en la UPV  (por si alguien se perdió esos posts, terminé Informática de Sistema en la UA, y ahora estoy en el segundo ciclo de Ingeniería Automática (de la Escuela de Industriales)  en la UPV)

Explicación para los que no saben de qué va el tema, por orden de aparición:

El protagonista es un profesor de Física al que todos llaman "El Hitler"  (no quiero saber por qué). A mí no me ha dado clases y tampoco creo que lo haga, pero es famoso en Industriales entero por ser, digamos, "muy exigente".

Con "las locomotoras" se refiere a unas cuantas locomotoras antiguas que hay puestas en un jardincillo de la Escuela de Industriales. Se pueden ver en Google Maps (coordenadas 39.482221, -0.342611 y metedle zoom).  El tal Juliá al que se menciona un par de veces es el rector de la UPV, y "los de Caminos", es un supuesto pique que hay por cual de las dos escuelas es la más cool de la  UPV.  Lo demás creo que se autoexplica...   (Por cierto, el video está sacado de la peli El Hundimiento, y si no la habeis visto, estais tardando)

Por cierto (y van 2 xD), en el blog del que saqué esto, PolideformaT*, también había una selección de hechos físico-matemáticos  (I y II) de este señor al más puro estilo Chuck Norris facts. Destacaré algunos:

• Manglano no deriva, Manglano desintegra.
• En los exámenes de física de Manglano, la respuesta a todas las preguntas fue “Integración”. Por supuesto obtuvo un 10: Para Manglano la integración es la solución a todos los problemas.
• Manglano obtuvo la determinante de una matriz m x n x p x q x r x s x t x u.
• Manglano puede dibujar un polígono con 2 lados.
• Los ángulos de un triángulo hecho por Manglano suman más de 180 grados. De hecho pueden medir lo que él quiera.
• Manglano es capaz de sacar un 2 en un sistema binario.
• Manglano arrancó la otra cara de la Banda de Moebius tras beberse el líquido que había en la Botella de Klein.
• Manglano robó el margen del cuaderno de Fermat.
• Manglanole sugirió a Riemman su hipótesis, pero nunca le dijo la solución.
• Schrödinger utilizo a Manglano para demostrar su paradoja, pero finalmente utilizo un gato porque al abrir la caja Manglano siempre vivia y no había rastro de los demás elementos.
• Para integrar, Manglano hace infinitas sumas diferenciales. Una a una.
• Manglano es capaz de hacer pasar una sola recta por 3 puntos cualesquiera del Universo.
• Todos los números primos son divisibles por sí mismos, por la unidad y por Manglano.
• Manglano puede expresar los números irracionales en forma de fracción.

 

* PolideformaT: parodia de PoliformaT

CAVE + MoCap en la UPV

Hace unas semanas, el señor Mephisto me comentaba cosas atractivas sobre algo muy interesante: la CAVE que hay en la UPV. Nunca había oído hablar sobre ello, y en ese momento me pareció una frikada de excepción, y cuánto más escuchaba, más ganas me daban de verlo con mis propios ojos.

CAVE (Cave Automatic Virtual Envirnment)

La CAVE de la UPV (situada en la Ciudad Politécnica de la Innovación, edificio 8G) es una sala con forma de cubo en la que se proyecta cualquier simulación gráfica en cuatro pantallas (dos laterales, una frontal y el suelo), con la idea de sumergir al espectador (¿o deberíamos decir actor?) en el escenario mediante el uso de unas gafas especiales que le permiten observar la proyección en 3 dimensiones. Además el ángulo de visión del usuario se corrige modificando la perspectiva, calculada a partir de su posición (captada por las cámaras).  Las imágenes son proyectadas hacia unos espejos que enfocan a las paredes, que son translúcidas. Es decir, que la imagen que puede verse en las paredes se proyecta desde fuera (esto no ocurre así en el suelo, donde es proyección directa). Como dato curioso, la máquina que mueve toda la parte "gráfica" de esta CAVE es un animalito de 16 procesadores y 16 GB de RAM, sobre la que corre una versión especial de SuSe.

MoCap (Motion Capture)

El MoCap (o "captura de movimiento" en castellano) es un sistema que permite almacenar movimientos digitalmente. En la sala de MoCap que hay en la UPV (no sé exactamente dónde, pero supongo que también en el edificio 8G u 8H) se dispone de 8 cámaras y 2 trajes con 25 bolas, que permiten grabar animaciones para videojuegos y/o cortos, con hasta dos personas interactuando a la vez.

II Semana del Videojuego UPV

La próxima semana se celebra en la UPV la II Semana del Videojuego. ¿Y en qué afecta a todo lo anterior? Pues que, entre otros eventos y con motivo de esta semana, se harán visitas tanto a la CAVE (jueves 11 por la mañana) como a la MoCap (viernes 12). La parte mala es que sólo había 30 invitaciones/entradas (gratuitas, por supuesto) para cada lugar, y todas están agotadas :( Eso sí, también decían que intentarían formar más grupos si se agotaban.

Y digo yo...¿alguien se apuntaría a venir conmigo si sacan más plazas? ¡Seguro que es super interesante!

Ensalada de enlaces:

- Visionarium UPV

- II Semana del Videojuego

- MOCAP y CAVE, en ACUV

- Centro de Visualización de la UPV

- Entradas MOCAP

- Entradas CAVE

Patapon

He tardado un montonazo, pero  por fin puedo  decir que he terminado con el Patapon, que es el juego que venía por defecto cuando me regalaron la PSP :)

El juego en sí es bastante repetitivo, y estoy segura que mucha gente ha acabado odiándolo por ello. La historia y el modo de juego son muy simples: la tribu de los Patapon  (esa especie de ojos con patas) está en guerra con otra tribu (que son iguales pero de color rojo). Tú eres el Ser Supremo, y tienes que guiarlos en su lucha. ¿Cómo? Pues muy fácil: cada botón de tu PSP es un tambor: el triángulo es Chaka, el cuadrado es Pon, la X es Don, y el círculo es Pata. Y dependiendo del patrón, tus patapons harán una cosa u otra. Por ejemplo, pata-pata-pata-pon hace que avancen, con pon-pon-pata-pon atacan al enemigo, con chaka-chaka-pata-pon se cubren...  y así hasta seis movimientos posibles. Eso sí, ¡hay que hacerlo al ritmo de la música!

Además, hay varios tipos de guerreros: infantería, caballería, arqueros..., de manera que según contra qué enemigo se estén enfrentando será más eficiente usar unos u otros. También hay distintos tipos de armas y cascos, y "estofados" que se usan como potenciadores. Además, aparte del juego normal, hay varios minijuegos extremadamente monos que  hacen que tus patapons obtengan los elementos necesarios para crear nuevas armas o guerreros.

A parte de lo gracioso que es (el final es la muerte) creo que lo más destacable son los gráficos: simples y elegantes, oscurillos pero carismáticos. Y si no lo creeis, echad un ojo en google. Otra de las cosas que más me han gustado es que puedes volver a pantallas anteriores, por ejemplo, para luchar contra jefes que ya venciste y hacer más fuerte tu ejército. Incluso después de haber terminado con el final boss todavía me apetece darle caña a algunos intermedios :)

En fin, que estoy deseando hacerme con la segunda parte de este juego :)

Ubuntu Karmic Koala

Con mi clásico efecto retardado y demás, por fin me decidí a actualizar a Ubuntu Karmic Koala. En realidad pensaba esperar a la 10.04, que será LTS, para hacer una instalación limpia y decente... pero estaba aburrida y tenía una conexión a internet....

Además, mi vieja Jaunty Jackalope que empezó funcionando bastante decentemente se había convertido en un maremagnun de comportamientos erráticos: tardaba más de 5 minutos en encenderse, la mitad de los procesos eran incapaces de finalizar por sí mismos... vamos, que se hacía un poco odiable trabajar con ella. Por suerte o por desgracia, en el 90% de mi tiempo de mi tiempo "productivo" de estos meses he necesitado usar programas muy concretos que sólo tiran en Windows (Solidworks, Quartus II...) así que tampoco es que lo haya notado mucho.

De momento estoy feliz con Karmic en un porcentaje bastante decente: ahora carga a velocidad record (en unos segundos), los programas son perfectamente capaces de  cerrarse por sí mismos y cargan rápido  :3

Pero por supuesto, también tengo mis pegas...

- PulseAudio se vuelve loco de vez en cuando y me bloquea el sonido. Es aleatorio, lo mismo no me ocurre en un día entero que me pasa cada 10 minutos. De momento siempre tengo una terminal abierta y a punto para hacer un "pulseaudio --kill" y que vuelva en sí, pero es un coñazo. La semana que viene termino exámenes y me pondré a escarbar en los foros de  Ubuntu a ver si encuentro una solución rápida. Y si no, habrá que sobrevivir hasta abril. ¡Acepto ideas!

- El cursor se vuelve también loco de vez en cuando, también aleatoriamente: sabe desplazarse pero cuando digo de hacer click, nanai: se pone a cambiar de forma (flecha, cursor, mano, etc) y no se arregla hasta que lo muevo con el touchpad. No tengo ni idea de dónde sale este error, es tan absurdo que no se por dónde cogerlo xD

- Firefox sigue a su rollo y no se deja instalar complementos (o al menos ningún complemento para Twitter).

- La pantalla de bienvenida aparece descuadrada, en alguna resolución de pantalla misteriosa. Tengo que desplazar el cursor hasta las esquinas para centrarla y poder hacer login. Esto más que molesto es curioso xD

- ¡El logo de descarga de la pantalla de despedida sigue saliendome en 8 bits! Aunque ahora como es en blanco y negro no es tan divertido como antes que era de colorines, pero mola verlo pixelado...

- ¡Sigo sin encontrar ningún maldito software de ToDo Lists que haga lo que yo quiero! Vale, esto no es un error, pero me jode.. Al final voy a tener que programármelo yo misma ¬¬  Quiero un gestor de ToDo Lists que simplemente me permita poner una hora de inicio y otra de final, que me avise a la hora de inicio y que  me permita mostrar una lista con toda la planificación del día. ¡Sólo eso! Instalé y probé un montón, y ninguno me gustó u_u

Y ahora lo chungo: cada vez que lo enciendo me salta una notificación del tipo de "oh dios mio tu discoduro está a punto de morir, ¡cámbialo!"  ¿Hasta qué punto le daríais credibilidad a esto? No está mi economía como para ir cambiando discosduros así alegremente u_u (y gracias a Dell que fueron majos y la placa base me la cambiaron gratis....)

ACTUALIZADO: Parece ser que lo del disco duro es un bug https://bugs.launchpad.net/ubuntu/+source/libatasmart/+bug/438136 . Al pasar smartctl  a mano obtengo:

 

motagirl2@aleph:~$ sudo smartctl -i  -H /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     SAMSUNG HM400LI
Serial Number:    *censurado xD*
Firmware Version: 2TF00_00
User Capacity:    400,088,457,216 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 0
Local Time is:    Wed Jan 27 21:26:49 2010 CET

==> WARNING: May need -F samsung or -F samsung2 enabled; see manual for details.

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

En fin, que salvo lo del sonido (que es un coñazo) todo lo demás son errores tontos y podré vivir con ellos.

Y  para finalizar... let’s flame:

Mencanta =^_^=

Frenada regenerativa

¿Sabías que tu proveedor de energía eléctrica te roba cada vez que bajas en ascensor?

No me refiero a que acudan a tu casa, te esperen en la planta baja, te golpeen con un ladrillo y se lleven un pozal lleno con tus joyas y tu dinero, sino que te están robando tu energía. Veámoslo.

En primer lugar, necesitamos saber más o menos cómo es y cómo funciona un motor. Externamente, los motores eléctricos suelen tener este aspecto:

Caja de bornes: donde se encuentran las conexiones para enchufar nuestro motor a la red (en estrella o triángulo)
Aletas: Proporcionan más superficie expuesta al aire, para mejorar la refrigeración.
Eje: Parte que va a rotar.
Patas: Fundamentales para anclar el motor al suelo y que no salga volando ;)

Por dentro, son así (este concretamente es de jaula de ardilla, lo sabemos por las "rayitas" del rótor):

Estátor: Parte del motor que permanece inmóvil.
Rótor: Parte del motor que va a girar, arrastrando al eje y al ventilador (si lo hay).

Como veis, por dentro son terriblemente simples. Tan terriblemente simples que el primer día de clase de Electricidad Industrial desmonté uno y lo volví a montar, y seguía funcionando xD

Pasemos ahora a ver (muy por encima, estilo para dummies) qué es lo que hace que un motor gire.

El estátor, la parte fija, tiene un montón de espiras conductoras enrolladas. Cuando estas espiras están conduciendo electricidad (cuando el motor se conecta a la red), generan un flujo de campo magnético. Es decir, el estátor se comporta como una especie de imán, con polo norte y polo sur en su interior. Y en este interior está ubicado el rótor, que también tiene otro montón de espiras enrolladas. ¿Y qué pasa cuando metes una espira en un campo magnético? Pues que esta espira gira y tiende a orientarse con el campo.
Si sólo tuviéramos una espira en el estátor, nuestra espira del estátor sólo giraría una vez. Pero tenemos muchas, y además estamos usando corriente trifásica (R, T y S), por lo que podemos conectar cada espira a una de las fases. Así conseguimos que el campo generado por el estátor no "se está quieto" sino que sigue girando, arrastrando así al rótor (que se ve atraído por él):

Por otro lado, también hay que saber que un motor y un generador son totalmente reversibles. Es decir, que si  tenemos un motor y en vez de darle corriente, le damos un movimiento de rotación a su eje, estaremos generando electricidad en los bornes de las espiras del estátor , con lo que tenemos un generador (y de hecho ese es el principio de funcionamiento de, por ejemplo, los aerogeneradores)

Veamos ahora la diferencia de funcionamiento entre un motor y un generador en la forma más simple posible:  mediante un esquemita de entradas y salidas en unos simples conductores y a base de GIMP:

¿A que hace mucho que no veíais algo tan cutre? :D

En el caso del primer conductor, lo tenemos inmerso en un campo magnético B y le damos una intensidad I y un par resistivo Tres (por ejemplo, gente dentro de la cabina del ascensor). Frente a esto, se producirá una fuerza en sentido contrario y una velocidad intentando contrarrestar el par resistivo. Esto es, tenemos un bonito y precario motor.

En el segundo conductor, también inmerso en un campo magnético B, operamos al contario: lo dotamos de un par de rotación Trot (por ejemplo, viento haciendo girar un molino). En este caso, también tenemos una fuerza que se opone al giro y.. tachán! Una preciosa corriente I y una fuerza electromotriz e, listas para ser usadas.

Ahora que ya sabemos cómo funcionan y en qué se diferencian un motor y un generador, podemos volver a nuestro ascensor de antes.

Cuando el ascensor está subiendo, no hay ningún problema: el peso de la cabina actúa como par resistivo, la conexión a la red le da la intensidad que necesita y el motor de nuestro ascensor está actuando como en el primer caso (motor) y no pasan cosas raras.

Pero... ¿y cuándo bajamos? El peso de la cabina va en el sentido del movimiento, así que ya no es un par resistivo, sino que nuestro motor se convierte en el segundo caso:  sin haberlo planeado, tenemos un generador.

La pregunta es bastante clara... ¿a dónde va toda esta energía generada? Pues en la inmensa mayoría de los casos... se devuelve a la central eléctrica. ¿Y alguno de vosotros ha visto una sóla factura de su compañía eléctrica en la que se le devuelva algo de dinero en concepto de energía generada y devuelta a la red? No, ¿verdad?

Aunque hay comunidades de vecinos negociando con las eléctricas para que les devuelvan el dinero, parece poco probable que estas vayan a ceder. Pero hay otras soluciones más o menos complejas, por ejemplo, montar algún sistema de almacenamiento (baterías o bancos de condensadores, por ejemplo) de manera que toda esa energía sobrante se almacene para, por ejemplo, alimentar la iluminación de la escalera.

Pero las aplicaciones no son sólo para ascensores (aunque sí que es el ejemplo más cercano). Por ejemplo, este sistema (que recibe el nombre de "frenada regenerativa") se usa contínuamente en metros y trenes, donde la energía producida al bajar una cuesta o frenar en una estación se devuelve a la catenaria y se utiliza para alimentar otros trenes cercanos. También es común en coches eléctricos o híbridos, donde se utiliza para recargar la batería. Y también se ha hecho relativamente conocido últimamente en sistemas como el KERS, recién implantado en la Fórmula1 para recargar una batería auxiliar que permite a los pilotos obtener más potencia después de una frenada.

Ensalada de enlaces:

- Regenerative Brake (en la wikipedia en inglés)

- Frenada Regenerativa (en "Control de Máquinas Eléctricas", de google books)

- Sistema de frenada regenerativa en el metro de Granada (en Ecomovilidad.net)

- ¿Qué es el freno regenerativo? (en Meka-Eko)

- Bicicleta con freno regenerativo (en Engadget)

- Frenada regenerativa en el Toyota Prius (en Mecánica Virtual)

- Frenada regenerativa en un cochecito de juguete (12", en Youtube)

- Frenada regenerativa en una bicicleta para encender una bombilla (18", en Youtube)

- Fernando Alonso vs Trulli, adelantamiento gracias al KERS (22", en Youtube)

- Kone Serie-R, ascensores que utilizan frenada regenerativa para iluminación interna entre otras cosas (pdf, Kone.com)

 

LegoTechnics 8062-3

Me ha llevado deceeenas de horas  (no las he contado, pero más de 30 seguro), pero por fin puedo decir que he terminado la tarea 6 de Sistemas Mecánicos: este bonito modelo 8062-3 de los LegoTechnics, usando Solidworks. Quizá no parezca para tanto, pero las tripas del camión son una fiesta de engranajes (para la dirección, las ruedas, levantar la caja, bajar la rampa...).

Tengo otros modelos anteriormente, pero este me ha dado tantos problemas que me ha hecho especial ilusión xD Un día de estos hago el ánimo y os enseño también los anteriores (y los que me quedan por hacer .... u_u)

Anillo geek

Resistencia de 1KΩ + estaño + soldador = Anillo fantabuloso.

Rápido, sencillo y barato, a la par que elegante y superfashion de la muerte en ambientes ingenieriles.

xkcd - Fourier

Claramente, era lo que viene siendo un gato en tiempo contínuo.

Tranquilos, Pinocho sigue bien, pero encontré esto cuando buscaba more info sobre Fourier (en escasos días me examino de Señales y Sistemas y me gusta saber cosas  sobre la gente en la que tengo que pensar durante más de 10 minutos)

Por otro lado, xkcd (los autores de la viñeta) están hoy haciendo un homenaje a GeoCities, que por lo visto cierra hoy,  con un rediseño espectacular de su web. No os lo perdais, os vais a sentir muuuy viejunos, recordareis los bonitos modems de 56k, los perpetuos cartelitos de "under construction".... No hace falta viajar en el tiempo, sólo mirad la captura:

Scanner en Ubuntu con XSane

Yo formaba parte de la gran masa de usuarios de linux que cuando necesitan usar su scanner buscaban un pc con Windows cerca para ahorrar odio y tiempo. Hasta ayer, que me dio el ramalazo geek y me dije "mota.... ¡vamos a ganar unos cuantos puntos de exp!"

Y puesto que me llevó unos cuántos dolores de cabeza y unas cuántas horas de navegación, prueba y error, os contaré aquí cómo he hecho para que tire.

En primer lugar, necesitamos una interfaz mágica para comunicarnos con nuestro scanner. Yo he elegido XSane por dos razones: 1- venía de serie en mi  Ubuntu. 2- SANE viene de "Scanner Access Now Easy", y si pone "easy" no puede ser malo.

Si no lo tenemos (o no estamos seguros, que también puede ser), abrimos una terminal, escribimos

sudo apt-get install xsane

metemos la contraseña de superusuario, y dejamos que se descargue y se instale.

Una vez que lo tenemos, accedemos a él desde Aplicaciones - Gráficos o directamente tecleando xsane en la terminal.

Se nos abrirá una ventanita en la que nos pedirá seleccionar el dispositivo entre todos los encontrados (en mi caso, la webcam y el susodicho scanner, que es el que nos interesa).

Lo seleccionamos, aceptamos.... y lo más probable es que nos encontremos con esto:

Que no cunda el pánico, vamos a solucionarlo.

Lo primero que necesitamos saber es el modelo exacto de nuestro scanner (en mi caso, un Acer ScanPrisa 640U que está a punto de cumplir diez añitos) y si está soportado por Sane. Nos metemos aquí a la página del proyecto Sane y buscamos nuestro modelo de scanner  (ojo, si tienes un Acer como yo, debes saber que ahora se llaman BenQ):

¡Bien! Está soportado. Concretamente mi modelo de scanner utliza SnapScan así que entramos en el enlace a ver qué versión del firmware necesitaremos para hacerlo funcionar:

Sabiendo esto, el siguiente paso es hacernos con la versión del firmware que necesitamos. Para ello, usamos el CD que venía con el dispositivo o lo obtenemos directamente de la web del fabricante. Generalmente, lo que descargaremos será un pack de un montón de megas, pero lo que nos interesa apenas ocupa unos pocos KB: es un archivo .bin con el nombre que hemos visto en el paso anterior. También puede ser que la versión no sea exactamente la misma (mi caso, cómo no xD), así que con coger la inmediatemente superior suele valer.

Una vez hemos encontrado nuestro firmware, lo copiamos a alguna carpeta mágica donde pueda dormir tranquilamente. Por ejemplo, /etc/bin (originalidad al poder).

A continuación, según pone en la página de SnapScan, necesitamos "crear" el dispositivo:

mknod /dev/usbscanner c 180 48

Y hecho esto, debemos decirle a XSane dónde están los drivers. Vamos a la carpeta /etc/sane.d y buscamos el archivo de configuración que va a usar nuestro scanner, que es el indicado en la página donde miramos si era compatible. En mi caso, snapscan.conf, así que lo abrimos como superusuario para poder cambiarlo:

sudo gedit /etc/sane.d/snapscan.conf

Buscamos donde ponga /usr/share/sane/snapscan/your-firmwarefile.bin (es la primera linea no comentada) y lo sustituimos por la ruta hasta nuestro precioso archivo .bin que guardamos antes, de manera que quede así (pero obviamente, con tu versión del firmware):

firmware /etc/bin/u96v121.bin

Guardamos (recuerda que probablemente tendrás que ser superusuario), volvemos a lanzar XSane, seleccionamos el scanner, y pueden pasar dos cosas:

1) Que nuestro scanner empiece a hacer ruidos sospechosos y nada agradables justo antes de recibir el mismo mensaje de error que al principio. Esto significa que la versión de firmware que has usado no es la buena. Que no cunda el pánico, a mi me ha costado cinco intentos encontrar la correcta dentro del pack. Simplemente, ve probando hasta que encuentres la que lo hace funcionar. Eso sí: entre cambio y cambio de snapscan.conf deberás desconectar y reconectar el scanner para que los cambios tengan efecto.

2) Que todo haya ido bien y encuentres en tu pantalla un mar de ventanitas similares a estas:

¡Enhorabuena! ¡Todo ha ido bien!

Al principio, XSane puede parecer un auténtico caos de opciones sin sentido y demás, pero en cuanto has mirado un poco las opciones descubres que es el paraiso de la customización, y todo al alcance de la mano. Algunas opciones interesantes a un sólo clic:  elegir color/B&N/grises, elegir la resolución, ajustar el contraste, brillo y gamma, ajustar los colores.... y lo mejor: elección del modo de salida. Podemos escoger si queremos abrirla con el visor interno, guardarla automaticamente, enviarla por correo, enviarla a la impresora....o una cosa muy útil:  crear un proyecto multipágina y exportarlo directamente a pdf cuando hayamos escaneado todas las páginas. ¡Un amor! Además, vemos (antes de empezar a scanear) el tamaño y peso (en megas) que tendrá nuestra imagen (lo cuál se agradece).

Cuando hayamos toqueteado todas las opciones y lo hayamos configurado a nuestro gusto, simplemente tenemos que hacer clic en "Adquirir vista previa" en la ventana de vista previa, seleccionar sobre ésta la  parte de la imagen que queramos obtener, y luego pulsar "Explorar" en la ventana principal del programa (que es donde están también todas las opciones). La imagen irá a donde hayamos seleccionado en el modo de salida.

Espero que esto haya sido más o menos útil, creo que no me he dejado ningún paso... Quejas, dudas y traumas, en los comentarios :)

 

 

Almacenamiento magneto-óptico

No puedo evitar visualizar esto cada vez que leo "almacenamiento magneto-óptico" en los apuntes, así que he tenido que perpetrar este sacrilegio para que todos seais partícipes y no sea yo la única traumada :D

 

¡Festival del humor!

Cinco minutos de Gimp hacen maravillas con mi integridad  mental xD

(Imagen original)

 

Codificación de colores en modo texto de VGA

¡Otro post mágico sobre periféricos! Y probablemente esta semana y la que viene haya algunos más, puesto que tengo el examen de prácticas el martes y el de teoría el lunes siguiente.

Recordemos los capítulos anteriores porque probablemente serán útiles en este:

- Punteros y modelos de memoria

- Acceso a ROM para obtener los patrones de bits de los caracteres

- Modificación de los patrones de bits de los caracteres

- Acceso a la Tabla de Vectores de Interrupción

Bien, dicho esto, también nos será útil saber cómo organiza VGA el acceso a los colores.

Sabemos que, si escribo un carácter directamente en memoria  de video (en nuestro caso -80x25- el segmento comienza en 0xB800), este ocupará 2bytes repartidos tal que así:

8bits: carácter
1bit: parpadeo
3bits:  color de fondo
4bits: color de carácter

Sabiendo esto, podemos usar 4 bits para el color, es decir, que tenemos 16 colores distintos a elegir. En realidad, cada uno de esos colores está apuntando a una paleta, que a su vez indexa 256 registros de un conversor analógico digital (DAC), en  el que cada color (rojo, verde, azul) ocupa 6bits. O sea, 3 colores de 6 bits cada uno (64 posibilidades por cada color) nos da 256 bonitos colores para usar.

La manera en que utilizaremos esto es la siguiente: modificaremos la paleta de un color determinado (en este caso, el 5, violeta) para que indexe otro color del DAC. Entonces, cada vez que pintemos algo de ese color, se estará pintando en realidad del color con el que lo hayamos modificado.

¿Lo primero que necesitamos saber? A donde apunta (en el DAC) el color que hemos elegido. Esta función es útil para eso:

int indiceDAC(int indcolor) {
/* dice a que registro DAC apunta una entrada del registro de paleta */
struct REGPACK r;
r.r_ax=0x1007;
r.r_bx=indcolor;
intr(0x10,&r);
return(r.r_bx>>8);
}

Una vez sabemos cuál es el índice del DAC que vamos a modificar, probablemente queramos saber sus componentes originales:

int lee_paleta(int indDAC, int *R, int *V, int *A) {
/* lee componentes RVA para una entrada DAC */
struct REGPACK r;
r.r_ax=0x1015;
r.r_bx=indDAC;
intr(0x10,&r);
*R=(r.r_dx>>8);
*V=(r.r_cx>>8);
*A=(r.r_cx<<8)>>8;
return(0);
}

Y por supuesto, alguna manera de modificarlo:

int establece_color(int indDAC, int R, int V, int A) {
/* establece componentes RVA para una entrada DAC */
struct REGPACK r;
r.r_ax=0x1010;
r.r_dx=R<<8;
r.r_cx=(V<<8)+A;
r.r_bx=indDAC;
intr(0x10,&r);
return(0);
}

Ahora que sabemos todo esto, lo suyo sería comprobarlo. Para ello,  dibujaremos un cuadrado directamente en memoria de video y lo rellenaremos del color 5.  Esto es tan simple como un par de bucles anidados en los que asignamos valores de caracter y color a un  cacho de memoria de video.

Podemos cambiar de color directamente (leer  paleta,modificar colores, establecer color) o hacerlo interactivo:  creando una nueva interrupción (así), en la que leemos el buffer de teclado (puerto 0x60) y en función de las teclas pulsadas modificaremos los colores.  En mi caso: A y Z modifican los rojos, S y X los verdes y C y D los azules. Para hacerlo aún más pijotero, podemos hacer  un bucle mágico para escribir los valores actuales de cada color en la memoria de video.

Y esto es lo que tenemos al final:

(si os sale que el video no está disponible, entrad aqui)

Credits: Las funciones "establece_color", "lee_paleta" e "indice_DAC" han sido sacadas del libro de apuntes de la asignatura, descargable aquí.

 

IX Jornadas de Astronomía

Desde hace varios años, llevan celebrándose por estas fechas en Yecla unos ciclos de astronomía y astrofísica. Nunca puedo ir puesto que se realizan de lunes a jueves y me suele pillar en Alicante, pero esta  vez creo que podré asistir al menos a dos de las charlas. Siempre he leído cosas muy buenas sobre estos eventos, y tengo muchas ganas!

Si alguno más os animais, os dejo la programación. Todas las charlas son a las 20.30 en el Aula de Cultura "Azorín" de la CAM (C/ España, 14).

 

Lunes 11:

“De 7 a 200 mil:el sistema Solar crece...!!!”
Por René Duffard
Doctor en Astrofísica
Instituto de Astrofísica de Andalucía (CSIC)

 

Martes 12:

“Luz extrema. El Universo en rayos X y gamma”
Por José Miguel Torrejón Vázquez
Doctor en Ciencias Físicas
Profesor de la Universidad de Alicante

 

Miércoles 13:

“Fractales y nubes interestelares”
Por Néstor Sánchez Doreste
Doctor en Astrofísica
Instituto de Astrofísica de Andalucía (CSIC)

 

Jueves 14:

“6 números que definen el Universo”
Por José Miguel Rodríguez Espinosa
Doctor en Ciencias Físicas
Director científico Gran Telescopio de Canarias IAC

 

(Díptico aquí)

Por cierto, seguro que a más de uno os suena el de la charla del martes jeje.

Ubuntu Jaunty Jackalope

En primer lugar y antes de nada, Vladi me acaba de galardonar con el super premio Blog de Oro. Gracias!! Técnicamente  debería  entregárselo a otros 15 blogs más, pero como no quiero que os peleeis, consideraos todos premiados  también =)

Por otro lado, a lo que iba: hace unos días (concretamente el 23Abril) salió la versión final de Ubuntu. Su nombre es Jaunty Jackalope, que significa "jackalope vivaz". Un jackalope viene siendo un conejo con cuernos de ciervo que podría ser la versión americana del  típico gambusino gamusino. 

Misteriosamente, de momento no he tenido ningún problema raro (siempre me pasa algo),  salvo las típicas chorritonterías. A saber:

- El logo con la barra animada vaciándose que sale al cerrar sistema  sigue saliendo en nula-resolución. Vamos, que decir que está a 16 colores sería pasarse xD
- Los minijuegos en flash han hecho catacrocker y van a trompicones. Esto será probablemente porque el driver que usa la NVidia es otra versión, pero de momento no es algo urgente. Aunque quizá sea una fumada del firefox porque no lo he notado en ninguna otra cosa.
- Anjuta se borró del mapa, pero volvió a mí reinstalándolo desde 0.
- El sonido parece oirse más débil. O eso o me estoy quedando sorda.
- El rhythmbox me tira algunos  errores de que le faltan componentes, pero aún así funciona. Miraré esto  más a fondo, aunque no es molesto..... salvo al abrirlo.
- La configuración de pidgin también se quedó en el limbo de las configuraciones y tuve que configurarlo otra vez (y mira que es cansino)
- Aparentemente, se ha desinstalado el cups-pdf que permitía imprimir directamente a pdf. Puede que esté escondido y yo todavía no lo haya encontrado... pero lo dudo xD
- Hay un nuevo notificador muy majoso, pero no sé quién es ni cómo se llama, así  que no he podido decirle las cosas exactas que quiero que haga...
- Sigo sin encontrar  una  opción para decirle que quiero que el reproductor de video por defecto sea VLC en vez de Totem. Arreglado. Gracias juanfra!

Vamos, que practicamente no he notado cambios (la vez anterior fue como  una hecatombe en miniatura)

En fin, que todo lo de arriba no es más que una excusa para postear el preciosísimo wallpaper que encontré hace tiempo en Ubuntips:

¡Por dios!  No me digais que no os parte el alma =)

Richard Stallman en Alicante

Niños, niñas, elefantes voladores y demás: vayan vaciando sus agendas para el martes 12 de mayo a las 17.30 porque... ¡viene Stallman!

La pista la dio VicenteJuan en twitter, y tras una rápida búsqueda en google encontré la fuente original de la noticia, en la FreeSoftwareFoundation, right here. Según pone, y suponemos que será cierto,(cito textualmente),

Alicante, Spain. Aula CAMON, Avd. Ramón y Cajal, 5, Torrevieja. Richard Stallman hablará sobre las metas y la filosofía del movimiento del Software Libre, y el estado y la historia del sistema operativo GNU, el cual conjuntamente con el núcleo Linux ahora es utilizado por decenas de millones de usuarios en todo el mundo.

Lo único malo, malísimo, es que  es mi tarde con  más clases (ninguna obligatoria, aunque sí recomendables) y que es en Torrevieja. Pero seguro que encuentro alguien para hacer una excursión.... o eso espero :S

Edit:

Parece ser que podría haber un error en la noticia original, y que fuera en Alicante-Alicante, puesto que en esa misma calle y número (pero en Alicante) existe una CAM (google maps says). Esto es lo que ocurre cuando en todos los pueblos de los alrededores hay una maldita Avenida Ramón y Cajal XD

Portátiles chiquitines

Acabo de ver en Ubuntips esta bonita gráfica que (basándose en sus características) supuestamente te ayuda a saber cuál es el nombre "técnico" y "respetable" de tu ordenador portátil, puesto que "portatil chiquitín" no es muy descriptivo ^^ Por ejemplo: netbook, ultraportatil, etc etc

Ahí va:

Por ejemplo, en  mi caso:

- Acer Aspire ¿1391? (aka "mi portátil viejo"):  Is the PC worth more than $500? ->  YES -> Is the screen larger than 13"? -> YES -> You’ve got a plain old LAPTOP

- Dell XPS M1330 (aka "mi portátil nuevo"): Is the PC worth more than $500? ->  YES -> Is the screen larger than 13"? -> NO -> Does it have an optical disc? -> YES -> You’ve got an  ULTRA-PORTABLE

Puedes poner tus cosicas en los comentarios, que no muerden.

Sun OpenSource Technologies

(Disclaimer:  Esta entrada está basada en notas que he tomado durante una charla, así que probablemente no haya mucha coherencia entre párrafo y párrafo. No me lo tengais en cuenta. Tampoco voy a poner links, porque me puedo morir. ¡Usad un buscador! )

Esta mañana he estado en la sesión informativa de Sun OpenSource Technologies,  junto con los agradables mangarrufos Lord_Kote  y Scipion. Han sido tres intensas horas de información, self-promoting (esto era esperable), datos técnicos a porrillo, etc etc. en una pequeña sala que con15 alumnos  y 5 profesores ya estaba llena..  Por cierto, yo era la única mujer  no profesora... después de 5 años y todavía me sorprende xD

La sesión estaba planeada en tres grandes bloques:

1 . OpenSolaris
2.  OpenSPARC
3.  Programas Especiales para Universidades

De ellos, el que más interesante  me ha parecido es es  de openSPARC, pero puesto que ha sido el más "técnico" ha sido del que menos notas he tomado (muchos esquemas, datos y demás).  A cambio, sobre  OpenSolaris tengo miles de notas, así que tendré que dejarme cosas  en el tintero. Y sobre los programas para universidades, pues muy interesante también, pero ahi los estudiantes ni pinchamos ni cortamos.

En primer lugar, y con una Solaris 2008.11 sobre la que se había virtualizado Ubuntu y otros OSs (el ponente, un Arquitecto de Sistemas, se ha declarado  Ubuntero de corazón) nos han contado cosas de por qué Sun es guay: Solaris, SPARC, StorageTec, Java, MySQL... etc etc, que son la empres que más invierte en OpenSource por persona, etc.

Ya entrando en el tema de openSolaris, nos han contado que su objetivo es llegar a ser tan amigable como Linux, lo que venía reducido en la frase "Easy to Get-Install-Use-Maintain". Para ello, tenemos liveCDs, un instalador gráfico, el uso de Gnome/Compiz, repositorios de paquetes en la red (Image Packaging System, con unos 4000 paquetes actualmente). Estos paquetes están divididos en tres clases: Community (donde meten las last releases y el software de terceros), Sun (su software) y uno último, de pago, llamado Subscription (donde meten actualizaciones de seguridad, bugs y demas).

Han insistido bastante también en que la HCL (lista de  hardware compatible) es muy grande y va en aumento. Además, se supone que cuando vas a instalar Solaris,  se analiza el sistema y si hay algún driver no soportado, se avisa al usuario y se le indica dónde y cómo puede conseguirlo.

Una diferencia fundamental de Solaris con , por ejemplo, Ubuntu, es que está más orientado a unos objetivos comerciales. Por ello, sacarán una  nueva versión cada  5 años, pero manteniendo los updates trimestrales: La idea es evitar cambios drásticos frecuentes en sistemas grandes y/o críticos.

Después de la introducción, nos han contado las cosicas de las que se sienten más orgullosos: el ZFS, el D-Trace, CIFS incorporado en el kernel, el sistema de repositorios y AMP/MARS.

ZFS, que viene siendo Zettabyte File System es, como su nombre indica, el sistema de archivos. Nos cuentan que es el primer sistema de archivos de 128 bits, que es muy escalable y fiable, que la información siempre se mantiene consistente y que no se degrada, que es un sistema transaccional, que las instrucciones son atómicas, que es muy rápido  y que por todas estas cosas no necesita file-checks periódicos. Además, nos premite usar algo llamado "atributos" para garantizar un tamaño mínimo, elegir el algoritmo de compresión, el de cifrado, etc etc. Por cierto, han dejado caer que OS X Leopard utiliza ZFS para la famosa time-machine.

Todo esto de la consistencia y no degradación de los datos viene dado por  algo llamado Copy-On-Write (que crea duplicados del dato y de sus punteros en el espacio libre por si ocurre un imprevisto), otra cosa llamada End-To-End Checksums (que usa checksums de 64Kb separadas de los datos, garantizando que no haya pérdidas de datos ni "escrituras fantasma") y los Solaris Containers (que vendría a ser la virtualización de distintas zonas "estancas" (frente a las zonas globales) e independientes unas de otras, que sólo compartirían el núcleo de Solaris, lo que las haría más eficientes ocupando menos espacio).

El siguiente "punto gordo" es D-Trace, quees una herramienta de trazabilidad que usa unas 30.000 "sondas" activables o desactivables por el usuario para optimizar aplicaciones, permitiendo ver cómo responde el sistema operativo de una manera no intrusiva y ligera. Se supone que esto dota de flexibilidad y dinamismo al sistema porque no hace necesario el lanzamiento de un core dumped para ver dónde está fallando.

Para acabar con esta primera  parte, nos han hecho una comparativa con RedHat. Que el ciclo de vida de openSolaris es mayor, cómo se reparten el mercado, el precio de la subscripción (más o menos igual), el soporte hardware , etc.

Después, ha empezado la de OpenSparc. Nos han hablado de las tres línas de procesadores que Sun lleva en marcha. A saber: x86/x64, UltraSparc Sparc64 y UltraSparc CoolThreads, que es lo último que han sacado.

Ha comentado un poco el tema de los problemas en los procesadores: la latencia, debida a que la tecnología que desarrola memorias no tiene nada que ver con la que desarrolla procesadores (y cada vez se alejan más), y la velocida de reloj (cuyo aumento necesita un alto consumo energético, y por tanto, mucho calor). También se han comparado las tecnologías de single-threading con las de multi-threading. Como media, las primeras pasan un 85% de los ciclos esperando a la memoria, por lo que sólo ofrecen un 15% de tiempo  de uso. Por el contrario, el multi-threading ofrece una media de 85% de tiempo de uso.

Entonces, en 2005, a Sun se le ocurrió la idea de juntar CMP (múltiples núcleos) con HMT (múltiples hilos) para obtener lo que llamaron CMT: Chip Multi Threading. De ahí salió entonces el UltraSparc T1 (de nombre Niagara), que  a menos velocidad de reloj (entre 1 y 1.4GHz) y siendo mucho más simple que los procesadores comerciales del momento, era capaz de ejecutar más instrucciones. Algunos datos que nos han dado es  que ejecuta los threads de 4 en 4, y cada uno de estos grupos en un core (existe en versión de 4, 6 y 8 cores), que el acceso a la memoria es UMA y que consume muy poquito. Como dato curioso, inicialmente sólo tenía una FPU (unidad de coma flotante) lo que obviamente creaba cuellos de botella en aplicaciones que necesitaran usar dicha unidad (esto se arregló para la siguiente versión, la ultraSparc T2, donde metieron una FPU para cada core). A cambio del pequeño fail con la FPU, el sistema era perfecto para servidores web, LDAP y similares, puesto que incluía de serie una cripto-aceleradora embebida.

Respecto al ultraSparc T2, como ya dije, arreglaron el tema de la FPU (poniendo una en cada core), aumentaron los hilos a 8 por cada núcleo, y además embebieron el PCI,  la interfaz gigabit ethernet y los controladores de memoria, obteniendo así un SOC (System On a Chip)

Después, se sacaron de la manga el T2+ (Victoria Falls), también SOC y SMT (simultaneous multi threading), pero con algunos cambios para mantener la coherencia. Y ya que estaban, subieron a 128 threads por core.

Para terminar, nos habló de los problemas de estas tecnologías (como la escalabilidad, programabilidad, verificación y desarrollo de software), y nos ha contado algo sobre openSPARc:que es un procesador Open Source de 64 bits liberado bajo la GPLv2, que se pueden  obtener los  diseños online (wiki.opensparc.net) y que los donan a universidades y cosas así.

En este punto de la charla, alguien ha hecho una pregunta interesante: ¿En qué beneficia todo esto  del opensource a Sun? La respuesta ha sido que si fuera algo cerrado, se comerían el 100% de la tarta de beneficios, pero sería una tarta pequeña. En cambio, abriéndose  y liberando sus cosicas (por ejemplo, Java), consiguen ser más usados y conocidos, y por tanto, la tarta de beneficios crece ingentemente. Y aunque el porcentaje de beneficios  que se comen es más pequeño, es ingentemente más grande que la tarta pequeña entera. Vamos, que se supone que todos salimos ganando.

Despues, y muy rápido porque ya eran casi las 15.00 (se suponía que acabaríamos a las 14.00), nos han hablado de que tienen diferentes programas para las Universidades: donación de hardware y software (para uso docente o de investigadores), proyectos de fin de carrera, la suite Star Office, cursos de formación gratuita (SAI) con posibilidad de certificación, etc etc etc.

En definitiva, una  charla interesante sobre un tema, para mi, practicamente desconocido.

Aunque se les habían olvidado los CDs de openSolaris que se supone que nos iban a regalar (las prisas...), tenían algunas camisetas e "identificadores para el equipaje" que han repartido entre los que han hecho preguntas y cosas así. Yo no he hecho ninguna, pero al salir uno de ellos se me ha acercado y me ha dado un pack ^^ La camiseta es blanca y XL-hombre  (aka gigantesca, me la pondré en verano para dormir xD) con un logo azul grisaceo que pone "Sun, 25 years of innovation" y spam encubierto de AMD64Opteron en una manga. Respecto al identificador de equipaje, es naranja y blanco, con el logo de Java y el de Solaris , lleva escrito "Sun Tech Days, a WorldWide Developer Conference. Innovation Happens Here" y huele a plástico. A mí lo de Sun Tech Days me ha sonado a programar en verano al solanero junto a la piscina, pero no creo que se refieran a eso xD

Se supone que enviarán a un profesor las transparencias que han utilizado y él las colgará en su blog para que las podamos descargar (o eso he entendido), así que si a alguien le interesa ojearlas, que me lo diga y cuando me entere de que están disponibles se lo hago saber.

Moraleja: Buscaré  mi CD de Solaris 10, o en su defecto, pediré uno de OpenSolaris para trastearlo en mi portatil viejo y darle una segunda oportunidad (a Solaris)

Ale, me voy a teletransportarme que pierdo el bus.  Lo siento mucho si ha sido muy espeso xD

Acceso a la tabla de vectores de interrupción

Otro bonito capítulo sobre mis prácticas de periféricos, de esos que nadie comenta pero luego cuando nos cruzamos por el campus me rascais la cabeza y me dais las gracias :P

Esta no pensaba hacerla todavía,  pero por lo visto esta mañana  a las 7.00 mis vecinos han considerado divertido poner música a todo volumen (nunca antes odié a Bach) y pasear con tacones (o equivalente). Así que como no podía dormir, y no tenía nada mejor que hacer (en realidad sí, pero no importa), le he dedicado un rato a esta práctica que es muy sencilla.

La tabla de vectores de interrupción es un cacho de memoria (concretamente, desde el 0000:0000) en  el que se almacenan las direcciones de las funciones o rutinas que atenderán a cada interrupción. Es decir, que cuando se produce una  interrupción, se transfiere el control del sistema a la rutina situada en la dirección indicada en la posición de memoria especificada en la posición correspondiente de este vector.

Hay 256 interrupciones (la lista está aquí).Cada una, usa 4bytes de este vector: 2bytes para el offset y otros 2bytes para el segmento en que se encuentra la función (no, no me he equivocado: guarda primero el offset y después el segmento). Por tanto, en total la tabla ocupa 1KB. Además, cada interrupción está en la posición indicada por su número: La dirección de la interrupción 0 se encuentra en los 4 primeros bytes, la de la interrupción 1 en los 4 siguientes, etc. En definitiva: el offset de la dirección de la interrupción i se encuentra en el byte  tvi+4*i y su segmento en el tvi+4*i+2 (suponiendo tvi el inicio de la tabla de vectores de interrupción, o sea, 0000:0000)

Supongamos que no nos gusta la rutina normal de teclado, y queremos una propia que por ejemplo, en vez de escribir el carácter por pantalla, imprima el valor del código de teclado (es decir, el código de la tecla pulsada, que no depende del carácter sino  de la posición de la tecla y de si se pulsa o se suelta. Por ejemplo,  el ESC genera el scancode 1, el 1 genera el código 2, el 2 el 3, etc etc. La tabla completa está aquí -la Tabla90-). Podría ser algo tal que así:

void interrupt rutina_teclado(){

char codigo;
codigo = inport(0x60);
/*Blablablabla hacer cosas blablabla*/
outport (0x20, 0x20);

}

Inciso: Sí, pongo las llaves así, mucha gente lo ve raro pero ... a mi me parece más amigable que ambas en nueva línea. :P
Encuesta: ¿Cómo  las pones tú? xD

La palabra interrupt le indica al compilador que lo que está haciendo no es una función normal, sino una interrupción. O sea, que le está pidiendo al compilador que genere código para salvar y restaurar el estado de la CPU cada vez que se ejecute ese código (esa es la gracia de las interrupciones)

Con inport(0x60) lo que hace es leer el scancode de la tecla pulsada/soltada, y el outport(0x20, 0x20) simplemente es el  EOI (End Of Interruption), que hace que se salga correctamente de una interrupción. ¡Debemos usarlo siempre para terminar una interrupción!

Bueno, obviamente, esto así solito, en el limbo de los  códigos, no tiene mucho sentido, así que tendríamos que modificar la TVI para que cada vez que pulsemos una tecla, vaya a nuestra maravillosa rutina en vez de a la normalita. Como ya sabemos, la interrupción de teclado es la 9, así que lo que nos interesa está en esa posición (O sea, necesitamos un punterete hacia MK_FP (0 , 9*4)).

Lo primero, antes de romper nada, es guardarnos la dirección  de la rutina original. (Aunque si se rompe algo, que no panda el cúnico: basta con cerrar y abrir  nuestro maravilloso emulador de DOS). Para ello, guardamos en un par de variables el offset y el segmento, que como dije antes, están respectivamente en los dos primeros y dos siguientes bytes de 0 , 9*4.

Lo siguiente es modificar la posición de la tabla que nos interesa y decirle que ahora tiene que apuntar a nuestra rutina. El identificador de una función es en realidad un puntero a la misma, así que se convierte en algo tan simple como lo que sigue:

asm cli;
*(tvi+9*4)=FP_OFF(rutina_teclado);
*(tvi+9*4+2)=FP_SEG(rutina_teclado);
asm sti;  

Es importante desactivar la llegada de interrupciones antes de cambiar nada. ¿Os imaginais la super catástrofe que sería que se produjera una interrupción de teclado después de haber cambiado el offset pero antes de haber modificado el segmento? ¡Eso sí que sería una fieshta! Podemos hacerlo con  instrucciones en ensamblador: asm cli (desactivarlas) y asm sti (activarlas), una vez que se han modificado. Cuenta la leyenda que también se puede usar disable() y enable(), que están incluidas en dos.h . . . pero yo no las he usado así que no prometo nada.

Y una vez cambiado esto... ya podríamos casi decir que está todo hecho. Eso sí: En el tremendamente abierto "hacer cosas" de la rutina es bastante interesante configurar un caracter "de escape", para que cuando se detecte una  determinada tecla pulsada, se salga de la interrupción restaurando la rutina original (y así además te ahorras tener que cerrar el DOS para poder usar el teclado normalmente xD). Pero eso lo haceis vosotros: no os lo voy a dar todo mascadito :P

Fail típico 1: poner un while(salir==false) dentro de la rutina. Esto es absurdo, porque la rutina se invocará  SIEMPRE que pulse o suelte una tecla, así que el bucle no me hace falta.

Fail típico 2: llamar explícitamente a la función. ¡No hace falta! Vendrá ella solita cada vez que pulses una tecla.

Ale, espero que os haya servido de algo, y si no es así... al menos a mi me ha servido para "afianzar conocimientos". Acepto comentarios, mails y tabletas de chocolate :P

Os dejo con la típica captura de rigor: En ella pulso las teclas M O T A en ese orden. Si pinchais en la imagen y la veis en flickr,  le he puesto notitas explicativas ^^

Por cierto, fe de erratas del artículo sobre Modificación de los patrones de bits de los caracteres: Comprobé una vez más el ejecutable sobre cmd, y resulta que no funcionaba por la  simple razón de que no lo tenía configurado en el modo 80x25 y en pantalla completa. En cuanto lo cambié, comenzó a tirar. Cosas que pasan XD

Modificación de los patrones de bits de los caracteres

[Capítulo anterior: Acceso a ROM para obtener los patrones de bits de los caracteres]

Hace unos días os conté cómo acceder a ROM (la BIOS de toda la vida) para coger los patrones de bits de los que están formados los caracteres que se escriben en la memoria de  video. Esto puede ser divertido, pero... también un poco estático, ¿no?

El experimento ganaría en posibilidades si pudiésemos modificar esos patrones para crearnos nuestras propias fuentes. Vale, sí, sería una cosa muy artesanal y a bajo nivel, bit a bit y todo eso, pero... ¿acaso teneis algo mejor que hacer?   xD

Yo no voy a crear aquí un juego de fuentes entero porque no estoy tan enferma (de momento), sino que me voy a conformar con ponerle una rayita encima a la letra A (sí, igualito que en el enunciado de la práctica 4 de Periféricos, soy poco original).

Así, de primeras, no  podemos  modificar los patrones de bits porque están en ROM, que como su propio nombre indica, es Read Only Memory. Así que el primer paso es copiar esa lista de 256 caracteres * 16 bytes/caracter de la ROM a la RAM. ¿Como? Creando una variable char* de ese tamaño (con malloc), y asignándole byte a byte el contenido de la variable (también char*) original que contiene la lista de patrones en la ROM (esto lo expliqué aquí)

Ahora, puedo añadir todas las modificaciones que desee, puesto que mi tablita ya está en memoría escribible. Como  dije, añadiré una rayita sobre la A. Puesto que la A es el carácter 65, avanzo hasta su posición. Los 8 siguientes bytes son cada una de las "filas" de pixeles de las que está formada la A, así que como quiero la rayita ENCIMA de la A  (en el primer byte), no necesito desplazarme "hacia abajo" (sumando entre 1 y 8 al desplazamiento de 256*16):

    *(listaRAM+65*16)=255;

255 es en hexadecimal lo que en binario viene siendo 11111111, o sea, en el idioma de los pixeles (xD) una línea.

Ahora que ya tenemos nuestra lista con la modificación, lo que queremos es decirle a la tarjeta dónde está el nuevo juego de carácteres, para que "olvide"   el viejo y use el nuestro (modificado). Esto tenemos que hacerlo con interrupciones en ensamblador, o sea que necesitareis un TurboAssembler o equivalente.

El código sería el siguiente:

    asm push ax;
    asm push bx;
    asm push cx;
    asm push dx;
    asm push es;
    asm push bp;
    asm mov ax, 1110h;
    asm mov bx, 1000h;
    asm mov cx, 0100h;
    asm mov dx, 0;
    asm les bp, listaRAM;
    asm int 10h;
    asm pop  bp;
    asm pop  es;
    asm pop  dx;
    asm pop  cx;
    asm pop  bx;
    asm pop  ax;

Ese cacho de código viene siendo una llamada a palo seco a una señora interrupción software. En primer lugar, guarda los  registros del procesador en la pila (push). Luego guarda en AX, BX, CX y DX los valores predeterminados para "decirle" a la interrupción qué es lo que quiere. Después, se llama a la interrupción  en  sí con  "int" (la interrupción 10h, con 1100 en  AX, que es esta), y finalmente devuelve a su sitio los registros del procesador (pop), para que pueda seguir su curso.  Y "asm" indica al compilador que lo que sigue es ensamblador, así que con  eso llama al TurboAssembler.

Tras compilar y linkar, ejecutamos, y esto es lo que obtenemos: Todos los caracteres "A" de la pantalla se convierten en "A con palito" (aka "A customizada") hasta que hacemos un cls.  ¿A que mola? ^^

Un par de fotos del "antes" y "después" de la operación:

Por alguna  misteriosa razón, funciona perfectamente sobre DosBox,  no así con el símbolo de sistema (cmd). No me pregunteis por qué, pero llevo una semana volviéndome loca con esto, así que antes de moriros de asco... probadlo con DosBox xD (A mí la idea me la dio el profesor, porque hasta este momento había estado usando cmd) No he probado con otros emuladores, pero si alguien se ha aburrido y lo ha hecho, podría darnos feedback  :P