Jubatian's kernel hackery

[Artcfox]

That sounds pretty awesome. I'm looking forward to see what you're able to do with Mode 74.

I'll see what I can accomplish by exploiting the pre-vsync callback.

[Artcfox]

So this seems a bit embarrassing, but with both your kernel boost kernel (and with the original kernel) I can add:

Code: Select all

__builtin_avr_delay_cycles(23000);

to the end of my main loop before wdr reports that I'm going above 400K clocks. I can go a few thousand higher, but then my worst case code path ends up triggering a missed vsync.

Did I seriously leave that many clocks per frame on the table?!

To put that into perspective, my main loop only takes around 8000 clocks per frame, maybe 9000 in the absolute worst case.

[uze6666]

Wow, I leave a couple months an Jubatian creates a new better kernel, a new better emulator..and two video modes!

We will have to discuss how to bring all that neat code into the main repo. For now I'm thinking about keeping the current one for backward compatibility and create a new /kernelv2 folder with your new version. Same for cuzebox and your new vmodes when all are stable and done.

[Jubatian]

I would add video mode 74 and 90/92 to the master repo after the UCC deadline, I would say they were sufficiently tested then (both are used in UCC games, Mode 74 in mine with most features exploited, Mode 92 in Yllawwally's entry). These modes are both perfectly compatible with the normal unmodified kernel.

This pack of kernel boost hacks are quite extreme, I wouldn't push it into the master, rather the original "2000 cycle boost" hack along with inline mixer tweaks. The original "2000 cycle boost" hack just changes the sync method on the scanline interrupt entry, so it is fairly compatible with everything (only Mode 13 or any modes using Timer 0 termination need timer value adjustments). The inline mixer tweaks can win additional cycles to that (in a normal 224 line display trimming 10 cycles from the inline mixer can give you ~400 cycles extra for user code). These are such modifications which wouldn't likely have any side effect apart from gaining VBlank cycles.

[uze6666]

This pack of kernel boost hacks are quite extreme, I wouldn't push it into the master, rather the original "2000 cycle boost" hack along with inline mixer tweaks. The original "2000 cycle boost" hack just changes the sync method on the scanline interrupt entry, so it is fairly compatible with everything (only Mode 13 or any modes using Timer 0 termination need timer value adjustments). The inline mixer tweaks can win additional cycles to that (in a normal 224 line display trimming 10 cycles from the inline mixer can give you ~400 cycles extra for user code). These are such modifications which wouldn't likely have any side effect apart from gaining VBlank cycles.

Sounds good for me. Is there a way to see a diff so I can get a grasp of the changes?

[Jubatian]

Here is a comparison with the original simple kernel boost. I tested it again, nothing breaks expect Mode 13 as far as I see. In Flight of a Dragon I use a slightly more advanced variant to do the timer sync, gaining a few extra cycles (every cycle gained multiplies with the number of VBlank lines you have, so it pays off to push it), but not much more.

I tried to quick fix Mode 13, but I bumped against the code on line 951 in videoMode13core.s. Damn it, why? It is impossible to subtract 57 from that keeping that routine taking the same amount of cycles!

[Jubatian]

I now added a compatibility constant to allow making timer terminated modes compatible with differently timed kernels.

https://github.com/Jubatian/uzebox/tree/simple_boost

Mode 13 as it is now was possible to be transformed accordingly, so it now works with the simple boost. You may check it out and experiment with it (the current master is merged there with the kernel boost hack). If this proves to be satisfactory, I will propagate it into the master kernel, so you can have slightly more cycles to work with in VBlank.

[D3thAdd3r]

Very nice, you develop so fast I can barely keep up just knowing what has improved; those are delightful surprises of assembly sorcery! There seem some important core improvements lately that will have a large effect on games.

On the 32 tiles wide 5.5 cycle mode 3 I just want to say that will be an amazing thing for certain games. For the SPI vram concept(which I hope can be 32)I will try to make a new sprite demo with regular M3 for now, but it seems you have already found the cycles(in what was already optimized asm in my mind) to blit 50 ram tiles.