I've been tempting LGB to implement Speakeasy on his superb XEP128 emulator.
Hemm, I always feel puzzle because of the adjectives you use with Xep128
He likes very much the idea, but he sees some problems.
First of all, XEP actually doesn't emulate very well the Enterprise sound, needing to re-write great parts of the code.
And secondly, there are some legal aspects that must be pondered, because the chip inside the device maintains a copyright on the internal Rom and the algorithms used.
Indeed. But forgetting the "boring" legal problem: Xep128's main problem is about the (non-existing ...) sound infrastructure and sync with the emulation ... Audio currently is only a hack, and I am surprised a lot, that it more or less works without major glitches (ok, it can be noticed sometimes still ...) because of not sync'ed emulation of audio buffering/output etc. As any audio part related stuff *MUST* be rewritten in the future, I feel a bit useless to include more audio related stuff before this point. The second problem with this Speakeasy: that chip is a CPU for real it turned out. The ROM does not contain audio samples but actually instructions. OK, not a fully generic CPU as Z80 is, but still. Thus a very exact emulation would require to emulate its internals. And you must do it in *parallel* of the EP-related stuffs (ie, CPU/Nick/Dave, all needs to do "parallel" even if it means just call the handlers rapidly in the main loop for these emulation handlers). Just for a speakeasy, it simply does not worth to include another performance critical stuff in the main loop of the emulator, which would slow things down for every emulation, at by every Z80 opcodes executed (since currently that is the "elementary" time what Xep128 can emulate in "one step", Nick/Dave "ticks" are calculated from the executed CPU t-cycles - well it's not the most precise way, I guess for example ep128emu has the Nick slot frequency as the "basic timing factor" or such but the theory is similar after all, just the details are different).
So, the conclusion: I guess, from the view point for Enterprise-128 emulator, it is really not important *how* that chip works *internally*. The important factor, that EP softwares can use that hardware should work with the emulator, regardless how I implement it. Ie, just outputting values to printer port, that's all. So I can even have some tables with digitalized sound samples for the allophones so I would not emulate the chip's internals to generate those. This also solves licensing/patent problems of the algorithm used by the chip, and also it wouldn't slow down the main loop ("the heart") of the emulator. Then what I need are "only" these:
* sane audio infrastructure implemented in Xep128
* having the allophone sample table (probably with some extra data eg repeating points, or such?)
I really don't see the value to emulate the chip internals ... It would make sense if EP can *modify* the internal program executed by the chip, then yes, it would be needed ... But just to play sounds, it simply does not make sense to emulate at that low level of that chip. Of course, it's still an option to make (or use, eg the sources, you mentioned!) a close emulation of the hardware used to *generate* the wave table. But only that table is used by Xep128, which is already the raw sound output, and nothing more.