Steem SSE 3.6 bug reports

A place to discuss current and future developments for STeem

Moderators: Mug UK, Steem Authors, Moderator Team

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Steem SSE 3.6 bug reports

Post by Steven Seagal »

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 Mask
01DX XXXX XXXX XXXX Data

0000 0000 0000 0111 Mask
XXXX XXXX XXXX X01D Data

0000 0001 1100 0000 Mask
XXXX XXX0 1DXX XXXX Data

0000 1100 0001 0000 Mask
XXXX 01XX XXXD XXXX Data

1100 0000 0000 0001 Mask
01XX 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?
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
jury
Captain Atari
Captain Atari
Posts: 376
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Steem SSE 3.6 bug reports

Post by jury »

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
Atari Super Hero
Atari Super Hero
Posts: 515
Joined: Sat Jan 10, 2009 5:40 am

Re: Steem SSE 3.6 bug reports

Post by Hippy Dave »

Steven Seagal wrote:
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?
The LMC1996 data sheet doesn't mention Microwire incorrectly (maybe unclearly).
The Atari schematics also show that-12dB doesn't exist.
This 'official' document is indeed doubly wrong.
User avatar
npomarede
Atari God
Atari God
Posts: 1339
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Steem SSE 3.6 bug reports

Post by npomarede »

Hippy Dave wrote:
Steven Seagal wrote:
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?
The LMC1996 data sheet doesn't mention Microwire incorrectly (maybe unclearly).
The Atari schematics also show that-12dB doesn't exist.
This 'official' document is indeed doubly wrong.
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'.

Nicolas
User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Steem SSE 3.6 bug reports

Post by Steven Seagal »

http://pdf.datasheetcatalog.com/datashe ... 010789.PDF

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.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
User avatar
npomarede
Atari God
Atari God
Posts: 1339
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Steem SSE 3.6 bug reports

Post by npomarede »

Steven Seagal wrote:http://pdf.datasheetcatalog.com/datashe ... 010789.PDF

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 :)
User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Steem SSE 3.6 bug reports

Post by Steven Seagal »

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.

Pacemaker:

mask
$c1ff = 1100000111111111

data
$8000 = 1000000000000000
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
User avatar
npomarede
Atari God
Atari God
Posts: 1339
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Steem SSE 3.6 bug reports

Post by npomarede »

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.
User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2261
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem SSE 3.6 bug reports

Post by DrCoolZic »

User avatar
Stefan jL
Atari God
Atari God
Posts: 1303
Joined: Thu May 09, 2002 3:21 pm
Location: Sweden
Contact:

Re: Steem SSE 3.6 bug reports

Post by Stefan jL »

It seems Antago STX don't work in Steem... Kodak80 claims it works in Hatari though.
DL: http://www.atari-forum.com/viewtopic.ph ... 86#p268786

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.
Image
User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Steem SSE 3.6 bug reports

Post by Steven Seagal »

Stefan jL wrote:It seems Antago STX don't work in Steem... Kodak80 claims it works in Hatari though.
DL: http://www.atari-forum.com/viewtopic.ph ... 86#p268786

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.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2261
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem SSE 3.6 bug reports

Post by DrCoolZic »

DrCoolZic wrote:can have a look here http://www.atari-forum.com/viewtopic.ph ... 09#p265709
Did you have time to look at ipf and ctr not working ?
User avatar
dlfrsilver
Atari God
Atari God
Posts: 1490
Joined: Mon Jan 31, 2005 1:41 am

Re: Steem SSE 3.6 bug reports

Post by dlfrsilver »

Steven Seagal wrote:
Stefan jL wrote:It seems Antago STX don't work in Steem... Kodak80 claims it works in Hatari though.
DL: http://www.atari-forum.com/viewtopic.ph ... 86#p268786

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 !
User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2261
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem SSE 3.6 bug reports

Post by DrCoolZic »

dlfrsilver wrote:
Steven Seagal wrote:
Stefan jL wrote:It seems Antago STX don't work in Steem... Kodak80 claims it works in Hatari though.
DL: http://www.atari-forum.com/viewtopic.ph ... 86#p268786

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).
I have also created a version with "track-header" that seems to work most of the time http://www.atari-forum.com/viewtopic.ph ... nc#p266236
User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Steem SSE 3.6 bug reports

Post by Steven Seagal »

DrCoolZic wrote:
DrCoolZic wrote:can have a look here http://www.atari-forum.com/viewtopic.ph ... 09#p265709
Did you have time to look at ipf and ctr not working ?
Yes and when I did it just worked, of course.
Loads to titles, didn't test further.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
User avatar
Stefan jL
Atari God
Atari God
Posts: 1303
Joined: Thu May 09, 2002 3:21 pm
Location: Sweden
Contact:

Re: Steem SSE 3.6 bug reports

Post by Stefan jL »

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 :)
Image
User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Steem SSE 3.6 bug reports

Post by Steven Seagal »

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 :)
No I mean I got the games mixed up!
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2261
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem SSE 3.6 bug reports

Post by DrCoolZic »

Steven Seagal wrote:
DrCoolZic wrote:
DrCoolZic wrote:can have a look here http://www.atari-forum.com/viewtopic.ph ... 09#p265709
Did you have time to look at ipf and ctr not working ?
Yes and when I did it just worked, of course.
Loads to titles, didn't test further.
Just tested again and seems to be right?
Sorry dont know what went wrong :(
Post Reply

Return to “Development”