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

Hi Board,

using my CPC 464 breadboard adapter (see my other thread), I have implement a "next generation speech synthesizer" for the CPC which I wanted to share with you; it uses the fabulous Emic 2:



As you can hear, the speech quality of the Emic 2 is really nice... :smiley027: No complaints there - well, maybe one can complain about the price, which is a little bit high (about 60 $) :banghead: But I think it is worth it.

Besides the Emic 2, the other components in the design are: Atmega 328 for implementing a parallel (CPC) to serial interface, to bride from the CPC to the Emic 2; a 74LS373 flip flop, 2 G16v8 PLD's for address decoding and generation of the chip select signal, and some other gates. The hardware extension is at address &F9E1.

The speech synthesizer requires (almost) no driver, since the microcontroller and the Emic 2 are implementing an "intelligent" interface. The Basic program shown in the video is implementing a simple protocol, but basically, to talk to the speech synthesizer, one only needs to write bytes to port address &F9E1 (e.g., using OUT in BASIC). Interestingly, the interface from the CPC's parallel data bus to the Atmel was tricky to implement.

Cheers,
Michael

roudoudou

My pronouns are RASM and ACE

LambdaMikel


robcfg

Sounds cool! Does it support other languages or does it require a new rom?


Sent from my iPhone using Tapatalk

||C|-|E||

Hahaha, it is very nice! Regarding the languages, as far as I now, the Emic2 can talk in Spanish and English. You can also choose different types of voices, so it should be possible to do quite a lot of different things with it.

Kris


remax

Yes, I'd like to hear it, HAL. Sing it for me. ;D
Brain Radioactivity

LambdaMikel

... gosh... what have I done... yesterday I asked it Open the cassette player door, CPC and it wouldn't do it  :o

I will probably turn this into a PCB and hence a "real" CPC extension - it should be possible to produce this for 50 $ a piece or so, without the Emic 2 of course (there will be a plug-in header for the Emic 2).


XeNoMoRPH

your amstrad news source in spanish language : https://auamstrad.es

CraigsBar

I want one lol.

Sent from my ONEPLUS 3t using Tapatalk

IRC:  #Retro4All on Freenode

LambdaMikel

Quote from: CraigsBar on 00:56, 03 May 17I want one lol.

That's doable - when my PCB is ready, I can fabricate a couple and sell them assembled, with or without Emic 2 included. I will keep you all posted on the progress :)   Not sure how much time I will find in the next weeks to work on the PCB, though. Might take a while.

Cpcmaniaco


CraigsBar

Lol. Do is see this turning into an ongoing production run akin to the c4cpc and m4 boards lol.

Sent from my ONEPLUS 3t using Tapatalk

IRC:  #Retro4All on Freenode

Bryce

How compatible have you made it? What addresses is it mapped too and can it emulate either the DKTronics or Amstrad Speech synths? Those features would make it much more interesting as there are games that detected and used these.

Bryce.

LambdaMikel

That's a good suggestion, Bryce... since I am using PLDs for the address decoding, it is quite easy to let it listen to DKtronics and SSA-1 ports as well, without increasing the chip count. Maybe I can also add a little DIP switch for IO port selection.

With regard to compatibility - as far as the Atmel 328 programming is concerened, it should be possible to implement some kind of "byte to allophone" tables that could come close to what SSA-1 and Dktronics are doing (I actually own both). However, a bigger problem is timing and synchronization between the CPC and the 328. So far, proper communication requires a special "protocol" between the CPC and the 328. Basically, it needs Bit 8 from the databus to "clock" the data connection. I.e., to send the characters "AB" (65 66) to the 328 (which sends it to the Emic over serial), I am currently sending the bytes "193 (= 65+128) 0 194 (= 66 + 128)";  otherwise, the 328 was no able to reliably read the bytes with its IO ports (I got bitflips and all kinds of synchronization problems...) THe original idea was to simply use the chip select / address detected signal from the PLD's, and feed it into the 328 which would use it as an interrupt, and then read the byte from the databus. Didn't work. I am wondering if anybody else has encountered this problem, and has a potential better solution. The schema above is working quite reliably, but is also timing sensitive, since the data connection is "self clocked" in that way, and the 328 is, honestly, not the fastest, even though I am clocking it with 16 Mhz. So there needs to be some delay between sending the bytes, as well as zero byte in between payload bytes, for some reason. It turns out that the 328's INT0 interrupts was completely useless for implementing this "receiver", so I am currently just polling the IO ports of the 328 in a tight loop, buffering bytes as I am receiving them. At first I was just hoping the 328 could listen to the data bus directly, but these dreams were shattered early on in the project :-) Hence, I even had to add the flip flop to latch the data bus; something which I had though would not be necessary.

Bryce, if you have any ideas / experience on how to read bytes fastly and directly from the databus, without requiring the above "protocol" trick, please let me know! A bus driver or similar would probably also not make a diference; the flip flop that I have should be good enough for this.

So, to answer your question - it might be possible, but it's not too straightforward with the current design  :) I would first need to figure out how be able to directly buffer bytes from the data bus without requiring the "8th bit must be set" and "zero byte" protocol. If that should be possible with the 328, then it is also possible to emulate SSA-1 and DKtronics.

yannis_uno


LambdaMikel

Update: The board has been submitted to OSH Park for PCB production... 85$ for 3 boards (PCB only of course).
Fingers crossed that I didn't mess up with KiCad and that the PCBs work as well as the breadboard prototype.
I must say that this is my first "more complex" KiCad project. I will know more in a week when the PCBs arrive.

Cheers,
Michael



Bryce

Looks good. If you flip the emic2 header connector to the rear of the board (no layout change required), the emic2 would "fold back" on the rear side of the PCB and your board would be much smaller.

Bryce.

LambdaMikel

Right, thanks for the suggestion! We won't see the status lights of the Emic 2 then, but I guess that's acceptable if it can bring the size (and hence the price!) down considerably. Will try that and check if it reduces the price a bit.

Btw, I thought again about the DkTronics / SSA-1 compatibility idea - one other problem is that the Emic 2 always requires start and end byte for the speech,  i.e. "S", then the stream of bytes, and then Enter. If I recall Dktronics and SSA-1 correctly, then they only require the allophone byte, and they speak directly as they receive the byte, no buffering (on the hardware level). You might have to poll the port for "ready" signal. Hence, they don't require a start ("S") and end byte (Enter), unlike the Emic 2. That makes it difficult. When is the string "entered"? I could wait for a pause of x milliseconds in the stream of bytes and assume that the string is complete then (-> Enter), and prepare for the next string (-> "S"), but this seems to be an unreliable heuristics. Looks like DkTronics and SSA-1 compatibility is not that easy to achieve, given that the Emic 2 requires a different protocoal and start and end byte  :( I have made providions to the hardware though for chaning the IO port without programming, and supporting 2 different modes (DIP switches), as well a soft reset button in case the thing gets stuck. I'll keep thinking about it though, maybe another idea crops up. 



Bryce

Quote from: LambdaMikel on 14:49, 08 May 17
Right, thanks for the suggestion! We won't see the status lights of the Emic 2 then, but I guess that's acceptable if it can bring the size (and hence the price!) down considerably. Will try that and check if it reduces the price a bit.

Btw, I thought again about the DkTronics / SSA-1 compatibility idea - one other problem is that the Emic 2 always requires start and end byte for the speech,  i.e. "S", then the stream of bytes, and then Enter. If I recall Dktronics and SSA-1 correctly, then they only require the allophone byte, and they speak directly as they receive the byte, no buffering (on the hardware level). You might have to poll the port for "ready" signal. Hence, they don't require a start ("S") and end byte (Enter), unlike the Emic 2. That makes it difficult. When is the string "entered"? I could wait for a pause of x milliseconds in the stream of bytes and assume that the string is complete then (-> Enter), and prepare for the next string (-> "S"), but this seems to be an unreliable heuristics. Looks like DkTronics and SSA-1 compatibility is not that easy to achieve, given that the Emic 2 requires a different protocoal and start and end byte  :( I have made providions to the hardware though for chaning the IO port without programming, and supporting 2 different modes (DIP switches), as well a soft reset button in case the thing gets stuck. I'll keep thinking about it though, maybe another idea crops up.

Doesn't your board have a µP onboard that could add the S and Enter?

Bryce.

LambdaMikel

Quote from: Bryce on 10:13, 09 May 17Doesn't your board have a µP onboard that could add the S and Enter?

Thats right Bryce, but it is not clear when begin of speech (S) and end of speech should be shuffled into the allophone byte stream from the CPC. I can only think of a time-based criterion, like I said above: if no byte has been sent for the last x milliseconds, assume the input is complete. What you cannot do is send HELLO like this: S H <CR> S E <CR> S L <CR>.... etc. You will need to send S HELLO <CR>. THe SSA-1 and DkTRonics just require the allophone bytes for HELLO, and each allophone is output directly, no need for start and end tokens.

LambdaMikel

Being an absolute beginner with KiCad and PCB production, I wanted to summarize some of the errors I made  in that process such that other newbies can benefit from it - I actually had to generate the gerbers 5 times, because I was finding errors in the PCBs again and again - it was quite a humbling experience, but great fun also!  :) Here are some tips / hints, solutions to obstacles that I faced, and errors I made, hope it is helpful to others:

A. Eschema:

       
  • when you connect PINs to a bus, make sure that all your pins have labels, otherwise the bus doesn't know which line / track is going from where to where. The pin numbers and names on the chips / components are not sufficient for that.
  • many components have invisible GND and VCC. during electrical check, KiCad always complained about non-connected VCC and GND pins, even though I had global VCC and GND labels on the corresponding CPC expansion port pins! I tried to put global labels manually to these hidden pins, but to no avail. The right solution is the following, which required quite a bit of web research:  First, make sure that KiCad shows the invisible pins. Then, for a bus connector such as the CPC's expansion port, attach a global GND label to GND pins (there can be more than one such pin which gets that label - they will be connected then), and attach a global VCC label to the VCC pin. THis is still not enough, even though the hidden pins have global labels VCC and GND. Next, create and place a VCC and a GND label somehwere on the board, and find the "gnd" and "vcc" components from the component library. Connect them to the labels. This is still not enough to satisfy KiCad's electrical checker. Next, find the "powerflag" component from the library and attach one to each of VCC and GND just just placed on the board. Finally, KiCad thinks the 74x chips are powered and connected correctly  :P
  • Global labels are extremely helpful if you don't want connection all over the board. Just attach the GND or VCC global label and you are done.
  • Don't forget the rule check!
  • It is ok for KiCad to complaint about non-connected components, but carefully check all the errors and make sure that you did not forget any important connections.
  • KiCad is frequently updated it seems. Sometimes, they forget to include certain components. Believe it or not, but my installation didn't have the SW_PUSH little momentary push button in the library! I had to install and download the latest version of the KiCad component library. Likewise, other components might be missing from the standard libraries - in my case, the AMega328p and the Lattice GAL G18V8's. However, with a little bit of Web search I was able to find libraries for these. For the CPC edge connector, I didn't find anything on the Web, but had to create my own symbol and footprint. I could adapt and Apple 2 connector for this.
B. PCBNew and Gerber generation

       
  • Really make sure that that you set up the design rules (global and connection-specific!) correctly, before you start with the (auto) routing! Especially if you are using the metric system (mm), and have to convert OSHPark's inches-based design rules, make sure that you convert inches correctly into mm's... that should be straight forward, but in my case, I messed up by an order of magnitude, and the tracks where only one tenth in width of what they should have been  :doh:
  • When you import the Netlist, do the "Spread Out". This is only available if you Switch the View to "Standard View" in my version, not "Open GL". And also only as right mouse button context menu with Arrow Tools selected, and the Place Components mode is enabled. Took a while to find this option!! Without auto spread out, all components are messed up in a large pile stacked upon each other.
  • After spread out, place the components manually, using a reasonably fine or coarse grid to help with neat alignment. You will have to fiddle a lot with component placement, because of routing... I have used the built-in KiCad auto-router (not the external one which is a separate program), which is a great help IMHO and a great tool, but sometimes if fails to auto-connect everything. In my case, out of 100 connections, frequently there were 5 to 15 left which it couldn't route automatically. I would just play arround with the component placements, rotate and move them etc., and finally I got an auto-layout that would work. I would have needed days to do this manually. Many people say auto-router is not that good in KiCad and that they prefer to do it by hand, manually - in my case, I was very grateful for the autorouter, and I would not have succeeded without it  ;D
  • The auto-router works great IMHO, BUT it does NOT necessarily respect the board boundaries / cuts. Sometime, it placed tracks at the edge / board cut boundaries, and sometimes, tracks where even outside of the board outline! I then noticed that it was using space rather excessively, and I figured that it uses the GRID spacing / setting. I had previously set the grid to a coarse value, because it aids manual component placement (it is difficult to align them neatly if the grid is too fine), and I had to switch the grid to a finer resolution before re-running the router. This time, it stayed within boundaries.
  • Sometime, you will need to measure distances on the board. There is no ruler tool. However, you can hit space at current mouse cursor position, and this resets the delta difference distance display to zero, so you can measure distances relative from this point.
  • In order to remove failed or incomplete auto-route attempts, just use undo - Ctrl-z. Sometime undo is no longer an option, i.e., after you exited and restarted the session, and you found a bug in the layout. Then, use the arrow tools and select only the connections with rubberband / mouse rectangle (lasso) mouse selection. You can only select the PCB tracks and delete them, but keep everything else you worked on untouched (components, silscreens, edge cuts, ...) Extremely helpful. Then run auto-route again.
  • Sometime, you will discover a bug in circuit! Then, go back to ESchema, fix the schema / circuit, regenerate the Netlist. Go back to PCBNew. Re-read the netlist. ANswer yes to the dialog that informs you that your changes will be undone. Delete all the tracks using method described above (6). Auto-route again. Done. It could keep all but the PCB tracks.
  • Careful when you move components!! At first I was trying to get to a working layout by running autoroute, and then only move the components for which it wasn't able to route at first, and try running autoroute again after rearranging components a bit. This approach messes up your design completely, because the PCB tracks ARE NOT being move along with the components. Also, if you do this, then the next autorouter run will place connections on top of connections, etc. Whats worse, the DRC checker is not complaining about this  ??? So, don't try to run / stack partial auto-router layout on top of each other, it messes up everything!
  • Use the 3d Viewer to visualize your board. Sometimes, the 3d renderer complaints that it could not compute the board outline. This is bad! Then, go bad to PCBNew and delete the outline, and do it again. In my case, from double clicking, there were tiny yellow edge line segments that ("pixeldust") that were causing the trouble. Delete you old outline polygon and all partial outline line segments (pixeldust) and do a fresh, clean polygon outline "in one shot".
  • Do the Design Rule Check and fix any errors!
  • Don't trust the auto router - use the "Highlight Subnet" functionality and check every pin of each chip by clicking on it. It will highlight all the connected tracks and end points / pins. Found a couple of errors and omissions that way  :P
  • Gerbers. Do the plotting, make sure to enter the right track width according to the desing rules into the Generate Gerbers plotting dialog! Make sure to select the right layers (for Osh Park - Front and Back Copper, Front and Back Soldermask, Front and Back Silkscreen, and Board Cuts / Outline). Don't forget the drill file.
  • Really inspect you board thoroughly, also using GerbView... check that the tracks and VIAs are not microscopic and that they have decent width and size as you zoom in, and that the stay within the bounds of the board / edge cuts... wasn't the case for my first Gerbers  ???
  • For OshPark, you will then need to rename the generated files (see OshPark design rules page for KiCad and naming conventions! the extensions of the files need to be changed), zip it up, and transmit it.
I must say that this was quite a lot to learn, and lot to Google to find solutions to these little challenges I encountered on the way, and a bit of a painful learning experience - I was cursing and shouting a lot last Sunday when I made the first runs  :laugh: But then, also extremely satisfying when you get you board back and when it works... (hope it will). Overall, it is tremendous fun to use these sophisticated tools - it is incredible what we can do these days with powerful tools such as KiCad. A real feast for "makers".   

Hope this helps other newbies - would also be VERY interested in any comments / feedback from the senior hardware designers here, and what their process and tool stack looks like (Bryce?)  ;)

Bryce

All good tips. But there's also the lazy way... Some PCB manufacturers will accept the KiCAD files directly and they create the gerbers for you, then you've nothing to worry about :)

Bryce.

LambdaMikel

I guess that's also a matter or price, right? Do you have an estimate of how much such a service would cost for my PCB, Bryce. Just curious, maybe for next time - this time I wanted to learn how to do it. Maybe next time I can be more lazy  ;D

zhulien

any chance for motherx4 compatible versions?

Powered by SMFPacks Menu Editor Mod