Problem getting demo starter code to work

Nightfox · 31 May 2017, 22:29

Hello all,

I am using Photon's demo starter code to handle all the boring initialisation for a demo available here:

http://coppershade.org/asmskool/SOUR...pershade-DDE1/

The problem is when I click the mouse to return to the system I am just greeted with a black screen. I have narrowed it down to the vertical blank interrupt causing the issue but I have no idea why. For now I have just had to comment out the line assigning the new VBlank.

I am using an A1200 with a 68030 CPU if that helps

Galahad/FLT · 31 May 2017, 22:56

Which file? Ministartup?

Nightfox · 31 May 2017, 23:12

technically both since ministartup has an include for the wrapper file

roondar · 01 June 2017, 16:51

I did have a similar problem with the mini startup myself, though not with the interrupt section. The WaitEOF/WaitRaster routines didn't always work for me and could end up hanging the system.

Now I don't know if your problem is related to this, but mine was solved by replacing the WaitEOF routine with the following code:

Code:

WaitEOF	bsr.s	WaitBlitter
.wvbl	btst	#0,(custombase+vposr+1)
		beq		.wvbl
.iloop	btst	#0,(custombase+vposr+1)
		bne		.iloop
		rts

Maybe this can help.

Nightfox · 01 June 2017, 18:33

That did indeed fix it although my demo's frame rate became jerky when it was running super smooth before.

I changed it back to the original routine and the frame rate is smooth again but the exit problem returns. Interestingly, I put sprites in my demo and when I exit the demo the background is all black but the sprites are still displayed on the screen but they are frozen.

roondar · 01 June 2017, 23:24

It could be because the code I posted waits for rasterline 0 and the code that Photon used waits for a high number instead. That might be enough to cause jerkyness, especially if you use both WaitEOF and a VBlank interrupt, this can cause the wait to miss its rasterline and wait a full extra frame.

You could try adapting my WaitVPos routine for your purpose. That lets you pick a rasterline.

Code:

		; Routine WaitVPos
		; This routine waits on a specified vertical raster position
		; 
		; D6: Scanline to wait on (0 = top of visible screen (line 44))
		;
		; Returns:
		; D6: Undefined
		; D7: Undefined
WaitVPos
		add.w	#44,d6
		asl.l	#8,d6
.waitvpos
		move.l	custombase+vposr,d7
		and.l	#$1ff00,d7
		cmp.l	d6,d7
		bne.b	.waitvpos
			
.iloop	move.l	custombase+vposr,d7
		and.l	#$1ff00,d7
		cmp.l	d6,d7
		bne.b	.iloop
		rts

It's not the fastest possible, but it might be of use.

Photon · 23 July 2017, 23:00

Quote:

Originally Posted by roondar

I did have a similar problem with the mini startup myself, though not with the interrupt section. The WaitEOF/WaitRaster routines didn't always work for me and could end up hanging the system.

Now I don't know if your problem is related to this, but mine was solved by replacing the WaitEOF routine with the following code:

Code:

WaitEOF	bsr.s	WaitBlitter
.wvbl	btst	#0,(custombase+vposr+1)
		beq		.wvbl
.iloop	btst	#0,(custombase+vposr+1)
		bne		.iloop
		rts

Maybe this can help.

This code would make your effect run half framerate if it executed past scanline $ff.

Quote:

Originally Posted by roondar

It could be because the code I posted waits for rasterline 0 and the code that Photon used waits for a high number instead. That might be enough to cause jerkyness, especially if you use both WaitEOF and a VBlank interrupt, this can cause the wait to miss its rasterline and wait a full extra frame.

You could try adapting my WaitVPos routine for your purpose. That lets you pick a rasterline.

Code:

		; Routine WaitVPos
		; This routine waits on a specified vertical raster position
		; 
		; D6: Scanline to wait on (0 = top of visible screen (line 44))
		;
		; Returns:
		; D6: Undefined
		; D7: Undefined
WaitVPos
		add.w	#44,d6
		asl.l	#8,d6
.waitvpos
		move.l	custombase+vposr,d7
		and.l	#$1ff00,d7
		cmp.l	d6,d7
		bne.b	.waitvpos
			
.iloop	move.l	custombase+vposr,d7
		and.l	#$1ff00,d7
		cmp.l	d6,d7
		bne.b	.iloop
		rts

It's not the fastest possible, but it might be of use.

WaitRaster does exactly this, but allows to wait for a position above scanline $2c and doesn't busy-wait to leave the line.

Effects and startup code should certainly work on all PAL Amigas.

WaitEOF: A wait for scanline $138 would just as certainly hang all NTSC Amigas, make all WaitRaster calls use $105 or less and adapt the Copper list.

Anything else is too much speculation without more information on environment and whether the source is unmodified.

Nightfox · 23 July 2017, 23:36

Photon do you know why your starter code does not return me to the OS correctly and requires a reboot?

roondar · 23 July 2017, 23:47

Quote:

Originally Posted by Photon

This code would make your effect run half framerate if it executed past scanline $ff.

Right, that could be a problem. It seems I got lucky then with my code, as it hasn't happend yet. But I'll look it into it, always good to improve code

Quote:

WaitRaster does exactly this, but allows to wait for a position above scanline $2c and doesn't busy-wait to leave the line.

I could try WaitRaster, I kinda bypassed it when WaitEOF caused problems.

Quote:

Effects and startup code should certainly work on all PAL Amigas.

WaitEOF: A wait for scanline $138 would just as certainly hang all NTSC Amigas, make all WaitRaster calls use $105 or less and adapt the Copper list.

Anything else is too much speculation without more information on environment and whether the source is unmodified.

Well, I'm not going to claim my code is perfect in any way, but I will say that the reason I'm using my own WaitEOF/waitvpos code is that the ministartup code (specifically WaitEOF) hangs my program on exit quite often (not 100% of the time, but close to).

This happens for me on both real PAL A500's and WinUAE A500 cycle exact setting.

I have no idea why though

Photon · 24 July 2017, 13:48

Nightfox: A good startup should definitely return you safely to the OS!

If the files in your link doesn't let you do that, they could have an error or there's something about how you run it.

I can't reproduce it. It would be interesting to find the cause. To eliminate variables, can you assemble PhotonsMiniStartup1.04!.S (unmodified) to an object file (executable) and run the exe? This will tell us if it's something in the Assembler or outside. If it works, you can do the same with DDE-Plot1.S and then your demo.

Nightfox · 24 July 2017, 20:53

I was using your unmodified files. I am using an A1200 with 030 accelerator using AmigaOS3.9. Not sure if that makes things too complicated to diagnose

Photon · 24 July 2017, 21:19

OK, no, it's not too complex. But part of the diagnostics is that you have to do these steps on your machine since it works here.

Nightfox · 24 July 2017, 22:13

This is your unmodified starter code [ Show youtube player ]

Photon · 25 July 2017, 09:44

And here are some unmodified Assemblers. [ Show youtube player ]

My sources are very tested and clearly commented. There could still be something that doesn't play nice with your environment. If you want to find it you must do like I asked on your machine, with just one environment removed (the Assembler).

--> A, WO, run exe. Does it work?

The reason for AsmPro causing the Copper to roll is especially juicy

and one reason why these things are not obvious.

Nightfox · 25 July 2017, 20:43

hmm. Writing the object file then executing it outside the assembler works. I guess Asm-One 1.48 is misbehaving somehow. Thanks Photon, you rock my socks off. I wonder if there's a way of fixing this

roondar · 25 July 2017, 22:23

I've tested the startup as well using VASM for cross-assembling and unmodified, it does indeed work.

Makes me wonder why I managed to get it to crash on exit, while the change I did somehow fixed it. One thing I'm wondering about is: I'm assuming this also works outside of the display window, mine was a bit smaller than standard.

Could that mean I need to change the raster line I wait on?

That would feel very odd to me, as the beam surely does travel to the lines outside of the display window. Other than that though, I'm not sure what causes the difference. I remember testing this with a pretty much empty frame loop because I thought the problem was with my code. It's quite possible that is indeed true, but I'm not sure what is wrong then.

Photon · 25 July 2017, 22:47

Quote:

Originally Posted by Nightfox

hmm. Writing the object file then executing it outside the assembler works. I guess Asm-One 1.48 is misbehaving somehow. Thanks Photon, you rock my socks off. I wonder if there's a way of fixing this

There could be something in my source interfering with a setting. Here are mine, don't take these as "correct" or anything.

Even though Asm-One 1.48 and AsmPro seem buggy under 68000 in the short video, I wouldn't conclude that they don't work - maybe a setting or a 68020+ library causes it.

Quote:

Originally Posted by roondar

I've tested the startup as well using VASM for cross-assembling and unmodified, it does indeed work.

Makes me wonder why I managed to get it to crash on exit, while the change I did somehow fixed it. One thing I'm wondering about is: I'm assuming this also works outside of the display window, mine was a bit smaller than standard.

Could that mean I need to change the raster line I wait on?

That would feel very odd to me, as the beam surely does travel to the lines outside of the display window. Other than that though, I'm not sure what causes the difference. I remember testing this with a pretty much empty frame loop because I thought the problem was with my code. It's quite possible that is indeed true, but I'm not sure what is wrong then.

No, the raster always hits $138 in PAL (and $105 in NTSC). This is to wait out the full frame and make a clean break before starting your own screen, and on exit, do the same so that all HW regs are set up for the OS vblank at the top of the next frame.

roondar · 25 July 2017, 23:07

Quote:

Originally Posted by Photon

No, the raster always hits $138 in PAL (and $105 in NTSC). This is to wait out the full frame and make a clean break before starting your own screen, and on exit, do the same so that all HW regs are set up for the OS vblank at the top of the next frame.

Well, I'll see if I can find what exactly breaks it. If I do, I'll report back to this thread, but frankly don't count on that happening too soon - as I have no idea

Nightfox · 25 July 2017, 23:16

My settings were the same as yours except I don't have RTG mode enabled because the text output is buggy with it turned on. But I tried turning it on anyway and the same thing happened. I also just tried Asm-One 1.49 beta and it has the same problem

StingRay · 26 July 2017, 08:58

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.

31 May 2017, 22:29	#1
Nightfox Registered User Join Date: Apr 2016 Location: Perth, Australia Posts: 384	Problem getting demo starter code to work Hello all, I am using Photon's demo starter code to handle all the boring initialisation for a demo available here: http://coppershade.org/asmskool/SOUR...pershade-DDE1/ The problem is when I click the mouse to return to the system I am just greeted with a black screen. I have narrowed it down to the vertical blank interrupt causing the issue but I have no idea why. For now I have just had to comment out the line assigning the new VBlank. I am using an A1200 with a 68030 CPU if that helps

01 June 2017, 18:33	#5
Nightfox Registered User Join Date: Apr 2016 Location: Perth, Australia Posts: 384	That did indeed fix it although my demo's frame rate became jerky when it was running super smooth before. I changed it back to the original routine and the frame rate is smooth again but the exit problem returns. Interestingly, I put sprites in my demo and when I exit the demo the background is all black but the sprites are still displayed on the screen but they are frozen. Last edited by Nightfox; 01 June 2017 at 18:50.

01 June 2017, 23:24	#6
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,410	It could be because the code I posted waits for rasterline 0 and the code that Photon used waits for a high number instead. That might be enough to cause jerkyness, especially if you use both WaitEOF and a VBlank interrupt, this can cause the wait to miss its rasterline and wait a full extra frame. You could try adapting my WaitVPos routine for your purpose. That lets you pick a rasterline. Code: ; Routine WaitVPos ; This routine waits on a specified vertical raster position ; ; D6: Scanline to wait on (0 = top of visible screen (line 44)) ; ; Returns: ; D6: Undefined ; D7: Undefined WaitVPos add.w #44,d6 asl.l #8,d6 .waitvpos move.l custombase+vposr,d7 and.l #$1ff00,d7 cmp.l d6,d7 bne.b .waitvpos .iloop move.l custombase+vposr,d7 and.l #$1ff00,d7 cmp.l d6,d7 bne.b .iloop rts It's not the fastest possible, but it might be of use.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Can anyone work with the code from this game...?	Peter	Coders. General	3	09 November 2009 16:19
WinUAE: Sumea Demo doesn't work properly	Leonid	support.WinUAE	7	06 May 2008 20:33
Rocket ranger code wheel won't work	paul9090	support.Games	32	18 February 2002 23:30
Can anyone make this demo work?	Ziaxx	support.Demos	20	02 January 2002 21:03

31 May 2017, 22:56	#2
Galahad/FLT Going nowhere Join Date: Oct 2001 Location: United Kingdom Age: 50 Posts: 8,986	Which file? Ministartup?

31 May 2017, 23:12	#3
Nightfox Registered User Join Date: Apr 2016 Location: Perth, Australia Posts: 384	technically both since ministartup has an include for the wrapper file

01 June 2017, 16:51	#4
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,410	I did have a similar problem with the mini startup myself, though not with the interrupt section. The WaitEOF/WaitRaster routines didn't always work for me and could end up hanging the system. Now I don't know if your problem is related to this, but mine was solved by replacing the WaitEOF routine with the following code: Code: WaitEOF bsr.s WaitBlitter .wvbl btst #0,(custombase+vposr+1) beq .wvbl .iloop btst #0,(custombase+vposr+1) bne .iloop rts Maybe this can help.

23 July 2017, 23:36	#8
Nightfox Registered User Join Date: Apr 2016 Location: Perth, Australia Posts: 384	Photon do you know why your starter code does not return me to the OS correctly and requires a reboot?

24 July 2017, 13:48	#10
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	Nightfox: A good startup should definitely return you safely to the OS! If the files in your link doesn't let you do that, they could have an error or there's something about how you run it. I can't reproduce it. It would be interesting to find the cause. To eliminate variables, can you assemble PhotonsMiniStartup1.04!.S (unmodified) to an object file (executable) and run the exe? This will tell us if it's something in the Assembler or outside. If it works, you can do the same with DDE-Plot1.S and then your demo.

24 July 2017, 20:53	#11
Nightfox Registered User Join Date: Apr 2016 Location: Perth, Australia Posts: 384	I was using your unmodified files. I am using an A1200 with 030 accelerator using AmigaOS3.9. Not sure if that makes things too complicated to diagnose

24 July 2017, 21:19	#12
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	OK, no, it's not too complex. But part of the diagnostics is that you have to do these steps on your machine since it works here.

24 July 2017, 22:13	#13
Nightfox Registered User Join Date: Apr 2016 Location: Perth, Australia Posts: 384	This is your unmodified starter code [ Show youtube player ]

25 July 2017, 09:44	#14
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	And here are some unmodified Assemblers. [ Show youtube player ] My sources are very tested and clearly commented. There could still be something that doesn't play nice with your environment. If you want to find it you must do like I asked on your machine, with just one environment removed (the Assembler). --> A, WO, run exe. Does it work? The reason for AsmPro causing the Copper to roll is especially juicy and one reason why these things are not obvious.

25 July 2017, 20:43	#15
Nightfox Registered User Join Date: Apr 2016 Location: Perth, Australia Posts: 384	hmm. Writing the object file then executing it outside the assembler works. I guess Asm-One 1.48 is misbehaving somehow. Thanks Photon, you rock my socks off. I wonder if there's a way of fixing this

25 July 2017, 22:23	#16
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,410	I've tested the startup as well using VASM for cross-assembling and unmodified, it does indeed work. Makes me wonder why I managed to get it to crash on exit, while the change I did somehow fixed it. One thing I'm wondering about is: I'm assuming this also works outside of the display window, mine was a bit smaller than standard. Could that mean I need to change the raster line I wait on? That would feel very odd to me, as the beam surely does travel to the lines outside of the display window. Other than that though, I'm not sure what causes the difference. I remember testing this with a pretty much empty frame loop because I thought the problem was with my code. It's quite possible that is indeed true, but I'm not sure what is wrong then.

25 July 2017, 23:16	#19
Nightfox Registered User Join Date: Apr 2016 Location: Perth, Australia Posts: 384	My settings were the same as yours except I don't have RTG mode enabled because the text output is buggy with it turned on. But I tried turning it on anyway and the same thing happened. I also just tried Asm-One 1.49 beta and it has the same problem

26 July 2017, 08:58	#20
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	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.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)