Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

R0ger

Members
 View Profile  See their activity

  • Content Count

    753

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by R0ger

  3. Posted

    3 hours ago, Synthpopalooza said:

    I can explain some of it.

     

    As I said, all you need, for the most basic testing, is to sync the counter before you start playing, and then just make sure you only play desired multiple on the channel you want the bass on. In RMT using C mode no change to tone table is needed, as those note already are multiple of 3. But with your new modes, you will need to change the tone tables, and there is also this atomicity problem Pavros mentions.

    It might work without it, but in my experience, if there is few cycles window, sooner or later the counter will flip inside of it, even if it is low frequency. I suggest starting with original Pavros bass, synchronized C, multiple of 3. After it works, go for experiments.

  4. Posted

    It's some weird player I've never seen. It seems to use 16 bit bass.

    Basically you would have to insert your sync code before it starts playing, and mind it has to be done in DMA free time, like in VBI.

    Then you have to make the player play tone table you need. Which might be an issue here. You have to understand the whole player first.

    I know RMT player. I know where it stores its tone tables. I know where it defines distortion values for each instrument. So hacks like these are easy.

    This thing, not so much.

  8. Posted

    Interesting ideas. I've just studied how you use the multiple of 15 and IRQ to introduce the phase shift. That's exactly what insight into the underlying principles allows you to do. Perfect !

    I didn't test anything more yet. I'm more and more convinced the click is not really an issue in most of the cases.

    There is another thing which I want to try though. With one sync you can make all multiples of 3 to generate 10000 sequence. That is what all music players can do, and it is imho the most useful achievement.

    If we go for sync at every note, using method 2 to avoid much worse STIMER clicks, I think we could achieve any desired sequence (of those possible) for any frequency. We would just need table of starting offsets for every frequency, and code which will be able to do it. It's of course much more complicated, but hey, that's the fun part. There are some better sounding ones I think. And we could actually get like 5 different stable timbres ? That would be cool.

     

    Still I see many limitations. It's just 8 bit bass. It can do PWM, but with IRQ and extra channel. And if we go for IRQ, we can go all the way and use IRQ to generate the bass directly, see this recent thread: https://atariage.com/forums/topic/292342-new-bass-approach-rediscovered-in-old-song

    Or going the Hard-bass way of constant-sample-frequency soft-synth.

     

    I'm not giving up on this though, it certainly makes C bass better.

     

     

     

    • Like 4

  9. Posted

    26 minutes ago, phaeron said:

    Recording from an NTSC 130XE:

     

    CBass1.thumb.png.266bc6e48ad2b02783659a8b88ff9b4d.png

     

    Depending on the phase change, yeah, you're going to occasionally get two pulses close to each other. Emulation of this is going to be very touchy as the output depends on emulation of the correct polynomial offsets coming out of init mode, the correct polynomial patterns, and the correct relative delays between the channels tapping off from the global polynomial counters.

    CBass1.wav 591.79 kB · 1 download

    Somehow Altirra manages to do that quite well. As if it was made by some dedicated madman :-D

    Problem is Atari 800 (hence Coleen) or RMT are way behind, and most of this advanced stuff is just beyond their reach. Sure, RMT uses external pokey emulation, but the way it calls it clearly has some limitations to precision. That's certainly another area where it can be improved.

     

     

     

     

    • Like 1
    • Haha 1

  10. Posted · Edited by R0ger

    7 minutes ago, ivop said:

    I first ran it on atari800. There it sounds unstable (which shows that its Pokey emulation is sub-par to Altirra), but no clicks(!). After that, I tried Altirra and it's stable, but indeed after a few rounds of the scale you hear a slight click. I wonder if it isn't related to the RMT player somehow? I find it very hard to believe that a single phase shift combined with a frequency change at the same time can create such an audible click.

     

     

    It's not related to RMT, Here it is without RMT, just one write to AUDF every time the frequency changes.

     

    CBass.xex

     

    I wasn't sure how the click happens either. But I recorder it from Altirra, and then analyzed the recording in Audacity, and it's clearly just the phase shift, and nothing else.

     

    Basically you get sequence like this: 1000010000101000010000 ... that is enough to produce short transient higher harmonics pulse.

     

    Here's how it looks as recording:

     

    image.thumb.png.d0bff70b9cdd2304a1746bcfd06472ca.png

     

    Btw. it seems like this 0010100 is one of the most audible cases. It of course depends on what frequencies are being exchanged and at what point the the sequence it happens.

    • Like 2

  11. Posted · Edited by R0ger

    Ok, let's continue here, it's your research 🙂

     

    First let me thank you once more for this great research, it really brings lot of details about little explored subject.

     

    After finally reading Atari Fan article I did some experimenting on my own, and I found there is still some clicking when changing AUDF registers.

     

    CBass1.xex

     

    It only happens sometimes, let the scale play several times, you will know when you hear it.

     

    This code uses first synchronization method, on the beginning only. After that, it just relies on playing just frequencies which are multiple of 3. It uses normal RMT player with RMT C distortion and normal RMT frequency table for C.

     

    The clicking is not related to STIMER synchronization, as no synchronization is done after the initial one. It is caused by the fact, that while all frequencies play 10000 bit sequence, those bits are played in different order for each multiple of 3. So when you change frequency between bits, there might be slight phase shift, which produces the clicks.

     

    It's not big issue in most cases, and I don't think it can't be easily solved, but I wonder what do you think about it.

     

  15. Posted · Edited by R0ger

    I had an idea today .. if I only need synchronization on the beginning, I can simply use RMT player after I do the synchronization. As long as I only play RMT C bass on one channel and nothing else, the synchronization should hold. And it seems it does !

     

    First XEX is example of constant volume, second XEX uses some decay. Not total decay. I just wanted to hear how is it going to help. IMHO not much. Complete decay removes the click perfectly, obviously.

    It starts on deepest sound using default RMT freq tables, which is G# (F2 divisor).

     

    The bass is softer than comparable E bass, but out of all possible C bass sounds, the stable one is one of the weakest and most buzzing. And it's just normal 8 bit C bass, with all it's inaccuracies.

    If you mix drum & bass in one channel, this won't help you at all. I typically do reserve 1 channel for bass, so it's not an issue. And like this it's really simple to use, just add some extra code in music init to sync the timers to polycounter.

     

    Please note it was not tested on real hardware, only in Altirra.

     

    CBass1.xex CBass2.xex 

     

    Edit: here is my song Dreams from IRQ bass testing adapted for this bass. It uses long tones, and on every bass note change there is also drum beat in other channel, so the clicking is not a problem.

     

    CBass3.xex

    • Like 2

  17. Posted · Edited by R0ger

    1 hour ago, Chilly Willy said:

    According to the tester app comments, the type 2 generator doesn't produce clicks as it uses cpu timing rather than pokey timers. Only the type 1 generators click... at least, that's what the comments claim.

    Interesting, will recheck the chapter .. my polish is far from 100% :-D

     

    ...

     

    Ok, so I recheck the chapter, and I'm not entirely sure now what you are talking about. What do you mean by type 2 generator ?

     There are 2 method of synchronization, one using STIMER and another using AUDF=0. I presume this is what you mean.

    STIMER will definitely cause clicking. But that's not what I'm talking about.

     

    My demonstration uses synchronization only at the start, not between the notes. I tries to keep the channels synchronized by using only multiplies of 3. The poly counter is synchronized so it produced the exact same 5 bits of the sequence every time. And since only one of them is 1, and the rest is 0, we always get 10000 sequence. If you write the right values of AUDF, synchronization isn't needed (which is discussed in another chapter).

    You will still get clicks when writing to AUDF though. Every multiply of 3 scans the same 5 bits. But every multiply of 3 scans them in different order !

    One can scan them like 1,2,3,4,5, another will go 1,3,5,2,4, or 5,4,3,2,1. The resulting wave will always be single one separated by four zeros.

    But there will be phase jump every time you change AUDF.  The sequence can come out like this:

     

    100001000010(new AUDF)01000010000

     

    This will happen if the sampling order changes from 1,2,3,4,5 to 5,4,3,2,1. That's what my example is about, I don't think it's being discussed in the article. I will be glad to be wrong.

     

    Btw. there is no demonstration of the principle used in a song, right ?

     

    PS. I think you will get the same effect using Pavros testers, turning the synchro off (L key) and then using Z,X,C for changing note. Synchro off makes lot less clicking than synchro on, but there is still some clicking.

    • Like 2

  18. Posted

    I've read the AtariFan article and it is VERY helpful.

    It explains all quirks of C distortion. How and why different timbres are generated using different frequency values. Why some tones are stable (which form what in RMT is called bass E), and some not (bass C in RMT). What else there is (multiples of 5 and 15) and why it's not used.

    And especially, how some CAN be stabilized and used reliably.

    The article goes to incredible depth, contains lot of tables. The problematic is really complex though, and I understood most of it only after playing with it myself.

    I do believe I know understand everything in the article though, and if Pavros won't make English version himself (in past he mentioned he will), I can do some (lot shorter) to sum it up later.

     

    Unfortunately there is one more problem, I haven't found being discussed. In simple terms, whenever you change frequency with this new bass, there is audible click.

    I can even explain why it is, and why it's basically impossible to fix, but it would make no sense without explaining all before it. So Pavros, if you're here, hit me up.

    It might still be usable in some cases, but I consider it big limitation.

     

    Here is short example .. frequency is multiple of 3, stabilized using pokey reset (first method, basically the code from the article), lowest frequency, shifted up and down by 3. You can also hear the clicks in the Pavros testers.

     

    CBass.xex

  19. Posted · Edited by R0ger

    Never heard about this one ..

     

    Anyway .. @Wratchild has gotten pretty close to porting it. Check his posts, he posted some demo recently somewhere here, IIRC.

    But many things have to come together for something like that happen.

     

    I plan to do completely new game of that genre, don't expect it before 2025 though ;-)

     

    Here is link to demo of my engine. I plan to remake it basically from the scratch, this was my first thing for Atari and I have come up with many improvements since then ..

     

    https://atariage.com/forums/topic/237244-rescue-3d-engine-demo

     

     

    • Like 8

  22. Posted · Edited by R0ger

    5 hours ago, Gunstar said:

    @R0ger Am I right in my understanding that RGBY 8x11F, and all other RGBY modes for that matter still have the 128 color Antic palette at their full disposal/limit, or does it create a larger virtual palette with what you are doing, like Colorview does with flipping three 16 shade R,G,B screens to create a virtual palette and on-screen colors of 4096?

     

    Do on-screen colors, at least at this point in your RGBY modes, max out at 88 for 8x11 mode and go down from there? Or is this a misnomer on my part in my figuring that's exactly what 8x11 means, 8 shades/brightness levels by 11 colors(or vice-versa if I mixed it up), or have I forgotten, missed or mixed up that explanation? Or have I totally misunderstood?

    The palette resulting from PAL mixing itself is close to existing Atari colors. Color $20 and $0f will give something rather close to 2F.

    But with flickering, different palette is created. I wouldn't say larger, but different. First the hues. Atari hues lie on a circle in color space. I'm picking 4 colors on the circle. Not even equally spaced. It's more like equilateral triangle for RGB, and yellow stuck between R and G. Flickering then creates hues between 2 base colors. So these new hues are somewhat at different angles, and they all have slightly worse saturation.

     

    At the moment I use these colors for hues: 70,B0,E0,20 .. basically RGB are picked to be as strong and as single-component as possible. And then yellow is added. If you imagine the color space, the base colors create polygon. The flickering and dithering then can create virtual colors inside that polygon. So if some picture would be heavily skewed toward some color, the base colors could be picked differently. Though I like the system RGB + one extra color to extend the polygon toward area of interest.

     

    Brightness levels are simpler. I use these 6: 0,4,8,10,12,14 .. as you can see, there is more detail in the bright values, as both flickering and dithering are more visible in bright areas. Flickering gives me extra levels very similar to original 2,6,9,11,13.

     

    This also brings problem. When I'm dithering the images on PC, I'm using this 11x7=77 color palette, which I then recode into hue/bright values, and into 2 fields for flickering modes. But I have to compute the palette first. I have to simulate the way base colors combine into the resulting colors. I have very simple formula for that, which only picks other Atari palette color, but most of the time I use different method. I create XEX with all colors possible, I make screenshot in Altirra, with PAL artifacts and frame blending, and then I use this screenshot as reference.

     

    This is old reference image from 11x7F mode:

     

    image.png.a3d200cf808fcfee7f5eff22eaecc6ae.png

     

    Today I don't mix hues only in neighbor pairs only, I do all combinations. So instead of adding R-Y,Y-G,G-B,B-R I also add R-G and B-Y. So I actually have 10 hues, and the hues can't be ordered nicely like this, so today I use different reference pattern. The old one also had to be processed to remove the scanlines, the new one can be used straight from Altirra.

     

    bgyr10x11.png.d92c9988ec95eb75390c654b664029ba.png

     

    Quote

    perceptually some of those images seem like more than 88 colors or even 128. of course that is the case with some Rasta images too, to me. Even though I know it's limit is 128 color palette and maximum on screen colors, and most of the time average half of that.

    There is another level of color interpolation with dithering. And that's complex topic by itself. Rasta can't do it that well, at least it can't adapt dithering to current palette. It has to do dithering first, and then adapt palette to it. Also my approach has basically every color (minus character limits) available everywhere, which helps.


     

    • Like 2
    • Thanks 1

  23. Posted

    19 minutes ago, PixelCrunch said:

    Jesus christ, those are really well done art pieces.

     

    My favorite one is the Coco art. It looks like something straight from the movie reel, but downsized.

    It's converted images. Not 'art'. If you want to see it in movement, I did test which only works in emulator, here: 

    It's not Coco though. It's different kind of art 🙂

    • Like 1

  24. Posted

    17 minutes ago, Gunstar said:

    The flickering on these images is not nearly as bad as the old GTIA flicker you got with interlacing modes, not NEARLY, it's very minor in comparison, and would probably be even less with NTSC. Except you need PAL for the color blending here.

    Main reason is that GTIA flicker is used to increase resolution. You can control it with blur, but generally you flicker 2 quite different brightness levels. My flickering is used to increase color depth. I can guarantee the brightness level to be closer, and I can use deflickering patterns. I was never friend of flickered modes. But on many CRT TVs this is just OK. And on LCDs, projectors, or emulators it's no issue whatsoever.

    • Like 4

  25. Posted

    The red is simple. I can't really do black. On the hue lines, there is always one color from red, green, blue or yellow. So whatever the original image was closer to, that's what you get. It's one of the areas I improved recently, for flickering images. I can flicker blue and yellow, which will average as gray. I construct 10 hues out of those 4 base ones, instead of just 8, which you can see in these images.

    The same reason also introduces some chroma noise in composite signal, making dark areas brighter. It's good idea to adjust TV brightness / contrast so the darkest colors in the picture are dark enough. Also these pictures are on average 50% darker than full image. So that can be adjusted for too. And boosting color saturation won't hurt either :-D Some TVs will do all these adjustments automatically to some extent.

     

    As for the noise, yeah, it can be pretty much everything, in analog world ..

    These images mostly rely on PAL blending. And most TVs only do inter-line blend on HF and composite inputs. It's typically not applied on S-video.  But not always ! Some TVs will apply it even on S-video. Same with VGA or HDMI convertors. You simply have to try it.

     

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...