English Amiga Board


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

 
 
Thread Tools
Old 24 September 2008, 10:34   #21
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,017
OCS-only "scanline" effect. (discovered in other theads, documenting here)

DDFSTRT < 0x18 = every other line is blanked.

My theory:

Bitplane state machine state can only change sequentially. Bitplane state machine states are something like:

1: inactive
2: "passed 0x18" (more like passed 0x14 but it isn't important)
3: "passed ddfstrt (=active)"
4: "passed ddfstop"

Normal horizontal line, DDFSTRT >= 0x18. 1 -> 2 -> 3 -> 4 -> 1

DDFSTRT < 0x18:

first line: 1 -> 2 (1->3 can't happen)
second line: 2 -> 3 -> 4 -> 1 (normal visible line)
third line: 1 -> 2 (another blank line)
and so on..

(I guess this was supposed to prevent < 0x18 DDFSTRT but implementation was 100% correct)

Note that display can get quite messed up (or system can even crash) if DDFSTRT is too small because bitplane dma starts conflicting with refresh slots.

ECS/AGA fixes this "bug".
Toni Wilen is online now  
Old 15 October 2008, 00:42   #22
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
I think this is a normal behavior of the vdu (IC) timing vs video timing. At least if I remember page 190 of HRM correctly.

Last edited by Photon; 16 October 2008 at 23:32.
Photon is offline  
Old 20 October 2008, 12:18   #23
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,017
Quote:
Originally Posted by Photon View Post
I think this is a normal behavior of the vdu (IC) timing vs video timing. At least if I remember page 190 of HRM correctly.
What chapter? Different HRM revisions have different page numbers

Perhaps it is documented somewhere but it has nothing to do with timing, Denise could simply inhibit sprite parallel to serial conventers after DDFSTOP but I am quite sure Denise does not know anything about DDFSTRT or DDFSTOP, it most likely waits for first BPL1DAT write (by Agnus) which then starts display processing circuitry until next hsync.
Toni Wilen is online now  
Old 01 December 2008, 20:48   #24
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,017
OCS/ECS-only "7-plane" mode.

If BPLCON0 is set to 7 planes following interesting things happen:

- Agnus DMA sequencer uses 4 planes mode
- Denise shows all 6 planes (can be EHB,HAM or DPF, all work)

BPL5DAT and BPL6DAT are "static" (16-bit pattern repeats) 5th and 6th plane pattern. (of course copper can also be used to update the pattern)

This trick was used in intro First Anniversary by Lazy Bones (perhaps only one program using it..) BPL5DAT was used for vertical lines. Normally you can't have >4 planes without slowing down the copper.

Perhaps it can also be used for some weird EHB/HAM tricks
Toni Wilen is online now  
Old 01 December 2008, 22:16   #25
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 41
Posts: 7,816
Send a message via MSN to dlfrsilver
great ! Toni, can this technic be used for games or it is specifically made for programs
like demos ?
dlfrsilver is offline  
Old 15 December 2008, 13:28   #26
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,146
Quote:
Originally Posted by Toni Wilen View Post
This trick was used in intro First Anniversary by Lazy Bones (perhaps only one program using it..) BPL5DAT was used for vertical lines. Normally you can't have >4 planes without slowing down the copper.
I think this intro by Brainwalker [hi mate, if you should ever happen to read this: Greetings =)] uses the same feature (for the analyzer). Maybe you can check Toni?
StingRay is offline  
Old 15 December 2008, 18:11   #27
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,017
Quote:
Originally Posted by StingRay View Post
I think this intro by Brainwalker [hi mate, if you should ever happen to read this: Greetings =)] uses the same feature (for the analyzer). Maybe you can check Toni?
Yes, it does use "7 planes" for "noise" effect. 2 programs so far, maybe there are more..

(download link is broken)
Toni Wilen is online now  
Old 15 December 2008, 18:18   #28
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,146
Quote:
Originally Posted by Toni Wilen View Post
Yes, it does use "7 planes" for "noise" effect. 2 programs so far, maybe there are more..

(download link is broken)

Thanks for checking! And sorry that I didn't check the download link, I've fixed it now, thanks for that info too!
StingRay is offline  
Old 24 December 2008, 22:44   #29
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,017
"Not really undocumented but if you want to make A1000-only program very easily"

A1000: 00D80000 - 00DDFFFF is custom chip mirror
Other models: RTC + non mapped space. Never custom chips.

Original/nonmodifed game Hacker uses (accidentally?) 0xDDF00A to read mouse counters. This only works on A1000

(note that WinUAE 1.4+ properly maps this area which can look like Hacker got broken but in reality it was "broken" previously..)
Toni Wilen is online now  
Old 02 August 2009, 14:04   #30
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,017
More blitter stuff:

All blitter cycles require free bus cycle (=not used by any other Agnus DMA channel), including blitter idle cycles. (which can become free cycle for CPU if CPU needs bus cycles)

Following blitter channel combinations add extra idle cycle if fill mode is enabled: 1, 5, 9 and D (for example normal AD copy cycle diagram becomes AD-)

Switching from "extra cycle fill mode" to non-extra cycle mode (fill or not) when blitter is already active: blitter stops. (there is one demo part that only works due to this feature, it has buggy blitter wait..) EDIT: blitter can also stop when changing bltcon0 while blit is active.

Starting blitter: 2 blitter idle cycles needed before normal blitter cycle diagram starts.

Copper writes to custom registers happen 1 cycle later than CPU writes.

Last edited by Toni Wilen; 03 August 2009 at 09:32.
Toni Wilen is online now  
Old 03 September 2009, 07:37   #31
FrenchShark
FPGAmiga rulez!
FrenchShark's Avatar
 
Join Date: Dec 2007
Location: South of France
Age: 45
Posts: 155
Quote:
Originally Posted by Toni Wilen View Post
More blitter stuff:

All blitter cycles require free bus cycle (=not used by any other Agnus DMA channel), including blitter idle cycles. (which can become free cycle for CPU if CPU needs bus cycles)

Following blitter channel combinations add extra idle cycle if fill mode is enabled: 1, 5, 9 and D (for example normal AD copy cycle diagram becomes AD-)

Switching from "extra cycle fill mode" to non-extra cycle mode (fill or not) when blitter is already active: blitter stops. (there is one demo part that only works due to this feature, it has buggy blitter wait..) EDIT: blitter can also stop when changing bltcon0 while blit is active.
After implementing the blitter in VHDL and studying the DMA sequences and the remarks from Toni, I think I get most of it :
- Sources A and B datapaths need two cycles to reach the minterm block because of the 32-bit shifter.
- Source C datapath needs just one cycle to reach the minterm block.
- Source A DMA cycle is always present, if USEA = 0, it becomes an idle cycle. During this cycle, the minterm from the previous data is computed, that's the reason why the blitter put an idle cycle if source A DMA is off.

These 3 remarks are enough to explain the "Blitter Speed" rules in the HRM.

A and D only : 2 cycles
cycle #1 : read A(0)
cycle #2 : D idle + mask & shift A(0)
cycle #3 : read A(1) + minterm(0)
cycle #4 : write D(0) + mask & shift A(1)
etc...

B always add one cycle : because of the second cycle needed for its shifter.

C or D is free : because it is during the second cycle needed by A to mask and shift.

I do not explain the fill mode "bug" yet, the only extra cycle that would make sense is for AD. It must be A, idle, D (if we suppose that the blitter needs an extra "fill mode" cycle after the "minterm" cycle occuring during A)

Quote:
Starting blitter: 2 blitter idle cycles needed before normal blitter cycle diagram starts.
I bet it is 3 idle cycles if USEA=0 and 2 idle cycles if USEA=1.
Blitter cycle sequences #1 to 7 in the HRM should be shifted by one cycle to the right to show the first empty A cycle.

Toni, tell me what you think.

Regards,

Frederic
FrenchShark is offline  
Old 03 September 2009, 15:34   #32
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,017
Quote:
After implementing the blitter in VHDL and studying the DMA sequences and the remarks from Toni, I think I get most of it :
- Sources A and B datapaths need two cycles to reach the minterm block because of the 32-bit shifter.
- Source C datapath needs just one cycle to reach the minterm block.
I haven't thought about internal logic too much but this seems perfectly logical.

Quote:
I do not explain the fill mode "bug" yet, the only extra cycle that would make sense is for AD. It must be A, idle, D (if we suppose that the blitter needs an extra "fill mode" cycle after the "minterm" cycle occuring during A)
I am quite sure it is AD- (A--AD-...AD--D)
(I guess the fill logic happens in "second cycle" in blitter pipeline)

Quote:
I bet it is 3 idle cycles if USEA=0 and 2 idle cycles if USEA=1.
Yes. I meant 2 idle cycles that are always at start, not counting possible first "missing A" cycle. ("missing A" I counted as a part of "real" blitter cycle because it repeats)

EDIT: do you think 2 idle cycles at start are related to "preloading" A/B shifts or something?

Last edited by Toni Wilen; 03 September 2009 at 15:50.
Toni Wilen is online now  
Old 04 September 2009, 04:32   #33
FrenchShark
FPGAmiga rulez!
FrenchShark's Avatar
 
Join Date: Dec 2007
Location: South of France
Age: 45
Posts: 155
Quote:
Originally Posted by Toni Wilen View Post
I haven't thought about internal logic too much but this seems perfectly logical.



I am quite sure it is AD- (A--AD-...AD--D)
(I guess the fill logic happens in "second cycle" in blitter pipeline)
That's crazy: that means "minterm" cycle has to move to the idle cycle before A and the "fill logic" cycle is hapenning during A. This is the only way the data can be available to the D cycle after A.
The other explanation is that this is a real silicon bug and that minterm + fill logic are done in one cycle anyway.

Quote:
Yes. I meant 2 idle cycles that are always at start, not counting possible first "missing A" cycle. ("missing A" I counted as a part of "real" blitter cycle because it repeats)
Ok, so we are in phase here.

Quote:
EDIT: do you think 2 idle cycles at start are related to "preloading" A/B shifts or something?
That's funny, in my design, the ASH and BSH values are actually "expanded" to a 16-bit multiplying value since my 32-bit shifters are done with HW multipliers. It would be a waste of resources for an ASIC but it saves a bunch of cells on an FPGA.
I also use these 2 cycles to initialize the width and height counters and to load some flags like USEx (because line mode has to force them to 1011, no matter what the BLTCON0 value is).

Regards,

Frederic
FrenchShark is offline  
Old 04 September 2009, 09:07   #34
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,017
Quote:
Originally Posted by FrenchShark View Post
initialize the width and height counters and to load some flags like USEx (because line mode has to force them to 1011, no matter what the BLTCON0 value is).
I wouldn't do this because there are at least one demo that clears C-channel BLTCON0 bit, writes to BLTSIZE and expects nothing to be drawn

EDIT:

(I talked about this in some beta thread): blitter seems to change to (currently) unexplained cycle sequences (or even stop) if USEx flags or fill mode on/off change and blitter is already running. Testing all combinations could reveal blitter's internal cycle sequence system. Unfortunately this would be extremely boring.. (32 * 32 tests, 16 channel combinations + fill mode on/off)

Last edited by Toni Wilen; 04 September 2009 at 11:28.
Toni Wilen is online now  
Old 05 September 2009, 03:52   #35
FrenchShark
FPGAmiga rulez!
FrenchShark's Avatar
 
Join Date: Dec 2007
Location: South of France
Age: 45
Posts: 155
Quote:
Originally Posted by Toni Wilen View Post
I wouldn't do this because there are at least one demo that clears C-channel BLTCON0 bit, writes to BLTSIZE and expects nothing to be drawn

EDIT:

(I talked about this in some beta thread): blitter seems to change to (currently) unexplained cycle sequences (or even stop) if USEx flags or fill mode on/off change and blitter is already running. Testing all combinations could reveal blitter's internal cycle sequence system. Unfortunately this would be extremely boring.. (32 * 32 tests, 16 channel combinations + fill mode on/off)
Well, for one demo, I do not really care. I am even wondering if I will implement this extra fill mode cycle. The Minimig does not do it and it still nice to be faster than the original. Usually it does not hurt.

For example, the VHDL implementation of Capcom's 1943 that I have has a Z80 running at 24MHz (the original runs at 6MHz). Only the instructions fetches are slowed down to 6MHz. As a result, the animation is smooth all the time even with the maximum number of sprites (128 total).

Regards,

Frederic
FrenchShark is offline  
Old 05 September 2009, 05:41   #36
redmonlee
 
Posts: n/a
Thanks for your sharing. Thanks for sharing this useful information. It's great.




property internet management software project document asset This internet management software is perfect for your document and web company property internet management software project document asset
 
Old 08 September 2009, 00:24   #37
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Quote:
Originally Posted by FrenchShark View Post
Well, for one demo, I do not really care. I am even wondering if I will implement this extra fill mode cycle. The Minimig does not do it and it still nice to be faster than the original. Usually it does not hurt.

For example, the VHDL implementation of Capcom's 1943 that I have has a Z80 running at 24MHz (the original runs at 6MHz). Only the instructions fetches are slowed down to 6MHz. As a result, the animation is smooth all the time even with the maximum number of sprites (128 total).

Regards,

Frederic
I think sacrificing compatibility is a bad idea. You don't know it's just for one demo. There are plenty of platforms that "run Amiga faster than any Amiga". And even more games/demos/apps that are incompatible with all versions of the real thing. But that was usually future-incompatibility with machines that didn't exist yet. Now all original Amigas have been manufactured, so you can look back and choose the model you like.

So if you know the cause and it doesn't require complex patching, why not make it proper? After release missing features might be requested and then you might have to make patches instead of a simpler solution perhaps.

I'm a bit passionate about this subject so sorry I'd love to see any Amiga model 100% re-made in off-the-shelf components. Will yours use buffers for I/O, video, audio?
Photon is offline  
Old 08 September 2009, 00:38   #38
kamelito
Zone Friend
kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 924
Maximum compatibility is mandatory

Hi,

I agree with Photon, compatibility is key, take for instance the Clone-A project the is aim of individual computers is to be 100% compatible.
So posting things like that is like shooting in your foots
I'll wait for Clone-A then, I'm not in a hurry, the only problem is that Clone-A is just targeting the Amiga.

kml

Quote:
Originally Posted by Photon View Post
I think sacrificing compatibility is a bad idea. You don't know it's just for one demo. There are plenty of platforms that "run Amiga faster than any Amiga". And even more games/demos/apps that are incompatible with all versions of the real thing. But that was usually future-incompatibility with machines that didn't exist yet. Now all original Amigas have been manufactured, so you can look back and choose the model you like.

So if you know the cause and it doesn't require complex patching, why not make it proper? After release missing features might be requested and then you might have to make patches instead of a simpler solution perhaps.

I'm a bit passionate about this subject so sorry I'd love to see any Amiga model 100% re-made in off-the-shelf components. Will yours use buffers for I/O, video, audio?
kamelito is offline  
Old 08 September 2009, 01:26   #39
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Well, he hadn't decided yet, as I read it. While it's pretty darn hard to get every single cycle timing right, it's very important for the chipset, and especially for Amiga as we know... CPU speed and memory timings/wait-states will affect compatibility in ways that Amiga users are well aquainted with and for which solutions exist. Chipset - nope.

Maybe a solution could be to attempt an exact replica in cycle timings for the A4000 chipset & chipmem timing, and then have a non cycle exact option (or a factor so at least the whole chipset is in "sync")? And CPU and memory could run as fast as they can.

Remaining problems are then "superfastcopper" vs display and CPU vs display cycle timings (or non-DMA audio). The former for things like fullscreen sprite backgrounds and the latter for things like c2p modes, misc "extra-HAM modes" etc.
Photon is offline  
Old 09 September 2009, 16:50   #40
FrenchShark
FPGAmiga rulez!
FrenchShark's Avatar
 
Join Date: Dec 2007
Location: South of France
Age: 45
Posts: 155
Quote:
Originally Posted by Photon View Post
Well, he hadn't decided yet, as I read it. While it's pretty darn hard to get every single cycle timing right, it's very important for the chipset, and especially for Amiga as we know... CPU speed and memory timings/wait-states will affect compatibility in ways that Amiga users are well aquainted with and for which solutions exist. Chipset - nope.

Maybe a solution could be to attempt an exact replica in cycle timings for the A4000 chipset & chipmem timing, and then have a non cycle exact option (or a factor so at least the whole chipset is in "sync")? And CPU and memory could run as fast as they can.

Remaining problems are then "superfastcopper" vs display and CPU vs display cycle timings (or non-DMA audio). The former for things like fullscreen sprite backgrounds and the latter for things like c2p modes, misc "extra-HAM modes" etc.
I plan to be able to set the copper speed to 3.5, 7, 14 or 28 MHz.
Along with the MOVEM instruction, this will give you a way to get high-color chunky mode with the copper (despite the faster Chip RAM, in hi-res doublescan, you will still eat up all the cycles).

Regards,

Frederic
FrenchShark is offline  
 


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 20 August 2011 00:41
Stuff for sale amiga a1200 plus more retro stuff blast MarketPlace 23 22 June 2010 20:05
Action Replay Undocumented Features deicidal support.Hardware 0 01 March 2010 18:15
I've got some Amiga stuff...I want your SNES stuff! Fingerlickin_B MarketPlace 14 20 February 2009 02:33
Amiga stuff for trade for Atari Stuff 8bitguy1 MarketPlace 0 12 February 2009 06: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 15:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.11440 seconds with 14 queries