English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 16 August 2005, 20:20   #1
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
Undocumented Amiga hardware stuff

I have found and confirmed many undocumented chipset features when improving emulation and i thought there may be some interest in seeing them documented..

Some of these may be common knowledge.

I'll start with the copper:

- Writing to "dangerous register" with COPCON bit 1 zeroed stops the copper (See AGA.guide COPCON for more information)

- SKIP doesn't really skip anything, it just prevent's next MOVE to do its write. SKIP followed by WAIT or another SKIP never "skips". (Game Apocalypse, uses SKIPs as nops in copper list)

- skipped MOVE to "dangerous register" (and COPCON zeroed) also stops the copper (Rainbow Island requires this.. it has quite buggy copperlist.)

- Copper is waiting, disable copper DMA, access both COPJMP1 and COPJMP2, enable DMA -> copper stops.

Copper stops = stays stopped until next vblank

More random info later..

EDIT: COPJMP1+COPJMP2 stop condition updated.

Last edited by Toni Wilen; 01 January 2006 at 20:12.
Toni Wilen is online now  
AdSense AdSense  
Old 16 August 2005, 21:28   #2
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,139
Keep the info coming, that's great!
Codetapper is offline  
Old 17 August 2005, 00:36   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
ECS/AGA and DDFSTOP >= 228 (0xe4) results in full horizontal overscan bitplane DMA. Like someone had set DDFSTRT=0x18 and DDFSTOP>=0xd4.

Does not happen in OCS.

Also some "illegal" DDFSTOP values can cause complete display corruption, syncs get messed up etc... (don't remember the exact values now)

Non-aligned DDFSTRT values cause bitplane delays (BPLCON1) work incorrectly. Basically hidden offset which depends on DDFSTRT is added to shift value. (I have called it "delayoffset". New Zealand Story, James Pond II AGA, Pinball Illusions, Loons Docs disks, Overkill AGA etc..)
Toni Wilen is online now  
Old 17 August 2005, 16:56   #4
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 653
thanks for the info Toni, that can help a lot sometimes

Quote:
Originally Posted by Toni Wilen
- Writing to "dangerous register" with COPCON bit 1 zeroed stops the copper
what is a "dangerous register"?
is the copper stopped for ever or until the next vblank?
Wepl is offline  
Old 17 August 2005, 18:39   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
Weird bitplane effect used in SWIV's scoreboard.

PF2P > 5 (BPLCON2) and BITPLANES == 5 and NOT AGA

- pixel in bitplane 5 = zero: planes 1-4 work normally (any color from 0-15 is possible)

- pixel in bitplane 5 = one: planes 1-4 are disabled, only pixel from plane 5 is shown (color 16 is visible)
Toni Wilen is online now  
Old 18 August 2005, 18:14   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
Mysterious world of blitter line mode..

- D-channel can be disabled. No effect on anything.. (even speed of blit stays the same)
- C must be enabled (nothing is drawn without C)
- B (not tested)
- disabling A stops BLTAPT from updating (result is incorrect lines)
- BLTDMOD is not used in line mode. BLTCMOD is used for both C and D.

And here is the most interesting undocumented feature ever:

- First pixel is written to address pointed by BLTDPT, all following pixels are written to address pointed by BLTCPT! (Demos Cardamon and Cardamom)
Toni Wilen is online now  
Old 04 September 2005, 13:38   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
Attached sprite:

Documentation says: odd sprite's SPRxCTL bit 7 must be set.

ECS (probably OCS too, not tested yet): sprite is attached if odd _or_ even (or both) sprite SPRxCTL bit 7 is set.

AGA: only odd sprite SPRxCTL bit 7 enables attachment.
Toni Wilen is online now  
Old 07 September 2005, 21:25   #8
Joe Maroni
Moderator

Joe Maroni's Avatar
 
Join Date: Feb 2003
Location: Germany
Age: 38
Posts: 1,283
Send a message via MSN to Joe Maroni
what the hell...

where did you get those infos...
Joe Maroni is offline  
Old 08 September 2005, 17:14   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
Debugging incompatibilities and running lots of small test programs on my real A1200 and A500 (but this is painful from floppies... Anyone have spare A500 HD controller that includes passthrough connector and memory expansion for sale? for example SupraDrive500XP)
Toni Wilen is online now  
Old 08 September 2005, 17:17   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
More or less useless info..

CLXDAT bit 15 is always set. ("not used" says HRM) Game "Barney and Freddy Mouse" breaks if this bit is not set...

HRM says [sprite to playfield] "collision detection does not change when you select either single- or dual-playfield mode". This is not true. There is small but significant difference..
Toni Wilen is online now  
Old 01 January 2006, 18:45   #11
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,495
Quote:
Originally Posted by Toni Wilen
Mysterious world of blitter line mode..

- D-channel can be disabled. No effect on anything.. (even speed of blit stays the same)
- C must be enabled (nothing is drawn without C)
- B (not tested)
- disabling A stops BLTAPT from updating (result is incorrect lines)
- BLTDMOD is not used in line mode. BLTCMOD is used for both C and D.

And here is the most interesting undocumented feature ever:

- First pixel is written to address pointed by BLTDPT, all following pixels are written to address pointed by BLTCPT! (Demos Cardamon and Cardamom)
This is most interesting, because you normally want 1 pixel of the line to be omitted if you want to fill the poly afterwards... Otherwise you get double pixels plotted at the corner points of the poly, resulting in the infamous horizontal lines emanating from the corners when it's filled.

I did it by subtracting 1 from the blit height in the linedraw routine just before drawing, Slayer did it by XOR'ing an extra pixel so it goes away, but could this mean that by pointing BLTDPT to a trash area, the pixel goes there and the rest of the line goes to BLTCPT and is correct for filling?

If it's true, then a bunch of cycles would be saved in the linedraw routine

1) one register saved and one sub.w (up to 12 cycles on A500)
2) one longword or word write to memory for the BLTDPT. UNLESS BLTDPT is increased after the blit to point to just beyond the last pixel. (up to 12 cycles more)
Photon is offline  
Old 01 January 2006, 20:10   #12
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
Quote:
Originally Posted by Photon
but could this mean that by pointing BLTDPT to a trash area, the pixel goes there and the rest of the line goes to BLTCPT and is correct for filling?
Exactly. Seems only Cardamon/Cardamom's coder found and took advantage of this weird feature.

Quote:
2) one longword or word write to memory for the BLTDPT. UNLESS BLTDPT is increased after the blit to point to just beyond the last pixel. (up to 12 cycles more)
BLTDPT == BLTCPT after blit ends. (Demo Deformations won't work properly without this)
Toni Wilen is online now  
Old 01 January 2006, 20:24   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
Browsed older changelogs more..

Switching bitplane DMA on during DDFSTRT ~<= hpos ~<= (DDFSTOP - size of fetch unit) can have 3 different results:

- OCS: nothing happens, bitplane DMA fetches don't restart until next line. (the rest of current horizontal line is also filled with background color)

- ECS/AGA: DMA restart normally if DMA was previously disabled when hpos was outside of DDFSTRT and DDFSTOP. (Sixth Sense Investigation's buggy copper list requires this..)

- ECS/AGA: display processing jumps to "DDFSTOP passed"-condition (process modulos after next fetch unit and end current line) immediately if DMA was previously disabled when hpos was between DDFSTRT and DDFSTOP. (Found this by doing tests on my real A1200)
Toni Wilen is online now  
Old 02 December 2007, 18:22   #14
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 210
Hi all this is my first post in this board !

I resurrect this old thread. First to say that, according to my tests (which may be not as extensive as those made by Toni) also BLTALWM is unused in line mode. (In contrast to what C= HRM says).

Thanks Toni for discovering BLTDPT is used just for first pixel, I now use this feature in my line routine.

I have also tried to replicate Photon technique to avoid "filling problem", but it didn't work. It seems to me that the blit height in line mode is a pixel counter, not a line counter, so subtracting 1 avoids the last pixel to be drawn. This is ok for lines with slope >= 1 (because there is one pixel per line) but not for the others:
a line finishing like
..............**
.................***

in one-dot mode becomes
..................*
.....................*
so the last pixel would not be drawn in any case (because of one-dot mode). This is not good because next line will start exactly there, so we end up with 2 pixels in the row.
I guess there is somethnig else I don't understand.
Photon, could you enlight me, please?


Quote:
Originally Posted by Photon View Post
This is most interesting, because you normally want 1 pixel of the line to be omitted if you want to fill the poly afterwards... Otherwise you get double pixels plotted at the corner points of the poly, resulting in the infamous horizontal lines emanating from the corners when it's filled.

I did it by subtracting 1 from the blit height in the linedraw routine just before drawing, Slayer did it by XOR'ing an extra pixel so it goes away, but could this mean that by pointing BLTDPT to a trash area, the pixel goes there and the rest of the line goes to BLTCPT and is correct for filling?

If it's true, then a bunch of cycles would be saved in the linedraw routine

1) one register saved and one sub.w (up to 12 cycles on A500)
2) one longword or word write to memory for the BLTDPT. UNLESS BLTDPT is increased after the blit to point to just beyond the last pixel. (up to 12 cycles more)

Last edited by TheDarkCoder; 06 December 2007 at 16:01.
TheDarkCoder is offline  
Old 15 March 2008, 17:50   #15
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
FMODE SSCAN2 bit. (This is documented but it can be easily missed and/or misunderstood..)

HRM says "If SSCAN2 bit in FMODE is set, then disable SH10 horizontal coincidence detect."

'Disable' means BOTH zero and one SH10 bit matches horizontal sprite comparator = same sprite can appear TWICE (horizontally) on screen. Without any copper tricks.

Fantastic Dizzy CD32 in Big6 compilation uses this feature to create background tree graphics, background is created using 4 x 64 pixel attached sprites.
Toni Wilen is online now  
Old 17 March 2008, 08:57   #16
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 210
Quote:
Originally Posted by Toni Wilen View Post
FMODE SSCAN2 bit. (This is documented but it can be easily missed and/or misunderstood..)

HRM says "If SSCAN2 bit in FMODE is set, then disable SH10 horizontal coincidence detect."

'Disable' means BOTH zero and one SH10 bit matches horizontal sprite comparator = same sprite can appear TWICE (horizontally) on screen. Without any copper tricks.

Fantastic Dizzy CD32 in Big6 compilation uses this feature to create background tree graphics, background is created using 4 x 64 pixel attached sprites.
Indeed I never understood such point in HRM! Thanks for pointing out!
TheDarkCoder is offline  
Old 11 May 2008, 09:14   #17
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
Another interesting sprite-related undocumented feature:

Sprites are visible between DDFSTRT - End of scanline. Not DDFSTRT - DDFSTOP as documented.

Tested with OCS and ECS Denise and A1200 (I am quite sure this is Denise's feature)

(found while debugging Blittersweet-demo)
Toni Wilen is online now  
Old 16 May 2008, 15:59   #18
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,903
Quote:
Originally Posted by Toni Wilen View Post
Sprites are visible between DDFSTRT - End of scanline. Not DDFSTRT - DDFSTOP as documented.
This wasn't exactly right.

It is first write to BPL0DAT that also enables sprites.

Write to BPL0DAT enables bitplane shift registers inside Denise (this is nothing new, Agnus DMA does this automatically internally). My guess is that there is logic that outputs background color as long as BPL0DAT has not been written to.

Test used: DDFSTRT set to 0x80, put sprite on left side of screen. It is not visible. Use copper to write to BPL0DAT on left side of screen. Single raster line of sprite is now visible + 16 pixels of bitplane data that was written to BPL0DAT.

Perhaps useful for some weird tricks, not sure
Toni Wilen is online now  
Old 30 June 2008, 20:37   #19
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,495
@Toni: Perhaps for a simple sprite-frame without having to add bitplane dma? (i.e. width 320 _plus_ some pixels, but only as sprites please)?

@TheDarkCoder: I'd have to look, but I think the trick was to calculate all blitter values normally, then subtract 1 from blitsize height just before drawing. This trick requires that all lines are drawn downward (or all upward), ie. swap endpoints to make sign of dy the same for all.





Quote:
Originally Posted by TheDarkCoder View Post
Hi all this is my first post in this board !

I resurrect this old thread. First to say that, according to my tests (which may be not as extensive as those made by Toni) also BLTALWM is unused in line mode. (In contrast to what C= HRM says).

Thanks Toni for discovering BLTDPT is used just for first pixel, I now use this feature in my line routine.

I have also tried to replicate Photon technique to avoid "filling problem", but it didn't work. It seems to me that the blit height in line mode is a pixel counter, not a line counter, so subtracting 1 avoids the last pixel to be drawn. This is ok for lines with slope >= 1 (because there is one pixel per line) but not for the others:
a line finishing like
..............**
.................***

in one-dot mode becomes
..................*
.....................*
so the last pixel would not be drawn in any case (because of one-dot mode). This is not good because next line will start exactly there, so we end up with 2 pixels in the row.
I guess there is somethnig else I don't understand.
Photon, could you enlight me, please?
Photon is offline  
Old 01 July 2008, 09:59   #20
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 210
Quote:
Originally Posted by Photon View Post

@TheDarkCoder: I'd have to look, but I think the trick was to calculate all blitter values normally, then subtract 1 from blitsize height just before drawing. This trick requires that all lines are drawn downward (or all upward), ie. swap endpoints to make sign of dy the same for all.
@Photon: please give a look, I'd like to learn a new trick. I tried to do what you suggested, but didn't work. The problem is that when you subtrack 1 from blitsize height, the line has one pixel less, not one row less. I have drawn all lines downward, but didn't work. :-(
TheDarkCoder is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
who can provide hardware to create ADFs of some old rare stuff like Nautilus...? Bernd support.Other 3 19 August 2011 23:41
Stuff for sale amiga a1200 plus more retro stuff blast MarketPlace 23 22 June 2010 19:05
Action Replay Undocumented Features deicidal support.Hardware 0 01 March 2010 17:15
I've got some Amiga stuff...I want your SNES stuff! Fingerlickin_B MarketPlace 14 20 February 2009 01:33
Amiga stuff for trade for Atari Stuff 8bitguy1 MarketPlace 0 12 February 2009 05:36

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:24.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Page generated in 0.87130 seconds with 13 queries