Restore system sprite

[Lazycow]

After ending my program that takes of the System and bangs the hardware directly (yes, sorry), the system sprite pointer is invisible.

Hm, how could that happen? Yes, I am using hardware sprites - do I have to restore anything? Here's my current attempt to restore anything at the end of the program:

        move.l    graphicsBase,a6
        sub.l    a1,a1
        jsr    _LVOLoadView(a6)
        move.l    oldView,a1
        jsr    _LVOLoadView(a6)
        move.l    38(a6),$dff080
        jsr    _LVOWaitTOF(a6)
        jsr    _LVOWaitTOF(a6)

any hints?

[Asman]

And you call this when you back to OS ? What about restore values for dmacon and intena ?
If you want I can post my EnableOs asm routine here. Just give me a sign.

[Lazycow]

Oh... yes, these registers have been modified, indeed. Thanks for the hint.
I was just using my 20 year old code without thinking.

[Asman]

@Lazycow
Is it possible that you can release some old sources ? That would be so nice to look into such staff and perhaps optimize a bit or/and add some tweaks.

[Lazycow]

Ok, the sprite is visible again. Haha!
But another thing: I remember that sometimes when you start from floppy, the disk drive didn't stop running. What's the usual way to avoid this?

@Asman: Releasing 20 year old sources ... uh, that would be embarrassing!

[phx]

Originally Posted by Lazycow

But another thing: I remember that sometimes when you start from floppy, the disk drive didn't stop running. What's the usual way to avoid this?

You have two options:

1. Wait long enough before disabling multitasking, to give trackdisk.device a chance to turn off the motor.

2. Turn it off yourself after taking over the system.

        lea     CIAB+CIAPRB,a3

        ; Motor off for all drives.
        or.b    #$f8,(a3)
        nop
        and.b   #$87,(a3)
        nop
        or.b    #$78,(a3)               ; deselect all
        nop

[Asman]

@phx
Is second way works fine on faster machines too ?

@Lazycow
I usually wait 2 seconds (but I do not use cpu depend loop like I saw in some games) somewhere on begin of game (before system overtaken of course).

About releasing 20 year old sources: Why not. A journey of a thousand miles begins with a single step

[Lazycow]

just unpowering the motor, how crude... I try that one

@Asman: I might release the updated sources. The copper-modifications are somewhat freaky...

[phx]

Originally Posted by Asman

@phx
Is second way works fine on faster machines too ?

Yes. Works fine on my A3000 with CSPPC/060.

AFAIK waiting for a CIA-access will slow down the CPU sufficiently enough. And the NOP flushes the 060's instruction pipeline.

[Lazycow]

Kind of awkward, but there's another thing... I start the program on the workbench with double-click. Then it runs until it detects the mouse button.

But when the program terminates, workbench thinks I have dragged the icon and workbench moves it. Kind of annoying... After each start, I have to reposition the icon...
I tried to add delays (dos.library/Delay) before killing the system and after killing the system, but somehow this does not help. Any hints?

[Asman]

@phx - Thanks for info. It seems that nop is quite useful instruction.

@Lazycow - Everything depend. Did you use some kind WB startup code ? Or you just takeover the system on beginning ? Perhaps your system overtaken routine missing something.

If your project is not top secret then post asm routine here. Otherwise you can PM me and I will look into code, but of course I'm not guarantee that I will solve your all problems, because there are still many amiga coding things to learn

[Lazycow]

Maybe this is kind of an emulation problem, because the (emulated) harddisk is too fast... If I start it with doubleclick from floppy, there's no problem.

It should be released... soon... (hopefully) Double-click problem or not.

... I just have to fix the crude lazycow-startup-code again, because it fails when there's no shell-window when starting from floppy-startup-sequence directly. But I have found some example startup-code. Let's see...

[Lazycow]

Ok, I solved the double-click problem. The demo now only ends if the mouse button has been pressend and then released rather than pressed only.

[Lonewolf10]

Apologies to Lazycow for going back to the drive off code, but I tried using this in my own code:

	or.b	#%10000000,$BFD100	;as interrupts are off, we manually
	and.b	#%10000111,$BFD100	;switch off disk drive motor

... but instead of switching off the drives, it switches them all on! Was I doing something stupid, or are the NOP's in PHX's example code that important?

[phx]

It would be strange when your code switches a drive's motor on, but it may happen that you cannot switch it off, because the state of the DSKSEL0..3 bits (bits 3..6) is unknown before you clear them.

The motor bit (7) is only processed by a drive on a falling edge of its DSKSELx bit.

[Lonewolf10]

Originally Posted by phx

It would be strange when your code switches a drive's motor on, but it may happen that you cannot switch it off, because the state of the DSKSEL0..3 bits (bits 3..6) is unknown before you clear them.

The motor bit (7) is only processed by a drive on a falling edge of its DSKSELx bit.

Thanks for the help

[Lazycow]

Ok, I have fixed some OCS problems, but there's still a (minor) glitch on startup... some pixels in the topleft corner (visible for ca. 1s)
Here's the (modified) startup code from Stingray...

        move.l    graphicsBase,a6
        move.l    gb_actiView(a6),Display_oldView(a5) ; save old view
        move.l    $26(a6),Display_oldCop1(a5)
        move.l    $32(a6),Display_oldCop2(a5)
        sub.l    a1,a1 ; flush view
        jsr    _LVOLoadView(a6)
        jsr    _LVOWaitTOF(a6)
        jsr    _LVOWaitTOF(a6)
        lea    $dff000,a6
        move.w    $10(a6),Display_oldATKCON(a5)
        move.w    $1C(a6),Display_oldINTENA(a5)
        move.w    $02(a6),Display_oldDMACON(a5)

        move.w    #$7FFF,d0
        ;bsr    Display_WaitRaster
        move.w    d0,$9A(a6)            ; Disable Interrupts
        move.w    d0,$96(a6)            ; Clear all DMA channels
        move.w    d0,$9C(a6)            ; Clear all INT requests

        move.w    #$1fff,$9a(a6)
        move.w    #$1fff,$9c(a6)
        move.w    #$8200+32+64+128+256,$96(a6)    ; my DMA

I am almost certain it is visible after LoadView()...
Any ideas how to fix this? Is this the mouse pointer or what?

[Lonewolf10]

Originally Posted by Lazycow

Any ideas how to fix this? Is this the mouse pointer or what?

If you have set up the sprites correctly (pointing to a null sprite - unless you are actually using them) then it shouldn't be the mouse pointer.
Personally, I always have my sprites setup at the start of the copperlist.

It could be that you are pointing 2 bytes earlier than your screen display actually is located, and picking up variables or other data accidentally.

[Lazycow]

@Lonewolf10: Oops, you're right... after LoadView() the screen is ok, the garbage shows up later... I'll investigate...

[Photon]

It's heart-warming to see this, more support than my web host is giving my company

Any sprite DMA pointers should be changed only when bitplanes have been off until end of line, such as after $12c for a normal display window or at vblank/"EOF". Then there's no need for null sprites.

I've stopped caring about the floppy drive light It's not that big a deal. Look at the screen instead cos something awesome just loaded!!

And even 25 year old sources can show something never seen before to those who pay attention