Puerto serie a 115.200bps en spectrum, por software

[dandare]

A vueltas con la actualización del dandanator por kempston/serie, he estado haciendo experimentos para subir la velocidad actual, de 57.600bps a 115.200bps. El ahorro de tiempo es considerable, ya que pasamos de 2:12 en actualizar una eeprom a 1:21.

A 115.200bps, los tiempos de instrucción en el spectrum van muy muy ajustados, ya que un baudio son unos 30,5 t-states, es decir, entre 7 y 8 instrucciones NOP del Spectrum.

Para darle más emoción al tema tenemos que jugar con tres variables

• 1) El Spectrum 48k y el spectrum 128k tienen velocidades distintas y si en el primero un baudio son 30,8 t-states. en el segundo son 30,4

• 2) Algunos driver USB-TTL no soportan 2 stop bits, algo standard y totalmente necesario a estas velocidades. Afortunadamente, los CH340G (los baratos) sí.

• 3) Los chips USB-serial admiten márgenes de error astronómicos para este propósito, del +- 3%, lo que vienen a ser unos 3 t-states por bit, o unos 33 por byte, es decir, un bit entero

Conseguí una versión funcional tanto en 128k como en 48k (con código reescribible), pero era inestable. Esto es porque los módulos USB-TTL usan cristales que son altamente sensibles a la temperatura, y por eso varían en ese rango de -3% a +3%.

Durante estos días me han estado dando ideas tanto Habi, como JGN (4Mhz), overCLK y mad3001 y he podido introducir mejoras en el código.

Al final, ajustar el código y probarlo en hw real era muy lento para los ajustes finos y cambios de temperatura que había que hacer, así que he programado un mini-emulador de spectrum (muy limitado) y emulador de puerto serie de tal forma que puedo probar los distintos casos. El emulador toma código compilado Z80 y lo ejecuta. Con una granularidad de cuarto de ciclo de reloj, esto es unos 70 nanosegundos, el puerto serie va cambiando de estado y mandando un fichero bit a bit, como lo haría el hw real. El minispectrum lee el puerto y va componiendo los datos, de nuevo tal y como se hace en el hw real.

Gracias al inventillo, y a las sugerencias de los compañeros, creo que tengo un código más o menos funcional, que sacaré como Rom extra para que probéis en vuestros equipos. Por si falla, también estará el loader original a 57600bps

Os dejo una captura del software en marcha

Spectrum - Serial emulator.png

[merlinkv]

¡Genial! Tiene muy buenas pinta y sería una gran mejora.

+10 a todos los implicados.

[dandare]

Una muestra funcionando en un +2A

[mad3001]

Es alucinante grabar la eprom prácticamente más rapido que con un grabador de eprom (y te ahorras sacar la eprom del dandanator)...

[shikitin]

Que cracks estáis hechos!!!
Felicidades y gracias por el curro que os montáis "por amor al arte".

[Jason_rg]

Hola Dandare

Una vez enhorabuena por una nueva función!!!

Saludos

Enviado desde mi SM-G950F mediante Tapatalk

[Radiosity]

Eres una maquina macho.

Un saludo.

[wilco2009]

Sinceramente pensaba que con un z80 a 3.5MHz no se podía pasar de 80Kbps. Entiendo que necesitas 2 bits de stop porque el ancho de pulso que eres capaz de detectar es algo más grande de lo que es necesario pero suficiente para que entre dentro de la tolerancia que te dan 8 bits seguidos.

Enhorabuena por esos resultados.

[dandare]

Sinceramente pensaba que con un z80 a 3.5MHz no se podía pasar de 80Kbps. Entiendo que necesitas 2 bits de stop porque el ancho de pulso que eres capaz de detectar es algo más grande de lo que es necesario pero suficiente para que entre dentro de la tolerancia que te dan 8 bits seguidos.

Enhorabuena por esos resultados.

Gracias a todos. Ha sido un proceso entretenido en el que he podido comprobar otra vez aquello de que la teoría y la práctica no son lo mismo. Mi primer simulador fallaba estrepitosamente porque no tenía en cuenta el margen de error del puerto serie. Era una simulación "ideal".

Los dos bits de parada son por el retorno al byte siguiente, es decir, el proceso y almacenamiento del byte recibido, la comprobación de la longitud pendiente y la vuelta a la detección del siguiente start bit.
Este código:

Código: Seleccionar todo

InvertByte:	CPL		; 4ts 
		EXX		; +4ts = 8ts Use original registers
		LD (HL),A	; +7ts = 15ts Save loaded byte to RAM
		INC HL		; +6ts = 21ts Next RAM position
		DEC DE		; +6ts = 27ts One byte less to receive		
		LD A,D		; +4ts = 31ts Check if all bytes are received
		OR E		; +4ts = 35ts
		JP NZ,BucSerial	; +10ts = 45ts Loop if some bytes remain
		

como ves, superamos con creces los 30,5ts del bit de parada y, aunque algo salvo en la lectura del bit 8, no es suficiente para compensar esto. Por eso necesitamos 2 bits de parada. En el código, el CPL se podría quitar, bien preprocesando lo enviado y mandándolo invertido (recuerda que el kempston devuelve los datos al reves) o bien inviertiendo todo una vez DE es 0. Aún así, seguimos necesitando los dos bits de parada

Realmente, el ancho del pulso puedo tardar detectarlo entre 28 y 31 ts, por lo que sí está dentro del ancho normal a 115.200 (30,5ts más o menos):

Código: Seleccionar todo

		; bit 1		; Shifted late 0,5 ts
		IN A,(C)	; +12ts = 12ts
		AND 1		; +7ts = 19ts
		OR D		; +4ts = 23ts
		RRCA		; +4ts = 27ts
		LD D,A		; +4ts = 31ts
														
		; bit 2		; Shifted late 1 ts
		IN A,(C)	; +12ts = 12ts
		AND E		; +4ts = 16ts
		OR D		; +4ts = 20ts
		RRCA		; +4ts = 24ts
		LD D,A		; +4ts = 28ts