Dear diary,
Malban is learning.
Learning stuff he never thought he would, would need or even knew he did not know about.
The last couple of days he tried adding emulation for VecVoice.
- New here, implementing a serial communication 9600 baud 8n1. While he knew that his old US Robotix and Zyxel supported that communication, he never thought he would implement it himself in some form or another. The known vectrex speech devices communicate using that protocol via the joystick port.
- The only usable “source” of knowledge came from an old source code of Alex Herbert and – at least for him – these were confusing to get into. The actual communication as said is done via the joystick port. The joystick port on the other hand is not directly connected to an easily accessable vectrex device. The joystick port is connected to the sound chip and is reachable via register 14 of the soundchip. The soundchip on the other hand also can not be addressed directly, here one has to communicate via VIA.
So the actual communication goes like this:
– assume you want to tell the VecVoice device to receive the byte value “128” (IY)
– for that one must transfer 10 bits to VecVoice (8n1): 0 (startbit), 1000 0000 (data), 1(stopbit)
– the communiction with VecVoice is done via bit 4 of PSG Port A (that is the first button of the second joystick)
– so we must ensure that the above bit sequence is sent “through” that (PSG Port A-) bit, and each bit is held for about 156 vectrex “cycles”, this is roughly 9600 baud
– the thing that Alex came up with (and Malban didn’t know about, and which thoroughly confused him at first…):
in his code it looks like that the above said bit is set by using the PSG Port A enable bit in Register 7 of the PSG, which at first did not make any sense to Malban.
But probably the following is actually going on:
1) the output of PSG port A is initialized right in the beginning to “1110 1111”, this is a bit mask for bit 4
2) it seems that the PSG internally remembers that value for eternity if you do not actually CHANGE the output again
3) what I mean by that is: even when port A receives data (in input mode), once you switch to output mode, the above set “output” data reappears
4) when port A is in input mode the connected device (here our speech device) can still (sort of) read port A, after all – the cables are still connected – and what they
always seem to receive is: “1111 1111” – when port A is in input mode
5) so … using the above mask, you can change the status of bit 4 of PSG port A by “simply” changing PSG port A from input to output mode
6) that again is done by bit 6 of PSG register 7
7) (actually VecVoice expects the bits inverted, but since the enable register is zero active, which is sort of also inverted, the double invertedness cleverly resolves itself within the communication routine)
– so with that knowledge…
– select on VIA Port b to communicate with the sound chip (mux select->soundchip, mux enable, BDIR and BC1 to :latch ])
– set VIA Port a to the register you want to address (psg register 7, because we must read 7 befor we set anything, so we know what we must set)
– of the value we got from register 7 we set bit 6 to 0 if we want to send a “0” bit and to 1 if we want to send “1” bit
– write that value to VIA port A (which with mux select and enable goes to PSG)
– keep the latch to 7 and set in VIA port B BDIR/BC1 to write
– wait 156 cycles and repeat for the other 9 bits
– voila – you just sent 1 byte to VecVoice! - Malban has no intentions to emulate the hardware of the speech chips, all he ever planned was use samples and get some sort of coherent sampled output
- after implementing the above said serial communication the first barely conceivable speech from Alex demo program was heard
- but Malban was astonished, that Verzerk and YASI were totally garbled!
- THERE ARE TWO DIFFERENT DEVICES!
- Malban didn’t know that, call him ignorant or perhaps he has been dormant in the vectrex community for to long, but now he knows there are two different speech devices:
1) VecVoice, based on the SP0256AL speech chip (older)
2) VecVox, based on the SpeakJet chip (newer)
(both devices very conceived and developed by Richard Hutchinson) - luckily communication wise both use the same protocoll, but internally they are quite different and support a different set of phonemes
- for the SP0256AL I got some pretty good samples, for the SpeakJet the current samples I am using have same crackling noises 🙁
- Malban has not connected any of the speech devices to any of his hardware yet – he will do so as soon as he is able to
- the SP0256AL is pretty straight forward, and can be (in my opinion) emulated quite well using samples. Although in the meanwhile there DOES exist a correct software emulation of that chip, it was done by “Joseph Zbiciak” for his intellivision emulator and is now also used by the Mame/Mess team. But unless something serious happens, Malban probably will not port that code to java and use it. After all the SP0256AL is pretty old, and won’t be used for any future development tasks (and that is what Vide is about…)
- the SpeakJet on the other hand is quite up to date, still available and has many more advances features!
- the emulation of SpeakJet is rudimentary at best, especially as long as Malban is not able to listen to the real thing
- he started emulation of some of the more advances features (different pitches, time stretching, repeat etc), most of them are implemented, and the output DOES sound different than without changing anything… – but that is about it – different…
- he used a library called: TarsosDSP which provides methods to do pitch shifting, time stretching etc, it is pretty easy to use, comes with all sources and is licenced under GPL V3
- the thing is – while the library is great – it works much better with larger samples… The samples used for the phonemes are quite tiny, anything from 40ms to 700ms at most. These small durations are not handled well, since for the DSP processing frequency windows and overlaps must be found, and the search corridors within the library are also in about 20-50 ms. This makes the results somewhat “not quite so nice”.
- Anyway all these DSP processing, transfering data into frequency domains and back doing FFT etc. is also new. While Malban did learn the mathematical background years back at the university – he has not done that before… also something new…
Thats it for now…
The next step will be using the new emulation within vedi, to enhance possible future programs …
Regards
Vide