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

Quote from: zhulien on 23:39, 07 February 18lambdaspeak is coming along really well, can't wait for a released version. I am guessing it will have dktronics and it's own modes as well as ssa1? can it make a cylon voice?

Thank you, we are getting there!  :)

The CPLD problem with the SSA1 |say command (the LambdaSpeak 2.0 breadboard prototype was loosing allophone bytes) just got fixed, thanks to Bryce, who pointed out that the VCCIO voltage  should not be at 5 V. With an additional voltage regulator on the breadboard that only supplies VCCIO it is working reliably now. So we are good to go with the final version wich will be designed by Bryce.

So far, we have no DKtronics emulation... honestly, I don't think it is worthwhile, because there is less software for DKtronics, and the SSA1 RSX driver is much better than what DKtronics supplied. We have SSA1 emulation. I have both an SSA1 and a DKtronics - BASIC programs that were written for the DKtronics can be ported easily to work with the SSA1 (and hence LambdaSpeak SSA1 emulation). I did that with my Eliza program, which was originally written for DKtronics:


https://youtu.be/aTxufTKfrYk

So, unless somebody comes up with an argument why DKtronics emulation is really important and a must have, we won't add it.

LambdaMikel

Quote from: Bryce on 08:52, 08 February 18At the moment only SSA-1 emulation has been done, but the long term plan is to have DKTronics emulation too. At the moment I am making some changes so that the firmware can be updated via a USB cable. That will allow for updates after the hardware has been released.

That's great! Yes, then we should add DKtronics emulation later on - or if people really want it badly, we can add it right away.

@Bryce - or mails / posts just crossed  ;D

Bryce

No, we just posted in parallel. I hope that with the USB port that we can still add more stuff (including DKTronics emulation) later. I know that it wasn't as well supported as the SSA-1, but all the hardware is there, it's just a matter of coding it, so it technically "for free".

Glad that fixed the SSA problem, there were probably voltage dips when the IO was loaded. The longer wires on the prototype would have made this problem worse too. It may not have happened on a final board, but it's good to know and means we need to keep an eye on the 3V3 current demand.

Bryce.

robcfg

Quote from: LambdaMikel on 08:53, 08 February 18
Thank you, we are getting there!  :)

The CPLD problem with the SSA1 |say command (the LambdaSpeak 2.0 breadboard prototype was loosing allophone bytes) just got fixed, thanks to Bryce, who pointed out that the VCCIO voltage  should not be at 5 V. With an additional voltage regulator on the breadboard that only supplies VCCIO it is working reliably now. So we are good to go with the final version wich will be designed by Bryce.

So far, we have no DKtronics emulation... honestly, I don't think it is worthwhile, because there is less software for DKtronics, and the SSA1 RSX driver is much better than what DKtronics supplied. We have SSA1 emulation. I have both an SSA1 and a DKtronics - BASIC programs that were written for the DKtronics can be ported easily to work with the SSA1 (and hence LambdaSpeak SSA1 emulation). I did that with my Eliza program, which was originally written for DKtronics:


https://youtu.be/aTxufTKfrYk

So, unless somebody comes up with an argument why DKtronics emulation is really important and a must have, we won't add it.


Well, thing is it would be nice to have Dk'Tronics support as to be able to use software intended for it without having to modify it first.


GUNHED

Congratulations to all the achievements!  :) :) :)


One idea: Wouldn't it be more easy to do an update from the CPC side? That would save the USB port and the principle of the CPC-Booster could be used. It's ATMega32 also can be updated from the CPC side.


(Ok, there may be few households with a CPC and no PC and special cable to do such an update, but it would just feel better to do everything with the CPC).


One could for example send an special code to the LambdaSpeak port and subsequently send the 'update' data.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Bryce

Quote from: GUNHED on 14:36, 08 February 18
Congratulations to all the achievements!  :) :) :)


One idea: Wouldn't it be more easy to do an update from the CPC side? That would save the USB port and the principle of the CPC-Booster could be used. It's ATMega32 also can be updated from the CPC side.


(Ok, there may be few households with a CPC and no PC and special cable to do such an update, but it would just feel better to do everything with the CPC).


One could for example send an special code to the LambdaSpeak port and subsequently send the 'update' data.  :)

It's a bit more difficult from the CPC side. For a start the update file is probably a lot bigger than on the CPCBooster and it means that the user first needs to get the file from the internet to their CPC and a CPC program is needed to flash it and possibly a jumper to put it into programming mode. The USB solution actually only needs 2 resistors and the USB socket, so it's not a major expense and the flashing software is already available for Windows and Linux etc. All you need is a standard USB cable, the entire process is much faster via USB.

Another "safety" feature is that the device can still be reflashed by the user even if the code on the AVR got corrupted during a failed update.

Bryce.

GUNHED

Some good points.  :)

However the ATmega644 has only 64 KB of Flash, which would fit on a DSK / Disc very easy. Ok, the update would take few minutes probably, but an update is not made very often. Also it doesn't matter if you download an update from internet to the PC or if you just download a DSK.

The big advantage of the 'update by using a CPC' solution would be that you don't need to add hardware. Just add a little function to the AVR code. So it's free of cost! :)

Also CPC users would be enabled to help in developing new / enhanced software for the AVR.

Of course you're right about the safety, that may be better to manage with an external cable, on the other hand just don't change a part of the AVR (one page) which contains the routine for the update process, this would render a CPC update save.

Surely you guys know what and how to do, just sharing my thoughts here. Maybe it can help.

It's an amazing project and I'm sure it will rock the CPC.  :) :) :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Bryce

The 644 doesn't have USB, I would be swapping to a different processor if I integrate USB updates. However, I doubt we would need more than 64K so extra program space in a bigger µP would probably never get used. Another issue with CPC update even for 64K is that it would be impossible from a bare 464.

CPC users could of course still be involved in AVR programming via USB, but I doubt the source code will be released, so either way this won't be a possibility. The updates would come as pre-compiled HEX files.

Bryce.

Edit: Before Michael gets a heart attack, that I'm thinking of swapping µP again. There is a USB solution for the 644 which would be also an option, using vitual USB firmware. (Which I think is what @gerald did on the C4CPC?)

gerald

Quote from: Bryce on 15:59, 08 February 18
Edit: Before Michael gets a heart attack, that I'm thinking of swapping µP again. There is a USB solution for the 644 which would be also an option, using vitual USB firmware. (Which I think is what @gerald did on the C4CPC?)
C4CPC use the AtMega32U4 which have a hardware USB 2.0 low/high speed device peripheral. It's a 32k flash part, with 4k reserved for the bootloader. It's SMD only and you can get it in smaller (ie less io) package or with16k flash.

zhulien

Quote from: LambdaMikel on 08:53, 08 February 18
So, unless somebody comes up with an argument why DKtronics emulation is really important and a must have, we won't add it.


If LambdaSpeak is using some type of FPGA or similar, then the only argument I have is that the SSA-1 and DkTronics are pretty much the same and all software could work on both if you change the port used in the software.  The same allophones etc are supported in both, they have a slight sound difference perhaps due to some type of filters used? That i am unsure.  If LambdaSpeak can cater for reading of both ports simultaneously then it would just work with all DkTronics software and SSA-1.

LambdaMikel

#110
Quote from: zhulien on 17:02, 08 February 18If LambdaSpeak is using some type of FPGA or similar, then the only argument I have is that the SSA-1 and DkTronics are pretty much the same and all software could work on both if you change the port used in the software.  The same allophones etc are supported in both, they have a slight sound difference perhaps due to some type of filters used? That i am unsure.  If LambdaSpeak can cater for reading of both ports simultaneously then it would just work with all DkTronics software and SSA-1.

Yes, both SSA1 and DKtronics used the same chip, the difference is in software mostly I think. The SSA1 driver has a real text-to-allophone synthesizer, whereas in DKtronics software you will have to work with allophones directly, or use some predefined words from a lexicon of fixed words - of course, this can just be ellivated by having a more sophisticated driver.

LamdaSpeak 1 could already decode a couple of addresses, for SSA1, DKtronics, and had its own native port address range which could be selected with a DIP switch. There were 3 dedicated wires from the address decoder to three ATMega inputs, which could then distinguish for which device (SSA1, DKtronics, native) the request was made.

The current LambdaSpeak 2 prototype breadboard has only one wire from the CPLD to one ATMega input, which is shared for SSA1 and native mode, and the current mode of the device is used to decide what to do with the IO request.

Bryce, we can support DKtronics, but I think it would be safer if we had a separate, dedicated wire from the CPLD for DKtronics IO address, since DKtronics and SSA1 are so similar in terms of protocol. With a shared wire from the CPLD, there is the danger that DKtronics software recognizes the SSA1 emulation, and vice versa, and then it will not work properly, as the protocols are slightly different.

So, if I can get one more track / trace on the PCB (I know, it is already a layout nighmare probably) we can do that.


Firmware side should be fairly easy, indeed. Almost copy and paste from SSA1 code, only the busy and load request bits etc. need to be set a little bit differently.

LambdaMikel

Quote from: gerald on 16:51, 08 February 18C4CPC use the AtMega32U4 which have a hardware USB 2.0 low/high speed device peripheral. It's a 32k flash part, with 4k reserved for the bootloader. It's SMD only and you can get it in smaller (ie less io) package or with16k flash.

That means it cannot hold more than 32k firmware? That would be too small for us indeed. Current firmware size is about 40 k. It's mainly the firmware image for the Epson chip that takes up most of the space in PROGMEM. LambdaSpeak driver itself is only 16 k or so.

zhulien

"The SSA1 driver has a real text-to-allophone synthesizer" are you sure that is done in hardware? I always thought that was software. If it is more than just letting all software not care which speech synth is present and working (since sending allophones to their individual ports just works the same), I would agree, not worth supporting the dkTronics, but... if it is almost no effort it can only be a good thing.  The CPC Wiki page says only Jump Jet works with DkTronics (I didn't even know that).  In the end, it is easy for software to support Lambda, SSA-1 and DkTronics anyway.

LambdaMikel

Quote from: zhulien on 18:19, 08 February 18"The SSA1 driver has a real text-to-allophone synthesizer" are you sure that is done in hardware? I always thought that was software.


Yes, with driver I mean the RSX DKtronics software. Neither SSA1 nor DKtronics have a firmware in the hardware, really (ok, the SPO256 chip has, but that is the same for both devices).


Bryce

Quote from: LambdaMikel on 18:03, 08 February 18
Bryce, we can support DKtronics, but I think it would be safer if we had a separate, dedicated wire from the CPLD for DKtronics IO address, since DKtronics and SSA1 are so similar in terms of protocol. With a shared wire from the CPLD, there is the danger that DKtronics software recognizes the SSA1 emulation, and vice versa, and then it will not work properly, as the protocols are slightly different.

So, if I can get one more track / trace on the PCB (I know, it is already a layout nighmare probably) we can do that.

:picard: We did have three seperate signals from the CPLD to the AVR, one for each mode. YOU told me to go to a one wire system.  :D In fact, I think my last version of the schematic probably still has them in. I think your reason was that scanning these inputs meant that the AVR wouldn't reply to the CPC fast enough.

Regarding Firmware in the originals. There were two versions of the DKTronics, one with the RSX's on a ROM in the device and one where you had to load them from tape.

As far as µP with 64K and USB is concerned, there's the ATxMEGA64aU4, which is the same footprint, but with 64K. However, it's a 3.3V part, so we may need to look at whether it would require any additional level-shifting for any of its i/o. @gerald: The final design has a TQFP µP because the EPSON speech chip is too.

Bryce.

LambdaMikel

Quote from: Bryce on 21:22, 08 February 18We did have three seperate signals from the CPLD to the AVR, one for each mode. YOU told me to go to a one wire system.   In fact, I think my last version of the schematic probably still has them in. I think your reason was that scanning these inputs meant that the AVR wouldn't reply to the CPC fast enough.

Right, seems I underestimated the desire for such a mode, and with only SSA1 mode and native mode there is no problem sharing the line.

Yes, I was against the idea of triggering / selecting the mode automatically based on incoming IOREQ(device), because changing the modes is not done so easily, i.e., the Epson needs to be reconfigured, and that can take a while. In the meantime, we will have lost the byte from the port, or it will make the firmware quite complex (i.e., buffer the bytes, then switch modes, ...) I didn't want to go there. This is why we said you have to select the mode with a control byte, and then LamdaSpeak is in that mode (SSA1, native, now: also DKtronics) until it is changed.

So, I still want to maintain the interal modes / states, but of course I can simply add the second line from the address decoder such that SSA1 and DKtronics can be clearly distinguished. Still, the mode has to be activated first, using some control byte, and not be selected automatically based on port address. (Well, maybe even this is possible, if the software first checks "in a friendly way" if DKtronics or SSA1 is present, i.e., by sending the 0 allophone or the like, as many games do, and then they check for the response on the port).

I'll do that  :)

LambdaMikel


Bryce

I'm not sure we need to yet. Let's check how similar the chips are and if we can blindly port the data over.

Bryce.

LambdaMikel

#119
Quote from: Bryce on 09:07, 09 February 18I'm not sure we need to yet. Let's check how similar the chips are and if we can blindly port the data over.


All right.

Btw, DK'tronics emulation is in. I have used another wire from the CPLD - PC5 (PC6 is reset, PC7 is native / SSA1 IO request). Interestingly, I have had a hard time using PC2 to PC5 as inputs - turns out JTAG debugging is enabled by default on the ATmega 644s I had bought! Took me a while to figure out how to disable JTAG in order to use these pins as ordinary inputs. All other pins are taken by now - only 3 PINC pins left.  :P

So far, I tested with my BASIC Eliza above which was originally written for DKtronics (for the video, I had ported it to SSA1). So, BASIC programs written for the DKtronics are working fine.

I still need to check the DKtronics ROM / tape software now... does anybody have a link to the DKtronics RSX driver on DSK?

http://www.cpcwiki.eu/index.php/Dk%27tronics_Speech_Synthesizer


has the tape and ROM only. Will test this weekend and post a video.

Bryce

Quote from: LambdaMikel on 18:41, 09 February 18



All right.

Btw, DK'tronics emulation is in. I have used another wire from the CPLD - PC5 (PC6 is reset, PC7 is native / SSA1 IO request). Interestingly, I have had a hard time using PC2 to PC5 as inputs - turns out JTAG debugging is enabled by default on the ATmega 644s I had bought! Took me a while to figure out how to disable JTAG in order to use these pins as ordinary inputs. All other pins are taken by now - only 3 PINC pins left.  [emoji14]

So far, I tested with my BASIC Eliza above which was originally written for DKtronics (for the video, I had ported it to SSA1). So, BASIC programs written for the DKtronics are working fine.

I still need to check the DKtronics ROM / tape software now... does anybody have a link to the DKtronics RSX driver on DSK?

http://www.cpcwiki.eu/index.php/Dk%27tronics_Speech_Synthesizer


has the tape and ROM only. Will test this weekend and post a video.

Don't you have a ROMBoard/MegaFlash type device to use the DKTronics ROM?

Bryce.

Gesendet von meinem Motorola DynaTAC 8000x mit Tapatalk


LambdaMikel

#121
Quote from: Bryce on 21:22, 08 February 18As far as µP with 64K and USB is concerned, there's the ATxMEGA64aU4, which is the same footprint, but with 64K.

Unfortunately, it seem XMega is a no go for me...
http://www.avrfreaks.net/forum/atmega-vs-atxmega
Would require almost complete reimplementation it seems.
All the features that I am using, TIMER, watchdog, interupts, SPI, ...
diable JTAG, ... will need to be rewritten.

So, we would have to stay with ATMega, no XMega please.

But I am open to discussion - is there anybody here who as ported ATMega code to XMega before? Basic IO is simple of course, but the other stuff... see above.


pelrun

How easy it is to port to a new microcontroller depends mostly on how you structured your code. I recently ported an AVR device over to STM32 and most of the work was in refactoring the original code to separate the hardware-specific implementation from the application code. Once that was done, providing an equivalent ARM implementation for the peripherals was relatively easy.


XMega is obsolete these days, and is full of hardware bugs - so it's probably better to consider another architecture if you decide AVR isn't sufficient.

pelrun

Alternatively, if the main problem is the flash is filled up with a ROM image for the EPSON chip (i.e. data that the AVR itself doesn't use), then how about adding a cheap serial flash ROM to hold it instead?

Powered by SMFPacks Menu Editor Mod