Hippy Dave wrote:The Pacemaker demo has a bug. -12 DB does not exist (YM2149 should be silent). The Pacemaker demo has sound because it incorrectly uses the Microwire register (and gets ignored on a real STE). Thus Steem must only have YM sound when input 1 is selected, and must emulate Microwire accurately enough to ignore the Pacemaker demo. Nicolas fixed this in Hatari (June 2014).

Yet both the demo and Steem seem to be conform to doc:

The MICROWIRE™ bus is a three wire serial connection and protocol designed to allow multiple devices to be individually addressed by the controller. The length of the serial data stream depends on the destination device. In general, the stream consists of N bits of address, followed by zero or more don't care hits, followed by M bits of data. The hardware interface provided consists of two 16 bit read/write registers: one data register which contains the actual bit stream to be shifted out, and one mask register which indicates which bits are valid. Let's consider a mythical device which requires two address bits and one data bit. For this device the total bit stream is three bits (minimum). Any three bits of the register pair may be used. However, since the most significant bit is shifted first, the command will be received by the device soonest if the three most significant bits are used. Let's assume: 01 is the device's address, D is the data to be written, and X's are don't cares. Then all of the following register combinations will provide the same information to the device. 1110 0000 0000 0000 Mask01DX XXXX XXXX XXXX Data

0000 0000 0000 0111 MaskXXXX XXXX XXXX X01D Data

0000 0001 1100 0000 MaskXXXX XXX0 1DXX XXXX Data

0000 1100 0001 0000 MaskXXXX 01XX XXXD XXXX Data

1100 0000 0000 0001 Mask01XX XXXX XXXX XXXD Data

As you can see, the address bits must be contiguous, and so must the data bits, but they don't have to be contiguous with each other.

In fact they do, if I got it right. So official doc would be doubly wrong? For the -12DB and for the mask structure?

I have Steem v3.6.3 on 2 machines on Linux Mint 17. One is a desktop machine on which 3.6.3 works fine, and the other setup is on Dell notebook and here I can not make it play any sounds, its absolutely silent Any clues/hints what's wrong?

Hippy Dave wrote:The Pacemaker demo has a bug. -12 DB does not exist (YM2149 should be silent). The Pacemaker demo has sound because it incorrectly uses the Microwire register (and gets ignored on a real STE). Thus Steem must only have YM sound when input 1 is selected, and must emulate Microwire accurately enough to ignore the Pacemaker demo. Nicolas fixed this in Hatari (June 2014).

Yet both the demo and Steem seem to be conform to doc:

... So official doc would be doubly wrong? For the -12DB and for the mask structure?

Hippy Dave wrote:The Pacemaker demo has a bug. -12 DB does not exist (YM2149 should be silent). The Pacemaker demo has sound because it incorrectly uses the Microwire register (and gets ignored on a real STE). Thus Steem must only have YM sound when input 1 is selected, and must emulate Microwire accurately enough to ignore the Pacemaker demo. Nicolas fixed this in Hatari (June 2014).

Yet both the demo and Steem seem to be conform to doc:

... So official doc would be doubly wrong? For the -12DB and for the mask structure?

Yes, official doc has some errors, this is what I wrote back in the Hatari maling list :

But I think we should blame Atari for this error ; the STE addendum doc at http://dev-docs.atariforge.org/files/ST ... 5-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)

Anyway, the Atari's doc doesn't give enough detail on the LMC data/mask inner work. For accurate source, you should look at the official LMC1992 datasheet.From what I saw in Steem, the implementation is indeed flawned, because it doesn't take into account that the mask can be made of non consecutive '1'.

On page 9 of that datasheet, a note right after "chip select address" says:"Note 2: Additional don't care states may be inserted here for ease of programming. (Optional.)"So that doc would be wrong too, and be at the source of the confusion.It seems the ultra-cheap chip doesn't exactly behave as documented by the manufacturer.Atari would be to blame for the choice of the chip, not the doc mistake.

On page 9 of that datasheet, a note right after "chip select address" says:"Note 2: Additional don't care states may be inserted here for ease of programming. (Optional.)"So that doc would be wrong too, and be at the source of the confusion.It seems the ultra-cheap chip doesn't exactly behave as documented by the manufacturer.Atari would be to blame for the choice of the chip, not the doc mistake.

No, the doc is correct, you can have "don't care" states, just ignore them and keep on concatening bits. In the end you will get your complete command once you receive at least 11 valid bits, starting with bits 10.In Hatari, I implemented the decoding based on the datasheet, and not surprinsingly, you get the correct result in the end for Pacemaker

I probably misread the Hatari source then, because I interpreted that a command is not valid if there are "don't care" (mask bit is 0) between "address" and "data". When I do the same in Steem, the write in Pacemaker is ignored and sound is normal.

Steven Seagal wrote:I probably misread the Hatari source then, because I interpreted that a command is not valid if there are "don't care" (mask bit is 0) between "address" and "data". When I do the same in Steem, the write in Pacemaker is ignored and sound is normal.

I think you misread, Hatari ignore those extra bits between the address and the 9 bits of data. I tested it with a lot of variations and fragmentations in the mask and it produced the expected result as described in the datasheet.

I might have missed some config to test but i did the most obvious ones at least, like turning off HD and changing TOS and ST/STE.

Can't find the thread but we already discussed that.There's a timing issue with pasti.dll.I have 2 STX versions of Albedo, that don't load all the time (it's random), and 1 CTR version that loads all the time. No Steem bug.

I might have missed some config to test but i did the most obvious ones at least, like turning off HD and changing TOS and ST/STE.

Can't find the thread but we already discussed that.There's a timing issue with pasti.dll.I have 2 STX versions of Albedo, that don't load all the time (it's random), and 1 CTR version that loads all the time. No Steem bug.

There is the version made by brume of Albedo, and the version i made from his dump, with the very latest AUFIT program.

His version doesn't work, while the one i did works perfectly with Steem 3.7.0 beta (not the actual 3.6.4).

Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !

I might have missed some config to test but i did the most obvious ones at least, like turning off HD and changing TOS and ST/STE.

Can't find the thread but we already discussed that.There's a timing issue with pasti.dll.I have 2 STX versions of Albedo, that don't load all the time (it's random), and 1 CTR version that loads all the time. No Steem bug.

There is the version made by brume of Albedo, and the version i made from his dump, with the very latest AUFIT program.

His version doesn't work, while the one i did works perfectly with Steem 3.7.0 beta (not the actual 3.6.4).

Steven Seagal wrote:Can't find the thread but we already discussed that.There's a timing issue with pasti.dll.I have 2 STX versions of Albedo, that don't load all the time (it's random), and 1 CTR version that loads all the time. No Steem bug.

You mean Antago has the same copy protection as Albedo? Anyway i solved it... it turned out i had not disabled the second diskdrive in Steem so i did that and now Antago loads fine in Steem

Stefan jL wrote:You mean Antago has the same copy protection as Albedo? Anyway i solved it... it turned out i had not disabled the second diskdrive in Steem so i did that and now Antago loads fine in Steem