split binary files

Por alessandro_scaccia

Resident (41)

27-03-2018, 14:15

Hi,

I'm looking for a tool that split .bin fil in 2 more little. In previous topic i found but the link is dead...

Can you help me?

Alessandro.

Entrar ou registrar-se para comentar

Por NYYRIKKI

Enlighted (6093)

27-03-2018, 15:07

You don't need a special tool for this. You can use BASIC... Something like:
BLOAD"BIGONE.BIN":BSAVE"1ST_PART.BIN",start,split_address:BSAVE"2ND_PART",split_address,end

Please see BSAVE-command documentation.
Here is also "BIN"-format description, if you have forgot...

Por alessandro_scaccia

Resident (41)

27-03-2018, 16:15

ok, but i need some explanation:

the hex offset address that a read from HxD tool start from 00000000. I think that the first address on basic is &HC000.

So, if i want to cut the bigone.bin at offset address (readed from HxD) 000036E0, what is the address on basic?

bye

Por alessandro_scaccia

Resident (41)

27-03-2018, 22:00

hi,

i make a test:

BLOAD"BIGONE.BIN":BSAVE"1.BIN",&HC000,&HD0FF,&HC020:BSAVE"2.BIN",&HD0FF,&HCFFF

Once saved the cassette file .cas and open it, i notice that had created 2 files but more more little (0,5kb and 4kb)

how do I understand the correct addresses?

Bye

Alessandro.

Por NYYRIKKI

Enlighted (6093)

27-03-2018, 22:15

Ah, ok... If the start address is 0 then we are talking probably about picture files that are technically same format but they are loaded to VRAM instead or RAM and so on MSX2 SCREEN 8 for example the file size can be even >53KB. (In BASIC RAM start address can be between #8000-#FFFE, but VRAM can be between #0000-#FFFF)

In this case most easy way to split the file is to use VRAM also during splitting... This can be done by adding ",S"-parameter. Example:

10 SCREEN 8: BLOAD"48K.BIN",S
20 BSAVE"1ST_16K.BIN",0,&H3FFF,S:BSAVE"2ND_16K",&H4000,&h7FFF,S:BSAVE"3RD_16K",&H8000,&HBFFF,S

Por NYYRIKKI

Enlighted (6093)

27-03-2018, 22:29

About your tests... naturally "end address" must be bigger than "start address"

alessandro_scaccia wrote:

how do I understand the correct addresses?

If you have trouble understanding the 7-byte header with HEX-editor, you can try this: (example for disk)

10 'Print BIN-file address info
20 LINE INPUT "Filename:";N$:OPEN N$ AS #1 LEN=7
30 FIELD #1,1 AS TP$, 2 AS BG$, 2 AS EN$, 2 AS ST$
40 GET #1:CLOSE
50 IF TP$<>CHR$(&HFE) THEN PRINT "Not a BIN-file":END
60 PRINT"Begin address: ";HEX$(CVI(BG$))
70 PRINT"End   address: ";HEX$(CVI(EN$))
80 PRINT"Start address: ";HEX$(CVI(ST$))

To explain these just in case:
Begin address = Address in RAM/VRAM where the data is loaded to
End address = Last address where the data is loaded (data length = end address - begin address : file length = data length + 7)
Start address = Address where the program is started from if ",R"-parameter is used.

When you want to do a split, you need to select that "spit_address" between begin address and end address.

Por alessandro_scaccia

Resident (41)

28-03-2018, 13:07

Ok now understand.

i create a .asc file that use your script to found the correct address.

having a test with a .bin 26kb that not load from .dsk with these parameter address:

BEGIN ADDRESS: 82DF
END ADDRESS: EE1A
START ADDRESS:82DF

BSAVE command:

BSAVE"APE1.BIN",&H82DF,&HCC00,&H82DF:BSAVE"APE2.BIN",&HCC00,&EE1A,&H82DF

The file .bin are generated correctly, first 19kb and second 8kb
But when try to bload"firstone.bin",r:bload"secondone.bin",r
fails....
i try to bload first without ,r and viceversa but nothing...

I try to use the parameter -S also, but this create two files of 16kb and not work again with bload.

Bye

Por alessandro_scaccia

Resident (41)

28-03-2018, 14:22

I notice also that your script seems to read at reverse the byte BEGIN-END-START

for example

BEGIN ADDRESS: 82DF
END ADDRESS: EE1A
START ADDRESS:82DF

are on the .bin (open with HxD):
DF82
1AEE
DF82

is correct?

Por alessandro_scaccia

Resident (41)

28-03-2018, 14:27

I read somethings of header and found it:

[.BIN]

What are the [.BIN] files?

The [.BIN] files are binary files and contain machine language. On disk, the structure is like this:
First 7 bytes of file-header:

byte 0 : ID byte #FE
byte 1+2: start-address
byte 3+4: end-address
byte 5+6: execution-address

Then follows the machine-language. Note that this is only true for BIN files on disk, because cassette-files have a separate header with the address-information in it. The structure is as follows:
First a long header with binary 1s,
10 bytes #D0 (which indicates the file type, here binary),
6 bytes for the filename,
(a short silence),
short header with binary 1s,
2 byte start-address,
2 byte end-address,
2 byte execution-address,
then follows the machine-language.
The computer recognizes the baud rate by the long header with the binary 1's. So actually, you can save in a lot of speeds, limited by the cassette-quality (about 4600 Baud is really the maximum for good cassettes).

so considering that my .bin is extracted from cassette... thinks that the header are different...

how can find the correct header?

Por alessandro_scaccia

Resident (41)

28-03-2018, 16:04

Ok,

i was wrong the command. Now it's working. I have 2 .bin files that works fine with a basic 28815 bytes.

But if put into .dsk and load into msx-basic.... voila': bytes reduced to 23432 or 24990 (ctrl pressed).
At this point the bload command:

BLOAD"APE1.BIN":BLOAD"APE2.BIN,R

not work because the SUM of 2 bin files are more than 24990 bytes..... and the system freeze.

i looking for a solution...

Por Grauw

Ascended (10821)

28-03-2018, 16:09

alessandro_scaccia wrote:

I notice also that your script seems to read at reverse the byte BEGIN-END-START

for example

BEGIN ADDRESS: 82DF
END ADDRESS: EE1A
START ADDRESS: 82DF

are on the .bin (open with HxD):
DF82
1AEE
DF82

is correct?

Yes that’s normal. The 16-bit values (words) are stored in little-endian, meaning the least significant half (last two hex digits) of the word is stored first and the most significant half (first two hex digits) is stored second. Almost all values with more than 8 bits are stored this way on Z80 (and Intel x86 too).