L

LambdaSpeak Speech Synthesizer, Sample Player, RTC, MP3, Serial Interface, MIDI

Started by LambdaMikel, 08:56, 01 May 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

LambdaMikel

Good suggestion... maybe. When I started with this project, I was not aware of the motherx4. I can look into that for the next PCB that I will be making.

My PCB should arrive soon (tomorrow or so) - btw, I have also resolved the protocol issues by now. That means, I no longer need to shuffle in zero bytes and set the 8. bit of the payload data. One can simply send out a <byte> with "out &f9e<x>, <byte>" - and even without delay.

The price for this is that the 328 will now pull down *READY and put the CPC into wait state with that. Unfortunately, the connection between READY / WAIT and PB0 of the atmega 328 requires an extra cable since I had not anticipated this in the PCB design - I will just solder that cable on top by hand. The next version of the PCB will have that extra track  ;)

Now, that the protocol issue is resolved, I can also think about implementing a compatibility mode - in that mode, the idea would be that the "S = start of speech" and "<CR> = end of speech" tokens for the Emic 2 would not be required, but sent by the 328 automatically, on a time-based "speech pause" criterion. Given that SSA-1 and DKtronics work synchronous, but the Emic 2 asynchronous, there will still be a delay until it speaks, but it might work. I am not sure though if existing games (e.g., Roland in Time) are polling an input pin for ready, though. In that case, I would also have to provide a ready signal back-channel. The current solution doesn't do that. So, there might still be some more hardware changes required in order to support SSA1 and DK'tronics speech synthesizer compatibility. Stay tuned  :)

LambdaMikel

Aren't they pretty?  :D [attach=3]

Duke

Quote from: LambdaMikel on 20:04, 17 May 17
Aren't they pretty?  :D [attach=3]
The logo looks cool  8)

Only able to see one side, so not sure, but remember to make a fat vcc trace and gnd too (if you haven't done a gnd plane on the backside).

Bryce

The VCC traces look like they are about 5 or 6mil which can handle up to 700mA without a problem, way more than anything on the PCB will require.

Bryce.

LambdaMikel

Quote from: Duke on 20:15, 17 May 17Only able to see one side, so not sure, but remember to make a fat vcc trace and gnd too (if you haven't done a gnd plane on the backside).

Hmm, yes there is VCC and GND on the back, but it is not fatter than the other tracks - you are right, I should make them fatter, and maybe even backplane filled with copper, right? That's for v2 of the PCB, too  ;)

LambdaMikel

Quote from: Bryce on 20:26, 17 May 17The VCC traces look like they are about 5 or 6mil which can handle up to 700mA without a problem, way more than anything on the PCB will require.

Alright, in that case it should be fine  :)

Bryce

If you intend having more boards made, I'd probably go up a size or two for the VCC just to be on the safe side and definitely add a ground plane if you don't have one, but the current PCB will definitely work with traces that size.

Bryce.

LambdaMikel

Quote from: Bryce on 20:34, 17 May 17
If you intend having more boards made, I'd probably go up a size or two for the VCC just to be on the safe side and definitely add a ground plane if you don't have one, but the current PCB will definitely work with traces that size.

Bryce.

Thanks Bryce, for the next version I will be asking who else would be interested in purchasing one, and plan and change accordingly.

Cheers
Michael

LambdaMikel

The PCB's have arrived - and it is working!  ;D

At first I plugged it in, powered up the CPC - and nothing! CPC didn't even start up. After a while I had figured out that I had missalligned the IDC connector by one pin column when I had plugged it together  :doh: Here is a video of the first PCB version; it also shows the  additional cable for the WAIT / READY signal which I did not anticipate in the PCB: 

[/url]

Cheers,

Michael

LambdaMikel

One thing I always seem to struggle with is "clean soldering" - I mean the solder points all look neat with the magnifier glass, but the PCB looks "dirty" and "sticky" somehow. Is there a way to clean the PCB to make it look more neat after soldering? I am assuming that this is from flux / rosin core in the solder.

Bryce

Well you can use "no clean" solder, but it doesn't live up to its name, it should be called "less cleaning" solder. The best way to clean this up is to buy this: https://www.reichelt.de/Sprays-fuer-die-Leiterplatte/KONTAKT-361/3/index.html?ACTION=3&LA=2&ARTICLE=26015&GROUPID=4073&artnr=KONTAKT+361&SEARCH=%252A   or similar.

Bryce.

LambdaMikel

Thanks, will order something similar over Amazon here in the US... is it true that the PCB is really "eaten away" by the rosin core if not being cleaned properly like this?

||C|-|E||

Depends on the rosin, but many are actually really gentle with the PCBs. I have seen perfectly fine boards that were not cleaned for more than 40 years  :)  Regarding the cleaning, and since I have access to it for free, I like to use 100 per cent isopropanol, it works very well. I must confess that I tend to make the PCBs really dirty when soldering because I like to use quite a lot of flux, and it is the very traditional stuff. This is not necessary nowadays though, there are much cleaner products. It is just personal taste and familiarity with it, and I like the smell :)

pelrun

Fluxes are "temperature-activated acids", and are designed to be pretty inert at room temperature. It's only when you get up to soldering temperatures that they start dissolving oxides, and even then, it's the already "corroded" material that it removes, not the base metal. Cleaning is usually for aesthetic or electrical reasons - some flux residues are hygroscopic and may become slightly conductive over time, or they may affect impedance-controlled traces in sensitive RF circuits.

Bryce

With very high voltages or very accurate low voltages / high frequencies it's best to remove all the flux residue. For insensitive, low-speed 5V logic it really doesn't make a difference. The old fluxes were quite aggressive and PCBs didn't have solder mask back then, but with modern flux and solder mask it won't "eat" anything on the PCB.

Bryce.

LambdaMikel

That's good to know - I will try to clean it up a bit anyways, for nicer look.

LambdaMikel

Today, something interesting happened - the whole thing stopped working!  :o Checked all the chips, everything seemed to be fine. The AVR wouldn't start up - it turns out the 22 pF capacitors for the oscillator quartz were fried! I would never have thought that a capacitor would fail in such a circuit... must be extermely low grade, or maybe because the following thing happened (below). I replaced them with some higer grade capacitors, and it is working again - hope these will last longer!

I am now trying to make the microcontroller software work with speech games such as "Roland In Space". During that process, I connected my DD3 (in order to load the game) to the CPC expansion port connector holding the speech synthesizer, and it was perfectly blocking the display such that I couldn't see anything. Great design - I should have though about that. Maybe Bryce was right from the beginning and the whole board should not be so tall  :laugh:

I then tried to connect the speech synthesizer card with the flat band cable, similar to my breadboard adapter, and during that process I must have gotten the polarity of the cable / connector wrong.... Might that have blown the capacitors? Who knows. Anyways, I have figured out how to connect both the DD3 and the speech synthesizer to the expansion port by now (see screenshot), using a the breadboard adapter connector I had made, and I am now good to go to investigate how I can make "Roland In Space" speak  :P

I was intruiged to read that DK'tronics speech synth and SSA-1 have the same chip, but are actually not compatible... they use a different IO port. It seems that some games are supporting SSA-1, but only one or two DK'tronics. I can remember the Amsoft Pool / Snooker supported the DK'tronics (interestingly, that does not seem to be listed on the Wiki, but I can remember it speaking from playing it in 1986 with my DK'tronics). It shouldn't be difficult to support both IO ports (SSA-1:  out = in = &FBFE, DK'tronics: out = in = &FBEE). Output port and allophone translation shouldn't be such a big problem, however, INPUT might be.

And here is a question - does anybody know if the games such as Roland in Space would actuall read / poll the port to wait for the "ready" signal from the SSA-1 / DK'tronics? Or do the games just send the allophones slowly enough? I was hoping that I would not have to add this to the hardware, as it requires decoding of ~IOREQ & ~RD and, and, depending on SSA-1 or DK'tronics, I will have to indicate ready as follows:

SSA-1:

bit7   Status 1 (0=Speech Busy, 1=Ready/Halted)   (SBY Pin, Standby)
bit6   Status 2 (0=Ready to Receive Data, 1=Busy) (/LRQ Pin, Load Request)
bit5-0 Not used (garbage, probably usually high)

DK'tronics:

N/A    Status 1 (none, SP0256.Pin8 is not connected) ;SBY Pin, Standby
bit7   Status 2 (0=Ready to Receive Data, 1=Busy)    ;LRQ Pin, Load Request
bit6-0 Not used (garbage, probably usually high-z)

Maybe I will only support SSA-1... since this seems to be different. As I will have to buffer the allophone bytes anyways, and translated them, I can always indicate "ready" for the SSA-1 emulation, using 

bit7 = 1, bit6 =  0

Maybe this could just be "hardwired". However, does anybody know if the games really wait for ready and need this? I would be happy of not having to change the hardware.

gerald

Quote from: LambdaMikel on 05:51, 25 May 17
And here is a question - does anybody know if the games such as Roland in Space would actuall read / poll the port to wait for the "ready" signal from the SSA-1 / DK'tronics? Or do the games just send the allophones slowly enough? I was hoping that I would not have to add this to the hardware, as it requires decoding of ~IOREQ & ~RD and, and, depending on SSA-1 or DK'tronics, I will have to indicate ready as follows:

SSA-1:

bit7   Status 1 (0=Speech Busy, 1=Ready/Halted)   (SBY Pin, Standby)
bit6   Status 2 (0=Ready to Receive Data, 1=Busy) (/LRQ Pin, Load Request)
bit5-0 Not used (garbage, probably usually high)

DK'tronics:

N/A    Status 1 (none, SP0256.Pin8 is not connected) ;SBY Pin, Standby
bit7   Status 2 (0=Ready to Receive Data, 1=Busy)    ;LRQ Pin, Load Request
bit6-0 Not used (garbage, probably usually high-z)

Maybe I will only support SSA-1... since this seems to be different. As I will have to buffer the allophone bytes anyways, and translated them, I can always indicate "ready" for the SSA-1 emulation, using 

bit7 = 1, bit6 =  0

Maybe this could just be "hardwired". However, does anybody know if the games really wait for ready and need this? I would be happy of not having to change the hardware.
Roland in Space is indeed reading the port, the original software that came with the SSA1 boes it too.
Its the only way to have a proper synchronisation with the SP0256.
Some reading, if you did not already find it : http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-ssa-1-speech-synthesizer-rom-needed/msg4641/#msg4641

LambdaMikel

Thanks, this is helpful!


> Roland in Time expects the following sequence:
> - LRQ = 0, SBY = 1
> - write: LRQ = 1, SBY = 0
> - waits 18microseconds and then reads port: LRQ = 1, SBY = 1
> After this it has identified an ssa-1 and probably allows the allophone to complete and the final state:
> is back to LRQ = 0, SBY = 1.
>
> It sends allophone 0.

So I really need to create that pulse.
What trouble me is having to create LRQ = 1, SBY = 1.
It would be easier to simply toggle between 01 and 10.

LambdaMikel

... I will try to get the Atmega 328 to do the LRQ and SBY generation... I should still have 2 pins available. Only problem is that 328 doesn't have tri-state output. I had the same issue with READY / WAIT signal before - it seems the only way to put a pin into tristate (not connected) mode is to declare it as an input pin. It is possible to toggle the pin between input (not connected) and output (for 0,1) though, that worked for the READY / WAIT signal.

Anyways, that requires some hardware changes - so back to the breadboard for now... the new PCB (if this will work at all) will require a couple of changes:

       
  • make READY / WAIT signal a track instead of an extra wire on the current PCB
  • have 2 more tracks for LRQ and SBY
  • a headphone jack - the jack on the Emic is only good for headphones or powered amplifiers, whereas in fact, the Emic has a built-in amplifier which can drive a loudspeaker. These are the two remaining pins SP-, SP+ from the Emic board. I will connect to these.
  • use the 10 switch DIP more wisely - currently, it uses 2 switches for power supply for Emic 2 and AVR (for powercycling - hard reset), and 8 pins for the decoder line F9E<line> (0 - 7). That might be overkill. I might rather use 2 switches for mode selection (0 = Emic 2 native, 1 = DK'tronics, 2 = SSA-1), and then only use 6 switches for <line>, from 0 to 5 or so. For SSA-1 and DK'tronics, the IO address is fixed, anyways, so it would only apply for Emic 2 = mode 0.
  • make sure that the DD3 is visible... reduce height of board.
It would be nice if the headphone jack would just connect to the CPC built-in speaker... not sure that is possible though. The SND pin on the expansion port produces some audible sound if I put my finger on there, but I believe this is intended as output only, not input, or?

For the people that indicated interest in purchasing one of these speech synthesizers, I suggest to wait until the hardware is finalized and Rev. 2 is working ;-) That might take a while though... not sure if the synchronization / emulation of SSA-1 will work out at all to be honest. The good thing about having a microcontroller "on board" - it is mostly a software problem then  :laugh:

LambdaMikel

Quote from: LambdaMikel on 16:29, 25 May 17... I will try to get the Atmega 328 to do the LRQ and SBY generation... I should still have 2 pins available. Only problem is that 328 doesn't have tri-state output.

If it only was so easy  ;D One more catch - just putting bit 7 and bit 6 for LRQ and SBY on the data bus "when the AVR likes to" won't do it, because I will jam the bus - rather, I need to generalize the "IO address recognized & ~IOREQ & ~WR" into "IO address recognized & ~IOREQ"  = X and add two more gates: SPEECH_READ = X & ~RD and SPEECH_WRITE = X & ~WR. Then, SPEECH_READ will have to act as "output enable" of some tristate buffer... I will need one more chip. The AVR cannot get the CPC's bus timing right. Rather, it will provide the LRQ and SBY signals as inputs to the tristate buffer, which puts them on the bus when SPEECH_READ is encountered. That should do the trick, but requires one more chip (the tristate buffer) in the design.

The good thing about requiring one more chip is that I don't need to toggle the AVR pins between input (tristate) and output  (0,1) mode then. They can just stay in output mode.

Btw, if anybody has much easier idea of realizing this, please chime in!

LambdaMikel

Had some time this weekend, and upgrade the breadboard - the changes / additions described above seem to work.
I can successfull read values from the 74LS244 via BASIC INP(&F9E1), with its data set from from the Atmega 328.
Seems I am good to go to work out the microcontroller software part of this "SSA-1 compatibility mode"  :)
Attaching an image - the 74LS244 is in the upper right corner. I also moved the 74LS02 and 74LS08 to the right of the board.

LambdaMikel

A little update: by now, I have convinced the SSA1 speech software that the emulated SSA-1 is "operational".
It then proceeds by loading the RSX extension, and I can then issue commands like |say,@a$ which currently don't do anything, but there is also no error being reported, so it seems that the software is convinced that thre is an SSA-1 present.

I also have a plan now how to map the SPO256 Allophones from

http://www.cpcwiki.eu/index.php/SP0256_Allophones

into Emic 2 / DECTalk allophones "on the fly", using a look-up table, and I finally found the description of the DecTalk
allophone parser mode:

https://www.parallax.com/sites/default/files/downloads/30016-Emic-Epson-Fonix-DECTalk-501-Users-Guide.pdf



radu14m


LambdaMikel

Quick update: I can by now load the SSA-1 driver and also |say,@a$ works, but when Roland in Space starts up, it doesn't say "Amsoft proudly presents..." etc. The strange thing is that within the game itself, it IS speaking ("Time for tea" and similar). So it seems there are some issues with timing yet to be worked out. It is difficult to get the timings right with the AVR 328, given that it is not synchronized with the CPC clock.

Does anybody have any advice how to time LRQ and SBY signals such that it will also work for the Roland In Space title screen? It is strange that it works within the game itself and for the SSA-1 software, but not for the title screen.

Powered by SMFPacks Menu Editor Mod