Commander X16

To clarify - I'm not saying Ed's strategy doesn't work for several types of programs as well, but for games or things with lots of movement, you really need to do your VERA writing during vblank to avoid tearing and artifacting. If you're driving a menu system or other relatively-static UI, then yeah, you can do all the VERA writing during main execution and just use the vsync IRQ as a timer that bumps a flag once per frame so your program can stop and wait for that value to change in order to begin drawing the next update.

I think the real thing to consider is that you probably need to decide whether you're doing your updates "on camera" or "off camera" and don't mix them.

Quote

This is the most useful post I've seen in months here on the forum when it comes to irq design. Very interesting feedback from both @Ed Minchau and @ZeroByte. Thanks guys. 

 

On 5/26/2022 at 4:55 PM, ZeroByte said:

To clarify - I'm not saying Ed's strategy doesn't work for several types of programs as well, but for games or things with lots of movement, you really need to do your VERA writing during vblank to avoid tearing and artifacting. If you're driving a menu system or other relatively-static UI, then yeah, you can do all the VERA writing during main execution and just use the vsync IRQ as a timer that bumps a flag once per frame so your program can stop and wait for that value to change in order to begin drawing the next update.



I think the real thing to consider is that you probably need to decide whether you're doing your updates "on camera" or "off camera" and don't mix them.

If the only time you access VERA is during the VBLANK, then great, access it then. But if you're using VERA to store sequential data, like @Jeffrey did with the Wolf 3D wall images, then changing any parameters in VERA can really screw things up in a hurry. So I guess it all depends on how you want to use VERA.

Asteroid Commander uses lots of sequential data stored in VRAM for various purposes. If I try updating the screen every VSYNCH or even every third one, it'll stomp all over a whole bunch of things. But if the only time you're accessing VERA is to push data to the screen and PSG/PCM, like I was doing with the Balrog video demo, do it all in the VBLANK.

It really depends on the use case.

On 5/27/2022 at 9:27 PM, Ed Minchau said:

Asteroid Commander uses lots of sequential data stored in VRAM for various purposes. If I try updating the screen every VSYNCH or even every third one, it'll stomp all over a whole bunch of things. But if the only time you're accessing VERA is to push data to the screen and PSG/PCM, like I was doing with the Balrog video demo, do it all in the VBLANK.

Ed, may I ask, does the technique to process the VBLANK in the main loop (outside of the interrupt) help with the frame rate? I mean, I notice that during my IRQ processing, that if the CPU time goes beyond the available time to process one frame, then the logic "stutters" and is noticable. When processing the frames in the main loop, this might help, isn't it? because the main loop can just take it's time to paint, while the interrupt will handle the coordinates of the objects to be painted ... hmmm... might consider.

@svenvandevelde - I know I've asked before, but this is written in C, right? (although, if memory serves, not cc65)

Kick C, in progress by @Jesper Gravgaard.

It is the most impressive work I've seen in years. If your code is well written, it generates FAST code that I've never seen. His methods of SSA and code optimizations is something I've never seen in a compiler for the 6502 family.

That being said ...

It has a steep learning curve. Not the language of course, which is C, but learning how to witte you code so that your xode becomes optimal. So looking at the generated assembler is how you learn how to apply the most ideal language constructs. And that is where people struggle...

The compiler works with a fragment system that contains hundreds, if not thousands, of 6502 assembler  code snippets that are used to generate the assembler.

It has taken me about a year to come to this result. I've helped Jesper to write many fragments that were missing. 

Fragments are needed as a result of missing combinations of C code constructs. For example a fragment that implements how to assign an char  element in a struct indirected by a constant pointer with variable offset from a byte in memory, assigned from a signed byte indirected by a constant offset from a variable pointer through zero page.

It takes time to learn the compiler and how to use it. It is not perfect yet. It had defects and its error messaging is good but incomplete. Sometimes the compiler will crash and it will take you about 3 weeks to find out why it is crashing. 

Of course I've also downloaded the code from github and now I'm at a level where I can debug and correct the compiler code where needed. 

But besides all that, the result is there. 

Through its users this environment will become better. Users like me who persevere. Jesper had been helping me in the background with bugs and also writing certain fragments. 

I've been debugging his code of the compiler to find crashes and intercepting the exceptions to get meaningful error messages and to know WHERE it complains in your code. 

But the core of his compiler is solid. 

If your are interested we can setup a discord session and I'll explain you my current environment. Or I'll record a video how to use it ...

I am working from a fork from his compiler and have written lots of code for the CX16 as libraries for use by others. 

Vera library, heap, banking... etc ...

Let me know if you're interested in this offer. Jesper is a bit offline now due to his personal obligations but I can help you a lot getting you started if you want. On discord. 

 

I was wondering what it might take to make Zsound integrate with your project - I just got done with my first non-trivial hybrid C/asm project and was thinking I may go ahead and make C wrappers for the code, but it's for cc65.

I think the shortest pathway to other compilers/assemblers would be to build a "player" that you load into memory somewhere and interact via a jmp table at the head of it.

The thing I think might be the most problematic is the ZP space. Other than that, it stays in its lane and will eventually require 1 dedicated bank of working space (which you will signal at init() time)

i see ... indeed, i will need a memory segment where your music player runs in. No way to compile this or link.

A direct memory load and a jmp, that"s it. How many zeropage does your music player use?

Put it at the highest top of the main ram, and pls minimize zeropage usage.