Undocumented Amiga hardware stuff

[Toni Wilen]

New undocumented feature:

If both HAM and DPF bits are set (OCS/ECS): HAM logic gets strangely mixed with dual playfield.

- if HAM selection bits are zero: color selection uses dual playfield color selection logic.
- if HAM selection bits are non-zero: selected R/G/B component value is palette _index_ number of current pixel. In other words HAM planes 0 to 3 raw value is not used like normally but they are processed using dpf logic which returns palette index.


I am not sure why no one else has found (or reported) this. I also missed it when I tested weird combinations long, long time ago. Originally found by vAmiga author.

[chb]

Originally Posted by Toni Wilen

New undocumented feature:

If both HAM and DPF bits are set (OCS/ECS): HAM logic gets strangely mixed with dual playfield.

- if HAM selection bits are zero: color selection uses dual playfield color selection logic.
- if HAM selection bits are non-zero: selected R/G/B component value is palette _index_ number of current pixel. In other words HAM planes 0 to 3 raw value is not used like normally but they are processed using dpf logic which returns palette index.

That's interesting! Just to make sure I understand that correctly:

a) Direct colors will be picked from a 3+4 (08 is transparent) color palette like on a 2+2 plane DPF? Also using only palette colors 0-3 and 9-11 like DPF?

b) If "foreground" planes are non-zero, "background" planes are ignored? So "11" (fg) + "00" (bg) gives the same value as "11" (fg) + "11" (bg)? And the modified R/G/B component can also only be in the range 1-7 0-3 and 9-11?

And I guess changing playfield priorities will also work exactly like in DPF mode?

EDIT: corrected color ranges

[Toni Wilen]

Originally Posted by chb

That's interesting! Just to make sure I understand that correctly:

a) Direct colors will be picked from a 3+4 (08 is transparent) color palette like on a 2+2 plane DPF? Also using only palette colors 0-3 and 9-11 like DPF?

b) If "foreground" planes are non-zero, "background" planes are ignored? So "11" (fg) + "00" (bg) gives the same value as "11" (fg) + "11" (bg)? And the modified R/G/B component can also only be in the range 1-7 0-3 and 9-11?

And I guess changing playfield priorities will also work exactly like in DPF mode?

Yes.

HAM selection bits (planes 5 and 6) are not affected by DPF.

Everything else uses DPF logic. Note that planes 5 and 6 are not filtered when selecting R/G/B replacement palette index, they are included in DPF color selection, just like in normal 6 plane DPF mode.

[Jobbo]

In line mode the HRM asks you to fill in BLTAPT (high and low) with dy4-dx2 as a long word.

However, I've seen demos that don't set BLTAPTH and in my own code I can set it to anything and things still work fine.

So, it seems safe to assume the blitter ignores the high word.

Might be common knowledge, but I didn't see it in this thread and it was news to me.

[robinsonb5]

Originally Posted by Toni Wilen

Even "simple" CIA chips can have secrets.

On the subject of CIA secrets, can anyone confirm this oddity?

The HRM's description of the CIA TOD counters reads as though the read latch is engaged by reading the high byte and remains high until the low byte is read - but having seen an access pattern today that trips up Minimig but which I believe works on real hardware, I believe that that the read latch is also cleared by writing to the low byte.
Can anyone confirm?

I also noticed that the Minimig CIA implementation doesn't engage the read latch at all if the ALARM bit is set. Is this correct?

[Toni Wilen]

I remember testing these long time ago, current UAE behavior:

Read TOD LO: latch cleared. Return latched LO if latch was enabled.
Read TOD MID: nothing interesting happens. Return latched MID if latch was enabled.
Read TOD HI: current TOD value gets latched but only if not already latched.

Write TOD LO: enable TOD. Read latch not affected.
Write TOD MID: nothing interesting happens.
Write TOD HI: disable TOD. Read latch not affected.

ALARM shouldn't affect reads, only writes.

[robinsonb5]

Originally Posted by Toni Wilen

I remember testing these long time ago, current UAE behavior:

Read TOD LO: latch cleared. Return latched LO if latch was enabled.
Read TOD MID: nothing interesting happens. Return latched MID if latch was enabled.
Read TOD HI: current TOD value gets latched but only if not already latched.

Write TOD LO: enable TOD. Read latch not affected.
Write TOD MID: nothing interesting happens.
Write TOD HI: disable TOD. Read latch not affected.

ALARM shouldn't affect reads, only writes.

OK thanks - this matches the HRM's description.


The oddity I was seeing had two causes: firstly in my test program the assembler had replaced a move with a clr, which of course on 68000 causes a read before the write. This was unlatching the read counter on write.


I was investigating this while looking for a discrepancy between Minimig and real hardware. I think the crucial piece of information I was missing is that after a reset the TOD counter doesn't count at all until it (or CRB) is written to for the first time. Since Kickstart has always done this by the time user code gets a chance to run, this isn't usually noticeable - but from looking at the source, WinUAE appears to behave this way so I guess it's a known characteristic.

[Toni Wilen]

TODs are cleared at reset. I used "Double Dragon II" RESET Action Replay protection hack to confirm it. This hack allows to execute RESET from chip RAM and continue code execution normally when using 68000.

Test program executed RESET, then it copied CIA registers to RAM.
Waited few scanlines, copied CIA registers again
Waited 1000 scanlines, copied CIA registers again.

Result was always:

00000000 FF000000 FFFFFFFF 0003FFFC (CIA-A in reversed order)
00000000 FF000000 FFFFFFFF 0000FFFF (CIA-B in reversed order)

1000 scanline wait had 76 keycode in CIASDR and SP flag set in interrupt register. All other register contents were identical.

CIA-A 03/FC is due to need to switch off overlay after reset. Normally it would have been 00/FF too.

CIA register copy was done in reversed order to prevent latch related side-effects. I also did it in non-reserved and results were same.

I didn't test ALARM, perhaps later but I assume it is cleared too.

btw, I forgot that ALARM does affect reads, if ALARM is set, TOD LO read does not enable latch.

[Retro1234]

Originally Posted by Toni Wilen

New undocumented feature:

If both HAM and DPF bits are set (OCS/ECS): HAM logic gets strangely mixed with dual playfield.

- if HAM selection bits are zero: color selection uses dual playfield color selection logic.
- if HAM selection bits are non-zero: selected R/G/B component value is palette _index_ number of current pixel. In other words HAM planes 0 to 3 raw value is not used like normally but they are processed using dpf logic which returns palette index.


I am not sure why no one else has found (or reported) this. I also missed it when I tested weird combinations long, long time ago. Originally found by vAmiga author.

sorry bit over my head, how many colours can you have on each playfield?

[robinsonb5]

Originally Posted by Toni Wilen

TODs are cleared at reset. I used "Double Dragon II" RESET Action Replay protection hack to confirm it. This hack allows to execute RESET from chip RAM and continue code execution normally when using 68000.

Neat trick! Thanks for sharing the results - very useful and much appreciated.

[lmimmfn]

Originally Posted by robinsonb5

Neat trick! Thanks for sharing the results - very useful and much appreciated.

Curious , do you see any use for this?

[robinsonb5]

Originally Posted by lmimmfn

Curious , do you see any use for this?

Only in making the Minimig FPGA core better match real hardware, and thus avoid an obscure combination of circumstances which was resulting in its system clock running too fast.
The chances of this particular discrepancy causing a problem were incredibly tiny - but as the late, treat Terry Pratchett taught us, million to one chances crop up nine times out of ten.

[lmimmfn]

Originally Posted by robinsonb5

Only in making the Minimig FPGA core better match real hardware, and thus avoid an obscure combination of circumstances which was resulting in its system clock running too fast.
The chances of this particular discrepancy causing a problem were incredibly tiny - but as the late, treat Terry Pratchett taught us, million to one chances crop up nine times out of ten.

Lol, makes sense, im still curious if this is useful in any way, like dual plane with 1 plane using HAM and the other using only colour registers, it would be interesting if thats possible.

[Toni Wilen]

Flexible Zoom / Upfront enables B channel in linedraw mode to load new line pattern words. (normal documented method only allows 16-bit static pattern)

Unfortunately it isn't as useful as it looks. When B channel is enabled, line draw cycle sequence becomes (was known long time ago but I didn't know it actually was useful, sort of):

-BC-BD-BC-BD (normal is -C-D-C-D).

B is loaded twice/pixel which wastes lots of DMA time. Linedraw disables normal +-2 adders, B is loaded twice from same address, then modulo is added, repeat.

Weird undocumented feature anyway

[Toni Wilen]

Details here:

http://eab.abime.net/showpost.php?p=...6&postcount=35

Basically it is blitter bug, it finishes too early and if CPU steals final D write cycle, in worst case there is no free blitter cycles for final D write until after new blit has already been started.

[Toni Wilen]

Very tiny and quite useless undocumented feature: ECS/AGA VPOSW LOL bit (NTSC Long Line) can't be set to 1. LOL bit is always cleared when VPOSW is accessed.

[Toni Wilen]

ECS Denise SPRxCTL SH1 (sprite horizontal hires positioning bit) only works as documented in superhires. It works strangely if lores or hires.

If SH1=1 and bitplane resolution is lores or hires: first pixel column of sprite becomes transparent (disappears). The rest of sprite works normally, sprite position is not changed.

Perhaps it was originally supposed to work in lores/hires too but bug happened and it was too expensive to create another chip revision?

[Toni Wilen]

ECS Agnus implements DIWHIGH V11 start (bit 3) and stop bit (bit 11). They are not documented in HRM ECS chapter. (V10 is documented as highest vertical bit)

AGA reuses them as superhires resolution horizontal bits. (H0)

[Toni Wilen]

ECS Denise weird way of programmed horizontal blanking. This is not chipset unexpected side-effect, it was designed to work this way (Why?).
Previous description in winuae changelog was not complete. Now checked and confirmed with a scope (finally use for my new few months old 4 ch scope..).

OCS Denise + OCS or ECS Agnus:

Only hardwired PAL/NTSC blanking.

ECS Agnus + ECS Denise :

HBSTRT/HBSTOP in Agnus. Denise does not have any blanking registers, Agnus CSYNC output is connected to Denise, this line is used to transfer blanking state to Denise.

Denise EXTBLKEN: enable external blank = CSYNC input is used for blanking. When CSYNC line is active (low), Denise output is blanked. EXTBLKEN=0: hardwired PAL/NTSC blanking in use.

BEAMCON0 undocumented BLANKEN=1: Agnus CSYNC output does not anymore have normal composite sync signal but blanking state.

VARCSYEN=0: HBSTRT-HBSTOP is used to generate CSYNC output blanking state.

EXTBLKEN=1, BLANKEN=1, VARCSYEN=0 is normal programmed blanking configuration.

"Wrong" configurations:

CSYTRUE=1: blanking state gets inverted. (blanked region becomes normal and normal region becomes blanked)

VARCSYEN=1: programmed HSSTRT-HSSTOP becomes blanking range.

BLANKEN=0: Normal composite sync signal becomes (useless) blanking signal.

When BLANKEN=1: CSYNC does not anymore contain composite sync (HSYNC + VSYNC) but only blanking state. CSYNC cable/display can't be used with programmed blanking, only H/V sync works (for example VGA monitor)

AGA:

Lisa added HBSTRT/HBSTOP registers + not anymore based on CCKs but shres pixels. Alice still has Agnus BLANKEN logic and HBSTRT/HBSTOP registers but CSYNC connection does not exist anymore. Lisa blanking enable is still called EXTBLKEN even when blanking modes (hardwired and programmed) are now fully Lisa internal.

Blanking works normally, both in H/V sync and CSYNC modes. No weird CSYNC configuration needed anymore. No need to set extra BEAMCON0 bits.

[MiaM]

Wow. Had this been known/understood by people in general back in the days I bet someone would had made an expansion providing a slightly slower pixel/system clock (iirc 6.9x *4 rather than 7.14*4) which combined with the external sync mode could had made it possible to generate teletext data using an Amiga.

Given that a teletext generator was so expensive that not even all relatively big commercial TV channels had one this could had been a huge thing.