Aleksi Eeben
-
Posts
11 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by 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.

-
2
-
1
-
-
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
-
1
-
-
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.
-
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!
-
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.htmbarbie-vu-ntsc.a26 tietycoon-vu-pal.a26 tietycoon-vu-ntsc.a26 tia-cia-timing.txt
-
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.
-
1
-
-
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!)
-
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 -
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.
-
3
-
-
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/atari2600starbarsCSDb 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:
-
4
-





Vortex Font Book - 4x8 fonts for your projects
in Atari 2600 Programming
Posted
I created a bunch of 4x8 pixel, 7-bit ASCII character sets for my latest project Vortex Reader, an 80-column text viewer with hypertext features for Commodore 64. I thought these might be useful for homebrew/retro/embedded developers, for whatever you're tinkering where you need text on a small bitmap display, so I released the fonts under CC BY 4.0. The internet is full of 8x8 fonts, but 4x8 are a bit harder to find!
Here's a preview of the 11 fonts in Atari 2600 / VIC 20 style flat pixels:
Binaries attached, the format is: ASCII characters 32-127, 8 bytes per character and only low nybble is used (768 bytes per font)
More info and previews in different pixel ratios: https://bit.ly/vortexfontbook
Vortex Fonts.zip