zx81 video

[bugbit]

https://8bit-museum.de/heimcomputer-2/sinclair/sinclair-scans/scans-zx81-video-display-system/
http://www.user.dccnet.com/wrigter/index_files/ZX%20Video%20Tutorial.htm
https://problemkaputt.de/zxdocs.htm#zx80zx81iomap
https://github.com/TomHarte/CLK/wiki/The-ZX80-and-ZX81
http://searle.hostei.com/grant/zx80/zx80nmi.html
https://problemkaputt.de/zxdocs.htm
https://retrocomputing.stackexchange.com/questions/6134/how-do-high-resolution-graphics-work-on-the-zx81

---

La CPU intenta obtener un byte de instrucción de código de operación del archivo de video. ULA roba ese byte como un código de carácter y en su lugar alimenta a la CPU con un byte de código de operación NOP. Inmediatamente después de eso hay un ciclo de actualización. El ULA usa la parte superior de la dirección de actualización, pero sustituye el código de carácter recién leído y el contenido de un contador interno de tres bits en la parte inferior para formar una dirección ROM. Por tanto, se devuelve una fila de un patrón de carácter. Termina en un registro de desplazamiento dentro del ULA y se convierte en video.

Toda la RAM es estática, por lo que este mal uso del ciclo de actualización no es problemático.

El contador de tres bits se puede restablecer mediante software, al igual que la parte superior de la dirección de actualización: el Z80 usa el registro I para ello. Para Manic Miner y algunos otros títulos, el truco es simplemente apuntar a una región existente de la ROM que tenga cerca del rango completo de 64 caracteres posibles lo suficientemente cerca entre sí, reiniciar el contador de tres bits en cada línea y usar un mapeo mesa. Notará que no está perfectamente mapeado; ocurren distorsiones extrañas. Eso se debe en parte al mapeo de 256 valores de entrada a códigos de 64 caracteres y en parte a que no hay ningún lugar en la ROM que tenga los 64 valores de bytes posibles lo suficientemente cerca unos de otros. Entonces el juego hace todo lo posible.

No Limits y otros utilizan una observación separada: que la dirección de actualización inalterada se observa en el bus de expansión y en la RAM interna. La versión con el código de carácter y el contador de filas impuesto llega solo a los chips ROM. Así que configuraron la dirección de actualización fuera del área de la ROM y dentro del área de la RAM. Suponiendo que la RAM responde durante un ciclo de actualización, lo que sucede entonces es: la CPU intenta leer el byte de pantalla ficticio, se bloquea y reenvía, mezclado con el contador de filas y la dirección de actualización, a la ROM que no responde. La RAM responde a la dirección de actualización en su lugar. Ese valor entra en el registro de desplazamiento del ULA y se emite.

No todas las expansiones de RAM de terceros responden al ciclo de actualización, pero generalmente es una modificación simple y la mayoría lo hace de todos modos.

Para seguir un esquema, consulte, por ejemplo, el rediseñado por Ron Reuter disponible desde aquí :ingrese la descripción de la imagen aquí

La ROM es IC2, tiene sus nueve pines de dirección bajos (tres para el contador de filas, seis para el código de caracteres) conectados a ambas líneas de direcciones que salen de IC1, el ULA e IC3, el Z80. Las resistencias R18 – R26 impiden que la entrada de dirección del ULA fluya hacia el Z80. Como tanto la RAM interna como el puerto de expansión están en el mismo lado de esas resistencias que el Z80, ven la dirección que el Z80 está generando solo; no se ven afectados por el ULA. Es casi un prototipo del bus flotante del ZX Spectrum.

Las selecciones de chips son generadas por ULA; afortunadamente, son independientes de si sabe que está esperando un gráfico de personaje. Entonces, cuando la dirección de actualización generada está en la RAM en lugar de en la ROM, la selección del chip de RAM está activa y la ROM no, y la mutación de la dirección de actualización de ULA no es visible para la RAM.