Chimera Kernel Submissions

[mos6507]

Now, we don't yet have beta carts to give out, but there is enough interest in seeing different kernels on Chimera that I thought I'd open up a regular thread here so you can submit them for me to run on my cart. I know it's kind of weird, but this should work if you know what you're doing.

 

To start things off, I'll post my current demo source which you can use as a foundation. It should be fairly self explanatory. Any questions, please post them here.

 

Assemble your programs as standard 4K ROMs. No bankswitching. These will operate in Chimera with magic writes enabled. So you are free to write to the cart as if it were regular ram. Take a good look at the chimera header to see where all the hotspots are and how to set up the queues. In the example I posted, I have to step-index the queues by 2 and seek them to start on 0 or 1 on each frame to get them to display properly. You'll want to do the same to match your data interleaving (if any). If I set the seek to 1, it has the effect of making the fonts double height which is kind of neat.

 

Chimera.zip

 

So the current objective that Supercat is trying to reach is a gapless Stellar Track style display with the max amount of columns while still allowing for per-scanline playfield and background color changes. All registers would be updated by queues.

 

Another obvious choice is a queue-based Suicide Mission kernel. That one is a little harder to work with because it puts gaps into the graphics. It's not appropriate for all applications. I'm also not exactly sure how the data is organized.

 

You're not going to see anything but a solid or blank screen on emulators so you have to kind of guess what's going to happen. But if I can get the kernels to run I'll post a pic/video of them in action.

 

Have fun.

[mos6507]

Supercat, I can't get the shimmer to work on your 13-column kernel. Could you just modify it for that? There is also something weird going on at the top of the screen. It's important that if this be used that it starts and stops cleanly without any tearing or anything.

[supercat]

Supercat, I can't get the shimmer to work on your 13-column kernel. Could you just modify it for that? There is also something weird going on at the top of the screen. It's important that if this be used that it starts and stops cleanly without any tearing or anything.

 

If the kernel has to share the screen with other kernels, then it will be necessary to either add explicit code to set up the sprites before the 13-character kernel (probably burning one scan line--maybe two) or else simply use the 13-character kernel with at least four blank lines at the top (so any tearing won't be visible).

 

If it is merely necessary to have gaps for computation between instances of the same kernel, then you could simply make sure that the later instances of the kernel start where the earlier ones left off; you could avoid losing a scan line in that case. Note that if you run the kernel for eight scan lines each time, you'll use the same entry point for every row of text.

 

I threw that kernel together to demonstrate how such a kernel could work. It's a little sloppy on startup, but for demonstration purposes that shouldn't matter too much. Note that the foreground and background color are loaded on a per-line basis. The code could easily be modified to load COLUPF instead of COLUBK; if separate copies of the code were used for even and odd frames, it could also be modified to load COLUPF and COLUBK on alternate lines, or to load them both, every other line, etc. It could probably even load the foreground color every line while loading COLUPF, PF1, and PF2 on every other line. What would you be wanting to do that wouldn't fit within the kernel?

[mos6507]

I threw that kernel together to demonstrate how such a kernel could work. It's a little sloppy on startup, but for demonstration purposes that shouldn't matter too much. Note that the foreground and background color are loaded on a per-line basis. The code could easily be modified to load COLUPF instead of COLUBK; if separate copies of the code were used for even and odd frames, it could also be modified to load COLUPF and COLUBK on alternate lines, or to load them both, every other line, etc. It could probably even load the foreground color every line while loading COLUPF, PF1, and PF2 on every other line. What would you be wanting to do that wouldn't fit within the kernel?

 

I think I was more interested in the extra column width of resolution than anything else. I would currently like to take your kernel, have it flicker properly, and make it so that I can use equates to control how many rows per screen and how tall each row is--similar to the kernel I'm using now. Then if I want gaps I can have them and change any registers I want at the row level. Without gaps then you will only be able to change one register, but per scanline, not row. I would prefer the flicker to be done in such a way that does not require alternately shifting it upward and mandating unused queue indexes at the top. This is because this would confuse the way the ARM text renderer looks at the memory map.

 

Combining that kernel with another kernel on the same screen isn't really on my radar right now.

 

As it is now, I could drive it with queues but without the flicker going, you'd see all the gaps in the fonts and it wouldn't look that good. So I haven't bothered wiring it up yet in the hopes you'll finish it off for us.

[+Random Terrain]

Nice to see things moving along.

[supercat]

Okay, this version shows the kernel running three times. The funny bit of flicker on the edge of the second one is a result of using INTIM rather than a queue. As implemented, each group must be a multiple of four scan lines except the last, which must be a multiple of four, plus one. Alternatively, one could have all groups be a multiple of four scan lines, but then have an "oddball" that just ran for one scan line.

ATEXT.ZIP

[mos6507]

Okay, this version shows the kernel running three times. The funny bit of flicker on the edge of the second one is a result of using INTIM rather than a queue. As implemented, each group must be a multiple of four scan lines except the last, which must be a multiple of four, plus one. Alternatively, one could have all groups be a multiple of four scan lines, but then have an "oddball" that just ran for one scan line.

 

I'm looking through the code and I'm having a hard time knowing where the number of scanlines per row is set, or the number of rows per screen. Can't this be done at the top with equates?

[supercat]

I'm looking through the code and I'm having a hard time knowing where the number of scanlines per row is set, or the number of rows per screen. Can't this be done at the top with equates?

 

Each row runs until it fetches a background color value of zero. If you want a black background, use a value of "1". Since queues don't actually work in emulation, I used INTIM instead of the background color queue. When INTIM counts down to zero, that marks the end.

[mos6507]

I think that's a problem. In my existing kernel, there are no black lines around rows. The screen is just a solid color up until I want to highlight a row.

 

I understand why you are doing this, to try to dual-purpose a load operation, but I picked a blue background to try to reduce the contrast a little bit and help out with the flicker.

 

ldx QUEUES+13

lda INTIM

; ** CYCLE 69+

sta.w HMOVE

bne RPlp{1}b

 

Could I replace the LDA INTIM with a compare operation instead so I can designate any number as the row separator?

[supercat]

ldx QUEUES+13

lda INTIM

; ** CYCLE 69+

sta.w HMOVE

bne RPlp{1}b

 

Could I replace the LDA INTIM with a compare operation instead so I can designate any number as the row separator?

 

The "LDA INTIM" should be replaced with a load from a queue; the value being retrieved sets the background color. The background color for the first line is set by the value in the accumulator when qzt is called (sorry I forgot to document that); the zero byte that's retrieved from a queue is not stored to COLUBK.

 

Using zero as a row separator shouldn't cause any problem, because only the upper 7 bits of the color register matter anyway.

[mos6507]

Using zero as a row separator shouldn't cause any problem, because only the upper 7 bits of the color register matter anyway.

 

I get that. The problem is aesthetic, being forced into having a black line between rows. That might be ok for some kernels but I'd prefer not to have that in the menu kernel which currently has a solid blue background for all but the highlighted row.

Edited July 4, 2008 by mos6507

[supercat]

I get that. The problem is aesthetic, being forced into having a black line between rows. That might be ok for some kernels but I'd prefer not to have that in the menu kernel which currently has a solid blue background for all but the highlighted row.

 

Why are you forced to have a black line between rows? The background color for the first row of a line is set by what's in the accumulator. The color for each row after that will be fetched from the queue. After the last row is displayed, the background color will be left as whatever it was on the last row, but there will be time to change it, if desired, before the next row is displayed. The background color for the first row of the next line should be loaded into the accumulator before qzt is called again.

 

Requiring that the color of the first line of each row be somewhere other than the queue may be a slight nuisance, but I can't see why it should cause any major problem. If the display starts with a dummy read of the color queue before the kernel is invoked, then if you want 8-line rows of text, your queues should look like:

Shape: R0.0 R0.1 R0.2 R0.3 R0.4 R0.5 R0.6 R0.7 R1.0 R1.1 R1.2 R1.3 R1.4 R1.5 R1.7 R1.7 R2.0 R2.1 etc
Color: ---- R0.1 R0.2 R0.3 R0.4 R0.5 R0.6 R0.7 #$00 R1.1 R1.2 R1.3 R1.4 R1.5 R1.7 R1.7 #$00 R2.1 etc

The values for color R1.0, R2.0, R3.0, etc. must be stored elsewhere (perhaps in another queue). R0.0 could be stored in another queue, or at the top of the main color queue.