22 February 2021, 22:54 | #1 |
Registered User
Join Date: May 2017
Location: AmigaLand
Posts: 456
|
Strange bug
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 Code:
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" [IMG]upload photos |
23 February 2021, 00:27 | #2 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,334
|
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? |
23 February 2021, 15:25 | #3 |
Registered User
Join Date: Mar 2018
Location: Austria
Posts: 615
|
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) |
23 February 2021, 15:49 | #4 |
Registered User
Join Date: May 2017
Location: AmigaLand
Posts: 456
|
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 ? Last edited by LeCaravage; 23 February 2021 at 17:46. |
23 February 2021, 21:25 | #5 |
AmigaMan
Join Date: Oct 2012
Location: Castro Urdiales/Spain
Posts: 760
|
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. |
23 February 2021, 22:22 | #6 | ||
Registered User
Join Date: May 2017
Location: AmigaLand
Posts: 456
|
Quote:
Quote:
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 ? |
||
23 February 2021, 22:54 | #7 |
Registered User
Join Date: May 2017
Location: AmigaLand
Posts: 456
|
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. |
24 February 2021, 00:02 | #8 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,334
|
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? |
24 February 2021, 12:46 | #9 |
AmigaMan
Join Date: Oct 2012
Location: Castro Urdiales/Spain
Posts: 760
|
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. |
24 February 2021, 13:00 | #10 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,334
|
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. |
24 February 2021, 14:59 | #11 |
Registered User
Join Date: May 2017
Location: AmigaLand
Posts: 456
|
|
24 February 2021, 15:30 | #12 |
Registered User
Join Date: May 2017
Location: AmigaLand
Posts: 456
|
@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) ?
|
24 February 2021, 15:43 | #13 |
Registered User
Join Date: May 2017
Location: AmigaLand
Posts: 456
|
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). |
24 February 2021, 15:58 | #14 | |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,334
|
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.
Quote:
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. |
|
24 February 2021, 17:04 | #15 |
Registered User
Join Date: Mar 2018
Location: Austria
Posts: 615
|
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). Code:
;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 |
24 February 2021, 18:29 | #16 | |
AmigaMan
Join Date: Oct 2012
Location: Castro Urdiales/Spain
Posts: 760
|
Quote:
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Bug in x64 file requester and bug in Blizzard PPC ROM filesize | headkase | support.WinUAE | 5 | 26 June 2016 14:17 |
Always the same bug with RSI Megademo... and another strange thing... | sodapop | support.WinUAE | 8 | 08 May 2011 18:40 |
strange little bug with Chrome | Marcuz | project.EAB | 6 | 02 August 2009 19:33 |
Unsual Case of Dr. Strange / Return of Doctor Strange | killergorilla | HOL contributions | 1 | 12 July 2007 16:08 |
Strange Bug | BippyM | support.WinUAE | 1 | 18 January 2003 20:07 |
|
|