English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 04 January 2019, 16:17   #1
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 38
Blanck buffer with VASM and dcb or blk on amiga 500 OCS

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


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:
Code:
            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:

Code:
             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)
prb28 is offline  
Old 04 January 2019, 16:26   #2
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,199
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.
StingRay is offline  
Old 04 January 2019, 16:56   #3
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 38
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.
prb28 is offline  
Old 04 January 2019, 16:57   #4
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 773
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.
roondar is offline  
Old 04 January 2019, 17:06   #5
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 38
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 !
prb28 is offline  
Old 04 January 2019, 17:43   #6
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,199
Quote:
Originally Posted by prb28 View Post
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).

Quote:
Originally Posted by roondar View Post
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+.
StingRay is offline  
Old 04 January 2019, 17:46   #7
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,462
Quote:
Originally Posted by roondar View Post
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..
ross is offline  
Old 04 January 2019, 17:47   #8
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 38
Quote:
Originally Posted by StingRay View Post
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?
prb28 is offline  
Old 04 January 2019, 17:54   #9
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,462
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)
ross is offline  
Old 04 January 2019, 17:59   #10
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 38
Quote:
Originally Posted by ross View Post
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.
prb28 is offline  
Old 04 January 2019, 18:19   #11
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,199
Quote:
Originally Posted by prb28 View Post
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.
StingRay is offline  
Old 04 January 2019, 18:20   #12
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,462
Quote:
Originally Posted by prb28 View Post
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.
Code:
  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..
ross is offline  
Old 04 January 2019, 18:20   #13
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 773
Quote:
Originally Posted by ross View Post
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:
Code:
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.

Last edited by roondar; 04 January 2019 at 18:26.
roondar is offline  
Old 04 January 2019, 18:33   #14
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 38
Quote:
Originally Posted by ross View Post
What do you mean by "allocated at runtime"?
I thought the BSS section was not bundled in the file, I was wrong.

Quote:
Originally Posted by ross View Post
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:
Code:
             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
Code:
ds.b LOGO_LINE_FULLBPL_W_B*6
seems stripped in the exe file.
prb28 is offline  
Old 04 January 2019, 18:35   #15
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,462
@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 is offline  
Old 04 January 2019, 18:42   #16
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,462
Quote:
Originally Posted by prb28 View Post
I thought the BSS section was not bundled in the file, I was wrong.

The end of my code is:
Code:
             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
Code:
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
ross is offline  
Old 04 January 2019, 18:43   #17
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 773
Quote:
Originally Posted by ross View Post
@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

Quote:
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.
roondar is offline  
Old 04 January 2019, 19:02   #18
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 38
Quote:
Originally Posted by ross View Post
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?
prb28 is offline  
Old 04 January 2019, 19:31   #19
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,256
Quote:
Originally Posted by ross View Post
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.

Quote:
Originally Posted by prb28 View Post
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.

Quote:
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.
phx is offline  
Old 04 January 2019, 19:48   #20
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 38
Quote:
Originally Posted by phx View Post
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.
prb28 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Port Wolfenstein on Amiga 500 / 1000 OCS Miggy4eva Retrogaming General Discussion 184 15 February 2018 16:25
Amiga 500 Rev.6A VS Amiga 500 Plus with 2MB chip and ACA 500 turrican9 support.Hardware 0 24 December 2016 03:16
Sound buffer full when switching Amiga screen modes Leandro Jardim support.WinUAE 1 01 September 2015 12:16
Amiga 500. OCS or ECS? trydowave support.Hardware 10 25 May 2013 22:58

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.10969 seconds with 14 queries