This is probably doable without major problems.
Except that a 'profitable' use of this 16-color PF sprites-made-up of repeated stripes escapes me :)

Sure interesting as a test for a weird effect (like a very fast multi-view, modifiing only little memory data).
There are effects on the C64 that do something similar using real-time character map editing, repeated across various portions of the screen.

But we are going off topic in the thread (i.e. from simply documenting undocumented features to using it).
Not that I mind but I don't know if it's the right thing :nervous

Please open a thread about abusing vhpos. So interesting :)

demo SOS triangle (ECS Agnus/OCS Denise) has Strobe/Bitplane conflicts, which leads to the first "STRHOR" Strobe happening far down in the image. The upper part therefore remains black. Only the green text scroller is permanently visible.

Well, in fact this is not exactly something undocumented (the conflict between DMA channels has already been reported, even if there are some very peculiar ones and I don't remember if they have all been described). The thing that isn't properly documented is what Denise internally does when it receives the Strobes.

The intro had not yet been emulated correctly until now (in latest winuae.7z it is) because WinUAE is Agnus-centric and the Strobes for Denise are used basically for resetting the internal counter.
This because in fact in normal conditions the Strobes are always 'emitted' at the same Agnus' cycle and therefore Denise is a 'blind support' to Agnus.
So for the most can be 'neglected' in the emulation of display/blanking functions, because solved with Agnus related 'methods'.

Until recently we didn't know if they were actually used even in real (except to reset the counter)... for example understanding what STRLONG did only happened a few days ago.
Of course, what Strobes do for Paula has always been known :)

A little addition: even with ECS Denise the intro doesn't work, it also still uses Strobes completely except in specific conditions.
In a future post I will explain what really Strobes do (with a bit of history of Amiga chipsets and the reasons for some of the designers' choices).

That's what I meant.

Before this demo I did exactly the same thing with STRHOR and STRVBL, which was "only" resetting Denise's H-Counter. STREQU is ignored.
Now there seems to be another effect here. Presumably, after the last STRVBL, a (at least one ?) STRHOR has to be registered by Denise in order for bitplanes to get into the shifter.
A few tests are necessary.

Yes. STRVBL enables Denise vertical blanking (Digital RGB outputs are forced to zero when Denise HB or VB is active) which stays active until Denise sees non-STRVBL strobe.

(ECS Denise programmed modes uses different method. Strobe based blanking is not used in programmed modes.)

The reason is that Strobes set latches inside Denise that:

STREQU: at STROBE+[dHBSTRT] enable blank, do not enable /BURST at STROBE+[dBURST]
STRVBL: at STROBE+[dHBSTRT] enable blank, enable /BURST at STROBE+[dBURST]
STRHOR: at STROBE+[dHBSTRT] enable blank, at STROBE+[dHBSTOP] disable blank
STRLONG: delay [dHBSTRT] and [dHBSTOP] by a clock

So the only way to disable BLANK is with STRHOR.
All dXXXX are fixed hardwired comparisons values, in a rom-matrix similar to that inside Agnus.
It is very likely that the HB and VB states are separate latches and that their outputs are ORd to the final internal BLANK signal.
All STROBE are 'immediate' (i.e. same line) because the latch is set in any case before (Agnus)HBSTRT.

And now the (I hope) short story.

The designers needed in the original ICS/OCS chipset a simple system to fully generate a broadcast video signals (NTSC and/or PAL), without the need for complicated video encoders.
The main signals to be generated were therefore the vertical and horizontal synchronisms, the pre/post equalization and serration signals, the color burst signals and the BLANK.
The most logical thing was to have Agnus generate the pulses and Denise generate the video/blank/bust signals.
Since Denise only works by lines, a command mechanism had to be provided by Agnus for Denise, and these are precisely the strobe signals.

So:
- during STREQU lines: equ/serrations/vsync pulses (Agnus); no burst, VBLANK (Denise).
- during STRVBL lines: hsync pulses (Agnus); color burst (/BURST pin), 'extra-video' stuff (usually void), VBLANK (Denise).
- during STRHOR lines: hsync pulses (Agnus); normal video, HBLANK (Denise)
- long lines (NTSC): STRLONG on second refresh slot [this is a little special, maybe I'll explain it separately] (Denise)

--continue---

Thanks for the explanation. I had been wondering all along why Denise had to differentiate between STRHOR and STRVBL/EQU.

The story continues, it's time for the ECS chipset.

The features that the new Denise must support concern the super hires resolution and the programmed modes..
But both Agnus and Denise must be interchangeable, that is, capable of functioning in every possible combination of the two chips.
How to reconcile this need for compatibility with new features?

The designers decided to use the two unused pins present in Denise: CDAT and BLANK which are connected respectively to _CDAC (quadrature clock to generate pixels at 35ns but which we are not interested in now) and _CSYNC.
This because none of the programmed mode registers existing in the new ECS Agnus are available in ECS Denise! (that's right, BEAMCON0 and the other related do not exist in ECS Denise).

With the programmed modes the synchronism signals can be anywhere on the line and the hardwired BLANK cannot be good anymore.
Fortunately it helps you a bit (which is not even mentioned in the HRM..) that allows you to switch from [use STROBE] mode to [external signal] mode for the BLANK:
EXTBLKEN in BPLCON3 (need ECSENA=1 in BPLCON0).

When EXTBLKEN=1 then Denise's BLANK signal is generated following the _CSYNC signal.
This is not a fully perfect way to generate a BLANK (but works), and can be also helped by BRDNBLNK=1 (or by COLOR00=0 in the right positions).
Furthermore, usually the programmed modes are much less fussy about the blank and only need valid coverage for VSYNC and HSYNC.

The designers also added another bit, which is actually more confusing than anything else (and has actually been made 'obsolete' in AGA): BLANKEN.
BLANKEN=1 basically use blank registers in Agnus to generate the CSYNC and drive BLANK in Denise.
Main idea is to generate a perfect BLANK from Agnus to Denise but this has a lot of side effects..
This generates a kind of CSYNC which may or may not work... it was probably designed exclusively if separate H&V synchronization signals are used.


Warning: don't take what I wrote at face value, there are still some things in Denise that are not clear and possible speculations (since there are no schematics availables).
For example the free-running counter bug in OCS Denise is somehow incompatible with the STREQU in first blank line.. we should investigate.

Last message and then I'll shut up :)

> For example the free-running counter bug in OCS Denise is somehow incompatible with the STREQU in first blank line.. we should investigate.

This probably has a simple solution and it's not a bug but a 'design choice' (for a remaining initial defect? for the rush? for leftovers from debugging of the chip? who know..)
In the Amiga 1000 Denise they find this 'solution' and were then forced to report the 'choice/bug' in the OCS version (they fixed the 'problem' properly only from the ECS version).

The designers knew that the first line of the blank was certainly a STREQU and decided for a starting BLANK position of the vsync different from normal HBLANK (more secure?).
What is a way to do this?: do not reset the counter and assign the match with the start in a position >$1C7(+2)[<$1FF].
Obviously this absolutely cannot work with the programmed modes and they were forced to reset the counter and hook in the low positions.
If I'm not mistaken the VBLANK on A1000 starts in a 'different position' than ECS..

I'm quite satisfied with this speculation, also because I don't have any better ones ;) If anyone has a better one, please post it.
[there would also be a possible theory about a counter that decreases from a predefined value when STREQU arrives, but considering that everything is done for the greatest economy I really think that this is not the case]

Finally :D ;)

Joke aside, reading technical stuff from knowledgeable people (even if I am sometimes lost :p ) is always a must. Keep posting mate :great

interesting information about ECS Denise. I want to deal with that soon.

From Denise's (OCS) point of view, blanking means "only" the disabling of the RGB output, so that the front/back porch region around HSync (Beam Retrace controlled by Agnus) does not get any data ?

By the way, I have set the hardwired blanking to Denise Hpos 14 to 84.

Yes, the same of course also applies for vblank, usually lines from 0 to 20 NTSC or 25 PAL, which covers vsync pulses and a cushion zone used on TV for extra-data.

A little too optimistic here :).
With DIW fully open visible lores pixels are 376, so the first pixel is at 92 ($5c).

Ok, all the pieces are in place now, Toni and I have finished torturing a couple of Denises but we have understood how the STROBE management works internally.
Nothing sensational compared to what I have already described previously, just how it is technically implemented (so I don't edit the previous messages, it's not worth the effort and they are broadly correct).
As usual, the designers have adopted the policy of the cheapest and with less gates way, even at the cost of having some small side effects.

An example is the method used to solve the problem I mentioned in message https://eab.abime.net/showpost.php?p...&postcount=331
To avoid a 'match value' they simply used the cycle immediately following $1C7(+2).. i.e... the STROBE itself :)
This has a couple of side effects that explain the 'different' vblank (as I correctly remembered) that can be noticed on the A1000 (and which was 'cloned' into OCS).
I don't know in which way this is related to lack of counter reset, but it's not important and it doesn't change anything on a practical level (except a rare bug regarding the DIW, well known by those who patch OCS stuff to work on ECS..); probably they saved two transistors and that was enough of a justification ;).

Very quick summary diagram:
STREQU = enable master_blank (immediate)
STRVBL = reset counter, /BURST, latch enabled for dHB matches
STRHOR = reset counter, /BURST, latch enabled for dHB matches, clear master_blank (immediate)
STRLONG = LOL delay (reset at STROBE)

Operative description:
- STREQU is immediate BLANK for OCS Denise (this explain the last line blank that start early), enable master_blank
- line0 does not emit STRHOR in OCS Denise (this generate the 'ugly' extreme bottom line, shorter than normal and containing only COLOR00 like the $137SHF/$138LOF PAL
- STRHOR enable and disable blank at match positions, enable timed burst, and also immediately disable master_blank
- STRVBL is a 'reduced' version of STRHOR (it probably shares most of the gates but with one difference: it doesn't touch master_blank)
- master_blank always wins and need to be disabled if you want to re-enable view (only STRHOR can do it)
- STRLONG should be really set in a specific 'range' to be really usefull else it is 'reset' by strobes (the 'range' is after a STROBE and before dHBs)

The side effect of this setting is that at the last line of the BLANK there is a small window open for DIW (because STRHOR immediately deactivates the master_blank and then reactivates it for dHBs matches).
Of course this 'little window' can also contain normal video data :)

The funny thing is that STRVBL, which could be understood as the most significant signal for vertical BLANK actually does nothing for vertical blank!
Fortunately on normal NTSC/PAL screens the sequence is always STREQU->STRVBL->STRHOR and everything works fine anyway :D

If anyone is wondering: yes, in ECS Denise they fixed STRVBL and now it actually does something sensible.
But that's another story...

:great

At this point I'm trying to pass the maximum non-blanking area, what leaves the Amiga (what I think is transfered through the cable). Cropping, such as typical monitor viewing area or non border, is then done in a 2nd step outside of the actual emulation.

valuable information. I'm going to integrate that the days, especially line0

already mentioned ?

paula: not serviced intreq2 doesn't clear when perfin (state 3) and !AUDxON and AUDxIP, state changes to 0.
then toggle AUDxON (e.g. a few lines later ), still armed intreq2 does AUDxIR now

attached test triggers three additional level 4 interrrupts.

Ross' values are correct hardwired blanking start/end points. At least if Denise output is captured from video DAC hybrid chip analog outputs. Any device that captures it earlier: undefined results.

Do you mean INTREQ2 is only cleared when it causes interrupt? (INTREQ changes)

Yes. If delayed INTREQ2 is not cleared (possible retrigger) when toggling AUDxON test results would differ to real machine.

Other undocumented information on strobes.

What has not been discussed previously is how Paula handles VERTB in INTENA/INTREQ (to manage BLIT it uses the INT3 PIN and COPER via 'software').
We known that Paula also uses STROBEs, but how? Now we know :)

Internally it maintains a flag which is set to 0 by the STRHOR strobe and is set to 1 by both the STRVBL and STREQU strobes.
When there is flag transition from 0->1 then VERTB is triggered.

This results in different behavior in each chipset combination, which can be summarized in the following table:

A1000 Agnus:
Line 0: STRHOR
Line 1: STREQU -> Paula VERTB, OCS Denise BLANK enable

OCS Agnus:
Line 0: STRVBL -> Paula VERTB, ECS Denise BLANK enable
Line 1: STREQU -> OCS Denise BLANK enable

ECS Agnus:
Line 0: STREQU -> Paula VERTB, OCS Denise BLANK enable, ECS Denise BLANK enable
Line 1: STREQU

OCS Denise BLANK enable -> immediately at strobe position
ECS Denise BLANK enable -> next internal or programmed HBSTRT position after strobe was detected

Note the OCS line 0 which is strangely STRVBL :)

All the various changes appear to have been made between later versions of the chipset to accommodate VERTB and VBLANK (finally in ECS they fixed everything).

:great