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.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,
[Vendido] interfaz Beta Disk
Moderador: Sir Cilve Sinclair
- programandala.net
- Manic Miner
- Mensajes: 210
- Registrado: Mié Ago 04, 2010 9:20 pm
- Ubicación: España
- Contactar:
Re: [Vendido] interfaz Beta Disk
Marcos Cruz (programandala.net)
- Kyp
- Sabreman
- Mensajes: 444
- Registrado: Lun Dic 16, 2013 6:16 pm
Re: [Vendido] interfaz Beta Disk
¡Anda! Había visto ese proyecto pero no me había fijado que era tuyoprogramandala.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.
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
- programandala.net
- Manic Miner
- Mensajes: 210
- Registrado: Mié Ago 04, 2010 9:20 pm
- Ubicación: España
- Contactar:
Re: [Vendido] interfaz Beta Disk
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.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
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)
- Kyp
- Sabreman
- Mensajes: 444
- Registrado: Lun Dic 16, 2013 6:16 pm
Re: [Vendido] interfaz Beta Disk
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ónprogramandala.net escribió:2 para la longitud en octetos, 1 para la longitud en sectores
Casualmente, o no, la pantalla son justo $1B sectores así que no tiene ese problemaprogramandala.net escribió: Piensa que de otro modo no podrías, por ejemplo, cargar una pantalla en memoria sin machacar las variables del sistema...
- programandala.net
- Manic Miner
- Mensajes: 210
- Registrado: Mié Ago 04, 2010 9:20 pm
- Ubicación: España
- Contactar:
Re: [Vendido] interfaz Beta Disk
Sí, ¡menudo mal ejemplo se me ha ocurrido!Kyp escribió:Casualmente, o no, la pantalla son justo $1B sectores así que no tiene ese problemaprogramandala.net escribió: Piensa que de otro modo no podrías, por ejemplo, cargar una pantalla en memoria sin machacar las variables del sistema...
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)
- Kyp
- Sabreman
- Mensajes: 444
- Registrado: Lun Dic 16, 2013 6:16 pm
Re: [Vendido] interfaz Beta Disk
He hecho la siguiente prueba: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...
SAVE "r87" CODE 0,87
LOAD "r87" CODE 16384
y estos son los resultados:
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.......
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\!°.;
Peeeero....
Si le digo:
LOAD "r87" CODE 16384,87
Éste es el resultado:
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.
- programandala.net
- Manic Miner
- Mensajes: 210
- Registrado: Mié Ago 04, 2010 9:20 pm
- Ubicación: España
- Contactar:
Re: [Vendido] interfaz Beta Disk
No queda duda. Yo no recordaba eso. De hecho en aquella época llegué a adaptar el ensamblador GENS para usarlo con la Beta Disk.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.
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)
- Kyp
- Sabreman
- Mensajes: 444
- Registrado: Lun Dic 16, 2013 6:16 pm
Re: [Vendido] interfaz Beta Disk
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):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?
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....
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 ................
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...
¿Quién está conectado?
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 14 invitados