Req : "Audio Sculpture" (STX,...) even not running...

All about the serious stuff.

Moderators: Mug UK, Zorro 2, Moderator Team

ijor
Hardware Guru
Hardware Guru
Posts: 3152
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby ijor » Thu Oct 26, 2017 1:36 pm

I am out of home for a few days so I can't do any testing. But this is quite an interesting case and I can't afford not to make some comments :) ...

troed wrote:... the code that follows (a "regular" trap #1 supervisor call) cannot execute since the trap #1 vector is not set up correctly. I'm not sure what the target hw does in that case actually


From the point of view of the 68000 hardware there is no such a thing as a non initialized exception vector. The CPU would read the exception vector and would attempt to fetch and execute at whatever address the vector points.

npomarede wrote:Yes, that's it. It seems that unlike "andi to sr" which allows to change SR and clear S bit, STOP will do a privilege violation exception (vector at addr $20) in case the requested value clear the S bit, which is the case with "#$777".


Yes, of course. A STOP that clears the S flags can trigger a privilege violation. It is clearly documented by Motorola. I am quite surprised this was not implemented by emulators and that it's the first time we found an example.

Yes, the stacked PC should be the one of the next instruction in case of the privilege exception ... It's not completely explicit in Motorola doc, but it still says that STOP increases PC then stop prefetching ...
Also, note that STOP can also be interrupted by a TRACE exception in case the T bit was set before the STOP. In that case, it could be interesting to check on real HW if the stacked PC is also pointing after the STOP.


It doesn't matter for this purpose what exactly STOP performs internally. All group 1 exceptions have the same behavior in this regard. In these two cases the PC in the exception frame should be the same, and also the same as the one in an interrupt exception. Only group 0 exceptions can interrupt an instruction at the middle and then can push a different PC.

ijor
Hardware Guru
Hardware Guru
Posts: 3152
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby ijor » Thu Oct 26, 2017 1:41 pm

Steven Seagal wrote:About the images:
The STX one linked to at the start is v1.5! Both it and the STX of v1.3 run in Steem, but may fail to load.
The SCP of v1.3 loads almost all the time but I lose keyboard control with option C1 ("precise" keyboard...) - without option C1 it hangs on the black 'Audio Sculpture' screen.
The CTR of v1.3 hangs (I think it fails the protection on track 3).

EDIT: This software reprograms the 6301. Yeepee, another case! :)

EDIT2: There was also another WD1772 emu bug that messed up the timing of 6301 programming, without it the SCP image also runs.
But we still have a problem with the CTR image.


The CTR image likely has a wrong decoding of track 3. In case of doubts the Pasti images that were taken directly on the ST should have the right data. But OTOH, note that the (non converted) Pasti images miss some data on track 2. I can't check it now, but I think that data is not relevant and not read by the software. This is an old bug in the imaging tool. Anyway, I will provide a corrected Pasti image.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby npomarede » Thu Oct 26, 2017 1:43 pm

ijor wrote:
npomarede wrote:Yes, that's it. It seems that unlike "andi to sr" which allows to change SR and clear S bit, STOP will do a privilege violation exception (vector at addr $20) in case the requested value clear the S bit, which is the case with "#$777".


Yes, of course. A STOP that clears the S flags can trigger a privilege violation. It is clearly documented by Motorola. I am quite surprised this was not implemented by emulators and that it's the first time we found an example.

Hi
I read motorola's doc (9th edition from 1993 and programmer's ref manual incl cpu32 from 1992), but I didn't see any mention of this in the description of STOP. Did you use another doc ? (the only mention of this behaviour is in the description of LPSTOP)

ijor
Hardware Guru
Hardware Guru
Posts: 3152
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby ijor » Thu Oct 26, 2017 2:08 pm

npomarede wrote:I read motorola's doc (9th edition from 1993 and programmer's ref manual incl cpu32 from 1992), but I didn't see any mention of this in the description of STOP. Did you use another doc ? (the only mention of this behaviour is in the description of LPSTOP)


Hi Nicolas,

I have an old official manual that I bought back at the day. I'm not at home, so I can't tell you which edition. It is much older than the one you mention, from the 80's. For the 68000 and 68010 only. It is probably the most complete edition by Motorola. Will post a picture of the cover when back at home.

User avatar
Brume
Red eyes
Red eyes
Posts: 4100
Joined: Mon Apr 22, 2002 10:16 am
Location: France
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby Brume » Thu Oct 26, 2017 2:10 pm

ijor wrote:This is an old bug in the imaging tool. Anyway, I will provide a corrected Pasti image.

Also I dare to ask:
Maybe could you provide a new version of the imaging tool? ;)
Thanks in advance, ijor.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1988
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby Steven Seagal » Thu Oct 26, 2017 3:06 pm

ijor wrote:Yes, of course. A STOP that clears the S flags can trigger a privilege violation. It is clearly documented by Motorola. I am quite surprised this was not implemented by emulators and that it's the first time we found an example.


To be fair with Steem authors, this was implemented but I found it appropriate to change that a few days ago as I thought it was a mistake. :)

The documentation states:

Code: Select all

If Supervisor State
   Then Immediate Data -> SR; STOP
Else TRAP


You could interpret it as "test Privilege once, if OK put Data in SR and wait".
I'm surprised that privilege is tested at each iteration.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby npomarede » Thu Oct 26, 2017 3:18 pm

Steven Seagal wrote:
ijor wrote:Yes, of course. A STOP that clears the S flags can trigger a privilege violation. It is clearly documented by Motorola. I am quite surprised this was not implemented by emulators and that it's the first time we found an example.


To be fair with Steem authors, this was implemented but I found it appropriate to change that a few days ago as I thought it was a mistake. :)

I had a look at Steem's source (the old ones) earlier and I didn't see they handled this in cpu.cpp ; where do you see they trigger exception 8 if S is not set in the new value ?
The documentation states:

Code: Select all

If Supervisor State
   Then Immediate Data -> SR; STOP
Else TRAP


You could interpret it as "test Privilege once, if OK put Data in SR and wait".
I'm surprised that privilege is tested at each iteration.

It doesn't test at each iteration, because if new value is wrong at start there will be no iteration at all, only a privilege exception.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1988
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby Steven Seagal » Thu Oct 26, 2017 3:32 pm

Privilege is tested at each iteration right at the start of the instruction:

Code: Select all

void                              m68k_stop(){
  if (SUPERFLAG){
  ...
  }else{
    exception(BOMBS_PRIVILEGE_VIOLATION,EA_INST,0);
  }
}


While the CPU is stopped, the "process" loop keeps coming here.
This is why PC is not updated before the "unstop".

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby npomarede » Thu Oct 26, 2017 3:39 pm

Steven Seagal wrote:While the CPU is stopped, the "process" loop keeps coming here.
This is why PC is not updated before the "unstop".

OK, I didn't see the outer "if (SUPERFLAG){" at first.

ijor
Hardware Guru
Hardware Guru
Posts: 3152
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby ijor » Fri Oct 27, 2017 2:54 am

Brume wrote:
ijor wrote:This is an old bug in the imaging tool. Anyway, I will provide a corrected Pasti image.

Maybe could you provide a new version of the imaging tool? ;)


Well, yeah :) But it's not so easy. The imaging tool have to be tested well on a real ST. Can't be performed under emulation. And currently I have very limited possibilities to setup my ST hardware, unfortunately.

Btw, not trying to give excuses, but it isn't exactly a bug. It is a feature, a known limitation. I was aware about only one case that I was affected by this (again, I'm not at home, without my notes I don't remember which one). This is the second one that has the same issue, but in this case seems it is not as important as in the other title. The other title won't run because of this. IIRC, I provided a Pasti image converted from a Discovery Cart dump.

ijor
Hardware Guru
Hardware Guru
Posts: 3152
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby ijor » Fri Oct 27, 2017 3:26 am

Steven Seagal wrote:The documentation states:

Code: Select all

If Supervisor State
   Then Immediate Data -> SR; STOP
Else TRAP


You could interpret it as "test Privilege once, if OK put Data in SR and wait".
I'm surprised that privilege is tested at each iteration.


Not exactly. They are two separate things. That seudocode only documents that STOP is a privileged instruction. That doesn't mean that clearing the S flag would trigger a privilege violation. Other instructions that modify the SR show the same seudocode, yet they don't trigger a priv violation exception if they clear the S flag.

In the manual I have, there is an explicit note that clearing the S flag could provoke an exception. For some reason they removed that note on later versions of the manual. It is possible that the omission is intentional because it depends on the microcode. And conceivable (have no way to test it), it behaves different in other CPU32 processors.

npomarede wrote:It doesn't test at each iteration, because if new value is wrong at start there will be no iteration at all, only a privilege exception.


Actually it is (almost) exactly the other way around. It tests (sort of, see below) at each iteration and, strange as it might sound, there are multiple iterations even if the new value clears the S flag ...

The instruction doesn't explicitly test if the new value would clear the S flag or not. That would be too expensive to implement at the microcode. What happens is that STOP does set the SR regardless. And in later iterations, because now the processor is in User mode, a priv violation exception is triggered. Not by the microcode, but by the same logic that checks for priv violations whenever starting any instruction.

It is possible that this is an incidental, and not by design, consequence of the microcode implementation. Conceivable it is different in later processors.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby npomarede » Fri Oct 27, 2017 8:07 am

ijor wrote:Actually it is (almost) exactly the other way around. It tests (sort of, see below) at each iteration and, strange as it might sound, there are multiple iterations even if the new value clears the S flag ...

The instruction doesn't explicitly test if the new value would clear the S flag or not. That would be too expensive to implement at the microcode. What happens is that STOP does set the SR regardless. And in later iterations, because now the processor is in User mode, a priv violation exception is triggered. Not by the microcode, but by the same logic that checks for priv violations whenever starting any instruction.

It is possible that this is an incidental, and not by design, consequence of the microcode implementation. Conceivable it is different in later processors.

Hi
I confirm I see this behaviour : in case the new SR value has S=0, then the new value is first copied into SR and it's this value that's latter pushed into the stack during the priv exception. This is different from the case where S=0 before the STOP.
For example, as tested on my STF :

Code: Select all

SR=700        STOP 555        SR_NEW=2700     SR_STACK=0700   PC_STACK=STOP
SR=2700       STOP 555        SR_NEW=2515     SR_STACK=0515   PC_STACK=STOP+4

I discussed this yesterday with Toni Willen (WinUAE dev) and he was able to test this on other 680xx CPU, and results are even different :
Toni Willen wrote:So apparently it first updates SR, then it checks S-bit state, if not
set -> exception (which always sets S). Probably yet another re-use of
some existing 68000 microcode routine.

But wait, there is still one more! 68020 and 68030 does not cause
exception! STOP #0 will stop the CPU normally. 68060 again (68040 most
likely too, didn't test) cause the exception but does not change the SR!
(Stacked SR is same as SR before STOP instruction)


So Ijor assumptions are correct, this beaviour is not the same in all 680xx CPU.

Nicolas

User avatar
troed
Atari God
Atari God
Posts: 1213
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby troed » Fri Oct 27, 2017 10:57 am

Alright. So since Hatari doesn't emulate the 6301 and a program there is indeed used for decryption of the main application code I needed to do a bit more work. But now I have the 1.5 image working in Hatari as well.

as15_hatari.png


PS: I'm sort of sure there's an emulation issue with timing when in mono, and I'm not sure AS correctly patches TOS 2.06. I've gone to color 1.62 to do these final parts.
You do not have the required permissions to view the files attached to this post.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby npomarede » Fri Oct 27, 2017 1:21 pm

troed wrote:PS: I'm sort of sure there's an emulation issue with timing when in mono, and I'm not sure AS correctly patches TOS 2.06. I've gone to color 1.62 to do these final parts.

Regarding the mono issue, I see a problem at address $D7EA when the program reads timer B data registers to simulate a wait for several VBL and I see the value read in FFFA21 is not correct in that case mixing mono and low res.
Is that where it stops in your tests ? If so, you can write a NOP at addresses $D812 and $D81C and it should pass.

ijor
Hardware Guru
Hardware Guru
Posts: 3152
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby ijor » Fri Oct 27, 2017 1:56 pm

npomarede wrote:
Toni Willen wrote:So apparently it first updates SR, then it checks S-bit state, if not
set -> exception (which always sets S). Probably yet another re-use of
some existing 68000 microcode routine.

But wait, there is still one more! 68020 and 68030 does not cause
exception! STOP #0 will stop the CPU normally. 68060 again (68040 most
likely too, didn't test) cause the exception but does not change the SR!
(Stacked SR is same as SR before STOP instruction)


So Ijor assumptions are correct, this beaviour is not the same in all 680xx CPU.


Interesting. The different behavior with the 020/030 might be not only a microcode issue but also a consequence of the different prefetech.

Btw Nicolas, did you read my recent comment on the other thread that STOP does can take 4 cycles only in some cases? When Troed mentioned an issue with STOP, I thought initially it might be this.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby npomarede » Fri Oct 27, 2017 5:14 pm

ijor wrote:Btw Nicolas, did you read my recent comment on the other thread that STOP does can take 4 cycles only in some cases? When Troed mentioned an issue with STOP, I thought initially it might be this.

Yes I saw this other thread from you. On first sight, I don't think any program are not correctly emulated due to this case you described, but it should be emulated nevertheless (Audio Sculpture makes little use of cycle accuracy in its protection, so these 4 cycles could not be the case for the problem when we saw the protection was crashing)

Nicolas

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1988
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby Steven Seagal » Fri Oct 27, 2017 6:02 pm

troed wrote:Alright. So since Hatari doesn't emulate the 6301 and a program there is indeed used for decryption of the main application code I needed to do a bit more work. But now I have the 1.5 image working in Hatari as well.

as15_hatari.png


OK now I may post the Steem screenshot ;)

audio_sculpture_1_5_stx.png


PS: I'm sort of sure there's an emulation issue with timing when in mono, and I'm not sure AS correctly patches TOS 2.06. I've gone to color 1.62 to do these final parts.


In Steem too, guess some code could be missing... Is it supposed to be monochrome-compatible? (v1.5 or v1.3)?

EDIT Here in mono ("preview", code isn't fixed, when restarting it passed that part by accident :shrug: ):

audio_sculpture_1_5_stx_mono.png
You do not have the required permissions to view the files attached to this post.
Last edited by Steven Seagal on Fri Oct 27, 2017 6:17 pm, edited 2 times in total.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1988
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby Steven Seagal » Fri Oct 27, 2017 6:12 pm

ijor wrote:
Steven Seagal wrote:The documentation states:

Code: Select all

If Supervisor State
   Then Immediate Data -> SR; STOP
Else TRAP


You could interpret it as "test Privilege once, if OK put Data in SR and wait".
I'm surprised that privilege is tested at each iteration.


Not exactly. They are two separate things. That seudocode only documents that STOP is a privileged instruction. That doesn't mean that clearing the S flag would trigger a privilege violation. Other instructions that modify the SR show the same seudocode, yet they don't trigger a priv violation exception if they clear the S flag.


That's what I meant, more precisely "test Privilege at start of instruction, if OK put whatever Data in SR and wait".
So no hint of an exception if the new SR is in user mode in the updated doc. But now we know why: unreliable behaviour depending on which CPU is running! :mrgreen:

To me, the exception makes little sense.

User avatar
dlfrsilver
Atari God
Atari God
Posts: 1421
Joined: Mon Jan 31, 2005 1:41 am
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby dlfrsilver » Fri Oct 27, 2017 10:10 pm

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

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1988
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby Steven Seagal » Sat Oct 28, 2017 9:50 am

Steven Seagal wrote:
PS: I'm sort of sure there's an emulation issue with timing when in mono, and I'm not sure AS correctly patches TOS 2.06. I've gone to color 1.62 to do these final parts.


In Steem too, guess some code could be missing... Is it supposed to be monochrome-compatible? (v1.5 or v1.3)?


Indeed, this wasn't correctly emulated... I guess because we don't often meet this situation.
What's a bit troubling is that, again, apparently, the same bug is in Steem and Hatari.

User avatar
kodak80
Captain Atari
Captain Atari
Posts: 448
Joined: Sat Nov 09, 2013 12:05 am
Location: Brisbane, Australia
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby kodak80 » Sat Oct 28, 2017 10:12 pm

Good to see the emulation being updated and I see that the Steem SSE beta now allows this SCP and STX to run. :D
Atari Falcon 030 | Atari 1040 STE | Atari 1040 STFM | Atari 1040 STF | Kryoflux & Supercard Pro Flux boards
Admin of Atari ST Review Magazine Archive: http://www.ataristreview.com

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby npomarede » Sun Oct 29, 2017 12:17 pm

ijor wrote:Interesting. The different behavior with the 020/030 might be not only a microcode issue but also a consequence of the different prefetech.

Toni did some more tests when combining with TRACE bit.
It can give some "funny" result to obfuscate some code too. Consider this :
Toni Wilen wrote:

Code: Select all

; already in supervisor mode
or #$8000,sr
stop #0
addq.l #1,d0
Sequence is:
- stop does 0 -> sr copy
- trace exception (my test code only stored SR and stacked PC and did RTE)
- execution continues normally from addq.l #1,d0 in user mode and no
trace enabled
(because trace stacked SR was zero)

Also, Toni measured that STOP would take only 4 cycles if TRACE if set before the STOP :
Toni Wilen wrote:Hint about STOP being sometimes faster made me to do some more tests: if
Trace is set, STOP is faster! 4 vs 8 cycles. 4 cycles if trace, 8 cycles
if T was not set (and S-bit was cleared in STOP parameter)


Nicolas

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 639
Joined: Mon Nov 04, 2013 5:23 pm

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby JimDrew » Sun Oct 29, 2017 4:56 pm

kodak80 wrote:I have tried writing Brume's SCP dump back to floppy but it does not work in either my STE or STFM. I have tried the various options in the SCP program when writing back but I have had no success with getting a disk 1 that boots.

On boot it accesses the disk twice and then no further disk activity and my screen turns itself off as it is not detecting any video output. :(

I hope this helps. If the dumps are good then maybe Jim Drew should have a look at the SCP dump for further testing?


I was just made aware of this, so I will grab the image and look at it.
I am the flux ninja

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1988
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby Steven Seagal » Sun Oct 29, 2017 5:21 pm

npomarede wrote:Toni did some more tests when combining with TRACE bit.
It can give some "funny" result to obfuscate some code too. Consider this :
Toni Wilen wrote:

Code: Select all

; already in supervisor mode
or #$8000,sr
stop #0
addq.l #1,d0
Sequence is:
- stop does 0 -> sr copy
- trace exception (my test code only stored SR and stacked PC and did RTE)
- execution continues normally from addq.l #1,d0 in user mode and no
trace enabled
(because trace stacked SR was zero)

Also, Toni measured that STOP would take only 4 cycles if TRACE if set before the STOP :
Toni Wilen wrote:Hint about STOP being sometimes faster made me to do some more tests: if
Trace is set, STOP is faster! 4 vs 8 cycles. 4 cycles if trace, 8 cycles
if T was not set (and S-bit was cleared in STOP parameter)


Nicolas


It is compatible with the delay in updating SR.
After STOP's first iteration, trace starts at once, SR is updated during the first nn cycles of that exception, then it is stacked, the PC stacked is "PC+4", privilege won't be tested again.
I see this so now but I hadn't thought of that before.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 639
Joined: Mon Nov 04, 2013 5:23 pm

Re: Req : "Audio Sculpture" (STX,...) even not running...

Postby JimDrew » Mon Oct 30, 2017 12:34 am

I took a quick look at the image file (.scp format). Track 0, 1, and 2 are definitely not "normal" by PC/Atari ST standards. I didn't look at other tracks. Each of these tracks starts with a single $4489 sync, followed by 16 words of data, followed by three $4489 sync marks. Around 16 or so words later there is another set of three $4489 sync marks, followed by a sector's worth of data. So, every sector has the two sets of sync marks, and each sector was written individually, not as a full track in one revolution. Thus, there are numerous write splices. The disk is a bit dirty, so the image is a little noisy. I don't have a ST setup currently, but other than perhaps a bit noisy I don't see any reason from a flux stand point why this disk won't copy correctly.
I am the flux ninja


Social Media

     

Return to “Applications”

Who is online

Users browsing this forum: No registered users and 3 guests

cron