some dodgy source code

[Steve]

I wonder if any of you know what is wrong with this source code that I typed up from the book Amiga Assembler Insider Guide by Paul Overaa? It is meant to display a graphic but displays a corrupt window then crashes. Maybe has something to do with the LVO offsets? Just I had to rename the two include files to .s to get them to upload to here. If anyone has the disk for this book that would be great also.

[Toni Wilen]

Attach also compiled binary, it is much easier to debug if both binary and source is available than to guess if the problem is in source code, your assembler or somewhere else.

[Steve]

Ah I didn't realise that. Ok I have also attached the binary.

The thing is there is an additional file for the example in the book called 'function_offsets.i' but the code isn't given.
I assumed these were just the _LVO library offsets so added them to Defines.i
I did think it was strange adding the offsets manually. I thought they were already defined in the commodore includes?

[Steve]

Slightly updated binary with proper window size values. I hadn't entered the correct values from the book. Still gives a program failure message though after it closes itself and the graphics don't look like much. Just a few small horizontal lines?? And on a Picasso uaegfx display which I code on it looks like an screwy corrupt mess inside the window with lines all over the place?

[Lonewolf10]

Originally Posted by Steve

Still gives a program failure message though after it closes itself and the graphics don't look like much.

Two things spring to mind:

1) Is d0 cleared (set to 0) before exiting the program? Anything other than a value of 0 indicates to workbench that an error has occured

2) Are you properly handshaking with workbench at start and exit? You need to store the specific message (ID?) that workbench allocates to your program at startup and reply to it when exiting. Failing to do so generates an error message.



Edit: Just looked at your source code (Example_CH15-2.s) and you did clear d0 before exiting so ignore my first idea (above), but you do not do any handshaking as mentioned in my 2nd idea (above).

FYI: replace clr.l d0 with moveq #0,d0 (the latter is 2 cycles faster and does exactly the same thing)

[Steve]

Originally Posted by Lonewolf10

Edit: Just looked at your source code (Example_CH15-2.s) and you did clear d0 before exiting so ignore my first idea (above), but you do not do any handshaking as mentioned in my 2nd idea (above).

FYI: replace clr.l d0 with moveq #0,d0 (the latter is 2 cycles faster and does exactly the same thing)

Hi. Thanks I didn't know that. About the handshaking, is it easy to add to the program? As it's an introductory book it leaves out a lot of information on the finer details of Workbench coding.

[kamelito]

Reading the code I think that it has been written to be launched from the shell and not the workbench. Is it crashing if you launch it from the shell?
As for the corrupted image, I'm not sure but the datas are mostly zeroes. Images datas should be in chip memory though. Did you try on OCS?

Kamelito

[Steve]

Hi. Thanks for your reply. It uses the intuition library so is meant to be run from workbench. I have written other programs from the book that are DOS only. I think it is supposed to display diagonal lines in the window because as you say there are mostly zeros in the image data.

[kamelito]

It's not because it uses Intuition that it must be launched from WB.
Kamelito

[Toni Wilen]

Intuition (and nearly everything else) can be used without WB.

Example programs are rarely WB compatible (unless they are C programs and linker adds WB packet support automatically or they are meant to show how to do WB programs ). Always run them from CLI/Shell.

0x07000004 guru (AsyncPkt) is the most common side-effect for trying to run non-WB compatible program from WB by clicking its icon. (WB packet is put in same queue that dos uses and dos does not want to see it)

[kamelito]

IMHO the planpick and planoff should be "dc.b $00,$03,$00,$00" since it's bytes here not words.
Don't know if the assembler permit or correct such things.
Kamelito


Image1:
dc.w 0,0 X,Y origin relative to container TopLeft
dc.w 395,215 Image width and height in pixels
dc.w 2 Number of bitplanes in image
dc.l ImageData1 Pointer to ImageData
dc.b $0003,$0000 PlanePick and PlaneOnOff
dc.l NULL Next image structure

[Steve]

Ah ok. I tried in DOS and it doesn't crash anymore when the program closes. The graphics still look a bit odd as you can see. Maybe you are right kamelito about changing the PlanePick and PlaneOnOff definitions to byte values?

[Steve]

Ok, this is interesting. I changed the dc.b to dc.w I get this result. A large blue rectangle?? Do you think this is correct? More importantly it actually works in Workbench now without crashing!

[kamelito]

Can't say as I don't own that book. I doubt it can run from the WB without crashing thought (except if you did manage WB signal stuff)
Kamel

[Steve]

I can't explain it but now the program doesn't crash from WB even if I change the code back. Very strange. The dc.b values must be correct and not an error as I checked the Image structure definition and those values are marked as UBYTE and the rest are WORD so they should be dc.b. As for the blue rectangle this is obviously not what the image is supposed to look like. It is either a diagonal white line or horizontal white line? I'm not if the ImageData is incorrect. It could be a misprint in the book although it listed twice and is the same both times. It would really be handy to have the disk with this book.

[mark_k]

PlanePick and PlaneOnOff are byte fields, so don't change those to dc.w. You might want to remove the leading pair of zeros from each but that's just cosmetic.

Looking at your source code:

Image1:		dc.w	0,0				X,Y origin relative to container TopLeft
		dc.w	395,215				Image width and height in pixels
		dc.w	2				Number of bitplanes in image
		dc.l	ImageData1			Pointer to ImageData
		dc.b	$0003,$0000			PlanePick and PlaneOnOff
		dc.l	NULL				Next image structure
		SECTION Image,DATA_C

ImageData1:	dc.w $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000
		dc.w $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000
...

The amount of image data is far less than needed for a 395×215 2-plane image. Are you sure you didn't mis-type the width and height in the Image structure? Or did you just not post all of the image data here?

[Steve]

It is exactly as it is in the book. Must be an error in the book.

[Steve]

Yes it seems like the full code for the image wasn't printed. I copied some ImageData code from a similar program on the Mastering Amiga Assembler disk, added it to my code and it compiled fine and looks correct. Also the crashing still seemed to occur when I tested it. Looks like as far as the corrupt image is concerned that one is solved. Maybe they didn't print the entire listing because it took up too many pages? Who knows.

[mark_k]

Does the program still crash when you run it from a CLI/Shell window, not Workbench?

[Steve]

Originally Posted by mark_k

Does the program still crash when you run it from a CLI/Shell window, not Workbench?

No. Strange thing is it works fine on my main development Workbench using uaegfx at 1024x768 24 bit but on a standard Workbench screen it gives the software failed message in the corner. It's a bit odd but oh well. It only crashes though once the program has run its course.