Re: LMC1992/Microwire test WAS: [hatari-devel] No sound in the Pacemaker Demo

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 05/06/2014 14:50, Nicolas Pomarède a écrit :

> As for the serial protocol, as David noted in another post, the
> datasheet for LMC1992 tells that :
>
> "When the ENABLE line is low, data can be serially shifted from the
> controller to the LMC1992. As the ENABLE line goes through the low-to
> high transition, any additional data is ignored. Data present in the
> internal shift register is latched and the instruction is executed"
>
> This means the mask should contain 11 consecutive "1" bits, but they can
> be at any position.
>
>
> But I think we should blame Atari for this error ; the STE addendum doc
> at http://dev-docs.atariforge.org/files/STE_Dev_Add_5-25-1989.pdf gives
> several examples which are wrong (only the first 3 are correct, the 2
> others are wrong because they include "0" bits in the mask before the 3
> data bits are received)

I changed microwire's decoding, based on the official LMC1992 datasheet.

When scanning mask register, decoding will start with the first "1" bit 
and ends when a "0" bit is received.
Corresponding bits of the data register are stored in a command variable.
If the command doesn't start with the address "10", it should be rejected..
We should then have at least 9 bits that represent the real command to 
execute. If more bits were received, then only the 9 latest ones should 
be kept to represent the command (LMC1992 allow to receive some "don't 
care" bits before the 9 last bits).

With this mask/data 0xc1ff/0x8000 are correctly rejected in Pacemaker 
demo by Paradox, and the YM sound can be heard (we keep mixer=1 set by TOS)

Unless tests by cyprian show different results, I think this should be 
the correct behaviour and should be bug proof in case some program use 
0xffff as a mask for example.

Nicolas