Problem getting demo starter code to work

[Nightfox]

I should also mention that if my WB is in my usual NTSC interlaced mode and I use your old startup then as soon as I run your code my 1084S screen flickers for a second as if it is switching into the NTSC mode for a split second then going back into PAL again for your program, whereas if my WB is in PAL non interlace then the screen doesn't do this at all and is always able to exit fine.

[Photon]

OK, it was worth a shot. Probably everything would work if you commented out the two jsr -222(a6) lines in wrapper1.04!.S. This is why I hesitate to add stuff I can't test on my own reliably.

Originally Posted by Nightfox

I should also mention that if my WB is in my usual NTSC interlaced mode and I use your old startup then as soon as I run your code my 1084S screen flickers for a second as if it is switching into the NTSC mode for a split second then going back into PAL again for your program, whereas if my WB is in PAL non interlace then the screen doesn't do this at all and is always able to exit fine.

If you have a CRT monitor (and perhaps on some others, too?), it's normal with a "hiccup" of the display when switching from NTSC to and from PAL (so it should happen when starting Asm-One, too?). This is just how sync works on monitors. But interlace or not shouldn't cause such a hiccup. Maybe LoadView confuses the WB/Asm-One views in the system Copper lists?

So removing jsrs might fix this too

[meynaf]

Originally Posted by Photon

But interlace or not shouldn't cause such a hiccup.

Some monitors really do have a sync loss when going from interlace to non-interlace, while others don't.

[Photon]

Originally Posted by meynaf

Some monitors really do have a sync loss when going from interlace to non-interlace, while others don't.

CRT monitors/TVs could hiccup when not correctly driven, but I think this is evitable. If you have such a monitor I could send a test? Anyway, maybe something for PM or another thread.

[meynaf]

Originally Posted by Photon

CRT monitors/TVs could hiccup when not correctly driven, but I think this is evitable. If you have such a monitor I could send a test? Anyway, maybe something for PM or another thread.

Sorry I cannot perform tests anymore due to dead monitors, but simple Intuition screen cycling was enough. Under same conditions, 1083S-D1 had no problem where 1083S-P1 had some hiccup.
I guess that if Nightfox's monitor is 1084S-P1 then some small sync loss is "normal".

[Nightfox]

Originally Posted by Photon

OK, it was worth a shot. Probably everything would work if you commented out the two jsr -222(a6) lines in wrapper1.04!.S.

I tested this just then. Running the program again has the problem of displaying Workbench requiring Amiga + N to go to the program's screen. It does exit fine though.

[Photon]

Originally Posted by meynaf

Sorry I cannot perform tests anymore due to dead monitors, but simple Intuition screen cycling was enough. Under same conditions, 1083S-D1 had no problem where 1083S-P1 had some hiccup.
I guess that if Nightfox's monitor is 1084S-P1 then some small sync loss is "normal".

On my 1084S-P here, my demo Frazetta doesn't cause a hiccup (because I spent time ensuring proper switching). Nor on my TV, C1081 or other monitors. That's not the same as the Copper List-building+sorting of the OS. Probably it's tricky to switch timely then, or it doesn't want to exclude having multiple modes on displayed at the same time.

Originally Posted by Nightfox

I tested this just then. Running the program again has the problem of displaying Workbench requiring Amiga + N to go to the program's screen. It does exit fine though.

It's probably the system doing this then, but you could see if unchecking Safety (if it does what I think it does) makes a difference.

[Nightfox]

Sorry I tested it again and it exited to black again. I guess I was just having a lucky streak in the last tests. Safety also makes no difference, and even with safety off I get put into the WB screen when I run the program

[meynaf]

Originally Posted by Photon

On my 1084S-P here, my demo Frazetta doesn't cause a hiccup (because I spent time ensuring proper switching). Nor on my TV, C1081 or other monitors. That's not the same as the Copper List-building+sorting of the OS. Probably it's tricky to switch timely then, or it doesn't want to exclude having multiple modes on displayed at the same time.

But you get a hiccup if you don't do proper switching, don't you ?

[Photon]

Originally Posted by Nightfox

Sorry I tested it again and it exited to black again. I guess I was just having a lucky streak in the last tests. Safety also makes no difference, and even with safety off I get put into the WB screen when I run the program

With the jsr -222(a6)'s removed? Does it show the purple color before you click out of it?

If yes and yes, then it could be outside the startup completely that it happens. You could run Asman's code a bunch of times and see if you can provoke the same. (It doesn't turn off the interrupts, so it's not a perfect test. No black screen=no conclusion, 1 black screen=result.)

[Asman]

@Nightfox
What about such simple example

	section	test,CODE_C

	move.w	#$7fff,d0
	move.w	d0,$dff09a
	move.w	d0,$dff096
	move.w	d0,$dff09c

	lea	copper(pc),a0

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

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

It should works on Asm-One with Safety option.

[Nightfox]

Originally Posted by Photon

With the jsr -222(a6)'s removed? Does it show the purple color before you click out of it?

If yes and yes, then it could be outside the startup completely that it happens. You could run Asman's code a bunch of times and see if you can provoke the same. (It doesn't turn off the interrupts, so it's not a perfect test. No black screen=no conclusion, 1 black screen=result.)

Yes with those commented out and I assemble and run I see Workbench, but when I push Amiga+N I see the purple, and when I click I just see black.

Originally Posted by Asman

@Nightfox
It should works on Asm-One with Safety option.

Your code works fine and exits to Asm-One correctly.

[Asman]

@Nightfox. Thanks for test. I have my own startup code and I am really curious if it works correctly on your environment. But first I must test it a bit

[Photon]

Originally Posted by Nightfox

Yes with those commented out and I assemble and run I see Workbench, but when I push Amiga+N I see the purple, and when I click I just see black.



(@Asman) Your code works fine and exits to Asm-One correctly.

That's strange. With the jsrs removed, it should behave like Asman's. Last time you tested, you could exit fine(?)

And when the purple is showing, the interrupts are turned off (except our own VBI), so you should not be able to press Amiga+N at all...

The only possibility that would allow you to press Amiga+N while the demo is running (purple) that I can see is that somehow the VBR is moved by some software that doesn't update Exec to reflect the change.

Then I would be enabling the system's VBI and that would allow you to switch, as well as interfere with the hardware takeover/return. I think that's the reason then.

Supervisor() return and OldOpenLibrary() should preserve a4, but there could be a difference on 3.9.

Simplest test: #$c020 -> #0 in startup1.04.S, it should really show the purple without having to press Amiga+N, at least.

[Nightfox]

I'll test that tomorrow Photon. I managed to damage the ribbon cable of my A1200 keyboard today (somehow managed to accidentally touch it with my soldering iron!) I melted away 2 of the traces in the middle of the cable. I've put in a new plastic square under where the hole formed and put silver paint on it letting it dry overnight to see if I can get this working again. Otherwise I will just connect a temporary USB keyboard

Also I suspect one of the times I tested your code when it was working, it was probably only working due to sheer luck since for some reason there is about a 20% chance that it does exit correctly.. and maybe I just happened to get that lucky 20% every time I tested it

[Nightfox]

As soon as I repaired my keyboard ribbon cable and tested it, my beloved Commodore 1084S turns black and starts emitting a somewhat loud high pitched noise... I think it's dead

[Nightfox]

Update: There was nothing wrong with the startup code at all. Turns out I had an option in AsmOne enabled called "WB to front" which I'm guessing puts Workbench on the screen right before your code executes and that screws everything up. I guess that option is really only useful for programs that run in a window

[StingRay]

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.

So apparently I was right.

[Nightfox]

Haha yep. I am curious though, why would AsmOne moving WB to front cause this issue?

[Photon]

Probably it's meant for developing apps that require the Workbench windowing environment and should open windows on the Workbench screen (i.e. they have no screen of their own).

And so even though the editor is in PAL, the split second before execution of your code it pulls the rug out from under by switching to the NTSC mode you use for Workbench. And then VPOS never reaches the last PAL rasterline, throwing off the WaitEOF (which could be rewritten to handle NTSC).