Star Bars Atari 2600 Music Competition at CSDb (Submission deadline 15.8.2023)

[Aleksi Eeben]

Star Bars is a new music sequencer and play routine for Atari 2600. The editor runs on a Commodore 64 (sorry about that! 😄) and exports both PAL and NTSC Atari 2600 ROM images containing your music and the music player code.
  
Download the editor, manual, example Atari 2600 ROM's & player source code at https://bit.ly/atari2600starbars

 

CSDb competition link: https://csdb.dk/event/?id=3323

 
AtariAge users: If you don't have and don't want to create a CSDb account, you can email me your entry as a music data file and I will post it to the competition. (CSDb requires the entries as C-64 executable releases in their database so that their voting system can be used.)
  
   

 

Quoting the rules from CSDb forum (https://csdb.dk/forums/?roomid=12&topicid=161270😞
- Submit your tune as a C-64 executable (press F6 in the editor, 24 characters of text asked for the player, after that give a filename). Make a CSDb release and mark it as released at "Star Bars Atari 2600 Music Competition"
- Competition started on 1.8.2023 and runs until 15.8.2023
- Submitted entries will be collected to a single disk image on 16.8.2023
- Voting ends on 20.8.2023 and the winners will be announced. Winner gets lots of fame and visibility!
- Only CSDb votes count and you can start voting when the first submissions appear
- Barbie and Tie Tycoon are not in the competition, they're just example submissions
  
Demo songs:

 

[Thomas Jentzsch]

Nice, but will there be ROMs to be used on a real 2600? Besides the two demo ROMs that is.

Edited August 8, 2023 by Thomas Jentzsch

[Aleksi Eeben]

10 minutes ago, Thomas Jentzsch said:

Nice, but will there be ROMs to be used on a real 2600? Besides the two demo ROMs that is.

Yes, I'll release all competition entries as both PAL and NTSC 2600 ROM's along with the compilation disk.

[Thomas Jentzsch]

Great!

 

And welcome to AtariAge!

[Windless]

(Nothing constructiv to say, but just wanted to say it's amazing... when I'm done with my hardware projects and get back to my 2600 demo, I really want to have a deeper look at it )

Edited August 8, 2023 by Windless

[+MarcoJ]

this is an interesting concept. The tunes sound quite advanced for TIA generated music. Good sounding arpeggios and gradual tone changes. I notice that the TIA's frequency registers are written to quite often during screen drawing. I am guessing this gives richness to the sound by causing glissando/vibrato? I have used TIATracker in the past, which updates TIA music registers only on the overscan/vblank every frame. Well done for making a new musical program for the 2600. 

[Aleksi Eeben]

Updated Star Bars to version 1.2 - download at the bitly link in the first post
- Improved sound quality* on Atari 2600 (and Stella ❤️), optimized 8 bytes of player & 1 byte of RAM
- Notes below E-3 in the editor and C-64 executables now play 42% pulse width instead of 50%, just like TIA

* techsplanation: tuning rate is now halved and tuning bit patterns changed from evenly distributed bits (10001000, 10010010, 10101010) to adjoined bits (11000000, 11100000, 11110000 etc.) This makes TIA freq counter "overflows" less likely, because there's less transitions between the two AUDF values. If AUDF is changed to a value smaller than the current internal counter value the next output bit is delayed (until internal counter wraps), which builds interference or "wolf notes" (or a great E.T. landing sound) when the counter value, note frequency and Star Bars tuning rate happen to sync up. Further improvement would be possible by individually inspecting each note of the scale on both PAL & NTSC Atari's and very slightly detuning the most problematic notes (if any found) - or adjusting the tuning rate (maybe even dynamically, now it's once every 16th scanline) - or in some cases even using another AUDC setting per note where the ranges of two AUDC values overlap

[Thomas Jentzsch]

I figure that you process the next pattern bit 4, 8, 16 32 or 64 times per frame, right? So the more frequently you process the bits, the better it sounds. Correct?

 

With this change, you reduce the "overflows", but effectively also increasing the intervals for the two frequencies. Doesn't that have a negative impact?

[Aleksi Eeben]

13 hours ago, Thomas Jentzsch said:

I figure that you process the next pattern bit 4, 8, 16 32 or 64 times per frame, right? So the more frequently you process the bits, the better it sounds. Correct?

 

With this change, you reduce the "overflows", but effectively also increasing the intervals for the two frequencies. Doesn't that have a negative impact?

True and false - In a perfect world the sound would always improve when increasing the tuning rate and on VIC 20 I happily went up to 5-8 kHz... If the internal TIA freq counter was a downwards counter that loaded AUDF value to itself when reaching zero, then that would work, but apparently it's not.

 

In Star Bars 1.0-1.1 I was doing the tuning every 8th scanline, but in 1.2 it's dropped to every 16th. It's about balancing and finding the sweet spot... Changing the bit patterns to adjoined bits possibly helped more than halving the tuning frequency. Especially the case with tuning bits %01010101 (50% between two AUDF values) is suspicious, because a very rapid trill at ~2 kHz was performed.

 

(Evenly distributed bits is still great for VIC 20 frequency or for playing samples on a PET 😀)

I'll study this in more detail once Tempest gets his 2600 JR and Harmony. Here's a couple of test ROM's - these are the worst case scenario since they're playing long static tones. "v1_2-QF" is what is now in the release. In music context when it's mixed up with arpeggios and bits of noise waveform, other musical elements stuffed on the same channel, glissandos etc., the problem can be much less apparent. (For example a frame of noise in a drum sound or a short hihat zeroes the tuning bits and plays normal TIA noise at frequency $00-$1F, breaking the interference building up -- btw. I just realized it'd be possible to improve the high pitched noise AUDF=$00,$01 and make it less periodic by using the tuning bits, but that's another story!)
 

wolftest.zip

[Thomas Jentzsch]

Interesting findings.

 

I did what you also did initially for the siren sound in Star Castle Arcade, but with only 4 updates per frame. I used fractional math instead of bit pattern, since that was quite easy to implement: add an 8 bits frequency value to an 8 bit sum, in case of an overflow, the next pitch is used, else the base pitch. This creates pattern like 01001001010010100101001... Sounds like I could have done better with your latest approach. But that still leaves the question, how frequent one should change the pitch. E.g. is 1111110000 or 1110011100 better? I suppose that also depends on the number of updates per frame. Hm...  

 

But I wonder how you can define all frequencies by mixing two pitches with just 8 bits. Or are you modifying the bits, even for a constant frequency? So effectively your bit pattern are infinite like mine are, too. Or are you just using longer, but fixed pattern?

 

BTW#1: How well does Stella compare to real hardware here?

BTW#2: You updated the 2600 demo ROMs using your latest approach, right?

Edited August 14, 2023 by Thomas Jentzsch

[Aleksi Eeben]

Wow, those modern homebrew look so good! Off-topic, but is there a reason for using non-standard 276 NTSC scanlines in Boulder Dash and 270 in Star Castle Arcade?

 

I'm using only 3 fractional bits and combining the 3 different AUDC ranges (div 2, div 6, div 31). Each AUDC chosen is used in AUDF range 5-30 (+ fractional bits +1). So theoretically there's 768 different frequency settings, but some of them overlap and the accuracy is nonlinear - it's more acccurate where AUDF is a larger value (10-30) and gets a little hazy where AUDF is small (5-9). Maybe one could say the pitch resolution is 9-bit, compared VIC 20 VIC-I chip's 7-bit (or 10-bit with similar tuning routine). 

 

Fractional bits are written as 8-bit tuning patterns in the frequency table. It could be a lookup table, like I did on VIC 20, but that'd just waste precious cycles (as long as we don't want to do frequency sweeps or vibrato).

 

For example, the PAL frequency table (Note, target Hz, AUDF [5-30], fractional bits [0-7], div; where div 31, 6, 2 = AUDC 6, C, 4 respectively)

 

Fractional bits lookup table:

 

Version 1.0-1.1:

0 00000000

1 10000000

2 10001000

3 10010010

4 10101010

5 11011010

6 11101110

7 11111110

 

Version 1.2:

0 00000000

1 00000001

2 00000011

3 00000111

4 00001111

5 00011111

6 00111111

7 01111111

 

2 hours ago, Thomas Jentzsch said:

BTW#1: How well does Stella compare to real hardware here?

BTW#2: You updated the 2600 demo ROMs using your latest approach, right?

 

#1 I can't really say for sure before doing more tests on hw, but it's doing fairly well. It did sound a bit rougher than this https://www.youtube.com/watch?v=mPRHSMpqHiU&t=1016s (NTSC 2600 playing Star Bars version 1.1, before the bit pattern change), but one factor could be the analog components smoothing out the sound. After the bit change in version 1.2 it should sound quite close now? If you can run the wolf tests on hw let me know the results! Other, simpler and more naive Atari emulators don't seem to have much if any difference between the versions.

I briefly peeked into Stella 7 code and noticed there's some constants that are approximate, such as the "about 30 kHz" clock being 31440/31200 Hz (NTSC/PAL). When I calculated those for the Star Bars frequency tables from CPU clock speed and actual frame rates I got 31399.5175/31113.1053 Hz. But those probably cancel out when Stella targets to 60.00/50.00 FPS instead of 59,92/49,86 FPS, and in any case the difference is minimal: 1 skipped frame every 16 seconds on NTSC or 8 seconds on PAL. Maybe that could be enough to cause a different note of the scale to be problematic on Stella than on the HW? I can't fully figure it out in my head, when everything is affecting everything, so HW/Stella wolf tests is the way  I did even experiment with changing myDivCounter to a downwards counter that resets at zero to AUDF value (removing "overflows" caused by rapid AUDF changes), but then we lose the E.T. landing sound and phaser06 test doesn't sound right (if I got it right in the first place).

 

Maybe there's still some minor trouble with the SDL2 sound in Stella, possibly related to dynamic buffer size changes if the emulated frame rate is slightly fluctuating? Pure guess. What I hear could be a macOS-specific problem too. Does the resampler get enough data from the previous fragment? That shouldn't matter with nearest neighbour. Something sounds a little off with timing or something (and I get audio buffer underruns/overruns). Perhaps a trace of the TIA output before resampling would reveal if there is any problems at all, maybe there isn't!

 

#2 Yes, all files with datestamp 14/8 at the old bitly/Dropbox link are updated, including the demo ROMs. Music data files (barbie.prg and tietycoon.prg) are not changed, because the frequency/tuning table is not part of the music data. There's separate frequency tables for NTSC and PAL playback, found in player source folder.

[Thomas Jentzsch]

6 hours ago, Aleksi Eeben said:

Wow, those modern homebrew look so good! Off-topic, but is there a reason for using non-standard 276 NTSC scanlines in Boulder Dash and 270 in Star Castle Arcade?

Because we can!  (CRT TVs do not mind)

 

The reasons are different: Extra lines/frame add CPU time to each frame. And CPU time is on the edge in both games. In Boulder Dash, the extra lines are solely required to do the complex calculations fast enough. In Star Castle Arcade they are also to make the display area as tall as possible.

 

6 hours ago, Aleksi Eeben said:

I'm using only 3 fractional bits and combining the 3 different AUDC ranges (div 2, div 6, div 31). Each AUDC chosen is used in AUDF range 5-30 (+ fractional bits +1). So theoretically there's 768 different frequency settings, but some of them overlap and the accuracy is nonlinear - it's more acccurate where AUDF is a larger value (10-30) and gets a little hazy where AUDF is small (5-9). Maybe one could say the pitch resolution is 9-bit, compared VIC 20 VIC-I chip's 7-bit (or 10-bit with similar tuning routine). 

Have you thought about on-the-fly fractional math instead? Using one byte (2+5 bits) for the AUDC and base frequency values and another byte (8 bits) for the fractional bits would theoretically allow 32K different frequencies (with quite some overlapping). So you can be closer to the correct frequency. This would be easy for your initial approach in 1.0-1.1. For 1.2 it should be possible with some extra logic.

 

By which logic do you create the new tables in 1.2? The bit sequence length is always 8bits, right? So you cannot do something like e.g. 11111110000 or even longer sequences. But maybe longer or shorter same bit sequences sound better? And maybe the optimal length depends on the frequency?

 

Or maybe I am misunderstanding something?

6 hours ago, Aleksi Eeben said:

Fractional bits are written as 8-bit tuning patterns in the frequency table. It could be a lookup table, like I did on VIC 20, but that'd just waste precious cycles (as long as we don't want to do frequency sweeps or vibrato).

So you are running short on cycles? I didn't expect that. It would most likely make my idea impossible.

6 hours ago, Aleksi Eeben said:

#1 I can't really say for sure before doing more tests on hw, but it's doing fairly well. It did sound a bit rougher than this https://www.youtube.com/watch?v=mPRHSMpqHiU&t=1016s (NTSC 2600 playing Star Bars version 1.1, before the bit pattern change), but one factor could be the analog components smoothing out the sound. After the bit change in version 1.2 it should sound quite close now? If you can run the wolf tests on hw let me know the results! Other, simpler and more naive Atari emulators don't seem to have much if any difference between the versions.

I will give it a try this week.

6 hours ago, Aleksi Eeben said:

I briefly peeked into Stella 7 code and noticed there's some constants that are approximate, such as the "about 30 kHz" clock being 31440/31200 Hz (NTSC/PAL). When I calculated those for the Star Bars frequency tables from CPU clock speed and actual frame rates I got 31399.5175/31113.1053 Hz.

Hm, I have to check if we are doing wrong here.

6 hours ago, Aleksi Eeben said:

But those probably cancel out when Stella targets to 60.00/50.00 FPS instead of 59,92/49,86 FPS

I knew about NTSC, but AFAIK PAL is doing 50.00 FPS, no? Which base clocks are you using?

6 hours ago, Aleksi Eeben said:

, and in any case the difference is minimal: 1 skipped frame every 16 seconds on NTSC or 8 seconds on PAL. Maybe that could be enough to cause a different note of the scale to be problematic on Stella than on the HW? I can't fully figure it out in my head, when everything is affecting everything, so HW/Stella wolf tests is the way  I did even experiment with changing myDivCounter to a downwards counter that resets at zero to AUDF value (removing "overflows" caused by rapid AUDF changes), but then we lose the E.T. landing sound and phaser06 test doesn't sound right (if I got it right in the first place).

I think the difference is negligible, but then, I am no expert here.

6 hours ago, Aleksi Eeben said:

Maybe there's still some minor trouble with the SDL2 sound in Stella, possibly related to dynamic buffer size changes if the emulated frame rate is slightly fluctuating? Pure guess. What I hear could be a macOS-specific problem too. Does the resampler get enough data from the previous fragment? That shouldn't matter with nearest neighbour. Something sounds a little off with timing or something (and I get audio buffer underruns/overruns). Perhaps a trace of the TIA output before resampling would reveal if there is any problems at all, maybe there isn't!

I don't think this is SDL related. It is all done in Stella.

6 hours ago, Aleksi Eeben said:

#2 Yes, all files with datestamp 14/8 at the old bitly/Dropbox link are updated, including the demo ROMs. Music data files (barbie.prg and tietycoon.prg) are not changed, because the frequency/tuning table is not part of the music data. There's separate frequency tables for NTSC and PAL playback, found in player source folder.

Thanks!

[JetSetIlly]

8 hours ago, Aleksi Eeben said:

I briefly peeked into Stella 7 code and noticed there's some constants that are approximate, such as the "about 30 kHz" clock being 31440/31200 Hz (NTSC/PAL). When I calculated those for the Star Bars frequency tables from CPU clock speed and actual frame rates I got 31399.5175/31113.1053 Hz. But those probably cancel out when Stella targets to 60.00/50.00 FPS instead of 59,92/49,86 FPS, and in any case the difference is minimal: 1 skipped frame every 16 seconds on NTSC or 8 seconds on PAL. Maybe that could be enough to cause a different note of the scale to be problematic on Stella than on the HW? I can't fully figure it out in my head, when everything is affecting everything, so HW/Stella wolf tests is the way  I did even experiment with changing myDivCounter to a downwards counter that resets at zero to AUDF value (removing "overflows" caused by rapid AUDF changes), but then we lose the E.T. landing sound and phaser06 test doesn't sound right (if I got it right in the first place).

Have you read the research done by @Crispy on this subject? The PDF is worth reading in detail if you've not done so already.

 

[Thomas Jentzsch]

12 minutes ago, JetSetIlly said:

Have you read the research done by @Crispy on this subject? The PDF is worth reading in detail if you've not done so already.

I am quite sure Aleksi is at least aware. He chose a volume of 8, which reduces the interaction between the two channels significantly.

[Aleksi Eeben]

5 hours ago, Thomas Jentzsch said:

Have you thought about on-the-fly fractional math instead? Using one byte (2+5 bits) for the AUDC and base frequency values and another byte (8 bits) for the fractional bits would theoretically allow 32K different frequencies (with quite some overlapping). So you can be closer to the correct frequency. This would be easy for your initial approach in 1.0-1.1. For 1.2 it should be possible with some extra logic.

 

By which logic do you create the new tables in 1.2? The bit sequence length is always 8bits, right? So you cannot do something like e.g. 11111110000 or even longer sequences. But maybe longer or shorter same bit sequences sound better? And maybe the optimal length depends on the frequency?

 

I knew about NTSC, but AFAIK PAL is doing 50.00 FPS, no? Which base clocks are you using?

I used fractional maths in Sid Vicious (VIC 20 SID emulator) I wrote in 2006 - https://www.dropbox.com/sh/7m0d1nfrwujtmd4/AAAhehcmONEziJM8MMI8EAdUa?dl=0 - It's basically "exactly" as real SID accumulating oscillators work, but at much lower rate, mixed out as 6 kHz 4-bit output. 

 

That would be probably slower than the rolling mask bit / 8-bit pattern / 3-bit fraction style, and I'm happy with the frequency resolution, it's good enough. (Thanks to P. Suarez for pointing out some great optimizations I had missed, such as the use of bit instruction, because of my old VIC 20 code where I originally adapted this from was working in a different way...)

 

With the current method there's still room for something else, such as the VU meters I'm currently working on (tests attached here, coming to next Star Bars update). Unrolling the whole kernel (making .scanlinedivider in player.s obsolete) and splitting C0 and C1 processing to different scanlines would free a few / a lot of cycles on every scanline... Or maybe read the rotating "maskbit" from a big table per scanline, a zero indicating no tuning to be done on this line... There's infinite ways to do the timing in a better way for a specific use, but I wanted to keep the test player (example.s & player.s in player source folder) as simple and generic as possible.

 

Some rumble and crackle and inaccuracy don't matter in a musical context, but what I'm concerned about is if there's some notes gone totally missing due to how the TIA oscillator works - that'd make composers unhappy 😄 If some notes "choke", there's a small chance that it's not the same exact notes on Stella and HW, due to very small differences in emulation constants vs. HW. 

Attached the timing calculations I did for the frequency tables and matching the frame tempo on C-64 NTSC/PAL. In the Star Bars editor you can switch between NTSC/PAL Atari timing, and the CIA timer interrupt is set to a matching rate, which are slightly different on NTSC/PAL C-64. I think I took the CPU clock info from M. Korth's no$2k6 documentation: https://problemkaputt.de/2k6specs.htm

 

barbie-vu-ntsc.a26 tietycoon-vu-pal.a26 tietycoon-vu-ntsc.a26 tia-cia-timing.txt

[Aleksi Eeben]

5 hours ago, JetSetIlly said:

Have you read the research done by @Crispy on this subject? The PDF is worth reading in detail if you've not done so already.

 

Yes, I came across this article, it was a good read! The effect of the TIA frequency divider (as explained further down in the thread) is perhaps bigger than the non-linearity and cross modulation in channel mixing, but both are important.

 

Next thing could be emulating the frequency response of the analog audio path. Maybe start with a simple HPF/LPF eq matched by ear and have the filter as an option in Stella 🙂 Different console models/generations may have big differences there, maybe even as big as Game Boy and Game Boy Color, where the Color model cuts off all bass frequencies!

[Thomas Jentzsch]

17 hours ago, Aleksi Eeben said:

That would be probably slower than the rolling mask bit / 8-bit pattern / 3-bit fraction style, and I'm happy with the frequency resolution, it's good enough. (Thanks to P. Suarez for pointing out some great optimizations I had missed, such as the use of bit instruction, because of my old VIC 20 code where I originally adapted this from was working in a different way...)

Got you.

17 hours ago, Aleksi Eeben said:

With the current method there's still room for something else, such as the VU meters I'm currently working on (tests attached here, coming to next Star Bars update). Unrolling the whole kernel (making .scanlinedivider in player.s obsolete) and splitting C0 and C1 processing to different scanlines would free a few / a lot of cycles on every scanline... Or maybe read the rotating "maskbit" from a big table per scanline, a zero indicating no tuning to be done on this line... There's infinite ways to do the timing in a better way for a specific use, but I wanted to keep the test player (example.s & player.s in player source folder) as simple and generic as possible.

I like the VU meters. Maybe they could be made with different volume reaction time? One with slow and one with fast decay. I remember having seen that (in red) on an old tape deck. Similar to this:

So you are looking for more free CPU time during the kernel? Maybe I can help.

 

One question: Why are you using maskbit in the TiatonicTuning macro instead of rotating c0/1bits directly? Is that because of the transition between two notes? Or just for less CPU cycles? Or both?

17 hours ago, Aleksi Eeben said:

Some rumble and crackle and inaccuracy don't matter in a musical context, but what I'm concerned about is if there's some notes gone totally missing due to how the TIA oscillator works - that'd make composers unhappy 😄 If some notes "choke", there's a small chance that it's not the same exact notes on Stella and HW, due to very small differences in emulation constants vs. HW. 

I wonder if these cracks are the result of what is explained in the linked thread. And if there is a chance to avoid changing AUDFx at the wrong time.

17 hours ago, Aleksi Eeben said:

Attached the timing calculations I did for the frequency tables and matching the frame tempo on C-64 NTSC/PAL. In the Star Bars editor you can switch between NTSC/PAL Atari timing, and the CIA timer interrupt is set to a matching rate, which are slightly different on NTSC/PAL C-64. I think I took the CPU 

These clocks sure look familiar. Guess I never calculated their effect on PAL.

Edited August 16, 2023 by Thomas Jentzsch

[ZippyOasys]

@Aleksi Eeben is it possible to use this in batari basic projects? I kinda want to use Tie Tycoon for my next project.

 

 

- ZippyRedPlumber

Edited August 22, 2023 by ZippyOasys

[Aleksi Eeben]

On 8/22/2023 at 3:13 AM, ZippyOasys said:

@Aleksi Eeben is it possible to use this in batari basic projects? I kinda want to use Tie Tycoon for my next project.

 

 

- ZippyRedPlumber

I'm not familiar with Batari Basic - maybe it would be possible to use Star Bars in a title screen or something, if the title screen is coded in assembly and placed in another memory bank.

[Aleksi Eeben]

On 8/15/2023 at 4:37 PM, Thomas Jentzsch said:

So you are looking for more free CPU time during the kernel? Maybe I can help.

 

One question: Why are you using maskbit in the TiatonicTuning macro instead of rotating c0/1bits directly? Is that because of the transition between two notes? Or just for less CPU cycles? Or both?

 

I wonder if these cracks are the result of what is explained in the linked thread. And if there is a chance to avoid changing AUDFx at the wrong time.

I don't see the point in optimizing the test code kernel - more useful would be implementing the routine in actual new games or demos and then, in the process come up with new practical solutions for timing the tuning calls/macros. (For example, I doubt anyone would want to reserve register X as literal scanline counter during the entire kernel, like the test code does). Some game projects could fit in the tuning calls quite naturally, for example one tuning call per lane in a frogger clone 🙂

 

(Thinking of a frogger clone, one could ditch the maskbit completely and use hard-coded bit values lda #$01,$02,$04,$08,$10,$20,$40,$80.. for each frogger lane, total of 16 calls per frame so that the hard-coded bit rotate loops.)

Question about maskbit: It's just for less cycles - rotating c0/1bit directly would take 20 cycles, but with a rotating mask and bit compare it's 16 cycles. On VIC 20 original there was also a third voice to be tuned.

 

lda maskbit / asl / adc #$00 / sta maskbit / -- / bit c0bits / -- / bit c1bits = 16 cycles

lda c0bits / asl / adc #$00 / sta c0bits / -- / lda c1bits / asl / adc #$00 / sta c1bits = 20 cycles

 

 

Yes, the cracks are probably from these TIA internal freq compare overflows, that slightly delay the next bit when all three factors happen to sync up (desired note pitch, cpu/tia clock, tuning rate). I'll study this further once Tempest gets his Harmony and I can ask him to run a bunch of tests

 

I have a vague, bubbling idea about controlling the overflows by very quickly writing +2 and +1 values to AUDF before writing the correct value - might not work on Stella as it only checks the internal counter reset once every TIA sound clock cycle (~30 kHz)? ...and only _might_ work on the real hw, depending on if the chip logic does an instant counter reset when a matching value is written to AUDF or if it's somehow tied to the TIA sound clock? All question marks before hw tests...

***

I've just updated Star Bars Editor to version 1.3. It now comes with 36 preset sounds (press F8), VU meters in both C-64 executables and exported Atari ROM's, much smoother C-64 exe, tempo change command, fast forward playback and an easter egg(!). Same download link as before.

 

5 days left to Star Bars Music Competition submission deadline, 5 entries now and at least 1 or 2 more coming: https://csdb.dk/event/?id=3323

 

[Aleksi Eeben]

All competition entries are now here and voting will close on 9th September: https://csdb.dk/event/?id=3323

 

There's both PAL and NTSC Atari ROM's in the zip.

 

votepack-starbars-compo.zip

[Thomas Jentzsch]

Thanks for posting the votepack which includes all the Atari 2600 ROMs. I listened to all six tunes on my Atari 2600 before I voted.

[ZippyOasys]

On 8/26/2023 at 5:35 AM, Aleksi Eeben said:

I'm not familiar with Batari Basic - maybe it would be possible to use Star Bars in a title screen or something, if the title screen is coded in assembly and placed in another memory bank.

Hypothetically, if I was to use the title screen asm kernel, what file would I put in?