Primeros pasos en la toma de control de una Commodore 128D

Sucia pero...

 

De chico era un marginal, en lugar de tener una Commodore 64 como cualquier hijo de vecino, tenía una Atari 130 XE, debido a seguir un consejo técnico. Esto me dejó fuera de sintonía con el resto de mis conocidos, en un nicho donde era difícil conseguir software y afectó de modo profundo e impredecible qué soy hoy, supongo que si no quedé afuera del juego fue porque tuve acceso a una IBM PC muy poco tiempo despues por un pariente. De hecho, estoy escribiendo con el teclado Modelo M de 1987 de esa máquina.

La misma persona que me dió este consejo y otro más que tambien falló (comprar un microprocesador 6809E en lugar de un 6809) sin embargo fué decisiva en mi rumbo y formación, me hizo mi primera fuente 200 AC a 12 y 5 DC, me regaló mi primer osciloscopio, me ayudó a elegir y comprar mi primer tester, me explicó el funcionamiento del ULA de la sinclair y fuzzy logic y muchas más cosas que no puedo identificar, asi que nada tengo que reclamarle, nadie es perfecto.

Esa "E" en 6809 significa que el reloj necesita unos componentes externos para funcionar y eso produjo un primer impedimiento en que lo hiciera funcionar que nunca pude superar, sigue en mi lista de asuntos pendientes desde ya hace 35 años.

El consejo técnico debe haber venido por el lado de que la Atari tenía 128KB como la C128, corría a 1.8Mhz en lugar de 1 Mhz de la C64, debía ser más barata que la C128 y yo le debo haber aportado que se veía mucho más linda, cosas de chicos, pero un hecho indudable:

Atari 130XE gana

Commodore 128 parece más seria

Commodore 64 no llega a ser horrible...

Conclusión, ninguna novedad,  las decisiones puramente técnicas (y estéticas) no suelen ser las más apropiadas, hay que tener en cuenta otros factores, como la facilidad para quien intenta aprender algo, la disponibilidad de herramientas y una comunidad que le acompañe.

Quince años después de haberme desecho de la Atari 130XE, estaba en la feria del Parque Los Andes y veo algo raro, una C128D, que viene a ser una C128 pero en un gabinete con disketera y el teclado separado.

Es el mismo mother, incluso el teclado no es externo, está externalizado, tiene la misma interfaz paralela como si estuviera adentro, un cable de como veinte hilos.

Si mirás la entrada de la wikipedia, verás que en realidad parece  que se trata de una C128DCR, Cost Reduced, el gabinete metálico en lugar de plástico y el ROM de 1986, me falta abrirla para ver si tiene el chip de video 8568 que sería el tercer factor de confirmación.

La conecté y funcionó ok, fantástico, la almacené. Tiempo después me hice un ratito y la conecté a 220 V siendo de 110 V.

Ahora, quince años después, no recuerdo bien el contexto pero podría fijarme en el chat que tuvimos, un compañero de trabajo, pasabamos por temas nostálgicos cuando le conté de esta máquina y me alentó a hacerla funcionar.

Siguiendo su indicaciones, me fijé que los capacitores estuvieran ok. Le conté que recordaba haber visto un fusible intacto y cuando estaba en ello reparé en otro fusible, bien cerca de la entrada de alimentación, nada intacto. Debía estar tan ofuscado y desmoralizado en el momento del error que no reparé en este.

El fusible era el del centro abajo a la derecha

 

Me llevó dos horas netas a lo largo de varios días encontrar los adaptadores. El primero, el que además es selector de entrada, apareció rápido y lo que es notable es que en este momento no recuerdo donde lo encontré. El segundo tenía que estar en un frasco con los splitters, atenuadores y fichas de cable, como corresponde, pero nada, no lo podía hallar y cuando apareció ese frasco, no estaba. Por suerte, cuando ordené originalmente mantuve una cierta disciplina y en el mismo cajón estaban unas antenas de TV y estaba conectado a una de ellas.

La conecté con gran pánico y encendió el led de arranque, prendió y apagó el de la disketera, vamos bien. Conecté a la entrada de TV con unos mínimos sufrimientos y acá está:

 

Primer arranque

Esas letritas raras tras el ready se deben a que tenía el keylock apretado, son caracteres gráficos.

Tras palpar un poco determiné que en gran medida la baja calidad se debe al adaptador selector.

 

Adaptadores

 

¿Qué se puede hacer con esto?

Primero limpiarla un poco.

La verdad verdad es que no me interesa para jugar, para eso están los emuladores y si en todos estos años no los he usado, algo debe significar. Tampoco programarla, para eso están los emuladores y otro montón de otras arquitecturas más actuales y provechosas.

 

Video

Tengo que encontrarle un propósito y como lo que más me interesa ahora es FPGA y gracias a DVGHV aprendí mas o menos a lidiar con señales VGA, lo que me resultaría provechoso e interesante es tomar la señal y superponer la pantalla en una ventana, utilizando la placa PYNQ que tiene entrada y salida HDMI. Debería tomar cada cuadro de la C128 y superponerlo en algún lugar encima de lo que venga de la computadora por HDMI, tipo como eran las primeras placas aceleradoras 3D.

Para esto no necesito cargar ningún programa, sólo descifrar cual de las tres interfaces me conviene, tiene olor a megaproyecto, es más de lo que estoy dispuesto a hacer en estos días.

 

CP/M vía diskete

 

Me produce una atracción perversa arrancar en modo CP/M, pero esto requiere cargar desde floppy. Esta es mi cadena de dependencias:

• Comprobar que desde PC se pueden formatear y grabar diskettes para Commodore.
  
• Conseguir una fuente AT.
  
• Armar una máquina con disketera de 5 1/4 con el resto de la basura que tengo, es que hace un par de años tiré demasiadas cosas.
  
• Obtener la imagen de CP/M.
• Obtener el sistema operativo y software para grabar el disco.
• No sé si la disketera funciona.

 

CP/M vía emulador de disketera

Tengo un camino mejor y que representa ingenio a diferencia de lo anterior que es sólo copiarse de esfuerzos ajenos: descifrar como con un microcontrolador simular una disketera 1571 o 1581.

• Obtener la especificación de comunicación.
• Implementarla en un microcontrolador.
  
• Obtener la imagen de CP/M.
• Ponerla en la eeprom del microcontrolador.
• Servirla en el momento apropiado.
  

Hay menos factores librados al azar. Pero debe ser increiblemente difícil, por más que los detalles de bajo nivel los debe estar resolviendo el microprocesador 6502 de la disketera.

Este proyecto no es novedoso, hay varios modelos dando vueltas por ahí, incluido un emulador para Raspberry Pi 3 que no descarto utilizar.

Para cargar otros programas, tengo otras posibilidades adicionales.

 

Carga vía cartridge

 

Este es bastante interesante, usar un microcontrolador que se haga pasar por un cartridge:

• Obtener el pinout, protocolo y timing.
• Implementar la emulación con el microcontrolador
• Obtener algún programa
• Ponerlo en la eeprom del microcontrolador
• Conectar 

Con un ATMega328p me parece que no alcanza aunque corra a 20Mhz. Quizás si podría con la placa NUCLEO que vengo usando en un trabajo práctico y corre a 180Mhz, más que es tolerante a 5V, pero tendría que ver bien, anticipándome y viendo EasyFlash3 y C64-Pi parece que entramos en terrenos de FPGA. De un modo u otro me parece que me queda grande.

 

Carga vía emulador datassette

Conseguir archivos guardados en cassettes en formato wav o mp3 y meterlos no por el datassette que tengo, que no sé si funciona sino desde la placa de sonido:

• Identificar la entrada de audio.
• Comprobar que tenga un nivel electrónico apropiado para la salida de una compu o mejor aún un reproductor de mp3, como puede ser un celular viejo.
  
• Armar algún tipo de conector.
• Obtener algún programa.
• Ponerlo en el reproductor
  
• Cargarlo.

Este es de los menos interesantes pero quizás esté a mi alcance y prefiero terminar esta nota habiendo hecho algo concreto, no sólo planes que quién sabe cuándo y sí los ejecutaré.

Y ya empezamos mal, no sé por qué pensé que iba a ser como con la Spectrum que podías usar cualquier reproductor de cinta. No logro encontrar documentación, lo mejor es la existencia de un adaptador llamado C2N232 que permite hacer que una PC se haga pasar por el datassette mediante una conexión RS-232.

Si tomara ese camino el único mérito sería portar el firmware a un ATMega328p, que no sería poco porque está escrito en unas 700 líneas de assembly, mmmh.

Quizás estoy cometiendo el error de pensar que por que la comunicación es analógica, tal como indica sound input/output en el pinout del cassette de MSX tomado de un foro que hallé mientras buscaba algo que desambigüe el sentido de CASSETTE READ/WRITE, lo que me llevó al foro correcto.

Pinout MSX

Llevaré adelante el siguiente experimento, cuyo objetivo es determinar si la interfaz entre la CPU y el datassette es digital o analógica.

1. Identificar la entrada y la salida de datos.
   
2. Desarmar el datassette para poder medir sin armar conector.
3. Encontrar un cassette.
   
4. Escribir un programa
5. Salvarlo
   
6. Capturar la señal
   
7. Analizarla

 

1 Pinout

+----+----++----+----+----+----+
| A1 | B2 || C3 | D4 | E5 | F6 |
+----+----++----+----+----+----+

 

Pinout Datassette C64

 

2 Punto de medición

 

Interior Datassette

Con conector

 

Mesa de trabajo

3 Cassette

 

Listo

 

4 Programa

 

10 A=A+1
20 PRINT A
30 GOTO 10

 

5 Salvarlo

 

SAVE "ONE",1,2

 

Proceso de grabación completo

De paso observá que se ve muy bien, esos adaptadores y el cable de audio RCA evidentemente nada aportaban, le soldé una ficha RCA a un cable coaxial, RG11 o similar, el patrón de interferencia es de la cámara del celular. Es un motivo menos de preocupación, se veian unas rayitas horizontales muy cortas que en mi experiencia con PC indicaban fallo de la memoria de video, ahora no están más.

 

6 Capturas

 

Captura como 35 segundos completa salvo...

...el comienzo, donde se ve la bajada del sensor

Todo igual...

Detalle pulsos

Para ver si ganaba información capturé apretar play/stop sin intervención de la compu, nada.

Play Stop

 

Ampliación de las zonas marcadas en orden cronológico:

Inicio sensor y motor

Pulsos iniciales de lectura

Pulsos finales de lectura

No se si habrás observado, el violeta que es 6.2 V no regulados, no sé si lo que cáe es normal, a mirar el datassette por dentro.

Le conecté 4 V regulados y el motor anduvo, aún bajando hasta 3 V, no sé si a la velocidad apropiada, falla al rebobinar. Esto es un problemilla, C128 no está proveyendo el voltaje o la corriente apropiada. 

Volví a conectarlo a la C128 y obtuve resultados distintos, no hay señal salvo unos ruiditos del datassette a la C128. De paso capturé dos programas de distinta longitud:

Programa corto

Programa largo

Si te fijás bien, verás que los bloques del medio son distintos.

 

7 Análisis

 

No funcionó la grabación en sí, ya que parece que la señal "cassette motor" no es suficiente, me falta electrónica para lidiar con esto, supongo que debería poner un transistor que aumente la corriente.

La C128 ni se enteró, tras el save desactivó el video unos segundos, demasiados quizás. Luego dijo "ok". Esto significa que si quiero capturar, tengo que poner "cassette sense" a tierra.

No hubo ninguna manifestación de cambio, ni en el pin de ida ni el de vuelta, sólo esa señal cuadrada con período 380 uS, 2.64 khz, 400 uS, 250 khz en el segundo intento. Esto es bueno, la señal parece digital, con un microcontrolador debería poder capturarla con un GPIO y reproducirla luego.

El microcontrolador candidato preferido es el ATMega328p debido a manejarse con 5V, pero tiene muy poca RAM.

Como no puedo leer, no sé si la reproducción debería ser igual a la grabación, voy a apostar a que si. O quizás sería buena idea buscar algún manual. Si alguien que sabe me quiere tirar alguna pista, no me ofende.

Prometo que si hago algo más lo publicaré, lo que pasa es que esta nota es producto de mi alta procrastinación.

 

 

 

 

Para estudiar Designing Video Game Hardware in Verilog

El libro cuenta la evolución inicial de los video juegos, desde la nada de un generador de barrido y unos simples circuitos digitales hasta una CPU de 16 bits, pasando por sprites por hardware y video juegos hechos completamente sin CPU.

Para hacer los ejemplos tiene una plataforma de emulación online excelente https://8bitworkshop.com/ muy muy buena, que permite no tener que saber casi nada y concentrarse en la esencia del libro que no es FPGA ni Verilog.

Si hiciste la transición de programación (no)estructurada a objetos, esta es la inversa, partís de objetos, la pelotita del pong son unos circuitos, no unos valores abstractos en memoria.

 

Ejemplos

 

Como en otras ocasiones, hago la adaptación a Vivado 2018 con Nexys4ddr y algún bonus si se me ocurre. Uso testbenchs, que el framework de la plataforma ofrece implícitamente. Todos los ejemplos que están para CRT y algunos para VGA a 25MHz. Yo hago todo con VGA, así hay algunas adaptaciones extra.



Todo versionado en github.

 

Capítulo 7, clock divider

 

Divisor de reloj

Sin dificultades, salvo que hay que inicializar los valores de los divisores para que funcione en el emulador.

 

Capítulo 8, binary counter

binary counter

Nada especial, con elegir en el bus de salida del contador "waveform style" -> "analog" se consigue esa formita de dientes de sierra.

 

Y gracias a la recomendación del Colo, una visualización mas fidedigna cambiando los settings de analog con "hold" en lugar de "interpolate":

 

Con "hold"

 

Capítulo 9, video sync generator

 

Acá hay que usar VGA@25Mhz en el selector de plataforma y usar estilo "analog" en vsync y hsync.

hsync se vé, vsync apenas

hsync no se distingue, pero si siete frames en vsync

 

Capítulo 10, test pattern 

 

La magia del framework provisto resuelve la frecuencia del clock de base, hay que meter un divisor para la realidad. Siendo de 25MHz y mi placa 100MHz aunque me llevó un rato darme cuenta, con dividir el reloj por cuatro estamos ok, así que tomo prestado el prescaler que ya había tomado prestado de antes y miro que las frecuencias estén ok o pruebo directo con el monitor de descarte que ya está bastante roto de todos modos.

Tiene que dar

• vsync 57.8 Hz
• hsync 30 kHz

Capítulo 11, digits

Desde mi punto de vista este es el más importante pues hace algo que no termino de entender y a la vez hay que adaptar a VGA, por que lo que sale en la pantalla apesta:

Klingon

Tuve que pasar de tres bits (RGB) a seis bits (RGGGGB) para prender al máximo el verde. La evolución fue:



assign GREEN   = display_on && bits[~xofs];


Siendo GREEN el pin VGA_G[0]

Luego, cambié a los nombres del xdc y asigné de modo repetido

assign VGA_G[0] = display_on && bits[~xofs];
assign VGA_G[1] = display_on && bits[~xofs];
assign VGA_G[2] = display_on && bits[~xofs];
assign VGA_G[3] = display_on && bits[~xofs];

y finalmente lo hice bien:

assign VGA_G = {4{display_on && bits[~xofs]}};

Y post finalmente volví a RED, GREEN, BLUE y generé un módulo de adaptación, al cual tambien moví los pines para ver hsync y vsync en el osciloscopio, así queda limpio el módulo.


  assign HS_probe = hsync;
  assign VS_probe = vsync;
  assign VGA_R    = {4{RED}};
  assign VGA_G    = {4{GREEN}};
  assign VGA_B    = {4{BLUE}};

Y me facilita levemente el próximo paso, que es ejecutar una simulación y su salida pasarla por un programa que me muestre el render, pues esto de estar regenerando todo lleva mucho tiempo.

De paso, me ocurrió que comenzaron a haber errores incomprensibles relativos a los constraints, seleccionando explícitamente el top module se corrigió.

 

Retroceso táctico

 

Para diagnosticar mejor me propuse simular y no me funcionaba para nada la simulación. Entonces volví al ejemplo anterior, tampoco.

La corregí agregando un bloque initial donde puse todos los reg a cero, pero no en el testbench sino en el módulo mismo, video_sync_generator.v.

Teniendo entonces un ejemplo que funciona y su simulación tambien, le puse un $strobe para obtener en ???.sim/sim_1/behav/xsim/simulate.log
los valores y poder hacer un render por software.

 always @(*)
   $strobe("%b %b %d", simul_hsync, simul_hvync, GREEN );

Son cerca de 30 MB por frame.


Lo que necesito es un programita que lea el log y me muestre lo que hubiese aparecido en la pantalla, ya sea un frame o una secuencia de frames, incluso que pueda conectarlo a tail -f y verlo en vivo.



El programa es muy sencillo, toma el standard input y  lo parsea y lo comento en VGA Renderer

 

Capítulo 11, digits, otra vez

 

Teniendo el renderer la situación es esta:

VGA_G undefined

Esas franjas verde claras son XX:


tail -F .../simulate.log | tr "x" "7" | wish render.tcl

Mirando la waveform:

En rojo VGA_G undefined

Comento de paso con respecto al VGA Renderer que lo bueno de usar tail en lugar de un archivo es que se puede ir cambiando la simulación y para patrones repetitivos como lo que ha habido hasta ahora se hace render parcial:

Resultado de ir cambiando los bits de xofs

Si fuera por la adaptación de resolución de CRT a VGA la simulación online debería estar ok, no? No sé como poner el waveform para este ejemplo, así que lo simulé localmente y...

Green undefined en el original

...hay XXs en el ejemplo original.

No logré entender cómo arreglarlo ni si tiene relación con el resultado real, por el momento sigo con el próximo.

 

Capítulo 11, bitmaps

 

En la simulación anda ok salvo que sigue generando undefineds, todo el fondo verde claro.

Mal fondo

En la FPGA, horrible, ni vale la pena mostrarlo.


En https://8bitworkshop.com/v3.4.2/?platform=verilog-vga&file=chardisplay.v

 

Capítulo 12, Ball Motion

 

Falló horriblemente, me rendí un poco, dejé de hacer la adaptación y me concentré en comprender.

 

Final

Uno de los temas trata de una CPU de 8 bits que se programa con su propio assembly, claro, con el compilador en el simulador online, no recuerdo si había manera de compilar afuera. Luego una CPU de 16 bits, etc, mirá el libro, vale la pena.

Llegue hasta el capítulo 28 creo y abandoné un año, lo retomé y sorprendentemente entré en sintonía muy rápido y terminé el libro.

Algo muy interesante es que sugiere utilizar el icestick para los ejemplos, lo cual implica que la edu-ciaa-fpga es más que suficiente. Con respecto al video el clock le dá si usas (si conseguís) un CRT, pero para VGA se complica.

 

Este termina básicamente con dos frases:

In our simulator, control inputs are simply bit values sent to a module. The real world is a bit more messy.

Y otra que no tengo la paciencia de buscar parecida:

Al trasladar a una FPGA real pueden haber errores de sincronización que el emulador ignora.

¡Qué bueno que abandoné en ese momento! Sabiendo este detalle, dejo de confiar ciegamente en el código del libro y uno de estos días (meses, años) lo retomo.

Hackathon Global 2021

En mi trabajo hay cada tanto hackathones, en este caso de utilización de IA y otra vez me ha tocado ser jurado. ¿Por qué jurado? Porque hay un gran proyecto de capacitacion interna llamado "proyecto ninja" dentro del cual está encuadrada la misma competencia y como estoy cerca de la cima tengo este derecho, privilegio u obligación, como lo quieras ver.

¿Por qué jurado? Me sirve bastante ver todos los proyectos propuestos, son varios paises con diversidades, son tecnologías y metodologías de vanguardia que se están explorando y adoptando gradualmente.

¿Por qué no participante? El rol de participante no me resulta muy satisfactorio, pues es una experiencia agotadora y ya estoy medio viejo, las veces que he participado lo he hecho con equipos que han aceptado:

• venimos a aprender
• sin expectativas de ganar
• no vamos a matarnos

Quizás lo de viejo no sea tan importante, ya tenía ideas parecidas hace... bastante.

Para contrastar, he sabido de personas que en un hackathon pretérito han alquilado una habitación cerca del lugar del evento para pasar la noche programando. Ese mismo equipo se sintió muy estafado cuando quedaron cuartos entre cinco, siendo los quintos evidentemente nosotros.

No digo que esté mal, obvio, no pensamos todos igual, pero mi sed de victoria es muy moderada.

Si no fuera por el cansancio, preferiría siempre ser participante, cada tanto viene bien exponerse a la presión, incluso hubo un hackathon en el que fuí jurado por que no pude armar equipo, no por mis condiciones sino por falta de gente.

 

Con respecto a esta experiencia en sí, tengo algunas notas para compartir, algunas útiles sólo para quienes participaron de este evento, pero la mayoría espero para cualquiera en cualquier otro hackathon.

 

Para los equipos participantes

• Alguien debe velar por los aspectos técnicos, como controlar el tiempo y silenciar a quien no esté hablando, quizás deberia comenzar la última persona en exponer y que tome la posta la primera al finalizar su parte.
• Recordar que no siempre quien más sabe ni que tiene la capitanía es la mejor persona para exponer.
  
• Para evitar retroalimentación de audio, o silenciarse o usar auriculares. Podría ocurrir que como fuente de sonido este configurado el audio mismo en lugar de sólo el microfono, en ese caso seria necesario silenciarse.
• Cuando hay fallas como las de gestión del silencio o algo de la demo, no dar explicaciones ni pedir disculpas, eso come tiempo y la lástima no da puntos.
• Recordemos que en las presentaciones no es buena idea poner mucho texto.
  

Este es el resumen de fallas y su frecuencia sobre seis equipos:

• Mala gestión del silencio: 2
• Texto excesivo: 2
• Mala gestión del tiempo: 3
• No mostrar la aplicación: 2 (casi 3, un equipo preguntó al comienzo si hacian demo) 

Las dos últimas afectaban los criterios de calificación de modo explícito, las dos primeras son más subjetivas.

Si tuviera que hacer una única recomendación, sería:

Hacer algunos ensayos de la presentación con personas ajenas

Notas de color

Uno de los equipos propuso acceder al home banking mientras se maneja. Acá es ilegal interactuar con un dispositivo mientras se conduce un vehículo, no sé si en algún lugar del mundo no lo es.

No le bajé puntos a este equipo por este motivo por que, bueno, quien usa dispositivos mientras conduce no sólo es negligente, imprudente y falto de respeto por la integridad y vida tanto propia como ajena, sino que está enferma, no lo puede evitar.

No, mentira, no estaba en los criterio de evaluación... ¿o si?, ¡oh, no! ¡Me equivoqué!, uno de los criterios decía:

"Es viable llevar a cabo la idea desde un punto de vista económico, legal, de sostenibilidad e incluso moral"

¡ufa!, si me hubiese dado cuenta los hacia moco.

Otro equipo propuso un sistema de recompensas, en el cual si se detecta que alguien podría por cortar la relación, acercarle algun incentivo para que se quede, también recompensar a quien manifieste tal satisfación que se detecte (no recuerdo si dijeron exactamente cómo) que sería "evangelizador". Si se trata de una medición meramente declarativa, o sea, sin relacionar a eventos reales, esto incita al fraude. Esta técnica no es para nada novedosa, ¿quién no ha llamado al cable a solicitar un descuento esgrimiendo un me voy para otro lado?

 

Para la organización

 

• Habría que tener otro meet que haga de recepción, algunos integrantes entraban antes de tiempo por respetar demasiado el horario o equivocarse.
• Los formularios con las calificaciones deberían enviarse al final todos juntos, esto tiene que ver con...

 

La esencia de esta nota

Hay un problema al calificar que ya me había ocurrido antes en otras calificaciones en las que participé, es un proceso que conlleva un cierto aprendizaje.

Hay criterios que son bastante absolutos, como por ejemplo si se ha respetado el tiempo de exposición o si se mostró una demo. Pero otras son medio relativas, como si la idea representa algo de valor o incluso medio intermedias como si se cumple con el enunciado del ejercicio.

Esta última te puede parecer rara, pero cuando el tema es sobre como en este caso la aplicación de IA a ciertos problemas, si uno no es experto en IA y en esos ciertos problemas, quizás necesites ver varios ejemplos hasta terminar de comprender qué cumple y cuánto cumple.

Para la vez anterior y esta repetí desarrollé la técnica que paso a relatar:

Al primer equipo le puse 7 en todos los aspectos relativos.

A los equipos siguientes, ajusté lo mismo, más o menos mediante comparación.

Tuve una dificultad con el criterio de uso del tiempo, el primero lo hizo bien y le puse un 10, ya que me parecía un criterio absoluto, pero cuando ví al segundo me dí cuenta que debí haberle puesto 9 o dicho de otra manera, el problema es si a alguien inicialmente le ponés un 10 y luego aparece un posterior merece un 11.

¿Por qué 7 y no 5? Si ponemos 7 tenemos mas libertad para ir para abajo, como que estamos apostando a que el primero no lo hizo tan mal.

Una optimización si estás en mejores condiciones de calificar, sería usar 7 o 5 pero ya aplicado una cierta calificación, como si el primer equipo en realidad fuera el segundo.

 

Para graficar la situación base:

• criterio relativo 1: 5
• criterio relativo 2: 5
• criterio relativo 3: 5
• criterio relativo 4: 5
  
• criterio absoluto 1: 10

y la optimización:

• criterio relativo 1: 6
• criterio relativo 2: 4
• criterio relativo 3: 5
• criterio relativo 4: 6
  
• criterio absoluto 1: 10

 

De un modo u otro, no importa si los puntos que le estás dando parecen bajos, es justo en relación a los otros equipos ya que no estás sesgando, pero si hubiera habido un equipo al cual el resto del jurado le puso 10 y vos le hubieras puesto también 10, o sea, el equipo al que mas valoraste, le vas a manchar ese 10.

Obviamente, al adquirir experiencia, este recurso es un poco menos necesario.

Mientras escribo esto, descubro que he cometido un importante error metodológico, con una muy leve influencia en los resultados, al punto que casi cancelé la nota, pero me parece que lo que puede aportar ésta tiene más valor que ocultar mi error. Sólo es detectable si sos insider,  a ver si te das cuenta...