Interface I y puerto 0xef

[zx81]

Buenos días,

A raíz de un mensaje en WoS (http://www.worldofspectrum.org/forums/s ... hp?t=36772) me ha surgido una duda que solo se puede resolver con el hardware real. Como sé que algunos de vosotros sois afortunados poseedores de "la cosa", quizá podáis ayudarme a resolverla.

Básicamente, y según ese hilo, el puerto 0xef no devuelve 0xff cuando no hay ninguna cinta en la unidad de microdrive. La cuestión es saber qué devuelve sin preguntar porqué, ya que el asunto no tiene sentido (o yo no se lo encuentro). Se supone que antes de hacer nada hay que seleccionar una de las 8 unidades lo que, de paso, pone en marcha el motor de la unidad seleccionada. Es entonces cuando puede saberse, por ejemplo, si la cinta tiene activada la protección de escritura o no. En caso de no haber una unidad seleccionada, lo lógico sería que devolviera 0xff o, como mucho 0xfe como si todas las cintas estuvieran protegidas contra escritura. Otros valores ya entran dentro de las limitaciones del diseño del IF1.

Vamos, que con conectar el IF1 y una unidad de MDRV basta con ejecutar este simple programa:

10 PRINT IN 239
20 GOTO 10

y dejar correr un par o tres de pantallas. Lo ideal sería poner después una cinta en la unidad y, sin hacer nada más, volver a ejecutar el programa. Pero me consta que tener cintas es mucho más difícil que tener el IF1y el MDRV así que no pediré peras al olmo.

Y si de paso, se puede mirar también qué devuelve el puerto 247 (0xf7, RS-232/LAN) por el mismo procedimiento, mejor.

Saludos y gracias por adelantado.
José Luis

[mcleod_ideafix]

En cuanto pueda hago la prueba. Tengo cartuchos, pero ninguno está en condiciones de ser leido correctamente. Si lo que necesitas es la información de si está protegido o no contra escritura, eso sí puede testearse.

De momento... ¿has repasado la información de aquí?
http://www.worldofspectrum.org/faq/refe ... erence.htm

Concretamente:

Código: Seleccionar todo

Port 0xef
Bits DTR and CTS are used by the RS232 interface. The WAIT bit is used by the Network to synchronise, GAP, SYNC, WR_PROT, ERASE, R/W, COMMS CLK and COMMS DATA are used by the microdrive system.

           Bit    7   6    5    4    3    2    1     0
                +---------------------------------------+
            READ|   |   |    |busy| dtr |gap| sync|write|
                |   |   |    |    |     |   |     |prot.|
                |---+---+----+----+-----+---+-----+-----|
           WRITE|   |   |wait| cts|erase|r/w|comms|comms|
                |   |   |    |    |     |   | clk | data|
                +---------------------------------------+

Asi en una primera lectura, leer este puerto sin cartucho dentro debería dar: valores no determinados en los bits 7, 6 y 5 (puede que sean 0, o 1, o sigan el estado del bus flotante). BUSY se usa para la red, y si no hay cable de red ni nada, entiendo que vale 0. DTR lo mismo para el puerto serie. Entiendo que valdría 0. GAP y SYNC son señales del microdrive, y si no hay cinta dentro, imagino que valdrán 0. Por último, WRITE PROT, que creo que es la interesante aquí, valdrá 0 si el cartucho no está protegido, y 1 si lo está.
Esto claro está, suponiendo que las señales usen lógica positiva.

[mcleod_ideafix]

Suponiendo que Spectaculator emule bien esto, al hacer:

Código: Seleccionar todo

PAUSE 1: PRINT IN 239

Me devuelve 6. Podría ser que GAP y SYNC usen lógica negativa (1 si no hay GAP y 0 si lo hay, y 0 si hay pulso de sincronismo y 1 si no lo hay).

Lo del PAUSE 1 antes es para asegurarme de que la lectura se realiza cuando la ULA no está dibujando la pantalla, por lo que el estado del bus flotante no afecte al resultado (el bus flotante en esos momentos devuelve $FF)

[zx81]

Gracias por mirarlo mcleod_ideafix.

Primero, confirmarte que todas las señales usan lógica negativa con lo que un bit a cero significaría GAP, SYNC o WR-PROT. La cuestión, explicada en mi primer mensaje, es que en pura teoría leer del puerto 239 no tiene sentido salvo que primero se escoja una unidad a manejar lo que, de paso, pone en marcha el motor correspondiente. Fíjate que hay una sola señal GAP, SYNC o WR-PROT en el puerto 0xef y hasta 8 drives a manejar.

Da la impresión de que cuando se lee el puerto sin haber seleccionado antes alguno de los drives y sin ninguna cinta insertada, la señal WR-Prot devuelve un 0, como si todas las unidades estuvieran protegidas.

Lo que me ha dado la impresión que hace Spectaculator es que tiene una especie de latch que almacena cual fue la última unidad accedida en R/W y cuando se lee el puerto 0xef sin haber seleccionado antes un drive devuelve algo parecido al último status que tuvo esa unidad. La prueba la he hecho configurando el emulador con dos drives, insertando una cinta en el drive 2 y el valor devuelvo es distinto según primero ejecute un CAT 1 y el IN 239 o un CAT 2 y el IN 239. Lo raro es que con cinta insertada y motor parado un IN repetido de ese puerto devuelve 5 o 6 valores del bit GAP a 1 y otros 5 o 6 valores de GAP a 0. Eso para mi no tiene sentido con la cinta parada, ya que la señal GAP en lectura es generada durante la escritura activando la señal ERASE pero no la señal WRITE (todo esto son deducciones mías sin tener un solo HW donde probar, solo viendo como se comporta y lo que hace la ROM del IF1). Sin moverse la cinta, es difícil que la cabeza lectora detecte algo que haga cambiar el GAP, digo yo.

Como es de esperar, el emulador EightyOne hace algo distinto y cuando no hay cinta devuelve un 0xef (239) siempre.

Dicen las lenguas de doble filo que la emulación más exacta es la del Spectaculator, aunque el autor del EightyOne presume de ser el único que tiene un formato específico (MDV) para representar las cintas de manera exacta. Yo, sinceramente, pongo en duda que con un controlador tan extremadamente sencillo se pueda hacer una emulación perfecta al 100% y tampoco le veo muy sentido dado que, hasta donde yo sé, nadie se inventó ningún formato nuevo de cinta.

La verdad es que todo lo que rodea al funcionamiento a bajo nivel del IF1 y los Microdrives está escasamente documentado. Y si el emulador que mejor lo hace es Spectaculator no se puede decir que el autor haya contribuido mucho a echar un poco de luz sobre el asunto. Lo más que ha hecho es hacer una especificación nueva de formato de snapshot (SZX) que es inservible para almacenar el estado del microdrive. Le mandé un correo en julio pasado al respecto y aún estoy esperando respuesta....

Gracias por tu interés mcleod_ideafix.

[mcleod_ideafix]

Vamos, que con conectar el IF1 y una unidad de MDRV basta con ejecutar este simple programa:

10 PRINT IN 239
20 GOTO 10

Antes de cada prueba, he apagado y encendido el ordenador.

Este programa, ejecutado en un Spectrum 48K "gomas" con Interface 1, sin conectar aún ninguna unidad de Microdrive da:
Para el puerto 239: siempre da 244.
Para el puerto 247: casi casi siempre da 30, excepto en algunas ocasiones, en que da 126.

Si conecto una unidad de Microdrive, sin meter ningún cartucho dentro, no hay cambios en el comportamiento de los dos puertos respecto de la primera prueba.

Si pongo una cinta de microdrive con la protección de escritura quitada (es decir, que se puede escribir en esa cinta), lo mismo, no cambia nada en los puertos.

Si a esa misma cinta le hago un CAT 1 y sin esperar al resultado, reseteo (botón reset) el ordenador y ejecuto el programa con el puerto 239, obtengo una mezcla de resultados 241 y 245, habiendo más 241 que 245. Al cabo de unos pocos segundos, se apaga el motor del microdrive y el puerto 239 me devuelve siempre 246.

Si repito la prueba del CAT pero usando una cinta que está protegida contra escritura (no tiene la lengüeta de plástico lateral) entonces la secuencia es 240 y 244, habiendo más 240's que 244. Al parar la cinta el puerto 239 devuelve siempre 246.

Ahora, algo más sofisticado. Uso la secuencia OUT 239,2: OUT 239,0 para arrancar el motor del Microdrive. En esas condiciones, el puerto 239 va devolviendo 244 excepto cuando inserto una cinta con la lengüeta (es decir, que se puede escribir en ella), y entonces el valor pasa a ser 245. Si la cinta no se puede escribir, esto es, no tiene la lengüeta, entonces me devuelve 244 (mientras la inserto devuelve 245 pero eso es sólamente porque durante la inserción se empuja momentáneamente el interruptor de detección de la protección de escritura).

Como es de esperar, una vez que he hecho la secuencia 239,2 y 239,0 cada vez que leo el puerto 239 el motor de la unidad de Microdrive se pone en funcionamiento. Cuando corto el programa, se vuelve a parar.
El puerto 247, por cierto, me devuelve siempre el valor 30, da igual que haya cinta, que no la haya, o que esté protegida o no contra escritura.

Da la impresión de que cuando se lee el puerto sin haber seleccionado antes alguno de los drives y sin ninguna cinta insertada, la señal WR-Prot devuelve un 0, como si todas las unidades estuvieran protegidas.

Pues sí. Eso es justo lo que pasa El esquemático del Microdrive y el Interface 1 puede arrojar alguna luz sobre esto:

MICRODRIVE:

En el Microdrive, la señal COMMS_OUT "capturada" por la unidad de Microdrive (recordemos que cada unidad de Microdrive se comporta como un bit de un registro de desplazamiento por el que circula esta señal COMMS_OUT) está conectada a la base de Q1 mediante la resistencia R1. Si en la base de Q1 hay 0V, Q1 está en corte y la unidad no está seleccionada. Si COMMS_OUT es suficientemente positiva, la unidad está seleccionada y Q1 se satura.

Con Q1 saturado (unidad seleccionada), circula corriente de emisor a colector de Q1, lo que hace que la unión base-emisor de Q2 se polarice directamente y en consecuencia, también se sature, circulando corriente directamente desde la toma de 9V en el emisor de Q2, hasta el colector de Q2. El colector de Q2 sirve como toma de tensión para tres elementos del Microdrive:

El motor, a través de una resistencia de limitación de corriente (R10) le llegan los 9V y cuando esto ocurre, empieza a ronronear. El colector de Q2 también está unido, mediante otra resistencia de limitación (R3), al LED que indica que la unidad está en uso.

INTERFACE 1:

Otra cosa que está unida al colector de Q2 es el interruptor detector de la lengüeta de protección. Si hay una cinta microdrive con la protección desactivada, empujará al interruptor y lo cerrará, enviando los 9V procedentes del colector de Q2 por el pin 2B, hacia el Interface 1. Si la cinta no tiene lengüeta y por tanto no cierra el interruptor, esa unidad no enviará nada al pin 2B (ver párrafo siguiente). Los pines 1A, 2A, 3A, etc, se corresponden con la cara de pistas en el Microdrive, y los pines 1B, 2B, 3B, etc, con la cara de componentes (en el esquemático del Microdrive está señalado al revés)

Si por el contrario la unidad no está seleccionada, Q2 no conduce, y tanto el interruptor detector de protección, como el LED de estado como el motor es como si tuvieran un pin sin conectar a nada (Q2 cortado se comporta como si de su emisor a su colector hubiera un cable cortado). En esas condiciones da igual que dicho interruptor de protección esté cerrado o abierto, ya que no enviará nada por el pin 2B. De hecho, el estado reportado por el Microdrive es equivalente a decir "cinta sin lengüeta". El estado del pin 2B, cuando no hay nada conectado a él, es 0V (mediante una resistencia de pulldown R33 en el Interface 1). Dicho estado va a parar a un pin de la ULA del Interface 1, mediante una resistencia de limitación de intensidad R9, que impide que los 9V lleguen "con toda su fuerza" al Interface 1.

[zx81]

Muchas gracias por la info mcleod_ideafix. Algunas veces uno tiene suerte y esta vez la buenaventura se ha aliado conmigo y el azar se ha puesto de mi parte (para usa vez que me pasa podría haber sido con la primitiva, caramba, debe ser porque no juego....).

Ayer por la tarde recibí un mensaje de un checo llamado Tomas Franke, que yo no sé si tiene que ver algo con la escena del QL, porque le comenté que no conocía el formato MDV usado por EightyOne para los microdrives y me dijo que era muy común en los emuladores de QL.

El amigo me preguntaba por si sería muy difícil modificar JSpeccy para soportar un interface HW llamado LEC que diseñó otro checo allá por 1987 y que permite ampliar la memoria del Spectrum 48, hasta 80, 272 o 528 KB de memoria no contenida que se mapea en bloques de 32 KB, uno fijo entre 0x8000-0xFFFF y otro "móvil" entre 0x0000-0x7FFF. Sé todo esto porque el hombre me ha enviado un PDF con documentación del aparato, con información de funcionamiento e incluso las instrucciones y esquemas para hacerlo en versión "real". Tú que eres un mago del HW igual te gustaría ver ese documento (no me ha dicho que el documento sea un NDA). Si te interesa, dímelo y te lo paso por correo.

El asunto de ese interface era poder ejecutar un CP/M 2.0 que usaba bien un disco RAM, los microdrives o el BetaDisk. El documento menciona que el Microdrive debe ser emulado al más bajo nivel posible, ya que el CP/M usa un formato para la cinta diferente al de Sinclair. A esto le comenté que el problema del IF1 es lo mal documentado que está, especialmente las señales GAP y SYNC. Y esta mañana tenía en el correo este regalo como respuesta, que copio tal cual y en inglés (lo siento por lo que no dominen en absoluto la lengua de Shakespeare):

Interface I ULA is quite simple. It has the data separator, that analyses the sequence of puses coming from magnetic heads. It separaes the data and the clock pulses. It uses a PLL - phase lock loop - and it needs to be synchronized first. That's why every header and every sector begins with multiple 0x00 bytes... Because 0x00 doesnt contain any data '1' bits, all incoming pulses are clocks certainly. The PLL locks on them and now we know which pulses are clock an which are data. We're bit-synchronized now. But we still do not know, where the bytes are starting. Inside ULA, there is special serial to paralell shift register, which collects the data bits from the input stream and rotate them into complete bytes. There is also the comparator, which can detect that certain pattern is just in the shift register.In Interface I it detects that 0xFFs are just in the register. And this is our SYNC signal. Just set it to 1 when 0xFF was received and put it back to 0 when something else is in.
On real Spectrum, if 0xFF is writen on the tape, the SYNC will go '1' for the moment it is in the register. No matter if it's the header or just other 0xFF of someone's data. It's the task for the operating system to compute the checksums and decide what is header and what is data.
GAP indicates there are no pulses coming from the tape head. When the erased piece of tape without the record is in touch with the head currently.
Why does it exist? Interface I ULA counts, if all 8 bits are received ot sent already. If IN or OUT operation to the data port appears and not all 8 bits are processed yet, it stops Z80 by pulling the /WAIT signal active, until all 8 bits are sent/received. Then it releases /WAIT and the IN/OUT is completed. It prevents to change or to read the data in progress. When the operation starts the software tests the GAP to ensure there is something on the cartridge, to prevent freezing forever in WAIT until someone will place recorded cartridge in. If you'll try to make PRINT IN from the data port and no recorded cartridge in (or no motor running), then you'll wait forever.

> In addition, the MDRV is emulated with MDR files. At the document you has sent I can read what the software uses his own MDRV format. That will not work with the actual MDRV emulation why the MDR format don't stores all the formatting data including the GAP sizes and handles fixed 512 bytes sector length. The same is applied to Fuse emulator and, I guess, to Spectaculator. As far I know, only the EigthyOne emulator uses a new MDV format what stores all the MDRV data, but this file format isn't documented or standarized.
>

I made some tests with .mdv and EightyOne. This file format is widely used by QL emulators.
It is the world's easiest thing to emulate it: It has no internal structure. It's the direct equivalent of the tape loop. Just the data as they go to/from Interface I data port. And when the file ends, it continues to read/write it from begining again. Gaps, sync sequences, headr flags, data bytes, checksums... as the Z80 outs them, you need just an T clock counter that reads or write one byte each x T states.

Microdrive uses stereo head, with 2 tracks. Data are recorded to both tracks at once, even bits to one track and odd bits to the others. It doubles the data rate. Thats why Microdrive is faster than some old early 80's disk drives using single density.

One bit period is 10 microseconds, there are 8 bits in byte = 80 microseconds, divided to 2 tracks = 40 microseconds.

¿No quería caldo?. Pues ale!, media docena de tazas.

Lo que me choca es que repite de nuevo que la cinta graba diferentes datos en cada canal del estéreo y, si la memoria no me falla, tú encontraste que en realidad grababa lo mismo pero desfasado.

Analizaré la info que me mandas con tranquilidad y ya te comentaré. Espero no necesitar más pruebas....

Muchas gracias de nuevo.

[mcleod_ideafix]

Lo que me choca es que repite de nuevo que la cinta graba diferentes datos en cada canal del estéreo y, si la memoria no me falla, tú encontraste que en realidad grababa lo mismo pero desfasado.

Esta información es realmente buena!!!! Sobre lo que vi en su día, lo comenté aquí:
viewtopic.php?f=15&t=2185

Y es más, estuvimos mirando qué tipo de codificación era, y resultó ser Manchester diferencial. Me gustaría saber qué opina tu interlocutor sobre estas averiguaciones que hicimos...

[zx81]

Lo que me choca es que repite de nuevo que la cinta graba diferentes datos en cada canal del estéreo y, si la memoria no me falla, tú encontraste que en realidad grababa lo mismo pero desfasado.

Esta información es realmente buena!!!! Sobre lo que vi en su día, lo comenté aquí:
viewtopic.php?f=15&t=2185

Y es más, estuvimos mirando qué tipo de codificación era, y resultó ser Manchester diferencial. Me gustaría saber qué opina tu interlocutor sobre estas averiguaciones que hicimos...

Puedo preguntarle por el tema, a ver qué opina al respecto. Al final, quizá sea verdad que en cada vuelta de cinta lee una pista diferente, pero eso no coincidiría con los tiempos que él explica justo al final del mensaje.

En cualquier caso, de la lectura detallada de tu contestación y la de él, deduzo que hay otra cosa que Fuse no hace bien. Trata los microdrives como si pudiera haber activo más de uno a la vez. Incluso en el caso de que pudiera haber más de un motor activo, dudo que el encadenamiento de unidades se siga haciendo cuando el primero de la cadena está en marcha (quiero decir que la unidad no hará un "forward" de las señales hacia el siguiente una vez éste se selecciona).

Y yo pensaba que meter un cartucho en la unidad con ésta funcionando estaba prohibidísimo...

Lo que ahora no tengo claro es la razón de lo siguiente. Partimos de una cinta SIN formatear. Del mensaje de Tomas se entiende que cuando la unidad no "ve" datos en la cinta activa la señal GAP (poniéndola a cero). Pero la rutina GET-M-BUF en 0x15EB de la ROM del IF1v2 primero espera a tener el GAP activo, luego a que se le desactive y finalmente verifica el bit de SYNC. ¿es posible que en señales aleatorias obtenidas de una cinta sin formato a veces a la unidad le de la impresión de que no hay GAP?

[zx81]

Este hombre es una mina de información. Le he preguntado acerca de tus investigaciones osciloscópicas y me ha contestado esto:

I e-mailed with Jiri Lamac today. He made some analysis too, on those day he wrote his CP/M bios. He sent me a picture from his notes, see the attachment.

The data on both tracks are not bit interleaved, but byte interleaved. First track contains the whole byte, the second track contains second byte and they are half interleaved just like the bricks in the wall and the bit period is 12us about.

Jiri Lamac es el diseñador original del LEC que comenté en otro mensaje, de una modificación de la ROM del Spectrum y del CP/M 2.0 que ejecuta el aparato (impresionante!). La imagen que me manda es algo así:

| Byte 1 | Byte 3| Byte 5 | Byte 7 |
-----| Byte 2 | Byte 4 | Byte 6 | Byte 8 |

Estoy alucinado, en serio. Tomáš me ha resuelto más dudas en DOS correos que toda la Internet en 6 meses. Como diría un amigo mío, lo importante no es saber, sino tener el teléfono del que sabe.

Ganas me dan de implementarle el LEC en la próxima versión de JSpeccy para devolverle el favor. Otro cantar ya es implementar una emulación del MDRV adecuada con esa info, teniendo en cuenta que a ver cómo te las arreglas para emular la señal /WAIT al Z80. Casi que la emulación del formato MDV es más fácil (de hecho, no es un formato....).

[mcleod_ideafix]

La imagen que me manda es algo así:

| Byte 1 | Byte 3| Byte 5 | Byte 7 |
-----| Byte 2 | Byte 4 | Byte 6 | Byte 8 |

Pues tiene toda la razón. Lo que yo observé en el osicloscopio es eso mismo. Deduje, erróneamente, que era una especie de "pepiline" por la sencilla razón de que sólo envié tres datos. Si hubiera enviado más (una secuencia del 0 al 10 por ejemplo) habría visto esto mismo, el "interleave" de los bytes. Y sí, efectivamente, el tiempo de un bit son 12us.

Creo que sería cuanto menos conveniente escribir una entrada en Wikipedia o algún sitio similar con toda esta información...

[flopping]

Muchas gracias por la info mcleod_ideafix. Algunas veces uno tiene suerte y esta vez la buenaventura se ha aliado conmigo y el azar se ha puesto de mi parte (para usa vez que me pasa podría haber sido con la primitiva, caramba, debe ser porque no juego....).

Ayer por la tarde recibí un mensaje de un checo llamado Tomas Franke, que yo no sé si tiene que ver algo con la escena del QL, porque le comenté que no conocía el formato MDV usado por EightyOne para los microdrives y me dijo que era muy común en los emuladores de QL.

El amigo me preguntaba por si sería muy difícil modificar JSpeccy para soportar un interface HW llamado LEC que diseñó otro checo allá por 1987 y que permite ampliar la memoria del Spectrum 48, hasta 80, 272 o 528 KB de memoria no contenida que se mapea en bloques de 32 KB, uno fijo entre 0x8000-0xFFFF y otro "móvil" entre 0x0000-0x7FFF. Sé todo esto porque el hombre me ha enviado un PDF con documentación del aparato, con información de funcionamiento e incluso las instrucciones y esquemas para hacerlo en versión "real". Tú que eres un mago del HW igual te gustaría ver ese documento (no me ha dicho que el documento sea un NDA). Si te interesa, dímelo y te lo paso por correo.

El asunto de ese interface era poder ejecutar un CP/M 2.0 que usaba bien un disco RAM, los microdrives o el BetaDisk. El documento menciona que el Microdrive debe ser emulado al más bajo nivel posible, ya que el CP/M usa un formato para la cinta diferente al de Sinclair. A esto le comenté que el problema del IF1 es lo mal documentado que está, especialmente las señales GAP y SYNC. Y esta mañana tenía en el correo este regalo como respuesta, que copio tal cual y en inglés (lo siento por lo que no dominen en absoluto la lengua de Shakespeare):

Muchas gracias de nuevo.

Hola compañero, ¿podrias pasarme esos esquemas y toda la info para ver ese interface?, estoy interesado en el y quiza me lo haga, muchas gracias.

[zx81]

Hola compañero, ¿podrias pasarme esos esquemas y toda la info para ver ese interface?, estoy interesado en el y quiza me lo haga, muchas gracias.

Nada más fácil amigo, porque ayer mismo lo encontré en WoS sin problemas. El documento que hay ahí es exactamente el mismo que me pasó a mi:

http://www.worldofspectrum.org/infoseekid.cgi?id=1000794

Ya nos contarás como te ha ido...

[zx81]

Creo que sería cuanto menos conveniente escribir una entrada en Wikipedia o algún sitio similar con toda esta información...

Dada la extensión, afición y nivel técnico de la comunidad espectrumera española lo que deberíamos tener es un wiki o algo en español con toda la información que hay por ahí acerca de nuestra máquina. Hay mucho en inglés, pero no poco de ello desactualizado o con errores. La CSS FAQ hace años que no se actualiza ni para corregirla.

Para la Wikipedia me parece información demasiado técnica, no estoy seguro de que tuviera cabida ahí.

A ver si entre todos se nos ocurre algo y lo podemos llevar adelante.

[Metalbrain]

Creo que sería cuanto menos conveniente escribir una entrada en Wikipedia o algún sitio similar con toda esta información...

Dada la extensión, afición y nivel técnico de la comunidad espectrumera española lo que deberíamos tener es un wiki o algo en español con toda la información que hay por ahí acerca de nuestra máquina. Hay mucho en inglés, pero no poco de ello desactualizado o con errores. La CSS FAQ hace años que no se actualiza ni para corregirla.

Para la Wikipedia me parece información demasiado técnica, no estoy seguro de que tuviera cabida ahí.

¿Qué tal por aquí?
http://scratchpad.wikia.com/wiki/Catego ... nformation

[speccy]

Desconocía ese repositorio técnico... Impresionante.