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. badapple_silencequietestconflictinggenerator.mp3

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.

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?

I find myself using the cheat sheet regularly now. Thanks again! Another small typo: "Shift right arithmetic circular" -> "Shift right circular".

Adding some practical examples to the theory that others have explained nicely... I use BLWP/RTWP extensively in my code, for example in the action game Rock Runner. Some pointers: game_screen.asm contains the main game loop, which is mostly a list of calls to subroutines. Subroutines themselves can also perform nested calls. This keeps the code manageable and readable. rendering.asm for example contains a set of subroutines for rendering. In their documentation, IN refers to a register in the workspace of the calling code. STATIC refers to a register in the workspace of the subroutine that has a fixed purpose across calls (like a static variable in C), so it is conveniently available in all related subroutines. I put the vector with addresses of the workspace and the code right before the code ('!' is a local label, supported in the xas99 assembler). main.asm defines the addresses of 9 register workspaces for all kinds of purposes, 8 of which fit in fast scratch-pad RAM. The few microseconds overhead are generally irrelevant.

Very nice! Surprisingly complete, effective graphics, some sound, all in compact code. Nice use of subroutines. I like the low-level approach with custom VDP and CRU routines. As for coding tips: Documentation is essential to make sense of any assembly code, e.g. what do the subroutines do. You can use BLWP/RTWP subroutines (with their own register workspaces) instead of BL/RT subroutines, so you don't need to worry about clobbering registers. You might then even keep all your variables in registers, which makes for simpler code (although the naming isn't as explicit). You could consider the xdt assembler. It supports long names and macros, to work at a slightly higher level of abstraction.

Very useful! Possible typo: "LIMI cnt: Load int. level: 0,1 enable; 2-15 dis." -> isn't it the other way around?

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

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.

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.

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.

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.

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.

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.

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.