R0ger

So .. with this new wisdom I gained, here is new demonstration. I'm trying to generate all hues possible. In the process I realized I have a parameter for pattern 'density', and it almost works like luma. So in the demo you can see hue changing from top to bottom, and this 'luma' changing from left to right. You can see that patterns around 50% of density have best resolution in hue. As the patterns get too sparse or too dense, they can't encode phase well. Basically you have yellow, blue, red and green .. and the rest is mix of these. How do I compute it ? First the convention. I use interval 0..2 for all phases, i simply discarded Pi from all the equations, I don't need it. For each pixel I compute current luma phase, which is simply 0 for even pixels and 1 for odd pixels. Then I also for each pixel compute expected chroma phase, based on X*5/4. Its a bit 'slower' then luma phase. Then on even lines desired hue is added, and on odd lines hue is subtracted from it and 0.5 is added - this gives me correct desired hue phase. Then I do the delta of these phases, and normalize the delta to lie from -1 to 1. For constant hue the value would change from -1 to 1 repeatedly across the screen. Then I only draw the pixel if the phases don't differ too much. If the delta is lower then my desired pixel density, let's say 0.5, I draw the pixel, otherwise I leave it black. In this image the density used goes from 0 to 0.6, more than that gives mostly white area. I will try to do some image converter. The pixel density is not really luma, it's more like ATARI palette, and I have no control over saturation, but who knows, maybe I can do something interesting with it. Artifact2.xex

Thansk Phareon, nice explanation. We were basically right, we just didn't have the right numbers. And I didn't realize that yellow and blue are 0 and 180. I kept thinking in Atari colors .. 0 phase must be white. Which is nonsense. Zero amplitude is white. All makes sense now. And great job on Altirra. The only difference compared with real HW is the colors a bit weaker, and checkerboard pattern doesn't do anything. On real HW it shows red and green stripes 4 pixels wide. But it's really minor issue, I wouldn't bother with it.

Well PAL blends the colors better, but they will blend as eye can't tell the individual pixels anyway. The same technique is used on VGA and higher, where no artifacting or line blending happens. That's simply dithering. Also we typically don't call PAL line mixing as artifacting. We were experimenting with this on our today's local Atari meeting. We tried big LCD TV and two CRTs, and 3 different Ataris. We got 2 different phase cases (color layouts, what you have to choose in the beginning of the game). And it seemed to be computer dependent, not TV dependent. No idea what causes it. Most likely the TV is synchronized to different line, so what's even line in one case is odd line in another case ? Not sure. Still the colors are pretty bright, even the modern LCD ! We also had vivid discussion on how it actually works. And we came to no conclusion. It's clear the pattern repeats after 8 pixels. Even if you do simple checkerboard pattern, you can see red & green stripes 4 pixels wide. It's clear the individual lines have to be different, because of inverted PAL chroma phase. If you use same lines, the effect cancel each other. Theoretically. But then there are patterns where this is not true (blue & yellow). Why ? I think the general principle is it's simply interpolation of 2/5 chroma sub-carrier by the luma signal (pixels). But I couldn't come with any clear formula, especially why it does repeat after 8 pixels ? Makes no sense. Phareon you here ? You know, right ? Right ?

Tested it on real hardware and CRT, and the colors are way more vivid compared to Altirra. It looks great ! Also made quick test project to play with it, so far I just reproduced the effect: Artifact.xex

Wow, really nice ! Not that I have any use for it, but it sure look great ! Can't wait to test it on real HW.

I think he means simply color dithering .. using 2 different colors on the same line. The chroma will merge quite well actually. And I must say I didn't see much of it used. But I don't know Atari software that much. I use red-blue dithering to get very nice violet in my current WIP (still undisclosed, but will go public soon). On some TVs you can't tell it's not extra color.

Well I can't tell NES displays 228 lines just fine. I have no way to test it, I'm surrounded by PAL machines I just can see that NES (well I checked SNES, but it might be the same) games, as well as SEGA games, typically have 224 (28x8, 228 was a mistake) pixels in emulators. Info on misc Japan consoles (NTSC based), from quick googling: NES: 256x240, but only 224 recommended. SNES: 256x224 SEGA Master System: 256x192 SEGA Megadrive: 320x224 Ok, it just makes no sense ..

Well there is no need to have display list and VRAM anywhere near, I certainly never thought about it. But that's not the problem .. problem is I want to use as much as possible. 192 is safe. It's also very small number. Btw. any idea how for example SNES and SEGA does 228 lines on NTSC ? Because clearly they do.

Hm .. went through some old games .. and many actually have 192 pixels only. Still can't find anything official, or some recommendation.

Try settings reset, and then try again. You most likely just turned something on or off, happens to me all the time.

I use Altirra for that too. Most of the time you have to shift hues 1 up (ie add $10 to every color code). Exceptg grays, of course. But I know how PAL machines can differ one from another, so I guess there simply cannot be universal solution.

Well I kinda want BOTH edges of the image visible And I want to know how to assure that to reasonable degree.

Btw. what are the official screen size recommendations ? I know many games use 200 lines. That's very conservative on PAL, but I've seen NTSC screens that didn't show even that. Also, if 200 lines .. what should the top offset be ? Dlists I've seen mostly start with 24 empty lines. I know it's ok on 200 lines PAL, but what about NTSC ?

Very nice, it even supports multi-trigger scheme ! So generally making game support (not require) paddle triggers is good idea.

Thanks ! My game is actually kind of puzzle game, so this approach seem to be perfect. First there are existing already working gamepads. Second if you wanted to convert existing joystick or build your own, it's simple. Third games already exist which supports the solution. And I don't even have to come with a name for it, as it's simply Sega. The next topic is about extra hardware .. not really what I'm interested in, but interesting read. NES controllers or generic HID would be nice too, but these days most gamepads are based around analog joysticks, and they are not very useful for 8bit gaming.

Wow .. I thought Sega uses some complex multiplexer .. but clearly not. 2nd trigger is simply on pin 9. It's bit more complex to get more, but this would be enough for me. Thing is I actually have some Sega controllers, and I know they work with Atari and 1 trigger. Maybe all I need is just to try reading the paddles.

That would be powerful and elegant .. but then it would be hard to make joystick which supports both standards. And you don't need THAT many fires most of the time.

Not sure how it works (don't understand German) .. but it seem way too complex .. I'm thinking 1 extra fire, the same scheme NES has and many other consoles of the time. It's also simple modification to the joystick. Most of them already have 2 buttons, you would just need new cable.

Howdy ! Was there any attempt to make controllers with more than 1 fire button ? I mean as separate control input. First you would need a way to use it on Atari. I think it would be possible to use paddle hardware for detection (and it would actually allow for 3 separate fire buttons). The you need software which supports it, but modifying existing games (where it makes sense) would be simple. I'm actually working on a game where 2 buttons would be nice. And then you would need the joystick. But at least here in Europe we mostly build new ones or make a major repairs on old ones, it's not a big deal either. The cable with enough lines can be a problem, but with those cheap Chinese extension cords, it's doable. I want to know if you heard about anyone trying it, doing it, if there are games supporting something like that, old or new, and what do you think about the idea in general.

IMHO it would behave differently at different frequencies. If you want 1/16 pulse, you want 8 times higher frequency, just with 7 from the 8 pulses being suppressed. I guess it must the analog circuitry not catching up. Maybe try reading the signal with oscilloscope right of the POKEY pin.

You just need to discuss price

Which reminds me, there is MJ tester done by Raster, up to full 16 joysticks. It was on Flop 50, here included for your convenience. Mjtester.xex

I'd call it 4 by 4

That's actually great. I mean the fact the 1/16 signal doesn't have to run at sample frequency at all. You can the 8kHz sample rate without the 1/16 signal being audible. Simply run the 1/16 signal as high as real hardware can reliably mix it.

Damn that's smooth. And such a simple idea ! Great job !