[Vendido] interfaz Beta Disk

Comerciantes sensatos y gente con falta de espacio en casa, aquí tenéis vuestro sitio.

Moderador: Sir Cilve Sinclair

Re: [Vendido] interfaz Beta Disk

Notapor programandala.net el Sab Jul 20, 2019 1:04 am

Kyp escribió: Lo único es que el tamaño va en sectores, no parece que se puedan grabar fracciones de sector ni hay forma de decir el tamaño en bytes,


Sí se puede. Si no, sería un grave problema. Ahora de memoria no recuerdo los detalles, pero en mi desensamblado de TR-DOS podrás encontrarlo. Si no, te lo miro cuando pueda. El caso es que, como el tamaño del fichero en octetos es conocido porque se guarda en su entrada correspondiente en la pista de directorio (o, mejor dicho, creo que solo en la cabecera propia del fichero, la misma que se usa en cinta, y que ahora no recuerdo si se guarda al inicio del fichero o en su entrada en la pista de directorio, pero da igual), el sistema puede calcular cuántos octetos debe usar del último sector ocupado, aunque efectivamente se guarde también el número total de sectores que ocupa el fichero.
Marcos Cruz (programandala.net)
Avatar de Usuario
programandala.net
Manic Miner
 
Mensajes: 209
Registrado: Mie Ago 04, 2010 9:20 pm
Ubicación: España

Re: [Vendido] interfaz Beta Disk

Notapor Kyp el Sab Jul 20, 2019 8:06 pm

programandala.net escribió:Ahora de memoria no recuerdo los detalles, pero en mi desensamblado de TR-DOS podrás encontrarlo. Si no, te lo miro cuando pueda.

¡Anda! Había visto ese proyecto pero no me había fijado que era tuyo :shock:

Pero esa es la ROM 5.03 que es la del Betadisk 128, la del Betadisk 48 es la 3.0 y sigo pensando que no funciona igual. Y es que no hay sitio en la entrada de directorio para guardarlo, son 16 bytes: 8 para el nombre, 1 para el tipo, 2 para la dirección de carga, 2 para la de ejecución, 1 para el tamaño en sectores, y 2 para el sector y pista donde está el archivo en el disco. Total 16 bytes, no cabe más información :roll:
Avatar de Usuario
Kyp
Sabreman
 
Mensajes: 329
Registrado: Lun Dic 16, 2013 7:16 pm

Re: [Vendido] interfaz Beta Disk

Notapor programandala.net el Sab Jul 20, 2019 10:27 pm

Kyp escribió:Pero esa es la ROM 5.03 que es la del Betadisk 128, la del Betadisk 48 es la 3.0 y sigo pensando que no funciona igual. Y es que no hay sitio en la entrada de directorio para guardarlo, son 16 bytes: 8 para el nombre, 1 para el tipo, 2 para la dirección de carga, 2 para la de ejecución, 1 para el tamaño en sectores, y 2 para el sector y pista donde está el archivo en el disco. Total 16 bytes, no cabe más información :roll:


He estado mirando el desensamblado de TR-DOS 5.03, pero hace meses que no manejo ese código y me es difícil seguirlo ahora, a pesar de que ya está bastante comentado.

A la hora de manipular ficheros, TR-DOS 5.03 apunta a una zona de 16 octetos, como dices, llamada "file descriptor area": 8 octetos para el nombre, 1 para el tipo, 2 para la dirección de carga, 2 para la longitud en octetos, 1 para la longitud en sectores, 1 para el primer sector de la primera pista, 1 para la primera pista. Por tanto sí está la longitud real. Lo que no recuerdo es si TR-DOS graba además, al comienzo de cada fichero de tipo BASIC o CODE, la cabecera propia de Spectrum, la que se graba en las cintas (GDOS y G+DOS lo hacen así).

Seguro que en TR-DOS 3 es similar. Piensa que de otro modo no podrías, por ejemplo, cargar una pantalla en memoria sin machacar las variables del sistema...

He encontrado esta explicación que en su día le mandé a César Hernández cuando estaba programando la emulación de TR-DOS para Pentagon en ZEsarUX:

Lo que se hace es que el sistema operativo usa un búfer para guardar
cada sector que lee del disco. Como la transferencia de sectores es de
más bajo nivel que la transferencia de ficheros, la rutina que
transfiere los ficheros sabe qué hacer con el contenido de cada sector
que va transfiriendo, hasta completar la longitud del fichero, que ya
conoce anticipadamente. Por ejemplo: del último sector de un fichero,
una vez leído del disco al búfer, se transferirá a la memoria solo el
número de octetos que completen la longitud del fichero en cuestión.

Si no recuerdo mal, TR-DOS crea el búfer de sector cuando lo necesita,
moviendo el BASIC hacia arriba para hacer hueco.
Marcos Cruz (programandala.net)
Avatar de Usuario
programandala.net
Manic Miner
 
Mensajes: 209
Registrado: Mie Ago 04, 2010 9:20 pm
Ubicación: España

Re: [Vendido] interfaz Beta Disk

Notapor Kyp el Dom Jul 21, 2019 1:50 pm

programandala.net escribió:2 para la longitud en octetos, 1 para la longitud en sectores

Si por eso digo que el TR-DOS 5 es diferente a la 3. En el 3 esos 2 bytes son la dirección de ejecución que pones cuando salvas el archivo con SAVE "nombre" CODE inicio,tamaño,ejecución

programandala.net escribió: Piensa que de otro modo no podrías, por ejemplo, cargar una pantalla en memoria sin machacar las variables del sistema...

Casualmente, o no, la pantalla son justo $1B sectores así que no tiene ese problema :wink:
Avatar de Usuario
Kyp
Sabreman
 
Mensajes: 329
Registrado: Lun Dic 16, 2013 7:16 pm

Re: [Vendido] interfaz Beta Disk

Notapor programandala.net el Lun Jul 22, 2019 2:42 pm

Kyp escribió:
programandala.net escribió: Piensa que de otro modo no podrías, por ejemplo, cargar una pantalla en memoria sin machacar las variables del sistema...

Casualmente, o no, la pantalla son justo $1B sectores así que no tiene ese problema :wink:


Sí, ¡menudo mal ejemplo se me ha ocurrido! :D

Yo usé muchísimo la Beta Disk y no recuerdo haber tenido jamás un problema con eso. No tendría sentido que un sistema operativo de disco no guardara la longitud real del fichero y la redondeara en sectores, porque en la mayoría de los casos al cargar te machacaría lo que hubiera a continuación en la memoria.

La longitud real debe quedar guardada en algún sitio, tal vez en la cabecera de cinta que permite a BASIC saber si es una matriz y demás, guardada al inicio del fichero, no en la pista de directorio.

Podemos salir de dudas haciendo una prueba muy fácil: graba un bloque de 32 octetos de la ROM, cárgalo en los atributos y mira si se te cambia de color solo la primera fila...
Marcos Cruz (programandala.net)
Avatar de Usuario
programandala.net
Manic Miner
 
Mensajes: 209
Registrado: Mie Ago 04, 2010 9:20 pm
Ubicación: España

Re: [Vendido] interfaz Beta Disk

Notapor Kyp el Mie Jul 24, 2019 9:49 am

programandala.net escribió:Podemos salir de dudas haciendo una prueba muy fácil: graba un bloque de 32 octetos de la ROM, cárgalo en los atributos y mira si se te cambia de color solo la primera fila...


He hecho la siguiente prueba:

SAVE "r87" CODE 0,87
LOAD "r87" CODE 16384

y estos son los resultados:

Imagen

Como verás, ha cargado la primera fila de todo el primer tercio de pantalla, 32x8 = 256 bytes

La entrada de directorio es así:
Código: Seleccionar todo
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00000070   72 38 37 20 20 20 20 20  43 00 00 00 00 01 05 06   r87     C.......


Y en la pista $06 sector $05 hay esto:
Código: Seleccionar todo
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00006500   F3 11 FF FF 3E 07 18 01  00 D3 FE 3E 3F 18 04 00   ó.ÿÿ>....Óþ>?...
00006510   C3 01 3D ED 47 C3 1B 20  C3 2F 3D 00 00 00 62 6B   Ã.=íGÃ. Ã/=...bk
00006520   36 02 2B BC 20 FA B7 ED  52 19 23 30 06 35 28 03   6.+¼ ú·íR.#0.5(.
00006530   35 28 F3 2B 22 B4 5C 11  AF 3E 01 A8 00 7B EB 31   5(ó+"´\.¯>.¨.{ë1
00006540   00 60 CD F1 3C EB 23 22  7B 5C 2B 01 40 1E ED 43   .`Íñ<ë#"{\+.@.íC
00006550   38 5C 22 B2 5C 21 00 3C  22 36 5C 2A B2 5C 36 3E   8\"²\!.<"6\*²\6>
00006560   2B F9 2B 2B 22 3D 5C 11  03 13 D5 ED 56 FD 21 3A   +ù++"=\...ÕíVý!:
00006570   5C 21 B6 5C 22 4F 5C 11  AF 15 01 15 00 EB CD F8   \!¶\"O\.¯....ëÍø
00006580   3C EB 2B 22 57 5C 23 22  53 5C 22 4B 5C 36 80 23   <ë+"W\#"S\"K\6€#
00006590   22 59 5C CD B7 22 23 22  61 5C 22 63 5C 22 65 5C   "Y\Í·"#"a\"c\"e\
000065A0   3E 38 32 8D 5C 32 8F 5C  32 48 5C 21 23 05 22 09   >82.\2.\2H\!#.".
000065B0   5C FD 35 C6 FD 35 CA 21  C6 15 11 10 5C 01 0E 00   \ý5Æý5Ê!Æ...\...
000065C0   CD F8 3C FD CB 01 CE 21  DF 0E CD BE 2A 21 6B 5C   Íø<ýË.Î!ß.;*!k\
000065D0   36 02 21 8B 12 E5 C3 79  3C CD 41 3D CD BD 21 CD   6.!‹.åÃy<ÍA=ͽ!Í
000065E0   BB 2A 2A 59 5C 7E FE AA  20 07 23 5E 23 56 EB 18   »**Y\~þª .#^#Vë.
000065F0   03 21 01 00 22 42 5C AF  32 44 5C 21 B0 16 CD BE   .!.."B\¯2D\!°.;


Ha grabado un sector entero y luego ha cargado también un sector entero.

Peeeero....

Si le digo:

LOAD "r87" CODE 16384,87

Éste es el resultado:

Imagen

Ahora si ha cargado 87 bytes.

De todo esto se deduce que al grabar siempre graba múltiplos de sector pero al cargar le puedes decir que cargue solo una parte pero siempre que lo especifiques directamente, si no pones nada usa el tamaño por defecto que es múltiplo de sector.
Avatar de Usuario
Kyp
Sabreman
 
Mensajes: 329
Registrado: Lun Dic 16, 2013 7:16 pm

Re: [Vendido] interfaz Beta Disk

Notapor programandala.net el Vie Jul 26, 2019 9:10 am

Kyp escribió:De todo esto se deduce que al grabar siempre graba múltiplos de sector pero al cargar le puedes decir que cargue solo una parte pero siempre que lo especifiques directamente, si no pones nada usa el tamaño por defecto que es múltiplo de sector.


No queda duda. Yo no recordaba eso. De hecho en aquella época llegué a adaptar el ensamblador GENS para usarlo con la Beta Disk.

Ahora bien, ¿qué pasa con los programas en BASIC? Si en ese caso carga sectores enteros y la RAMTOP estuviera muy justa, ¿daría error antes de cargar o machacaría lo que hubiera por encima?
Marcos Cruz (programandala.net)
Avatar de Usuario
programandala.net
Manic Miner
 
Mensajes: 209
Registrado: Mie Ago 04, 2010 9:20 pm
Ubicación: España

Re: [Vendido] interfaz Beta Disk

Notapor Kyp el Vie Jul 26, 2019 4:49 pm

programandala.net escribió:Ahora bien, ¿qué pasa con los programas en BASIC? Si en ese caso carga sectores enteros y la RAMTOP estuviera muy justa, ¿daría error antes de cargar o machacaría lo que hubiera por encima?

Los programas en BASIC parece que los trata de forma especial. Por ejemplo: el cargador en BASIC del Abu Simbel que más o menos sería este listado (lo estoy escribiendo de memoria):

10 BORDER 0: PAPER 0
20 CLEAR 26000
40 RANDOMIZE USR 15363: REM: LOAD "screen" CODE
40 RANDOMIZE USR 15363: REM: RUN "abusimb" CODE

Quedaría en el disco así:

Entrada de directorio:
Código: Seleccionar todo
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000000   61 62 75 73 69 6D 62 20  42 66 00 66 00 01 00 01   abusimb Bf.f....


Datos (un sector):

Código: Seleccionar todo
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00001000   00 0A 0D 00 FD 32 36 30  30 30 0E 00 00 90 65 00   ....ý26000....e.
00001010   0D 00 14 12 00 E7 30 0E  00 00 00 00 00 3A DA 30   .....ç0......:Ú0
00001020   0E 00 00 00 00 00 0D 00  1E 1B 00 F9 C0 31 35 33   ...........ùÀ153
00001030   36 33 0E 00 00 03 3C 00  3A EA 3A EF 22 73 63 72   63....<.:ê:ï"scr
00001040   65 65 6E 22 AF 0D 00 28  1C 00 F9 C0 31 35 33 36   een"¯..(..ùÀ1536
00001050   33 0E 00 00 03 3C 00 3A  EA 3A F7 22 61 62 75 73   3....<.:ê:÷"abus
00001060   69 6D 62 22 AF 0D 80 AA  0A 00 35 33 36 33 0E 00   imb"¯.€ª..5363..
00001070   00 03 3C 00 3A EA 3A F8  22 61 62 75 73 69 6D 62   ..<.:ê:ø"abusimb
00001080   32 22 CA 31 30 0D 80 CA  B4 5D 08 00 00 00 B4 5D   2"Ê10.€Ê´]....´]
00001090   08 00 00 00 0A 00 00 00  00 00 00 00 00 00 00 00   ................
000010A0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
000010B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
000010C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
000010D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
000010E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
000010F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................


Hasta el offset $65 es exactamente igual a lo que se graba en un TAP (el bloque de datos, no el de la cabecera), lo he comparado con un editor hexadecimal.

Precisamente son $66 bytes, lo que dice en la entrada de directorio, claro que el BASIC no tiene una dirección de carga así que parece que para programas en BASIC el primer nº es el tamaño en bytes. El segundo nº es también $66, ¿lo repite?

Luego hay dos bytes $80 $AA, siempre esos dos valores, y una serie de datos que no se interpretar que supongo será algún tipo de estructura de datos sobre el programa. Supongo que ahí estará por ejemplo la línea de inicio porque en la entrada de directorio no está y el primer nº después del $80AA parece un buen candidato a ser el nº de línea de ejecución...
Avatar de Usuario
Kyp
Sabreman
 
Mensajes: 329
Registrado: Lun Dic 16, 2013 7:16 pm

Previo

Volver a Compra-Cambio-Venta

¿Quién está conectado?

Usuarios navegando este Foro: No hay usuarios registrados visitando el Foro y 3 invitados

cron