Cleaning Game Audio Files

Include new and ported/converted games, and old games/tools. Subjects about CP/M software goes in the CP/M Forum.
Bill B
Posts: 593
Joined: 26 Jan 2014 16:31

Re: Cleaning Game Audio Files

Post by 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.
Attachments
tape_clean_2.zip
(12.76 KiB) Downloaded 460 times
User avatar
Crazyboss
Site Admin
Posts: 274
Joined: 09 Aug 2012 21:45
Location: Sweden
Contact:

Re: Cleaning Game Audio Files

Post by 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 :)
//CLAUS - Webmaster at www.mtxworld.dk
User avatar
Dave
Posts: 1280
Joined: 11 Aug 2012 18:16
Contact:

Re: Cleaning Game Audio Files

Post by 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
Posts: 27
Joined: 21 May 2017 17:26
Location: Croydon, UK

Re: Cleaning Game Audio Files

Post by Pernod »

Bill B wrote: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.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
User avatar
Dave
Posts: 1280
Joined: 11 Aug 2012 18:16
Contact:

Re: Cleaning Game Audio Files

Post by 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
Posts: 593
Joined: 26 Jan 2014 16:31

Re: Cleaning Game Audio Files

Post by 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
Posts: 27
Joined: 21 May 2017 17:26
Location: Croydon, UK

Re: Cleaning Game Audio Files

Post by Pernod »

Bill B wrote: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.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
Bill B
Posts: 593
Joined: 26 Jan 2014 16:31

Re: Cleaning Game Audio Files

Post by 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
Posts: 27
Joined: 21 May 2017 17:26
Location: Croydon, UK

Re: Cleaning Game Audio Files

Post by Pernod »

Bill B wrote: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.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
Bill B
Posts: 593
Joined: 26 Jan 2014 16:31

Re: Cleaning Game Audio Files

Post by 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.
Post Reply