English Amiga Board

English Amiga Board (https://eab.abime.net/index.php)
-   Coders. Asm / Hardware (https://eab.abime.net/forumdisplay.php?f=112)
-   -   Problem getting demo starter code to work (https://eab.abime.net/showthread.php?t=87379)

Nightfox 26 July 2017 11:14

Quote:

Originally Posted by StingRay (Post 1174170)
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 26 July 2017 11:30

A4000 with Cyberstorm 060 MK1.

Nightfox 26 July 2017 11:32

Hmmm then no idea what is causing my issue

Asman 26 July 2017 11:35

@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 26 July 2017 11:39

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 26 July 2017 12:15

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 26 July 2017 12:34

Can you just check such simple example on you env.
Code:

        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 26 July 2017 12:48

That code works fine

Photon 26 July 2017 23:47

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 26 July 2017 23:52

Quote:

Originally Posted by Nightfox (Post 1174206)
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 27 July 2017 02:18

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

Nightfox 27 July 2017 10:53

Quote:

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

Quote:

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 27 July 2017 11:37

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

Leffmann 27 July 2017 13:12

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 27 July 2017 16:13

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.

Quote:

Originally Posted by Leffmann (Post 1174506)
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 27 July 2017 17:00

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

Photon 27 July 2017 17:39

1 Attachment(s)
:great 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. :)

Quote:

Originally Posted by Nightfox (Post 1174477)
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. :great

Nightfox 27 July 2017 19:05

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 27 July 2017 20:08

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 27 July 2017 20:22

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.


All times are GMT +2. The time now is 04:34.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.

Page generated in 0.05061 seconds with 11 queries