R0ger

Let's see this thread. You make title, which really doesn't make any sense. You link to XXL work. OK. Then you claim it would work better in character mode. People with lot more experience come, and say no, it wouldn't. Basically everyone who joined the discussion made similar type of engine in past. Then you show game, which is completely different, which could really work well in character mode. You say 3D is 3D, so there is no difference. You also claim C64 only has character mode. So yes, you may have meant it well. But most of what you said was just wrong, and you didn't even accept. So don't expect other to take you seriously. Also your criticism may be meant well, and I take it as such, but some people don't. And I much rather lost you than let's say Fandal, who basically left AA after what you said about Stunt car racer. Maybe it's just communication. Most of what you write sounds like you are mocking people. It's not Antic D ! Listen to 99% ! Maybe try to clearly say that you mean well, and if you mean something as a joke. It's not passed easily in written language. I know especially us Slavic guys are very tough on this. We don't hint sarcasms at all. But we are also lot better at picking it up. But look at Americans. They will start the post with several sentences praising the authors, expressing how happy they are. Then they add criticism, and if they mean it, they will apologize once more. And if they don't mean it, they will openly express it was meant as a joke in next sentence. It seems silly to us, but it makes things much clearer. I certainly mean everything I write in the same way. And I actually believe you do to. We just don't communicate it so well.

I don't get the reference to NMI/IRQ thred (which is mine ?) .. I accept you as Atari fan. I don't accept you as coder. Simple as that.

Well as long as he's funny mascot, it's ok. His attempts to energize active coders are quite counterproductive though.

There is big difference between bug report and criticism 😉

Amount of threads he derailed might be over 99% though .. Anyway, you know how your friends post these deep quotations on facebook, and they are silly or right out stupid most of the time ? Well today I got this: Don't take criticism from people you would never go to for advice. Accredited to Morgan Freeman, but I bet it must have been some AA member ..

Thanks for insight phareon. I have yet to test it properly on real HW. I have reports that this version with one NOP sometimes flashes the colors too. I think it might need 2 NOPs. As long as the time between checks isn't long enough so that DLI is fired twice, it should be OK. This IRQ bass can't be used in character mode, and you must avoid writes to WSYNC, as both mess timing so it can be heard. Typically it leads to IRQ being missed, which creates nasty click in the audio. Still it allows at least for some graphics on the screen.

Yes, I know, Mapa already pointed that to me via PM. Doesn't matter what line you are. Just what cycle on the line. But post #6 still holds. It doesn't matter at what cycle Antic fires the IRQ. It depends on at what cycle CPU starts to handle the IRQ. And that depends on current instruction. In other words, you can't control it.

I don't use ROM, some nothing of this really applies. Also the problem isn't that NMI is invoked twice. The problem is that if IRQ and NMI are invoked at the same time (simply speaking), CPU only calls IRQ handler, not NMI handler. I read NMIST twice, because there is like 6 cycles (don't know exactly) window, between NMIST being set and NMI being invoked. It's something like this: 1) is NMIST set to DLI ? 2) .. NMI should happen any moment now .. 3) is it STILL set to DLI ? 3) if so, NMI didn't happen Note that it requires NMIST being reset in DLI handler.

Aaand it's nonsense actually. Antic will trigger IRQ on odd cycle, no problem with that. But CPU will trigger IRQ only on instruction boundary. Of course I had to test it for 10 minutes before realizing why it doesn't work

Interesting idea. I would just have to start the IRQ right, and keep DLI on even lines. Will try.

That's intentional, the width of the square wafe is modulated. That's one of the features of this approach. If you turn on audio monitor in Altirra, you'll understand.

So I'm playing with this bass .. Thing is it generates tons of random IRQs, which is quite limiting for DLI. But I'm thinking, if I can make the DLI fire, with some delay, I can work with it. But of that's the problem .. when IRQ comes in right time, some DLI will not fire. I made little test which detects the problem, simply by expecting the DLI to fire on every second line, and comparing expected line with VCOUNT. It's the first XEX. You'll need Altirra if you want to emulate it and enable NMI/IRQ collision in CPU options. Every time there is mismatch, VCOUNT is loaded into COLBK, so you will see colors flash on the screen. Now the idea was I could use NMIST to detect if NMI overlap happened during IRQ handling. And it's not so simple. First, NMIST is not reset between DLIs. VBI sets it to VBI. First DLI sets it to DLI and it stays there. So step number 1 is to write to NMIRES in every DLI. I do it as first instruction in DLI handler. Second problem is that NMIST is set on cycle 6. But NMI itself is invoked few cycles laters. So situation can (and does) arise, that you read NMIST in IRQ handler, it is set to DLI .. but DLI will be handled properly just few cycles later. I solved this by reading NMIST twice in a row, with exactly one NOP in between. One seems to be enough, without it it still can all happen before DLI is actually fired. So there is code like this in the IRQ handler: lda nmist nop and nmist bpl no_collision collision ;act like it's DLI sta nmires ;do what you gotta do no_collision ;continue IRQ handler And it seems to work ! At least in this test of mine, it's the second XEX. I'm not trying to do anything specific inside the 'fake DLI' section, I just INC the zero page address I use for detection of missed DLI, to prove the concept. Have you tried to solve this problem ? Have you succeed ? Do you think there is some more problems ? IRQ1.xex IRQ2.xex

I'd say Qbert isn't 3d, but Crystal Castle is. The collision are clearly computed based on true 3D coordinates.

I have no idea what he's talking about. Not that it matters.

Just don't care about what random people online write. Do what you like. You can never satisfy everyone.

I wouldn't go as far as claiming I know what Emkay wants

I made Doom like game for Palm http://www.questions.cz/preview.html. Game like this is imho perfectly doable, as Project M shows. But I don't think it would be fun with joystick. Also the resolution is really low. The ratio of invested work and obtained fun just doesn't seem reasonable to me. And it's really not about this mode or that mode. If someone want's to invest the time, he will find a way. Even if you just picked up where Project M finished.

You don't avoid rounding in operations. You do avoid rounding in conversion to and from text. That's sometimes significant. But I'm not sure it's the reason.

Here are some first tests. It's just one channel for the bass. The first one is just the bass, 3 octaves bellow standard A distortion. It's very naive approach, simply handle only every 8th IRQ. The second one plays major chord, so you can see (hear) how it's all perfectly in tune. The bass is moved one octave higher. The color is changed during every IRQ, even those I skip. IRQ1.xex IRQ2.xex

It is described in detail in the video in the first post.

I got another idea. This demo uses 2 channels to generate IRQ. For precision, but mostly for range. What if we used just one channel ? Sure 64kHz/256 is about 250Hz. That's too high for real bass. But what if we ignore every second, or every 4th IRQ ? That will give us 2 more octaves, with no penalty on precision. And we know the bottom octave of standard A distortion on 64kHz is precise enough. We would get about 10 IRQs per frame, that's the price. But we would gain another channel.

So PG just discovered interesting song. Atari song. Old one. 1994. And as you might notice, the bass is especially good. Perfectly in tune. Super deep. With perfectly controlled PWM. And we even have the scope. It's clearly PWM rectangle. So distortion A, 2 channels, filters, 15kHz, and some pretty good skills in controlling it, right ? But wait ! The other two channels are A too. Nice rectangles. And not 15kHz. They are high notes with vibratos, you can't do that in 15kHz. So .. how ? Here is SAP converted to xex (credits again go to PG, whose skills in controlling winamp are unmatched, at least by me) Mental_Age_Demo.xex Little debugging in Altirra showed the secret. It's completely new approach, at least for me. It is normal 64kHz mode. AUDCTL is not touched after the music starts. Channels 0 and 1 are perfectly normal, updated in VBI. Channels 3 and 4 however, are joined in 16bit counter. But it is not used to generate sound directly. It is used to generate IRQ. And the frequency is not set to fixed frequency, like for example in Hardbass approach. It is set exactly for the next edge, and the frequency is changed after each edge. Example: we want to play 100Hz with 40/60 pulse width. That means there is up edge, 0.004s pause, down edge, 0.006s pause. And again. So as I said, the channel 3+4 are set to trigger IRQ. .. CPU does other stuff .. IRQ fires. We set the output of channel 3 to direct mode volume 8 (up edge). We set the frequency in channels 3+4 to 1/0.004s. RTI. .. CPU does other stuff .. IRQ fires. We set the output of channel 3 to direct mode volume 0 (down edge). We set the frequency in channels 3+4 to 1/0.006s. RTI. .. CPU does other stuff .. And again, and again. The frequencies are updated in VBI I guess. Didn't dig too deep into that. But the main principle is clear. So let's see the advantages: - perfect 16bit frequency control, also allowing super deep tones - PWM possible with basically no limitation - 2 channels needed with no limitation imposed on other channels - small CPU usage. It's only used on edges. So for common 100Hz bass the small piece of code is called 4 times per frame. And there are of course disadvantages - IRQ can and will collide with DLIs. - suitable only for low frequencies, ie. bass. CPU load rises with frequency. - it's not easily patched into RMT, nor any other tracker I know of. So .. have you hear about this one ? If so, why the hell didn't nobody tell me ?

Ok, ignore please. I forgot it's called 'theme' these days ..

Can't find the dark skin in the new version. Is it here hidden anywhere or is it gone ?