MAME: Speech

[Pernod]

Whilst rewriting the VIA handling in MAME I thought it's about time to get Speech working. All the components have been in there for many years but has never worked.

There's been previous discussion on the ordering of INT/READY on PB 6/7 of the system VIA, both the B and B+ schematic show PB6=INT and PB7=READY but I believe tricky implemented them in BeebEm the other way around for AstroBlaster, so which way are they? The AUG states "PB6 is the speech processor 'ready' output and PB7 is from the speech processor 'interrupt' output", to add to the confusion.

When should I actually perform the R/W from the slow data bus to the TMS5220, in terms of RS,WS,READY?

When I have Acorn Speech working I'll take a look at the Cheetah Sweet Talker, as it uses the same socket.

[tricky]

AstroBlaster will work either way, so will computer concepts speech. I think acorn speech requires them the new way (issue 7), which I think works in my mod of beebem.

[Pernod]

I'm suspecting maybe a bug in the MAME implementation of tms5220.

On my real Beeb with Speech at startup I get:
&FE40 = &7B
and after a SOUND -1,...
&FE40 = &3B

Is this telling me that after a tms5220 reset (¬RS and ¬WS both high) the ¬INT line is high on PB6?

[tricky]

In AstroBlaster I use this code to check for the ready signal to see if speech is fitted and to find out which line (SysVia PB6/7) it is connected to:

Code: Select all

SysPB6_SpeechReady     =  64 \\ These will be swapped on Issue <= 4 that
SysPB7_SpeechInterrupt = 128 \\ have not been modified to match series 7

SysPA5_SpeechEmpty   =  32 \\ ran out during speak / speak external
SysPA6_SpeechLow     =  64 \\ FIFO <= half full (8 bytes)
SysPA7_SpeechTalking = 128 \\ Speak / Speak External

.speak_init
{
	SEI

	lda #&0F : sta SysViaDDRB
	lda #0   : sta SysViaDDRA
	lda #0+1 : sta SysViaRegB \\ read select speech
	lda SysViaRegB : and #SysPB6_SpeechReady OR SysPB7_SpeechInterrupt : sta speak_READY
.find_READY
	LDA SysViaRegB : and #SysPB6_SpeechReady OR SysPB7_SpeechInterrupt
	eor speak_READY
	beq find_READY
	sta speak_READY
	lda #8+1 : sta SysViaRegB \\ read deselect speech

	ldy #9
	lda #&FF
.reset
	jsr speak_write_A
	dey
	bne reset

	CLI

	RTS
}

.speak_write_A
{
  PHA
  lda #&FF : sta SysViaDDRA
  PLA
             sta SysViaRegA
  lda #0+2 : jsr speak_write_rw \\ speech write enable
  lda #8+2 : sta SysViaRegB     \\ speech write disable
  RTS
}

.speak_write_rw
{
	sta SysViaRegB
}
.speak_wait_ready
{
	lda speak_READY
.wait
	bit SysViaRegB
	bne wait
	RTS
}

.speak_read_status \\ MI=Talking VS=Low NE=Empty
{
  lda #0   : sta SysViaDDRA
  lda #0+1 : jsr speak_write_rw \\ speech read enable
  lda #SysPA5_SpeechEmpty : bit SysViaRegA \\ 
  PHP
  lda #8+1 : sta SysViaRegB      \\ speech read disable
  PLP
  RTS
}

It's all a bit dim and distant now, but I'll try and help if I can.

[Pernod]

After finding the ROM for the Beeb Speech Synthesizer from Watford it was very easy to implement, considering no schematic or even a photo of the board.

It has a SP0256-AL2 connected to PB0-PB6 to speak allophones. PB7/PB8 specify high/low intonation. The CB1/CB2 lines are connected to LRQ/SBY.

It seems to work according to the manual, but I have no information on the clock used. If anyone has one of these I'd like to see a photo of the board and some recordings for comparison.

[marcusjambler]

Photos of the PCB of WE speech unit... I'm struggling to spot a crystal
Strangely pin 28 is not connected which, according to the SPO256, data sheet should be one side of the crystal

Marcus

[Pernod]

Photos of the PCB of WE speech unit... I'm struggling to spot a crystal
Strangely pin 28 is not connected which, according to the SPO256, data sheet should be one side of the crystal

Thanks for those, though the lack of crystal has thrown me. They're typically clocked between 3-4MHz. Anyone any ideas?

Oh, and could you post your ROM image? We currently have two variants so would be nice to compare your known genuine ROM with what we already have.

[marcusjambler]

Rom Dump

WESPEECH.zip

(4.56 KiB) Downloaded 77 times

[Pernod]

Rom Dump

WESPEECH.zip

Thanks, that matches a version with incorrect allophones for O'CLOCK.

[Pernod]

Strangely pin 28 is not connected which, according to the SPO256, data sheet should be one side of the crystal

Pin 27 goes to the 74LS629 which is a voltage controlled oscillator. Anyone know how to calculate the frequency generated?

[daveejhitchins]

The 74LS269 is listed as an: 8-BIT BIDIRECTIONAL BINARY COUNTER - and seems to indicate a 24 pin part - which is obviously isn't - added to that the links I've followed seem to result in the 24 pin part being a 74F269!! Hmmm! Interesting . . .

Dave H

[marcusjambler]

It looks like you set the range (RNG) and the actual frequency depends on the value of Cext and the pot.
According to Fig. 1 to 5

[marcusjambler]

74LS629 is the IC

[hoglet]

(Snap!)

It's a 74LS629, data sheet is here:
http://www.ti.com/lit/ds/symlink/sn54ls628.pdf

[daveejhitchins]

D'oh! Dyslexic, or what . . .

Dave H

[marcusjambler]

Maplins take on it....

http://www.americanradiohistory.com/UK/ ... -02-03.pdf

[Pernod]

D'oh! Dyslexic, or what . . .

Dave H

Apologies, I did typo it earlier.

The frequency is also changed by the state of PB6/7 to change intonation. The frequencies I use in MAME are currently guessed.

[OneSwitch]

BBC Micro on MAME? Does this work?! I had no idea. Is this a small step from getting it working on RetroPie without too much faff I wonder?

Is there development to get it on a par with BeebEm does anyone know? Would love to see emulation for the User Port and touch-screen added so it will work with some of the special needs educational stuff.

[Pernod]

Implementing the Acorn Speech is still proving a challenge.

In OS1.20 it is checking bit 7 of SYSVIA PB to determine whether Speech is present, whether this is the ¬READY or ¬INT output from the TMS5220 is still up for debate. See OS code at http://mdfs.net/Docs/Comp/BBC/OS1-20/D940, speech check at &DB11. Can anyone validate this either way? In tricky's custom BeebEm it's ¬INT, but this doesn't set the speech presence flag at &27B so is not a good example.

The Speech upgrade instructions do state that issue 2/3 boards should have PB6/PB7 switched, issues 4 and 7 are good. The circuit diagrams out there appear to be issue 4 with ¬READY on PB7. The B+ schematic also has ¬READY on PB7 to further support this.

Assuming the ¬READY is bit 7 and ¬INT is bit 6 then the OS will detect and initialise the TMS5220. The OS then proceeds to start language BASIC2 at &8000. In BASIC2 it enables IRQs and jumps to &8ADD where it hangs, repeatedly calling the IRQ entry point at &DC1C. Can anyone explain why, and what would cause, it to get stuck here? It's repeatedly trying to service a speech interrupt, finding the buffer empty and exiting, then repeat

[tricky]

Don't rely on my names, as they are only used ORed together and it then looks for the one that changes after a reset to decide which is which.
I think the beebem code may swap them more than once, which will also hinder identification.
From what I remember, the delays between sending a command and the flags changing are important to get it working with CC and AstroBlaster and maybe the OS.
With the original beebem, only the OS speech works, but my current one supports all three.
I can put my current version up tonight if you like.

[dv8]

In OS1.20 it is checking bit 7 of SYSVIA PB to determine whether Speech is present, whether this is the ¬READY or ¬INT output from the TMS5220 is still up for debate.

Bit 7 is READY, bit 6 is INT. This is what the OS is expecting and is how IC3 is wired up on issue 4 and 7 boards.

On issue 2 and 3 boards these signals are the other way round. As part of the Acorn Speech installation process users (or more likely dealers) were expected to cut the traces to pins 16 and 17 of IC3 and swap them over to match the later revision boards.

Some software, like CC Speech, automatically detects which pin is READY and configures itself accordingly. This was to make it easier for end users to install the system in issue 3 boards without having to do the hardware mod.

EDIT: corrections.

[Pernod]

With the original beebem, only the OS speech works, but my current one supports all three.
I can put my current version up tonight if you like.

I thought I had your version from 2015, but what I have doesn't detect OS speech. The speech presence flag at &27B is not set.

Bit 7 is INT, bit 6 is READY. This is what the OS is expecting and is how IC3 is wired up on issue 4 and 7 boards.

On issue 2 and 3 boards (and on the schematic) these signals are the other way round. As part of the Acorn Speech installation process users (or more likely dealers) were expected to cut the traces to pins 16 and 17 of IC3 and swap them over to match the later revision boards.

Here's what OS1.2 does to detect/initialise speech at startup:

Code: Select all

DB11	BIT &FE40   ;if bit 7 low then we have speech system fitted
DB14	BMI &DB27   ;else goto DB27

DB16	DEC &027B   ;(027B)=&FF to indicate speech present

Checks bit 7, I believe both INT and READY should be low at this stage so no problem either way.

It then proceeds to initialise speech:

Code: Select all

   	            ;X=&10
DB19	LDY #&FF    ;Y=&FF
DB1B	JSR &EE7F   ;initialise speech generator
DB1E	DEX         ;via this
DB1F	BNE &DB19   ;loop

Not sure why this is in a loop, why initialise more than once?

Code: Select all

EE7F	TYA         ;transfer command to A
EE80	LDY #&01    ;to set speech proc to write

			 ;if Y=0 read speech processor
			 ;if Y=1 write speech processor

EE82	PHP         ;push flags
EE83	SEI         ;disable interrupts
EE84	BIT &027B   ;test for prescence of speech processor
EE87	BPL &EEAA   ;if not there goto EEAA
EE89	PHA         ;else push A
EE8A	LDA &F075,Y ;
EE8D	STA &FE43   ;set DDRA of system VIA to give 8 bit input (Y=0)
			 ;or 8 bit output (Y=1)
EE90	PLA         ;get back A
EE91	STA &FE4F   ;and send to speech chip
EE94	LDA &F077,Y ;output Prt B of system VIA
EE97	STA &FE40   ;to select read or write (dependent on Y)
EE9A	BIT &FE40   ;loop until
EE9D	BMI &EE9A   ;speech proceessor reports ready (bit 7 Prt B=0)
EE9F	LDA &FE4F   ;read speech processor data if  input selected
EEA2	PHA         ;push A
EEA3	LDA &F079,Y ;reset speech
EEA6	STA &FE40   ;processor

My problem here is at &EE9D waiting for bit 7 to go low. This has to be READY, otherwise it proceeds blindly to reset the 5220 to high impedance state before the reset command has been latched. If the reset command is never latched and executed then INT stays low (after power-up) which caused my previous issue of always trying to service a speech interrupt.

[dv8]

My problem here is at &EE9D waiting for bit 7 to go low. This has to be READY, otherwise it proceeds blindly to reset the 5220 to high impedance state before the reset command has been latched. If the reset command is never latched and executed then INT stays low (after power-up) which caused my previous issue of always trying to service a speech interrupt.

Darn it! Yes, it should have said bit 7 is READY, bit 6 is INT. The stuff about the connections being swapped over on early issue boards still applies.

I've been working with the Cheetah Sweet Talker recently which puts its ready signal (SBY) on bit 6 adding to the confusion.

It then proceeds to initialise speech:
...
Not sure why this is in a loop, why initialise more than once?

To get the 5220 into a known good state requires a minimum of 10 reset bytes (&FF).

If the speech processor is in Speak External mode the reset byte isn't processed as a command, it's just added to the FIFO (which is 9 bytes long). Once the buffer is full, the tenth reset byte received is actually executed and the chip is reset.

[Pernod]

Darn it! Yes, it should have said bit 7 is READY, bit 6 is INT. The stuff about the connections being swapped over on early issue boards still applies.

I've been working with the Cheetah Sweet Talker recently which puts its ready signal (SBY) on bit 6 adding to the confusion.

Ok, glad to have someone agree on the connections.

I'm interested in anything you know about the Cheetah implementation, as I'll be looking at implementing it soon.

[hoglet]

My problem here is at &EE9D waiting for bit 7 to go low. This has to be READY, otherwise it proceeds blindly to reset the 5220 to high impedance state before the reset command has been latched. If the reset command is never latched and executed then INT stays low (after power-up) which caused my previous issue of always trying to service a speech interrupt.

Did you ever resolve this issue Nigel?

I have been trying to add Acorn Speech (TMS5220) support to BeebFPGA and hit a similar issue with the speech interrupt firing continuously. After some head scratching, it turned out to be a bug in the 6522 implementation.

The speech interrupt (VSPINT) is connected to the System VIA PB6 input. Once the MOS detects the TMS5220 is present, it sets timer 2 in pulse counting mode (counting negative edges on PB6) and loads an initial value of zero into the timer. The next falling edge of the VSPINT causes the timer to wrap from 0000 to FFFF, and this triggers the timer 2 interrupt. The timer 2 interrupt handler reloads the timer with zero again, ready for the next edge.

There are a few things to note here:
1. This use of timer 2 is a rather cunning way to add an additional negative edge triggered input to the system VIA.
2. The interupt is edge triggered, so a persistent low level should not cause repeated interrupts.
3. It's crucial that the timer interrupt is generated on the 0000->FFFF transition, and not just on the timer reaching zero.

In my case, the bug in the 6522 implementation related to (3). As soon as the timer was loaded with zero, the interrupt condition was being raised, regardless of what the TMS5220 was doing.

I suspect PB6 pulse counting mode is one of the lesser used features of the 6522, so it wouldn't surprise me if MAME has bugs here as well.

Of couse, this is an old thread, so maybe you have already resolved this issue?

Dave

[Pernod]

My problem here is at &EE9D waiting for bit 7 to go low. This has to be READY, otherwise it proceeds blindly to reset the 5220 to high impedance state before the reset command has been latched. If the reset command is never latched and executed then INT stays low (after power-up) which caused my previous issue of always trying to service a speech interrupt.

Did you ever resolve this issue Nigel?

Yes, I'm in the process of refactoring my bbc drivers and my local build has fully working Acorn Speech. My problem was related to my implementation of the Slow Data Bus not being updated correctly, no changes to 6522 or TMS5220.

I'd also misunderstood how the TMS5220 accesses the PHROM's expecting them to be in a 256K memory region and positioned according to which bank is defined in the TMS6100, so the Acorn PHROM at offset 0x3C000 (accessed with SOUND-1) and the General PHROM at offset 0x00000 (accessed with SOUND-16).