ZX-Tools
ZXNet echo conference «zx.spectrum»
░▒▓Hi, All!▓▒░
Here we get the following glitch: the BASIC file in the $B format is not normally Who knows what Sabzh looks at in $* files when it filters them when output Max.! __ __ ! __! __! __
copied via Subzh to *.TRD. Let me explain: For a file on the ZX, in the 16
bytes of the name, the parameters 'start' and 'length' have the same value, equal to
the length of the file. If you attach the code part of the program to the BASIC block (and all smart people do this), then the physical length of the file will increase, but on 0 track it will remain unchanged. Do you get it?
Because. The subject copies any files as
ANY -FILE WITH SUCH THING WILL BE COPYED WITHOUT THE CODE PART AND,
NATURALLY WILL NOT BE ROBOTICIAN.
Also. As I understand it, Sabzh doesn’t look at the length of the file in sectors at all, but
only in bytes, which is what actually causes all the glitches (IMHO).
>This should be taken into account, fellow author!!!
to the screen??? And also, what does HoBeta attach to the files? I know that the first
9 bytes are the name and extension of the ZX file, then 4 bytes are the start and length, and
then I don’t know. On the ZX there is the volume in sectors and the beginning of the file on the disk. But when
I tried to change the volume value, the file did not appear in
Sabzh at all :( And in HoBete it says “This is not an archive of a ZX file” >:-()
By the way, no one knows why HoBeta does not work with a 3.5" drive when
itstands under the name 'A'?
!( )(__ !(__!!__) ! (__( (_!_)
________) !___ !___
Here we get the following glitch: a BASIC file in the $B format is not normally
copied via Subzh to *.TRD. Let me explain: For a file on the ZX, in the 16
bytes of the name, the parameters 'start' and 'length' have the same value, equal to
the length of the file. If you attach the code part of the program to the BASIC block (and all smart people do this), then the physical length of the file will increase, but on 0 track it will remain unchanged. Do you get it?
Because. The subject copies any files as
ANY -FILE WITH SUCH THING WILL BE COPYED WITHOUT THE CODE PART AND,
NATURALLY WILL NOT BE ROBO CAPABLE.
Taken into account in version 1.2 which copies sector by sector.
ML> Who knows what Subzh looks at in $* files when it filters them when
ML> is displayed on the screen???
Not only in $*, but in any files larger than 16 bytes. On the header, of course.
These are the first 17 bytes. Counts the header CRC and outputs the file if the CRC
matches.
Bye, Dmitry Eliseev.
... AKA Dark Lord [Imperial TEAM] [Dark Jedi TEAM].
DE> Not only in $*, but in any files larger than 16 bytes. On the heading
DE> naturally. These are the first 17 bytes. Counts the header CRC and outputs the file
DE> if the CRC matches.
Thanks a lot for the information. CRC, as I understand it, is the 17th byte.
DE> outputs the file if the CRC matches.
ML> Big senx for the information. CRC, as I understand it, is the 17th
ML> byte.
============================= from ZX.SPECTRUM ===============
Structure of the 17-byte header added to TR-DOS
files by the HoBeta.exe program:
00-07 - file name
08 - file type
09-0A - Start
0B-0C - Length
0D-0E - Length in 256-byte records (byte 0E - size in sectors)
0F-10 - Checksum
Thus, the first 14 bytes are copied from the TR-DOS directory.
Calculation of the checksum: S=S+257*Di+i, where
S initial=0
Di - byte value
i - sequence number of the byte (if I'm not mistaken, starting from 0, not 1)
C src:
union {
struct {
unsigned char tr_filename[8];
unsigned char tr_filetype;
unsigned int tr_address;
unsigned int tr_length;
unsigned int tr_tr;
unsigned int tr_crc;
} tr_head;
unsigned char head[17];
} header;
unsigned int CheckSum;
int i;
CheckSum=0;
for (i=0; i<=14; CheckSum = CheckSum + (header.head[i] * 257) + i, i++);
header.tr_head.tr_crc = CheckSum;
In one of my programs I found this funny way to calculate
the header checksum:
checksum=0;
for (i=0; i<=14;checksum+=(unsigned char)*(bufptr+i), i++);
checksum*=257;
checksum+=105; Thank you.
======================================================================================================================
Best wishes! Michael KLUG