LambdaDrum progress & first demo

[zhulien]

you mentioned the LS had a serial port in the other thread, perhaps one of these can plug into it so you can play mp3s?


They really are cheap (about AU$4 each) and very available on ebay.  I just can't find documentation anywhere as to what commands to send them.  It would allow games to play mp3's via the serial port (play a track, pause, continue etc) - without any CPC CPU time... meaning we can have game packs. 




https://www.ebay.com.au/itm/1X-YX5300-UART-Control-Serial-MP3-Music-Player-Module-for-Arduino-AVR-ARM-P-E7R0/253972842282?epid=9009226204&hash=item3b21f6072a:g:iWwAAOSwcWJb5pPT


I just searched serial mp3 player and found this... i wonder if they are all the same.  last time i was searching for model numbers etc, and all i got was ebay sellers.


http://geekmatic.in.ua/pdf/Catalex_MP3_board.pdf

[Bryce]

Since this is the end of these threads, I wanted to thank @Bryce again for guiding me through the process! Without him, I would not have started with CPLDs (I was using GALs before), would not have known how to program them, and his "come on, this is not so difficult!" attitude pushed me to use the click text to speech board which requires a large MCU in order to be able to hold the Epson / Dectalk firmware image, which gets uploaded from the MCU into the Epson chip using SPI. In earlier version, I was using the Emic 2 text to speech board, which is self-contained and does not require this (it has its own MCU); hence, earlier versions were satisfied with the  ATMega 328p, compared to the large Atmega644-20pu which 64 KBs which is now being used.

Bryce will get a fully assembled LS 3.0 from me as a thank you.

Very kind words LambdaMikel, thank you. I'm glad I was able to motivate you to expand your knowledge and possibly effect future projects of yours too.

Bryce.

[zhulien]

i am imagining playing with a LS3.1? with serial port enabled and mp3 playback daughterboard - it sings a robotic voice with my own samples and drum arrangements playing over the top of the mp3 as well as AY beeps here and there, all coming through the CPC speaker (optionally) or through an Amp...  damn, the only missing thing is MIDI, but that's another possible use of the serial.  mp3 is more fun to imagine, and perhaps possible to patch Roland In Space to use actual Doctor'n the Tardis music.

[GUNHED]

IMHO LS3 is for anything related to speech, drum-kit stuff and samples. MP3 requires another technology - which is embedded very nice in the SF3 board. They can be used in team. 

[LambdaMikel]

Right, LS 3.0 is really final though... I am not making any changes anymore.

Regarding MP3 and Serial etc. - I thought about that. Problem for serial is that I would need another CPC port for receive port, and I do not have a single ATmega pin left! Otherwise I could just add it to the firmware and add RX, TX, GND to the PCB. But I won't.

If anything, for a next probject I would use the

https://www.mikroe.com/mp3-click
and use SPI, not serial.
In the other thread

http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/cpc-hardware-tinkering-platform/
I was musing about the idea of having a "mikrobus CPC hat" card for the CPC, with 3 or 4 mikro bus slots.

With at least two slots, one could also add some memory

https://www.mikroe.com/microsd-click

to the SD card. With three slots, one could add the text to speech module as well. But would require a large MCU again because of firmware image, adding a lot of complexity, and I don't want to go there. So how about the "blue pill" MCU STM32 board. I think that will be the next project, if any.

There is also a serial click board with proper DB9.

https://www.mikroe.com/rs232-click

And then, there must be a way to write SPI drivers and upload them to the firmware.

I think such a "mikrobus card" (with SPI and I2C support) and a controll MCU (STM32 blue pill) would be very fun. With plug in play of these little modules, people could easily reconfigure it for anything they need / like. OK, you must write a driver for the blue pill. But still - hardware development becomes plug and play from a hardware development point of view then, and hardware development turns into driver programming

[LambdaMikel]

PS And wrt to "singing via DECtalk and PCM drumming at the same time" - thought about that as well, and this is in principle doable with the current LS 3.0 hardware, BUT it is not trivial from a software point of view. Playing high quality PCM put a huge load on the CPU, and communicating via SPI with the Epson speech board over SPI in parallel would be tricky. But doable in principle... for now, there is in addition to the 4 PCM channels the channel 8, which is for the SPO256-AL2. It is easy to communicate with it whilst playing PCM samples, but it cannot sing obviously.

So, it is not impossible that it will "drum and DECtalk sing" at some point. But not this year.

Thanks for the idea though!! 

[zhulien]

IMHO LS3 is for anything related to speech, drum-kit stuff and samples. MP3 requires another technology - which is embedded very nice in the SF3 board. They can be used in team. 

I am sure the SF3 will be great, but for $4 to play mp3's on a CPC (if you already have an LS or MiniBooster) is pretty sweet.

[LambdaMikel]

I am sure the SF3 will be great, but for $4 to play mp3's on a CPC (if you already have an LS or MiniBooster) is pretty sweet.

... but why not get John's Usifac for that... then you can do it.

Btw, with the module above you gave the link, there is no way to upload MP3s to the card from the CPC!I have  bought a couple of these 3 to 4 $ cheap ones, and they all lack that capability AFAIK.

So, the CPC is just becoming a remote control for a cheap crap MP3 player 

If the card plays the music from its own storage / memory this is fine of course (and LS 3.0 also does that for PCM!), but AT LEAST it should be possible to upload into the card memory from the CPC. Here, you need to remove the SDcard and put it into your PC  Of course, even better would be if you could IN ADDITION to being able to send files to it from the CPC, also STREAM MP3 data from the CPC as well.

Also notice the title - UART *Control* Serial MP3 Music Player, it does not claim to be a UART SERIAL MP3 Music Playe.... 

[LambdaMikel]

This we could support with LS 3.0 - remove the databus segment bar (it has a socket!), and connect the remote control button to any databus from D7  to D0... then put it into "port echo mode", and turn the bit on with out &fbee,<byte> 
https://www.ebay.com/itm/REMOTE-CONTROL-FART-MACHINE-Whoopee-Cushion-Noise-Maker-Box-Joke-Prank-Sound-Toy/173770003817?hash=item28757fd569:g:fHAAAOSww5pbYfyU:sc:USPSFirstClass!94306!US!-1
(Actually, if you bitbang TX in that way using some databus bit / pin, then it might be possible to control that MP3 serial module as well; the only drawback is that you cannot read its replies with LS 3.0... maybe doesn't matter that much - I can try that for curiousity). So at least one could send serial data to it, but not receive any. As I said, we should be uing John's card for that.

And, to bitbang serial @ 9600 BPS or what such a MP3 module requires minimally also requires machine code... can't test that from BASIC.

PS Just thinking of it - you might just try to connect this MP3 module to the CPC printerport, and bit bang for serial TX control... that should also work, should it not?

[zhulien]

Btw, with the module above you gave the link, there is no way to upload MP3s to the card from the CPC!I have  bought a couple of these 3 to 4 $ cheap ones, and they all lack that capability AFAIK.


So, the CPC is just becoming a remote control for a cheap crap MP3 player 

That is correct but it isn't too bad, you have full control of playback and volume so with the games currently released on disc with bundled sdcard, wack the sdcard into the mp3 player.  Games can start the appropriate track at the appropriate time, can fade the music in and out by controlling the volume.  Easy to program, no CPU time.  For sure it has limited functions but it is supposed to work with existing MiniBooster and similar serial ports.

you need to remove the SDcard and put it into your PC  Of course, even better would be if you could IN ADDITION to being able to send files to it from the CPC, also STREAM MP3 data from the CPC as well.

Yes, and my megadrive should be able to automatically change cartridges also.  Still it is a very cheap option to add some nice musics to a CPC game even BASIC without any overheads.

[LambdaMikel]

Oh, that is interesting, I had no idea people are doing this... SDCards being released with Games.
(Since I am not that big in gaming - I backed the "Cosmic Force Cartridge" @ Kickstarter though,
for the first time!!)


I can think about serial a little bit more... okay, thinking aloud here... on a second thought, it *might* be possible with the current board... there are 2 ATmega controlled LEDs (RDY and TR). These could in principle become TX and RX for serial, when the "serial mode" is turned on (via a LS 3.0 control byte / command, as usual). One has to pull the 12 Bar LED Segment then (it is socketed). Stick 2 Dupont Wires in there.


One challenge is to do this without having to decode a second port. John's Usifac has a second control port. I am wondering if I could just design a "protocol" using the current LS "control byte" approach. I.e., to initiate serial transfer, send a control byte, number of bytes to transmit, and then the bytes. The bytes get buffered and transmitted via TR LED pin (line). Bits / bytes get received via RDY  at the same time and are being buffered by the ATmega for "later retrieval by the CPC". Then, a couple of control bytes / commands could be used to inquire the buffer status - how many bytes are available, and a command / control byte that initiates   flushing the bytes from the buffer to the CPC (using the same &FBEE port). Well, I really wish I had 2 more pins available on the ATmega, but I don't!


So yes, I think this would be possible with the current board, but I haven't tried it yet.

That scheme would only support half-duplex communication with the CPC though (internally with the serial, it could be full duplex).

It would be easy to add PIN headers for GND, RX, TX to the board (currently, one would need to pull the 12 LED Segment Bar, which is socketed).

Not sure I am going to do this though, but thanks for the suggestion!

And, @zhulien , a BIG THANKS to you again as well for suggesting the AMDRUM MODE!! I didn't even know about this.

[LambdaMikel]

...  all coming through the CPC speaker (optionally) or through an Amp... 

That was discussed before though, and the conclusion was that the SND pin is not meant to be force-fed with audio. So all cards that do that are doing something potentially harmful to the CPC if I understood correctly.


The SND pin is for (mono) output only, not for input. And for output, it is useless anyway, because of the audio jack, so no idea what that was meant for.


I added a Poll for that 

[zhulien]

i would use that if you had a feature at my own risk.

[zhulien]

documentation says "Sound (Mono Audio; Output from PSG). This is a mono audio signal generated by mixing the 3 PSG audio channels together."  - Does that mean it is a general sound line for any source that wants it but PSG for now is using it, or it is for PSG use only?


I read the documentation as just stating the fact that the output for the PSG is going to it.  There is no mention of exclusivity, not explicit or implied.

[GUNHED]

The SND pin is for (mono) output only, not for input. And for output, it is useless anyway, because of the audio jack, so no idea what that was meant for.

Well, first of all they had that pin, so they used it.    I assume that the SND out pin is for expansions which plug to the expansion port and produce their own sound / speech. This way there would be one common output. The disadvantage is that the great stereo feature of the CPC gets lot that way. Other computers are not that lucky anyway. *


* Quote from the Dictionary of the 'systems which suxx': In contrast to the wonderful ColorPC's from Amstrad - capable of playing stereo and using the PlayCity even Pink Floyds quadrophony other so called home computers are not equipped that well. The worst example regarding sound is the Commodore 64 which has only one sound channel and all his poor SID chip produces sounds like a chainsaw in liquid metal. Oh lord!

[LambdaMikel]

There is indeed still some space for a little header... and to my surprise, I still had 4 yet unassigned  CPLD pins. Now there is only one CPLD pin left. It is not that simple... the CPLD has to do some signal routing. RX and TX from the new 3-pin header go into the CPLD. Depending on the mode in which LambdaSpeak is, these get either routed to PD0 and PD1 (for RX0 and TX0) when in serial mode, or disconnected (High-Z). Since the pins PD0 - PD7 on the ATMega are usually already used for communication of CPLD -> ATMega (they are inputs), there is a clash between output for PD1 and input for TX0 when in serial mode. Hence, when in serial mode, the CPLD disconnects its PD0 to PD7 outputs completely (High-Z), and routes PD0 and PD1 via 2 more CPLD PINs internally to its 2 output PINs... And vice versa, these two more pins get disconnected when not in serial mode.
So, ATmega's PD0 / TX0 and PD1 / RX0 are being fed into 4 CPLD pins now, and CPLD has 1 more output (TX) and one more 1 input (RX).

So, for the protocol, the ATMega has to receive its "start serial input / output" control byte, buffer all bytes that have to be transmitted, then turn on the serial mode to tell the CPLD to change its internal signal routing, then the 2 TX and RX pin headers can be used for standard ATMega RX0 TX0 serial port. After all bytes have been transmitted or received, the ATMega turns of serial mode, and normal PD0 - PD7 port operation as inputs (outputs from CPLD) continues. I hope that the externally connected USART devices don't mind that TX / RX get disconnected (High-Z'ed) in between transmittions.

I haven't tested that yet. The board required some changes and it routes, and the equations also stil fit into the CPLD. Now I have to try it.

[LambdaMikel]

PS I will also try the SND input idea...

[LambdaMikel]

Thanks to @zhulien for being persistent in these issues.


https://youtu.be/E_u7NzCXM1k

Audio input into the CPC speaker indeed works. The final version will have 2 more DIP switches (so a 10 DIP instead of an 8 DIP); the 2 new switches allow to turn on and off routing the left resp. right channel into SND. I had to add 10 k Ohm resistors though. I checked the schematics, and this is also the resistor that is being used for the 3 channels for the AY internally. So it seems that these signal are simply being summed within the CPC (with the AY output), like in a standard summing OP amp. 

Next, I also tried the serial interface option - and that also worked, so I will also add the serial headers. I have implemented the new "serial" mode in the CPLD as described above, and as a test, I have connected the Emic 2 which is a USART device to that interface. The video shows that this works. Only transmission at 9600 BAUD tested so far, but I have no reason to believe the recieve and higher BAUD rates should not work. After all, this is the hardware USART in the ATMega, not software USART, so it should be pretty darn fast (up to 115 kbps as well). Good that the soldering iron hasn't gotten cold yet 

The PCB has already been rerouted and I should have a batch of new PCBs soon. In the meantime, I finish the firmware for serial transmissions using the control byte and buffering approach described above.

[LambdaMikel]

I'll test the MP3 board next.

[GUNHED]

The PlayCity also used the SND pin of the expansion port as entry. However it does not work with 464/6128 Plus computers. Only with the CPCs.
Maybe it could be helpful to see how Tot0 used this idea and which resistor he uses. But I guess you all know that already. 

[LambdaMikel]

I didn't look at the PlayCity, I just looked at the 464 schematics and the resistors in there. They are using 10k resistors, and that looks like a familiar summing op amp configuration (maybe there is an op amp in the cassette recorder).


The resistor values are still subject to some optimization, because the quality and distortation and gain etc. gets worse the more inputs are summed, and the resistor values in the CPC were calculated for 3 inputs to sum. Specifically the epson output is quite loud already and might need a bit larger resistor.


It is quite simple - as long as you have decoupling capacitors it is also safe (and LambdaSpeaks audio outputs have that obviously), and finding the right resistors works best with trial and error.

I don't have CPC PLus here, so I can't try that. I guess for that case it is good that you can disconnect the audio from SND with the 2 more DIP switches.

[LambdaMikel]

Update - the serial interface is working now, and the firmware is almost done.

I can communicate with with Emic 2 @ 9600 bps, 8N1, in both directions. I am using this as a test USART device. I have also ordered one of those FTDI cables for PC terminal test.

Looking forward to receiving the PCBs next week.



The interface will support up to 115 kps; there is also a 2x speed setting, more might be possible.

Since this is an "intelligent" interface, I will add commands / control bytes such as

- read bytes from USART until <bye> encountered (<byte> is an argument, might be CR or LF or... )
- read <n> bytes from  USART
- read bytes for <ms> milliseconds

etc. These commands, once invoked, are executed by the LambdaSpeak firmware, autonomously, and results get buffered, hence no CPU load at all for the CPC. The CPC then needs to retrieve the answer of course.

After that, the bytes are in a buffer, and one can retrieve the bytes from the buffer one by one by calling a control byte /command that puts it on the databus if there is still one available (there is also a control command for checking this).

Transmission work as follows: send the content you want to transmit, that gets buffered in the receive buffer. Then send the "start usart transmission" control byte / command, and the USART transmission is started.

It only uses on port, &FBEE.

[LambdaMikel]

Here ist a good find for all that wish to connect DB9-based legacy RS232 hardware to USART TTL:


https://www.amazon.com/gp/product/B07GP9SLCH/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1


Finally LambaSpeak can talk to my DECtalk... 

[TotO]

Yes, I have offered this adapter with the MiniBooster.
Your link looks to point an unavaliable item.

[LambdaMikel]

Yes, I have offered this adapter with the MiniBooster.
Your link looks to point an unavaliable item.

Upps, maybe I just bought the last one??

There are different options though:

https://www.amazon.com/NulSom-Inc-Ultra-Compact-Converter/dp/B00OPU2QJ4/ref=sr_1_2?keywords=NulSom+Inc.+Ultra+Compact+RS232+to+TTL+Converter+with+Female+DB9+%283.3V+to+5V%29&qid=1554746808&s=electronics&sr=1-2-catcorr


https://www.amazon.com/gp/product/B0088SNIOQ/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1


As long as they have
MAX3232
they should be good, right?

I am curious to learn if this will really work with my legacy hardware, since RS232 levels can be in range of -25 to 25 V... I hope that most devices will be fine with what that adapter can produce (is 5 V the max?)

I'll try this with my Amstrad NC100, the Tandy TRS80 Model 100, and of course my DECTalk.

Anybody knows more about voltage levels of existing DB9 CPC Serial Interfaces? Not TTL ones of course...