Altirra- Grabación archivos CAS

[Suppawer]

Saludos. Escribo esto como complemento a lo que comentamos en otro tema del foro.
Como algunos sabrán, el 27 de diciembre del 2015 fue un día importante. Desde la versión 2.80 test 5 de Altirra, podemos grabar archivos CAS en el emulador.

La secuencia de uso es la siguiente:
Cassette->New Tape
Cassette->Tape control (presionar botón "rec")
Grabar en el emulador.
Cassette->Save

Tuve éxito inmediato (aceleración c:Patch -cassette SIO desactivada) con SITRE, pero con otros copiadores tuve problemas. Estuve probando el NHP 2.56 y extrañamente, siempre tenía problemas en el último bloque:

Spoiler: MOSTRAR

Era muy extraño y se lo comenté a su creador. Esta fue su respuesta:

This is due to a bug in the Atari OS. It has a rare bug where it incorrectly measures the baud rate of the incoming tape signal when the start or end of the sync byte is immediately before the vertical blank interrupt. This is happening consistently on the last record of the tape due to the emulator having fully deterministic timing. It doesn't happen with OS-B or if you manually trigger the tape load to jitter the timing. Some of the guys in Poland made a synthetic testing tape with 10,000 records and found that about 0.1% of the blocks fail on a real Atari with the XL ver.2 OS and the entire tape was never able to load without patching the OS.
As for why it only happens when you save and reload the tape, the CAS format only stores gaps to millisecond precision, so the blocks get shifted by a tiny amount on save. About 1/7000th of a second is enough to avoid (or cause) the bug.

Adicionalmente, otro usuario en el foro agregó un comentario respecto a otro problema con un archivo cas:

Regarding to the "Bruce Lee Problem"

It still happens that the baudrate is incorrectly set and the bootloader is aborted.

Perhaps this can help.
In altirra 2.70 I get a pokey-divider of a steady $5BE, where in 2.80 it's a steady $5D4.

A lo que el creador de Altirra contestó:

Internal precision of the CAS translation is improved slightly in 2.80, so the timing changed. $5BE is the closest divider for 2.70 and $5D4 is the closest for 2.80.

As I've already noted, the current failure on this tape and configuration are due to the timing triggering the bug in the OS ROM on that one particular block. I will not make a change to "fix" this that simply moves the problem to another tape or configuration.

Todo era muy extraño. Y lo principal, ¿Por qué con SITRE no tuve estos problemas?

Decidí probar el NHP 2.56 con los otros sistemas operativos:

Spoiler: MOSTRAR

Con todos tuve el mismo problema, hasta que lo probé con el Atari 400/800 OS-B NTSC y funcionó bien, incluso después probándolo en Atari XL/XE OS ver.2. (En mis pruebas detecté diferencias en la duración del "pito"/ruido inicial: Con Atari 400/800 OS-B aprox. 10 segundos y con los otros aprox. 20 segundos).

Conversando con mr-atari, respetado usuario holandés, me facilitó un poco comentado OS: REV2-UHSIO (2015), que genera correctos archivos cas:

REV2-UHSIO is a build from my own MyBIOS (for Atarimax MyIDE-hardware).
Supports SIO,HSIO,bit7_SIO and UHSIO (with external clock).
Also I changed the tape-loading to support digital-playback devices upto 6000 baud.

Hay mucho aún por probar: otros nhps, stacs (pelusasoft), los CAIN, etc.

PD: Adjunto el RE2-UHSIO.ROM (agregarlo a "Firmwares Images"-> "XL/XE Kernel ROMS")

[vitoco]

Todo era muy extraño. Y lo principal, ¿Por qué con SITRE no tuve estos problemas?

Sin entender muy bien el problema y por qué afecta al último bloque de EOF, me aventuro a decir que SITRE no usa ese último bloque... el XEX está en memoria completito antes de llegar al último bloque.

Si ven lo que escribí en el hilo de SITRE, notarán que el punto 2 menciona que se graba un EOF falso. El bloque EOF verdadero se graba al final del XEX, cuando SITRE no intentará leer más bloques con formato propio (que no los hay). Si ese bloque EOF quedó corrupto, da lo mismo, pero creo que no lo está, pues si hay algo con el timming de grabación, justo antes de escribir ese bloque, se activa la ROM del SO, deshabilitando los parches que puse para aumentar la velocidad.

[vitoco]

Otra cosa... no sé si sea el caso de otros copiadores, pero para SITRE es importante qué versión sea la ROM, ya que la copia a RAM y la modifica en puntos predefinidos. Si haces correr SITRE con una ROM alternativa, es probable que las ubicaciones de la rutina para grabar en cassette hayan cambiado, y por lo tanto al modificar se tendrá simplemente una rutina corrupta y un comportamiento extraño.