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

Which file? Ministartup?

technically both since ministartup has an include for the wrapper file

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:

Maybe this can help.

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.

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.

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

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

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.

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

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 :)

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

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 :confused

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.

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

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. :)

This is your unmodified starter code https://youtu.be/a9LKji4YSL0

And here are some unmodified Assemblers. https://www.youtube.com/watch?v=tHMSip3KzCQ

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.

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

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.

:great 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.

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 :p

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

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.