krabob
Member |
I have been doing OS Enabled demo between 1999 and 2004 with intuition screens, and now I want to experiment with aga and direct blitter access on non-accelerated machines. But it seems intuition uses copjmp and trash the blitter writes sometimes. Plus, I also want fmode with %1111 (faster blitter) So I gave up the blitter+os solution.
So I started to get back to oldschool startups and I know there's a lot about.
I've read some Hardware refs, and compared the recent available startups (blueberry's 4kb one) and my last old system-shunt inherited from other coder's startup fom 1998.
Plus,as I want to run with low memory, I need to stream files with dos.library, from HD or floppy. That said, and after a lot of testing, I did my own startup That does that:
1. I still Forbid() at start and Permit() at end,and keep dmaconr/intenar/intreqr/adkconr
2. I still LoadView(NULL) and set copper with cop1lc
3. I create my frame vertb interupt with addintserver/remintserver, no use for $6c/VBR check.
4. I don't touch dmacon/intena at start like all startup does, it kills dos.library load capabilities: multitask is disabled, but all OS interrupts management are always on.
5. The last P61 12 is inited in cia+system mode. (note for the history, on a 4K 060 with an ariadne and a deneb, P61 test example didn't work with system=0; worked with=1)
...so during the demo, intuition continue to live and receive inputs, and I could just crash my demo by monkeying the keyboard very fast (the shell I use to launch must receive messages and is unable to answer them). Also, moving mouse takes about 60 or 70 lines of frame, and some mouse moves/clicks are also interpreted by WB when returning...
and sometimes it crashed. But I think I have found the solution:
Using an example here: http://eab.abime.net/showthread.php?t=62322
I setup a handler that receives from input.device, and I prevent keyboard and mouse signals to reach the workbench. Plus, I can use keyboard for anything (quitting with esc),...
My demo environment looks stable now, I did some heavy testing, And I have no more the latency dues to ghost mouse movements...
So I think I will let "os interupts" on for my demo, I wouldn't gain a lot of CPU shunting them. Still I have to use ownblitter/disown at some moment , and I use dmacon for blitter hog, but I think I will not touch intena at all.
Just so you know.
Apart that I have a question: What is the second copperlist for ? Is it executed simultaneously ? can you wait independant positions from the other copper ?
|
Angry Retired Bastard
Member |
krabob: Apart that I have a question: What is the second copperlist for ? Is it executed simultaneously ? can you wait independant positions from the other copper ? Do you mean the 2nd copper pointer, $dff084.l ? It's not a separate copperlist but rather another program counter. It's useful for stuff like calling "copper sub-routines". Pseudocopperlist:
CList1:
dc.w $5c07,$fffe ; wait for some line
dc.w $0080,#>returnpoint ; set copptr1 to our return address
dc.w $0082,#<returnpoint
dc.w $0084,#>CList2 ; set copptr2 to the subroutine
dc.w $0086,#<CList2
dc.w $008a,$666 ; start copper execution from copptr2 ( == jump to subroutine)
returnpoint: ; copper execution continues here when the subroutine is finished
....
CList2:
... do a bunch of stuff ....
dc.w $0088,$666 ; start copper execution from copptr1 ( == jump to the returnpoint)
|
