R0ger

Well you can still have inverted and non-inverted pixels in one byte. Question is how often that will happen. Anyway, I was thinking about it and clearly you must know some way how to force character map read in middle of the line. I'm not aware it's possible.

It's there. F key. Does anyone read the manual ? 😀 The character mode idea is interesting. And I have kernel anyway. There still would be conflicts, but I guess they could be minimized by palette design. GTIA mode on the other hand doesn't seem very useful to me. Note this is not they usual luma / chroma system. All lines use high saturation colors with various brightness. Luma / chroma system colors are washed out compared to this, and the resolution is bad as it is.

Well yes, it's just a gimmick. It's not very good for real 'browsing'. Where it excels is background playing. Like when you are at a party, talking with people .. and you want something nice to be happening on the screen. 10-30 minutes rendering time is just about perfect for that.

Using low PAL artifacting with NTSC palette should work fine. High NTSC and PAL artifacting introduce luma to chroma aliasing (false colors on B&W hires images), which is quite different on PAL and NTSC, but for lowres, high PAL artifacting should also work fine, and get you very close. But yeah, having extra option for chroma blend would be nice.

As I said, I was under impression they can't work on NTSC at all. So good for you I guess 🙂

The source picture is here: And Altirra does very good in how it looks on PAL TV (with PAL artifacting set to high, frame blending on):

The second one. There is clearly strong leak of chroma only lines to luma only lines. And that's what this GFX mode counts on. On the first one there is very little color. There actually should be none, and I've seen it on some PAL TVs when using S-video. The difference look quite like if you turn on PAL artifacting in Altirra on and off. And that's what's actually happening in my opinion, even if it's NTSC. The first one has more of 50% checkerboard pattern visible, but that's matter of exposure. I use that to decrease percepted flickering. And the second one has that typical 'chroma noise' .. that sub-pixel chroma spikes leaking into luma, typical for composite and HF.

Imho it makes perfect sense. At least in PAL. Chroma averaging in PAL is done to cancel phase shifts cause by HF signal bounces. So it's mainly done for HF signal. But composite input is usually connected just after the HF tuner, before all chroma separation. So chroma averaging affects it too. S-video is fed after chroma separation, so it's not affected. NTSC only TV wouldn't even have the averaging hardware (especially the 1 line delay loop). But modern TVs are universal, they have to handle PAL, so they have the hardware (even if it's more likely something digital these days). And it might actually help with chroma noise.

I could do this effect right in the program, but only for palettes which don't include black, which is used for the 'inside' of the set. Will think about it.

Well it's kinda gray zone on NTSC here. This image uses good old interleaving of luma and chroma lines. That's only supposed to work in PAL. Averaging of chroma from 2 consecutive lines is firm part of PAL color encoding. There is no need for that in NTSC though. Modern TVs usually do chroma blending on composite regardless if it's NTSC or PAL. Some even do it on S-video, even if they shouldn't. I was wondering if I should bother with fixing this image for NTSC by shifting the palette. In the end I did. So I'm happy it was worth it. Looks very true to the original.

Well I turning the ROM off just as the program starts, so whatever you have there is simply not there. You can turn DMA off using M key (only during calculation), there are 3 modes, screen off, Antic D, and Antic E with full kernel. Antic D is about 15% slower compared to nothing, so it's not a huge price for having a preview. I leave the status bar on even in no DMA mode, and PMG is used for showing the current pixel, both of which cost basically nothing. Btw. the calculation itself is done in 160x100 resolution, Antic E is only used to display more colors.

Not color/luma. That was my initial idea, but for Mandelbrot set you need lot of bright and strong colors. So I tried something else. First I tried simple 4 color palette where I would have 4 colors directly, and extra 4 colors by combining neighbor colors in scanline or checkerboard fashion. It works ok, but there is big contrast between these 2 sets. Some colors look solid, and some look scanlined. So I came up with an idea to have 2 different palettes on odd/even lines, where all result colors will be combination of 2 colors, and the palettes are constructed so the brightness difference is about the same. That way all colors looks scanlined to about the same extent. Here is picture where I experimented with the palettes, not all are used in the final program. Even lines palette is on the left, odd lines palette is on the right, and in between you can see them merged together. Note how some palettes go 'around', like black->red->yellow->green->blue->black, and some go 'there and back again' like black->white->black.

Sadly no. I use all 64k. 16k is used for storing the depths so refresh of visualization parameters is faster. If it were just demo, it wouldn't be needed, but for playing with it it's quite useful. There is also 8k for last finished picture, which is not very important feature, but that wouldn't be enough. It's actually quite packed atm.

New program for rendering Mandelbrot set named Fractari was released as part of FLOP 65: http://flop.atariportal.cz/index.en.php It uses scanline GFX mode to get 8 colors, and fast square algorithm for 16, 24 and 32 bits. It then selects the best variant based on zoom. The goal was to create the fastest possible Mandelbrot set generator. Included presets render from few minutes to 1 hour. The basic overview of the Mandelbrot set takes 24 seconds, with preview in Antic D mode. It renders the image in 4 phases, first phase only renders every 4th pixel. This gives you quick preview and you can continue zooming without waiting for the rest, and it's also used to estimate where more calculation is needed, and where the color of the other pixels can be just assumed. After the image is rendered, it allows relatively quick change of visualization parameters, things like palette and color scaling, without repeating the calculation. Other features include: - 3 different DMA modes for previewing the image, from fastest to best looking - preset locations to render nice images even if you can't navigate Mandelbrot set at all - party mode, which just goes through the presets one by one - and more ! I consider this as something of a version 1.0, and I already have tons of ideas for 2.0. Things like built-in help, animation using extended memory and disk operations. Please read detailed description in stand-alone article in FLOP 65. The program supports both PAL and NTSC, and while not tested, it should also work on better CPUs. Nice video about exploring Mandelbrot set, which actually inspired me to make this: https://www.youtube.com/watch?v=riLFpb-PcLs Few images from the program:

Quick hands on wrong place We've just released patch for my Fractari, it didn't work properly when launched from the reader. So if anyone already managed to get Flop 65 before this post existed, and is interested in the program, pls. redownload. Btw. I'll make dedicated thread about Fractari, so if you have question, pls. wait few minutes. And for the editorial stuff, thanks for reading, spread and enjoy. Edit: Fractari thread here: https://atariage.com/forums/topic/308670-fractari-mandelbrot-set-generator-for-8bit-atari/

Usually the NTSC stuff works better on PAL, rather than the other way around. You can always go slower. But going from PAL to NTSC means you have less time during the frame, and especially between VBI start and next frame start. That's where most of the not-prepared software fails. Also the colors are different. Old US made games usually works on PAL, even though slow. But it really depends game from game, demo from demo.

Looks like some high form of artifacting (system/video), or even bloom (screen effects). Both should be off in default settings.

You can actually select how the memory would look on startup in Altirra Testing on real hardware is important though. My issue usually is Altirra loads XEX instantly, where real hardware takes some time, which can show glitches during application startup.

I use latest Altirra, MADS, and PSPad. It's simple editor, has some basic projects, it's easy to configure so you have 1 key compile, with jumping on errors. All I ever needed. WUDSN is worth checking out, if you can stand Eclipse. I can't

Oh I can see the transients, and it's easy to spot the changes in amplitude. I just don't hear any kind of clicks or unwanted noises. The transition is simply smooth. My hearing is topped at 13.5kHz these days, which is kinda sad, but there shouldn't be anything above there here. And I'm using decent earphones ? The worst I hear is the attacking edge (volume change up) sometimes feel more urgent. The release edges sound all the same and smooth.

Can you guys post times of where you hear anything ? I was especially looking at the volume changes, and I can't hear anything weird.

I hear no clicks in WAV nor XEX. I did hear some clicks in Altirra, but it was not present in WAV i recorded from Altirra. So I tried increasing output buffer to 200ms and the clicking it vanished. Haven't had a chance to try it on real HW, but Altirra recording should by cycle perfect, unlike Altirra real-time experience.

Send xex, would be lot more useful.

Your understanding is wrong. What you see is result of the exact opposite. Change of AUDC or AUDF does NOT reset the wave generator. If you look closely, you'll see the phase of the wave is perfectly preserved. When changing AUDF, the new value is used next time the counter under-runs. And there is no way around this. Even if you changed the volume exactly on edge, there would be audible click, as there will be some transient harmonics. And you can't change the volume on the edge in any easy way anyway. The problem arises from the fact there are only 16 volume levels (and it's better to use just 8, so you you don't go over 32 total in all channels, which leads to other non-linear distortions). Changing the volume simply introduces extra signal. That the bad thing. Good thing is it's not really an issue in full song with other instruments. All Atari songs have this. Don't worry about it.

Oh, didn't I promise you demo of my brand new speech synth ? Sadly since all parties is on halt, there is always something more important. So I leave it at 'soon' for now.