Cleaning Game Audio Files

[Bill B]

Claus,

Thanks for bug report. Fixed in the attached version. The previous version would have worked if you had specified an output sample rate.

The difficulty with converting between .mtx and .wav files is knowing how long each block of data is. When converting to .wav you need to know where to insert some more audio lead-in. Conversely, when converting from .wav you need to know when the data stops, and the lead-in for the next block starts. I can do it in MEMU because the MTX ROM outputs a tape stop I/O instruction at the end of each data block.

It would probably be possible to do it for games saved with the standard MTX SAVE command. The required length information is then in defined positions in the data. For games with their own loader, rather more difficult. Perhaps the best solution might be a further option to MEMU to save a file in the other format at the same time as loading.

Bill.

[Crazyboss]

Great work Bill
will test it when I have time.

My games are standard loaders, but could it be possible to create a wave from a MTX. Could be easeier for me, cause now i have to load the file via the rememorizer and then save it to a wave. But it would be easier, if ether Memu could save waves, or it was possible to convert MTX to WAVE.

There are no checksum or any way the MTX knows if the data is loaded correct ? besides it dont run

Thats why I always included a checksum on screen for new games, so I know the wave is good

[Dave]

"But it would be easier, if ether Memu could save waves, or it was possible to convert MTX to WAVE. "

Claus, read my second post in this thread

[Pernod]

As those who were at Memofest 2016 know, I have created a version of Andy's MEMU that can load games from audio WAV files.

Is the source for this version available anywhere? I'd like to take a look to help get tape loading working in MAME.

[Dave]

The latest version of Bill's source files for MEMU for use with a Raspberry Pi are available on this page

http://www.primrosebank.net/computers/r ... memupi.htm

Regards
Dave

[Bill B]

Dave, Thanks for hosting this for me.

My code is currently based upon Andy Key's from a couple of years back. It does not contain Andy's latest enhancements (it will not run hextrain). It is also rather more Linux / Raspberry Pi specific.

However it does contain the following features:

• MTX serial I/O on real serial ports. So it is possible to build a proper NODE ring between computers. (Linux specific)
• Mapping MTX keyboard, printer and PIO ports to GPIO pins, see Dave's MTX-Pi. (RPi specific)
• VideoCore GPU acceleration of screen scaling. (RPi specific)
• Loading and saving WAV files. (Should be generic, but only tested on Linux (x86 & RPi)

The WAV file loading and saving works in exactly the same way as the real hardware, with audio edges clocking the emulated CTC, and pulses output on port 0x03. This means it works with a completely unpatched ROM (needs the -tape-disable switch to prevent the normal MEMU patching of the ROM). It also make use of the fact that, although never implemented in hardware, the MTX ROM supports automatic start and stop of the tape (using port 0x1F).

[Pernod]

The WAV file loading and saving works in exactly the same way as the real hardware, with audio edges clocking the emulated CTC, and pulses output on port 0x03.

Thanks for the info. I was hoping the MAME issue was something simple like only clocking the CTC on edges, but this was already in there. It simply doesn't acknowledge and cassette input, so need to look elsewhere for the issue.

[Bill B]

I don;t know whether it is relevant to MAME, but for MEMU, in order for the tape reading to work, I had to do some work on the Z80 emulation to make the CTC interrupt to the Z80 nearly cycle accurate.

As a consequence this version of MEMU is probably a bit slower than Andy's version. However, it did mean that I could eliminate the PANEL hack. The code for that is still present, but commented out.

[Pernod]

I don;t know whether it is relevant to MAME, but for MEMU, in order for the tape reading to work, I had to do some work on the Z80 emulation to make the CTC interrupt to the Z80 nearly cycle accurate.

In that case the Z80 could be issue, it is known to not be cycle accurate and I believe someone else is intending to improve this. This is also known to affect Spectrum emulation. I'll revisit the MTX when the Z80 improves.

[Bill B]

The timing does not have to be exactly cycle accurate, however the MTX tape input routine uses a Z80 busy loop to measure the time between CTC interrupts. If there is too much latency in the emulated interrupt response, then this timing becomes inaccurate, and cannot reliably distinguish between zeros and ones.