Dunno if it's of help, but.. dilemma of EGA & VGA combo

The memory layout would depend on how you connected the extra memory to the CRTC. The easiest way would be to connect your new A14 to RA1 in +GRPH mode the same way that A13 is currently connected to RA0. Then the memory layout would be interlaced with 4 lines instead of 2 like Hercules. Other layouts are possible but would probably require more logic. As well as this mod you'd also need a mod to latch the attribute byte on the +Q2' falling cycle in +GRPH+HRES mode, or every fourth byte on the screen would repeat the one two bytes previous. Another mod that would go well with this would be one to make interlaced 320x400x2 and 640x400x2 modes (and 50-line text modes) possible.

Jo22 wrote on 2023-09-11, 23:15:

I wonder if it's possible to have 640x200 in 4 colours on a regular CGA card. Assuming that 32 KB were physically available (as […]
Show full quote

I wonder if it's possible to have 640x200 in 4 colours on a regular CGA card.
Assuming that 32 KB were physically available (as piggy back) and that no aliasing happens (BC000-BFFFF range is an alias of B8000-BBFFF, the primary CGA page).

And most importantly, how would the memory layout look like in a modified CGA's 640x200 4c mode ?
Would it look like Plantronics 640x200 4c mode, like a variation of 320x200 4c mode?

In my opinion, you would essentially be building a Plantronics card at that point.
That card effectively doubled the RAM and pixel generation logic to output two pages of video memory with CGA 320x200 4-color layout as a combined 320x200 16-color picture or two pages of video memory with CGA 640x200 2-color layout as a combined 640x200 4-color picture.

A much simpler mod would replace the unused thin font in the CGA ROM with regular pixel patterns and wire up that address line somewhere.
You could then use something like the 160x100 16-color pseudo graphics mode, but it would be more like a 640x200 16-color picture with lossy compression.
Maybe have a look at the Walsh-Hadamard transform. It could potentially be useful in this context.

That would indeed be a very nice and simple mod! Bit 4 or 5 of the palette register would be a good one to choose as it otherwise has no effect in text modes. Since only half of the bit patterns are needed (you can get the others by swapping the foreground and background colours) you could use half of the character positions for a 640x100x16 mode and the other half for a 320x200x16 mode.

Could you elaborate on how the Walsh-Hadamard transform could be useful here? I'm intrigued! My CGAArt program can do this sort of lossy compression (picking the optimal character/foreground/background combination in each character position) but doesn't use such a transform.

reenigne wrote on 2023-09-14, 20:24:

That would indeed be a very nice and simple mod! Bit 4 or 5 of the palette register would be a good one to choose as it otherwise has no effect in text modes. Since only half of the bit patterns are needed (you can get the others by swapping the foreground and background colours) you could use half of the character positions for a 640x100x16 mode and the other half for a 320x200x16 mode.

Sure. Such patterns would also be an option, and admittedly a much simpler one.

reenigne wrote on 2023-09-14, 20:24:

Could you elaborate on how the Walsh-Hadamard transform could be useful here? I'm intrigued! My CGAArt program can do this sort of lossy compression (picking the optimal character/foreground/background combination in each character position) but doesn't use such a transform.

I think what makes the (2D) WHT handy is that, much like with the DCT, you basically get the spectrum of the input data, but kind of the square wave version, which looks better-suited to bi-level input data.
If you use a JPEG-like zig-zag reordering of the 2D coefficient matrix, quantize the WHT coefficients with power-of-two quantization factors by truncation and concatenate them, you would get a bit string that, if interpreted as an integer, roughly has the coarse features, starting with the DC offset, in the most significant bits and the fine detail in the least significant bits. This can then be used as a table index for locality-sensitive hashing, i.e. to help find an approximate nearest neighbor without an exhaustive search, and ideally in O(1).
This should technically work with arbitrary target pixel patterns, but one could also custom tailor them to the WHT to optimize the selection process.

Benedikt wrote on 2023-09-15, 17:52:

I think what makes the (2D) WHT handy is that, much like with the DCT, you basically get the spectrum of the input data, but kind of the square wave version, which looks better-suited to bi-level input data.
If you use a JPEG-like zig-zag reordering of the 2D coefficient matrix, quantize the WHT coefficients with power-of-two quantization factors by truncation and concatenate them, you would get a bit string that, if interpreted as an integer, roughly has the coarse features, starting with the DC offset, in the most significant bits and the fine detail in the least significant bits. This can then be used as a table index for locality-sensitive hashing, i.e. to help find an approximate nearest neighbor without an exhaustive search, and ideally in O(1).
This should technically work with arbitrary target pixel patterns, but one could also custom tailor them to the WHT to optimize the selection process.

Ah, so the WHT would be for creating the font given some images rather than for creating attribute clash images given the font? That is an interesting idea, and I'm quite curious about what the resulting font would look like. One could generate bit patterns for scanline 0 based on using 1 scanline per row, then fill in the bit patterns for scanline 1 based on using 2 scanlines per row (and given the existing scanline 0), and then so on for scanlines 2-3 and 4-7. That way the font would work well for various character cell heights. I have a collection of images that I've played about with in CGAArt - I might have a go at optimising a font based on these and see what happens.

Jo22 wrote on 2023-09-11, 23:15:

I wonder if it's possible to have 640x200 in 4 colours on a regular CGA card.

If you'd like to play with that concept without modifying a CGA card, the PCjr and Tandy 1000 systems already have that as a supported mode (in the BIOS, no less), as it was introduced with the PCjr.