Amiblitz3 programs on OCS Amiga 500

[Nightshft]

I'm writing programs with AB3.7.3 and - thanks to svens upgrade - in general these programs run fine on an A1200 (with or without Acc., with or without FPU).

Now I'm somewhat surprised/shocked that nearly all those programs dont run on an OCS Amiga 500.

I get "failure 8000 0003", "failure 8000 0004", "guru 8000 0020" and the like.
Even the simple program below wont run.
I just spent some hours to test a lot of programs, both on Winuae A500 and real A500 and they just crash.
Also tested AB 3.7.1 instead of 3.7.3 and it's the same.
Attached code compiled with BB2.1 runs fine on A500.
Am I missing something or does the AB3.7 compiler currently not produce working code for A500 target?

Can someone compile the below code on Amiblitz 3 producing a program that runs on OCS?

Testsystems:
Winuae: A500, OCS, Kick 3.1, Boot classicWb68K from Hdd, 1MB Chip and some Fastram
real: A500, OCS, Kick3.1, Boot classicWB68K from Hdd, Aca500+, 1MB Chipram and 4MB Fastram
(I also once tried a program on a naked WB3.1, same same.)

WBStartup
VWait 100  ;wait for disk drives
BLITZ
BitMap 0, 320,256, 4
Slice 0,42,4  ;define slice 0
Show  0       ;show bitmap 0
Repeat
  x=Rnd(320-26)
  y=Rnd(256-26)
  w=Rnd(20)+5
  c=Rnd(15)+1
  Boxf x,y, x+w,y+w, c
Until Joyb(0)>0
End

[Nightshft]

I a little further testing on target A500

- a simple hello world to console works
- "Blitz" without further commands works too
- "Initcoplist" works too
- The "Bitmap" command to initialize a bitmap seems to make the OCS machine freeze. It is from bitmaplib.

Dont have time for further testing at the moment.

[Zener]

Do you have enough free memory for the bitmap?

[Nightshft]

Yes for sure.
It was just a small 320x256x2 bitmap (needs about 20kB IIRC) and the systems just bootet with nearly all their chipram free.
Program either freezes (blank screen) or error message "program failed 8000 0003" appears.

I can reproduce it with the following code (this is the whole program)

Bitmap 0,320,256,2
End

Maybe someone wants to compile this with AB3 and try on a System with 000 cpu (emulated or real).

To me it looks like AB3 compiles the Bitmap command in a way that makes 000 cpus (or OCS/ECS systems) crash (Had it happen on Winuae A500, real A500 and real A600).

[Daedalus]

Yeah, I can confirm it happens that way. It's also been that way since AmiBlitz 2, which is where the FPU requirements came into things too. There are a few cases like this that I've come across, where it appears there are some '020-specific operations going on, e.g. non-word-aligned accesses, which are fine on an '020+, but illegal on an '000, even though all the instructions might be 68000-compatible. Such bugs can be tricky to find, but maybe Sven might be able to do that

In the meantime, you can work around it by manually allocating the bitmap (which will ensure it's always word-aligned) and using CludgeBitmap to assign it a bitmap object number. This is tested in WinUAE on an A600 config:

WBStartup
VWait 100  ;wait for disk drives
BLITZ

mem.l = AllocMem(320 * 256 / 2, 2)
If mem
  CludgeBitMap 0, 320,256, 4, mem

  Slice 0,42,4  ;define slice 0
  Show  0       ;show bitmap 0
  Repeat
    x=Rnd(320-26)
    y=Rnd(256-26)
    w=Rnd(20)+5
    c=Rnd(15)+1
    Boxf x,y, x+w,y+w, c
  Until Joyb(0)>0
  FreeMem mem, 320 * 256 / 2
Else
  NPrint "Error allocating memory!"
End If
End

This is slightly more involved because you need to manually allocate and free the memory involved, and if you mess it up, very bad things will happen. But it also allows you to check if there's actually enough memory, and exit gracefully instead of crashing as Blitz would otherwise do.

The AllocMem call takes the size of the memory required, and the second parameter is the type of RAM, as per the OS flags. 2 is chip RAM, 0 is any (usually fast, or chip if fast isn't available), or if you include the amigalibs.res file you can use the OS flags, e.g. #MEMF_ANY, #MEMF_CHIP, #MEMF_PUBLIC etc.

[Nightshft]

Thanks Daedalus that's very interesting and helpful.

And as 000 cpus dont support an fpu (support started with 020 AFAIK) nobody could know or test that the binaries wouldn't run there...
and of course no one would talk about it because the fpu requirement was the more virulent problem.

Is "bitmap" the only command affected - do you know others?

If Sven could fix this it would be awesome. It would mean that then AB3 could be used for target OCS again finally.

PS: I compiled your "workaround" code with AB3 and it works very well on A500, thanks.

[Daedalus]

No problem. Don't forget to change the size of the allocation if you change the size (including depth) of your bitmap. This won't be checked for you!

I'm trying to remember now - I'm sure I came across something else ages ago that crashed on an '000, but I can't remember. It's possible that there are other commands that use a common memory allocation routine that are also affected, maybe other graphics initialisation code like shapes, or audio object setup?

[Honitos]

I came to this thread by chance.
Acutally I do not know, why it crashes on a 68000. As blitz2/ab3 consists of all these several libs, there may be a fpu or 020-related change inside the lib that contains the bitmap-commands I did not know about... in this case it is not compiler related. The fix for the Val()-function for example had to be made inside the stringlib.

I may take a look into the source of the bitmaplib if it is available...

[Honitos]

Originally Posted by Nightshft

Yes for sure.
It was just a small 320x256x2 bitmap (needs about 20kB IIRC) and the systems just bootet with nearly all their chipram free.
Program either freezes (blank screen) or error message "program failed 8000 0003" appears.

I can reproduce it with the following code (this is the whole program)

Bitmap 0,320,256,2
End

Maybe someone wants to compile this with AB3 and try on a System with 000 cpu (emulated or real).

To me it looks like AB3 compiles the Bitmap command in a way that makes 000 cpus (or OCS/ECS systems) crash (Had it happen on Winuae A500, real A500 and real A600).

I just tested it with V3.7.4, compiled the code an ran it on WinUAE with 68000 only and Kick 3.1.4.
==> Did work without crash.

[Honitos]

Ah, tested it again, but this time with Kick1.3 - it crashed!
So I guess it is Kick1.3 related. Can someone test it with Kick 2.0?

Maybe bitmaplib uses a library function that is not available at Kick 1.3...

[Nightshft]

Crashes here with Kick 3.1
(in detail: Winuae, A500, cpu 000, ocs, Kick 3.1)
Edit: additional info: OS is ClassicWB68k (OS3.1) and compiled with AB3.7.4

NPrint "this program will now try to allocate a bitmap"
NPrint "press mousebutton to begin"
MouseWait
BitMap 0,320,256,4
NPrint "Bitmap allocated"
NPrint "press mousebutton to end"
VWait 20
MouseWait
End

[Nightshft]

I uploaded source and exe (see above) to the zone ("Amiblitz3 A500 quicktest") so you can try if you want.
If you upload the exe that does not crash on 000/Kick3.1 to the zone too I'd try to run it.

[Toni Wilen]

Possibly relevant: 68000 (and 68010) data address errors are only emulated if "more compatible" CPU option is ticked. It is easy to miss. If it is not ticked: behavior is like 68020+.

[Nightshft]

Thanks Toni! For bughunting reference: in my case it was ticked.

[Honitos]

I am sure it is related to the kickstart version rhan to the processor type.
But I have no clue so far.

[Daedalus]

I've just tested this with version 3.7.4, and I can confirm that Toni's hunch is correct: the crash only happens when "more compatible" is ticked. It runs fine when the option is disabled (so data address errors are ignored). My guess is that the bitmap allocation code is allocating at an odd address rather than an even address, which is an address error on the 68000. This is with a basic KS 2.05 A600HD, 2MB chip RAM configuration, with nothing else changed between tests.

The CludgeBitMap method is still a reasonable work-around, because that will always align the allocated memory on word boundaries.

[Daedalus]

Actually, just as I say that, it appeared to work fine for some things, but the debugger doesn't like it. I get "Can't copy borrowed bitmap" errors now with the CopyBitMap command. It appears to copy fine with the debugger turned off, but I don't know how much I trust it...

[fabbroz]

Hello, same problem here.
I've made a simple shoot'em'up with DualPlayField and freeze on a real A500 with KS1.3 and 1mb (512kb + 512kb)

"Software error - task held"

No problem on a real A1200
Any solution?

Regards,

[Daedalus]

If it's freezing at the same point (where bitmaps are being allocated), that could be the issue alright. The work-around that I posted above might help in that regard, though I should add that it's based on a neat bitmap arrangement in RAM. If you're using a bitmap that's an odd size, you'll need to add a few bytes per line (the number depends on the exact alignment) to the allocation to allow for the alignment of the bitplanes.

[fabbroz]

mmh.. still hang...

Here my (part of) code.

;INCLUDES
INCLUDE "inc-utils"
INCLUDE "inc-math"
INCLUDE "inc-structs"

WBStartup



;Modify
mem0.l=AllocMem(#SCREENW*(#SCREENH+#SCROFFSET)/2,2)
mem1.l=AllocMem(#SCREENW*((#SCREENH*2)+32)/2,2)

CludgeBitMap 0,#SCREENW,#SCREENH+#SCROFFSET,#BPL,mem0
CludgeBitMap 1,#SCREENW,#SCREENH+#SCROFFSET,#BPL,mem0
CludgeBitMap 2,#SCREENW,(#SCREENH*2)+32,#BPL,mem1

;Init Screens
;BitMap 0,#SCREENW,#SCREENH+#SCROFFSET,#BPL
;BitMap 1,#SCREENW,#SCREENH+#SCROFFSET,#BPL
;BitMap 2,#SCREENW,(#SCREENH*2)+32,#BPL

Use BitMap 1
LoadBitMap 1,playerData$,2
LoadPalette 1,playerData$,16
GetaShape 1,0,0,32,32
GetaShape 2,32,6,12,8
GetaShape 4,32,6,12,8
GetaShape 3,46,2,16,16 ;ENEMY
GetaShape 5,77,2,64,64
Cls

Use BitMap 2
LoadPalette 2,tilesData$,8
LoadBitMap 2,tilesData$,1
  For y=0 To 5
   For x=0 To 9
     GetaShape 10+t,x*32,y*32,32,32
     t+1
   Next
  Next

Cls

Use BitMap 0
Queue 0,150
Queue 1,150

;let's start
VWait 100
BLITZ

InitCopList 0,44,#SCREENH-32,$36,8,#COLORS,0
CreateDisplay 0
DisplayPalette 0,2
DisplayAdjust 0,0,0,0,32,-32

Originally Posted by Daedalus

If it's freezing at the same point (where bitmaps are being allocated), that could be the issue alright. The work-around that I posted above might help in that regard, though I should add that it's based on a neat bitmap arrangement in RAM. If you're using a bitmap that's an odd size, you'll need to add a few bytes per line (the number depends on the exact alignment) to the allocation to allow for the alignment of the bitplanes.