Hello.

I don't know if this is the proper section; posted this here because it is not a release, but rather me asking how to do it 🤣

TL;DR:
- How do I run code every VBlank?
- Which would be proper development tools for DOS?
- How do I need to deal with real/protected/etc modes? Which modes does it need to support, or in what way?
(i.e. I could try all modes but I don't know whether some might be more difficult or important to implement than others, I'm just trying to sort the priorities so I can release most important functions first and least important later)

Long time no see, I had been finishing my studies. I haven't forgot about the TSR I planned to make, and I made... a very little progress: Just got my first ever custom "TSR Code" to run!; by editing an old keyboard TSR made for Microsoft C Optimizing Compiler. I also happened to learn how to overwrite an interrupt pointer (int 0x10 in this case), getting input parameters through the calls, and sending them to the old int 0x10 using a magical function called chain_intr.
But I hit a roadblock when trying to implement the display mode replacement function... For my custom 0x4F01, I couldn't prepare a custom struct and set a pointer to it in a specific register to return because... No matter what, I simply couldn't set the struct's pointer to a register.

To keep it simple:

_asm { mov _ax, ax }; […]
Show full quote

_asm
{
mov _ax, ax
};

asm
{
mov _ax, ax
};

__asm
{
mov _ax, ax
};

None of these work! Essential for either:
- Preparing a new struct and return it
or
- Accessing firmware's returned struct and modifying it
That was my attempt from weeks ago, but I only managed to come back to it today so I don't know if I'll find a workaround before dropping my pirated copy of Microsoft's compiler for good...

... I guess this is what VBEPlus is meant to do? I wish it worked on my PC though, it says there's no "free modes available" IIRC, it could need a rather quick hotfix, but it's closed source AND the creator seems unreachable (??? or maybe I haven't tried hard enough).

I do know C (not C++!), but looks like I'm required to learn x86 ASM to do this... there's just not much to look at, just a bunch of ASM-based TSR examples with no C code, and useful TSRs and tools which might need tweaking but happen to be closed source and too old for their authors to be contactable.

In the meantime during my studies I have learnt more about PCs architecture and... oof, what about real/protected/etc modes? I got a bunch more to learn about that for sure, but what would be the best way for dealing with this, or which would be the "best tools"?
For instance, Microsoft C Compiler is most likely very different from the more widely used DJGPP.
I don't have "big" plans though, I'd just offer a pretty dumb tool to get lower display resolutions to work, by abusing CPU if necessary (and keeping it all the most hardware-independent as possible). I'm currently relying on the fact that my PC's internal graphics (Radeon HD 8570d/Trinity ATOMBIOS), aside of having fewer resolution modes and reporting VBE version 3 (the number alone breaks the checks within MAANY programs), the rest of the implementation SEEMS completely flawless: 8 bit modes available, 15 & 16 modes too, no artifacts in older windows versions/basic drivers, I get no problems with the mirrors in Duke3D, and so on

For now the first step is making a functional clone of VBEPlus (I guess): "Produce" lower resolution modes, based off the higher resolution ones (i.e. replace 1024x768 with 512x384 (and yes I'm still totally determined to get NO$GMB's interface running correctly here)).
That would leave graphics running on the top-left of the screen + whatever other programs left outside that area + whatever bug causes your program to draw outside the intended display area 😜

The next and final step (if possible and not too difficult (?)) would be to scale said top-left area to the full screen, and convert color bit-depth if necessary! That way it could emulate 8-bit color support.
The problem is, I got no idea how to even tackle that... I suposse I could just allocate and return a backbuffer to the programs, then convert size/color transfering from the backbuffer into the visible framebuffer... through software, every VBlank. But how do I even get code running on every VBlank?