Blanck buffer with VASM and dcb or blk on amiga 500 OCS

[prb28]

In Photon's tutorial, there is a blank buffer after an imported logo, my adapted code is:

Logo:
             INCBIN     "sky.178x67x3.raw"
LogoEnd:
Blank:
            dcb.w      LOGO_LINE_FULLBPL_W_B*6,$0
BlankEnd:

Built with wasm and runned in FS-UAE the memory is blanked as expected, but when I put it in a real amiga 500 (OCS), there is still "garbage" in it.


I've tried these variants with the same result:

            dcb.w      LOGO_LINE_FULLBPL_W_B*6
            dcb.w      LOGO_LINE_FULLBPL_W_B*6,$0000
            blk.w      LOGO_LINE_FULLBPL_W_B*6

this seems to work but with pixels showing:

             dcb.w      LOGO_LINE_FULLBPL_W_B*6,$f

With some blanking code during initialization, it's ok, but it shouldn't be needed.

Someone as a clue on what's happening?
(I have some doubts during my variant tests on my gotek drive: I don't know it it puts something in cache that would mess with my disk selection)

[StingRay]

dcb.w size,value is fine and if value is 0 the memory is cleared. If you see some garbage there is most probably a bug in your code (buffer size too small for example), i.e. it doesn't have to do with the assembler. Check that your buffers have the correct size and that you don't write outside any of the buffers.

I would use ds.b to create a cleared memory block though.

[prb28]

I may have some bug, but the rest of the code is constant: setting $f to the buffer gives me some colored stripes (as expected), with 0: it's not cleaned (wild pixels).


In the vasm documentation ds.b is equivalent to dsb.b <exp>,0 and in my case it does the same result.

[roondar]

Some assemblers automatically remove zeroes at the end of a file unless a specific flag (see the manual of the assembler for what flag to change) is added. This could explain what you see if the blank area is at the end of the file.

[prb28]

Yes !
You are right, it's the last bytes of the program.
After I have a BSS_C section that is allocated at runtime.
I've added a dummy byte after the buffer and it works.


thks !

[StingRay]

Originally Posted by prb28

In the vasm documentation ds.b is equivalent to dsb.b <exp>,0 and in my case it does the same result.

Yes, it does exactly the same. blk/dcb always remind me of old and (mostly) horrible SEKA sources hence I wouldn't use these in new code (for dcb this is only valid if it is used to create a cleared block of course).

Originally Posted by roondar

Some assemblers automatically remove zeroes at the end of a file unless a specific flag (see the manual of the assembler for what flag to change) is added. This could explain what you see if the blank area is at the end of the file.

Another note regarding this, hese executables don't work on 1.3, they require Kickstart 2.0+.

[ross]

Originally Posted by roondar

Some assemblers automatically remove zeroes at the end of a file unless a specific flag (see the manual of the assembler for what flag to change) is added. This could explain what you see if the blank area is at the end of the file.

Really?
I've never experienced such a thing, but I've used vasm only few times and it has never happened to me with any other assembler.
In any case, I consider it a bad choice, if I have allocated a block of zeros is because I need it..

[prb28]

Originally Posted by StingRay

Another note regarding this, hese executables don't work on 1.3, they require Kickstart 2.0+.

My amiga 500 has a kickstart 1.3, if I understand, if I had a kickstart 2.0+ this buffer would be cleaned?

[ross]

To be clear: are you talking about the bss part of the code/data segments?
Because if this the case, yes, in 1.3 they are not zeroed.
(but this bss part are not allocated with dc.x or dcb.x)

[prb28]

Originally Posted by ross

To be clear: are you talking about the bss part of the code/data segments?
Because if this the case, yes, in 1.3 they are not zeroed.
(but this bss part are not allocated with dc.x or dcb.x)

I was asking about the dcb.x buffer.
I know, that the bss, allocated at runtime, is not cleared.

[StingRay]

Originally Posted by prb28

My amiga 500 has a kickstart 1.3, if I understand, if I had a kickstart 2.0+ this buffer would be cleaned?

The executables with a "small" BSS hunk require OS 2.0+. If your executable works on 1.3 then the reason for your problems is not the thing roondar mentioned! It is then most likely indeed a too small buffer as I have guessed before.

[ross]

Originally Posted by prb28

I was asking about the dcb.x buffer.
I know, that the bss, allocated at runtime, is not cleared.

Maybe there is some misunderstood terminology.

  SECTION NAME,BSS
  DS.B 8

give to you every time a 8 bytes zeroed space.

What do you mean by "allocated at runtime"?

This is the real difference (at least for me) for DCB and DS.
With DS at the CODE/DATA SECTION end i'm expectiong a proper constructed CODE/DATA hunk for the exe.

If I use DCB dim,0 then no BSS space should be used and the exe would work properly in every kickstart.
A flag in the assembler can be acceptable to change this behaviour but not as default..

[roondar]

Originally Posted by ross

Really?
I've never experienced such a thing, but I've used vasm only few times and it has never happened to me with any other assembler.
In any case, I consider it a bad choice, if I have allocated a block of zeros is because I need it..

Yup, really. In my case it happened with vlink (the vasm linker).

It may have been an error on my part (as in, maybe I put the wrong arguments into the assembler/linker in some way - I am not claiming to be a complete expert on Amiga OS's hunk system in any way so me screwing up is certainly possible), but when using vlink I had to add the -Z flag to keep zeroes at the end of the file (whether in BSS or in non-BSS section).

For reference, prior to running into this issue, I tended to use:

vasm -kick1hunks -Fhunk -m68000
vlink -bamigahunk -s -sc -mrel

Nowadays I use the same, but with -Z added to the vlink commandline when I know I need to keep the zeroes at the end intact. This flag, according to the manual, keeps trailing zeroes. And it works

It seems logical to me that other assemblers/linkers may also use similar tactics to optimise file size.

For reference, the resulting binaries actually worked on Kickstart 1.3 just fine but would miss the trailing zeroes (and thus could have broken graphics etc). Adding the -Z flag made them work.

[prb28]

Originally Posted by ross

What do you mean by "allocated at runtime"?

I thought the BSS section was not bundled in the file, I was wrong.

Originally Posted by ross

With DS at the CODE/DATA SECTION end i'm expectiong a proper constructed CODE/DATA hunk for the exe.

The end of my code is:

             SECTION    MyDemoData,DATA_C
... some copper allocation ....

 Logo:
            INCBIN     "sky.178x67x3.raw"
LogoEnd:
Blank:
            ds.b       LOGO_LINE_FULLBPL_W_B*6
BlankEnd:


            SECTION    MyDemoBSS,BSS_C
Screen:
             ds.b       SCREEN_SZ_B

As said roondar, the

ds.b LOGO_LINE_FULLBPL_W_B*6

seems stripped in the exe file.

[ross]

@roondar
Well, could be that vlink simply was born with 2.0+ feature in mind.

The use of the bss part in the CODE/DATA segments is very convenient but it implies understanding the differences in behavior
between KS1.x and KS2.0+ otherwise you go in search of problems
I usually (if I know that the exe should be run in KS1.x) I manually clear the end part of the section (if I need zeroed).

[ross]

Originally Posted by prb28

I thought the BSS section was not bundled in the file, I was wrong.

The end of my code is:

             SECTION    MyDemoData,DATA_C
... some copper allocation ....

 Logo:
            INCBIN     "sky.178x67x3.raw"
LogoEnd:
Blank:
            ds.b       LOGO_LINE_FULLBPL_W_B*6
BlankEnd:


            SECTION    MyDemoBSS,BSS_C
Screen:
             ds.b       SCREEN_SZ_B

As said roondar, the

ds.b LOGO_LINE_FULLBPL_W_B*6

seems stripped in the exe file.

Ok, yes, then some assembler with DS.x could act as you experienced (but a warning should be issued..).
To avoid this problematic simply use a further SECTION MyDemoBSS2,BSS and insert all you zeroed space.
Or use as is and clear manually.

No problems ever

[roondar]

Originally Posted by ross

@roondar
Well, could be that vlink simply was born with 2.0+ feature in mind.

Could be, I'm rather stubborn with my 'KICKSTART 1.3 OR BUST' attitude towards Amiga development

The use of the bss part in the CODE/DATA segments is very convenient but it implies understanding the differences in behavior
between KS1.x and KS2.0+ otherwise you go in search of problems
I usually (if I know that the exe should be run in KS1.x) I manually clear the end part of the section (if I need zeroed).

IMHO the best way to deal with zeroed sections would be to manually allocate them. For 'OS legal' code I write I try to do that mostly. Same for data files, if the OS is up I prefer allocating space at runtime using Exec and loading in the data rather than making one big executable.

There are exceptions to this in my code, but it's how I 'like' to implement such things.

[prb28]

Originally Posted by ross

between KS1.x and KS2.0+ otherwise you go in search of problems.

Do you have some links to documentations on the web?


Just one more question, when clearing this memory at initialization, am I writing on an unallocated region, or is it safe allocated buffer even if it is stripped from the exe?

[phx]

Originally Posted by ross

Well, could be that vlink simply was born with 2.0+ feature in mind.

Sort of. Also other file formats, like ELF, use the technique of not storing uninitialized space at the end of a section. So it seemed easier and made more sense to enable it by default.

I understand that it is not optimal to expect every developer to be aware of the differences between Kickstart 1.x and 2.0. But changing that now would be even more confusing.

When you create a hunk-executable with vasm (-Fhunkexe) you have to enable this feature by the -databss option, but vlink does it always, unless -Z was specified. Yes... I'm not happy about these choices myself.

Originally Posted by prb28

Do you have some links to documentations on the web?

There is not much about the hunk-format. Best source for me was the Amiga Guru Book.

Just one more question, when clearing this memory at initialization, am I writing on an unallocated region, or is it safe allocated buffer even if it is stripped from the exe?

It is allocated, of course. But Kickstart 1.x misses to clear the extra allocated area.

[prb28]

Originally Posted by phx

There is not much about the hunk-format. Best source for me was the Amiga Guru Book.
It is allocated, of course. But Kickstart 1.x misses to clear the extra allocated area.

Thank you all, I've a clearer view of these allocations.