Undocumented Amiga hardware stuff

[pandy71]

Originally Posted by JPQ

In earlier this thread someone mentioned 7bit ocs mode how colours are defined in this mode? what i know there is only 32 colour registers.

http://eab.abime.net/showthread.php?t=41091

[PiCiJi]

Originally Posted by Toni Wilen

(Partially copied from http://eab.abime.net/showthread.php?t=71437)

How BPLCON1 really works:

When Agnus writes to Denise's BPL1DAT, all BPLxDAT registers are copied to internal Denise temp registers and flag is set. (separate flag for both odd and even planes)

When bitplane delay value (odd and even are separate) matches Denise's internal hpos counter ((hpos & mask) == delay value) and flag is set, internal temp register is copied to 16-bit output shift register and flag is reset.

Hpos comparison checks are continuous, internal copy happens immediately when comparison matches and if flag is set.

This explains all weird flickering/blanking side-effects if BPLCON1 values are modified "incorrectly" (comparison does not match before shift register empties too much) mid-scanline.

very interesting, I have thought the delay is processed only at the beginning of first scanline fetch and following playfield data is added to some ring buffer.
I assume in single playfield mode the delay for even planes is ignored

[Toni Wilen]

Originally Posted by PiCiJi

very interesting, I have thought the delay is processed only at the beginning of first scanline fetch and following playfield data is added to some ring buffer.

I thought so too but it didn't explain all side-effects. And I guess doing it this way was much simpler in hardware. (First or last word won't need any special handling)

I assume in single playfield mode the delay for even planes is ignored

No. Single or dual playfield won't have any effect on shifting behavior. Only difference (dual vs single) is palette entry selection method for shifted out pixel. (Same for HAM or EHB, BPLxDAT and shifting don't need to care)

[Toni Wilen]

Originally Posted by Toni Wilen

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)

This effect also affects dual playfield (OCS/ECS only) mode. If PF2P > 5 and second playfield has at least 1 enabled bitplane (there is no planes == 5 restriction), any non-zero color palette number in second playfield gets drawn using background color (color 0) only. Playfield #1 vs #2 (and sprites) priority selection still works normally.

This effect is used in intro Running Man by Scoopex. (Logo fade effect)

PF1P > 5 does not cause any side-effects.

[Mrs Beanbag]

on AGA is it possible to manually load data into 32- or 64-pixel wide sprites without using DMA?

[Photon]

First reaction is: of course it is, just mimic the DMA automatic behavior i.e. poke the right registers. You'd slow the CPU down since you'd be using the slow bus anyway, so I don't see the gain.

The question isn't really on topic but wth, it's friday! Or something.

[Mrs Beanbag]

sorry but i don't see how it is off topic... it is about programming Amiga hardware and i don't see it documented anywhere.

What registers would you poke to push 32 or 64 bit data into the sprites? SPRxDAT registers are only 16 bits wide. Usually you use the copper to put data in them on each scanline when the DMA for sprite 7 is deactivated by an early DDFSTART (for horizontal hardware scrolling). If i poke the same register sequentially, does it rotate the data in like a shift register or what?

[Toni Wilen]

I did quick test: Copper SPRxDAT writes when FMODE was set to 32 pixel and 64 pixel wide sprites.

At least with 16 pixel sprites it was quite useful. With wider sprites it seems to be totally unusable.

32 pixel wide (bit 3 in FMODE set = 2x16): high 16 pixels get filled with random garbage (I assume previous data in bus/buffers), low 16 pixels get filled with data copper wrote. If bit 2 in FMODE set (1x32): words are swapped, high 16 pixels gets data that copper wrote, low 16 pixels are random.

64 pixel wide (bit 2 and 3 in FMODE set): similar problem, different word order, upper 32 pixels get filled with random garbage, next 16 pixels are data copper wrote, last 16 pixels are again garbage.

Writing multiple times to SPRxDATA or SPRxDATB didn't make any difference.

I am quite sure CPU writes have same results and all custom registers are still 16-bit wide from CPU point of view.

[TheDarkCoder]

For the records: many many years ago, I did similar tests. My idea was, like Photon said, try to mimic what DMA does. I was unable to find a way to obtain the right output.

[Photon]

Normally this thread is for presenting test results that are not in the documentation but yes, I agree questions can lead to test results as shown by Toni

I had one of my own actually But in the end I ran some tests since curiosity was burning (about some follow-up questions as well).

So from tests on an A500:

1. VERTB triggers directly after last line ($138 or $139 in ILACE), and whatever copper address is in COPLC is read and triggered automatically at the same time. If you write to COPJMP as the very first instruction of your interrupt, all is well, but if you precede it with a write to COPLC, all hell breaks loose (rolling copper and no exit, no guru on reset).

Strangely I also found that if the first two instructions are a write to COPJMP followed by a write to COLOR00, the background color is not changed!

In both of these cases moving the instruction pairs down a few lines (cycles) made them work as expected.

I did these test in order to find out which of a move.w #$f0f,$dff180 and dc.w $180,$369 is executed first. At least from the tests it seems copper+vertb trigger at the same time, and that you have to postpone custom reg. writes, so that the copper starts executing before (custom reg writes in) the vertical blank executes. In other words, you can't hope to execute some code in VERTB before the copper starts.

This was with a faster CPU, so it might be that a 68000 is slow enough for this "competition" not to appear.

2.The raster position reported at VERTB start is line $00.09 (and so this should be the position when copper is started). This is not the top of the screen, but after the last line, outside the bottom of the screen. On my 1084S CRT, copper instructions are executed (at bottom) until the beam turns off after pos $00cb. You can then make any changes to bg-color you want from $00cd forward, nothing (not even bg color) will be drawn until the raster hits $1b07.

Rasterwaits in this no-show limbo work fine, VHPOS is updated continuously from $00cd to $1adf. The beam is turned completely off (poweroff, no colors possible) until $1b07.

[mc6809e]

According to the Agnus specifications document on the EAB file server, VBlank actually begins at the beginning of the last line (not that documentation can always be trusted).

So I was wondering, Photon, can you elaborate on your test? Did you use a STOP instruction to minimize interrupt latency?

Even with STOP interrupt latency is around 44 cycles. If other instructions are running, it might even be much longer (movem.l of all registers followed by a DIV is over 300 cycles of latency). This might affect the VPOS number that's read by the CPU.

You also write

At least from the tests it seems copper+vertb trigger at the same time, and that you have to postpone custom reg. writes, so that the copper starts executing before (custom reg writes in) the vertical blank executes.

It doesn't seem possible for the CPU to ever beat the copper in a race to access COP1LC if VERTB happens exactly when the copper gets loaded with its new address. The CPU should be running behind the copper having been delayed from the start by interrupt response cycles, unless it takes a lot of time for COP1LC to be moved into the copper list DMA pointer.

Maybe this is what you're saying but I've misunderstood.

[Toni Wilen]

Originally Posted by mc6809e

According to the Agnus specifications document on the EAB file server, VBlank actually begins at the beginning of the last line (not that documentation can always be trusted).

Document shows Agnus output sync signals, vblank signal is not same as vblank strobe (that Paula sees and generates vblank interrupt). Vblank starts at the beginning of line 0. (or 1 if A1000 Agnus). Very easy to see in logic analyzer (and tested many times long time ago)

I don't see anything undocumented in this case
DMA/CPU timing shouldn't have any undocumented features left. (Not including >=68020 CPU internal timing)

[Photon]

Originally Posted by Toni Wilen

Document shows Agnus output sync signals, vblank signal is not same as vblank strobe (that Paula sees and generates vblank interrupt). Vblank starts at the beginning of line 0. (or 1 if A1000 Agnus). Very easy to see in logic analyzer (and tested many times long time ago)

I don't see anything undocumented in this case
DMA/CPU timing shouldn't have any undocumented features left. (Not including >=68020 CPU internal timing)

Yes, the $0009 VHPOS reported in first instruction of VBI is probably bogus, as I wrote.

It's quite useful to know which fires first and the time differences in usecs or HPOS counts).

So "not same" doesn't give any useful information on that Both pieces of information could be in documentation, of course. I just haven't seen it.

From a programming point of view, they certainly seem to be competing over custom register writes at the same time. I don't compare with VHPOS though, but with first copper instructions executed, which may or may not be the same.

It would also be useful with a time measurement from last HPOS of line $138 in a non-interlaced display, to line 0. (Edit: well, it should be $cf HPOS-cycles, doh...)

Originally Posted by mc6809e

According to the Agnus specifications document on the EAB file server, VBlank actually begins at the beginning of the last line (not that documentation can always be trusted).

So I was wondering, Photon, can you elaborate on your test? Did you use a STOP instruction to minimize interrupt latency?

Even with STOP interrupt latency is around 44 cycles. If other instructions are running, it might even be much longer (movem.l of all registers followed by a DIV is over 300 cycles of latency). This might affect the VPOS number that's read by the CPU.

You also write

It doesn't seem possible for the CPU to ever beat the copper in a race to access COP1LC if VERTB happens exactly when the copper gets loaded with its new address. The CPU should be running behind the copper having been delayed from the start by interrupt response cycles, unless it takes a lot of time for COP1LC to be moved into the copper list DMA pointer.

Maybe this is what you're saying but I've misunderstood.

No, that was what I was saying.

No STOP instruction, so the usual overhead (something like 70 cycles on 68000).

The instructions were put at the very start address of the interrupt. Only when I wasted some cycles on movem, btst, skipped branch did custom register writes "take". CPU can't "win the race", which means any custom register writes (such as to COPLC) can't take effect until after the auto-loaded copper has started executing. You can re-start a copper set in the VBI "half a scanline too late" by writing to COPJMP, and this seems to work fine on A500+CRT. On faster CPUs, you may be able to "win the race", and this could be useful info for programmers testing code written on faster CPUs on stock A500 and seeing strange things happen. If they just "tried some things" they might not notice the 1 frame delay that comes from setting only COPLC in the VBI on 68000.

Edit: doublequote overflow, sorry.

[mc6809e]

Originally Posted by Toni Wilen

Document shows Agnus output sync signals, vblank signal is not same as vblank strobe (that Paula sees and generates vblank interrupt). Vblank starts at the beginning of line 0. (or 1 if A1000 Agnus). Very easy to see in logic analyzer (and tested many times long time ago)

Let me see if I'm clear on this now. A strobe during the first refresh cycle (STREQU?) tells Paula that VBlank has begun and so Paula sets bit 5 in intreq and triggers the interrupt if enabled.

Since Agnus moves COP1LC into the copper's current DMA pointer at the beginning of VBlank but this can't happen during a refresh cycle, the copper's DMA pointer must be updated after the first refresh cycle.

And since the copper and refresh cycles are interleaved, the first copper instruction access to chip ram happens between the following refresh cycles, blocking the CPU from chip ram and chip registers.

Taken all together, then, technically the interrupt happens first, but the CPU is blocked from doing anything with chip ram or chip registers because copper and refresh are active.

[Toni Wilen]

Originally Posted by mc6809e

Taken all together, then, technically the interrupt happens first, but the CPU is blocked from doing anything with chip ram or chip registers because copper and refresh are active.

Yes. I just re-checked. Copper can always execute its first instruction before CPU can get any chip RAM access slots.

[Mrs Beanbag]

Originally Posted by Toni Wilen

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

i was just thinking about 64 pixel wide sprites again, is it possible, for instance, to do hardware scrolling without an early DDFSTRT (thus without losing a sprite) by pushing the first word of bitplane data in with the copper instead? is bitplane data register cleared at end of line, or is it possible to push data in before the next line starts?

i have done a little test as well. you CAN load custom 64-bit wide data into a deactivated sprite, if you set DDFSTRT to 0x80 on any line, whatever data it reads in ton that line will repeat on every line thereafter that the sprite DMA is not active. this is not entirely unexpected. it could be useful, perhaps, in somewhat limited ways.

Originally Posted by Toni Wilen

32 pixel wide (bit 3 in FMODE set = 2x16): high 16 pixels get filled with random garbage (I assume previous data in bus/buffers), low 16 pixels get filled with data copper wrote. If bit 2 in FMODE set (1x32): words are swapped, high 16 pixels gets data that copper wrote, low 16 pixels are random.

I am actually not reproducing this... with 32 bit wide sprite (FMODE=$0004) when i continuously write to SPR7DATA with CPU loop it seems to get the data in both words of the output.

[Toni Wilen]

Originally Posted by Toni Wilen

If DDFSTRT is large enough when sprite position information is fetched (POS&CTRL) but DDFSTRT becomes smaller when sprite is displayed, second "plane" of sprite stops getting updated (no DMA fetches) and last fetched data is reused in all following lines.

Perfect example: http://eab.abime.net/showpost.php?p=...&postcount=686

ECS Agnus: no sprite bugs
OCS Agnus: strange sprite bug
A1000 Agnus: slightly different looking strange sprite bug

(WinUAE 3.0.0 or newer required)

Originally Posted by Toni Wilen

A1000 DIP Agnus (also in first A2000 revision) has undocumented "bug", display field's first or last (depending on your viewpoint) strobe isn't vblank probe which causes vblank interrupt to trigger one line later than in any other Amiga model. (yaqube found this one)

More A1000 Agnus differences:

Last line of field works normally if A1000 Agnus. If later revision: last line inhibits both sprite and bitplane DMA. (This explains above demo's different OCS vs A1000 Agnus behavior)

If DIWSTRT vertical display start line is zero, display window won't open (shows only background color) if A1000 Agnus. Works if later revision.

Originally Posted by Mrs Beanbag

I am actually not reproducing this... with 32 bit wide sprite (FMODE=$0004) when i continuously write to SPR7DATA with CPU loop it seems to get the data in both words of the output.

It really looks like CPU writes are different than Copper writes. Unfortunately CPU writes are very difficult to time 100% identically each time, which makes test mostly useless (to guess how it really works internally) without connected logic analyzer. (too many pins needed, SMD chips suck)

[Toni Wilen]

I am not sure if I already have "documented" following but here it goes:

Sprite vertical stop comparison is always active, even if sprite's vertical start has not yet matched.

If sprite's vertical stop is smaller than vertical start, when stop equals vertical position (while it is still waiting for vstart), sprite still "stops" normally and following two words gets loaded to SPRxPOS and SPRxCTL.

Example case:

Alien Breed 3D sprites 4 to 7 have two bugs without causing any visible glitches. (sprites 4 to 7 are loaded with same data and are not used, probably was designed to contain zero control words but they don't..)

vstart is outside of display but vstop is 52. When vstop == vpos, sprite "stops" and next control words get loaded. Second set has vstart of 252 but horizontal pos=0. Sprite starts normally at line 252 but is invisible because hpos = 0. If hpos was 1 or larger, it would have appeared in right border.

Sprite hpos from 1 to 4 (Counting SPRxPOS horizontal bits only, SPRxCTL horizontal bits does not make any difference) are visible in right border.

[ReadOnlyCat]

Originally Posted by Toni Wilen

I am not sure if I already have "documented" following but here it goes:

Sprite vertical stop comparison is always active, even if sprite's vertical start has not yet matched.

If sprite's vertical stop is smaller than vertical start, when stop equals vertical position (while it is still waiting for vstart), sprite still "stops" normally and following two words gets loaded to SPRxPOS and SPRxCTL.

Oh, interesting.

What does happen in terms of data fetches if the sprite's last vertical position stop is set to the top of the visible screen? The vertical comparator should never match until the next frame so do the fetches continue until that point or do they stop with the display window (at least in OCS/ECS) or at some arbitrary point?

If the fetches stop predictably at some hardware stop point at the bottom of the screen, then the "always active vstop comparator" behaviour opens the possibility when multiplexing sprites vertically to prepare several frames of sprite data in advance by setting the bottom sprites vertical stop positions to the top of the screen instead of at the bottom.

I am not sure this would be useful because it is usually more flexible to use the copper to change the sprite data pointers but it is still nice to know that this might be possible.

[Toni Wilen]

Sprite DMA is disabled from line 0 to line 24 (PAL) or 19 (NTSC). Line 25 (PAL) or 20 (NTSC) forces first sprite control word fetches.