Por qué existe una sección para el QL?

[na_th_an]

Como por ejemplo por qué demonios no era compatible con el spectrum

Porque es un PC.

[Gandulf]

Cuando uno ve tus post, Morgan, no sabe si estás de broma (y en ese caso hay que reconocer que algunos comentarios realmente son buenos), o si estás en serio y por consiguiente tienes un total desconocimiento de la máquina o máquinas que tanto amas.

Voy a contestar como si tu post fuera en serio al segundo punto, a tus dudas sobre el PC 200, al primero ya te contestará la gente de speccy.org (aunque cae de cajón que hay una sección de QL porque hay gente que la mantiene y aporta cosas suficientes para que exista, no se va a montar una zona del foro para que alguien haga un par de preguntas o comentarios).

¿Cómo va a ser compatible el Sinclair PC 200 con Spectrum? Si bien un artículo de la MH previa a la aparición de esta máquina especulaba sobre esta posibilidad, obviamente el producto final, que es el que tienes en posesión no puede ser compatible Spectrum, porque no deja de ser un PC normal y corriente XT bastante cutre, con el poco acierto de no poder conectar tarjetas de expansión sin tener que tener desmontada la tapa trasera, lo cual lo convirtió posiblemente en el peor ordenador PC de la historia. La posibilidad de conectar un PC a un televisor que da este ordenador no hace sino poner de manifiesto el poco acierto que tuvo la persona que ideó esta máquina, no se si intentando aprovechar la marca Sinclair para vender un truño, o si pensando que un PC es un ordenador de 8 bits; me inclino por lo primero.

No se le añadió un Z80 y una ULA o los circuitos necesarios para dar la posibilidad de iniciar o poner el ordenador en modo "Spectrum" (lo que en mi opinión al menos le daría el punto de la nostalgia), por lo tanto la diferencia entre tener un Sinclair PC 200 o cualquier otro PC compatible de la época es inexistente, salvo por el extraño diseño y por el color, que puede gustar o no.

Otra cosa de Amstrad que era para darles de comer aparte era la CGA esa que se sacaron de la manga con el modo en baja resolución y 16 colores fruto de su mentalidad de hacer las cosas a su bola y sin pensar en los estándares. Cuando ya existía la EGA y probablemente la VGA o al menos sus especificaciones, que sentido tiene "inventarse" un modo gráfico no compatible con el estandar CGA y no soportado ni por la BIOS ni por el software existente. De circo.

[Rinconete]

Si no recuerdo mal, el PC200 no era más que un PC1512 de color negro. Por tanto, no era mala máquina (tuve un 1512 que aún conservo y al que le tengo gran aprecio). Entonces se presentaba como un intento de aprovechar la marca Sinclair para vender un ordenador que ya se vendía bajo el distintivo Amstrad sin aportar nada nuevo. Y es verdad que aunque se trataba de una máquina bastante potente para la época, con un modo gráfico "propio" de 640x200 (si no recuerdo mal) y 16 colores, apenas lo usaba nadie (recuerdo algún juego de Infogrames). Y desde luego no tenía nada que ver con la serie Spectrum, sólo el color negro y el fabricante.

Morgan, aclárame, ¿se suministraba con MSDOS, CP/M y GEM DESKTOP? (como el 1512)

[mcleod_ideafix]

Lo de CP/M no lo recuerdo que se suministrase, pero sí con otro producto de Digital Research, el Gem Desktop.
El PC200 es de hecho el único PC que existe en el museo de la Escuela de Informática, aquí en Sevilla, y está por esa sutil ligazón con las máquinas originales de Sinclair.
El que tengo en el museo, además, lleva su coprocesador matemático instalado y todo Y es de los pocos PC's XT que llevaban de serie una disquetera de 3,5'', y el primero (?) que añadió salida de video compuesto a la salida CGA.
Digo de los primeros XT con salida de video, porque la generación anterior, el PC (a secas) de IBM, en su tarjeta gráfica original MDA / CGA, sí incluía también la salida de video. Los XT creo que ya se vendieron sin la salida de video, sólo la digital de 9 pines.

No es descabellado pensar que esa máquina pudiera haber sido diseñada con soporte de compatibilidad con el Spectrum, aunque fuera sólo el de 48K. Recordad que el Z80 y el 8086 son compatibles a nivel de código fuente. Esto es, un programa escrito en ensamblador, y que no use técnicas de automodificación puede ensamblarse en un binario ejecutable en 8086 (los COM del MS DOS se ejecutan en el mismo mapa de memoria que un COM de CP/M, es decir, 64K de RAM).

Desde el punto de vista electrónico no es nada difícil coger una ULA (lo de la contienda se resuelve usando la señal IOCHKRDY del bus ISA) con sus 16K de memoria dinámica, más 48K de memoria estática, y mapear esos 64K en una ventana de memoria superior a 640K. Un programa de Spectrum, o la misma ROM del Spectrum, convenientemente recompilada, podría cargarse en los primeros 16K de esa ventana de memoria, digamos en D000:0000, y a partir de ahí, bastaría con:
MOV AX,0D0000
MOV DS,AX
MOV ES,AX
MOV SS,AX
JMP FAR 0D000:0000
para arrancar en el modo "Spectrum". En el código recompilado, al no haber segmentos, cualquier salto, llamada, referencia a memoria, etc. siempre estaría dentro del rango D000:0000 a D000:FFFF

Incluso el clon más utilizado del 8088, el V20 de NEC, podía trabajar en modo dual 8080 / 8088. Para pasar de un modo a otro usaba el bit 15 del registro de estado. Cuando estaba a 0, las isntrucciones eran interpretadas según el juego de instrucciones del 8086. Cuando estaba a 1, se interpretaban como si fuera un 8080. De esta forma, con bastantes limitaciones (no hay IM 2 ni registros índices ni operaciones de bit) podía tener cierta compatibilidad binaria con el Z80. Si alguien está pensándoselo, el 8086 que hay en el PC200 no es compatible en patillaje con el 8088 o sus clones. Si algo se le puede agradecer a Amstrad en este aspecto, es el haber usado la versión de 16 bits "de verdad" del 8086, en lugar del 8088.

AÑADO: pero el V30, de NEC también, sí que es compatible pin a pin con el 8086 de Intel, y también posee la facilidad de ejecutar binarios para el 8080. Morgan, quizás tu PC200 tenga un NEC en lugar de un Intel, lo que significa que tu PC200 ha estado todos estos años con la capacidad de poder ejecutar algo del código de un Z80...

[Gandulf]

La CGA del PC200 tenía entendido que tenía un modo 16 colores propio en baja resolución, si es en alta entonces es el mismo modo que el del 1512, de todas formas un modo gráfico demencial y sin sentido. Menos mal que en el 1640 metieron la EGA (me imagino que sería una EGA estándar).

El problema del PC200 es principalmente el de conectar tarjetas, no se si recordais de los artículos sobre ese ordenador; si quereis meterle una VGA por ejemplo (era bastante frecuente en los XT que los usuarios metieran una VGA o una Adlb) no se puede volver a cerrar la tapa de atrás y tiene que quedar abierta. Sólo eso echa por tierra el ordenador.

Para mi la opción de conectar la CGA a la tele es totalmente absurda, ya que en esa época no había televisiones LCD, y conectar un PC a una tele de tubo para utilizarla como monitor la considero absurda; salvo que se pensara en un PC como en una máquina de 8 bits, algo que alguien compra para jugar, conectar a la tele y punto. Mala prespectiva.

[Gandulf]

está por esa sutil ligazón con las máquinas originales de Sinclair.

No es descabellado pensar que esa máquina pudiera haber sido diseñada con soporte de compatibilidad con el Spectrum, aunque fuera sólo el de 48K. Recordad que el Z80 y el 8086 son compatibles a nivel de código

Yo no consideraría el PC200 una máquina Sinclair. Lleva el nombre pegado y el color negro porque Amstrad tenía la licencia e intentó sacar tajada del nombre Sinclair, pero cualquier parecido o herencia de esta máquina con los spectrum o el QL es nula.

En cuanto a la compatibilidad spectrum yo creo que no la tenía simplemente porque no pensaron en ningún momento en hacer un nuevo spectrum o un ordenador que de alguna forma siguiera la línea de los spectrum. Meter una ULA y haber dato incluso soporte a las cargas de cassete de una forma similar a la que le dieron los emuladores en los años posteriores podría haber sido relativamente sencillo para ellos (o incluir en la placa o como tarjeta una pequeña placa con los componentes necesarios para un modo spectrun puro) sin incrementar mucho el precio. Seguramente en ese caso muchos habríamos optado por este ordenador.

Por otra parte el QL tampoco es compatible spectrum y nadie se lo reclamó. Era una línea Sinclair diferente.

A mi personalmente el PC 200 me parece un verdadero truño, prefiero el resto de PC de la serie Amstrad de aquella época.

[mcleod_ideafix]

La CGA del PC200 tenía entendido que tenía un modo 16 colores propio en baja resolución, si es en alta entonces es el mismo modo que el del 1512, de todas formas un modo gráfico demencial y sin sentido. Menos mal que en el 1640 metieron la EGA (me imagino que sería una EGA estándar).

Pues el 1640 fue quien la cagó, por lo que recuerdo. La EGA que incorporaba era monocromática, y los juegos de EGA rehusaban cargar proque pedían la EGA color, que necesitaba 64K de memoria de video. En lugar de implementar una tarjea multimodo (Hercules/CGA/EGA) habían puesto una que pasaba de Hércules a EGA, pero sin CGA, con el resultado de que tenías que cargar antes el típico emulador de CGA para poder jugar a la mayoría de los juegos que había por entonces.

[mcleod_ideafix]

Para mi la opción de conectar la CGA a la tele es totalmente absurda, ya que en esa época no había televisiones LCD, y conectar un PC a una tele de tubo para utilizarla como monitor la considero absurda; salvo que se pensara en un PC como en una máquina de 8 bits, algo que alguien compra para jugar, conectar a la tele y punto. Mala prespectiva.

La CGA tiene las mismas temporizaciones que la TV, por lo que en realidad, el monitor CGA era una TV. DIcho de otra forma, una TV con entrada RGB puede servir perfectamente como monitor CGA (con unas resistencias y diodos para convertir la señal TTL RGBI a RGB analógica, como se hace para conectar un 128K o un QL por RGB).

¿Mala perspectiva? El Commodore Amiga también ofrecía esa opción, y vaya si se aprovechó. El PC200 se vendía con un monitor negro (a juego con el ordenador) y monocromático, así que muchos usuarios, si querían color, no les quedaba otra que conectarlo a la TV. Supongo que Amstrad quiso de esa forma explotar el reclamo lúdico que la marca Sinclair sugiere: es más barato dar la opción de poder conectar el PC a una TV, que tener que incorporar un monitor color al equipo.

[Gandulf]

Yo creo que el problema es el aspecto, tipo Amiga/Atari que le quisieron dar. Nada acertado, en mi opinión. Si se orientó hacia el lado lúdico, ¿que mejor opción que saliera de serie con EGA como poco? Mucha de la gente que pasamos de spectrum a PC ya lo hicimos con orientación profesional/desarrollo; y este PC200 no era una buena opción. Tenía buenas cosas, como la unidad de 3.5, pero creo que no fue bien parido.

Los commodore PC 20, Amstrad 1512/1640 o por ejemplo el Epson PSE-30 y similares, eran opciones mucho más apetecibles. Sólo hay que pensar una cosa: Si el Sinclair PC 200 apareciera como Inves PC 200 y fuera blanco.... ¿cuantas unidades hubiera vendido Inves? por poner un ejemplo

En resumen: Odio el PC 200!!! , quizá no sea totalmente objetivo con él.

[Rinconete]

Lo de CP/M no lo recuerdo que se suministrase, pero sí con otro producto de Digital Research, el Gem Desktop.

Si es como el que se suministraba con el 1512 no estaba mal, sólo que se comía toda la memoria. El intérprete de BASIC (Locomotive Basic) estaba chulo pero tenía ese problema.

El PC200 es de hecho el único PC que existe en el museo de la Escuela de Informática, aquí en Sevilla, y está por esa sutil ligazón con las máquinas originales de Sinclair.
El que tengo en el museo, además, lleva su coprocesador matemático instalado y todo Y es de los pocos PC's XT que llevaban de serie una disquetera de 3,5'', y el primero (?) que añadió salida de video compuesto a la salida CGA.
Digo de los primeros XT con salida de video, porque la generación anterior, el PC (a secas) de IBM, en su tarjeta gráfica original MDA / CGA, sí incluía también la salida de video. Los XT creo que ya se vendieron sin la salida de video, sólo la digital de 9 pines.

vaya, curioso

No es descabellado pensar que esa máquina pudiera haber sido diseñada con soporte de compatibilidad con el Spectrum, aunque fuera sólo el de 48K. Recordad que el Z80 y el 8086 son compatibles a nivel de código fuente. Esto es, un programa escrito en ensamblador, y que no use técnicas de automodificación puede ensamblarse en un binario ejecutable en 8086 (los COM del MS DOS se ejecutan en el mismo mapa de memoria que un COM de CP/M, es decir, 64K de RAM).

¿Pero el 8086 tiene más instrucciones no? ¿es compatible a nivel de opcodes? ¿Y el 8080 también es compatible?

Desde el punto de vista electrónico no es nada difícil coger una ULA (lo de la contienda se resuelve usando la señal IOCHKRDY del bus ISA) con sus 16K de memoria dinámica, más 48K de memoria estática, y mapear esos 64K en una ventana de memoria superior a 640K. Un programa de Spectrum, o la misma ROM del Spectrum, convenientemente recompilada, podría cargarse en los primeros 16K de esa ventana de memoria, digamos en D000:0000, y a partir de ahí, bastaría con:
MOV AX,0D0000
MOV DS,AX
MOV ES,AX
MOV SS,AX
JMP FAR 0D000:0000
para arrancar en el modo "Spectrum". En el código recompilado, al no haber segmentos, cualquier salto, llamada, referencia a memoria, etc. siempre estaría dentro del rango D000:0000 a D000:FFFF

vaya, qué sorpresa, quizá esa era idea como dices

[Rinconete]

La CGA del PC200 tenía entendido que tenía un modo 16 colores propio en baja resolución, si es en alta entonces es el mismo modo que el del 1512, de todas formas un modo gráfico demencial y sin sentido. Menos mal que en el 1640 metieron la EGA (me imagino que sería una EGA estándar).

no me parece que estuviera mal, lo que pasa es que no lo usaba nadie

El problema del PC200 es principalmente el de conectar tarjetas, no se si recordais de los artículos sobre ese ordenador; si quereis meterle una VGA por ejemplo (era bastante frecuente en los XT que los usuarios metieran una VGA o una Adlb) no se puede volver a cerrar la tapa de atrás y tiene que quedar abierta. Sólo eso echa por tierra el ordenador.

Supongo que una tapa similar a la del 1512. Eso me recuerda que tuve una Sounblaster, marca desconocida por aquéllos entonces, pero que tenía la propiedad de ser compatible con la Adlib, que era el verdadero estándar.

Para mi la opción de conectar la CGA a la tele es totalmente absurda, ya que en esa época no había televisiones LCD, y conectar un PC a una tele de tubo para utilizarla como monitor la considero absurda; salvo que se pensara en un PC como en una máquina de 8 bits, algo que alguien compra para jugar, conectar a la tele y punto. Mala prespectiva.

Sí es verdad, no tenía mucho sentido.

[Rinconete]

La CGA del PC200 tenía entendido que tenía un modo 16 colores propio en baja resolución, si es en alta entonces es el mismo modo que el del 1512, de todas formas un modo gráfico demencial y sin sentido. Menos mal que en el 1640 metieron la EGA (me imagino que sería una EGA estándar).

Pues el 1640 fue quien la cagó, por lo que recuerdo. La EGA que incorporaba era monocromática, y los juegos de EGA rehusaban cargar proque pedían la EGA color, que necesitaba 64K de memoria de video. En lugar de implementar una tarjea multimodo (Hercules/CGA/EGA) habían puesto una que pasaba de Hércules a EGA, pero sin CGA, con el resultado de que tenías que cargar antes el típico emulador de CGA para poder jugar a la mayoría de los juegos que había por entonces.

No estoy seguro pero diría que la EGA del 1640 sí tenía color, había un modelo con monitor color ¿no?

[mcleod_ideafix]

¿Pero el 8086 tiene más instrucciones no? ¿es compatible a nivel de opcodes? ¿Y el 8080 también es compatible?

Sí a lo primero. No a lo segundo y tercero.
El 8086 y el 8080 mantienen compatibilidad a nivel de código fuente. Esto significa que cualquier instrucción del 8080 (que no del Z80) tiene una instrucción equivalente en el 8086, y cada registro del 8080 tiene un equivalente en el 8086.

Si mal no recuerdo, la asignación de registros en 8080 -> 8086, era así:
A -> AL
B -> CH
C -> CL
D -> DH
E -> DL
F -> BH
G -> BL
SP -> SP
PC -> IP
(en el 8080, al registro HL se le llama FG. No existen los registros IX e IY)

En cuanto a las instrucciones, por poner algún ejemplo:

LD A,0 se convierte en MOV AL,0
LD (FG),A se convierte en MOV [BX],AL
etc...
NOTA: en realidad, en el 8080 no se usaba como nmemotécnico LD sino MOV para el segundo ejemplo o MVI para el primero, pero vamos, es sólo una cuestión sintáctica, lo mismo que llamar FG al par HL.

Es decir, que podía escribirse un ensamblador que tomara código fuente escrito para el 8080, y convertirlo a opcodes del 8086. El ensamblador internamente haría la conversión de acuerdo con las reglas que he expuesto y después ensamblaría con opcodes del 8086. Algo como:

LD A,0 (o MVI A,0) que en 8080 se traduce como 3E,00 pasa a ser:
LD A,0 -> MOV AL,0 -> se traduce en 8086 como B0,00

En cuanto al Z80, los registros IX e IY pueden asemejarse a SI y DI, y las instrucciones RST pueden asemejarse a un INT. Además, las instrucciones de manejo de cadenas LDI, LDIR, CPIR, etc. también tienen su equivalente en 8086 (STOSB, REP STOSB, REP SCASB, etc.) si bien en este caso habría un lio porque LDIR y demás usan HL y DE como punteros fuente y destino y REP STOSB usa a SI (IX) y DI (IY) . En el caso del Z80, como veis, la traducción no es tan directa como en el 8080.

EDITO: fíjate hasta donde llega la compatibilidad (en código fuente) entre el 8080 y el 8086, que en un viejo tutorial de ensamblador de 8086 se podía leer lo siguiente:

Most of the functions originally offered in DOS 1.0 were direct descendents
of CP/M functions; there is even a compatibility interface so that programs
which have been translated instruction for instruction from 8080 assembler to
8086 assembler might have a reasonable chance of running if they use only the
core CP/M function set. Among the most generally useful in this original
compatibility set are:

09 -- print a full message on the screen
0A -- get a console input line with full DOS editing
0F -- open a file
10 -- close a file (really needed only when writing)
11 -- find first file matching a pattern
12 -- find next file matching a pattern
13 -- erase a file
16 -- create a file
17 -- rename a file
1A -- set disk transfer address

Dicha compatibilidad es la razón por la que los .COM en MSDOS comienzan todos en la posición 100h. En las posiciones 0 a FFh existe lo que se llama el "prefijo de segmento de programa", que contiene cantidad de información (entre ellas, la línea de comandos con los argumentos del programa) que está definida de esa forma desde los tiempos del CP/M. Si mal no recuerdo, incluso la primera cosa que se guarda en el PSP (en la dirección 0) es ni más ni menos que un trozo de código máquina que llama a la rutina de terminación de proceso. En CP/M un proceso terminaba haciendo JP 0. En MS DOS podía terminar de la misma forma. Podéis verlo vosotros mismos usando "debug" en una ventana de MSDOS en Windows XP:

Código: Seleccionar todo

Microsoft Windows XP [Versión 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\rodriguj>debug
-d0
1599:0000  CD 20 FF 9F 00 9A EE FE-1D F0 4F 03 D3 0F 8A 03   . ........O.....
1599:0010  D3 0F 17 03 D3 0F 57 04-01 01 01 00 02 FF FF FF   ......W.........
1599:0020  FF FF FF FF FF FF FF FF-FF FF FF FF F1 0D 4E 01   ..............N.
1599:0030  BD 14 14 00 18 00 99 15-FF FF FF FF 00 00 00 00   ................
1599:0040  05 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1599:0050  CD 21 CB 00 00 00 00 00-00 00 00 00 00 20 20 20   .!...........
1599:0060  20 20 20 20 20 20 20 20-00 00 00 00 00 20 20 20           .....
1599:0070  20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00           ........
-

Lo que hay en el offset 0 (la primera dirección disponible para un .COM) es la secuencia CD 20. Eso se corresponde con la instrucción en ensamblador INT 20h, que es precisamente la instrucción de terminación de proceso para MS DOS (para los .COM, para los .EXE es distinta).

Para colmo, si miráis en el offset 0x50, vereis la secuencia CD 21 CB. Eso se corresponde con la secuencia en ensamblador: INT 21h ; RETF. Para los que recordéis la programación en ensamblador en MS DOS, ese es el punto de entrada al sistema operativo. Es decir que hacer CALL 50 en un .COM es lo mismo que hacer INT 21h... ¿lo pillais? Casi casi: CALL 5 es el punto de entrada al BDOS en los programas CP/M.

CP/M:

Código: Seleccionar todo

LD DE,Mensaje
LD C,9h
CALL 5h
JP 0
Mensaje: DEFB "Hola, mundo", 13, 10, '$'

MS DOS:

Código: Seleccionar todo

MOV DX,Mensaje
MOV AH,9h
CALL FAR PSP:50h
JMP 0
Mensaje: DB "Hola, mundo", 13, 10, '$'

Si en DOS existía todo esto, era precisamente por lo que explica el tutorial: porque era factible que se pudieran portar fácilmente programas desde CP/M hasta DOS aprovechando esta compatibilidad de código fuente entre los procesadores implicados en ambos sistemas operativos.

Dado que Windows XP (32 bits) sigue manteniendo a MS DOS como subsistema, resulta que en las entrañas más profundas del código de Windows XP, sigue existiendo esa capa de compatibilidad (como ya habreis comprobado)...

(hala! qué largo me ha quedado esto...)

[mcleod_ideafix]

Un ejercicio curioso, para quien tenga tiempo para ello, consiste en coger el código fuente de la ROM del Spectrum, traducirlo (automáticamente) a ensamblador del 8086 y generar un .COM, para lanzarlo desde una ventana de MS DOS. Al cabo de unos milisegundos de ejecución (en un procesador actual), si se lee la memora del segmento actual, comprendida entre 4000 y 5AFF, obtendremos una copia del contenido de la pantalla del Spectrum con el (C)1982...

[Rinconete]

Un post muy chulo. Qué interesante, no lo había pensado pero tal como lo cuentas parece que el paso de Z80 a 8086 es bastante directo.

El CP/M apenas lo usé, sí recuerdo haber jugueteado y probado todo lo que venía en el manual del PC1512. MSDOS era muy similar en lo referente a la línea de órdenes y era lo que usaban mis amigos entonces, así que abandoné el CP/M. Desconocía todo lo que cuentas de la compatibilidad al nivel de las funciones, pero claro tiene su lógica.

Llegué a programar bastante en ensamblador de 8086, aunque casi no recordaba lo que comentas de los COM, han pasado muchos años. Y el DEBUG, madre mía, qué herramientas más simples había entonces.