Undocumented Amiga hardware stuff

[Toni Wilen]

Pixel clock is hardwired, it can't be changed. At least without changing main crystal.

Length of scanline can be changed if ECS/AGA (including sync pulse position/length and blanking start/end) but pixel clock is always 35ns, 70ns or 140ns.

[mc6809e]

Originally Posted by Toni Wilen

Pixel clock is hardwired, it can't be changed. At least without changing main crystal.

Length of scanline can be changed if ECS/AGA (including sync pulse position/length and blanking start/end) but pixel clock is always 35ns, 70ns or 140ns.

What about using an external clock source from a genlock for example? Built-in crystal is overridden, yes?

[MiaM]

External clock was my thinking too. That would also act as a relatively effective hardware dongle for anyone trying to copy the software.

The hardware would also need to contain a genlock and to be somewhat "safe" also hardware that would only output the Amiga picture on the main video output during the time teletext is supposed to be transmitted. That way you would "only" lose teletext and not screw up the whole signal if the correct software isn't running on the Amiga. Since the Amiga anyway needs to sync up to the external video signal and only needs to output teletext data during a short period of each frame/field, that hypothetical inferface could also output signal to a regular Amiga style monitor during the rest of the frame/field, so it would be possible for the software to indicate what's going on. I.E. for example some kind of bit map / progress bar showing which teletext pages are transmitted at the moment. It could also be used to enter real time subtitling (which at least was a thing back in the days - usually never perfect 1:1 speech - text but good enough to be a great aid for anyone hearing imparied during live transmissions).

[chb]

I've never seen a hard number what difference from the standard clock is possible via /XCLK, just mentions that it should be small and not exceed 1-2% (which would not suffice for teletext). Did anyone ever test that?
(Which brings us back to the "undocumented amiga hardware stuff")

[MiaM]

Not exceeding 1-2% would likely be a requirement for normal operation of everything. Mostly the serial port and the floppy controller will operate incorrectly if the clock deviates more. But I very much doubt that anything will actually fail at about 3% slower speed. At least for the slower speeds it should be easy to program the serial port to get the correct speed. If there would be a problem with the floppy drive and the floppy would be needed during normal operations this hypothetical product could worse case had been sold with an external floppy that runs 3% slower.

Side track anecdode-ish: I actually remember looking in to this back in the days, but I only had a very old version of the hardware reference manual and a short summary of how teletext works (intended for those who reapaired TVs)..

[hooverphonique]

I seem to remember somebody overclocking an A500 using XCLK by something like 10% without having problems (taking the exceptions mentioned by Mia into account, of course).

[pandy71]

Genlocks usually not feeding new crystal clock to the Amiga - Genlock use H and V lines (ERSY mode) to tell Amiga to synchronize H and V sync with external pulses so Amiga can track external video synchronization on line by line, field by field base.

In past i've replaced main oscillator so new clock can be feed to system and it will affect everything. For sure some crystals (or rather to be precise external crystal generator) with more than standard works - in case of my Amiga it was something over 30MHz for sure (don't recall if this was generator with 30.5 or 31.25MHz) - but even if TV didn't lost sync, floppy was unreadable (seem Paula DPLL was unable to sync).
Ideally will be to use some modern alternative such as https://learn.adafruit.com/adafruit-...akout/overview - with help of external MCU controlled by Amiga some dynamic overclocking should be possible.

[mc6809e]

Originally Posted by pandy71

Genlocks usually not feeding new crystal clock to the Amiga - Genlock use H and V lines (ERSY mode) to tell Amiga to synchronize H and V sync with external pulses so Amiga can track external video synchronization on line by line, field by field base.

Look up schematics for Commodore's A2301 PAL genlock -- it provides an external clock.

And for good reason. Synchronizing pixel output so that pixel boundaries have a constant relation to the color burst signal reduces artefacts.

[pandy71]

Originally Posted by mc6809e

Look up schematics for Commodore's A2301 PAL genlock -- it provides an external clock.

And for good reason. Synchronizing pixel output so that pixel boundaries have a constant relation to the color burst signal reduces artefacts.

Once again - ERSY solve problem from genlock perspective - whether it is implemented with XCLK or not this is different topic - some genlocks not use XCLK and some use it. From typical analog NTSC/PAL encoder chroma bandwidth produced from Amiga signal is way to high and need to be lowpass filtered and usually cheap LP filters introduce group-delay significantly higher than period even for few CLK periods (ideally LPF group delay shall be within half of luma period - doable without problem in digital encoders).

Primary synchronization point (also for chroma burst) is OH (time datum (OH))

it could be important if genlock will be entirely digital so synchronous sampling will be beneficial from feeding known external clock (also feeding external clock is beneficial for every flicker fixer/scandoubler)

[MiaM]

Btw, with both an external clock to generate the correct data rate for teletext, and external sync, could this maybe even work on OCS machines? That would likely require the sync signals towards the Amiga to be time shifted a bit to make the Amiga acutally output a "picture" at the correct time.

Or will OCS go havoc if it would see what effectively would act as if each line are a bit too short, i.e. each external horizontal sync pulse incoming earlier than expected?

[pandy71]

Originally Posted by MiaM

Btw, with both an external clock to generate the correct data rate for teletext, and external sync, could this maybe even work on OCS machines? That would likely require the sync signals towards the Amiga to be time shifted a bit to make the Amiga acutally output a "picture" at the correct time.

Or will OCS go havoc if it would see what effectively would act as if each line are a bit too short, i.e. each external horizontal sync pulse incoming earlier than expected?

If i understand correctly your question then seem TTX (i assume WST standard) data are in area (lines) that can't be normally used to display video - IIRC Amiga start displaying video in PAL 2 lines later than allowed by standard - IIRC line 25) where in theory second half of the line 23 is normal first visible video on TV (usually first half of the line 23 is also visible and carry WSS signal).

[MiaM]

That part, i.e. which part of the screen can video output be enabled on, could be overcome by just providing the external sync signals to the Amiga slightly time shifted as compared to the timing of the actual video signal to insert teletext data to.

The more interesting question is what happens when there are too few cycles each scan line.

Does all per-scan-line DMA channels run after each external horizontal sync input pulse, or do some run after the playfield DMA are finished?

[pandy71]

Originally Posted by MiaM

That part, i.e. which part of the screen can video output be enabled on, could be overcome by just providing the external sync signals to the Amiga slightly time shifted as compared to the timing of the actual video signal to insert teletext data to.

The more interesting question is what happens when there are too few cycles each scan line.

Does all per-scan-line DMA channels run after each external horizontal sync input pulse, or do some run after the playfield DMA are finished?

Once again - WST TTX occupy VBI (Video Blank Interval) lines normally not visible on screen ( quoting ETS 300 706 "Lines 6 to 22 and 318 to 335 may be used to carry Teletext data packets.") and those lines are also not available for graphic data in Amiga (not sure if ECS/AGA allow to be reprogrammed so graphic data can be placed there - if this is possible then you can output WST TTX data without problems just convert/resample samples from TTX domain to Amiga domain).

ETSI ETS 300 706 standard allow to use non-VBI lines for Teletext - you may try to follow this and try to prepare some signal - clock for tleetext is 444*15626Hz - using this rule you may think about generating picture and rescale it to Amiga timing (just as any picture - use 4 bit grayscale so higher phase accuracy can be achieved)

[Toni Wilen]

Originally Posted by pandy71

not sure if ECS/AGA allow to be reprogrammed so graphic data can be placed there

Yes. Both vertical and horizontal blank (and sync) can be freely moved if ECS Denise+ECS Agnus (with some limits due to way Denise HBLANK works, see above) or AGA.

(and this topic probably should be moved from this thread, this was, at least was supposed to be, about documenting undocumented features, not researching them)

[pandy71]

Originally Posted by Toni Wilen

Yes. Both vertical and horizontal blank (and sync) can be freely moved if ECS Denise+ECS Agnus (with some limits due to way Denise HBLANK works, see above) or AGA.

So if video HW can be programmed to start displaying data 12us from line beginning then Amiga should be capable to produce valid WST teletext data.

Originally Posted by Toni Wilen

(and this topic probably should be moved from this thread, this was, at least was supposed to be, about documenting undocumented features, not researching them)

yes, i agree, i intended to propose this - so admin please to exclude teletext discussion to the new thread (MiaM shall be thread owner).

[Toni Wilen]

This was quite unexpected. (as usual, thanks to ross for test program )

If BPL1DAT write disables border and active sprite was hidden behind the border:

- OCS Denise: sprite is visible 1 lores pixel (2 hires) earlier than bitplane first pixel.
- ECS Denise: sprite is visible 2 lores pixels (4 hires) earlier than bitplane first pixel.
- AGA: sprite is visible 1.5 lores pixels (3 hires) earlier than bitplane first pixel.

[Toni Wilen]

Fortunately this won't happen unless you do something wrong (accidentally or not).

If bitplane DMA ends before all sprite slots and last bitplane slot also has active sprite slot, sprite DMA is not inhibited by bitplane DMA but sprite DMA conflicts with bitplane DMA:
- Target DMA custom register becomes AND of last bitplane BPLxDAT register and conflicting sprite register, for example 0x110 (BPL1DAT) & 0x168 (SPR5POS) = 0x100 (BPLCON0).
- Source DMA address becomes bitplane pointer OR sprite pointer.
- DMA reads word (or larger if FMODE>0) from OR'd DMA address and writes it to new target custom register. (if larger then 16 bit fetch, highest 16 bits gets written)
- Bitplane +2/+4/+8 and possible modulo is added to OR'd DMA address.
- DMA address gets written back to both bitplane and sprite pointers.

Results:
- Something got mysteriouly written to wrong register (usually from 0x0100 to 0x0110, including 0x0110)
- All following same channel bitplane/sprite fetches read from wrong address.
- Worst case situation is write to 0x0100 with ERSY bit set. Result is hung system and no sync output (display blanks or shows no signal message).

If someone wants to write very obfuscated code, this can be used (with careful setup) to "emulate" copper by using sprite and bitplane DMA to update all BPLCON0-3 registers

This is fully repeatable, no random side-effects noticed. All chipsets.

[ross]

Originally Posted by Toni Wilen

Fortunately this won't happen unless you do something wrong (accidentally or not).

Gentlemen of the court, I swear my intentions were good

[DanScott]

Is this like "crossing the streams" ??

[ross]

Originally Posted by DanScott

Is this like "crossing the streams" ??

Basically yes, but googling the phrase in quotes results in some 'strange' results..