#142 Currah µSpeech emulation

open
nobody
None
5
2015-12-06
2007-08-29
No

The attached patch adds the beginnings of Currah µSpeech emulation. The SP0256 speech systhesis chip is not yet emulated -- the names of the allophones are written to standard output instead of being 'played'.

Unfortunately, as memory mapped I/O is used, this patch slows Fuse down slightly even when the interface is not enabled.

'uspeech.rom' is 'currah.rom' in Phil's ROM collection.

The SP0256 was also used in several other speech synthesis peripherals for the Spectrum:

* Cheetah Sweet Talker
* dk'tronics Speech Synthesizer (probably a rebranded * µSpeech)
* Fuller Orator (and Fuller Master Unit)

The Sweet Talker's demo tape (ftp://ftp.worldofspectrum.org/pub/sinclair/games/c/Chatbox.tzx.zip) contains a program written in BASIC which serves as limited documentation for that interface.

Related

Wiki: Fuse 1.2 Release Plan
Wiki: Fuse 1.2.2 Release Plan
Wiki: Fuse 1.3.0 Release Plan
Wiki: Fuse 1.3.1 Release Plan
Wiki: Fuse 1.3.2 Release Plan
Wiki: Fuse 1.3.3 Plan
Wiki: Fuse 1.3.4 Release Plan
Wiki: Fuse Next Release Plan

Discussion

  • Stuart Brady

    Stuart Brady - 2007-08-29

    Preliminary µSpeech emulation

     
  • Stuart Brady

    Stuart Brady - 2007-08-29

    Logged In: YES
    user_id=207506
    Originator: YES

    The second program on the Fuller & Orator demo tape (ftp://ftp.worldofspectrum.org/pub/sinclair/utils/FullerBoxOratorDemonstration.tzx.zip) also serves as documentation for the Orator. It seems it uses port 0x9f, and I think bit 6 might be used to specify intonation.

     
  • Philip Kendall

    Philip Kendall - 2007-09-01

    Logged In: YES
    user_id=29214
    Originator: NO

    Looks good to me once we get it outputting something useful. One very tiny point: any calls to abort() should use fuse_abort() which makes an attempt to restore the video mode; without this, the SVGAlib version leaves you without a working screen.

     
  • Stuart Brady

    Stuart Brady - 2007-10-03

    Timing emulation

     
  • Stuart Brady

    Stuart Brady - 2007-10-03

    Logged In: YES
    user_id=207506
    Originator: YES

    I've attached a new version which uses events. There's still no actual audio, but there are pauses between allophones. BTW, the abort() calls are in coretest.
    File Added: uspeech-2.diff

     
  • Stuart Brady

    Stuart Brady - 2011-05-07

    Update for changes in SVN head

     
  • Stuart Brady

    Stuart Brady - 2011-05-07

    I've attached an updated version, which applies to the head of the trunk. There are no changes in functionality.

     
  • Stuart Brady

    Stuart Brady - 2015-10-17

    I’ve attached a new version which actually works! It still needs some Fusification in places. As I intend to make Fuse more C99/POSIXy anyway, I’ve decided not to go too far down that path. The main thing left to do is to avoid the use of 64-bit integers and add as many of the other SP0256-based interfaces as is practical. Those that deliver an interrupt upon depletion of the FIFO will not fit brilliantly well into the model used in this patch. For these, it may be necessary to generate audio in small batches using an event.

     
  • Stuart Brady

    Stuart Brady - 2015-10-17

    Note: the sp0256_1.bin is a doubling of the sp0256-al2.bin file used in MAME with:
    CRC32 = b504ac15
    SHA1 = e60fcb5fa16ff3f3b69d36c7a6e955744d3feafc
    MD5 = c6fe422a12d834b34c54956782ec5f81

    The file expected by MAME is 2K long, whereas the code here expects a 4K file.

     
  • Fredrick Meunier

    Thanks Stuart, that sounds very interesting.

    There seems to be an official home of the so0256 al2 ROM here: http://www.spatula-city.org/~im14u2c/sp0256-al2/

    Can we use this ROM for this emulation? I don't have access to MAME ROMs so can't try out the code.

     
  • Stuart Brady

    Stuart Brady - 2015-10-18

    Thanks, Fred. The ROM on Joe Zbiciak’s web site that you have linked to is exactly the same, except that the ordering of data bits is reversed, i.e. d7↔d0, d6↔d1, d5↔d2 and d4↔d3. There’s code in jzIntv’s ivoice.c, where I got this from, for reversing the order of the data bits when loading the ROM, but this is effectively unused, given that jzIntv emulates an SP0256-012 with its own Mattel-specific ROM. The MAME version of this code, devices/sound/sp0256.c (now that MESS is part of MAME; formerly emu/sound/sp0256.c) lacks this reversal of the data bits. Given that MAME does emulate the SP0256-AL2 and even includes µSpeech emulation I think it’s best to avoid this reversal of bit order. There’s a posting by Joe which explains some of this which may be worth reading.

    I’m not sure whether the doubling up of the ROM’s content is accurate. The SP0256-AL2 datasheet refers to an 2K × 8-bit internal serial ROM (which it also calls a 16K[bit] ROM). The SP0256 can also use an external SPR016 2K × 8-bit serial ROM, and that datasheet for that makes mention of the “least significant 11 bits of the PC” and that “it is not necessary to load all 16 bits of address sequentially in one ASR load”, so perhaps we can safely make the same assumption about mirroring of the address space as we might make for a parallel ROM. I haven’t actually checked MAME’s behaviour, yet. If the file is only 2K long, the code in my patch will ignore the short item count returned by read() and the second half of the 4K ROM image buffer will be left as zeroes. This is one part of the code that we will want to Fusify, although we should avoid the usual ROM handling routines as these are geared towards images that map into the Z80’s address space.

    The version of jzIntv that I based this on is jzIntv 1.0 beta 4. This seems to be newer than the code that is currently in MAME. Note that the code in jzIntv is licensed under the GPLed (version 2 or later), but that the code in MAME is not. However, the code in MAME seems pretty much the same as an earlier version of that of jzIntv.

    Right now I’m only after feedback, but when I commit this, I intend to first commit a version of Joe’s original source with only simple modifications (reindenting / respacing, adopting POSIX types, replacing LOCAL with static, adding const, replacing iv/ivoice with sp0256), before committing the Fuse version of this code and adding it to Makefile.am along with µSpeech emulation, just as I would quite like to be able to see which parts we have modified ourselves.

    What is important though is that we remove the mask[] array from any version of Joe’s ivoice.c that we commit: it is large and specific to the SP0256-12, and it is not GPLed AFAIK.

     
    • Fredrick Meunier

      Thanks Stuart. I'm having problems using that approach - the page you link seems to say the expected ROM starts with 0x17 while the unswapped ROM starts with 0x38 but the one at Joe Zbiciak’s site starts with 0x07?:

      $ hexdump -C ~/Downloads/al2.bin | less
      00000000  07 de 07 e0 07 e2 07 e4  07 e6 07 e9 17 14 17 3f  |...............?|
      00000010  17 4c 17 5f 17 72 17 91  17 ad 17 ba 17 d2 17 ef  |.L._.r..........|
      00000020  17 fc 27 10 27 23 27 3b  27 77 27 9a 27 ab 27 bf  |..'.'#';'w'.'.'.|
      

      Any ideas what I am missing?

       
      • Sergio Baldoví

        Sergio Baldoví - 2015-11-29

        As I understand, the expected ROM starts with 0xE8:

        Hopefully my explanation about jzintv's ivoice_rdrom() and the above example make it clear "0xE8" is the right order. :-)

        But Joe Zbiciak is talking about the sp0256-012 model...

        $ hexdump -C sp0256-012.bin | head -3
        00000000  e8 bb e8 87 e8 17 e8 37  e8 f7 e8 8f e8 cf e2 d8  |.......7........|
        00000010  e2 9a e2 89 e2 dd e2 37  e2 2f ea 04 ea 54 ea 4c  |.......7./...T.L|
        00000020  ea d2 ea 8a ea 8e ea b1  ea fd ea 53 ea ab ea 47  |...........S...G|
        

        The sp0256-al2 in MAME starts with 0xE0...

        $ hexdump -C sp0256-al2.bin | head -3
        00000000  e0 7b e0 07 e0 47 e0 27  e0 67 e0 97 e8 28 e8 fc  |.{...G.'.g...(..|
        00000010  e8 32 e8 fa e8 4e e8 89  e8 b5 e8 5d e8 4b e8 f7  |.2...N.....].K..|
        00000020  e8 3f e4 08 e4 c4 e4 dc  e4 ee e4 59 e4 d5 e4 fd  |.?.........Y....|
        

        And the one at Joe Zbiciak’s site starts with 0x07...

        $ hexdump -C al2.bin | head -3
        00000000  07 de 07 e0 07 e2 07 e4  07 e6 07 e9 17 14 17 3f  |...............?|
        00000010  17 4c 17 5f 17 72 17 91  17 ad 17 ba 17 d2 17 ef  |.L._.r..........|
        00000020  17 fc 27 10 27 23 27 3b  27 77 27 9a 27 ab 27 bf  |..'.'#';'w'.'.'.|
        
         
        • Fredrick Meunier

          Thanks Sergio - I think that in summary it would be good for the documentation for the interface give some guidance on what is required to get the emulation up and running.

           
  • Stuart Brady

    Stuart Brady - 2015-10-18

    Another thing we could possibly do is remove the SPB-640 emulation from this code. It seems to have been sufficiently entangled with the SP0256 emulation that I thought better of removing it just yet. The SP0256 does have a single-decle FIFO but the 64-decle FIFO of the SPB-640 should have been factored out. It’s not clear to me how to emulate an SP0256 without the SPB-640 attached, though. I can well imagine that there’s logic within the SP0256 for communication with an SPB-640 and emulation of that logic may well be correct, even without an SPB-640 present in a device.

     
  • Fredrick Meunier

    HI Stuart,
    I think your proposed minimal plan to get the code ready to commit looks good (naturally we also need to get snapshot support in etc.)

    I don't think it is necessary to extract the SPB-640 code at this point - the peripheral is a bit obscure and unless some obvious harm can come of having it left in there I'd suggest leaving it in place.

     
  • Sergio Baldoví

    Sergio Baldoví - 2015-12-06

    I've been playing with this patch and looks brilliant. I think most other emulators use a set of dumped allophones rather than dealing with the SP0256 emulation.

    I've noticed lots of clicks and pops in the speaker and I wonder if you are having the same audio experience. I've recorded two samples:

    • token RUN, DELETE key, token CONTINUE
    • message from "Currah Microspeech - Side 1.tzx"

    https://www.dropbox.com/s/8qdeqatipcousys/uspeech_capture.tar.bz2?dl=0

    That seems to happen at the end of allophones. CPCWIKI states:

    Mind that completion of an allophone doesn't mute the voice generator (it'll keep repeating the end of the allophone until receiving a new allophone). To mute the voice generator, output a short pause (eg. PA1) after your last allophone."

    But I see a level 0 with some glitches. I've made another record from SpecEmu where there are some low sound, not sure if this is a repetition or a random noise, though.

     
    Last edit: Sergio Baldoví 2015-12-06

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks