A.D.A. Amiga Demoscene Archive

from a "modern" (1996+) point of view you shouldn't disable the multitasking at all. the system has never been designed to be interrupted for longer time. just to let you know about it. not that i would ever have acted according to this advice :)

@cyf:

I read somewhere that the double WaitTOF cancel the Forbid...so forbid after waittof

where did you read this?

in a startup code, i think ("how to code"). I dont know if it's true...

@cyf: you are right, it is written in that startup code. I have to check it it's true, maybe it is true for Forbid but for Disable??

@noname: you are right!!! But, you know, oldskool rulez!!:-)

hmmm...the problem with my tiny startup code was the dmacon : if bit All not set to 1, then nothing on screen! ... strange...
now it works

@cyf: well it is not strange, that bit is the "Master DMA Control",if it is set to 0 it swithes off all DMAs, so BPL DMA is off and there is nothing on the screen!
:-)

But...wasn't z5 who posted his code? I think that problem is also in his code

the DMAEN bit #9 ? ha!! yes! pfiu, poor memory...old days!

here is my little code -> download

not yet wb icon tooltype compliant... but interrupt works
you can comment, add, correct something ^^

@TDC:
Thanks a lot for checking my sources. Still, after doing the necessary changes, it still doesn't work. Futhermore, i can't debug because Asm-one crashes on the "ownblitter" routine. (does one get better at this with practise?)

btw. in your changes you suggested, i think you forgot to set bit 9 in dmacon aswell?

@Overflow:

Whats the link to the Eurochart Dr. Doom tutorial?

Check out Eurochart 42,43,44 (dowloadable from a lot of websites, including www.irishq.dk). There are some very nice articles on system-startup, blitter, copper and more written by Dr.Doom.

@z5: Iam sorry it still doesn't work. Are you sure the problem is the Interrupt? I only checked that. What exactly does it happen?
I'll try to assemble it, so then I can do the fix.

@tdc:
i've updated and uploaded my source at the same location ( here). I'm just waiting for my vbi counter to reach a value before quiting back to workbench. Also, when i try to debug in asm-one, i don't get past the ownblitter routine (it crashes).

I compared my source with the startup/vbi counter of Cyf and i'm doing nearly everything the same. I've got a feeling that it is going to be something stupid... :)

I've got a feeling that it is going to be something stupid... :)

yes, it's often the case !

err...it's the same source, no ? (move.L #$7fff,dmacon(a5) not corrected...)

other error, you write :
lea vbroffset,a0 ---->>> move.l vbroffset,a0 !

err...it's the same source, no ?

@Cyf:
Nope, something i assembled from various sources. Did quite a bit of looking around, added stuff, changed a few things on the way, followed the tutorial from Dr.Doom... And in the end, surprisingly, it had everything that is in your startup/interrupt routine (well, apart from the fact that mine doesn't work :) ) and i understand what's going on. So i have learned a lot about startup/shutdown and interrupt.

But i want to find the reason why it doesn't work instead of changing to another system allready. That's the best way to learn (allthough sometimes frustrating).

Edit: if you were asking if the source i uploaded is the same as before, no it isn't. And yes, i have corrected all the issues that TheDarkCoder has mentioned. (some interesting hits and tips in there).

ps:
"lea vbroffset,a0" it's not the same result that "move.l vbroffset,a0"

in first case, a0=address of the variable vbroffset (for example $30000)
$6c(a0) is not address of $6c+VBR but $6c+vbroffset (=$3006c)

in second case, a0=content of the variable vbroffset=VBR

Good morning!!! Yesterday evening I spent some time coding, just like the old days!! :-) First of all:

IT IS TRUE, that WaitTOF exits from the Forbid state, as reported in the startup form HowToCode!! SHAME ON ME!!!!!!!!!!!!!!! :-((((
This makes a problem, although not so important practically, but maybe interesting. I wrote some comment about it in the Cyf source code.
Anyone interested??
After that I examined z5 and Cyf startups. Well, I would like to say that I didn't do that trying to seem smarter than them. I think there is no such a thing as "the best startup". There are several good ways to do a startup (also bad ones :-) and any coder has his style and preferences, so vive-la-difference. I just looked their routine, changed them a bit and put comments to suggest different, not necessarily better ways. I think it's always interesting to look at an alternate point of view.
Said that, now I have these two startup in a "dark-remixed" version.
Unfortunately I have no web page where to put them so interested people can download them. Should I post them into the forum? Or send to someone who can put them on the web?

Quick notes for the authors:

@z5: Er...indeed, you code has some bug! :-)
I worked on it and finally got it work.
There were several bug, the most important one was the "lea vbroffset,a0" instead of the move.l, as Cyf alredy reported. Unfortunately, there is still at least one bug that I didn't find, since now ASM-One reports an error, when the code exit. I also didn't try your routine that uses the blitter. However, the Vblank interrupt now works. I put many comments and suggestions. Should I send it to you?

@cyf: Your code is very nice, I only added some comment. Most important, I commented the problem of the Forbid/WaitTOF and possible workarounds.

regards

Hello TDC !
yep, commented sources are good :)
perhaps z5 can put these 2 sources on ada.
and I can put them on my site (send by mail cyberpingui(arobase)free.fr)

@tdc:

It's only two weeks since i started assembler, so one can't expect me to have a decent startup-routine already :) I'm glad with what i've got so far. I'm going to get the vbi working with the suggestions here, then get to my next target: adding sound with P61 player.

You can send both startup-routines to me and i'll gladly put them online for others to download/change/ameliorate... See the contact page on ada for my email address. And thanks a lot!!

ok, so I sent both sources to z5!!

@z5: Yep, you really did a lot of progresses in2 weeks!! Keep going on!!
We all do a lot of bugs, as you saw, after 15 years of Amiga coding (well, not continuosly, there have been several interruptions) I still do stupid bugs as the one of Forbid/LoadView I discovered yesterday thanks to Cyf!!!
Shame on me!! :-(
And many 10x to Cyf and to this forum for giving a new opportunity to discuss about coding!! :-)

You can download Cyf's startup/vbi/shutdown here (i decided not to release my code because it's still buggy and not really wise to release code from a complete newbie :))

By the way, if this forum keeps going, i will assemble info and maybe create a coder's corner on A.D.A., but let's see first how it evolves. This discussion about vbi/interrupt/startup has again gathered a lot of info :)

thanks cyf and tdk!

good comments

* Comment by TDC: USE a modern assembler that knows MOVEC VBR,D0 !!
; for example ASM-One!!!
dc.l $4e7a0801 movec Vbr,d0

yep. I use DevPac 3, but this line was before I use devpac3 and when I coded on A500 with devpac 2 ^^ (see the test if 680x0...just for a1200 compatibility and the ecs mode in coplist)

@cyf: how is devpac 3?? Never seen it.Does it support the 020+ instructions?
and CPU specific issues? But it's long since I heard about it,so I guess it is not aware of 060. It is still supported?

devpac 3 is good :) (I like IDE)
support 68020,30, and 40, not 060/ppc (but I havent 060!)

I just installed asm-one, and I would need to test it

In the meantime, my startup/vbi is working and very stable :) I've got two picture wipe effects in there aswell with vbi timing in between effects.

Still don't really understand why you do btst #5,intreq+1(a5) instead of btst #5,intreq(a5)? Even if btst was per byte, i would still still need the lowest byte of intreq to test the vbi interrupt request, no? More strangely, it seems to work in both ways...

EDIT:
btst intreqr(a6)=btst $dff01e doesnt work. read hi byte because test direct address $dff01e
if you put value of $dff01e in a register like d0, and test register, the lower byte is read first. for 680x0. on a 68000, it's possible to test for example blitter : btst #14,dmaconr instead of btst #6 on 680x0.
if someone could better explain.

you can now share you startup (and wipe) code :))

@tdc: another subject:
I have some problem with integration of old replayroutine (like NT, PT1, PT2, PT3) in this startup code : no music, or music ok but when exit, system crash when a key pressed (!). ok with simple NT replay, but a Recoverable alert...

pfiu, yes, I always had a problem with replay routines cia, but here even with NT or normal PT... it's strange...or it's me ?! all my old sources I tested works with PT1.1 replay (and old startup)

so, please write a special chapter for replay routines ! and especially P61!^^

@Cyf:
I'm reading your mind :) I have created a topic on P61 replay routine before i saw your request here :)

about BTST...
the 680x0 CPUs are "big endian". Chack on the net what oes it mean in general. In this particular case, it means that the word register INTREQ is mapped in memory in 2 bytes: the byte at $dff01e contains bits 8-15 while
the byte $dff01f contains bits 0-7. What you really need to test is bit 5.
The BTST (and also BSET,BCLR;BCHG) when the destination operand is in memory, test always inside a byte. BTST #5,$01e tests bit 5 if the byte at $01e, which is bit 13 of the register INTREQ!!!! Yo are lucky that your code works, beacuse bit 13 is another interrupt which by chance happen to be set to 1.
Also note that this is true for any 680x0, also for 68000. The BTST #14,DMACONR, works because bit #14 is in the high byte. Since the bittest work ona byte, it test the bit 14 MOD 8 = 6. I guess that if you write BTST #22,DMACONR it works too! BUT, problems are when you try to test the low byte of a word.

about replayers: it's hard to make old rotine work with all CPU.
Let's move on the other thread!

you can now share you startup (and wipe) code :

well, i'm going to work on it a bit more. I'm going to add sound (with P61 player routine) and try to comment and explain the complete source code. Then i will make an archive of everything (picture, module, all files) and put it online.

I succeeded in doing work the TrackerPacker3 player (with CIA timer) ! here

now, the P61 ! ...Edit : YES! It works! here

I read somewhere (from Mr Bluesky I think) :
before using OwnBlitter :
1. stop multitasking (forbid)
2. wait blit
3. ownblit

and before change Intena, use jsr Disable(a6) (stop interrupt)

good ?

@Cyf:

I would say that the WaitBlit breaks the Forbid state, so it is useless to do 1 and 2. It it exactly the same issue as the error I was doing: WaitTOF breakes the Forbid state. The RKRM says that whenever a task enters a Wait state,
the forbid state is broken. Moreover, unlike the case of the View, the OwnBlitter function has been provided by C= exactly for the purpose of taking direct control of the blitter. So it is really safe to do as specified by C=, i.e. just OwnBlitter AND WaitBlit. (I don't remember the correct order on-the-fly, but it's clearly specified on the manuals).

Regarding the Disable before changing INTENA, I say YES, that's better than doing a "simple" Forbid. That's what I do.

[quote]How does one add timing to a demo? [/quote]

timer.device

I am serious.