#1430 Sound output on xpet "eats" some notes.

[Frederic bezies]

Hello.

I noticed sometimes sound emulation with xpet and audio enabled models (like the 40xx and 80xx lines) "eats" some notes.

Instead of getting all the notes at the same volumes, some are too high, some are too low.

You can download unofficial OST for the game "Attack of the Petscii Robots" with the generator program here: http://shiru.untergrund.net/files/faulty_robots.zip

I recorded the last stable version of the game on the title screen. You can hear all sounds are in the same volume. I attached it to the bug report.

I tried tweaking the settings, without any luck :(

[Frederic bezies]

Game developer made a C64PETSCII version of the game. You can hear what the "music" title must look like.

You'll notice every sound is at the same volume.

[Frederic bezies]

Alex Semonov (who wrote the unofficial OST program) told me this:

"A note on the bug. VICE filters out regular CB2 sound in a weird way, so it eats up notes (reduces volume a lot) on some high pitched notes, and restores volume in even higher notes."

[Frederic bezies]

Forget to add, this is "Attack of the PETSCII Robots" by David Murray aka The 8-bit Guy.

http://www.the8bitguy.com/24749/petscii-robots-now-available-for-sale/

[Frederic bezies]

Just to compare, here is the rendering with mame 0.228 and pet4032f romset. Audio seems to be in a better shape. No sounds are "eaten" here.

[Olaf Seibert]

I have no idea what the code in petsound.c is supposed to be doing. It certainly isn't making square waves from the value that was written into the VIA's shift register. That would be the obvious thing to do, I'd think...

[Ingo Korb]

I think it tries to calculate the sample value directly from the number of 1-bits in the shift register - or more precisely, the subset that is covered by the current output sample.

[Olaf Seibert]

I put some print statements in pet_sound_machine_calculate_samples(). If I interpret the values correctly, it gets called about once per scan line (*delta_t is usually around 64) and is asked to generate 3 (nr) samples.
In theory, the shift register can generate 1 bit every cycle (although in practice the timer, which divides the frequency, is usually set to values higher than 1, up to 255). So trying to squeeze 64 samples of a square wave into 3 samples of output is perhaps a bit difficult... no wonder that the code does weird things.
If the timer value (59464) is higher than about 21 then there seems to be a chance to actually create the correct square wave, since 63/21 = 3.

for those less used to PET sound:

poke 59467,16    : rem enable shift register controlled by timer 2
poke 59466,15    : rem this is the wave form shifting out
poke 59464,tone  : rem lo byte of timer which shifts 1 bit every underflow

The program below clearly shows the weird volume change that the current code is causing:

 100 poke 59466,15
 110 poke 59467,16
 120 for i = 1 to 255
 130 poke 59464,i
 140 next

[Olaf Seibert]

Even though this is way outside my area of expertise, I can't just leave it alone. Therefore don't expect a fix soon.

I looked at the source of MAME 0.226, and I compiled it, but I could not try out any PET, since I don't have the PET ROMs in the form MAME wants. @fredbezies74 Where can I get them?

In MAME it looks like the full 1 MHz bitstream from the shift register is calculated, and then fed into a speaker device which downsamples appropriately. It even seems it emulates the clock going up and down, not just 1 step per cycle.

In MAME's 6522via.cpp, in via6522_device::shift_out(), it calculates changes to the shift register and calls m_cb2_handler() with the output bit.
In src/mame/drivers/pet.cpp, m_via->cb2_handler().set(FUNC(pet_state::via_cb2_w)); apparently sets via_cb2_w() as the function that gets called. via_cb2_w() in turn calls update_speaker() which does a weird thing: it ANDs the CB2 output bit with PIA1's PA7. That is apparently the Diagnostic Sense input. I never heard of anything relating that to sound output.
But let's assume this somehow doesn't destroy the sound output.
Then it calls m_speaker->level_w(level); which ends up in src/devices/sound/spkrdev.cpp speaker_sound_device::level_w(int new_level).
From there on it does complicated stuff to (presumably) downsample this bitstream.

[Frederic bezies]

Hello.

I attached the roms you need to this bug report. By the way, current Mame code is buggy. Here is what Alex Semonev (who wrote the OST) write me:

"0.228 is still broken. It sounds plain wrong, just without any weird filters, so it sounds clear at least. But instead of 250 Hz tone you'll get 500 Hz, so it can't really be defined as 'better'. We're reported it to the bug tracker back in December, guess it'll take a while before they'll fix it. I had to make a temporary fix by myself in order to be able to record proper sound, actually."

See this bug report: https://github.com/mamedev/mame/issues/7559

Hope I helped a little.

[Olaf Seibert]

Thanks! MAME indeed sounds too high.
I like the way they can compose chips to machines in such an easy way.
And there seems a HSG High Speed Graphics emulation in there somewhere.... maybe I could do something with that at some point.

[Frederic bezies]

You're welcome; I wanted to help as quickly as possible. I'm happy this bug bites the dust. This is the more important thing for me here. Thanks once again for the bugfix.

[Olaf Seibert]

Interesting... the thing that MAME does with the diagnostic sense is actually correct. You can see it on the schematic: http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/8032/8032029-03.gif
I came across it in a discussion about CB2 sound: http://www.vcfed.org/forum/showthread.php?43349-PET-2001-CB2-Sound-Mod

[Olaf Seibert]

It may be simpler than I thought. Can you compile a test version and tell me if this improves things for you, and in particular if anything gets worse?
I did fix a bug where the bits from the shift register were apparently used in the wrong order (least significant bit first, instead of msb). That may give some slight differences I suppose.

[Olaf Seibert]

Hm, I discovered a mistake in the previous patch (delete from the tracker). Here is a new one.

[Frederic bezies]

Well, it is far better! No sounds get eaten. I recorded a small video and you'll hear there is no variations in sound height. No "eaten" notes now. Wow! Not perfect, but far better! Thanks for the patch.

[Olaf Seibert]

I have committed that (plus some more cleanup) as revision 39811.

So what are you comparing the sound with? I remember that a PET with a real speaker and the recommended circuit sounded a lot better than the piezo speakers that are present in the 40xx and 8xxx models. The difference being so much that it in principle wasn't considered acceptable for many use cases.

Unfortunately my PETs are not ready to be used for comparison. With all the things I read about leaky capacitors I'd even be afraid to turn them on (even if they were easily accessible right now) ... And they all have the silly piezo speaker anyway.

[Frederic bezies]

I saw you pushed a fix. I compared to mame (which is way to high) and I got feedbacks from both David Murray (The 8-bit guy) and Alex Semenov which wrote the "faulty robots" program.

Both said it sounds more like a real PET, so mission accomplished here. I can enjoy piezo speaker "music" now without "eaten notes" which is a deliverance :)