How to make it executable from WB?

[bodhi]

Hi all,

I'm just trying to figure out how to make my assembled ASMPro binary execute from Workbench (ie, double clicking).

The code assembles and runs fine in ASMPro and I'm able to "wo" the object to disk. Running the object from a DOS cli/shell works fine too but if I try to double-click it I get a crash :?

any help appretiated!

[Redwood]

Have a look at this page:

http://www.mways.co.uk/amiga/howtoco...tupandexit.php

The iconstartup.i file it refers to (along with the rest of the tutorial) can be downloaded from the main page at

http://www.mways.co.uk/amiga/howtocode/

(look for the link where it says "Download the original AmigaGuide version here").

Cheers,
Redwood

[thomas]

http://eab.abime.net/671760-post22.html

[spud]

And if all else fails there is always IconX :-)

[Leffmann]

Eventually ASM-Pro itself will be the problem, and you can't fix that with IconX

One problem (of many) with ASM-Pro and its relatives is that your program runs as a subroutine in the same context that ASM-Pro does, which is really bad and makes no sense, so you'll either be a CLI program or a Workbench program depending on how you started ASM-Pro.

When you wish to handle starting from WB correctly you'll work not with your own DOS process but ASM-Pro's process, which means your own code for handling a start from WB will halt with no idea what's going on, because ASM-Pro has already done this.

You can run into a heap of other problems when writing programs that want to run nicely with the AmigaOS, because your program has no process of its own. You can work around these problems, but it's annoying to have to write extra code to cater for a bad programming environment.

[bodhi]

Well, I gave both Red's and Thomas' iconstatup.i variations a shot and neither fix the problem. But I'm guessing this startup code is necessary for general WB execution, so still useful info. Thanks guys.

hmm, I recently added code to fully takeover the system which disables all OS ints/DMA, with forbid, etc. Although it works fine within ASMPro, I'm thinking it may be the cause of the crashing when I try to execute from WB. Why do I think this? Well, when I comment out my jsr TakeOverSys, and execute that version from WB, it doesn't crash. (yes, my "debugging skills" are awesome, I know!)

leffman: I've only used it (ASMPro) for a few hours so far with pretty simple code but perhaps I'm now begining to see the tip of the ASM* bug-iceberg. From what you say, I now don't know if ASMPro is obfuscating some of my own coding errors. I mean, if my code runs nicely in ASMPro (which it does), yet crashes in WB then I guess it must be. If, as you say, my code is running under ASMPro's context (when run within ASMPro) then ASMPro is behaving more as a "framework" which just confuses the issue of finding a bug - yuck.

Not really sure where to begin but I'm going to give this TakeOverSys routine a long hard lookover, hopefully I'll find the problem there and be able to continue using ASMPro (really have come to like its interface).

[bodhi]

TakeOverSys
	move.l	(ExecBasePtr).w,a6 ; base address of Exec lib in memory

	move.l	#IntuitionName,a1 ; address of library name string   
	moveq	#0,d0 ; min version of lib (0=any)
	jsr	_LVOOpenLibrary(a6) ; open it
	move.l	d0,_IntuitionBase ; store returned lib-base address. (d0=0=failed to open)

	move.l	#GfxName,a1
	moveq	#0,d0
	jsr	_LVOOpenLibrary(a6)
	move.l	d0,_GfxBase
	; forbid multitasking
	jsr	_LVOForbid(a6)
	; take control of blitter
	move.l	_GfxBase,a6
	jsr	_LVOOwnBlitter(a6)
	jsr	_LVOWaitBlit(a6) ; wait for any active blits to complete
	; store and deactivate current View
	move.l	gb_ActiView(a6),wbview
	sub.l	a1,a1
	jsr	_LVOLoadView(a6) ; flush View to nothing <- *** crash when not "cycle exact" ***
	jsr	_LVOWaitTOF(a6) ; 2xWTOF hack
	jsr	_LVOWaitTOF(a6)
	; store interrupt and DMA status and control regs
	move.l	#CUSTOM,a6
	move.w	INTENAR(a6),oldINTENA
	move.w	INTREQR(a6),oldINTREQ
	move.w	DMACONR(a6),oldDMACON

	jsr	DisableAll
	rts

Well, it was the call to my "TakeOverSys" subroutine that was causing the crash afterall. More specifically, _LoadView is the OS function responsible for the crash, *BUT* only when WinUAE CPU emulation is set to "Fastest Possible".

I have WinUAE's CPU Emulation set to fastest possible, just to speed up reboots and directory scanning, but it seems LoadView doesn't like the fast lane much. Setting WinUAE (v2.6.1) to Cycle Exact fixes it and I can execute by double clicking from WB with no probs.

Strange thing is, if I put in a small delay (mouse wait, or somthng) _before_ calling TakeOverSys, everything works fine even with WinUAE CPU set to fastest possible.

I found this one confusing, because 1. the code runs fine if executed via CLI/Shell and within ASMPro, 2. It _only_ crashes when I try to execute it by double clicking from Workbench and 3. I pretty much always have Fastest Possible set in WinUAE and most modern demos run fine. I'm guessing most of them use the LoadView/2xWaitTOF sequence too. But I suppose they are doing some extra bits before calling their TakeOverSys routines, which gives them that little extra delay that LoadView seems to need (?) Or maybe my TakeOverSys routine is completely wrong or needs some extra stuff?

So, basically, to fix the problem I just need to wast some cycles before calling TakeOverSys or simply set WinUAE to Cycle Exact.

Thanks for the help anyway guys. Always appreciated!

[Toni Wilen]

It can't be caused by CPU speed because it would also cause nearly all demos to crash that way (that use sane startup code), including my test programs.

Perhaps you have some weird/unofficial graphics.library updates or patches installed? Also I am not sure if it is 100% guaranteed safe to have blitter allocated when calling LoadView().

What kind of crash? Random guru or always the same?

[bodhi]

Originally Posted by Toni Wilen

It can't be caused by CPU speed because it would also cause nearly all demos to crash that way (that use sane startup code), including my test programs.

Exactly. Which is why this has been so confusing for me. But, on my setup at least, delaying the time between doubleclicking my exe and it calling _LoadView (either with a pause in code, or using Cycle Exact) definitely fixes things.

I also forgot to mention that I'm using DOpus5. I always have used it, so I forget it's not a standard part of the OS! Anyway, I have my directory display set to "View As > Name" by default (just a text directory listing, without icons). I discovered lastnight that if I set dir listing to "View As > Icon" and doubleclick my exe from that view....it works! And so do a few other programs/demos which I just assumed had "bad startup code" and so I always just ran them using RunLame.

If I run these progs and my own code using vanilla Workbench (and not DOpus) I can execute fine also.

So it's now looking like an issue with the way DOpus is handling background loading of some exes when set to "View As > Name" (have no idea if DOpus uses some custom loading routines or smthn?)

Originally Posted by Toni Wilen

Perhaps you have some weird/unofficial graphics.library updates or patches installed? Also I am not sure if it is 100% guaranteed safe to have blitter allocated when calling LoadView().

And yes, then there is also that strong possibility! I have used the same SYS: folder for almost a decade (in both WinUAE and realAmiga), I've always been "suspicious" of unofficial OS hacks (BoingBags, etc) but I may have done something to do with patching exec/intuition/graphics.libs and forgot to remove...somewhere along the line. hehe

Yes, so I think it's now time to do a fresh install of everything to be sure. Painful

[bodhi]

eeerr, setting "Hard Flush" in WinUAE has fixed everything for me! Wow

Don't ask me what Hard Flush is, but I like it!