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.
[Rep]

Keep the info coming, that's great!
[Rep]

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..)
[Rep]

thanks for the info Toni, that can help a lot sometimes

what is a "dangerous register"?
is the copper stopped for ever or until the next vblank?
[Rep]

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)
[Rep]

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)
[Rep]

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.
[Rep]

what the hell...

where did you get those infos...:-)
[Rep]

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)
[Rep]

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..
[Rep]

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)
[Rep]

Exactly. Seems only Cardamon/Cardamom's coder found and took advantage of this weird feature.

BLTDPT == BLTCPT after blit ends. (Demo Deformations won't work properly without this)
[Rep]

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)
[Rep]

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? :-):-)



[Rep]

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.
[Rep]

Indeed I never understood such point in HRM! Thanks for pointing out!
[Rep]

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)
[Rep]

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 :-)
[Rep]

@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.






[Rep]

@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. :-(
[Rep]

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".
[Rep]

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.
[Rep]

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.
[Rep]

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 :-)
[Rep]

great ! Toni, can this technic be used for games or it is specifically made for programs
like demos ?
[Rep]

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? :-)
[Rep]

Yes, it does use "7 planes" for "noise" effect. 2 programs so far, maybe there are more..

(download link is broken)
[Rep]

Thanks for checking! :-) And sorry that I didn't check the download link, I've fixed it now, thanks for that info too! :-)
[Rep]

"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..)
[Rep]

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.
[Rep]

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)

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
[Rep]

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)

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?
[Rep]

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.

Ok, so we are in phase here.

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
[Rep]

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)
[Rep]

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
[Rep]

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
[Rep]

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?
[Rep]

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


[Rep]

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.
[Rep]

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
[Rep]