R0ger

There actually was a disco ball in the hall

Great party ! Great sausages !

What !? You can do THAT ? I've been pulling my hairs over settings in registry for years !

Wow, that's quite powerful, didn't search in breakpoints .. will try. Now let me set these dynamically in the code, same as asserts .. and obviously it has to work from macros Just kidding .. anyway .. again I'm fighting some shitty little misplaced memory write which only very rarely crashes the program. Would be nice if I could tell at every subroutine what memory ranges it's allowed to write, and break on everything else. But that seems to be still long way to go. I'm thinking about detecting misplaced write by analyzing the logs. I know at what procedure I'm at, I can define safe ranges, and report anything outside of that. Good thing is I can do it after the error occurred, and I can add search conditions without need to rerun the code (and reproduce the error). So in the end the log analysis might be even more powerful.

Is this right place for Altirra related questions ? I need to log memory writes .. just PC, destination address, and value. I found how to log tons of thing, but not this. Thanks !

Eh. Uhm. Sails of what ? Who said that ? Well I have some good news, and bad news. Bad news first. The game hasn't been worked on much this year. The initial drive was over. The fun parts were done. Other ideas came in. The usual stuff. Now the good news. The game is planed to be released this October (on Bytefest). While it won't be complete on Fujiama, there will be some improvements compared to the version you've seen last year. I hear there were some keen beta testers there and I want to use the opportunity. Also me, the humble author of this gem of a game, plan to come this time, so we can fine tune the gameplay on the spot.

Czech guys are coming !

Lol that's nuts !

Looks real nice, but $40 ? Cartridge only ?

I did some minor programming in Forth and I must say it's exactly like the image depicts.

Pretty much what I experienced. When writing right after wsync, I could write up to 8. With one extra nop I could write 10. With 2 nops I could write 12 and with 3 nops the dlist didn't break even with 15, but there were still visual glitches. 4 nops seems to glitch-less. That's with 40 characters width.

That puts the write EXACTLY where it must not be For me wsync and 4 nops solved the problem.

Certainly the third thing. Didn't notice it, I only quickly read sections directly containing word hscrol, and somehow I missed it. But that's exactly what's happening. Kudos to Phaeron for implementing so well !

I'm doing my experiments with PAL artifacting, I have simple program which display bitmap in 320x200 mode, and that's it. Now I added 'calibration' into the code. It scrolls the image a bit when I press keys 1 to 4. I use HSCROL for that. But I run into interesting problems. First some more info: The code turns ROM off, all interrupts are pointed at RTI, and disabled. The code just sets up the display, and uses bitmap linked into the XEX, which is generated outside Atari code. The display list is simple, 200 lines, address is set on every line and hscrol is enabled. Dlist is looped using Dlist instruction, not in VBI. As I said, there is no interrupt. This worked fine. Then I added simple loop, which reads keyboard, and if 1 is pressed it writes different value to hscrol register. Thing is the loop is not synchronized in any way. It runs as fast as possible. And time to time, when I pressed the key, the image disappeared. Altirra shows that Antic reads display list from completely wrong location. The CPU running fine, continues the loop. So today I did some testing with Bob!k, we double checked everything. In the end we removed all keyboard reading, and left simple code: loop lda random sta hscrol jmp loop This causes the problem every time, and fast, in less than a frame. Antic simply looses the way. Now .. Altirra emulates this quite well. Everything we tested about this worked the same on real hardware. But reading through Altirra's hardware reference I didn't find this problem. There are many hscrol related 'bugs', but everything described just seem to make Antic read false data when reading VRAM .. not Dlist. Or at least that's the way I understood it. In my case it seems Antic reads false data as Dlist, which makes it miss the Dlist jump instruction. So we added sta wsync into our code, just before writing to hscrol. We found, that we can write numbers up to 10 into hscrol. 8 was fine. 9 and 10 showed false data in the image, 11 killed the Dlist looping. In the end we found 4 extra nops after wsync make everything run smooth even with 15, and that's where I left it. It clearly isn't anything new, I just don't know which of the 'bugs' described in the reference it is. For sure I never suspected writing to hscrol at wrong time can kill your Dlist. Have anyone encountered this problem ? Is there some recommendation when exactly write to hscrol ? Does this apply to some other registers ?

I did some experiments on real hardware with Sega controllers. There is one issue. Sega controllers do have onboard chip, and it seems to send all lines through it. But their wiring is different than Atari. They expect +5V on pin 5, Atari has it on pin 7. Thing is, it actually works. The chip takes the voltage from signal lines. It then sends the second button into pin 6, which is pot1. It also connects the pin to ground, not to +5V, as paddle would. So you get inverse logic. Non pressed is +5V, pressed is 0. You read 1 from pot register for non-pressed state, and 224 for pressed state (or anything in between, depends on WHEN you press it). Bob!k, who was discussing and testing it with me, was VERY unhappy about feeding the chip from signal lines. And I guess we at least try to rewire one of the controllers. But I like the idea that it actually works with no modification at all. I made the software detect automatically what value the pot is at the beginning, and then I treat any change as button press, and it seems to work fine. Of course, if you modify the controller to feed the chip correctly, and/or to send the pot voltage the correct way, it will still work. Or if you make your own joystick which will just connect pot0 or pot1 to +5V. Btw. we tested the games mentioned above. Gem Drop correctly reads the button, so it must work somehow like I do it. Except the game doesn't really need the extra button. Weird choice to implement it. As for Tetricize, it either didn't work, or I didn't found out how to set it up.

I came to the same conclusion over night. That the white pixels might have exactly opposite phase on up edge and down edge, and they cancel out. Which would be perfectly correct, just unlikely on real hardware. Color adjustment in Altirra even has artifact phase and saturation, which should be the solution. But it does nothing. No artifact slider changes anything for me.

Oh I forgot to include the XEX .. Artifact-1pixel.xex

Here is the case of difference between Altirra and real hardware. Here there is the most simple pattern. 1 pixel per each byte. On left half of the screen only even rows are used, on right half only odd rows are used. The pattern is changing set pixel location from top to bottom. You can see how every pixel position corresponds to different hue phase, and how the even and odd fields (left and right half) have mirrored hue phase. Now here's the catch. On real hardware every pixel position creates false color, and to about same extent. Which is as expected. Altirra shows correct hues, but only on pixel horizontal offset 0,2,4,6. On offset 1,3,5,7 there is simply no color, pure white. IMHO it's no principal issue of how Altirra does it, most likely it's just simplification, or even speed optimization. In my experience it has pretty low effect on more complex images. But still .. maybe it's really simple fix ? Pretty please, dearest Phaeron Real hardware (XE, CRT TV) Altirra:

Finally got to test on real HW .. and indeed I can also get different setups every reboot. I get one setup in like 80%, but not always. Also I'm starting to noticing more differences between real HW and Altirra. It's nothing which would allow this technique to be any better though. Will report later.

Very nice ! Thanks for testing !

So I have image converter working. But it's all very clunky. You have to fine tune it to the picture a lot. If the image is too bright or too dark, it wont result in about 50% pattern which you need for color encoding. Then you have to balance focus on detail and focus on color. You can't have both. And you have poor resolution in hue anyway. Photos in general are pretty bad. What works lot better is anime. Like Pokemon. Big shapes, bright colors, but only few of them in the image. Like this: And source image: Here is the XEX, please note that it does not have any phase calibration, so the colors might be completely off on you computer. There should be some colors though. Pikachu.xex

Huh .. just got an idea right before going to bed .. and I had to test it .. what if we don't use white, but some actual color ? Would the hue shift be strong enough to be seen ? To create some completely new hues ? Well here is the answer, just on the red ($20/$2f). Other colors looks nice too, but on red the change is the strongest IMHO. Nobody can laugh at ATARI reds anymore ! Artifact4.xex

I'm still far from the image convertor. I keep experimenting with the stuff, some things still don't feel intuitive enough. Anyway, I was trying to make as many distinct hues as possible. 6 are everywhere, 8 are in my last demo, now I managed to do 16. The extra hues are made on the even lines. I can either use correctly reflected V coordinate, or I can also shift one step. That way even and odd line create 1 step different color, and they are mixed by PAL. I can't make more colors like this though, because if you differ the vectors too much on odd lines, you will simply loose saturation and go to white. Artifact3.xex

Hmmmm ! I'm actually quite deep in the image convertor. I went for Floyd-Steinberg dithering, which is centered around error correction. I can easily say in some places 'no, you can't put bright pixel here', or 'only this or this hue can be used here' and the FS dithering will handle it just fine. At the moment I think in HSV, but YUV sounds as better idea indeed. Damn you artifacts, I want to play Dark Souls Remastered, but how can I ?

There are colors, but it doesn't look like they are intentional .. if so the artistic choices are weird at least.