15 February 2010, 11:39 | #21 |
Registered User
Join Date: Jul 2006
Location: Lund / Sweden
Age: 45
Posts: 171
|
@pcm: Indeed of Instinct.
Well, it simply didn't wait at all. I checked the HRM aswell and found an example. They use: dc.w $80e3,$80fe And that works. However, annoyingly, the top-most bit must be set for it to work for scanlines >= $80, and cleared for scanlines < $80 otherwise it simply won't wait at all. Which is weird, since no of the vertical mask bits are set. Are the top most vertical raster position always used in the compare independant of mask bits or is this a winuae "feature"? (Just learning some amiga stuff, and started with the copper and wanted to make a simple copper loop example. Next step is to port the sierpinski zoomer from Andropolis just to teach myself some Amiga) |
15 February 2010, 11:41 | #22 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
You need to wait for last horizontal position (I think DF should work) because comparison is equal or larger.
(EDIT: I really need to learn to refresh before posting next time) |
15 February 2010, 11:44 | #23 |
Registered User
Join Date: Jul 2006
Location: Lund / Sweden
Age: 45
Posts: 171
|
@Tony:
Yeps, understood. What about the top-most bit? Why does that matter? How come it isn't vertically independant when all the vertical mask bits are set to 0? |
15 February 2010, 11:44 | #24 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
You're gonna do the Sierpinski zoomer on Amiga?
Cool I promised myself I'd try to make one of those on Amiga after I saw how cool it looked on the C64. I wonder if an alternate approach could be done with a couple of waits. Something like: wait for any vert pos that ends in binary 0 (ie. all even lines) and wait for any vert pos that ends in binary 1 (ie. all odd lines) + horiz pos $01 might work? Just speculating really. Last edited by pmc; 15 February 2010 at 11:52. |
15 February 2010, 11:44 | #25 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
Whoops - no need to speculate when Toni is around... or after re-reading previous posts!
|
15 February 2010, 12:03 | #26 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
Because bit 15 is not part of the mask (which also means it is impossible to use same WAIT for scanlines < 0x80 and >= 0x80). Check HRM and/or previous posts more carefully
|
15 February 2010, 12:34 | #27 |
Registered User
Join Date: Jul 2006
Location: Lund / Sweden
Age: 45
Posts: 171
|
Yeps, RTFM indeed. Clear as crystal now. Thanx guys.
|
01 September 2010, 20:14 | #28 |
AMOS Extensions Developer
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 44
Posts: 1,924
|
An old, but useful thread
Now I need some help. I have set up a working copperlist - well the screen displays ok. However I am having trouble displaying a sprite. I have set the registers as follows: move ADDRESS_H,SPR0PTH move ADDRESS_L,SPR0PTL move ACTMOUS,SPR0POS move $A000,SPR0CTL MOVE #$120,DMACON ADDRESS_H and ADDRESS_L are 2 16-bit values which together make up the longword that points to the starting address of the sprite data. ACTMOUS is calculated using the X Mouse and Y Mouse positions, but for an example position it is set to $B118. Which is in the middle of the screen, right? Regards, Lonewolf10 |
01 September 2010, 20:50 | #29 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
When you use sprite DMA you don't have to set the POS and CTL registers manually, they are to be inserted at the top of the sprite data pointed to, in that order.
The sprite coordinates correspond to those of the display window, so the center of a standard 320*256 screen would be about X 288 and Y 172. Also, writing $120 to DMACON will turn off bitplane and sprite DMA, you need to set the highest bit as well, and write $8120. |
01 September 2010, 20:54 | #30 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
Setting POS and CTL manually does work (some games and demos does it) but note that DMA internally does first POS and CTL fetch at line 25 (PAL) or 20 (NTSC) (if DMA is enabled)
|
02 September 2010, 11:09 | #31 |
Long time member
Join Date: Jul 2001
Location: UK
Posts: 754
|
Many years ago I released all my devpac source code disks and one of them contains my first ever demo - bouncing copper bar(s)
I still remember the rush I got when I first got it working. It was about 4 in the morning as Id been experimenting all night. Unfortunately I dont have the disks in adf format anymore but I think Ian may have them |
02 September 2010, 11:47 | #32 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
Here's your stuff Big-Byte
A few years back you were kind enough to share your .adf source code disks with me. Sorry to hear you lost them yourself - hope you enjoy seeing the fruits of all your hard work again. Last edited by pmc; 21 September 2010 at 17:40. |
02 September 2010, 22:39 | #33 |
AMOS Extensions Developer
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 44
Posts: 1,924
|
Thanks for all the tips.
I DL'ed "Big-Byte.rar" and will look at it over the weekend Regards, Lonewolf10 Last edited by Lonewolf10; 02 September 2010 at 22:40. Reason: forgot "and", lol. |
03 September 2010, 21:35 | #34 |
AMOS Extensions Developer
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 44
Posts: 1,924
|
For those using WinUAE like me (both my Amiga 600's are down right now), you can cheat a little and examine registers by pressing PageUp (activates a limited version of HRTmon). WARNING: There is no way back to what you were doing so make sure you save everything before hitting PageUp.
Now simply type the letter "E" and you can go through all the registers and the values at the time you pressed PageUp. It only lists 6 or so registers at a time, so keep typing "E" to list the next few. You can press the down key to list them one at a time, but when you reach the last one and do this it tries to continue where it left off when you pressed PageUp - it normally crashes the emulated Amiga at this point. I have found it useful to compare my register values with say, those used by workbench. Obviously, certain ones will be different (depending on screen size, depth, etc.). @Leffmann Still no joy with the sprite. I tried it by not setting the POS and CTL registers and with setting them manually, but made no difference. Is there anything specific required for the sprite data, or is it just a bunch of bitplane data? Regards, Lonewolf10 |
03 September 2010, 21:53 | #35 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
"Limited version of hrtmon"? I guess you mean Action Replay 1200? Full hrtmon is also supported (check ROM panel)
If you want to see true and full custom register contents (even write-only ones), use built-in debugger (Shift+F12) |
03 September 2010, 22:07 | #36 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
Here's an example. You can't assemble it in ASM-One directly but it's short enough to get the jist of:
Code:
include customregisters.i include macros.i ;------------------------------------------------------------------------------- section code_p Start moveq #-1, d0 moveq #-1, d1 moveq #0, d2 moveq #2, d3 jsr SetSystem tst.b d4 beq .exit bsr MousepointerTest jsr RestoreSystem .exit moveq #0, d0 rts ;------------------------------------------------------------------------------- MousepointerTest lea $dff000, a6 bsr Setup ; Read the initial counter values to prevent the pointer ; from blinking around when we start move.w joy0dat(a6), Mousecounters .mainloop WaitFrame bsr GetMousepos bsr SetSpritepos btst #6, $bfe001 bne .mainloop rts ; This routine keeps track of the mouse counter values and uses them to ; to calculate how much the pointer has moved each image frame. ; We think of the screen as 1280*1024 units in order to get some precision, and ; divide these coordinates by 4 to obtain the pointer's position in screen ; pixel coordinates GetMousepos ; Get the previous counter values and store the new ones move.w Mousecounters(pc), d2 move.w joy0dat(a6), d1 move.w d1, Mousecounters ; Calculate X counter difference move.b d1, d0 sub.b d2, d0 ext.w d0 ; Calculate new X position and clamp against screen edges add.w .mousepos(pc), d0 bpl .xok moveq #0, d0 .xok cmp.w #319*4 + 3, d0 bls .calcy move.w #319*4 + 3, d0 ; Calculate Y difference .calcy clr.b d2 sub.w d2, d1 asr.w #8, d1 ; Calculate new Y position add.w .mousepos+2(pc), d1 bpl .yok moveq #0, d1 .yok cmp.w #255*4 + 3, d1 bls .posok move.w #255*4 + 3, d1 .posok ; Store the new values and return pixel coordinates in D0-D1 movem.w d0-d1, .mousepos lsr.w #2, d0 lsr.w #2, d1 rts .mousepos dc.w 500, 500 Mousecounters dc.w 0 ; Take pixel coordinates in D0-D1 and place sprite SetSpritepos ; X 128 Y 44 will be the upper left corner in sprite ; coordinates. They correspond to the coordinates used for ; the display window minus 1 pixel in X add.w #$80, d0 add.w #$2c, d1 ; Get bit 0 of the X position and place in D2 moveq #0, d2 lsr.w #1, d0 addx.b d2, d2 ; Check bit 8 of the Y start position and set in D2 btst #8, d1 beq .novstart addq.b #4, d2 .novstart move.b d1, Sprite ; Add sprite height to get Y stop position and set in D2 addq.w #8, d1 btst #8, d1 beq .novstop addq.b #2, d2 .novstop ; Write POS and CTL into sprite data move.b d0, Sprite+1 move.b d1, Sprite+2 move.b d2, Sprite+3 rts Setup move.w #bpl_1bpl | bpl_color, bplcon0(a6) ; Set video priorities to 7 so sprites appear in front of ; bitplanes move.w #7<<3 | 7, bplcon2(a6) ; 320*256 large display starting at X $81 Y $2C move.w #0, bplcon1(a6) move.w #0, bpl1mod(a6) move.w #$38, ddfstrt(a6) move.w #$d0, ddfstop(a6) move.w #$2c81, diwstrt(a6) move.w #$2cc1, diwstop(a6) move.w #$89a, color00(a6) move.w #$eef, color01(a6) move.w #$000, color17(a6) move.w #$e48, color18(a6) move.w #$fcd, color19(a6) ; Write the bitplane pointer into the copper program move.l #Bitplane, d0 move.w d0, Bitplaneptr+4 swap d0 move.w d0, Bitplaneptr ; and the sprite pointers lea .sprites(pc), a0 lea Spriteptrs, a1 moveq #8-1, d0 .setsprites move.w (a0)+, (a1) move.w (a0)+, 4(a1) addq.w #8, a1 dbf d0, .setsprites ; Set copper program pointer and load immediately move.l #Copperprog, cop1lc(a6) move.w d0, copjmp1(a6) ; Start all DMA move.w #dma_set | dma_en | dma_bpl | dma_spr | dma_cop, dmacon(a6) rts .sprites dc.l Sprite rept 7 dc.l BlankSprite endr ;------------------------------------------------------------------------------- section data_c ; Bitplane data for a 320*256 frame Bitplane blk.b 40, %11111111 rept 254 dc.b %10000000 blk.b 38, %00000000 dc.b %00000001 endr blk.b 40, %11111111 ; 8*8 pixel sprite. The first two words are the POS and CTL ; control words which the sprite DMA will read and ; set automatically every frame, so are the last two words ; which we set to 0 to mark that the sprite is not to be ; redisplayed again further down the screen. Sprite dc.w 0, 0 dc.w %1111111000000000, %0000000000000000 dc.w %1100000100000000, %0111111000000000 dc.w %1000000100000000, %0111111000000000 dc.w %1000001000000000, %0111110000000000 dc.w %1000010000000000, %0111100000000000 dc.w %1000100000000000, %0111000000000000 dc.w %1001000000000000, %0110000000000000 dc.w %0110000000000000, %0000000000000000 BlankSprite dc.w 0, 0 ; We don't need to use the copper to display some sprites ; but it's convenient to delegate f.ex reseting bitplane ; and sprite pointers to it Copperprog Bitplaneptr = *+2 cmove 0, bpl1pth, 0, bpl1ptl Spriteptrs = *+2 cmove 0, spr0pth, 0, spr0ptl cmove 0, spr1pth, 0, spr1ptl cmove 0, spr2pth, 0, spr2ptl cmove 0, spr3pth, 0, spr3ptl cmove 0, spr4pth, 0, spr4ptl cmove 0, spr5pth, 0, spr5ptl cmove 0, spr6pth, 0, spr6ptl cmove 0, spr7pth, 0, spr7ptl cend Last edited by Leffmann; 03 September 2010 at 22:13. |
04 September 2010, 01:34 | #37 |
AMOS Extensions Developer
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 44
Posts: 1,924
|
Thanks for the code. I decided to RTM and now have a better understanding of sprites. It's good to have a working example I can compare mine against. I probably set one of the registers up wrong, doh!
I think the Sprite data might be wrong... can sprites start with word values of 0,0? I though the hardware looked for 0,0 to mark the end of the sprite, or doesn't that count when you initialise the sprite? Regards, Lonewolf10 |
04 September 2010, 03:01 | #38 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
The control words can be 0, which is interpreted as a sprite both starting and ending at line 0. This is how you stop a sprite from showing on the screen, and is why you set the next pair of control words at the end to 0, so the sprite doesn't appear again further down the screen.
Those control words get filled in right away by the SetSpritepos routine anyway so I just left them as 0 instead of some appropriate values. In worst case the pointer is simply not visible during the first frame. The structure of the sprite data is a pair of control words followed by its bitmap data, then comes a new pair of control words followed by more bitmap data (if needed), and so on. This is to allow you to reuse the same sprite channel to display more sprites. Each new sprite must be placed further down and completely separated from the previous by at least 1 scanline, so it's possible to f.ex create a column of sprites using the same sprite channel, but not a circle. The horizontally scrolling starfields you can see in many demos on the Amiga can be made by reusing a single sprite channel. This is all explained in the HRM, but I can write up a new example if you'd like. |
04 September 2010, 12:18 | #39 |
AMOS Extensions Developer
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 44
Posts: 1,924
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Combining copper scrolling with copper background | phx | Coders. Asm / Hardware | 16 | 13 February 2021 12:41 |
Understanding DIWHIGH register | jman | Coders. Tutorials | 6 | 11 June 2011 12:29 |
Anyone like to help understanding this bootblock ??? | Joe Maroni | Coders. Tutorials | 2 | 15 February 2007 17:33 |
Understanding ASM Routine | Crackersixx | Coders. Tutorials | 13 | 10 February 2006 02:58 |
understanding the COLORXX regs... | Joe Maroni | Coders. General | 2 | 14 February 2005 07:50 |
|
|