Strange bug

[LeCaravage]

Hi all,

I have a strange bug.
I save a bank and the output result is totally wrong. Can't figure out why.
So, gentlemen, need your help. Here is the code :

z is long word
pt is long word
i is long word
z=384
MEMF_ANY = 1

Initbank 0,z,#MEMF_ANY
pt = Bank(0)
for i=0 to z-1
  poke.b pt+i,255
next
Savebank 0,"ram:test.bin"

Here is the output file :
[IMG]upload photos

[Daedalus]

Hmmm, that is odd - it works just fine for me in both Amiblitz 3 and Blitz 2.1.

I even made an executable and tested it under Kickstart 1.3, in case it was a difference in the memory allocation routines, but it still worked. What version of Blitz are you using? If you try it with AllocMem_() OS calls instead, does it do the same thing?

[Nightshft]

It doesnt work for me too.

For debuging
- I checked if bank returns a valid adress. Yes it does, at least when I do initBank with memtype=2 (chipram). I get memory f.e. at 0x0012 9c58.
- I do another loop and peek the memory adresses. They incorrectly all yield 0. Like the saved file.
Strange. Dont have more time to investigate further now.

(Winuae, A1200, 2MB Chipram and some fast, Amiblitz 3.7.4)

[LeCaravage]

Amiga 500 OCS 1.3 1Mb Chip 4Mb Fast


Here is the BB I'm currently using (v2.10)

https://gofile.io/d/wjFXbT

May be BB options are wrong ?

[tolkien]

Try with
pt.l = Bank(0)
to ensure pt is a longword.
Dont remember what is the default datatype in amiblitz if none is declared.

[LeCaravage]

Originally Posted by tolkien

Try with
pt.l = Bank(0)
to ensure pt is a longword.
Dont remember what is the default datatype in amiblitz if none is declared.

pt is already a .l type variable.

Originally Posted by Daedalus

If you try it with AllocMem_() OS calls instead, does it do the same thing?

Do you have a sample code of how to use WriteMem from a pointer to where is The AllocMem adress ?


Strange, sometimes when I write the problematic code alone in a new file, it works. But when I use it within anoter bigger code, it fails.
Also, the bug seems to occur also on 3.x versions of BB (Nightshft's post)
May be a remaining bug never found across the versions evolution ?

[LeCaravage]

Just made a test with Allocmem and Writmem.
It seems to work.
Not sure yet as I did test only once.
Will check further tommorrow.

[Daedalus]

Okay, that is odd, because Banks are just a wrapper around the standard OS calls. You can easily use Allocmem_ instead, just remember to free the memory before you quit the program or it will be lost until you reboot (Banks are freed automatically on End).

It could be a bug in some particular version of the library though - I've tried it with both Blitz 2.1 and AmiBlitz 3 and both work as expected for me. But if it works when it's alone in a file, that might be a clue regarding what's happening. Perhaps some other command is corrupting that Bank object's structure, making it point elsewhere? Or perhaps an address is getting corrupted somewhere by an accidental unwanted access?

[tolkien]

I have tried that source code with amiblitz 3.8 and the file is all 0s.
Writing pt.l makes it works good. Extrange but true.

[Daedalus]

pt needs to be a .l type for it to work - Blitz defaults to a .q unless you specify others, which will corrupt pointers. But the OP said it's already declared elsewhere as a .l so that shouldn't be the issue...

Unless it's being declared out of scope, in a function perhaps?

In AmiBlitz 3 it's a good idea to use Syntax 2 at the start of your code. This disables the default variable typing, so you must explicitly set each variable in each scope to the desired type, similar to C and other languages, and avoids any resulting bugs.

[LeCaravage]

Originally Posted by Daedalus

Unless it's being declared out of scope, in a function perhaps?

I tried the problematic piece of code in and out of a Gosub. Same pb.

[LeCaravage]

@Daedalus : Btw, my BB manual says that Allocmem doesn't need Freemem as at the End of program, BB free the allocated memory. Is it true ? Or my manual is wrong (it's a translated manual) ?

[LeCaravage]

Well, I am shamefaced because Tolkien was right. It was a pb of pt definition. I forgot to define it at top of source.
The strange think is that I verified the start and end of bank adress and it seemed to be correct (384 bytes long).
Anyway, thanks to all who helped.
(Nightshft you should check if you didn't make the same mistake than me).

[Daedalus]

Well, great that you figured it out anyway It's an easy enough mistake, which is why the Syntax addition to AmiBlitz is so handy - it'll tell you as soon as you try to compile that something's not right.

Originally Posted by LeCaravage

The strange think is that I verified the start and end of bank adress and it seemed to be correct (384 bytes long).

By default, Blitz will give you a Quick type, which is 16 bit for integers. That means you'll get legitimate numbers in this case, just missing the upper 16 bits so your address will always be in the lowest 64k of address space, and the end will be 384 bytes away within that space unless it happens to straddle a 64k boundary.

Originally Posted by LeCaravage

@Daedalus : Btw, my BB manual says that Allocmem doesn't need Freemem as at the End of program, BB free the allocated memory. Is it true ? Or my manual is wrong (it's a translated manual) ?

Confusingly, there are two different AllocMem functions: The Blitz one, AllocMem(), which internally forwards the request onto the OS, but keeps track of it like any Blitz object. The manual's probably talking about this one. And there's the actual OS one, AllocMem_(), which is the actual exec.library call directly, without any Blitz involvement (note the underscore at the end that denotes a direct library call). This is the one I was talking about, to try and remove Blitz from the equation altogether, but since Blitz isn't involved, you need to track the usage and free it manually yourself.

[Nightshft]

Now it works.
Yesterday my testcode (which pokes the values to the memory-bank and then, in a second loop prints what it peeks() there) yielded in all zeros, like in Tolkiens try.

I think that "pt.l" already was a longword type, but I can't tell for sure because I didn't have much time yesterday, and did many changes to test if it works later. I was quite surprised that it "suddenly" works now, but it works, so all good.

I also checked and found that poke without bytesize definition (so poke instead of poke.b) will write a longword at the given adress. This would yield all zeros too in such a loop because the high byte is zero. Also 3 bytes out of boundary would get written to (just for future reference, I know you got it right).

;Ram Bank test
Syntax 2
size.l = 10
#memtype = 0
#banknum = 0

InitBank #banknum, size, #memtype

myadress.l = Bank(#banknum)
NPrint Hex$(myadress)
NPrint ""
If myadress = 0 Then End

NPrint "Poking"
rand.b=Rnd(10)+65
For i.w=0 To size-1
  Poke.b myadress+i, rand+i
  NPrint Hex$(myadress+i)," ",rand+i
Next

NPrint ""
NPrint "Peeking"
For i=0 To size-1
  NPrint Hex$(myadress+i)," ",Peek.b (myadress+i)
Next

SaveBank #banknum,"ram:test.bin"
End

[tolkien]

Originally Posted by LeCaravage

Well, I am shamefaced because Tolkien was right. It was a pb of pt definition. I forgot to define it at top of source.
The strange think is that I verified the start and end of bank adress and it seemed to be correct (384 bytes long).
Anyway, thanks to all who helped.
(Nightshft you should check if you didn't make the same mistake than me).

Great it works! We are here to help each others