Another "Bad Apple" demo

[PeteE]

19 hours ago, JasonACT said:

Yeah, it would be good to get a recording from a real TI with a speech synth attached so we can all set the "correct" sound level.

Here's a short clip of the ver 2.1 audio and speech from my NTSC 9918A console.  I had to truncate the cart ROM to 1MB so that it would fit on my FinalGrom99.  It does feel like the music audio overwhelms the speech.

 

 

 

Edited November 14, 2023 by PeteE
reexported wave as mono

[JasonACT]

1 hour ago, PeteE said:

It does feel like the music audio overwhelms the speech.

I agree, you made a good recording, the music is about the same level as both MAME and Classic99 when I play it back in VLC simultaneously, but the recording's speech is much louder than Classic99 and moderately softer than MAME.  It does feel like it's being overwhelmed.  Thanks for doing that.

 

@mizapf do you have any pointers on how to change MAME's speech volume level?

[+OLD CS1]

1 hour ago, PeteE said:

Here's a short clip of the ver 2.1 audio and speech from my NTSC 9918A console.  I had to truncate the cart ROM to 1MB so that it would fit on my FinalGrom99.  It does feel like the music audio overwhelms the speech.

It also sounds like the periodic noise channel might be 1/2 note off (standard issue between the 9919 and other derivative PSGs.)

[+mizapf]

4 hours ago, JasonACT said:

@mizapf do you have any pointers on how to change MAME's speech volume level?

This is normally done by the volume sliders in the OSD menu, "Slider controls".

[JasonACT]

26 minutes ago, mizapf said:

This is normally done by the volume sliders in the OSD menu, "Slider controls".

I see it, thank you...  I think the value 0.64 is a very close approximation for the speech volume level in MAME to match the real deal.

 

For me, the original PWM circuit has a 100 Ohm pull down & 220 Ohm feeding resistor, basically making it a third, but I knew that was too loud and replaced the 220 with a 470.  Then I replaced that with a 500 Ohm variable resistor (which I discovered today only really goes to about 420 Ohms and is still ever so slightly too loud).  I'm going to go back to the 470 Ohm, I spent years listening to the rocket noise & "Press fire to begin" in Parsec (pressing reverse to stop the rocket many times to hear the voice more clearly) and I think I'll be good with that value.

[Eric Lafortune]

Thanks for the experiments and feedback, everyone! I'll adjust the balance between the chiptune and the vocals based on the more accurate settings in Mame, and I'll fix the frequency of the periodic noise channel. For the latter, the SMS Power website has an extensive discussion of the SN76489, and the BBC Micro version of Bad Apple has the code that added the shift originally, which had escaped my attention.

[JasonACT]

On 11/13/2023 at 8:44 PM, JasonACT said:

When I precisely set my Pi Pico PWM audio code to 8000Hz to play back the speech, it runs too fast and I get lots of underflows.  Through trial and error, I've got it set to 7.5KHz playback and the demo runs nicely on a real NTSC console with my fake speech.  I'm not exactly sure what's going on

I've now spent some time on this, my logic analyser tells me the Pi Pico PWM is exactly (or as close as it can tell at 50MHz sampling, to) 8KHz.  Now, given I've got the Pico hooked up directly to the TI, I wrote a new DSR which measures microseconds fairly accurately, and given a TI BASIC program that loops while calling "CALL TEST" where the Pico prints the time-span from one VDP status read where the retrace has happened - to the next - I see some interesting numbers.

 

MAME has the screen going at 59.922738

 

My real NTSC console returns 2 numbers, mostly 16693 microseconds but sometimes there's an oddball 16671 microseconds reported.  These 2 numbers are reported fairly consistently, but if I hammer it (as much as you can with TI BASIC) then I do see some really odd numbers sometimes, but I'm fairly confident I can ignore them.

 

16693 uS = 59.905349 fps

16671 uS = 59.984404 fps

 

So, I think a real console does "try" to get 59.92 for NTSC through something happening in the TMS9918A chip, but it doesn't ever quite achieve it.  I think the doco also suggests it's close, but not perfect, too.

 

Given the speech synth has the delay line, if I were to produce a demo with long speech sections, I'd probably target a 59.9Hz VDP and let the synthesizer halt the machine when needed for the slightly faster real deal.  I also imagine a lot of 40 year old TIs are running refresh rates at fairly different numbers to original and even what mine is doing here.

[JasonACT]

@Eric Lafortune You may want to change your player code for the "Wait for VSYNC".  I'm not running my example from the scratchpad, but I suspect that would make it worse for the issue I see.  What I'm seeing on real hardware is missed frames, and I think it's because the status register sometimes (fairly often actually, once every 1.5 seconds) is being cleared by the VDP after you've read it, but the VSYNC has arrived in between.  I changed my code to set R12 to >0004 at the start and use "loop TB 0", " JEQ loop", " MOV @vdpsta,r3" which is actually quite a lot faster, and never misses the signal.  You will need to change your default for VDP register 1 to enable ints, so the TMS9901 sees it, but you don't have CPU ints enabled so it shouldn't be any different execution wise.  An emulator probably won't show this issue of course.

 

Anyway, I updated my call test routine to sample 180 frames (3 seconds) to check what my NTSC machine is really doing, there is a pattern the real TMS9918A uses to keep sync.  These are my findings for my particular machine's frame rate:

 

3003945 (16683) - 180 frames = 16688.5833r -> 59.9212036  *** Most often seen ***

 

3003934 (16683) - 180 frames = 16688.5222r -> 59.9214230
3003935 (16683)
3003942 (16682) - 180 frames = 16688.5666r -> 59.9212634598
3003943 (16692)
3003944 (16682)
3003944 (16693)
3003945 (16692)
3003948 (16697) - 180 frames = 16688.6 -> 59.9211437

 

vs MAME's 59.922738
 

First number is the Pi Pico uS time from when testing started.  The next number is the time from the previous frame (ignore that as it's meaningless in that summary) but in the following text it will make more sense.

 

  16692 (16692)
  33374 (16682)
  50067 (16693)
  66759 (16692)
  83442 (16683)
 100134 (16692)
 116816 (16682)
 133509 (16693)
 150201 (16692)
 166884 (16683)
 183576 (16692)
 200269 (16693)
 216951 (16682)
 233643 (16692)
 250326 (16683)
 267018 (16692)
 283711 (16693)
 300393 (16682)
 317085 (16692)
 333768 (16683)
 350460 (16692)
 367153 (16693)
 383835 (16682)
 400528 (16693)
 417220 (16692)
 433902 (16682)
 450595 (16693)
 467277 (16682)
 483970 (16693)
 500662 (16692)
 517344 (16682)
 534037 (16693)
 550719 (16682)
 567412 (16693)
 584104 (16692)
 600787 (16683)
 617479 (16692)
 634171 (16692)
 650854 (16683)
 667546 (16692)
 684229 (16683)
 700921 (16692)
 717613 (16692)
 734296 (16683)
 750988 (16692)
 767671 (16683)
 784363 (16692)
 801056 (16693)
 817738 (16682)
 834430 (16692)
 851123 (16693)
 867805 (16682)
 884498 (16693)
 901180 (16682)
 917873 (16693)
 934565 (16692)
 951247 (16682)
 967940 (16693)
 984622 (16682)
1001315 (16693)
1018007 (16692)
1034690 (16683)
1051382 (16692)
1068074 (16692)
1084757 (16683)
1101449 (16692)
1118132 (16683)
1134824 (16692)
1151516 (16692)
1168199 (16683)
1184891 (16692)
1201574 (16683)
1218266 (16692)
1234959 (16693)
1251641 (16682)
1268333 (16692)
1285026 (16693)
1301708 (16682)
1318401 (16693)
1335083 (16682)
1351775 (16692)
1368468 (16693)
1385150 (16682)
1401843 (16693)
1418525 (16682)
1435218 (16693)
1451910 (16692)
1468592 (16682)
1485285 (16693)
1501977 (16692)
1518660 (16683)
1535352 (16692)
1552035 (16683)
1568727 (16692)
1585419 (16692)
1602102 (16683)
1618794 (16692)
1635477 (16683)
1652169 (16692)
1668861 (16692)
1685544 (16683)
1702236 (16692)
1718929 (16693)
1735611 (16682)
1752304 (16693)
1768986 (16682)
1785678 (16692)
1802371 (16693)
1819053 (16682)
1835746 (16693)
1852428 (16682)
1869120 (16692)
1885813 (16693)
1902495 (16682)
1919188 (16693)
1935880 (16692)
1952563 (16683)
1969255 (16692)
1985937 (16682)
2002630 (16693)
2019322 (16692)
2036005 (16683)
2052697 (16692)
2069380 (16683)
2086072 (16692)
2102764 (16692)
2119447 (16683)
2136139 (16692)
2152832 (16693)
2169514 (16682)
2186206 (16692)
2202889 (16683)
2219581 (16692)
2236274 (16693)
2252956 (16682)
2269649 (16693)
2286331 (16682)
2303023 (16692)
2319716 (16693)
2336398 (16682)
2353091 (16693)
2369783 (16692)
2386465 (16682)
2403158 (16693)
2419840 (16682)
2436533 (16693)
2453225 (16692)
2469908 (16683)
2486600 (16692)
2503282 (16682)
2519975 (16693)
2536667 (16692)
2553350 (16683)
2570042 (16692)
2586735 (16693)
2603417 (16682)
2620109 (16692)
2636792 (16683)
2653484 (16692)
2670177 (16693)
2686859 (16682)
2703551 (16692)
2720234 (16683)
2736926 (16692)
2753619 (16693)
2770301 (16682)
2786993 (16692)
2803686 (16693)
2820368 (16682)
2837061 (16693)
2853743 (16682)
2870436 (16693)
2887128 (16692)
2903810 (16682)
2920503 (16693)
2937185 (16682)
2953878 (16693)
2970570 (16692)
2987253 (16683)
3003945 (16692)

 

Anyhoo, that's enough from me.

[JasonACT]

3 hours ago, JasonACT said:

Anyhoo, that's enough from me.

Clearly not.

 

Assembling the player .asm code with my suggested changes, and cut & pasting those [byte] changes into the NTSC ROM image, has it playing perfectly on my real machine even with the slightly wrong MAME timing, with my speech at 8KHz.  Absolutely awesome, thanks again!  It plays perfectly on Classic 99, except for the speech volume, which is very low...

 

MAME craps out, it speeds through the demo at full speed.  I don't think the TMS9901 CRU read for the VDP interrupt line is implemented (properly?).

 

I prefer not to use emulators though, so I don't have the source code to check on that one.  (But thanks for your speech .dll @Tursi - that was a time saver.)

 

EDIT: more testing on MAME, it almost works, but still had issues slowing down in the middle with the speech???

Edited November 17, 2023 by JasonACT

[Eric Lafortune]

Thanks for the experiments. The recent video tools already had a small epsilon on the Vsync frequencies to account for potential minor timing issues -- that may have helped.

 

I hadn't seen the CRU polling technique before, to wait for a vsync -- only the VDP status polling technique. After some searching, the advanced copper demo and XB GEM do turn out to use the former. I don't yet understand how VDP status polling can miss vsyncs. In practice, I rely entirely on Mame for development. Maybe CRU polling followed by VDP status polling would work on all systems/emulators.

[JasonACT]

6 hours ago, JasonACT said:

and I think it's because the status register sometimes (fairly often actually, once every 1.5 seconds) is being cleared by the VDP after you've read it, but the VSYNC has arrived in between.

I really have no idea why it's missing them, I only know that I have a very precise (and basically a fully current) piece of hardware attached to an ancient machine here, and running the code used in your player often completely misses an entire frame...  That is devastating to the speech production.  The output from the Pico says 33ms for a frame every 120 or so - and it isn't making any mistakes, because the timing is based off a memory write @>5000 into DSR RAM I have set up.  The TI just didn't see it for some reason.

 

I also don't know why MAME behaves differently.  But it has given me far more random issues than I would expect in my tests.

 

EDIT: not every 120 frames, but around 80, in fact.

Edited November 17, 2023 by JasonACT

[+mizapf]

7 hours ago, JasonACT said:

I don't think the TMS9901 CRU read for the VDP interrupt line is implemented (properly?).

Should be. I mean, it would fail in countless situations if it were not.

 

I'm not sure whether I can assist you effectively in your search. Maybe you should consider pulling the source codes of MAME and building it with debug outputs so that you can possibly add even more output at the relevant positions. I could point you to the respective locations in the code.

 

Just to rule out the obvious: The emulation runs at 100%, I hope. When you stop the emulation, do you get the report about 100% emulation speed in the console where you started the emulation? If not, the whole timing is unreliable.

 

[Eric Lafortune]

I've tested it myself in the demo now: the reading CRU bit 2 for the VDP interrupt works fine in Mame. That's more in line with my earlier experiences and expectations; it's amazingly accurate software. I'll apply this technique in the next updates of the video tools and the demo.

[JasonACT]

3 hours ago, mizapf said:

Just to rule out the obvious: The emulation runs at 100%, I hope. When you stop the emulation, do you get the report about 100% emulation speed in the console where you started the emulation? If not, the whole timing is unreliable.

No, not always.  I saw 99.94% on one run of the demo where the speech didn't break up.  I also saw 100.00% on a run where the speech did break up.

 

Just FYI: I'm using the 250 Gamebase version of MAME, I wouldn't know how to build my own version for Windows.

 

2 hours ago, Eric Lafortune said:

it's amazingly accurate software.

The speech usually breaks up for me at the part where the bowl breaks, sometimes works, sometimes doesn't work.  I do feel like the beeps and honks you get out of MAME on the title screen & selection screen when pressing random keys are delayed quite a lot compared to a real console.  On the "Press 1 for TI BASIC" screen, a real console will honk as you press the spacebar, MAME has a noticeable delay, if you have both going on the workbench at the same time.  I don't think that's an issue though.

[JasonACT]

6 hours ago, mizapf said:

Should be. I mean, it would fail in countless situations if it were not.

I agree, apologise and retract my comment.  I've run it now many, many more times and it hasn't gone berserk (run at high speed) a single time since that first run.  It might be time for me to buy a new PC.

 

I've also been running the unmodified new NTSC version and I sometimes (I feel it's much less often) see it slow down and hear garbled speech.  I thought it might be because the MAME window opens at the largest size on my 4K monitor, but even with resizing the window to be far smaller, the original sometimes has issues with the speech.

 

I've also run it (too-)many times on my real TI now, my modified version hasn't had a single issue at all.

 

Shrug.

[+arcadeshopper]

6 hours ago, JasonACT said:

No, not always.  I saw 99.94% on one run of the demo where the speech didn't break up.  I also saw 100.00% on a run where the speech did break up.

 

Just FYI: I'm using the 250 Gamebase version of MAME, I wouldn't know how to build my own version for Windows.

 

The speech usually breaks up for me at the part where the bowl breaks, sometimes works, sometimes doesn't work.  I do feel like the beeps and honks you get out of MAME on the title screen & selection screen when pressing random keys are delayed quite a lot compared to a real console.  On the "Press 1 for TI BASIC" screen, a real console will honk as you press the spacebar, MAME has a noticeable delay, if you have both going on the workbench at the same time.  I don't think that's an issue though.

you don't need to build your own, it's on whtech..  under https://ftp.whtech.com/emulators/MAME/ti99/ for the ti99 only build.. or if you want the full go up a folder

[+mizapf]

I won't dare to say that there can't be any weird errors at rare occasions. I had them all over the years in MAME, many of them due to uninitialized memory or misunderstanding on my part about the expected behaviour. When it is reproducible, we may have a way to track the error.

 

Execution speeds of >99% are perfectly fine; when you get 99.9% instead of 100%, it may have missed probably one deadline, which should not affect anything. Even with fast machines, you may sometimes get 99% or so, particularly when there are lots of floppy operations. (This is one of the heaviest operations in MAME.)

 

You can always control output size by setting the window parameter to 1 in mame.ini and setting the resolution to the desired size. Or you can provide that by the command line, like "-window -resolution 1280x960".

 

I can put some more information about building MAME for Windows on Ninermame.

[JasonACT]

I've made one more change to the player.asm code here, for the no-speech menu item, I load R11 with >4000 instead of clearing it...

 

https://www.unige.ch/medecine/nouspikel/ti99/eeproms.htm

 

Quote

The OE* (output enable) will generally do fine with the CS1* signal, since the on-board circuitery should only enable the CS1* pin for reading operations. However, sloppy design is a fact of life, and some cards may enable the ROM for write operations also (most notoriously: the TI99/4A console does).

Quote

Finally, TI did not do a very good design job whith the ROMs: these chips answer both read and write operations! 

I.E. Writing to console ROMs causes them to output data on the 16 bit data bus at the same time the TMS9900 is also outputting data - possibly reducing the life of the console.  >4000 should be fine, as no DSR ROM will be active.  He goes on to say this, so it's not an uncommon mistake to make...

Quote

NB I strongly recommend that you install this switch. Initially I didn't do it and I found out the hard way that many programs do dummy writes in the ROM area (often at address >0000) and mess up the EEPROM.

 

[Eric Lafortune]

I'll include it in the next update, thanks.

[Eric Lafortune]

I'm preparing a new release of the demo. Sorry about the delay; I've already been distracted by a new project (a 2.5D game, building on similar ideas).

 

@OLD CS1 mentioned that the periodic noise channel might be 1/2 note off, but I can't figure that one out, or hear it with my untrained ears. The demo is based on the source VGM file of the BBC Micro version (on Github). It should correspond to the audio version of their composer (on Bandcamp). In their demo, they process it for the 4 MHz clock and the 15-bits noise shift register of the BBC Micro. I'm just using the unprocessed sound data. The VGM header states that it is targeted at a 3.579545 MHz (NTSC) clock and a 16-bits noise shift register. That should be exactly right for our TI. Does anyone know what I'm missing?

[+OLD CS1]

3 hours ago, Eric Lafortune said:

The VGM header states that it is targeted at a 3.579545 MHz (NTSC) clock and a 16-bits noise shift register.

Our TMS-9919/SN76489 variant is a 15-bit shift register for the noise channel.

 

https://www.smspower.org/Development/SN76489#TheLinearFeedbackShiftRegister

 

Sadly, I tried converting the VGM to an ISR list for me to play with, but it is too complex for my script to output a good recognizable list.

[Tursi]

Well, I wrote literally 42 helpers for converting, massaging, and mangling VGM (and other audio) files, so let me have a quick play. They'll handle the noise pitch conversion for you or let you do it manually, and if you don't want to use my compressor the final intermediate format is a simple text file that should be easy to pack into whatever you are using.

 

https://harmlesslion.com/software/vgmcomp2/

 

The VGM unpacker informed me one potential issue with re-tuning the noise:

Quote

 

D:\new>d:\work\ti\vgmcomp2\release\vgm_psg2psg.exe bbcapple-palsms-3_2.vgm
Import VGM PSG - v20201001
Reading bbcapple-palsms-3_2.vgm - 118931 bytes
Reading version 0x150
Refresh rate 50 Hz (882 samples per tick)
Selecting 16-bit shift register.
File 1 parsed! Processed 12400 ticks (206.666667 seconds)
Adapting user-defined shift rates...
Song employs user-tuned noise channel, but both noise and voice are audible.
Noise and voice will be at different shift rates and one may sound off. Use
a 15-bit noise channel if your tracker supports it!
0 notes tuned.

-Writing channel 1 as bbcapple-palsms-3_2.vgm_ton00.60hz...
-Writing channel 2 as bbcapple-palsms-3_2.vgm_ton01.60hz...
-Writing channel 3 as bbcapple-palsms-3_2.vgm_ton02.60hz...
-Writing channel 4 as bbcapple-palsms-3_2.vgm_noi03.60hz...
Skipping channel 5 - no data
Skipping channel 6 - no data
Skipping channel 7 - no data
Skipping channel 8 - no data
done vgm_psg2psg.

 

It seems like that's true only in selected parts though, as I test play it. (The 0 notes tuned output there is a bug, it still retunes all the noise). (Note it also converted the 50hz original for 60hz playback).

 

My default converter in that case will keep the channel 2 frequency and map the noise to the closest fixed shift rate, so I went ahead and tried that out... 

Quote

 

D:\new>d:\work\ti\vgmcomp2\release\prepare4SN.exe bbcapple-palsms-3_2.vgm_ton00.60hz bbcapple-palsms-3_2.vgm_ton01.60hz bbcapple-palsms-3_2.vgm_ton02.60hz bbcapple-palsms-3_2.vgm_noi03.60hz bbcapple.snpsg
VGMComp2 PSG Prep Tool - v20201006

Opened tone channel 0: bbcapple-palsms-3_2.vgm_ton00.60hz
Opened tone channel 1: bbcapple-palsms-3_2.vgm_ton01.60hz
Opened tone channel 2: bbcapple-palsms-3_2.vgm_ton02.60hz
Opened noise channel 3: bbcapple-palsms-3_2.vgm_noi03.60hz
Imported 12400 rows
8206 custom noises (non-lossy)
43 tones moved   (non-lossy)
9785 mutes mapped  (non-lossy)
4 tones clipped (lossy)
3931 noises mapped (lossy)
** DONE **

 

So we can see that 3935 notes out of 8206 may have changed. If they are drum beats, we probably won't notice. If they aren't, we probably will.

 

It's good for a little while, but about halfway through the song there are some long notes on channel 2 AND some long notes on the custom noise channel... and changing them to non-custom as the converter wanted to did not work. (Around 1:24). 

 

 

This is a bit of a tricky case. Most of the song is fine with the fall-back to fixed rates. But those places absolutely are not. So it would be necessary to either mute the noise channel during those areas, or deliberately detune channel 2, or live with the detuned noise. I don't know if there's a happy medium there.

 

My tools would allow the detune of channel 2, and then overlay 2 onto the noise channel so that the prepare tool can make the right decisions.

 

D:\new>d:\work\ti\vgmcomp2\release\scalepitch.exe 1.066667 bbcapple-palsms-3_2.vgm_ton02.60hz
VGMComp2 Pitch Scaling Tool - v20210707

Opened channel 0: bbcapple-palsms-3_2.vgm_ton02.60hz
Imported 12400 rows, scaling by 1.066667
0 notes clipped (lossy)
0 notes zeroed (lossy)
Writing: bbcapple-palsms-3_2.vgm_ton02.60hz
** DONE **

 

But this was really really bad and immediately wrong, though, as soon as channel 2 kicked in.

 

So I think the only answer, if using this source, would be to let the noise be slightly detuned during those long stretches. It would be correct everywhere else. There appears to be no need to mess with channel 2 vs 3 anywhere but those long sections, but that would require hand editting of the psg files to cut out just the parts to edit, so in the interest of speed, I went ahead and overlaid channel 2 on 3 (after undoing the pitch scale above). This means that both channels will have the same pitch so prepare doesn't try to remap the noise, while not interfering with the custom noise pitches while channel 2 is otherwise silent. (I had to make a new tool, I never thought of this case before):

 

Quote

D:\new>d:\work\ti\vgmcomp2\release\retunenoise.exe bbcapple-palsms-3_2.vgm_noi03.60hz bbcapple-palsms-3_2.vgm_ton02.60hz P
VGMComp2 RetuneNoise Tool - v20240414

Opened channel 0: bbcapple-palsms-3_2.vgm_noi03.60hz
Opened channel 1: bbcapple-palsms-3_2.vgm_ton02.60hz
Will force periodic noise
Imported 12400 rows
3974 tones moved        (non-lossy)
3974 noise tones lost   (lossy)
188 noise type changed (lossy)
Writing: bbcapple-palsms-3_2.vgm_noi03.60hz
** DONE **

Also had to tweak the prepare tool to accept a case where channel 2 and noise were both playing but asking for the same shift count.

Quote

D:\new>d:\work\ti\vgmcomp2\release\prepare4SN.exe bbcapple-palsms-3_2.vgm_ton00.60hz bbcapple-palsms-3_2.vgm_ton01.60hz bbcapple-palsms-3_2.vgm_ton02.60hz bbcapple-palsms-3_2.vgm_noi03.60hz bbcapple.snpsg
VGMComp2 PSG Prep Tool - v20240414

Opened tone channel 0: bbcapple-palsms-3_2.vgm_ton00.60hz
Opened tone channel 1: bbcapple-palsms-3_2.vgm_ton01.60hz
Opened tone channel 2: bbcapple-palsms-3_2.vgm_ton02.60hz
Opened noise channel 3: bbcapple-palsms-3_2.vgm_noi03.60hz
Imported 12400 rows
12137 custom noises (non-lossy)
43 tones moved   (non-lossy)
9785 mutes mapped  (non-lossy)
4 tones clipped (lossy)
0 noises mapped (lossy)
** DONE **

Made it seem a lot happier (we preprocessed away a lot of the noises that were having trouble). Seems to sound okay though!

 

I dunno. Sorry for the spam. I just wanted to take a stab and it, and it revealed a couple places I could do better, so was happy for that.

 

bbcapple_vgmcomp2.zip

[Eric Lafortune]

Wow, excellent research, thanks! It sounds perfectly acceptable to me. In the meanwhile, I had found a brief analysis by Simondotm, the developer of the BBC demo, suggesting to suppress tone channel 2 in conflicting areas. It doesn't seem implemented in their own vgmconverter yet. I've implemented it in my own conversion tool, but now I need to study and compare the different approaches and results.

[Eric Lafortune]

Continuing on your experiments, I've added a few options to my transposing tool (still way more limited than your toolkit). If both tone 2 and the tuned periodic noise are audible at the same time, I can pick one of:

• Tune the loudest generator correctly (and leave the other one off-tune)
• Tune tone 2 correctly
• Tune the periodic noise correctly
• Silence the most quiet generator (and tune the other one correctly)
• Silence tone 2
• Silence the periodic noise

Comparing them on this chiptune, I prefer versions with the droning bass, so I'm now silencing the most quiet generator, which is tone 2 most of the time.