Quiz of the day: Order writing to DMA base address regs

[ijor]

According to Atari, the DMA base (address) registers, at $ff8609-$0d, have to be written from low to high.

Why they have to be written in that order? What happens if you write them in a different order?

[mfro]

If memory doesn't fool me, I think I remember some docs saying writing low order bits would clear high order bits?

[ijor]

If memory doesn't fool me, I think I remember some docs saying writing low order bits would clear high order bits?

close but not cigar

[Steven Seagal]

I don't have the answer, but when I tested it in Steem (clearing high bytes at writes to lower bytes), the sound was obviously wrong, so Steem doesn't check that at all.

[ijor]

I don't have the answer, but when I tested it in Steem (clearing high bytes at writes to lower bytes), the sound was obviously wrong, so Steem doesn't check that at all.

Sound? Please note I am talking about ST DMA, floppy and ACSI, not STE sound DMA.

[Steven Seagal]

Sound? Please note I am talking about ST DMA, floppy and ACSI, not STE sound DMA.

No wonder it didn't work!

[ijor]

Short answer. Writing to a lower byte might increase (not clear) the upper one. This will happen when bit 7 (uppermost bit) of the written byte is changed from one to zero.

The reason is how exactly the counters are implemented on MMU. They use a ripple carry. This saves quite some logic at the cost of not being fully synchronous. The upper bit of the lowermost byte, inverted, clocks directly the middle byte of the counter. Any change from high to low on that bit, anytime, would clock the counter on the middle byte. Similarly, the inverted uppermost bit of the middle byte clocks the high byte of the counter.

Actually, the ripple carry is not only across bytes, but across nibbles as well. But between nibbles doesn't have that collateral effect because both nibbles are written at the same time, and the written value overrides the ripple carry.

In case you are wondering, the video counter uses the same ripple mechanism. But there is no such effect because they are read only on the ST.

[npomarede]

Hi, thanks for this information,very interesting. I don't think many programs rely on this, but I will add this behaviour to Hatari.
On STE, do you think the same rule applies when writing to video counter ?

[ijor]

Hi Nicholas,

On STE, do you think the same rule applies when writing to video counter ?

Seems not. Seems all the STE counters moved to a fully synchronous implementation without a ripple carry. So even for the DMA counters the behavior seems to apply to ST only.

[Steven Seagal]

Here's the source of confusion:

STE documentation by The Paranoid:

? I set all the registers, but there is no sound at all.

! The DMA-Soundsystem expects you to write the high-byte of the Start- and
Endaddress first. Even though this serves no purpose at all, writing the
highbyte clears the others. Hence it must be written first.



Engineering Hardware Specification Atari Corp:

841017B The DMA Base Address and Counter Register must be
loaded in low, mid, high order.


The loading order for disk DMA wasn't enforced either in Steem.


Can we say this restriction is due to Atari using cheap components?

[ijor]

STE documentation by The Paranoid:
! The DMA-Soundsystem expects you to write the high-byte of the Start- and
Endaddress first. Even though this serves no purpose at all, writing the
highbyte clears the others. Hence it must be written first.

That might be true. I don't know. I'm not familiar with the STE sound system really to be sure.

Engineering Hardware Specification Atari Corp: 841017B
The DMA Base Address and Counter Register must be loaded in low, mid, high order.
Can we say this restriction is due to Atari using cheap components?

I don't think it is fair to qualify this as cheap components. It isn't really about the quality of any component at all. It's about how they modeled (designed, coded if you want) the logic inside the custom chip.

It would be analog as if Atari would have made some tricks in the code to save some bytes from TOS. You might qualify something like that as cheap coding, in the worst case. But certainly not as using cheap EPROMs.

If they wouldn't have used that mechanism in MMU, it might have increased the die size, which might translate to a more expensive chip. But in that case, more expensive doesn't mean better quality, just bigger.

[npomarede]

Hi, thanks for this information,very interesting. I don't think many programs rely on this, but I will add this behaviour to Hatari

Hi
just to let you know, the ripple carry adder behaviour for STF DMA addresses was added to Hatari devel version.

When activating traces for this, I can see that many games/demos FDC routines are triggering it from time to time on one of the 2 lower bytes.
But as they correctly write in low/mid/high order, this is harmless in the end

Nicolas