Another "Bad Apple" demo

[JasonACT]

1 hour ago, Eric Lafortune said:

Thanks for the experiments! Nice setup.

Thanks, I've got new (and hopefully final) circuit boards in the post as we speak, and I did double the value of the main signal feeding resistor for my current PWM speech emulation to reduce some digital signal noise...  So there is no way what I have now is anywhere near "original".  I think I'll add a small variable resistor for that component, when I build the new one.  The new circuit board has that speech audio line surrounded by thick ground lines, maybe that will help with any noise.  At least with a variable resistor, I'll be able to adjust it as needed.

Edited October 25 by JasonACT

[+mizapf]

12 hours ago, JasonACT said:

I tried MAME from GameBase, but it said the image was greater than 2MB and didn't load.

How did you create that image? Of course, an image in MAME cannot be longer than 2 MiB because we never had ultra-density floppy drives or controllers.

[JasonACT]

9 hours ago, mizapf said:

How did you create that image?

The demo has an .rpk and I extracted the c.bin from it & ran MAME from the command line using the -cart1 parameter.  An error message said it was bigger than 2MB.

[+mizapf]

MAME does not take "naked" bin files as cartridges for ... well ... 12 years or so? 🙂 But why would you want to take the bin file when there was already a RPK file?

 

I still wonder why it reports that error if you used the cart option. It should rather say that this is no valid cartridge.

[JasonACT]

14 minutes ago, mizapf said:

MAME does not take "naked" bin files as cartridges for ... well ... 12 years or so? 🙂 But why would you want to take the bin file when there was already a RPK file?

 

I still wonder why it reports that error if you used the cart option. It should rather say that this is no valid cartridge.

I mis-remembered.  That's what I did to try Classic99.  I used the .rpk file with MAME's -cart1 option (I just tried it again, and got the 2MiB error - the c.bin file does say invalid image).

[JasonACT]

Actually, I was trying "texas.exe" but it does in fact load OK with "texas250.exe" 

[+mizapf]

6 hours ago, JasonACT said:

I mis-remembered.  That's what I did to try Classic99.  I used the .rpk file with MAME's -cart1 option (I just tried it again, and got the 2MiB error - the c.bin file does say invalid image).

Please send me the RPK. I guess that the RPK was not created correctly, most likely with the wrong cartridge type.

[Eric Lafortune]

1 minute ago, mizapf said:

Please send me the RPK. I guess that the RPK was not created correctly, most likely with the wrong cartridge type.

Double-checking myself: I get the same error with Mame 0.242, but not with Mame 0.252. If I'm not mistaken, Mame 0.243 is the minimum.

You can find the official RPK file of Bad Apple at https://github.com/EricLafortune/BadApple/releases

[+mizapf]

It was likely 0.244, have a look here: https://www.ninermame.org/info/releases (also see my signature lines in my postings).

 

0.244     2022-05-25     bcf77373a5f     -     9995 decrementer; cartridges with smaller ROMs than 8K; gromemu now allows up to 4096 banks     -

 

For that reason, I document the changes and fixes. As always, if you are using MAME and have some problem, please update to the most recent version. Sounds funny, but I happen to fix some glitches every now and then. Still, I failed to make them time-travel back to older versions. 🙂

[JasonACT]

@Eric Lafortune Do you mind if I upload 2 x c.bin files here (143KB each) which are versions of your demo without the video.  rom50c.bin will be the original, just without the video stream, rom60c.bin will be the same except it has extra VSYNC commands (1 extra for every 5 in the original) to space it out for NTSC consoles.

 

I'd like to do this for 2 reasons, the first being that someone can maybe then record the volume difference of the sound chip on a real console (the 50Hz version works on both consoles, so that's the one to test) with their real speech synthesizer.  If they are different volume levels to MAME, which they very well may not be, @mizapf might feel inclined to fix it.

 

The second reason is, I've been experimenting, and while I'm not compiling from source, I think your description of speech breaking up due to some complex video frames on 60Hz consoles may not be the real reason.  I can't find your code which spaces out the speech data differently depending on refresh rates, but the build.sh file has hard coded a FPS value of 40.  The speech on the rom60c.bin file breaks up like you describe, but the only reason will be how it's spaced out.

[Eric Lafortune]

Interesting! I should check that myself, but feel free to post the files. I don't see an explanation for the speech breaking up with the 60Hz version on an NTSC console -- the pace of the speech frames should be the same.

 

The speech synthesizer dictates the 40 speech frames per second, irrespective of NTSC or PAL. The ComposeVideo tool (called near the end of the build script) gets an option `-50Hz` or `-60Hz` and spaces out the speech frames between the Vsync commands of the video, in order to get the right pace.

[JasonACT]

Ah, thanks for the pointer to where it all happens, I'll check that out before I post the rom60c.bin since mine is based on the 50Hz version.

 

Here is the rom50c.bin, if anyone feels like making a sound recording off real hardware...  It plays to a black screen (and there's a delay before it starts, of course).

rom50c.bin

[JasonACT]

I've been continuing with my experiments, just playing the speech this time.  With the original timing (but calculated against the 60Hz refresh) I'm sending in 4 bytes of speech data, sometimes 5 bytes to play catch up.  The 50Hz version is sending in 6 bytes, sometimes 7 to catch up.  There's a 16.66ms vs 20ms delay while waiting for the VDP status flag between the two.  But at 60Hz I get corruption in the speech audio output even with nothing else happening.  Turning on the music again shows it is staying in sync, but if I re-calculate the total length of speech frames to be 60 less (1 second) the speech corruptions go away for both the demo's long speech verses, but it's out of sync by a second by the time it finishes each.

 

Maybe 4 bytes of data isn't always enough to cover 16.66ms, but 6 bytes is always enough for 20ms?

 

This would mean processing it though the MAME speech code, to work out how many bytes are needed to cover the 16.66ms, instead of evenly distributing them like I am now.  I'll look at the ComposeVideo tool tomorrow.

[+mizapf]

5 hours ago, JasonACT said:

I'd like to do this for 2 reasons, the first being that someone can maybe then record the volume difference of the sound chip on a real console (the 50Hz version works on both consoles, so that's the one to test) with their real speech synthesizer.  If they are different volume levels to MAME, which they very well may not be, @mizapf might feel inclined to fix it.

You can set the volume levels in MAME for every sound-producing device using the "Slider controls" submenu in the OSD menu.

[JasonACT]

9 hours ago, mizapf said:

You can set the volume levels in MAME for every sound-producing device using the "Slider controls" submenu in the OSD menu.

Thanks for that, we all just need to know what level is needed to be OEM.

[+mizapf]

When you find out, I may change the default in MAME so that future releases get a more realistic mix.

[Tursi]

10 hours ago, JasonACT said:

Maybe 4 bytes of data isn't always enough to cover 16.66ms, but 6 bytes is always enough for 20ms?

Remember too that the number of bytes consumed by the speech synth depends entirely on the data provided - it's not a fixed value per time period. The usual method for streaming speech data is to wait for the data low status bit to be set and then send 8 bytes (there's a 16 byte FIFO on the synth and data low is set after 8 bytes are drained.) 

[Eric Lafortune]

That's a good point. ComposeVideo parses and counts the input speech data as frames and adds the corresponding chunks of bytes to the video output stream again (possibly already including a few bits of the next frames), so it should be okay. The interleaved streams of music/speech/video ensure that they always remain synchronized, but the speech buffer is the most sensitive part. Sending speech data too fast may go unnoticed because it halts the CPU, but sending speech data too slowly seems to be resulting in garbled speech.

 

I'll check some more. In Mame, you can watch the many internal registers of the speech synthesizer, but it's non-trivial to see the right things at the right time.

 

 

[JasonACT]

4 minutes ago, Eric Lafortune said:

Sending speech data too fast may go unnoticed because it halts the CPU, but sending speech data too slowly seems to be resulting in garbled speech.

It will be going too fast on a PAL system, when I start MAME from my batch files it reports either:

NTSC 59.922738
PAL   50.158969

So a PAL video system will be trying to consume the movie stream faster than the speech synth can handle and it gets the benefit, on the other hand, there is no benefit being had via a CPU halt on an NTSC console, though I've run the numbers and you may see at most 1 glitch if you're unlucky.

 

I've also now seen your code and it look good, very nice actually, and I agree it should be OK...  The difference though is the NTSC frame (16.6ms) between each half of speech data packets, where PAL has the single frame (20ms) between the full speech data packet.  That might be where @Tursi's point becomes important?

[JasonACT]

On 10/30/2023 at 10:39 AM, JasonACT said:

though I've run the numbers and you may see at most 1 glitch if you're unlucky.

I came down with the flu over the weekend, so I had to stop most of my experiments, but when I did the numbers here my head was not very clear.

 

There are 5011 actual "60Hz" (not NTSC) VSYNCs needed in the first verse of the speech, 83ish seconds, which I think is correct but only because I wrote some code to work it out...  It sort of matches the build script, but it doesn't matter though, even if approximate I can use 5000.

 

Using the MS calculator in sci mode...

 

1000 / 60 = 16.666666666666666666666666666667

1000 / 59.922738 = 16.688156005154504121624081997054

 

So frames take longer with NTSC, and you get less of them per 1000ms (a second).

 

5000 * 16.66r = 83333.333333333333333333333333335

5000 * 16.68x = 83440.780025772520608120409985271

 

So 83.333 vs 83.440 seconds start to finish = 107ms of gaps that happen on a real NTSC machine compared to whatever you might call a 60Hz one.

 

That, I think (someone should verify my maths, I'm still not 100% well) is plenty to ruin your day when making a cool TI demo on an NTSC machine.

Edited October 31 by JasonACT

[Eric Lafortune]

You were right, @JasonACT -- the NTSC version didn't work, even with the CPU-intensive animation disabled, and the approximate frequencies were the culprit. Thanks! I've now adapted the code and the garbling is gone, even with the animation enabled. There's still a very occasional non-deterministic glitch, maybe due to smaller rounding/timing problems. I'll check some more, document the option, and release an update.

[Eric Lafortune]

I've updated the VideoTools project to version 2.1. The ComposeVideo tool now applies the more accurate PAL/NTSC frame rates. It also pre-fills the speech buffer with more data when a speech fragment starts (not wasting those precious 16 bytes!), so it avoids spuriously underflowing the buffer later on.

 

With this update, version 2.1 of the Bad Apple project now offers a PAL version and an NTSC version. You can find the RPK files on the release page.

[+OLD CS1]

I can only just barely hear the vocals in Classic99.

[JasonACT]

14 hours ago, OLD CS1 said:

I can only just barely hear the vocals in Classic99.

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.

 

On a different topic, I'm also using the Classic99 speech dll wrapper code, which uses a hardcoded clock value which the MAME doco says produces 8KHz samples.  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, one thought is my Pi Pico 250MHz overclock is something a bit higher, which might make sense since technically a 266MHz overclock should be possible - however it doesn't work, but overall I'm pretty happy with it working now the way it is.

 

Nice work @Eric Lafortune

[Tursi]

Classic99 has never put a lot of effort into making speech playback accurate. I just use the MAME core and take it at face value, as I've never wanted to develop speech software. So I can't even tell you what parts of that emulation are strong or weak.