thecart-menu: fix compatibility with SECAM FGTIAs

[HiassofT]

FGTIAs latch trigger inputs at the beginning of HBLANK, add two STA WSYNCs before reading TRIG3 to ensure it reflects the actual RD5 status.

Note: ATR and XEX loader likely need a similar fix before leaving the critical section, this is not addressed by these changes yet.

see https://abbuc.de/forum/viewtopic.php?f=3&t=5130

[peterdell]

https://www.virtualdub.org/downloads/Altirra%20Hardware%20Reference%20Manual.pdf

"On a SECAM system with an FGTIA, the triggers are gated and only updated once each horizontal blank. This
causes delays in TRIG3 updating to match cartridge state changes and is a source of cartridge compatibility
problems. The TRIG3 cartridge sense can also be affected by the GTIA trigger latch function."

[HiassofT]

Testing feedback looks good so far https://abbuc.de/forum/viewtopic.php?p=41639#p41639

I've now uploaded the full software zip, including sources and cartmenu.rom in the usual place:
https://www.horus.com/~hias/thecart/software/thecart-software-260610.zip

The exact timing still isn't quite clear to me and I suspect there could be a window in the ATR and XEX loaders where a VBI firing shortly after the "cli" instruction might read a stale TRIG3 value. So I suspect it'd be best to add two "sta wsync" before the "cli"s (when cart enable was modified before) to be on the safe side.

[peterdell]

The forum is down, so I cannot check right now. I had a chat with Phaeron: "2 x STA WSYNC will suffice if the sampling point is at a static offset in the scanline. If it can move due to the vertical sync issue, that may not be sufficient because it may move later in the scanline -- which would require an interval longer than 114 cycles to guarantee a sample."

So 3 STA WSYNC might be required, depending on how /CSYNC (/CSYNC is a composite sync, not a horizontal sync.) is generated and on the internal timing of the FGTIA.

Pity, JoSch had an FGTIA machine, and I had my oscilloscope with me at the H.A.T.Z....

[HiassofT]

Verification with a real computer would certainly help.

I had a look through the ANTIC and FGTIA datasheets and currently there are some unknowns - and it would be good to verify if the stuff in the datasheets is actually correct :)

We have to distinguish between 4 cases: horizontal and vertical blank with positive video polarity and both with negative polarity (in the latter case CSYNC is inverted, i.e. active-high instead of active-low).

CSYNC is connected to the shift/load input of the 74LS165 which means the inputs are sampled at the cycle before it's rising edge and are then clocked into the FGTIA - this is also shown in the diagram on page 55.

ANTIC datasheet shows that the 16-clock HSYNC pulse occurs from color clocks 0..15, which means that for positive video and a hblank the trig3 value at color clock 15 is relevant.

Shifting-in starts at color clocks 16 and the trig3 value is clocked in at color clock 21.

This means color clock 22 is the earliest time at which the updated trig3 value might be available by reading the TRIG3 register - it's unclear though if there might be internal delays and when reading the TRIG3 register actually returns the updated value.

I haven't found any detailed specs concerning vblank, but the GTIA vsync waveform in the Altirra HW reference manual looks a bit like the CSYNC could be high for about 16 color clocks - and the falling edge is identical to the hsync case which means csync would be low in color clocks 0..(about) 211.

That would mean trig3 is sampled at color clock 211 and clocked in in color clock 217 - and color clock 218 would be the earliest possible time the value might be available in the TRIG3 register.

In case of negative video the sampling and clocking is likely the same for hblank and vblank:

CSYNC should be high in color clocks 0..15 which means sampling occurs at color clock 227 and trig3 is shifted in at color clock 5 (and thus available at color clock 6 earliest).

The correspondence between the 228 color clock cycle numbers and the 114 CPU cycle numbers seems to be a bit ambiguous in the various documents - due to various phase shifts it's also a bit tricky to describe (and I haven't dug further into this yet).

Assuming a simple 2:1 correlation between cycle numbers, i.e. CPU cycle 0 covers color clock cycles 0 and 1 this would give us the following numbers:

For positive video hblank trig3 is sampled in CPU cycle 7, clocked into FGTIA in cycle 10 and could be available at cycle 11 earliest

For positive video vblank trig3 is sampled in CPU cycle 105, clocked into FGTIA in cycle 108 and could be available at cycle 109.

For negative video trig3 is sampled in CPU cycle 113, clocked into FGTIA in cycle 2 and could be available at cycle 3.

It would be great if we could verify if this theory is about correct (plus/minus 1-2 cycle number counting differences, and hoping I didn't make any major mistakes).

When is the next time you could meet again and check? :-)

[HiassofT]

Forgot to add:

If the above theory is correct I gues we could be fine with 2 STA WSYNC:

The worst case delay is if trig3 changes in the cycle after sampling, folowed by STA WSYNC (which will hit WSYNC 4 cycles later).

And the worst case scenario seems to be positive video vblank where sampling occurs around wsync time.

But even if we account for a one or two cycle shift (eg sampling occurs at 103 or 104 instead of 105) we should be fine - the following wsync will happen after the wsync deadline and the second wsync brings us way past the clocking-in time.

The big assumption though is that TRIG3 status can be read quite soon after it was clocked in, in case of a huge delay it would be quite different.