Is there a solution to emulate EGA in Tandy (PCJr)?
Because the video modes are similar (320 × 200 × 16) —
https://groups.google.com/g/comp.sys.tandy/c/qQ7XYKSLItA
Although the modes are visually identical (320x200 pixels resolution and the same 16 colors), technically and internally they are not the same at all. For example, you could reuse the same bitmap graphics for all the 320x200x16 modes, but the code to represent those graphics on screen would be radically different.
EGA native modes are planar modes, that is, every of the four basic color components (Blue, Green, Red and Yellow) is stored in one memory plane/bank. They use the same memory address (segment A000h) but a port changes the plane/bank to read from/write to. This "trick" makes possible for the EGA to use more than 64 kb of memory if the card has it, bypassing the original IBM PC memory map and design limitations. So in low resolution mode it can hold up to 8 video pages, 4 on mid resolution (640x200x16). High resolution mode (640x350) is just impossible in full 16 colors if the card doesn't have at least 128 Kb. In brief, each of the 4 colour planes is limited to 64 Kb, but nothing impedes to have 4 planes of 64 kb each on a 256 kb card. If the card only has 64kb of RAM, there still are 4 planes but, logically, with only 16 kb of memory each. This poses and extra difficulty while programming it. Apart of the planar nature, EGA is also a quite more complex piece of hardware, having different extra possibilities than simpler adapters such as CGA or Hercules, such as hardware masking (that is, you can draw a image with transparent pixels by drawing first its bit mask), fast 4 pixels at once hardware memory copying, several different write/read modes, custom charset and smooth 1 pixel horizontal scrolling.
By contrast, both Plantronics and PCjr/Tandy can be seen as extended CGA modes. They are much simplier. In PCjr/Tandy we have two pixels per byte. Each nibble (4 bits) has the 4 color components (this time Red, Green, Blue, Yellow, the order is slightly different than in EGA). The low resolution mode is interchangeable with CGA, there's no need to change the programming. But the 320x200 needs to manage 4 scanlines instead of 2. Plantronics has a similar but slightly different scheme that
is very well explained here
The problem with QBASIC/QuickBASIC is that it's a quite close software ecosystem. Turbo C, Turbo Pascal and, I think, QuickC have a more open and abstract driver model that allows the user to write drivers for different graphic modes/adapters while using the same graphic primitives to draw lines, circles, get/put bitmaps, etc. But AFAIK QuickBASIC doesn't have any of this. The graphics support it has is what you have. The BASIC libraries are very closed. I think Quick BASIC dropped the PCjr/Tandy support. There were some GW-BASIC, ROM BASIC and catridge BASIC versions that supported those modes but not QuickBASIC.
So I think the solution would be to build some custom libraries in assembler with your custom graphic primitives, and call them from your QuickBASIC program. That's something that was done in the game MagiDuck. There's a thread on this very forum with the process. That game used a new pseudo graphic mode tweaking text mode and everything sould be done from scratch and implemented in assembler. That would be definitely something that would give a lot more work that just simply using an already released driver with the BASIC graphic primitives.