File Segmentation

[TGB1718]

I've been writing a 6502 disassembler in CC65 mainly to provide functionality that I don't

see in the ones I've used.

 

I have it producing the file segments and their sizes and tried it on a file I created for a game I was

writing, the object file is 2K in size and assembled in MAC/65, my question is, is it normal for native

6502 assemblers to produce so many segments in a file, I just find it strange.

 

This is the output:-

Select Output Device
Screen, Printer, Disk, Cassette
Segment  1: Load:A000 End:A0FB Size:00FB
Segment  2: Load:A0FC End:A1F7 Size:00FB
Segment  3: Load:A1F8 End:A2F3 Size:00FB
Segment  4: Load:A2F4 End:A3EF Size:00FB
Segment  5: Load:A3F0 End:A4B4 Size:00C4
Segment  6: Load:A4B5 End:A5A4 Size:00EF
Segment  7: Load:A5A5 End:A6A0 Size:00FB
Segment  8: Load:A6A1 End:A6C1 Size:0020
Segment  9: Load:A6C2 End:A7BD Size:00FB
Segment 10: Load:A7BE End:A7D8 Size:001A

D5:\MAC65\CITY>

 

I compiled the same code using MADS and although it doesn't run (still trying to find all the differences between MAC/65 and MADS)

and this is just one segment:-

 

Select Output Device
Screen, Printer, Disk, Cassette
Segment  1: Load:A000 End:A7DE Size:07DE

D5:\MAC65\CITY>

[flashjazzcat]

Possibly this was a way to avoid having to buffer large segments of the object file in RAM. Unless the assembler created an abstracted table of all segment sizes on the first pass, it won't know what to write by way of a segment header until it's reached the end of said segment. If it just arbitrarily limits segments to 252 bytes, it can get away with a 256 byte output buffer.

[TGB1718]

@flashjazzcat that was my thought too, but it just sort of seemed rather small, then again disk based MAC/65

may have run in 32K which wouldn't leave a lot of memory for the processing etc.

[flashjazzcat]

When I wrote a macro assembler (based on Charles Marslett's 'A65') I ran into this exact issue, and I just went for maximum segment sizes of 252 bytes. One could just as easily remember the file position of the start of the current segment and seek back to it once the whole thing has been written out and the segment size known (in order to write the header), but I wanted to keep it simple and I wrote a stand-alone de-segmentation tool. Such fragmentation is definitely the enemy of burst IO, though. Another way around it is to keep a table in RAM of all the segment sizes, but that could get rather large in itself.

[ivop]

I believe this is a known "issue" with MAC/65. There are even utilities to merge the segments and defrag the file.

 

As for cross-assembling, try ATASM. It uses MAC/65 syntax.

 

[vitoco]

^{As @flashjazzcat said, it is MAC/65 who is "splitting" the file in those segments, but it is OK other than having extra header bytes in the XEX file.}

 

^{Back in those days, I wrote a small BASIC utility to "solve" that issue. Today, I use XEX Filter (option -z 0).}

 

[+CharlieChaplin]

Yep,

as I have read it is standard for MAC/65 and Atari Assembler (or AMAC?) to produce dozens of small segments. One may use Streamliner, PrObj or similar tools on the A8 to merge them into one single/contiguous/monolithic data segment.

 

[flashjazzcat]

As mentioned, it's also not going to help with loading speed, since the binary loader will be issuing many small IO requests even if a segment occupies a large contiguous area of memory.

[VinsCool]

9 hours ago, vitoco said:

^{As @flashjazzcat said, it is MAC/65 who is "splitting" the file in those segments, but it is OK other than having extra header bytes in the XEX file.}

 

^{Back in those days, I wrote a small BASIC utility to "solve" that issue. Today, I use XEX Filter (option -z 0).}

 

Wow I wish I knew this tool existed before today!

I've done all my executable manipulations directly through an hex editor, or disassembly code I re-created, in such a way things are now very modular, but this tool would have saved me a lot of time! hahaha  

[stepho]

On 11/21/2021 at 10:54 PM, TGB1718 said:

Segment  1: Load:A000 End:A0FB Size:00FB

The end address or the size is off by one.
Should be one of the following:

Segment  1: Load:A000 End:A0FB Size:00FC

Segment  1: Load:A000 End:A0FA Size:00FB

[vitoco]

It should be this one:

5 hours ago, stepho said:

Segment  1: Load:A000 End:A0FB Size:00FC

$FC = 252 bytes.

[TGB1718]

31 minutes ago, vitoco said:

$FC = 252 bytes.

Thanks, still coding and testing