Translate

miércoles, 20 de julio de 2011

Formato del Cassette Virtual (Cas) de los emuladores de la Color Computer y la Dragon

El Formato que usan los emuladores de la color computer y la dragon ya esta documentado pero le faltan cosas  y no vien diferenciado entre coco y dragon.

El formato del cassette virtual (CAS) es usado por los emuladores para imitar un toca-cintas y su cinta las cuales contenian a su vez un programa o datos, estos podian ser un programa basic en los siguientes formatos:

1.- Basic Formato comprimido (Tokenizado) (.BAS). [Formato Interno: Tipo=0; Formato Binario=0]
2.- Basic Formato ASCII (.BAS) (Con CSAVE "nombre",A). [Formato Interno: Tipo=0; Formato AscII=255(&hFF)]
3.- Datos de programa (.DAT). [Formato Interno: Tipo=1; Formato Binario=0]
4.- Programa Binario (.BIN). [Formato Interno: Tipo=2; Formato Binario=0]
5.- Texto (de procesadores de palabras por ejemplo)  (.DAT). [Formato Interno: Tipo=3; Formato Binario=0]

Los Basic Tokennizados son copia de la memoria interna de la maquina que ya esta en ese formato, por eso y por ser mas pequeños era el formato predeterminado.



Extraido de 
Color Computer Technical Reference Manual (1981)(Tandy).pdf
http://archive.worldofdragon.org/index.php?title=Tape%5CDisk_Preservation#CAS_File_Format
http://www.cs.unc.edu/~yakowenk/coco/text/tapeformat.html



-------------------------------------------------------------------------------
The standard TRS-80 Color Computer tape is composed of the following items:



1. A leader consisting of 128 bytes of Hex 55

1. A leader block of $55 multiplied by the 16 bit number in location $90:91 (default 128).
Depende de la memoria 90:91 que contiene la cantidad de repeticiones)

2. A Namefile block
3. A blank section of tape approximately equal to 0.5 seconds in length; this allows BASIC time to evaluate the Namefile.
4. A second leader of 128 bytes of Hex 55
5. One or more Data blocks
6. An End of File block

The block format for Data blocks, Namefile blocks, or an End of File block is as follows:
1. One leader byte - 55H
2. One sync byte - 3CH
3. One block type byte: 00H = Namefile - 01H = Data FFH = End of File
4. One block length byte - 00H to FFH (0-255)
5. Data - 0 to 255 bytes
6. One checksum byte — the sum of all the data plus block type and block length
7. One leader byte - 55H

The End of File block is a standard block with a length of 0 and the block type equal to FFH.
The Namefile block is a standard block with a length of 15 bytes (0FH) and the block type equals 00H.
The 15 bytes of data provide information to BASIC and are employed as described below:
1. Eight bytes for the program name
2. One file type byte - 00H = BASIC 01 H = Data 02H = Machine Language
3. One ASCII flag byte - 00H = Binary FFH = ASCII
4. One Gap flag byte — 01 H = Continuous FFH = Gaps
One Gap flag byte — 00 H Según: http://www.cs.unc.edu/~yakowenk/coco/text/tapeformat.html
(The tech manual shows 01 as the code for "no gaps", but binaries saved by Extended Color BASIC actually have 00.)
5. Two bytes for the start address of a machine language program
6. Two bytes for the load address of a machine language program




The first block of a standard CAS file should be a namefile block, and the last block should normally be an EOF block.
Some games used copy protection where the number of blocks to be loaded did not match the number specified in the file header and a fake EOF block was included so a simply copy of the file would result in a truncated file.
(Esto me parece extraño, en la cabecera no hay ni cantidad de bloques ni tamaño total, solo tamaño del bloque y nada mas tiene que ver con esto, en conclusion si hay un EOF Block hay termina todo a menos que el proceso de lectura lo haga un software que utilice otra rutina)

Note that standard format CAS files may omit leaders. Use the FIXCAS utility to add leaders to more closely resemble the true Dragon cassette tape format.

Since the standard format CAS file is a fairly simple representation of the data stream read from a tape after demodulation and decoding of the audio signals, certain properties of cassette tapes cannot be reproduced, e.g. gaps of silence (at least one game loader uses this as a copy protection mechanism that needs the RAW format of CAS to work - although this doesn't store silence it does store noise in those gaps).

The above description makes it pretty easy to create CAS files. Reading CAS files can be a bit more difficult though. Data is actually represented as a stream of bits on cassette tapes, and the Dragon uses different audio signals to represent different bit values. When decoding such an audio signal into a bit stream and creating a CAS file, the structure described above might not align to byte boundaries in the CAS file. Especially the leader may not be decoded to an integral number of bytes. To make matters even worse, both leaders and sync bytes may contain noise and still be readable. A robust CAS file reader must take this into account.
For an example of a RAW format CAS file exhibiting both byte misalignment and leader noise, see Beyond Software's Kriegspiel (last modified 2009-01-04) in the download area.


Aparte de todo eso hay cosas que no dice nadie, como por ejemplo:
Un archivo BIN tiene una cabezera que hay que quitar para pasarla al CAS
La cabecera es asi:

Un número magico que es para CoCo &hFF y para DRAGON &h55

Cabecera BAS Comprimido (Tokennizado)
        Un número especial para la CoCo y una cabecera completa para dragon

CoCo Dragon
&hFF 1 - &h55
1 - Byte tipo de archivo (0=BAS | 1=DAT ; 2=BIN ; 3=TEX)
2 - Dirección de carga - integer menos significativo primero
2 - Tamaño  - integer menos significativo primero
2 - Dirección de ejecución - integer menos significativo primero
1 - &hAA