Problem getting demo starter code to work

[Nightfox]

Originally Posted by StingRay

It must be a problem on your end, I've tested the code with ASM-One 1.48 and ASM-Pro and there were no problems.

On a real Amiga or emulator? And if real emulator which Amiga and any accelerator boards?

[StingRay]

A4000 with Cyberstorm 060 MK1.

[Nightfox]

Hmmm then no idea what is causing my issue

[Asman]

@Nightfox
What screen mode do you have on your WB and Asm-One. Did you try set on "Safety" parameters in Preferences and check again if Photon ministartup works.

[Galahad/FLT]

Try booting with no startup-sequence, and running ASMone then, and see if that fixes it. Could be you have something in your startup-sequence that interferes with ASMOne running properly.

[Nightfox]

I run WB at high res NTSC interlace and asm-one at high res pal non interlace. Safety has always been enabled

Booting with no startup sequence fixes the problem. We are certainly narrowing down the problem it seems

[Asman]

Can you just check such simple example on you env.

	SECTION	test,CODE_C

	lea	copper(pc),a0

	move.l	a0,$dff080
	move.w	a0,$dff088
lmb	btst	#6,$bfe001
	bne	lmb
	rts

copper:
	dc.l	$01800000
	dc.l	$01000000
	dc.l	$fffffffe

It should be works with Asm-One and Safety enabled.

[Nightfox]

That code works fine

[Photon]

Good idea Asman! But the Safety option doesn't make a difference for it (or for my startup) here, works fine. Reinstall? Corrupt Asmone.Prefs file? I don't know. But Asman's snippet does not restore the Copper, so if you run the exe you will see the difference

I have an idea, but it's a long shot. First, what happens if you try your demo in AsmPro? (Double-check that chipmem sections end up in chipmem!)

[Galahad/FLT]

Originally Posted by Nightfox

I run WB at high res NTSC interlace and asm-one at high res pal non interlace. Safety has always been enabled

Booting with no startup sequence fixes the problem. We are certainly narrowing down the problem it seems

Can you post up your startup-sequence?

[Photon]

Crystal ball says the problem goes away if you boot Workbench to PAL.

[Nightfox]

Can you post up your startup-sequence?

My startup-sequence is here: https://pastebin.com/wspZN9SC
My user-startup is here: https://pastebin.com/HbpZZzEj

Crystal ball says the problem goes away if you boot Workbench to PAL.

OMG Photon... If I have Workbench in PAL high res non interlace mode then open Asm-One and run your code it exits perfectly! What the heck? What is going on here? I'm sure you might already know why. Is there a fix for this so I don't have to switch to PAL screen mode every time I want to open Asm-One, even though Asm-One uses that screen mode when it opens anyway?

[Galahad/FLT]

Your startup-sequence has settings for VGA Only, does it use that particular part of the sequence?

[Leffmann]

The code expects PAL when it exits back to Workbench, but the real source of the problem is the LoadView(NULL) call, because it gives no guarantee of what hardware display settings you receive.

Calling LoadView(NULL) will give you whatever you booted into: if you have a PAL Amiga and set it to NTSC in the early startup menu, and use VGA in Workbench, then calling LoadView(NULL) will give you the NTSC.

AFAIK the only solution is to open a top-most Workbench screen and explicitly request either PAL or NTSC, to make sure you get the right display settings.

[Photon]

So my crystal ball worked in my very first reply, and NightFox didn't reply about NTSC until yesterday. Information is trickle-fed, and others spend much more time on solving this than you. It should be the other way around, because there are more users than devs.

Originally Posted by Leffmann

The code expects PAL when it exits back to Workbench, but the real source of the problem is the LoadView(NULL) call, because it gives no guarantee of what hardware display settings you receive.

Calling LoadView(NULL) will give you whatever you booted into: if you have a PAL Amiga and set it to NTSC in the early startup menu, and use VGA in Workbench, then calling LoadView(NULL) will give you the NTSC.

AFAIK the only solution is to open a top-most Workbench screen and explicitly request either PAL or NTSC, to make sure you get the right display settings.

This is where it gets technical. And becomes a bit about hardware vs OS (maybe. probably not. let's see.)

As per source comment, LoadView(NULL) was added to trigger automatic monitor switching. I don't have every user's setup, so I got it tested and added it in good faith. Most startups have this just after saving gb_ActiView, so if this is what causes the freeze, it should occur on start, not on exit(?)

Some startups use WaitTOF, which should be compatible with all display setups(?) Some startups do it twice for interlaced displays, which seems strange since you wouldn't know if the two calls left you in the odd or even frame anyway. Some other reason?

The reasoning goes that WaitEOF is what you want, because you don't want to take over the hardware in the middle of the frame as you would from WaitTOF. Just before Vblank is the cleanest break from coppers, interrupts, etc. (and you wouldn't waste 3 frames doing nothing before your demo code executes). Maybe I'm trying to be too pure for the platforms I want to support.

I could certainly save gb_ActiView, but I couldn't LoadView(NULL) right after for it to work on this setup. And if I remove that, monitor autoswitch doesn't work. So logic suggests LoadView(savedView) before hardware takeover could work for NightFox and users with monitor autoswitches? Is it available on all Kick/WB 1.2-3.1 PAL Amigas?

Lots of thoughts to add but opening a WB screen isn't a pretty option for me.

[roondar]

Right, I've looked at my code and finally found the bug.

The last thing I do before returning to the wrapper is deallocate all the memory I've allocated (through Exec). So, in the way that goes, I forgot to change back a6 to the custom chip base. A very basic error and once I found it I really felt quite silly.

I suppose it just happens every now and then.

Anway, Photon's code works just fine for PAL Amiga's - if you don't screw up register use like I did

[Photon]

good that you made it work, yes, the wrapper is meant to be a simple black box. Outside the save/restore registers part you're in the startup context.

My old startup had all kinds of useful stuff like SysInit and SysExit stubs you could use for things like allocation, but I don't use it anymore. It's just simpler to use this and plop whatever I want into it.

Worked wonders for a mate's old Seka sources too, with startups for 1.2 that would guru, just comment out the old startup/exit lines, put a Demo: label and add the wrapper include at top, done. No digging into what does this thing do etc.

Originally Posted by Nightfox

Is there a fix for this so I don't have to switch to PAL screen mode every time I want to open Asm-One, even though Asm-One uses that screen mode when it opens anyway?

This version tests if LoadView(savedView) at start instead of LoadView(NULL) improves things. Could you try it? It's not certain that it will fix it, but from results I will know what the next step will be.

[Nightfox]

Thank you for your help Photon. Your updated code when assembled and run causes me just to see my Workbench screen, but using Amiga + N I can switch to the program and it exits correctly when left clicking. The only issue now is to make it show the program screen right away rather than having to use Amiga + N to see it.

[Photon]

Interesting. What happens if you just do this?

1. Start Asm-One and make sure a PAL mode is selected
2. Left-click on the Asm-One menu bar or click the To Front icon
3. assemble and run the unmodified startup1.04!.S

[Nightfox]

Just tested it. Booted AmigaOS 3.9 into its usual NTSC interlaced mode, opened Asm-One in it's usual PAL non interlaced mode, opened your old starter, clicked on the menu bar (there is no click to front button), assembled and ran. It was fine the first time. Then I exited your startup clicked on the asm-one menu bar again then assembled and ran once more then it exited to a black screen. This has actually happened before, it did very occasionally exit correctly but 90% of the time exit into blackness. I also just tried an experiment to see if Amiga + M/N can be used to get out of the black screen and it doesn't.