Undocumented Amiga hardware stuff

[robinsonb5]

Interesting - I've been curious about something else related to that recently:
Majic12: Ray of Hope 2 has a couple of splash screens which have DIWSTART set to 0 and a crazy high DIWSTOP too. If Denise horizontal counter starts at 2, a start of 0 never matches, and as a result on Minimig the splash screen doesn't show. It does show on real hardware and in WinUAE, though. Is the DIWSTART comparison a greater-than rather than an exact match? (Seems uncharacteristically expensive hardware-wise when the rest of the chipset is so tight and elegant)
Or is the display window getting enabled some other way and then remaining enabled due to both DIWSTART and STOP being outside the allowable range?

[Toni Wilen]

Originally Posted by robinsonb5

Interesting - I've been curious about something else related to that recently:
Majic12: Ray of Hope 2 has a couple of splash screens which have DIWSTART set to 0 and a crazy high DIWSTOP too. If Denise horizontal counter starts at 2, a start of 0 never matches, and as a result on Minimig the splash screen doesn't show. It does show on real hardware and in WinUAE, though. Is the DIWSTART comparison a greater-than rather than an exact match? (Seems uncharacteristically expensive hardware-wise when the rest of the chipset is so tight and elegant)
Or is the display window getting enabled some other way and then remaining enabled due to both DIWSTART and STOP being outside the allowable range?

Check posts #65-#67 in this thread. It is OCS Denise "bug". ECS Denise or AGA: blank screen.

[ross]

DIW is always an exact match.
The 0 match is due to an OCS bug where the STREQ strobe does not reset the Denise counter.
So for a few lines the counter is free-running and as it is 9 bit at some point it rolls to 0 and matches, by opening the screen.
The bug has been fixed in ECS and AGA and therefore the screen does not do any display there...

EDIT: an exact time match

[robinsonb5]

Originally Posted by Toni Wilen

Check posts #65-#67 in this thread. It is OCS Denise "bug". ECS Denise or AGA: blank screen.

Awesome, thank you.

Originally Posted by ross

DIW is always an exact match.

Thanks for confirming - I'd have been very surprised if that hadn't been the case.

The bug has been fixed in ECS and AGA and therefore the screen does not do any display there...

Interesting - with current WinUAE that particular demo does display the splash screen even with ECS or AGA chipset selected - is that expected, or is the demo accidentally managing to enable the DIW some other way?

[ross]

Originally Posted by robinsonb5

Interesting - with current WinUAE that particular demo does display the splash screen even with ECS or AGA chipset selected - is that expected, or is the demo accidentally managing to enable the DIW some other way?

A bit off-topic, cause is demo specific 'oddities'

Anyway, in AGA the demo manage to enable the DIW thanks to a KS3.x weird setup.
You can find something like this in system Copper list:

008E 0181 0090 0281 01E4 0000

Yes, x-STRT and x-STOP at the same value (using DIWHIGH bit).
The DIWSTRT 'wins' and there's never a stop, then the demo use the stupid values (rewiting the usual DIW registers and DIWHIGH is reset), so the DIW never close..
Don't ask me why those values are used by the system

About ECS, are you sure?
I have tried different configurations and the screen remains black.
Are you sure you are using a Full ECS machine and not a configuration with only an Agnus ECS?
The hardware patch is in Denise..

[robinsonb5]

Originally Posted by ross

A bit off-topic, cause is demo specific 'oddities'

Good point - if I need to revisit it or have other queries I'll use the "troublesome demos" thread (or a new one) instead.

so the DIW never close..
Don't ask me why those values are used by the system

Thanks, that's really helpful.

About ECS, are you sure?

Yes, but when testing I made the mistake of only changing the chipset, not the kickstart version, so was still using KS3 - so mystery solved. Thanks again.

[Toni Wilen]

VHPOSW write updates both Agnus and Denise horizontal counter! This is not documented anywhere, probably because it is most likely meant to be some kind of chip testing feature and you can't read Denise counter.

VHPOSW bits 0 to 7 are copied to Denise internal horizontal counter bits 1 to 8. Bit 0 is cleared. (Denise horizontal counter counts lores pixels = counts twice the speed of Agnus horizontal counter)
This is practically useless feature but explains weird side-effects like having horizontal blanking middle of scanline or repeating same sprites or matching normally inaccessible horizontal window stop position $1c8 or later.

No one probably noticed because you need perfect timing and know Agnus internal horizontal counter details perfectly or display won't sync and/or you have all kinds of glitches that hide the Denise horizontal counter "feature"

Probably only sort of practical use is to simulate some ECS Denise programmed mode features with OCS Denise.

This is "supported" by both OCS and ECS Denise. AGA not tested (but probably is also supported).

Ross can (probably) explain some other possible mostly same uses for this feature

[Toni Wilen]

Sort of "documented". HRM says Also, the last word in a disk-read DMA operation may not come in (that is, one less word may be read than you asked for).

Part 1: Observations from simple test program that uses disk DMA to transfer short pieces of data from disk and collect horizontal position of disk DMA end. (DSKBLK bit in INTREQR)

Observation 1: About half of interrupts trigger in hblank.
Observation 2: Other half trigger in visible region but only in ~left half of screen. There is never any disk DMA end interrupts in right half of screen!

Isn't that interesting and unexpected? (and yes, this is caused by bug in topic title)

[ross]

Originally Posted by Toni Wilen

Isn't that interesting and unexpected?

Not only interesting and unexpected, but also rather amusing to find a plausible explanation
You will never believe how much time we spent thinking about it and shooting random things (especially me ))

[a/b]

Visible region clarification please...
As determined by display size (08e/090) or dma size (092/094)? Did you use a standard 320/640pix wide screen, or a custom one with weird settings? Thinking about how it would behave on e.g. minimal 32px dma wide on the rightmost possible position and minimal display size that excludes fetched display data.

[paraj]

Thanks for the update, interesting as always

Below is the offending code. So if I understand it right, it can't work if DSKBLK is only signalled when disk DMA actually finished? (Too little time to properly start next read).
It needs to start next read in time to catch first 4489 (and of course it's broken for case when first read is started during first sync word, common error), which can be missed if DSKBLK is only asserted when read is actually finished?

ReadDiskSectors                 ;0508be
    MOVEA.L drs_TrackBuf(A3),A1 ;0508be: 226b0002
    MOVE.L  A1,dskpt(A6)        ;0508c2: 2d490020
    MOVE.W  #$4489,dsksync(A6)  ;0508c6: 3d7c4489007e
    MOVE.W  #$9500,adkcon(A6)   ;0508cc: 3d7c9500009e SETCLR+MFMPREC+WORDSYNC+FAST
    MOVE.W  #$4000,dsklen(A6)   ;0508d2: 3d7c40000024
    MOVEM.W D6-D7,-(A7)         ;0508d8: 48a70300
    MOVE.W  #$000a,D7           ;0508dc: 3e3c000a
    MOVE.W  #$821e,D6           ;0508e0: 3c3c821e
.SectorLoop                     ;0508e4
    MOVE.W  D6,dsklen(A6)       ;0508e4: 3d460024
    MOVE.W  D6,dsklen(A6)       ;0508e8: 3d460024
    BSR.B   WaitDiskBlock       ;0508ec: 6154
    DBF.W   D7,.SectorLoop      ;0508ee: 51cffff4
    MOVEM.W (A7)+,D6-D7         ;0508f2: 4c9f00c0
    MOVE.W  #$4000,dsklen(A6)   ;0508f6: 3d7c40000024
    RTS                         ;0508fc: 4e75
; ...
WaitDiskBlock                   ;050942
    BTST.B  #1,intreqr+1(A6)    ;050942: 082e0001001f bit 1 = DSKBLK
    BEQ.B   WaitDiskBlock       ;050948: 67f8
    MOVE.W  #$0002,intreq(A6)   ;05094a: 3d7c0002009c DSKBLK
    RTS                         ;050950: 4e75

; ...
MFMDecodeTrack                  ;050afa
    MOVEM.L D1-D6/A1-A2,-(A7)   ;050afa: 48e77e60
    MOVEA.L drs_TrackBuf(A3),A1 ;050afe: 226b0002
    MOVEQ.L #10,D1              ;050b02: 720a
    MOVE.L  #$55555555,D4       ;050b04: 283c55555555
.SectorLoop                     ;050b0a
    CMPI.W  #$4489,(A1)+        ;050b0a: 0c594489
    BNE.B   .SectorLoop         ;050b0e: 66fa

[ross]

Originally Posted by a/b

Visible region clarification please...

The visible region is where there is no hblank, even if actually used by COLOR00.
Therefore completely independent of the DDFSTR or DIW settings or the resolution, simply where the amiga (in standard, non-programmed modes) can display something..

Originally Posted by paraj

So if I understand it right, it can't work if DSKBLK is only signalled when disk DMA actually finished? (Too little time to properly start next read).

Yep, DSKBLK is signalled for sure when DMA is finished, and this was known, but not only there.

It needs to start next read in time to catch first 4489 (and of course it's broken for case when first read is started during first sync word, common error), which can be missed if DSKBLK is only asserted when read is actually finished?

This for sure.

[Toni Wilen]

Part 2: What happens.

Paula's internal DSKLEN counter decreases every time new 16 bit word gets loaded in Paula's internal storage buffers. Disk interrupt/DMA end is triggered when DSKLEN==0 and internal buffers are empty.

What actually happens:

Internal shift register becomes filled (16 bits), DSKLEN decreases. DSKLEN==0 and buffers are empty condition triggers before new data fills the buffer. DMA ends, DSKBLK interrupt is triggered and last word is lost.

Why interrupt only triggers in left half of screen? Because DMA to Agnus empties all buffers during hblank (DMA slots are between refresh and audio slots). Filling new buffer takes about 16*7 CCKs = about middle of scanline. If new buffer is filled in right half (and after this fill DSKLEN==0), it means there was at least one buffer already filled in "left half of screen" (after disk DMA slots), "buffers are empty" condition is false, bug does not trigger, buffers are transferred at the beginning of next scan line. Last word is not lost.

There is still some not fully known behavior if buffer fill happens between strobe (first refresh slot) and DMA transfer. This shouldn't affect anything else than some very special test programs

[mc6809e]

Originally Posted by Toni Wilen

VHPOSW write updates both Agnus and Denise horizontal counter! This is not documented anywhere, probably because it is most likely meant to be some kind of chip testing feature and you can't read Denise counter.

VHPOSW bits 0 to 7 are copied to Denise internal horizontal counter bits 1 to 8. Bit 0 is cleared. (Denise horizontal counter counts lores pixels = counts twice the speed of Agnus horizontal counter)
[Snip]

Ross can (probably) explain some other possible mostly same uses for this feature

So if a bunch of sprites are displayed on the left side of the screen, writing to VHPOSW can get denise to redisplay them again provided a low enough HPOS is written? And Agnus continues to fetch BP data (provided HPOS is within normal bounds)?

A few writes to VHPOSW would sure beat a bunch of copper moves to reposition sprites, like for creating a third background layer. Of course it would need to be corrected before the end of the line to get Denise and Agnus back to the correct values and on track for the next line, refresh, hsync, etc.

[ross]

Originally Posted by mc6809e

So if a bunch of sprites are displayed on the left side of the screen, writing to VHPOSW can get denise to redisplay them again provided a low enough HPOS is written? And Agnus continues to fetch BP data (provided HPOS is within normal bounds)?

A few writes to VHPOSW would sure beat a bunch of copper moves to reposition sprites, like for creating a third background layer. Of course it would need to be corrected before the end of the line to get Denise and Agnus back to the correct values and on track for the next line, refresh, hsync, etc.

It's not that easy.
The signal that inhibits the sprites fetching, activated by the bitplanes fetching , is still active in that case, and therefore the sprites DMA would not 're.start'.
It is true, however, that by using the right HPOS it is possible to start the DMA fetching anywhere during the line, more than one time, all over again.
There are several complicated cases, which also include the middle-line regeneration of the blank.

[chb]

Originally Posted by ross

It's not that easy.
The signal that inhibits the sprites fetching, activated by the bitplanes fetching , is still active in that case, and therefore the sprites DMA would not 're.start'.
It is true, however, that by using the right HPOS it is possible to start the DMA fetching anywhere during the line, more than one time, all over again.
There are several complicated cases, which also include the middle-line regeneration of the blank.

But if one does not want/need to restart sprite DMA, but just show the same sprites again on a different position?

[ross]

Originally Posted by chb

But if one does not want/need to restart sprite DMA, but just show the same sprites again on a different position?

This is relatively simple.
If the sprite is armed (i.e. a write on SPRxDATA has been previously performed), each match with the x value in SPRxCTL/SPRxPOS insert the data present in the DATx registers in the video shifter and Denise begins to display them.
But this is totally independent of whether the DMA is active or not (usually is DMA that writes in DATA), it can be done with the CPU or the Copper; the x-POS rewriting can be at any time, the important thing is that it's before the beam reaches that position.

EDIT: and now you know what the (in-)famous vertical sprite stripe that can be seen in some situations (i.e. a bad system take over) is: sprite DMA disabled in a 'random' position during screen draw, sprite that is not dis-armed by the DMA (because there is not a write on SPRxCTL, not even manual) and x-POS in a visible position of the video

[chb]

Originally Posted by ross

This is relatively simple.
If the sprite is armed (i.e. a write on SPRxDATA has been previously performed), each match with the x value in SPRxCTL/SPRxPOS insert the data present in the DATx registers in the video shifter and Denise begins to display them.
But this is totally independent of whether the DMA is active or not (usually is DMA that writes in DATA), it can be done with the CPU or the Copper; the x-POS rewriting can be at any time, the important thing is that it's before the beam reaches that position.

EDIT: and now you know what the (in-)famous vertical sprite stripe that can be seen in some situations (i.e. a bad system take over) is: sprite DMA disabled in a 'random' position during screen draw, sprite that is not dis-armed by the DMA (because there is not a write on SPRxCTL, not even manual) and x-POS in a visible position of the video

I know But wouldn't a single write (well, rather two to restore it again) to VHPOSW be more efficient than repositioning all 8 Sprites?

[ross]

Originally Posted by chb

I know But wouldn't a single write (well, rather two to restore it again) to VHPOSW be more efficient than repositioning all 8 Sprites?

Yeah, I understand what you mean.
Basically you write a value at a certain position where Denise's counter is 'rewound' to allow the match to repeat for all sprites at a certain point to the right in the video.
The problem is that you don't 'reposition' only the sprites, but you 'reposition' even the Agnus* counter, with all the resulting consequences: the Amiga system has lots of hardwired values in which 'something happens'.
The activation/display of the sprites is not 'untied' from the rest, everything is designed to be 'sequential', in which the events must not overlap or conflict and some sequences in the chain activate or deactivate the following ones depending on use.
So an 'unexpected' value in Agnus counter can have all kinds of side effects.
Of course you can also arrange the other DDF or DIW registers or whatever you want with copper, but in the end you will make the copper list heavier (and the very same waits in the copper list are influenced by the writing of V(H)POSW..) and in any case you can only do it in ECS because in OCS you would go crazy...

*The two counters are not value synchronous (the only way to synchronize them perfectly, with a 'standard system defined' delay, is during the STROBE signal near line start).
So you think you've fixed something on one side (Denise x-POS) but on the other (Agnus stuff) it doesn't work as you would like.
I assure you that getting something decent is very complicated (in some cases even impossible).
Ok ok, you can create some normally 'unfeasible' effects, but only as a demonstration

So my advice, if it is only for sprite multiplexing, is to use the canonical methods (but in fact some weird tests could also be done..).


EDIT:
Attention: I certainly don't want to say not to do tests or experiments with this register! (I've done some crazy ones that you can't imagine...), so any ideas to (ab)use it are welcome.
In the near future WinUAE will support it even better, so everyone can crash the Amiga without thinking twice
I just wanted to point out that there are no free meals, unfortunately some things cannot be done (or if it can be done it have very serious limitations).

[mc6809e]

Originally Posted by ross

Yeah, I understand what you mean.
Basically you write a value at a certain position where Denise's counter is 'rewound' to allow the match to repeat for all sprites at a certain point to the right in the video.
The problem is that you don't 'reposition' only the sprites, but you 'reposition' even the Agnus* counter, with all the resulting consequences: the Amiga system has lots of hardwired values in which 'something happens.
,[snip]

Well I wouldn't necessarily expect completely arbitrary positions to be workable. I was thinking in terms of a third repeating background.-- 15 color attached sprites side by side behind a PF. No doubt Agnus is using the lower bits of HPOS to determine which BP to fetch next. Changing HPOS arbitrarily would reposition sprites but Agnus might end up fetching from the wrong BP. If the sprites remain in the same relative location, though, things might work out okay.

Still there may be some visually fun opportunities available by turning off most or all bp fetching.

What for instance happens with one BP, all black, and HPOS is changed arbitrarily (to values when only BP dma is expected, of course)? Now build a large cluster of adjacent sprites and change HPOS arbitrarily. Assuming they have priority over the PF there should be no problem. Agnus might have crazy BP fetch patterns but it wouldn't matter. BP wouldn't show anything.

Of course you only get one look for each of these large sprites but it might be fun to see how many can be bounced around the screen at once by changing HPOS multiple times per scanline.