Subject: Test Program.

From: "Marc H" <[email-masked]>
Date: Sat, 08 Jun 2013 01:02:31 -0000

In the files section is a disk file (or will be shortly) called soundtest.zip.  I need some volunteers to please DL & convert the file to a SSSD disk and run the EA5 executable called soundtest.  The program will not damage your TI in anyway.  It will flash some text and make some random noise for about 5 seconds and either display an all clear message or lock up at some point.  

I would like to here from anyone who executes this especially if you get a lock up condition.  If you do get a lockup will you please report the date code on the bottom of the computer as well as whether it is a 4 or 4A ?

Thanks.

Marc

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 08 Jun 2013 13:28:58 -0000

> I would like to here from anyone who executes this especially if you get a lock up condition.  

Do you have a theory about this? Do you think that you can lock up the sound chip this way?

BTW, if this is possible, it indeed has a potential to lock up the console because the sound processor also connects to READY. 

Michael

---

From: Marc Hull <[email-masked]>
Date: Sat, 8 Jun 2013 06:58:41 -0700 (PDT)

Well it's not my theory and I'm not sure it is entirely correct.  The Bunyard manual states several time not to read the sound chip as it will lock up the console.  Doesn't lock up on any of mine though so it appears to be info based on an earlier design or just more Ti information obfuscation ;-)....

I have a use for reading memory mapped into the >8400 area but it goes out the window if it locks up peoples consoles.

--- On Sat, 6/8/13, Michael Zapf <[email-masked]> wrote:

From: Michael Zapf <[email-masked]>
Subject: [TI994A] Re: Test  Program.
To: [email-masked]
Date: Saturday, June 8, 2013, 8:28 AM

  

      

Michael

---

From: "Tony Knerr" <[email-masked]>
Date: Sat, 08 Jun 2013 19:46:35 -0000

Tested on 99/4P. Bunch of random noise, then message "ALL GOOD. PRESS QUIT", QUIT key worked.

Tony

---

From: [email-masked]
Date: Sat, 8 Jun 2013 22:43:18 +0000 (UTC)

Michael 

Yea it is possible I have accidentally done it with the RXB command CALL IO(0,X) like this messing around. 

100 FOR X=-327667 TO 32768 
110 PRINT X 
120 CALL IO(0,X) ! Call IO chip and play GROM sound list pointer at X 
130 CALL PEEK(-31879,Y) ! Peek to see if zero (0) so the sound list is done. 
140 IF Y<>0 THEN 130 ! Not a zero (0) then keep going. 
150 NEXT X 

I was just looking for some strange sounds I could produce easy. But somewhere it changed the screen color and locked up the system. 
This only plays GROM sound lists so you got me what went wrong? 

In less then 15 minutes the screen will be messed up and it progressively gets worse. 

Rich 
----- Original Message -----
From: "Michael Zapf" <[email-masked]> 
To: [email-masked] 
Sent: Saturday, June 8, 2013 6:28:58 AM 
Subject: [TI994A] Re: Test Program. 

Michael

---

From: James Abbatiello <[email-masked]>
Date: Fri, 14 Jun 2013 01:32:55 -0400

On Fri, Jun 7, 2013 at 9:02 PM, Marc H <[email-masked]> wrote:

> **
>
>
> In the files section is a disk file (or will be shortly) called
> soundtest.zip. I need some volunteers to please DL & convert the file to a
> SSSD disk and run the EA5 executable called soundtest. The program will not
> damage your TI in anyway. It will flash some text and make some random
> noise for about 5 seconds and either display an all clear message or lock
> up at some point.
>
> I would like to here from anyone who executes this especially if you get a
> lock up condition. If you do get a lockup will you please report the date
> code on the bottom of the computer as well as whether it is a 4 or 4A ?
>
I ran it on mine (with LTA1283 printed on the bottom) and it did not lock
up.  Is the sound chip even enabled for reads?  For reads in the range
>84xx it seems like U505 should get a low input on its G1 and thus not
enable the sound chip via its Y1 output.

-- 
James Abbatiello

---

From: Marc Hull <[email-masked]>
Date: Fri, 14 Jun 2013 12:09:37 -0700 (PDT)

Well the whole thing is starting to look like smoke to me.  The only reason I brought it up was I plan on using some registers mapped into that area and when I saw the dire warnings about "reading" the sound chip I went off onto this.   Now I am just curious as to what spawned the warning in the first place ;-).... 

--- On Fri, 6/14/13, James Abbatiello <[email-masked]> wrote:

From: James Abbatiello <[email-masked]>
Subject: Re: [TI994A] Test Program.
To: [email-masked]
Date: Friday, June 14, 2013, 12:32 AM

  

 

    

I ran it on mine (with LTA1283 printed on the bottom) and it did not lock up.  Is the sound chip even enabled for reads?  For reads in the range >84xx it seems like U505 should get a low input on its G1 and thus not enable the sound chip via its Y1 output.

-- 
James Abbatiello

---

From: tursi <[email-masked]>
Date: Fri, 14 Jun 2013 14:21:01 -0700 (PDT)

> Well the whole thing is starting to look like smoke to me.  The only reason I
> brought it up was I plan on using some registers mapped into that area and
> when I saw the dire warnings about "reading" the sound chip I went off onto
> this.   Now I am just curious as to what spawned the warning in the first
> place ;-)....

More than likely the datasheet for the sound chip.. on the later one, at 
least, it states that READY is pulled low after CE, but before WR. It 
never says what releases READY in the case that WR never goes low -- it's 
possible that it's clocked to a fixed duration (as the datasheet includes 
a truth table that it states is valid only when the chip is NOT clocked), 
or that the datasheet is outright wrong.

I'll see if I can get the logic analyzer on there this weekend and see 
what a read cycle to the chip looks like - if nothing else it's a nice 
long-standing mystery that can potentially be settled. ;)

---

From: Jeff White <[email-masked]>
Date: Fri, 14 Jun 2013 22:00:39 -0400

I wonder if the Geneve or 98/8, which use the 9995 (or derivative), would lock up on a sound chip read.  Because of the 8-bit bus on the 9995, the read-before-write does not happen.  On the Geneve, you can use the same ports for read and write.

Jeff White

---

From: Jeff White <[email-masked]>
Date: Fri, 14 Jun 2013 22:05:14 -0400

Crikey, 99/8.

---

From: "Tony Knerr" <[email-masked]>
Date: Sat, 15 Jun 2013 13:55:01 -0000

The program works fine on the Geneve, too. No lockup.
Although Fctn-Quit doesn't work, a Ctrl-Shift-Shift is needed to escape.

Tony

--- In [email-masked], Jeff White <ti994a@...> wrote:
> On 14 Jun 2013, at 15:09, Marc Hull <marc.hull@...> wrote:

---

From: "Tursi" <[email-masked]>
Date: Sat, 15 Jun 2013 22:31:16 -0700

Tested with the logical analyzer on two machines, both pre-QI. I don't have 
any older ones to try, sadly.

Sound Chip SN94624

Write cycle:

Ready is low for 7.17us
WE is low for 7.69us
CS is low for 8us

(time in ns)
0        CS goes low first (TI)
100        READY goes low (sound chip)
240        WE goes low (TI)
7270    READY goes high (sound chip)
7930    WE goes high (TI)
8000    CS goes high (TI)

Read Cycles did not trigger the sound chip at all (CS never went low). The 
rumors of this issue being "fixed in later hardware" might actually predate 
the QI. I don't have a 99/4 to try with anymore, but that's interesting!

Serial number is 10056539, code LTA1883
Second machine is 2323377, code LTA2882

---

From: James Abbatiello <[email-masked]>
Date: Sun, 16 Jun 2013 14:56:14 -0400

> the QI. I don't have a 99/4 to try with anymore, but that's interesting!
Neat.  The circuit that masks out the reads looks like it covers not only
>8400->87FF (sound chip write) but also >8C00->8FFF (VDP write),
>9400->97FF (speech synth write), and >9C00->9FFF (GROM write).  Could
somebody theoretically map something read-only in any of those address
ranges?

-- 
James Abbatiello

---

From: James Abbatiello <[email-masked]>
Date: Wed, 19 Jun 2013 01:31:24 -0400

On Sat, Jun 8, 2013 at 6:43 PM, <[email-masked]> wrote:

> I was just looking for some strange sounds I could produce easy. But
> somewhere it changed the screen color and locked up the system.
I have a theory.  As the sound routine is playing and interpreting these
bytes as sound lists it eventually comes across some bytes that look like:
  >FF >wx >yz
It interprets this as a request to switch to fetching sound from the VDP
starting at address >wxyz.  It will do this by writing first >yz and then
>wx to >8C02 to set the VDP read address.  If it is a valid address then
everything works correctly.  However if it is greater than >3FFF then we
have a problem.  For example
  >FF >87 >yz
is going to write >yz to VDP register 7 instead of setting an address.
This causes your background/foreground color to change.  Similarly
  >FF >81 >yz
is going to write to VDP register 1 and can disable VDP interrupts.  In
that case no more sound commands will be processed and nothing will ever
turn the interrupts back on again.

-- 
James Abbatiello

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 19 Jun 2013 08:13:47 -0000

Hi James,

your theory works only for interrupt-driven sound processing. 

The interrupt routine is the one which decides to get the bytes from CPU or VDP RAM. Here we are pushing the bytes to the sound processor directly. The sound processor itself is passive, just accepting the bytes it gets.

Michael

---

From: James Abbatiello <[email-masked]>
Date: Wed, 19 Jun 2013 14:50:40 -0400

On Wed, Jun 19, 2013 at 4:13 AM, Michael Zapf <[email-masked]> wrote:

> The interrupt routine is the one which decides to get the bytes from CPU
> or VDP RAM. Here we are pushing the bytes to the sound processor directly.
> The sound processor itself is passive, just accepting the bytes it gets.
>

I was attempting to explain the behavior seen in the RXB example that was
using CALL IO(0,X).  I agree that directly feeding the sound chip would not
suffer from this potential pitfall.

-- 
James Abbatiello

---

From: Marc Hull <[email-masked]>
Date: Wed, 19 Jun 2013 15:21:02 -0700 (PDT)

The RXB issue seems to be an unrelated problem.  The behavior as described would be an immediate lock up of the system on a hardware level.  The 9919 READY pin would freeze the CPU until another condition was met (which couldn't possibly happen there fore you get a hardware level lock up.  At least that's my take on it ;-)...

--- On Wed, 6/19/13, James Abbatiello <[email-masked]> wrote:

From: James Abbatiello <[email-masked]>
Subject: Re: [TI994A] Re: Test Program.
To: [email-masked]
Date: Wednesday, June 19, 2013, 1:50 PM

  

 

    

      Hi James,

I was attempting to explain the behavior seen in the RXB example that was using CALL IO(0,X).  I agree that directly feeding the sound chip would not suffer from this potential pitfall.

-- 
James Abbatiello